<abstract>This document defines methods for negotiating Jingle video sessions that use the Real-time Transport Protocol (RTP) for media exchange.</abstract>
<remark><p>More completely specified how to include SDP parameters and codec-specific parameters (same approach as in XEP-0167); added and corrected Theora examples.</p></remark>
<remark><p>Specified Jingle conformance, including the need to use a lossy transport and the process of sending and receiving video content.</p></remark>
<remark><p>Added negotiation flow and SDP mapping; renamed to mention RTP as the associated transport; corrected negotiation flow to be consistent with SIP/SDP (each party specifies a list of the payload types it can receive); added profile attribute to content element in order to specify RTP profile in use.</p></remark>
<p>&xep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. One session type of interest is video exchange. This document specifies a format for describing Jingle video sessions, where the media exchange occurs using the Real-time Transport Protocol (see &rfc3550;).</p>
<p>In accordance with Section 8 of <cite>XEP-0166</cite>, this document specifies the following information related to the Jingle Video via RTP application type:</p>
<ol>
<li><p>The content negotiation process is defined in the <linkurl='#negotiation'>Negotiating a Jingle Video Session</link> section of this document.</p></li>
<li><p>The semantics of the &DESCRIPTION; element are defined in the <linkurl='#format'>Content Description Format</link> section of this document.</p></li>
<li><p>A mapping of Jingle semantics to the Session Description Protocol is provided in the <linkurl='#sdp'>Mapping to Session Description Protocol</link> section of this document.</p></li>
<li><p>A Jingle video session MUST use a lossy transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;.</p></li>
<li>
<p>Content is to be sent and received as follows:</p>
<ul>
<li><p>Outbound video content shall be encoded into RTP packets and each packet shall be sent individually over the transport. Each inbound packet received over the transport is an RTP packet.</p></li>
<p>A Jingle video session is described by one or more encodings contained within a wrapper &DESCRIPTION; element qualified by the 'http://www.xmpp.org/extensions/xep-0180.html#ns' namespace &NSNOTE;. In the language of <cite>RFC 4566</cite> these encodings are payload-types; therefore, each <payload-type/> child element specifies an encoding that can be used for the video stream. Such encodings are often used in the context of the Real-time Transfer Protocol (RTP; see <cite>RFC 3550</cite>) but may be used in other contexts as well. 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 in accordance with the dynamic assignment rules described in Section 3 of <cite>RFC 3551</cite> (these "dynamic" types use payload IDs 96 to 127). The &PAYLOADTYPE; element's 'id' attribute is REQUIRED and its 'name' attribute is RECOMMENDED. The encodings SHOULD be provided in order of preference.</p>
<p>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", and "sampling" parameters may be specified in relation to usage of the Theora <note>See <<linkurl='http://www.theora.org/'>http://www.theora.org/</link>>.</note> codec. Where such parameters are encoded via the "fmtp" SDP attribute, they shall be represented in Jingle via the following format, where the <parameter/> element is a child of the &PAYLOADTYPE; element:</p>
<p>Note: The parameter names are effectively guaranteed to be unique, since &IANA; maintains a registry of SDP parameters (see <<linkurl='http://www.iana.org/assignments/sdp-parameters'>http://www.iana.org/assignments/sdp-parameters</link>>).</p>
<p>When the initiator sends a session-initiate stanza to the receiver, 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):</p>
<p>Upon receiving the session-initiate stanza, the receiver determines whether it can provisionally accept the session and proceed with the negotiation. The general Jingle error cases are specified in <cite>XEP-0166</cite>. In addition, the receiver must determine if it supports any of the payload types advertised by the initiator; if it does not, it MUST reject the session by sending a ¬acceptable; error, which SHOULD include a Jingle-specific error condition of <unsupported-codecs/>:</p>
<p>The receiver then should send a list of the payload types that it can receive via a Jingle "content-accept" (or "session-accept") action. The list that the receiver sends MAY include any payload types (not a subset of the payload types sent by the initiator) but SHOULD retain the ID numbers and order specified by the initiator.</p>
<p>If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to a media field defined in <cite>RFC 4566</cite>. The generic format for the media field is as follows:</p>
<p>In the context of Jingle video sessions, the <media> is "video", the <port> is the preferred port for such communications (which may be determined dynamically), the <transport> is whatever transport method is negotiated via the Jingle negotiation (e.g., "RTP/AVP"), and the <fmt list> is the payload-type ID.</p>
<p>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".</p>
<p>For example, consider a VC-1 payload such as that described in &rfc4425;:</p>
<examplecaption="Jingle Format for Dynamic Payload-Type"><