This document defines a media description format for Jingle audio sessions.
WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.
Status: Experimental
Type: Standards Track
Number: 0167
Version: 0.2
Last Updated: 2006-02-13
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0166
Supersedes: None
Superseded By: None
Short Name: jingle-audio
Wiki Page: <http://wiki.jabber.org/index.php/Jingle Audio Media Description Format (JEP-0167)>
Email:
scottlu@google.com
JID:
scottlu@google.com
Email:
stpeter@jabber.org
JID:
stpeter@jabber.org
This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Jingle [1] can be used to initiate and negotiate a wide range of peer-to-peer sessions. The first session type of interest is audio chat. This document specifies a format for describing Jingle audio sessions.
The Jingle media description format defined herein is designed to meet the following requirements:
A Jingle audio session is described by one or more encodings contained within a wrapper <description/> element. In the language of RFC 2327 these encodings are payload-types; therefore, each <payload-type/> element specifies an encoding that can be used for the audio stream. Such encodings are often used in the context of the Real-time Transfer Protocol (RTP; see RFC 3550 [3]) but may be used in other contexts as well. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in RFC 3551 [4] (these "static" types are reserved from payload ID 0 through payload ID 96), although other encodings are allowed (these "dynamic" types use payload IDs 97 to 127) in accordance with the dynamic assignment rules described in Section 3 of RFC 3551. The 'id' attribute is REQUIRED and the 'name' attribute is RECOMMENDED. The encodings SHOULD be provided in order of preference.
Example 1. Audio Description Format
<description xmlns='http://jabber.org/protocol/jingle/media/audio'>
<payload-type id='18' name='G729'/>
<payload-type id="97" name="IPCMWB"/>
<payload-type id='98' name='L16' rate='16000' channels='2'/>
<payload-type id="96" name="ISAC" rate="8000"/>
<payload-type id="102" name="iLBC"/>
<payload-type id="4" name="G723"/>
<payload-type id="100" name="EG711U"/>
<payload-type id="101" name="EG711A"/>
<payload-type id="0" name="PCMU" rate="16000"/>
<payload-type id="8" name="PCMA"/>
<payload-type id="13" name="CN"/>
</description>
The <description/> element is intended to be a child of a <jingle/> element as specified in JEP-0166.
If the payload type is static (payload-type IDs 0 through 96 inclusive), it SHOULD be mapped to a media field defined in RFC 2327: Session Description Protocol (SDP). The generic format for the media field is as follows:
m=<media> <port> <transport> <fmt list>
In the context of Jingle audio sessions, the <media> is "audio", the <port> is the preferred port for such communications (which may be determined dynamically), the <transport> is "RTP/AVP", and the <fmt list> is the payload-type ID.
For example, consider the following static payload-type:
Example 2. Jingle Format for Static Payload-Type
<payload-type id="13" name="CN"/>
Example 3. SDP Mapping of Static Payload-Type
m=audio 9999 RTP/AVP 13
If the payload type is dynamic (payload-type IDs 97 through 127 inclusive), it SHOULD be mapped to an SDP media field plus an SDP attribute field named "rtpmap".
For example, consider a payload of 16-bit linear-encoded stereo audio sampled at 16KHz associated with dynamic payload-type 98:
Example 4. Jingle Format for Dynamic Payload-Type
<payload-type id='98' name='L16' rate='16000' channels='2'/>
Example 5. SDP Mapping of Dynamic Payload-Type
m=audio 9999 RTP/AVP 98 a=rtpmap:98 L16/16000/2
If an entity supports the Jingle audio media description format, it MUST advertise that fact by returning a feature of "http://jabber.org/protocol/jingle/media/audio" in response to Service Discovery [5] information requests.
Example 6. Service Discovery Information Request
<iq from='romeo@montague.net/orchard'
id='disco1'
to='juliet@capulet.com/balcony'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
Example 7. Service Discovery Information Response
<iq from='juliet@capulet.com/balcony'
id='disco1'
to='romeo@montague.net/orchard'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='http://jabber.org/protocol/jingle'/>
<feature var='http://jabber.org/protocol/jingle/media/audio'/>
...
</query>
</iq>
Informational messages may be sent within the context of Jingle to communicate the status of a Jingle audio session. The following payload elements are defined for Jingle audio session information, qualified by the 'http://jabber.org/protocol/jingle/info/audio' namespace:
Table 1: Information Payload Elements
| Element | Meaning |
|---|---|
| <busy/> | The device is currently unavailable for a session because busy with another audio session. |
| <queued/> | The audio session request is queued for pickup. |
| <ringing/> | The device is ringing but the principal has not yet interacted with it to answer. |
Example 8. Target Entity Returns Busy Message
<iq from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard'
id='info1'
type='set'>
<jingle xmlns='http://jabber.org/protocol/jingle'
action='info'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<busy xmlns='http://jabber.org/protocol/jingle/info/audio'/>
</jingle>
</iq>
Example 9. Target Entity Returns Queued Message
<iq from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard'
id='info2'
type='set'>
<jingle xmlns='http://jabber.org/protocol/jingle'
action='info'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<queued xmlns='http://jabber.org/protocol/jingle/info/audio'/>
</jingle>
</iq>
Example 10. Target Entity Returns Ringing Message
<iq from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard'
id='info3'
type='set'>
<jingle xmlns='http://jabber.org/protocol/jingle'
action='info'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<ringing xmlns='http://jabber.org/protocol/jingle/info/audio'/>
</jingle>
</iq>
The description of a format for audio sessions introduces no known security vulnerabilities.
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [7].
The Jabber Registrar [8] shall include 'http://jabber.org/protocol/jingle/media/audio' and 'http://jabber.org/protocol/jingle/info/audio' in its registry of protocol namespaces.
The Jabber Registrar shall include the name "audio" in its registry of Jingle media descriptions. The registration is as follows:
<media>
<name>audio</name>
<desc>Jingle sessions that support audio exchanges</desc>
<doc>JEP-0167</doc>
</media>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/jingle/media/audio'
xmlns='http://jabber.org/protocol/jingle/media/audio'
elementFormDefault='qualified'>
<xs:element name='description'>
<xs:complexType>
<xs:sequence>
<xs:element ref='payload-type' minOccurs='0' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='payload-type'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='channels' type='xs:byte' use='optional'/>
<xs:attribute name='id' type='xs:unsignedByte' use='required'/>
<xs:attribute name='name' type='xs:string' use='optional'/>
<xs:attribute name='rate' type='xs:short' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/jingle/info/audio'
xmlns='http://jabber.org/protocol/jingle/info/audio'
elementFormDefault='qualified'>
<xs:element name='busy' type='empty'/>
<xs:element name='queued' type='empty'/>
<xs:element name='ringing' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
1. JEP-0166: Jingle <http://www.jabber.org/jeps/jep-0166.html>.
2. RFC 2327: SDP: Session Description Protocol <http://www.ietf.org/rfc/rfc2327.txt>.
3. RFC 3550: RTP: A Transport Protocol for Real-Time Applications <http://www.ietf.org/rfc/rfc3550.txt>.
4. RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control <http://www.ietf.org/rfc/rfc3551.txt>.
5. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
6. See <http://www.speex.org/>.
7. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
8. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
END