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

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 23 Jul 2014 12:00:04 +0000

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Jul 2014 23:36:01 -0400

Thomas,

On 7/23/14 8:00 AM, Stach, Thomas wrote:
> 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.
>
> 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?
>
> 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?
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 24 Jul 2014 15:48:10 +0000

Paul,

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Mittwoch, 23. Juli 2014 23:36
> To: [email-masked]
> Subject: Re: [MMUSIC] ICE and the "unexpected answer" problem
> 
> Thomas,
> 
[TS] I could give details about the settings of direction attribute to a=sendrecv/inactive/sendonly, but that is not the issue I want to clarify.

I want to get clarification for the situation when due to an offer/answer exchange during an active dialog the support for ICE is removed (or added back again). 
In case of an ICE restart section 9.1.1.1 of RFC5245 has some words that mention changes of implementation level.
However, the case, where the implementation level changed outside of an ICE restart, is not covered.
E.g. in this MoH case, the offer was sent with the in-use candidates, but the answer did no longer include ice-ufrag/ice-pwd/candidates.
An implementation could have decided in such a situation to abandon the call or stop ICE for the rest of call. 
I think both would be bad.
It would be better just to do an ICE restart once the next offer is being sent. 
In the MoH case  it would be OK to do that when the call is put off hold again, 
i.e. it wouldn't be necessary to do the restart immediately.
Regards
Thomas

> > "unexpected" answer. If we take RFC3264 into consideration, an offerer
> > would need to be prepared to receive such an "unexpected" answer.
> >
> > The UA that got the "unexpected answer" would have to do an ICE restart
> > from the peer, that sent the "unexpected answer".
> >
> > Any thoughts/comments?
> >