Added TURN Credentials Service Support.
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.
+A Jingle Client can request volative TURN credentials, to be used in cases where connectivity check is a requirement. Like, for example, WebRTC. The concept and mechanism is quite similar to the RFC draft REST API For Access To TURN Services'.
+TURN provides an access control mechanism described in &rfc5389;, where long-term credentials are provided as part of the TURN protocol. Therefore the credentials provided in this Jingle Nodes mechanism are time-limited, but SHOULD be used as long-term credentials, when authentication against a TURN Server. +
++ Note: There is no need to run TURN server or support within a Jingle Relay. This mechanism allows decoupled deployment of distributed TURN Servers, without the requirement of database based authentication. +
+The &SERVICES; element MAY be empty or contain &RELAY; and/or &TRACKER; elements.
+The &SERVICES; element MAY be empty or contain &RELAY;, &STUN; and/or &TRACKER; elements.
The attributes of the &RELAY; and &TRACKER; element are as follows.
The attributes of the &TURN; element are as follows.
+| Attribute | +Definition | +Inclusion | +
|---|---|---|
| ttl | +The duration in seconds for which the provided credentials are valid. | +REQUIRED | +
| uri | +The TURN Server URI. | +REQUIRED | +
| username | +The username to be used on TURN authentication. THe recommended format is a colon-delimited concatenation of expiration timestamp and the requester bare JID. | +REQUIRED | +
| password | +The ppassword to be used on TURN authentication. Is the result of 'base64(hmac(secret_key, username))'. Where 'secret_key' is shared between the TURN server and entity providing the credentials. | +REQUIRED | +
The duration in seconds for which the provided credentials are valid. The usual and recommended value is 86400 seconds (one day).
+The TURN Server URI as described in I-D.petithuguenin-behave-turn-uris
+WebRTC's TURN request uses the 'username' value for its USERNAME and PASSWORD attributes, for the input to the MESSAGE-INTEGRITY hash.
+Along with 'username', WebRTC's TURN request uses the 'password' value for its USERNAME and PASSWORD attributes, for the input to the MESSAGE-INTEGRITY hash.
+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;.
@@ -342,8 +421,9 @@ All signalling, request, response and publishing is done via XMPP, not requiring to='romeo@montague.lit/orchard' type='result'>A Jingle Client that uses WebRTC, therefore requiring a TURN Server and its credentials to successfully alocate channels. This specification describes a simple way of discovering TURN Services and retrieving credentials to successfully allocate channels. + This also simplifies deployment and distribution of TURN servers, since its stateless authentication does not require connectivity to database authoriztion services.
+A Jingle Client with STUN support but no TURN support can use Relay Node Services as the fallback candidate instead of a TURN candidate. For instance, after a connectivity check proccess, none of the direct candidates worked. The Client can use the Relay Node Candidate as the fallback candidate(the lowest priority candidate).