In order for the initiator 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 initiator wishes to negotiate the Raw UDP transport for a given content type, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:raw-udp:0' namespace &VNOTE;, which MUST This is required to avoid a round trip and help expedite the negotiation. include the initiator's Raw UDP candidate via the 'ip', 'port', 'generation', and 'id' attributes of the &CANDIDATE; element.

The 'generation', 'ip', and 'port' attributes are REQUIRED. The 'ip' and 'port' attributes are self-explanatory. 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).

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 "default" candidate as described in &ice;. This is not necessarily the entity'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 sender needs to classify ahead of time the permissiveness of the NAT or firewall it is behind, if any. It then SHOULD assign the Raw UDP candidate as follows, where the candidate types are as described in ICE:

As described in XEP-0166, to acknowledge the session initiation request, the responder returns an IQ-result:

Once the responder acknowledges the session initiation request, it:

1. MUST attempt to send media data via UDP to the IP and port specified in the initiator's Raw UDP candidate.
2. MUST send an informational message of <trying/>.
3. SHOULD send its own Raw UDP candidate to the initiator via a Jingle "transport-info" message.

These are done simultaneously in order to ensure that a connection can be made, since the initiator's Raw UDP candidate might not result in success.

Informational messages are sent within the context of the Raw UDP transport to communicate whether the party has attempted to send media or has received media. The informational message MUST be an IQ-set containing a &JINGLE; element of type "session-info", where the informational message is a payload element qualified by the 'urn:xmpp:jingle:transports:raw-udp:info:0' namespace &VNOTE;. The following payload elements are defined:

Note: Because the informational message is sent in an IQ-set, the receiving party MUST return either an IQ-result or an IQ-error (normally only an IQ-result to acknowledge receipt; no error flows are defined or envisioned at this time).

This specification defines the following XML namespaces:

• urn:xmpp:jingle:transports:raw-udp:0
• urn:xmpp:jingle:transports:raw-udp:info:0

Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespaces to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

The XMPP Registrar shall include "raw-udp" in its registry of Jingle transport methods. The registry submission is as follows: