Specified Jingle conformance, including the preference for lossy transports over reliable transports and the process of sending and receiving audio content over each transport type.
&xep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. One session type of interest is audio chat. This document specifies a format for describing Jingle audio sessions.
+&xep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. One session type of interest is audio chat. This document specifies a format for negotiating Jingle audio sessions over the Realtime Transport Protocol (RTP; see &rfc3550;).
The Jingle content description format defined herein is designed to meet the following requirements:
@@ -103,6 +109,22 @@In accordance with Section 8 of XEP-0166, this document specifies the following information related to the Jingle Audio via RTP application type:
+The content negotiation process is defined in the Negotiating a Jingle Audio Session section of this document.
The semantics of the &DESCRIPTION; element are defined in the Content Description Format section of this document.
A mapping of Jingle semantics to the Session Description Protocol is provided in the Mapping to Session Description Protocol section of this document.
A Jingle audio session SHOULD use a lossy transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;, but MAY use a reliable transport such as "ice-tcp".
Content is to be sent and received as follows:
+For lossy transports, outbound audio 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.
For reliable transports, outbound audio content shall be encoded into RTP packets and each packet data shall be sent in succession over the transport. Incoming data received over the transport shall be processed as a stream of RTP packets, where each RTP packet boundary marks the location of the next packet.
A Jingle audio 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/> element specifies an encoding that can be used for the audio stream. In Jingle Audio, these 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 allowable attributes are as follows:
@@ -184,14 +206,17 @@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: