1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
This commit is contained in:
stpeter 2011-06-21 12:19:59 -06:00
parent 3f9b79b737
commit a78c77eaa1

View File

@ -25,8 +25,19 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>TO BE ASSIGNED</shortname>
&thiago;
<shortname>jinglenodes</shortname>
<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>
<version>0.1</version>
<date>2010-03-05</date>
@ -36,18 +47,12 @@
<revision>
<version>0.0.1</version>
<date>2009-12-17</date>
<initials>psa</initials>
<remark>
<p>First draft.</p>
</remark>
<initials>tc</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic="Introduction" anchor="intro">
<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>
<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>
</section1>
<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.
@ -110,6 +115,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<services xmlns='http://jabber.org/protocol/jinglenodes'>
<relay policy='public' address='montague.lit' protocol='udp'/>
<tracker policy='public' address='capulet.lit' protocol='udp'/>
<stun policy='public' address='200.111.111.111' port='3857' protocol='udp'/>
</services>
</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>
@ -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>
</section2>
<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>
<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>
@ -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'/>
</iq>
]]></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[
<iq from='juliet@capulet.lit/balcony'
id='uw72g176'
@ -183,6 +188,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
maxkbps='120'
expire='60'/>
</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>
</section1>
<section1 topic="Services Definitions" anchor="servicesdefinition">
@ -298,7 +304,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</tr>
<tr>
<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>
</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>REQUIRED</td>
</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>
</section2>
</section1>
<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>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>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 &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>
<example caption="Service discovery information request"><![CDATA[
<iq from='romeo@montague.lit/orchard'
@ -332,7 +343,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</query>
</iq>
]]></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 topic="Recommended Use Cases" anchor="usecases">
<section2 topic="Jingle Client with RAW-UDP Transport without any NAT detection mechanism" anchor="rawudpnostun">
@ -403,7 +414,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='udp'/>
<xs:enumeration value='tpc'/>
<xs:enumeration value='tcp'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
@ -422,6 +433,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring
type='serviceElementType'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:element name='stun'
type='serviceElementType'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
@ -430,6 +445,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<xs:simpleContent>
<xs:extension base='empty'>
<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:simpleType>
<xs:restriction base='xs:NCName'>
@ -442,7 +458,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='udp'/>
<xs:enumeration value='tpc'/>
<xs:enumeration value='tcp'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>