<remark><p>Retracted in favor of XEP-0167, which now consolidates both audio and video chat via RTP and therefore contains the content originally published in this specification.</p></remark>
<remark><p>Specified default value for profile attribute; clarified relationship to SDP offer-answer model; moved some attributes from payload-type element to optional parameter elements.</p></remark>
<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>
<pclass='box'><em>Note: This specification has been retracted in favor of &xep0167;, which now consolidates both audio and video chat via RTP and therefore contains the content originally published in this specification; please refer to XEP-0167 for the most up-to-date definition of XMPP video chat.</em></p>
<p>&xep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. One session type of interest is video chat. 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>
<li><p>The application format 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'>Application 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>
<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 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 <cite>RFC 4566</cite> 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.</p>
<p>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.</p>
<p>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.).</p>
<p>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 <cite>RFC 3551</cite>. The payload IDs are represented in the 'id' attribute.</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", "height", "sampling", and "width" 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:</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 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).</p>
<p>Upon receiving the session-initiate stanza, the responder determines whether it can proceed with the negotiation. The general Jingle error cases are specified in <cite>XEP-0166</cite> and illustrated &xep0167;. In addition, the responder must determine if it supports any of the payload types advertised by the initiator; if it supports none of the offered payload types, it must reject the session by returning a ¬acceptable; error with a Jingle-Video-specific condition of <unsupported-codecs/>:</p>
<examplecaption="Responder does not support any of the codecs"><![CDATA[
<p>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.</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 profile is negotiated via the 'profile' attribute of the &CONTENT; element in the Jingle negotiation (e.g., "RTP/AVT"), 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>
<p>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.</p>
<p>If an entity supports Jingle video exchanges via RTP, it MUST advertise that fact by returning a feature of "urn:xmpp:tmp:jingle:apps:video" in response to &xep0030; information requests &NSNOTE;.</p>
<p>Informational messages may be sent by either party within the context of Jingle to communicate the status of a Jingle video session, device, or principal. The informational message MUST be an IQ-set containing a &JINGLE; element of type "session-info". No informational message payload elements have yet been defined for Jingle Video via RTP, but they may be specified in a future version of this document.</p>
<p>In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the transport method and media being exchanged; for example, in the case of UDP, that would include Datagram Transport Layer Security (DTLS) as specified in &rfc4347;. &sdpdtls; defines such methods for the Session Description Protocol; the relevant RTP profile (e.g., "UDP/TLS/RTP/SAVP" for transporting the RTP stream over DTLS with UDP) shall be specified as the value of the &CONTENT; element's 'profile' attribute.</p>
<p>Upon advancement of this specification, the ®ISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.</p>
<p>The following namespaces are requested, and are thought to be unique per the XMPP Registrar's requirements:</p>