[MMUSIC] Text proposal resolving the ICE-"unexpected answer" issue

["Stach, Thomas" <[e-mail]>]

All,

at the last MMUSIC session I was asked to provide some text resolving the "unexpected answer" issue that I brought up on the MMUSIC list.
It took a while, but below is what I propose to include in draft-ietf-mmusic-ice-sip-sdp.

Currently there thee section dealing with the initial SDP offer/answer exchange.
3.  Sending the Initial Offer
4.  Receiving the Initial Offer
5.  Receipt of the Initial Answer
Now, section 9 deals with  subsequent SDP offer/answer exchanges, where the new text needs to go in.
It has subsections (9.1, 9.2) equivalent to 3 and 4 above, however, nothing equivalent to 5.
Thus, I think the existing 9.3 should be moved in new subsection 9.4 and the following text should be introduced:

9.3.  Receiving the answer for a subsequent offer

Some deployments of ICE include e.g. SDP-Modifying Signaling-only B2BUAs [RFC7092] that modify the SDP body during the subsequent offer/answer exchange. With the B2BUA being ICE-unaware a subsequent answer might be manipulated and might not include SDP candidates although the initial answer did.

An example of a situation where such an "unexpected" answer might be experienced appears when such aB2BUA introduces a media server during call hold using 3rd party call-control procedures. Omitting further details how this is done this could result in an answer being received at the holding UA that was constructed by the B2BUA. With the B2BUA being ICE-unaware that answer would not include SDP candidates.
Receiving an answer without ICE attributes in this situation might be unexpected, but would not necessarily impair the user experience.
In addition to procedures for the expected answer, the following sections give also some advice how to recover from the unexpected situation.


9.3.1 Procedures for All Implementations
When receiving an answer within an existing session for a subsequent offer as specified in 9.1.2.2, an agent MUST verify ICE support as specified in Section 5.1.

9.3.1.1 ICE restarts

If ICE support is indicated in the SDP answer, the agent MUST perform ICE restart procedures as specified in section 9.4 (the existing section 9.3) below.

If ICE support is no longer indicated in the SDP answer, the agent MUST fall-back to RFC 3264 procedures and SHOULD NOT drop the dialog just because of missing ICE support. If the agent sends a new offer later on it SHOULD perform an ICE restart as specified in 9.1.1.1.

9.3.1.2 Existing Media Streams with ICE Running

If ICE support is indicated in the SDP answer, the agent MUST continue ICE procedures as specified in section 9.4.1.4 (the existing section 9.3.1.4) below.
If ICE support is no longer indicated in the SDP answer, the agent MUST abort the ongoing ICE processing and fall-back to RFC 3264 procedures. The agent SHOULD NOT drop the dialog just because of missing ICE support. If the agent sends a new offer later on, it SHOULD perform an ICE restart as specified in 9.1.1.1.

9.3.1.3 Existing Media Streams with ICE Completed

If ICE support is indicated in the SDP answer and if the answer conforms to 9.2.2.3, the agent MUST remain in the ICE Completed state.

If ICE support is no longer indicated in the SDP answer, the agent MUST fall-back to RFC 3264 procedures and SHOULD NOT drop the dialog just because of this unexpected answer. Once the agent sends a new offer later on it MUST perform an ICE restart.


Existing 9.3 --> 9.4.  Updating the Check and Valid Lists
....

I'd like to get your feedback, if  that proposal is reasonable.

Regards
Thomas