Re: [MMUSIC] ICE and the "unexpected answer" problem

Thomas,

On 7/23/14 8:00 AM, Stach, Thomas wrote:
> 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.

Not too unusual.

> 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.

Can you provide details of the offers and answers?

If it is going to provide MoH then presumably it isn't setting the media 
inactive. (Or is it doing MoH on audio and setting video inactive?)

Note that once the call goes off hold all this will happen again to get 
back to the actual device again.

	Thanks,
	Paul

> 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
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>