Clarified ICE restarts and use of the generation attribute, in accordance with the ICE specification.
(In accordance with Jingle core, the responder will also acknowledge the transport-info message.)
In the unlikely event that one of the parties determines that it cannot establish connectivity even after sending and checking lower-priority candidates, it SHOULD terminate the session as described in 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 message 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 message (if not, the recipient sends a transport-reject message).
-The initiator then acknowledges the responder's acceptance:
-The parties then use the modified candidate in subsequent communications.
-Even after media has begun to flow, 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 network interface card). Such candidates are shared by sending a transport-info message.
The parties SHOULD check the newly-offered candidate for connectivity, as described previously. If the parties determine that media can flow over the candidate, MAY then use the new candidate in subsequent communications.
At any time, either party MAY restart the process of ICE negotiation by sending a candidate with a 'generation' value that is greater than the previous generation of candidates; when it does so, it MUST generate new values for the 'pwd' and 'ufrag' attributes, consistent with the definition of an ICE restart in Section 9.1.1.1 of &icecore;. As explained in &icecore;, typically the ICE negotiation would be restarted to change the media target (e.g., an IP address change for one of the parties) and certain third-party-call-control scenarios.
+The recipient then acknowledges receipt.
+The parties would then exchange new candidates to renegotiate connectivity. However, the paties can continue to send media using the existing candidate-in-use while ICE is being renegotiated.
+In order to use one of the newly-negotiated candidates, the parties would use the transport-replace action as explained in the Negotiating a New Candidate section of this document.
+