git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1881 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-05-28 21:09:35 +00:00
parent 50b382ce76
commit 441471d7d6
1 changed files with 9 additions and 51 deletions

View File

@ -21,12 +21,18 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>TO BE ASSIGNED</shortname>
<shortname>NOT_YET_ASSIGNED</shortname>
&joebeda;
&scottlu;
&stpeter;
&hildjj;
&seanegan;
<revision>
<version>0.18</version>
<date>2008-05-28</date>
<initials>psa</initials>
<remark><p>Removed content-replace action from acceptance flow, since in ICE that information is sent via STUN, not in the signalling channel.</p></remark>
</revision>
<revision>
<version>0.17</version>
<date>2008-03-20</date>
@ -197,10 +203,6 @@ INITIATOR RESPONDER
|<-----------------------------------|
| STUN Binding Result |
|----------------------------------->|
| Jingle content-replace |
|----------------------------------->|
| Jingle ack (XMPP IQ-result) |
|<-----------------------------------|
| Jingle session-accept |
|<-----------------------------------|
| Jingle ack (XMPP IQ-result) |
@ -539,59 +541,15 @@ INITIATOR NAT RESPONDER
|<===============RTP now can flow===============|
| | |
]]></code>
<p>Note: The initiator (controlling agent) is using "aggressive nomination" as described in Section 8.1.1.2 of &icecore; and therefore includes the USE-CANDIDATE attribute in the STUN Binding Requests it sends.</p>
<p>Note: Here the initiator (controlling agent) is using "aggressive nomination" as described in Section 8.1.1.2 of &icecore; and therefore includes the USE-CANDIDATE attribute in the STUN Binding Requests it sends.</p>
</section2>
<section2 topic='Acceptance of Successful Candidate' anchor='protocol-acceptance'>
<p>If, based on STUN connectivity checks, the parties determine that they will be able to exchange media between a given pair of local candidates and remote candidates (i.e., the pair is "nominated" and ICE processing is "completed"), the parties shall proceed as follows:</p>
<ol>
<li>The initiator sends a Jingle content-replace action to the responder.</li>
<li>The responder acknowledges receipt of the content-replace.</li>
<li>The responder sends a Jingle session-accept action to the initiator.</li>
<li>The initiator acknowledges receipt of the session-accept.</li>
</ol>
<p>First the initiator sends a Jingle content-replace action to the responder. The content-replace MUST contain information about the nominated pair, including the "rem-addr" and "rem-port" attributes (which specify the IP address and port for the responder's end of the pair, which is a "remote address" according to the initiator). This enables both parties to explicitly agree to both ends of the connection pair (i.e., the local address+port and the remote address+port).</p>
<example caption="Initiator requests content-replace"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='rep1'
to='juliet@capulet.lit/balcony'
type='set'>
<jingle xmlns='urn:xmpp:tmp:jingle'
action='content-replace'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='this-is-the-audio-content' profile='RTP/AVP'>
<description xmlns='urn:xmpp:tmp:jingle:apps:audio-rtp'>
[ ... ]
</description>
<transport xmlns='urn:xmpp:tmp:jingle:transports:ice-udp'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='8hhy'>
<candidate component='1'
foundation='1'
generation='0'
ip='192.0.2.3'
network='1'
port='45664'
priority='1694498815'
protocol='udp'
rel-addr='10.0.1.1'
rel-port='8998'
rem-addr='192.0.2.1'
rem-port='3478'
type='srflx'/>
</transport>
</content>
</jingle>
</iq>
]]></example>
<p>The responder then acknowledges the content-replace action.</p>
<example caption="Responder acknowledges content-replace"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='rep1'
to='romeo@montague.lit/orchard'
type='result'/>
]]></example>
<p>The responder then sends a session-accept action to the initiator, specifying the candidate that succeeded.</p>
<p>First, the responder sends a session-accept action to the initiator, specifying the candidate that succeeded. The session-accept MUST contain information about the nominated pair, including the "rem-addr" and "rem-port" attributes (which specify the IP address and port for the responder's end of the pair, which is a "remote address" according to the initiator). This enables both parties to explicitly agree to both ends of the connection pair (i.e., the local address+port and the remote address+port).</p>
<example caption="Responder definitively accepts the successful candidate"><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='accept1'