Re: [MMUSIC] ICE updated offer - Back to the initial question

["Parthasarathi R" <[e-mail]>]

Hi Thomas,

Could you please mention the exact 3PCC callflow which breaks because of the
ICE second offer. Of course ideally, it should have covered in ICE (RFC
5245). 

Early dialog will not work without PRACK (RFC 3264) in the single
offer/answer itself. In case you assume that 18x is reliable without PRACK
then it has lot of caveat as the intermediate SIP entities may use UDP as a
transport wherein UAS has no control over. I assume that you intent to say
that UPDATE (RFC 3311) is mandated in case of RFC 5245 second offer.

Thanks
Partha

> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of Stach,
> Thomas
> Sent: Monday, October 20, 2014 8:03 PM
> To: Christer Holmberg; Ari Keränen; mmusic
> Subject: Re: [MMUSIC] ICE updated offer - Back to the initial question
> 
> Christer,
> 
> I'm trying to understand ...
> ... and disagree with your last point
> 
> > -----Original Message-----
> > From: Christer Holmberg [mailto:[e-mail]]
> > Sent: Freitag, 17. Oktober 2014 12:01
> > To: Stach, Thomas; Ari Keränen; mmusic
> > Subject: RE: [MMUSIC] ICE updated offer - Back to the initial
> question
> >
> > Hi,
> >
> > Whatever decisions are made at the meetings must (or, at least that
> seem to
> > be de facto practise) be confirmed on the mailing list. So, it is ok
> to
> > challenge them (luckily that doesn't happen too often, though - at
> least
> > not within the groups where I participate).
> >
> > >Proposal A: Indicate in the ANSWER whether the second offer is
> needed or
> > not.
> > >Proposal B: If you need the update, send an offerless re-INVITE with
> a
> > flag
> > >            that suppresses an ICE restart,
> > >            but triggers the ICE updated offer instead.
> >
> > Using SIP terminology (as this mechanism could only be used with SIP
> > anyway), the second offer will almost always be send during an early
> > dialog, while the initial INVITE transaction is still ongoing.
> [TS] You seem to assume support for PRACK here.
> Of course, the offerless re-INVITE could not be used as a trigger for
> the new offer in this case.
> You would need "something else" in such an environment.
> The offerless INVITE, nevertheless, sounds attractive to me for other
> environments, since it only requires basic RFC3261 functionality.
> > You cannot send a re-INVITE during that time, so it wouldn't work.
> [TS] If PRACK is not supported, you also couldn't send that second
> offer during the early dialog.
> > Sending the re-
> > INVITE once the call has been established could prevent early media,
> [TS] So, if the offerer does support ICE but not PRACK, it wouldn't get
> early media, even if the connectivity checks were successful?
> Do you assume support for preconditions in addition to PRACK?
> > and
> > any other information transported on the media plane during the early
> > dialog phase.
> >
> > >Proposal C: The signaling entity should inform the media entity
> about
> > >            the candidates. The media entity can then learn through
> the
> > >           STUN checks which address is eventually used for media.
> >
> > That might work if the media entity is STUN aware (and if the
> > interface/protocol used to control the media entity supports
> transporting
> > that kind of information). Often they are not. They are simply used
> to e.g.
> > enforce bandwidth (and other network resources) and gating.
> >
> > > Are there additional proposals or do we want to choose from these?
> >
> > One is to keep everything as it is today, as nothing is broken.
> [TS] I beg to disagree here. I repeatedly mentioned that certain 3PCC
> call flows break _due_ to the updated offer.
> Regards
> Thomas
> > Nobody has indicated that as a preference, though.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> > > -----Original Message-----
> > > From: mmusic [mailto:[e-mail]] On Behalf Of Ari
> Keränen
> > > Sent: Dienstag, 14. Oktober 2014 10:15
> > > To: mmusic
> > > Subject: [MMUSIC] ICE updated offer
> > >
> > > Hi all,
> > >
> > > At the Toronto meeting we discussed whether we should change the
> > > behavior with ICE updated offer. Currently, based on RFC 5245, when
> > > ICE has finished, there is a new offer/answer with the selected
> > > candidate,
> > > *if* they are different from the "default candidates", i.e., the
> ones
> > > in original o/a m- and c-lines.
> > >
> > > Based on the discussion there was strong desire to have an option
> of
> > > not doing the updated o/a at all by indicating this in the original
> > > o/a. On the other hand, for some, the updated o/a was seen as a
> > > requirement for getting correct behavior from the network in
> certain
> > > scenarios (e.g., with SIP-aware middle boxes).
> > >
> > > I would like to hear from people, who have issues making the
> updated
> > > o/a optional, how bad the change would be and is there a way we
> could
> > > make this work also in those scenarios?
> > >
> > >
> > > Cheers,
> > > Ari
> > >
> > > _______________________________________________
> > > mmusic mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mmusic
> >
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic