<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>
<section2topic='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>
<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>
<examplecaption="Responder definitively accepts the successful candidate"><![CDATA[