mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
0.2
This commit is contained in:
stpeter
parent
3f9b79b737
commit
a78c77eaa1
56
xep-0278.xml
56
xep-0278.xml
@ -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">
|
||||
@ -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='localport' 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: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>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user