moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

0.3 final

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@144 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-31 20:48:10 +00:00
parent e1505c92ea
commit 9bad83b40f
1 changed files with 16 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
xep-0177.xml
View File

@ -66,8 +66,10 @@
action='session-initiate'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<description ...>
<transport xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'/>
<content name='this-is-the-audio-content'>
<description ...>
<transport xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'/>
</content>
</jingle>
</iq>
]]></example>
@ -79,7 +81,7 @@
]]></example>
</section2>
<section2 topic='Exchanging Address Information' anchor='protocol-addresses'>
<p>Once the session is provisionally accepted, each entity SHOULD send one &TRANSPORT; element in a transport-info meessage, containing exactly one &CANDIDATE; element per channel, whose 'ip' and 'port' attributes specify the IP address and port number of the candidate that the initiator has reason to believe will be most likely to succeed for that channel. This is not necessarily the initiator'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 client needs classify ahead of time the permissiveness of the NAT or firewall it is behind, if any. If the NAT is symmetric (not permissive), the candidate SHOULD specify a relay address. Otherwise it SHOULD be an address derived via prior discovery using &rfc3489;, which will be an address on the outside of the firewall or NAT.</p>
<p>Once the session is provisionally accepted, each entity SHOULD send one &TRANSPORT; element in a transport-info meessage, containing exactly one &CANDIDATE; element per content type, whose 'ip' and 'port' attributes specify the IP address and port number of the candidate that the initiator has reason to believe will be most likely to succeed for that content type. This is not necessarily the initiator'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 client needs classify ahead of time the permissiveness of the NAT or firewall it is behind, if any. If the NAT is symmetric (not permissive), the candidate SHOULD specify a relay address. Otherwise it SHOULD be an address derived via prior discovery using &rfc3489;, which will be an address on the outside of the firewall or NAT.</p>
<p>Note: The Raw UDP candidate is equivalent to the "in-use" candidate as described in &ice;. (In older versions of XEP-0166, this was referrred to as the "default candidate".)</p>
<example caption="Address Exchange Example"><![CDATA[
<iq from='romeo@montague.net/orchard' to='juliet@capulet.com/balcony' id='jingle2' type='set'>
@ -87,13 +89,15 @@
action='transport-info'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<transport xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'>
<candidate name='myvoicedata' ip='10.1.1.104' port='13540' generation='0'/>
</transport>
<content name='this-is-the-audio-content'>
<transport xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'>
<candidate name='myvoicedata' ip='10.1.1.104' port='13540' generation='0'/>
</transport>
</content>
</jingle>
</iq>
]]></example>
<p>The 'generation', 'ip', 'name', and 'port' attributes are REQUIRED. The 'name' attribute specifies the name of the channel and 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>The 'generation', 'ip', 'name', and 'port' attributes are REQUIRED. The 'name' attribute specifies the name of the content type and 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>Either entity may send this "transport-info" action at any time, after which the recipient should attempt to send media data to the specified address (either entity MAY also send the <link url='#protocol-info'>Informational Messages</link> described below). If media data can be delivered for the candidate, the recipient MUST send a Jingle "transport-accept" action to the initiator (either explicitly, or implicitly via a "content-accept" or "session-accept" action.</p>
<example caption="Responder Returns Transport-Accept"><![CDATA[
<iq from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard' type='set' id='accept1'>
@ -101,9 +105,11 @@
action='transport-accept'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<transport xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'>
<candidate name='myvoicedata' ip='10.1.1.104' port='13540' generation='0'/>
</transport>
<content name='this-is-the-audio-content'>
<transport xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'>
<candidate name='myvoicedata' ip='10.1.1.104' port='13540' generation='0'/>
</transport>
</content>
</jingle>
</jingle>
</iq>