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.
+The parties would check the newly-offered candidate for connectivity, as described previously. If the parties determine that media can flow over the candidate, they 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.
@@ -643,8 +643,7 @@ INITIATOR NAT RESPONDER to='romeo@montague.lit/orchard' type='result'/> ]]> -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.
+The parties would then exchange new candidates to renegotiate connectivity and would check the new candidates for connectivity, as described previously. If the parties determine that media can flow over one of the new candidates, they can then use the successful candidate in subsequent communications. However, while ICE is being renegotiated the parties can continue to send media with the existing candidate-in-use.