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

0.6

Browse Source
This commit is contained in:
stpeter 2011-08-26 15:15:19 -06:00
parent 63a5976565
commit fb9fb33319
1 changed files with 13 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
xep-0260.xml
View File

@ -33,6 +33,12 @@
<email>klaus.hartke@googlemail.com</email>
<jid>nx@jabber.org</jid>
</author>
<revision>
<version>0.6</version>
<date>2010-08-26</date>
<initials>psa</initials>
<remark><p>Added a 'dstaddr' attribute for feature-parity with XEP-0065.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2010-04-13</date>
@ -129,6 +135,8 @@ Initiator Responder
</section2>
<section2 topic='Exchanging Candidates' anchor='exchange'>
<p>Once the initiator has a set of candidates, it sends a Jingle session-initiate request that contains one or more transport candidates which are a mixture of <cite>XEP-0065</cite> streamhosts and ICE candidates used in <cite>XEP-0176</cite>.</p>
<p>Just as with the &QUERY; element from <cite>XEP-0065</cite>, here the &lt;transport/&gt; element that contains the candidates MUST possess a 'sid' attribute that specifies the Stream ID for this bytestream. The &lt;transport/&gt; element MAY possess a 'mode' attribute whose value is "tcp" (the default) or "udp" (for the latter, see Section 8 of <cite>XEP-0065</cite>). The &lt;transport/&gt; element MAY also possess a 'dstaddr' attribute whose value is the initiator's calculated hash value for the SOCKS5 DST.ADDR field (see Section 7 of <cite>XEP-0065</cite>).</p>
<p>Note: As explained in Section 5.3.2 of <cite>XEP-0065</cite>, the DST.ADDR value in the SOCKS5 negotiation is the SHA1 hash of (SID + Requester JID + Target JID). In the context of Jingle SOCKS5 Bytestreams, the "Requester JID" is the XMPP address of the initiator and the "Target JID" is the XMPP address of the responder (in the examples used here, the values are "romeo@montague.lit/orchard" and "juliet@capulet.lit/balcony" respectively).</p>
<example caption="Initiator sends session-initiate"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='xn28s7gk'
@ -177,7 +185,7 @@ Initiator Responder
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-accept'
initiator='romeo@montague.lit/orchard'
responder='juliet@capulet.lit/balcony'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='ex'>
<description xmlns='urn:xmpp:example'/>
@ -249,7 +257,8 @@ priority = (2^16)*(type preference) + (local preference)
<p>The local preference is used to rate different candidates of the same type, e.g. a DSL link might be preferred over a VPN connection. The value of the local preference SHOULD be between 0 and 65535. The proposed values are only guidelines. If a client wants to increase or decrease the value of a specific candidate it is free to do so. For instance, a client might have an expensive UMTS link as a last resort and might rate this link lower than all SOCKS5 relays.</p>
</section2>
<section2 topic='Connecting to Candidates' anchor='connect'>
<p>After receiving its peer's candidates, a client start to connect to them in order of the priority. The protocol is described in <cite>XEP-0065</cite> in detail. Once one client has successfully created a connection, it sends the &lt;candidate-used/&gt; element to the peer inside a Jingle transport-info message. If a client receives a candidate-used notification it SHOULD continue trying to connect to candidates sent by its peer if it has not tried all candidates with a higher priority than the one successfully used by the peer.</p>
<p>After receiving its peer's candidates, a client start to connect to them in order of the priority. A detailed description of the protocol can be found in <cite>XEP-0065</cite>.</p>
<p>Once one client has successfully created a connection, it sends the &lt;candidate-used/&gt; element to the peer inside a Jingle transport-info message. If a client receives a candidate-used notification it SHOULD continue trying to connect to candidates sent by its peer if it has not tried all candidates with a higher priority than the one successfully used by the peer.</p>
<example caption="Initiator sends candidate-used in Jingle transport-info"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='hjdi8'
@ -554,8 +563,8 @@ Romeo Juliet
<xs:element name='proxy-error'
minOccurs='0' maxOccurs='1' type='empty'/>
</xs:choice>
<xs:attribute name='dstaddr' use='optional' type='xs:string'/>
<xs:attribute name='mode' use='optional' default='tcp'>
<xs:attribute name='sid' type='xs:string' use='optional'/>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='tcp'/>
@ -563,6 +572,7 @@ Romeo Juliet
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name='sid' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>