diff --git a/xep-0176.xml b/xep-0176.xml
index 297c70af..19d7a767 100644
--- a/xep-0176.xml
+++ b/xep-0176.xml
@@ -27,6 +27,12 @@
&stpeter;
&hildjj;
&seanegan;
+ Changed content-modify to content-replace per XEP-0166. 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: First the initiator sends a Jingle content-modify action to the responder. The content-modify 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 responder then acknowledges the content-modify action.
-The responder then sends a &JINGLE; element with an action of 'content-accept' (or 'session-accept') to the initiator, specifying the candidate that succeeded.
+The responder then sends a session-accept action to the initiator, specifying the candidate that succeeded.
The &JINGLE; element in the content-accept or 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.
+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:
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 content-modify action with the changed candidate information, where the value of the 'generation' is incremented to specify that the candidate information is a modification to an existing candidate.
+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 content-replace action with the changed candidate information, where the value of the 'generation' 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 modification is acceptable, the recipient then sends a content-accept action.
-The initiator then acknowledges the responder's acceptance:
-The receiving party SHOULD check the newly-offered candidate for connectivity, as above. If the candidate is acceptable, the receiving party shall send a content-accept action.
-The responder then acknowledges the replaced content definition.
+The responder then accepts the replaced content definition.
+The other party then acknowledges the content-accept.
-