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

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

Partha,

> 
> Hi Thomas,
> 
> Could you please mention the exact 3PCC callflow which breaks because of
> the ICE second offer. 
You might want to look into
http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-02#section-3.1

> Of course ideally, it should have covered in ICE (RFC
> 5245).
We could cover this in ICEbis though.
> 
> 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. 
RC5245 has already covered this
Regards
Thomas
> 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