<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>
<code><![CDATA[
<parametername='foo'value='bar'/>
]]></code>
<p>The parameter names are 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>
<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"><