<remark><p>Specified how to include SDP parameters and codec-specific parameters; clarified negotiation process; added Speex examples; removed queued info message.</p></remark>
<remark><p>Defined info message for busy; added info message examples; recommended use of Speex; updated schema and XMPP Registrar considerations.</p></remark>
<p>&xep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. One session type of interest is audio (voice) chat. This document specifies a format for describing Jingle audio sessions.</p>
<p>A Jingle audio session is described by one or more encodings contained within a wrapper <description/> element. In the language of <cite>RFC 4566</cite> 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 <cite>RFC 3551</cite>.</p>
<p>The allowable attributes are as follows:</p>
<table>
<tr>
<th>Attribute</th>
<th>Description</th>
<th>Inclusion</th>
</tr>
<tr>
<td>channels</td>
<td>The number of channels; if omitted, it MUST be assumed to contain one channel</td>
<td>RECOMMENDED</td>
</tr>
<tr>
<td>clockrate</td>
<td>The sampling frequency in Hert</td>
<td>RECOMMENDED</td>
</tr>
<tr>
<td>id</td>
<td>The payload identifier</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>maxptime</td>
<td>Maximum packet time as specified in RFC 4566</td>
<td>OPTIONAL</td>
</tr>
<tr>
<td>name</td>
<td>The appropriate subtype of the audio MIME type</td>
<td>RECOMMENDED for static payload types, REQUIRED for dynamic payload types</td>
</tr>
<tr>
<td>ptime</td>
<td>Packet time as specified in RFC 4566</td>
<td>OPTIONAL</td>
</tr>
</table>
<p>The encodings SHOULD be provided in order of preference.</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 <cite>draft-ietf-avt-rtp-speex</cite><note>This Internet-Draft has expired; see <<linkurl='http://www.watersprings.org/pub/id/draft-ietf-avt-rtp-speex-00.txt'>http://www.watersprings.org/pub/id/draft-ietf-avt-rtp-speex-00.txt</link>> for an archived version.</note>, the "ebw", "eng", "mode", "sr", and "vbr" parameters may be specified in relation to usage of the Speex <note>See <<linkurl='http://www.speex.org/'>http://www.speex.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>
</section1>
<section1topic='Negotiating a Jingle-Audio Session'anchor='negotiating'>
<p>Upon receiving a Jingle initiate stanza containing a Jingle Audio content description as defined in this document, a receiver iterates through the list of offered payload types, composing an appropriate Jingle Audio response description according to the following rules:</p>
<ul>
<li>If the receiver does not support the offered encoding, it MUST NOT include the encoding in its response.</li>
<li>If the receiver does support the offered encoding, it SHOULD include the encoding in the response, preserving the offered payload type.</li>
<li>If the receiver is unable to support the offered encoding with the offered payload type, it MAY provide an alternate payload type in its response. This typically will happen only when translating from other signalling protocols.</li>
<li>The receiver SHOULD preserve the order of the offered encodings, which represents the priority assigned to them by the initator.</li>
</ul>
<p>If, after applying these rules, the receiver determines it does not support any of the offering encodings, the receiver MUST reject the session by sending a <unsupported-codecs/> error in response to the initiator's "initiate" action. Otherwise, it MUST provisionally accept the session by sending an empty IQ result. If the response content type differs from the one offered, the receiver MUST then propose the change in a "description-modify" action as defined in <cite>XEP-0166</cite>. If the description is identical, the receiver MUST send a "description-accept" action (either explicitly, or implicitly as part of a "session-accept" or "content-accept" action).</p>
<p>Following is an example of this negotiation:</p>
<p>The initiator acknowledges the 'description-modify' with an empty IQ result, and sends a 'description-accept' to accept the new Jingle Audio content description.</p>
<examplecaption="Initiator Accepts New Content Description"><![CDATA[
<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: Session Description Protocol</cite> (SDP). The generic format for the media field is as follows:</p>
<p>In the context of Jingle audio sessions, the <content> is "audio", 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.</p>
<p>For example, consider the following static payload-type:</p>
<examplecaption="Jingle Format for Static Payload-Type"><![CDATA[
<payload-typeid="13"name="CN"/>
]]></example>
<examplecaption="SDP Mapping of Static Payload-Type"><