moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

missing check-in 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@485 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-02-02 02:21:18 +00:00
parent e7000fb1d1
commit c0e5dc2e6f
1 changed files with 80 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

81
xep-0167.xml
View File

@ -112,7 +112,7 @@
</tr>
<tr>
<td>clockrate</td>
<td>The sampling frequency in Hert</td>
<td>The sampling frequency in Hertz</td>
<td>RECOMMENDED</td>
</tr>
<tr>
@ -225,6 +225,85 @@
<iq to='romeo@montague.net/orchard' from='juliet@capulet.com/balcony' id='jingleaudio3' type='result'/>
]]></example>
</section1>
<section1 topic='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 target entity 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 target entity does not support the offered encoding, it MUST NOT include the encoding in its response.</li>
<li>If the target entity does support the offered encoding, it SHOULD include encoding in the response, preseriving the offered payload type.</li>
<li>If the target entity 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 target entity 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 target entity determines it does not support any of the offering encodings, the target entity MUST reject the session by sending a &lt;unsupported-codecs/&gt; error in response to the initiator's "initiate" message. Otherwise, it MUST provisionally accept the session by sending an empty IQ result. If the response content type differs from the one offered, the target entity MUST then propose the change in a "description-modify" message as defined in <cite>XEP-0166</cite>. If the description is identical, the target entity MUST send a "description-accept" message (either explictly, or implicitly as part of a "content-accept" message).</p>
<p>Following is an example of this negotiation:</p>
<example caption="Initiation Example"><![CDATA[
<iq to='juliet@capulet.com/balcony' from='romeo@montague.net/orchard' id='jingleaudio1' type='set'>
<jingle xmlns='http://jabber.org/protocol/jingle'
action='session-initiate'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<content name='audio'>
<description xmlns='http://jabber.org/protocol/jingle/description/audio'>
<payload-type id='96' name='speex' clockrate='16000'/>
<payload-type id='0' name='PCMU' />
</description>
<transport xmlns='http://jabber.org/protocol/jingle/transport/ice'>
...
</transport>
</content>
</jingle>
</iq>
]]></example>
<p>The target entity now follows the rules provided in this section and determines it can only support PCMU. It provisionally accepts the session:</p>
<example caption="Target Provisionally Accepts Session"><![CDATA[
<iq to='romeo@montague.net/orchard' from='juliet@capulet.com/balcony' id='jingleaudio1' type='result' />
]]></example>
<p>It then offers the new content description in a 'description-modify' message:</p>
<example caption="Initiation Example"><![CDATA[
<iq to='romeo@montague.net/orchard' from='juliet@capulet.com/balcony' id='jingleaudio2' type='set'>
<jingle xmlns='http://jabber.org/protocol/jingle'
action='description-modify'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<content name='audio'>
<description xmlns='http://jabber.org/protocol/jingle/description/audio'>
<payload-type id='0' name='PCMU' />
</description>
</content>
</jingle>
</iq>
]]></example>
<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>
<example caption="Initiator Accepts New Content Description"><![CDATA[
<iq to='juliet@capulet.com/balcony' from='romeo@montegue.net/orchard' id='jingleaudio2' type='result' />
<iq to='juliet@capulet.com/balcony' from='romeo@montegue.net/orchard' id='jingleaudio3' type='set' />
<jingle xmlns='http://jabber.org/protocol/jingle'
action='description-accept' initiator='romeo@montague.net/orchard' sid='a73sjjvkla37jfea'>
<content name='audio'>
<description xmlns='http://jabber.org/protocol/jingle/description/audio'>
<payload-type id='0' name='PCMU' />
</description>
</content>
</jingle>
</iq>
]]></example>
<p>Finally, the target acknowledges the 'description-accept'.</p>
<example caption="Target Provisionally Accepts Session"><![CDATA[
<iq to='romeo@montague.net/orchard' from='juliet@capulet.com/balcony' id='jingleaudio3' type='result' />
]]></example>
</section1>
<section1 topic='Mapping to Session Description Protocol' anchor='sdp'>
<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>
<code><![CDATA[