Allowed batching of multiple candidates in a single transport-info action for optional interworking with the SDP offer-answer model, and added urn:ietf:rfc:3264 service discovery feature to advertise such support; updated security considerations regarding sharing of IP addresses.
The process for ICE negotiation is largely the same in Jingle as it is in ICE. There are several differences:
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.
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, the responder should 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.
The following is an example of the candidate format:
@@ -371,9 +378,11 @@ INITIATOR RESPONDERThe first step in negotiating connectivity is for each party to immediately begin sending transport candidates to the other party.
If the responder receives and can successfully process a given candidate, it returns an IQ-result (if not, for example because the candidate data is improperly formatted, it returns an error). Note: The responder is only indicating receipt of the candidate, not telling the initiator that the candidate will be used.
-The initiator keeps sending candidates, one after the other (without stopping to receive an acknowledgement of receipt from the responder for each candidate) until it has exhausted its supply of possible or desirable candidate transports. (Because certain candidates may be more "expensive" in terms of bandwidth or processing power, the initiator may not want to advertise their existence unless necessary.) For each candidate, the responder acknowledges receipt.
+The first step in negotiating connectivity is for each party to immediately begin sending transport candidates to the other party.
Each candidate or set of candidates shall be sent as <candidate/> children of a &TRANSPORT; element qualified by the 'urn:xmpp:tmp:jingle:transports:ice-udp' namespace. The &TRANSPORT; element shall be sent via a Jingle action of "transport-info" as shown in the examples below.
+Either party MAY include multiple <candidate/> elements in one &TRANSPORT; element. Sending one candidate per transport-info action typically results in a faster negotiation because the candidates most likely to succeed are sent first and it is not necessary to gather all candidates before beginning to send any candidates. Furthermore, because certain candidates may be more "expensive" in terms of bandwidth or processing power, the initiator may not want to advertise their existence unless it is necessary to do so after other candidates have failed.) However, sending multiple candidates in a single "transport-info" action can help to ensure interoperability with entities that implement the SDP offer/answer model described in RFC 3264. An entity SHOULD send one candidate per "transport-info" action and send multiple such actions, instead of sending multiple candidates in a single "transport-info" action; the only exception is if the other party advertises support for the "urn:ietf:rfc:3264" service discovery feature.
+If the responder receives and can successfully process a given candidate or set of candidates, it returns an IQ-result (if not, for example because the candidate data is improperly formatted, it returns an error). Note: The responder is only indicating receipt of the candidate or set of candidates, not telling the initiator that the candidate will be used.
+The initiator keeps sending candidates (without stopping to receive an acknowledgement of receipt from the responder for each candidate) until it has exhausted its supply of possible or desirable candidate transports. For each candidate or set of candidates, the responder acknowledges receipt.
At the same time (i.e., immediately after acknowledging receipt of the session-initiate request, not waiting for the initiator to begin or finish sending candidates), the responder also begins sending potential candidates, in order of desirability according to the responder. As above, the initiator acknowledges receipt of the candidates.
If an entity supports the Jingle ice-udp transport, it MUST return a feature of "urn:xmpp:tmp:jingle:transports:ice-udp" &NSNOTE; in response to &xep0030; information requests.
-If an entity supports the Jingle ice-udp transport, it MUST return a feature of "urn:xmpp:tmp:jingle:transports:ice-udp" &NSNOTE; in response to &xep0030; information requests.
+Naturally, support MAY also be determined via the dynamic, presence-based profile of Service Discovery defined in &xep0115;.
+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.
+Naturally, support MAY also be determined via the dynamic, presence-based profile of Service Discovery defined in &xep0115;.
+In order to speed the negotiation process so that media can flow as quickly as possible, the initiatior should gather and prioritize candidates in advance or as soon as the principal begins the process of initiating a session.
+In order to speed the negotiation process so that media can flow as quickly as possible, the initiatior should gather and prioritize candidates in advance, or as soon as the principal begins the process of initiating a session.
+The protocol-level "session-accept" action is not to be confused with an interface-level acceptance of the session request. After receiving and acknowledging the "session-initiate" action received from the initiator, the responder's client should present an interface element that enables a human user to explicitly agree to proceeding with the session (e.g., an "Accept Incoming Call?" pop-up window including "Yes" and "No" buttons). However, the responder's client should not return a "session-accept" action to the initiator until the responder has explicitly agreed to proceed with the session (unless the initiator is on a list of entities whose sessions are automatically accepted).
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 audio and video exchanges via RTP, refer to XEP-0167 and XEP-0180).
+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:
+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;).
+