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

0.15

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1539 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-01-06 20:16:17 +00:00
parent 468918de69
commit 86af8f8784
1 changed files with 18 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
xep-0176.xml
View File

@ -27,6 +27,12 @@
&stpeter;
&hildjj;
&seanegan;
<revision>
<version>0.15</version>
<date>2008-01-06</date>
<initials>psa</initials>
<remark><p>Clarified several small points regarding candidate gathering procedures and STUN connectivity checks.</p></remark>
</revision>
<revision>
<version>0.14</version>
<date>2008-01-02</date>
@ -342,7 +348,7 @@ INITIATOR RESPONDER
</table>
</section3>
<section3 topic='Exchange of Candidates' anchor='protocol-candidates-exchange'>
<p>The first step in negotiating connectivity is for each party to immediately begin sending transport candidates to the other party. <note>The fact that both parties send candidates means that Jingle requires each party to be a full implementation of ICE, not a lite implementation as specified in &icecore;.</note> These candidates SHOULD be gathered by following the procedure specified in Section 4.1.1 of &icecore; and prioritized by following the procedure specified in Section 4.1.2 of &icecore;. Each candidate MUST be sent in a &JINGLE; element with an action of "transport-info".</p>
<p>The first step in negotiating connectivity is for each party to immediately begin sending transport candidates to the other party. <note>The fact that both parties send candidates means that Jingle requires each party to be a full implementation of ICE, not a lite implementation as specified in &icecore;.</note> These candidates SHOULD be gathered by following the procedure specified in Section 4.1.1 of &icecore; (typically by communicating with a stanadlone STUN server in order to discover the client's public IP address and port) and prioritized by following the procedure specified in Section 4.1.2 of &icecore;. Each candidate MUST be sent in a &JINGLE; element with an action of "transport-info".</p>
<p>If the responder receives and can successfully process a given candidate, it returns an IQ-result (if not, for example because the candidate data is improperly formatted, it returns an error). Note: The responder is only indicating receipt of the candidate, not telling the initiator that the candidate will be used.</p>
<p>The initiator keeps sending candidates, one after the other (without stopping to receive an acknowledgement of receipt from the responder for each candidate) until it has exhausted its supply of possible or desirable candidate transports. (Because certain candidates may be more "expensive" in terms of bandwidth or processing power, the initiator may not want to advertise their existence unless necessary.) For each candidate, the responder acknowledges receipt.</p>
<p>At the same time (i.e., immediately after acknowledging receipt of the session-initiate request, not waiting for the initiator to begin or finish sending candidates), the responder also begins sending potential candidates, in order of desirability according to the responder. As above, the initiator acknowledges receipt of the candidates.</p>
@ -392,8 +398,8 @@ INITIATOR RESPONDER
priority='1694498815'
protocol='udp'
pwd='asd88fgpdd777uzjYhagZg'
raddr='10.0.1.1'
rport='8998'
rel-addr='10.0.1.1'
rel-port='8998'
type='srflx'
ufrag='8hhy'/>
</transport>
@ -459,7 +465,7 @@ INITIATOR RESPONDER
<li>The STUN Binding Requests generated by the initiator MAY include the USE-CANDIDATE attribute to indicate that the initiator wishes to cease checks for this component.</li>
<li>The STUN Binding Requests generated by the initiator MUST include the ICE-CONTROLLING attribute.</li>
<li>The STUN Binding Requests generated by the responder MUST include the ICE-CONTROLLED attribute.</li>
<li>The parties MUST use STUN short term credentials to authenticate requests and perform message integrity checks.</li>
<li>The parties MUST use STUN short term credentials to authenticate requests and perform message integrity checks. As in &icecore;, the username in the STUN Binding Request is of the form "ufrag-of-sender:ufrag-of-peer" and the password is the value of the 'pwd' attribute provided by the peer. <note>Thus when Romeo sends a STUN Binding Request to Juliet the credentials will be STUN username "8hhy:9uB6" and password "YH75Fviy6338Vbrhrlp8Yh" whereas when Juliet sends a STUN Binding Request to Romeo the credentials will be STUN username "9uB6:8hhy" and password "asd88fgpdd777uzjYhagZg".</note></li>
</ol>
<p>When it receives a STUN Binding Request, each party MUST return a STUN Binding Response, which may indicate either an error case or the success case. As described in Section 7.1.2.2 of &icecore;, a connectivity check succeeds if the STUN transaction generated a success response, the source IP address and port of the response equals the destination IP address and port that the Binding Request was sent to, and the destination IP address and port of the response match the source IP address and port that the Binding Request was sent from.</p>
<p>For the candidates exchanged in the previous section, the connectivity checks would be as follows. In particular, the parties send one STUN Binding Request from each of their local candidates to each of the remote candidates.</p>
@ -522,7 +528,7 @@ INITIATOR NAT RESPONDER
<li>The responder sends a Jingle content-accept or session-accept action to the initiator.</li>
<li>The initiator acknowledges receipt of the content-accept.</li>
</ol>
<p>First the initiator sends a Jingle content-modify action to the responder. The content-modify 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).</p>
<p>First the initiator sends a Jingle content-modify action to the responder. The content-modify 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-modify"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='mod1'
@ -883,8 +889,10 @@ INITIATOR NAT RESPONDER
<xs:attribute name='priority' type='xs:positiveInteger' use='required'/>
<xs:attribute name='protocol' type='xs:NCName' use='required'/>
<xs:attribute name='pwd' type='xs:string' use='required'/>
<xs:attribute name='raddr' type='xs:string' use='optional'/>
<xs:attribute name='rport' type='xs:unsignedShort' use='optional'/>
<xs:attribute name='rel-addr' type='xs:string' use='optional'/>
<xs:attribute name='rel-port' type='xs:unsignedShort' use='optional'/>
<xs:attribute name='rem-addr' type='xs:string' use='optional'/>
<xs:attribute name='rem-port' type='xs:unsignedShort' use='optional'/>
<xs:attribute name='type' use='required'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
@ -910,4 +918,7 @@ INITIATOR NAT RESPONDER
</xs:schema>
]]></code>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Steffen Larsen for his helpful feedback.</p>
</section1>
</xep>