The overall protocol flow for negotiation of the Jingle ICE-UDP Transport Method is as follows (note: many of these events happen simultaneously, not in sequence).

Note: The examples in this document follow the scenario described in Section 17 of &icecore;, except that we substitute the Shakespearean characters "Romeo" and "Juliet" for the generic entities "L" and "R".

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. A content type MUST include one transport method. If the initiator wishes to negotiate the ice-udp transport method for an application format, it MUST include an empty &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:ice-udp:0' namespace &VNOTE;.

The 'pwd' and 'ufrag' attributes MUST be included in the session-initiate request, in subsequent content-add and transport-replace actions, and when offering candidates via the transport-info action. The attributes SHOULD NOT be included in a session-accept action. The values are separately generated for both the initiator and the responder, in accordance with &icecore; and as shown in the examples. The attributes are defined as follows.

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

Once the responder acknowledges receipt of the session initiation request as shown above, both initiator and responder MUST immediately negotiate connectivity over the ICE transport by exchanging XML-formatted candidate transports for the channel. This negotiation proceeds immediately in order to maximize the possibility that media can be exchanged as quickly as possible. Concurrent with negotiation of the ICE candidates, it is possible for the initiator and responder to negotiate which content types the session will include, which transport methods will be tried for each content type, etc. Those negotiation flows are shown in other specifications, such as XEP-0166. This document specifies only negotiation of the ICE transport method.

Note: In order to expedite session establishment, the initiator MAY send transport candidates immediately after sending the "session-initiate" message and before receiving acknowledgement from the responder (i.e., the initiator MUST consider the session to be live even before receiving acknowledgement). Given in-order delivery as mandated by &xmppcore;, the responder will receive such "transport-info" messages after receiving the "session-initiate" message; if not, it is appropriate for the responder to return <unknown-session/> errors since according to its state machine the session does not exist. If either party receives an <unknown-session/> from the other party, it MUST terminate the negotiation and the session.

Note: See the Security Considerations section of this document regarding the exposure of IP addresses on behalf by the responder's client.

The candidate syntax and negotiation flow are described below.

As the initiator and responder receive candidates, they probe the various candidate transports for connectivity. In performing these connectivity checks, each party SHOULD follow the procedure specified in Section 7 of &icecore;. The following business rules apply:

1. Each party sends a STUN Binding Request (see &rfc5389;) from each local candidate it generated to each remote candidate it received.
2. In accordance with &icecore;, the STUN Binding Request MUST include the PRIORITY attribute (computed according to Section 7.1.1.1. of &icecore;).
3. For the purposes of the Jingle ICE-UDP Transport Method, both parties are full ICE implementations and therefore the controlling role MUST be assumed by the initiator and the controlled role MUST be assumed by the responder.
4. The STUN Binding Requests generated by the initiator MAY include the USE-CANDIDATE attribute to indicate that the initiator wishes to cease checks for this component.
5. The STUN Binding Requests generated by the initiator MUST include the ICE-CONTROLLING attribute.
6. The STUN Binding Requests generated by the responder MUST include the ICE-CONTROLLED attribute.
7. The parties MUST use STUN short term credentials to authenticate requests and perform message integrity checks. As in &icecore;, the username in the STUN Binding Request is of the form "ufrag-of-sender:ufrag-of-peer" and the password is the value of the 'pwd' attribute provided by the peer. Thus when Romeo sends a STUN Binding Request to Juliet the credentials will be STUN username "8hhy:9uB6" and password "YH75Fviy6338Vbrhrlp8Yh" whereas when Juliet sends a STUN Binding Request to Romeo the credentials will be STUN username "9uB6:8hhy" and password "asd88fgpdd777uzjYhagZg".

When it receives a STUN Binding Request, each party MUST return a STUN Binding Response, which indicates either an error case or the success case. As described in Section 7.1.2.2 of &icecore;, a connectivity check succeeds if all of the following are true:

1. The STUN transaction generated a success response.
2. The source IP address and port of the response equals the destination IP address and port to which the Binding Request was sent.
3. The destination IP address and port of the response match the source IP address and port from which the Binding Request was sent.

For the candidates exchanged in the previous section, the connectivity checks would be as follows. In particular, the parties send one STUN Binding Request from each of their local candidates to each of the remote candidates.

Note: Here the initiator (controlling agent) is using "aggressive nomination" as described in Section 8.1.1.2 of &icecore; and therefore includes the USE-CANDIDATE attribute in the STUN Binding Requests it sends.

