[MMUSIC] ICE and the "unexpected answer" problem

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

ICE experts,

we came across the following situation that has some relation to ICE restart procedures.

Consider that A calls B via a B2BUA. Both A and B support ICE and have successfully finished ICE procedures though the B2BUA is ICE-unaware.
Now after a while either A or B sends out a new offer to put the other party on hold (a=inactive) without indicating an ICE restart.
It includes the in-use candidates and the remote-candidates as required by section 9 of RFC5245 and expects to get the remote-candidates reflected in the answer.

However, the B2BUA in the signaling path introduces via some 3PCC means a media server that provides MoH to the Held UA.
On the call-leg towards the Holding UA, the B2BUA sends back some dummy answer that fulfills RFC3264 requirements (e.g. includes a=inactive) but does not include the expected remote-candidates.
The Holding UA was unaware of the B2BUA's interference, but now gets an "unexpected answer" to its hold offer.

Of course there could al                so exist other similar situations where the peer changes mid-call and the offerer receives some "unexpected" answer. If we take RFC3264 into consideration, an offerer would need to be prepared to receive such an "unexpected" answer.
But with respect to ICE procedures there is no guidance what to do next, although http://tools.ietf.org/html/rfc5245#section-9.1.1.1 talks already about Hold and ICE restarts.
However, it does not cover the above situation.
Would it be justified to include some clarification e.g.  into rfc5245bis or draft-ietf-mmusic-ice-sip-sdp that something like the above could happen and even give some suggestions when/how to perform ICE restart?

Such suggestion could look roughly as follows:
The UA that got the "unexpected answer" would have to do an ICE restart in order to get things straight again once it sends out its next offer.
In the above situation It would be sufficient when the Holding UA performs the ICE restart once it reconnects to the Held UA,
i.e. it would not be necessary to do the ICE restart immediately although in other situations that might be justified.
In yet other situations there might even be an ICE restart performed from the peer, that sent the "unexpected answer".

Any thoughts/comments?
If people agree I would also be happy to contribute corresponding text.

Regards
Thomas