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

Paul,

> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Mittwoch, 23. Juli 2014 23:36
> To: mmusic@ietf.org
> Subject: 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.
[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

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