If, based on STUN connectivity checks, the parties determine that they will be able to exchange media between a given pair of local candidates and remote candidates (i.e., the pair is "nominated" and ICE processing is "completed"), the parties shall proceed as follows:

1. The responder sends a Jingle session-accept action to the initiator.
2. The initiator acknowledges receipt of the session-accept.

First, the responder sends a session-accept action to the initiator, specifying the candidate that succeeded. The session-accept MUST contain information about the nominated pair, including the "rem-addr" and "rem-port" attributes (which specify the IP address and port for the responder's end of the pair, which is a "remote address" according to the initiator). This enables both parties to explicitly agree to both ends of the connection pair (i.e., the local address+port and the remote address+port).

The &JINGLE; element in the session-accept stanza SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity. If the 'responder' attribute is provided, all future commmunications SHOULD be sent to the JID provided in the 'responder' attribute.

Since according to the connectivity checks the initiator can also send data over that candidate, it acknowledges the responder's acceptance:

Now the initiator and responder can begin sending media data over the negotiated connection (in fact, they could have sent data as soon as the connectivity checks succeeded, as shown in the preceding examples).

If a candidate succeeded for the responder but the initiator cannot send data over that candidate, it MUST return a ¬acceptable; error in response to the responder's acceptance of the successful candidate:

If the responder cannot find a suitable candidate transport or it receives a ¬acceptable; error from the initiator in response to its acceptance of a suitable transport, it SHOULD terminate the session as described in Section 6.7 of XEP-0166.

The creator of a content type MAY modify an existing, in-use candidate at any time during the session, for example to change the IP address or port. This is done by sending a transport-replace action with the changed candidate information, where the value of the 'generation' attribute is incremented to specify that the candidate information is a modification to an existing candidate.

An example follows (change to IP address and port).

The recipient then acknowledges receipt.

If the transport-replace is acceptable, the recipient then sends a transport-accept action (if not, the recipient sends a transport-reject action).

The initiator then acknowledges the responder's acceptance:

The parties then use the modified candidate in subsequent communications.

Even after content acceptance or session acceptance, either party MAY continue to send additional candidates to the other party (e.g., because the user agent has become aware of a new media proxy or NIC). As above, such candidates are shared by sending a transport-info action.

The receiving party MUST acknowledge receipt of the candidate.

The parties SHOULD check the newly-offered candidate for connectivity, as described previously. If the parties determine that media can flow over the candidate, the initiating party shall send a transport-replace action to the responder.

The responder then acknowledges the replaced transport definition.

The responder then accepts the replaced transport definition.

The initiator then acknowledges content acceptance.

The parties then use the new candidate in subsequent communications.

If an entity supports the Jingle ice-udp transport, it MUST return a feature of "urn:xmpp:jingle:transports:ice-udp:0" &VNOTE; in response to &xep0030; information requests.

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.

If an entity supports the SDP offer / answer model described in RFC 3264 and therefore prefers to receive multiple candidates in a single "transport-info" action, it MUST advertise support for the "urn:ietf:rfc:3264" service discovery feature. Typically this feature will be advertised only by gateways between Jingle and SIP.

By definition, the exchange of transport candidates results in exposure of the sender's IP addresses, which comprise a form of personally identifying information. A Jingle client MUST enable a user to control which entities will be allowed to receive such information. If a human user explicitly accepts a session request, then the client SHOULD consider that action to imply approval of IP address sharing. However, waiting for a human user to explicitly accept the session request can result in delays during session setup, since it is more efficient to immediately begin sharing transport candidates. Therefore, it is RECOMMENDED for the client to immediately send transport candidates to a contact (without waiting for explicit user approval of the session request) in the following cases:

1. The user has permanently and formally authorized the contact to view the user's presence information via a presence subscription as reflected in an XMPP roster item (see &xmppim;).
2. The user has temporarily and dynamically shared presence with the contact via "directed presence" as described in RFC 3921.
3. The user has explicitly added the contact to a "whitelist" of entities who are allowed to access the user's personally-identifying information.

In order to secure the data stream that is negotiated via the Jingle ICE transport, implementations SHOULD use encryption methods appropriate to the transport method and media being exchanged (for details regarding RTP exchanges, refer to &xep0167;).

This specification defines the following XML namespace:

• urn:xmpp:jingle:transports:ice-udp: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.

If an entity supports the SDP offer / answer model described in RFC 3264 and therefore prefers to receive one "transport-info" action with multiple candidates, it MUST advertise support for the "urn:ietf:rfc:3264" feature.

The registry submission is as follows.

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