%ents; ]>
Jingle Video via RTP This document defines methods for negotiating Jingle video sessions that use the Real-time Transport Protocol (RTP) for media exchange. &LEGALNOTICE; 0180 Experimental Standards Track Standards Council XMPP Core XEP-0166 TO BE ASSIGNED &stpeter; Milton Chen Milton.Chen@vseelab.com 0.6 2007-04-17 psa

Specified Jingle conformance, including the need to use a lossy transport and the process of sending and receiving video content.

0.5 2007-03-23 psa

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.

0.4 2006-12-21 psa

Modified spec to use provisional namespace before advancement to Draft (per XEP-0053).

0.3 2006-08-23 psa

Modified namespace to track XEP-0166.

0.2 2006-07-12 psa

Updated to use content type instead of media type.

0.1 2006-03-23 psa/mc

Initial version.

0.0.1 2006-03-20 psa/mc

First draft.

&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;). Such sessions require the use of a lossy transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;.

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

  1. Enable negotiation of parameters necessary for video exchange.
  2. Map these parameters to 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 content 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 Content Description 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 MUST 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 one or more encodings contained within a wrapper &DESCRIPTION; element. In the language of RFC 4566 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 RFC 3550) 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 (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of RFC 3551. The &PAYLOADTYPE; element's 'id' attribute is REQUIRED and its 'name' attribute is RECOMMENDED. The encodings SHOULD be provided in order of preference.

]]>

The &DESCRIPTION; element is intended to be a child of a &JINGLE; element as specified in XEP-0166.

The defined attributes of the &PAYLOADTYPE; element are as follows:

Attribute Description Datatype/Units
channels The number of channels (e.g., 2 for stereoscopic video) positiveInteger (defaults to 1)
height The vertical extent of the displayed video, in pixels positiveInteger
id A unique identifier for the payload type positiveInteger
layer The relationship of a layer to the "bottom" of the stack, where 0 = bottom (the first layer) nonNegativeInteger
name A name for the payload type string
transparent Whether or not a layer is transparent boolean
width The horizontal extent of the displayed video, in pixels positiveInteger
x The horizontal starting point of a tile, in pixels from the origin point positiveInteger
y The vertical starting point of a tile, in pixels from the origin point positiveInteger

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

action='session-initiate' initiator='romeo@montague.net/orchard' sid='v1d30k1ll3dth3r4d10st4r'> ]]>

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 XEP-0166. 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 <unsupported-codecs/> error:

]]>

If there is no error, the receiver provisionally accepts the session:

]]>

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.

action='content-accept' initiator='romeo@montague.net/orchard' sid='v1d30k1ll3dth3r4d10st4r'> ]]>

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

]]>

After successful transport negotiation (not shown here), the receiver then accepts the session:

]]>

And the initiator acknowledges session acceptance:

]]>

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 transport method is negotiated via the Jingle negotiation (e.g., "RTP/AVT"), and the <fmt list> is the payload-type ID.

For example, consider the following static payload-type:

]]>

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

]]>

As noted, if additional parameters are to be specified, they shall be represented as attributes of the <payload-type/> element of the child <parameter/> element, as in the following example.

]]>

If an entity supports Jingle video exchanges via RTP, it MUST advertise that fact by returning a feature of "http://www.xmpp.org/extensions/xep-0180.html#ns" in response to &xep0030; information requests.

]]> ... ... ]]>

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", where the informational message is a payload element qualified by the 'http://www.xmpp.org/extensions/xep-0180.html#ns-info' namespace. No payload elements have yet been defined, but may be specified in a future version of this document.

Support for the Theora codec See <http://www.theora.org/>. is RECOMMENDED.

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/AVP" 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;.

Until this specification advances to a status of Draft, its associated namespaces shall be "http://www.xmpp.org/extensions/xep-0180.html#ns" and "http://www.xmpp.org/extensions/xep-0180.html#ns-info"; upon advancement of this specification, the ®ISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.

The XMPP Registrar shall include "video-rtp" in its registry of Jingle content description formats. The registry submission is as follows:

video-rtp Jingle sessions that support video exchange via the Real-time Transport Protocol lossy XEP-0180 ]]>
]]>