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.2

Browse Source
This commit is contained in:
stpeter 2011-06-21 12:19:59 -06:00
parent 3f9b79b737
commit a78c77eaa1
1 changed files with 37 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
xep-0278.xml
View File

@ -25,8 +25,19 @@
</dependencies> </dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
<shortname>TO BE ASSIGNED</shortname> <shortname>jinglenodes</shortname>
&thiago; <author>
<firstname>Thiago</firstname>
<surname>Camargo</surname>
<email>thiago@xmppjingle.com</email>
<jid>barata7@gmail.com</jid>
</author>
<revision>
<version>0.2</version>
<date>2010-06-21</date>
<initials>tc</initials>
<remark><p>Added STUN Service Tracking Support. Removed Public IP requirement for Relay Service.</p></remark>
</revision>
<revision> <revision>
<version>0.1</version> <version>0.1</version>
<date>2010-03-05</date> <date>2010-03-05</date>
@ -36,18 +47,12 @@
<revision> <revision>
<version>0.0.1</version> <version>0.0.1</version>
<date>2009-12-17</date> <date>2009-12-17</date>
<initials>psa</initials> <initials>tc</initials>
<remark> <remark><p>First draft.</p></remark>
<p>First draft.</p>
</remark>
</revision> </revision>
</header> </header>
<section1 topic="Introduction" anchor="intro"> <section1 topic="Introduction" anchor="intro">
<p> <p>Jingle Nodes is an XMPP Based Relay Service providing standard UDP/TCP Relay, but negotiated via XMPP. Jingle Relay Nodes are intend to provide easy to use Jingle Relay Type Candidates that can be used in ICE-UDP, RAW-UDP, TCP Jingle Sessions. Relay Candidates can provide NAT Traversal for Jingle users with or without STUN/TURN Support. The main benefits of Jingle Relay Nodes is the easy to use candidates, Jingle Clients can became a Node and Jingle Relay Nodes are published via XMPP, meaning every Client or Server can also act as a tracker of another Nodes and STUN Servers.</p>
Jingle Nodes is an XMPP Based Relay Service providing standard UDP/TCP Relay, but negotiated via XMPP.
Jingle Relay Nodes are intend to provide easy to use Jingle Relay Type Candidates that can be used in ICE-UDP, RAW-UDP, TCP Jingle Sessions.
Relay Candidates can provide NAT Traversal for Jingle users with or without STUN/TURN Support.
The main benefits of Jingle Relay Nodes is the easy to use candidates, Jingle Clients can became a Node and Jingle Relay Nodes are published via XMPP, meaning every Client or Server can also act as a tracker of another Nodes.</p>
</section1> </section1>
<section1 topic="Requirements" anchor="reqs"> <section1 topic="Requirements" anchor="reqs">
<p>Jingle Relay Nodes MUST be binded directly to a Public IP address without firewall for traffic on the port range reserved to be used by relay candidates. This is the main and unique requirement for a peer provide Relay Nodes Service. <p>Jingle Relay Nodes MUST be binded directly to a Public IP address without firewall for traffic on the port range reserved to be used by relay candidates. This is the main and unique requirement for a peer provide Relay Nodes Service.
@ -109,7 +114,8 @@ All signalling, request, response and publishing is done via XMPP, not requiring
type='result'> type='result'>
<services xmlns='http://jabber.org/protocol/jinglenodes'> <services xmlns='http://jabber.org/protocol/jinglenodes'>
<relay policy='public' address='montague.lit' protocol='udp'/> <relay policy='public' address='montague.lit' protocol='udp'/>
<tracker policy='public' address='capulet.lit' protocol='udp'/> <tracker policy='public' address='capulet.lit' protocol='udp'/>
<stun policy='public' address='200.111.111.111' port='3857' protocol='udp'/>
</services> </services>
</iq> ]]></example> </iq> ]]></example>
<em>In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.</em> <em>In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.</em>
@ -156,7 +162,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<em>In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.</em> <em>In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.</em>
</section2> </section2>
<section2 topic="Jingle Client Consuming the Relay Service" anchor="clientconsumingrelay"> <section2 topic="Jingle Client Consuming the Relay Service" anchor="clientconsumingrelay">
<p>A Jingle Client with direct access to a public IP can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...</p> <p>A Jingle Client with Internet connectivity wheter with direct access to a public IP or not, can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...</p>
<p> <p>
<em>Note: It is NOT mandatory to became a Jingle Relay Node it is OPTIONAL and SHOULD be done ONLY under user awareness and concentiment.</em> <em>Note: It is NOT mandatory to became a Jingle Relay Node it is OPTIONAL and SHOULD be done ONLY under user awareness and concentiment.</em>
</p> </p>
@ -168,7 +174,6 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<channel xmlns='http://jabber.org/protocol/jinglenodes#channel' protocol='udp'/> <channel xmlns='http://jabber.org/protocol/jinglenodes#channel' protocol='udp'/>
</iq> </iq>
]]></example> ]]></example>
<p>After receiving the &CHANNEL; the requester MUST send his stream to 'host' and 'localport' pair and send a &CANDIDATE; containing the 'host' and 'remoteport' values.</p>
<example caption="Candidate Returned by a Node with channel bandwidth throttle"><![CDATA[ <example caption="Candidate Returned by a Node with channel bandwidth throttle"><![CDATA[
<iq from='juliet@capulet.lit/balcony' <iq from='juliet@capulet.lit/balcony'
id='uw72g176' id='uw72g176'
@ -183,6 +188,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
maxkbps='120' maxkbps='120'
expire='60'/> expire='60'/>
</iq> ]]></example> </iq> ]]></example>
<em><p>After receiving the &CHANNEL; the requester MUST send his stream to 'host' and 'localport' pair and send a &CANDIDATE; containing the 'host' and 'remoteport' values.</p></em>
</section2> </section2>
</section1> </section1>
<section1 topic="Services Definitions" anchor="servicesdefinition"> <section1 topic="Services Definitions" anchor="servicesdefinition">
@ -298,7 +304,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</tr> </tr>
<tr> <tr>
<td>address</td> <td>address</td>
<td>The IP address or Host address of the Relay Channel.</td> <td>For Relay and Tracker Services the JID. For STUN Service the IP or Host address.</td>
<td>REQUIRED</td> <td>REQUIRED</td>
</tr> </tr>
<tr> <tr>
@ -306,12 +312,17 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<td>The protocol supported by the retrieved service.</td> <td>The protocol supported by the retrieved service.</td>
<td>REQUIRED</td> <td>REQUIRED</td>
</tr> </tr>
<tr>
<td>port</td>
<td>The port number of the STUN service. This field is only used in STUN Service entries.</td>
<td>REQUIRED for STUN entries</td>
</tr>
</table> </table>
</section2> </section2>
</section1> </section1>
<section1 topic="Determining Support" anchor="support"> <section1 topic="Determining Support" anchor="support">
<p>To advertise its support for the Jingle Nodes support, when replying to &xep0030; information requests an entity MUST return URNs for any version of this protocol that the entity supports -- e.g., "http://jabber.org/protocol/jinglenodes" for this version &VNOTE;.</p> <p>To advertise its support for the Jingle Nodes support, when replying to &xep0030; information requests an entity MUST return URNs for any version of this protocol that the entity supports -- e.g., "http://jabber.org/protocol/jinglenodes" for this version&VNOTE;.</p>
<p>If the entity supports Jingle Nodes as a Tracker, it MUST reply to a service discovery request with with "http://jabber.org/protocol/jinglenodes". If it also provides the Jingle Nodes Relay Services, it MUST reply with the URN "http://jabber.org/protocol/jinglenodes#channel".</p> <p>If the entity supports, Jingle Nodes as a Tracker, it MUST reply to &xep0030; with "http://jabber.org/protocol/jinglenodes". If it also provides the Jingle Nodes Relay Services, it MUST reply with the URN "http://jabber.org/protocol/jinglenodes#channel".</p>
<p>For optimization purpose the Client SHOULD check for Jingle Nodes support based on entity presence capabilities &xep0115;, which SHOULD contain the keywork "jn-v0".</p> <p>For optimization purpose the Client SHOULD check for Jingle Nodes support based on entity presence capabilities &xep0115;, which SHOULD contain the keywork "jn-v0".</p>
<example caption="Service discovery information request"><![CDATA[ <example caption="Service discovery information request"><![CDATA[
<iq from='romeo@montague.lit/orchard' <iq from='romeo@montague.lit/orchard'
@ -332,7 +343,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in <cite>XEP-0115</cite>. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p> <p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
</section1> </section1>
<section1 topic="Recommended Use Cases" anchor="usecases"> <section1 topic="Recommended Use Cases" anchor="usecases">
<section2 topic="Jingle Client with RAW-UDP Transport without any NAT detection mechanism" anchor="rawudpnostun"> <section2 topic="Jingle Client with RAW-UDP Transport without any NAT detection mechanism" anchor="rawudpnostun">
@ -399,11 +410,11 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<xs:attribute name='host' type='xs:string' use='required'/> <xs:attribute name='host' type='xs:string' use='required'/>
<xs:attribute name='localport' type='xs:string' use='required'/> <xs:attribute name='localport' type='xs:string' use='required'/>
<xs:attribute name='remoteport' type='xs:string' use='required'/> <xs:attribute name='remoteport' type='xs:string' use='required'/>
<xs:attribute name='protocol' use='required'> <xs:attribute name='protocol' use='required'>
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
<xs:enumeration value='udp'/> <xs:enumeration value='udp'/>
<xs:enumeration value='tpc'/> <xs:enumeration value='tcp'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
@ -422,6 +433,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring
type='serviceElementType' type='serviceElementType'
minOccurs='0' minOccurs='0'
maxOccurs='unbounded'/> maxOccurs='unbounded'/>
<xs:element name='stun'
type='serviceElementType'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
@ -430,6 +445,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<xs:simpleContent> <xs:simpleContent>
<xs:extension base='empty'> <xs:extension base='empty'>
<xs:attribute name='address' type='xs:string' use='required'/> <xs:attribute name='address' type='xs:string' use='required'/>
<xs:attribute name='port' type='xs:string' use='optional'/>
<xs:attribute name='policy' use='required'> <xs:attribute name='policy' use='required'>
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
@ -442,7 +458,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
<xs:enumeration value='udp'/> <xs:enumeration value='udp'/>
<xs:enumeration value='tpc'/> <xs:enumeration value='tcp'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>