&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;).

The Jingle application format defined herein is designed to meet the following requirements:

1. Enable negotiation of parameters necessary for video chat.
2. Map these parameters to the Session Description Protocol (SDP; see &rfc4566;) to enable interoperability.
3. Define informational messages related to video chat.

In accordance with Section 8 of XEP-0166, this document specifies the following information related to the Jingle Video via RTP application type:

1. The application format negotiation process is defined in the Negotiating a Jingle Video Session section of this document.

2. The semantics of the &DESCRIPTION; element are defined in the Application Format section of this document.

3. A mapping of Jingle semantics to the Session Description Protocol is provided in the Mapping to Session Description Protocol section of this document.

4. A Jingle video session SHOULD use a lossy transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;.

5. Content is to be sent and received as follows:

   • 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.

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"). 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:

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 &rtptheora;, the "configuration", "configuration-uri", "delivery-method", "height", "sampling", and "width" parameters may be specified in relation to usage of the Theora See <http://www.theora.org/>. codec. Where such parameters are encoded via the "fmtp" SDP attribute, they shall be represented in Jingle via the following format:

Note: The parameter names are effectively guaranteed to be unique, since &IANA; maintains a registry of SDP parameters (see <http://www.iana.org/assignments/sdp-parameters>).

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).

Upon receiving the session-initiate stanza, the responder determines whether it can proceed with the negotiation. The general Jingle error cases are specified in XEP-0166 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/>:

If there is no error, the responder acknowledges the session initiation request:

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.

The initiator acknowledges the 'content-accept' with an empty IQ result:

After successful transport negotiation (for the ICE-UDP method, see XEP-0176), the responder then accepts the session:

And the initiator acknowledges session acceptance:

Note: For more examples, see XEP-0167.

The SDP media type for Jingle Video via RTP is "video" (see Section 8.2.1 of RFC 4566).

If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to a media field defined in RFC 4566. The generic format for the media field is as follows:

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.

For example, consider the following static payload-type:

That Jingle-formatted information would be mapped to SDP as follows:

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.

That Jingle-formatted information would be mapped to SDP as follows:

The Jingle-Video-specific error conditions are as follows:

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;.

Naturally, support may also be discovered via the dynamic, presence-based profile of service discovery defined in &xep0115;.

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.

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.

This document requires no interaction with &IANA;.