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

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

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