Modified flow for ICE completion to require content-modify from initiator to responder, thus mapping to sending of revised offer in SIP; added rem-addr and rem-port attributes to map to a=remote-candidates information in SDP; changed raddr and rport attributes to rel-addr and rel-port to prevent confusion with rem-addr and rem-port attributes.
Note: 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 a given candidate, the responder sends a &JINGLE; element with an action of 'content-accept' (or 'session-accept') to the initiator, specifying the candidate that succeeded.
+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).
+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.