moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-25 10:42:19 -05:00
Code Issues Releases Wiki Activity

typos reported by Justin Karneges

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3185 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-05-28 16:25:44 +00:00
parent 9d2da32905
commit 5ae16b47cb
1 changed files with 2 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
xep-0176.xml
View File

@ -604,7 +604,7 @@ INITIATOR NAT RESPONDER
to='romeo@montague.lit/orchard' to='romeo@montague.lit/orchard'
type='result'/> type='result'/>
]]></example> ]]></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 check the newly-offered candidate for connectivity, as described previously. If the parties determine that media can flow over the candidate, they MAY then use the new candidate in subsequent communications.</p>
</section2> </section2>
<section2 topic='ICE Restarts' anchor='protocol-restarts'> <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> <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>
@ -643,8 +643,7 @@ INITIATOR NAT RESPONDER
to='romeo@montague.lit/orchard' to='romeo@montague.lit/orchard'
type='result'/> type='result'/>
]]></example> ]]></example>
<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>The parties would then exchange new candidates to renegotiate connectivity and would check the new candidates for connectivity, as described previously. If the parties determine that media can flow over one of the new candidates, they can then use the successful candidate in subsequent communications. However, while ICE is being renegotiated the parties can continue to send media with the existing candidate-in-use.</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> </section2>
</section1> </section1>