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

0.27

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3180 4b5297f7-1745-476d-ba37-a9c6900126ab
xep-0352-v0.2
Peter Saint-Andre 14 years ago
parent e5fa993d83
commit 295dbec93d
1 changed files with 38 additions and 69 deletions
Show Stats Download Patch File Download Diff File

107
xep-0176.xml
Unescape Escape View File

@ -29,6 +29,12 @@
&hildjj;
&seanegan;
&robmcqueen;
<revision>
<version>0.27</version>
<date>2009-05-27</date>
<initials>psa</initials>
<remark><p>Clarified ICE restarts and use of the generation attribute, in accordance with the ICE specification.</p></remark>
</revision>
<revision>
<version>0.26</version>
<date>2009-03-09</date>
@ -348,7 +354,7 @@ INITIATOR RESPONDER
</tr>
<tr>
<td>generation</td>
<td>An index, starting at 0, that enables the parties to keep track of updates to the candidate throughout the life of the session.</td>
<td>An index, starting at 0, that enables the parties to keep track of updates to the candidate throughout the life of the session. For details, see the <link url='#protocol-restart'>ICE Restarts</link> section of this document.</td>
<td>N/A</td>
<td>0</td>
</tr>
@ -561,16 +567,15 @@ INITIATOR NAT RESPONDER
<p>(In accordance with Jingle core, the responder will also acknowledge the transport-info message.)</p>
<p>In the unlikely event that one of the parties determines that it cannot establish connectivity even after sending and checking lower-priority candidates, it SHOULD terminate the session as described in <cite>XEP-0166</cite>.</p>
</section2>
<section2 topic='Modifying an Existing Candidate' anchor='protocol-modify'>
<p>The creator of a content type MAY modify an existing, in-use candidate at any time during the session, for example to change the IP address or port. This is done by sending a transport-replace message with the changed candidate information, where the value of the 'generation' attribute is incremented to specify that the candidate information is a modification to an existing candidate.</p>
<p>An example follows (change to IP address and port).</p>
<example caption="Initiator modifies the in-use candidate"><![CDATA[
<section2 topic='Negotiating a New Candidate' anchor='protocol-renegotiate'>
<p>Even after media has begun to flow, either party MAY continue to send additional candidates to the other party (e.g., because the user agent has become aware of a new media proxy or network interface card). Such candidates are shared by sending a transport-info message.</p>
<example caption="Initiator sends a subsequent candidate"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='kl23fs71'
id='uh3g1f48'
to='juliet@capulet.lit/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='transport-replace'
action='transport-info'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='this-is-the-audio-content'>
@ -579,41 +584,43 @@ INITIATOR NAT RESPONDER
ufrag='8hhy'>
<candidate component='1'
foundation='1'
generation='1'
id='y3s2b30v3r'
ip='192.0.2.3'
network='1'
port='45665'
priority='1694498815'
generation='0'
id='m3110wc4nd'
ip='2001:db8::9:1'
network='0'
port='9001'
priority='21149780477'
protocol='udp'
type='srflx'/>
type='host'/>
</transport>
</content>
</jingle>
</iq>
]]></example>
<p>The recipient then acknowledges receipt.</p>
<example caption="Recipient acknowledges transport-replace"><![CDATA[
<p>The receiving party MUST acknowledge receipt of the candidate.</p>
<example caption="Recipient acknowledges receipt"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='kl23fs71'
id='uh3g1f48'
to='romeo@montague.lit/orchard'
type='result'/>
]]></example>
<p>If the transport-replace is acceptable, the recipient then sends a transport-accept message (if not, the recipient sends a transport-reject message).</p>
<example caption="Responder definitively accepts the replaced candidate"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='jh329df7'
to='romeo@montague.lit/orchard'
<p>The parties SHOULD check the newly-offered candidate for connectivity, as described previously. If the parties determine that media can flow over the candidate, MAY then use the new candidate in subsequent communications.</p>
</section2>
<section2 topic='ICE Restarts' anchor='protocol-restarts'>
<p>At any time, either party MAY restart the process of ICE negotiation by sending a candidate with a 'generation' value that is greater than the previous generation of candidates; when it does so, it MUST generate new values for the 'pwd' and 'ufrag' attributes, consistent with the definition of an ICE restart in Section 9.1.1.1 of &icecore;. As explained in &icecore;, typically the ICE negotiation would be restarted to change the media target (e.g., an IP address change for one of the parties) and certain third-party-call-control scenarios.</p>
<example caption="Initiator restarts ICE negotiation"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='kl23fs71'
to='juliet@capulet.lit/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='transport-accept'
action='transport-info'
initiator='romeo@montague.lit/orchard'
responder='juliet@capulet.lit/balcony'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='this-is-the-audio-content'>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='9uB6'>
pwd='bv71hdn38hgb39hf6xlk33'
ufrag='g7qs'>
<candidate component='1'
foundation='1'
generation='1'
@ -629,53 +636,15 @@ INITIATOR NAT RESPONDER
</jingle>
</iq>
]]></example>
<p>The initiator then acknowledges the responder's acceptance:</p>
<example caption="Initiator acknowledges content acceptance"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='jh329df7'
to='juliet@capulet.lit/balcony'
type='result'/>
]]></example>
<p>The parties then use the modified candidate in subsequent communications.</p>
</section2>
<section2 topic='Negotiating a New Candidate' anchor='protocol-renegotiate'>
<p>Even after media has begun to flow, either party MAY continue to send additional candidates to the other party (e.g., because the user agent has become aware of a new media proxy or network interface card). Such candidates are shared by sending a transport-info message.</p>
<example caption="Initiator sends a subsequent candidate"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='uh3g1f48'
to='juliet@capulet.lit/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='transport-info'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='this-is-the-audio-content'>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='8hhy'>
<candidate component='1'
foundation='1'
generation='0'
id='m3110wc4nd'
ip='2001:db8::9:1'
network='0'
port='9001'
priority='21149780477'
protocol='udp'
type='host'/>
</transport>
</content>
</jingle>
</iq>
]]></example>
<p>The receiving party MUST acknowledge receipt of the candidate.</p>
<example caption="Recipient acknowledges receipt"><![CDATA[
<p>The recipient then acknowledges receipt.</p>
<example caption="Recipient acknowledges transport-info"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='uh3g1f48'
id='kl23fs71'
to='romeo@montague.lit/orchard'
type='result'/>
]]></example>
<p>The parties SHOULD check the newly-offered candidate for connectivity, as described previously. If the parties determine that media can flow over the candidate, MAY then use the new candidate in subsequent communications.</p>
<p>The parties would then exchange new candidates to renegotiate connectivity. However, the paties can continue to send media using the existing candidate-in-use while ICE is being renegotiated.</p>
<p>In order to use one of the newly-negotiated candidates, the parties would use the transport-replace action as explained in the <link url='#protocol-renegotiate'>Negotiating a New Candidate</link> section of this document.</p>
</section2>
</section1>

Write Preview
Loading…
Cancel
Save