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

[Christer Holmberg <[e-mail]>]

Hi,

>> 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

The text in that draft says:

	"The B2BUA cannot pass that request on until the INVITE transaction 
	with UA2 has completed."

This is only true if PRACK is not supported.

In 5245 we did a hack, allowing to send the "answer" in unreliable 18x. The justification was that "people don't implement PRACK". Perhaps, as part of the bis work, we should check whether that justification is still valid. 

Regards,

Christer








> 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