From a78c77eaa18c7d6b38fed133bdba38c750564c29 Mon Sep 17 00:00:00 2001 From: stpeter Date: Tue, 21 Jun 2011 12:19:59 -0600 Subject: [PATCH] 0.2 --- xep-0278.xml | 58 +++++++++++++++++++++++++++++++++------------------- 1 file changed, 37 insertions(+), 21 deletions(-) diff --git a/xep-0278.xml b/xep-0278.xml index 536996f0..cdfcdfe7 100755 --- a/xep-0278.xml +++ b/xep-0278.xml @@ -25,8 +25,19 @@ - TO BE ASSIGNED - &thiago; + jinglenodes + + Thiago + Camargo + thiago@xmppjingle.com + barata7@gmail.com + + + 0.2 + 2010-06-21 + tc +

Added STUN Service Tracking Support. Removed Public IP requirement for Relay Service.

 + 0.1 2010-03-05 @@ -36,18 +47,12 @@ 0.0.1 2009-12-17 - psa - -

First draft.

- + tc +

First draft.

 -

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

+

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.

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'> - + + ]]> 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. @@ -156,7 +162,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring 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. -

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

+

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

Note: It is NOT mandatory to became a Jingle Relay Node it is OPTIONAL and SHOULD be done ONLY under user awareness and concentiment.

@@ -168,7 +174,6 @@ All signalling, request, response and publishing is done via XMPP, not requiring ]]> -

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.

]]> +

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.

 @@ -298,7 +304,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring address - The IP address or Host address of the Relay Channel. + For Relay and Tracker Services the JID. For STUN Service the IP or Host address. REQUIRED @@ -306,12 +312,17 @@ All signalling, request, response and publishing is done via XMPP, not requiring The protocol supported by the retrieved service. REQUIRED + + port + The port number of the STUN service. This field is only used in STUN Service entries. + REQUIRED for STUN entries + -

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

-

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

+

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

+

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

For optimization purpose the Client SHOULD check for Jingle Nodes support based on entity presence capabilities &xep0115;, which SHOULD contain the keywork "jn-v0".

]]> -

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 XEP-0115. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

+

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.

 @@ -399,11 +410,11 @@ All signalling, request, response and publishing is done via XMPP, not requiring - + - + @@ -422,6 +433,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring type='serviceElementType' minOccurs='0' maxOccurs='unbounded'/> + @@ -430,6 +445,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring + @@ -442,7 +458,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring - +