Specified default value for profile attribute; clarified relationship to SDP offer-answer model; moved some attributes from payload-type element to optional parameter elements.
A Jingle video session is described by a content type that contains one application format and one transport method. The application format consists of one or more encodings contained within a wrapper <description/> element qualified by the 'urn:xmpp:tmp:jingle:apps:video-rtp' namespace &NSNOTE;. In the language of RFC 4566 each encoding is a payload-type; therefore, each <payload-type/> element specifies an encoding that can be used for the audio stream, as illustrated in the following example.
The &DESCRIPTION; element is intended to be a child of a &CONTENT; element as specified in XEP-0166.
-The &DESCRIPTION; element SHOULD possess a 'profile' attribute that specifies the profile of RTP in use as would be encapsulated in SDP (e.g., "RTP/AVP" or "UDP/TLS/RTP/SAVP").
+The &DESCRIPTION; element SHOULD possess a 'profile' attribute that specifies the profile of RTP in use as would be encapsulated in SDP (e.g., "RTP/AVP" or "UDP/TLS/RTP/SAVP"). If not included, the default value of "RTP/AVP" MUST be assumed.
The encodings SHOULD be provided in order of preference by placing the most-preferred &PAYLOADTYPE; element as the first child of the &DESCRIPTION; element (etc.).
The allowable attributes of the &PAYLOADTYPE; element are as follows:
| positiveInteger | RECOMMENDED | -||
| height | -The vertical extent of the displayed video, in pixels | -positiveInteger | -RECOMMENDED | -
| id | A unique identifier for the payload type | positiveInteger | REQUIRED |
| layer | -The relationship of a layer to the "bottom" of the stack, where 0 = bottom (the first layer) | -nonNegativeInteger | -OPTIONAL | -
| name | A name for the payload type | string | RECOMMENDED for static payload types, REQUIRED for dynamic payload types |
| transparent | -Whether or not a layer is transparent | -boolean | -OPTIONAL | -
| width | -The horizontal extent of the displayed video, in pixels | -positiveInteger | -RECOMMENDED | -
| x | -The horizontal starting point of a tile, in pixels from the origin point | -positiveInteger | -OPTIONAL | -
| y | -The vertical starting point of a tile, in pixels from the origin point | -positiveInteger | -OPTIONAL | -
In Jingle Video, the encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in &rfc3551; (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of RFC 3551. The payload IDs are represented in the 'id' attribute.
-Each <payload-type/> element MAY contain one or more child elements that specify particular parameters related to the payload. For example, as described in &rtpspeex;, the "cng", "mode", and "vbr" parameters may be specified in relation to usage of the Speex
Each <payload-type/> element MAY contain one or more child elements that specify particular parameters related to the payload. For example, as described in &rtptheora;, the "configuration", "configuration-uri", "delivery-method", "height", "sampling", and "width" parameters may be specified in relation to usage of the Theora
]]>
@@ -224,7 +196,7 @@
When the initiator sends a session-initiate stanza to the responder, the &DESCRIPTION; element includes all of the payload types that the initiator can receive for Jingle video (each one encapsulated in a separate &PAYLOADTYPE; element):
+When the initiator sends a session-initiate stanza to the responder, the &DESCRIPTION; element includes all of the payload types that the initiator can send and/or receive for Jingle video, each one encapsulated in a separate &PAYLOADTYPE; element (the rules specified in &rfc3264; SHOULD be followed regarding inclusion of payload types).
If the responder wishes to accept the content definition, it MUST send a content-accept action to the initiator, which SHOULD include a list of the payload types that it can receive. The list that the responder sends MAY include any payload types (not a subset of the payload types sent by the initiator) but SHOULD retain the ID numbers specified by the initiator. The order of the &PAYLOADTYPE; elements indicates the responder's preferences, with the most-preferred types first.
+If the responder wishes to accept the content definition, it MUST send a content-accept action to the initiator, which SHOULD include a list of the payload types that it can send and/or receive. The list that the responder sends MAY include any payload types (not a subset of the payload types sent by the initiator) but SHOULD retain the ID numbers specified by the initiator. The order of the &PAYLOADTYPE; elements indicates the responder's preferences, with the most-preferred types first.
If the payload type is dynamic (payload-type IDs 96 through 127 inclusive), it SHOULD be mapped to an SDP media field plus an SDP attribute field named "rtpmap".
For example, consider a VC-1 payload such as that described in &rfc4425;:
That Jingle-formatted information would be mapped to SDP as follows:
As noted, if additional parameters are to be specified, they shall be represented as attributes of the <payload-type/> element or its child <parameter/> element, as in the following example.