Recommended sending of candidate in initiation request to save a round trip and expedite the negotiation; removed name attribute; clarified flow of negotiation; modified spec to use provisional namespace before advancement to Draft (per XEP-0053).
Added informational messages; clarified connectivity checks and acceptance process; mentioned that the Raw UDP candidate is conceptually equivalent to the concept of an in-use candidate from the ICE specification; added reference to RFC 4347.
Removed candidate element and specified exchange of address information via transport-info messages; clarified usage of name attribute.
Initial version (split from XEP-0166).
The Jingle transport method defined herein is designed to meet the following requirements:
Note: The Raw UDP transport does not provide traversal of Network Address Translators (NATs) and is provided only for the purpose of specifying the IP address and port that an entity considers most likely to succeed without the need for NAT traversal. If NAT traversal is needed, &xep0176; SHOULD be used.
In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in XEP-0166. This stanza MUST include at least one transport methods. If the initiating entity wishes to negotiate the Raw UDP transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/raw-udp' namespace.
+In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in XEP-0166. This stanza MUST include at least one content type. If the initiating entity wishes to negotiate the Raw UDP transport for a given content type, it MUST include a &TRANSPORT; child element qualified by the 'http://www.xmpp.org/extensions/xep-0177.html#ns' namespace (see Protocol Namespaces), which MUST
As described in XEP-0166, to provisionally accept the session initiation request, the receiver returns an IQ-result:
-Once the session is provisionally accepted, each entity SHOULD send one &TRANSPORT; element in a transport-info meessage, containing exactly one &CANDIDATE; element per content type, whose 'ip' and 'port' attributes specify the IP address and port number of the candidate that the initiator has reason to believe will be most likely to succeed for that content type. This is not necessarily the initiator's preferred address for communication, but instead is the "address most likely to succeed", i.e., the address that is assumed to be reachable by the vast majority of target entities. To determine reachability, the client needs classify ahead of time the permissiveness of the NAT or firewall it is behind, if any. If the NAT is symmetric (not permissive), the candidate SHOULD specify a relay address. Otherwise it SHOULD be an address derived via prior discovery using &rfc3489;, which will be an address on the outside of the firewall or NAT.
-Note: The Raw UDP candidate is equivalent to the "in-use" candidate as described in &ice;. (In older versions of XEP-0166, this was referrred to as the "default candidate".)
-The 'generation', 'ip', 'name', and 'port' attributes are REQUIRED. The 'name' attribute specifies the name of the content type and the 'generation' attribute provides a tracking mechanism for determining which version of this candidate is in force (this is useful if the candidate is redefined mid-stream, for example if the port is changed).
-Either entity may send this "transport-info" action at any time, after which the recipient should attempt to send media data to the specified address (either entity MAY also send the Informational Messages described below). If media data can be delivered for the candidate, the recipient MUST send a Jingle "transport-accept" action to the initiator (either explicitly, or implicitly via a "content-accept" or "session-accept" action.
-Note: The "Raw UDP candidate" is the candidate that the entity has reason to believe will be most likely to succeed for that content type, and thus is equivalent to the "in-use" candidate as described in &ice;.
| NAT Type | +Recommended Raw UDP Candidate Type | +
|---|---|
| None | +Host candidate | +
| Symmetric (not permissive) | +Relay candidate | +
| Permissive | +Server reflexive or peer reflexive candidate discovered via &rfc3489; | +
As described in XEP-0166, to provisionally accept the session initiation request, the receiver returns an IQ-result:
+Once the receiving entity provisionally accepts the session, it:
+These are done simultaneously in order to ensure that a connection can be made, since the initiating entity's Raw UDP candidate may not result in success.
+The receiving entity MUST immediately attempt to send media data to the IP and port specified in the initiation request. If media data can be delivered, the recipient MUST send a Jingle "transport-accept" action to the initiator (either explicitly, or implicitly via a "content-accept" or "session-accept" action.
+The initiator MUST then acknowledge acceptance by returning an IQ result (or return a standard XMPP error).
+ ]]> +The initiating entity MUST then acknowledge acceptance by returning an IQ result (or return a standard XMPP error).
+While checking the initiating entity's Raw UDP candidate, the receiving entity SHOULD its own Raw UDP candidate to the initiating entity by sending a transport-info message to the initiating entity, as shown in the following example.
+The initiating entity MUST then acknowledge receipt by returning an IQ result (or return a standard XMPP error).
+Naturally, the intiating entity then MUST also check the receiving entity's Raw UDP candidate by following the checking procedure outlined above.
+While checking the initiating entity's Raw UDP candidate, the receiving entity MAY send an informational message to communicate the status of transport checking. The informational message MUST be an IQ-set containing a &JINGLE; element of type "transport-info", where the informational message is a payload element specified in the Informational Messages section of this document.
+Informational messages may be sent by the receiver within the context of the Raw UDP transport to communicate the status of transport checking. The informational message MUST be an IQ-set containing a &JINGLE; element of type "transport-info", where the informational message is a payload element qualified by the 'http://jabber.org/protocol/jingle/info/raw-udp' namespace; the following payload elements are defined:
+Informational messages MAY be sent by the receiver within the context of the Raw UDP transport to communicate the status of transport checking. The informational message MUST be an IQ-set containing a &JINGLE; element of type "transport-info", where the informational message is a payload element qualified by the 'http://www.xmpp.org/extensions/xep-0177.html#ns-info' namespace (see Protocol Namespaces). The following payload elements are defined:
| Element | @@ -151,12 +197,11 @@
|---|