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

0.11 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2296 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-10-01 01:55:22 +00:00
parent a47790b21a
commit 155e70810f
1 changed files with 65 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

90
xep-0177.xml
View File

@ -26,6 +26,12 @@
&scottlu;
&hildjj;
&seanegan;
<revision>
<version>0.11</version>
<date>2008-09-30</date>
<initials>psa</initials>
<remark><p>Clarified protocol flow.</p></remark>
</revision>
<revision>
<version>0.10</version>
<date>2008-09-25</date>
@ -116,6 +122,35 @@
</ol>
</section1>
<section1 topic='Protocol Description' anchor='protocol'>
<section2 topic='Flow' anchor='protocol-flow'>
<p>The overall protocol flow for negotiation of the Jingle Raw UDP Transport Method is as follows (note: many of these events happen simultaneously, not in sequence).</p>
<code><![CDATA[
INITIATOR RESPONDER
| |
| session-initiate (w/ candidate) |
|----------------------------------->|
| ack |
|<-----------------------------------|
| session-info: trying |
|<-----------------------------------|
| ack |
|----------------------------------->|
| transport-info: candidate |
|<-----------------------------------|
| ack |
|----------------------------------->|
| session-info: received |
|----------------------------------->|
| ack |
|<-----------------------------------|
| session-accept |
|<-----------------------------------|
| ack |
|----------------------------------->|
|<========MEDIA NOW FLOWS===========>|
| |
]]></code>
</section2>
<section2 topic='Transport Initiation' anchor='initiate'>
<p>In order for the initiator in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in <cite>XEP-0166</cite>. This stanza MUST include at least one content type. If the initiator wishes to negotiate the Raw UDP transport for a given content type, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:raw-udp:0' namespace &VNOTE;, which MUST <note>This is required to avoid a round trip and help expedite the negotiation.</note> include the initiator's Raw UDP candidate via the 'ip', 'port', 'generation', and 'id' attributes of the &CANDIDATE; element.</p>
<example caption="Initiation"><![CDATA[
@ -141,7 +176,7 @@
</jingle>
</iq>
]]></example>
<p>The 'generation', 'ip', and 'port' attributes are REQUIRED. The 'ip' and 'port' attributes are self-explanatory. The 'generation' attribute provides a tracking mechanism for determining which version of this candidate is in force (this is useful if the candidate is redefined mid-stream, for example if the port is changed).</p>
<p>All attributes are REQUIRED. The 'ip' and 'port' attributes are self-explanatory. The 'generation' attribute provides a tracking mechanism for determining which version of this candidate is in force (this is useful if the candidate is redefined mid-stream, for example if the port is changed). The 'id' attribute uniquely identifies this candidate for tracking purposes.</p>
<p>Note: The "Raw UDP candidate" is the candidate that the entity has reason to believe will be most likely to succeed for that content type, and thus is equivalent to the "default" candidate as described in &ice;. This is not necessarily the entity's preferred address for communication, but instead is the "address most likely to succeed", i.e., the address that is assumed to be reachable by the vast majority of target entities. To determine reachability, the sender needs to classify ahead of time the permissiveness of the NAT or firewall it is behind, if any. It then SHOULD assign the Raw UDP candidate as follows, where the candidate types are as described in <cite>ICE</cite>:</p>
<table caption='Raw UDP Candidate Assignment'>
<tr>
@ -178,9 +213,9 @@
</ol>
<p>These are done simultaneously in order to ensure that a connection can be made, since the initiator's Raw UDP candidate might not result in success.</p>
<section3 topic='Sending Media' anchor='response-send'>
<p>The responder MUST immediately attempt to send data to the IP and port specified in the initiation request. If all goes well, the data will be received by the initiator and media will flow. Because delivery of UDP data is not acknowledged, a party that receives media MUST send an informational message of &lt;received/&gt; to the other party as specified below.</p>
<p>The responder MUST immediately attempt to send data to the IP and port specified in the initiation request. If all goes well, the data will be received by the initiator and media will flow.</p>
</section3>
<section3 topic='Sending an Informational Message' anchor='response-info'>
<section3 topic='Sending a Trying Message' anchor='response-trying'>
<p>When it attempts to send data to a Raw UDP candidate, a party MUST send an informational message of &lt;trying/&gt;, including the candidate ID for tracking purposes.</p>
<example caption="Responder sends trying message"><![CDATA[
<iq from='juliet@capulet.com/balcony'
@ -200,31 +235,10 @@
<iq from='romeo@montague.lit/orchard'
id='trying1'
to='juliet@capulet.lit/balcony'
type='result'/>
]]></example>
<p>If a party receives data, it MUST send an informational message of &lt;received/&gt;, including the candidate ID for tracking purposes.</p>
<example caption="Initiator sends received message"><![CDATA[
<iq from='romeo@montague.net/orchard'
id='received1'
to='juliet@capulet.com/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:0'
action='session-info'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<received xmlns='urn:xmpp:jingle:transports:raw-udp:info:0'
id='a9j3mnbtu1'/>
</jingle>
</iq>
]]></example>
<example caption="Responder acknowledges received message"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='received1'
to='romeo@montague.lit/orchard'
type='result'/>
]]></example>
</section3>
<section3 topic='Sending A Candidate' anchor='response-candidate'>
<section3 topic='Sending a Candidate' anchor='response-candidate'>
<p>As noted, the responder SHOULD send its own Raw UDP candidate to the initiator by sending a transport-info message to the initiator, as shown in the following example.</p>
<example caption="Responder sends its Raw UDP candidate"><![CDATA[
<iq from='juliet@capulet.com/balcony'
@ -255,6 +269,29 @@
]]></example>
<p>Naturally, the initiator SHOULD also attempt to send media to the responder as specified above. This media, too, might or might not get through, but if it does then the other party MUST acknowledge success by sending a &lt;received/&gt; message.</p>
</section3>
<section3 topic='Sending a Received Message' anchor='response-received'>
<p>Because delivery of UDP data is not acknowledged (as is TCP data), a party that receives media MUST send an informational message of &lt;received/&gt;, including the candidate ID for tracking purposes.</p>
<example caption="Initiator sends received message"><![CDATA[
<iq from='romeo@montague.net/orchard'
id='received1'
to='juliet@capulet.com/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:0'
action='session-info'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<received xmlns='urn:xmpp:jingle:transports:raw-udp:info:0'
id='a9j3mnbtu1'/>
</jingle>
</iq>
]]></example>
<example caption="Responder acknowledges received message"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='received1'
to='romeo@montague.lit/orchard'
type='result'/>
]]></example>
</section3>
</section2>
<section2 topic='Informational Messages' anchor='protocol-info'>
@ -403,4 +440,7 @@
]]></code>
</section2>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Steffen Larsen, Robert McQueen, and Mike Ruprecht for their feedback.</p>
</section1>
</xep>