Re: [MMUSIC] Trickle ICE

[Lishitao <[e-mail]>]

Hi Emil

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Emil Ivov
> Sent: Friday, October 12, 2012 5:35 AM
> To: Christer Holmberg
> Cc: MMUSIC IETF WG
> Subject: Re: [MMUSIC] Trickle ICE
> 
> Hey Christer,
> 
> On 11.10.12, 21:23, Christer Holmberg wrote:
> >
> > Hi,
> >
> > Q1: Remote endpoint support (SIP):
> > ----------------------------------
> >
> >>>>> You say that, before the first offer is sent, one SHOULD
> >>>>> determine whether the remote endpoint supports trickle ICE.
> >>>>>
> >>>>> For SIP, you give RFC 3840 as an example. I am not sure how
> >>>>> that will work. Yes, you can use 3840 to request that the
> >>>>> offer is sent to an entity which supports trickle ICE (for
> >>>>> that, btw, you will also need to define an option tag, or
> >>>>> something similar),
> >>>>
> >>>> Right, but we were hoping this would happen in a separate spec
> >>>> that details use of trickle ICE with SIP.
> >>>>
> >>>>> but you cannot use it to determine whether the remote
> >>>>> endpoint supports trickle ICE. In addition, you typically use
> >>>>> 3840 at the same time when you send the initial offer.
> >>>>>
> >>>>> Of course, you could use SIP OPTIONS.
> >>>>
> >>>> Yes, that was the idea. The way 3840 describes it in Section
> >>>> 8.
> >>>>
> >>>>> But, there are a number of issues related to that, and I
> >>>>> don't think we want to define a mechanism which relies on the
> >>>>> usage of OPTIONS.
> >>>>>
> >>>>> And, if we simply say that it's "outside the scope of the
> >>>>> document",
> >>>>
> >>>> I was just about to say that ;).
> >>>>
> >>>> But, seriously, determining and negotiating caps happens very
> >>>> differently in different signalling protocols, so it doesn't
> >>>> seem reasonable to try and find answers for all of them in the
> >>>> generic trickle ICE spec.
> >>>>
> >>>> XMPP for example, has this part covered pretty well. If we
> >>>> determine that 3840 does not provide a way of doing the same
> >>>> then we can find another way for SIP.
> >>>>
> >>>> Eric had this idea, where a trickle ICE agent would simply fire
> >>>> a first offer that only other trickle ICE agents would accept
> >>>> and that any other SIP endpoint would answer with an error.
> >>>> This would be enough of a check and if it fails the caller can
> >>>> fall back to vanilla ICE.
> >>>
> >>> Sure, but that is not checking for trickle support before sending
> >>> the trickle offer :)
> >>
> >> Yes, the wording may need to be reviewed if we go for this.
> >>
> >>> Also, I guess I still haven't completely understood the backward
> >>> compatibility issue, but I guess I need to do some more reading.
> >>
> >> We describe these in Section 3 but the main problem is that a
> >> vanilla ICE agent that gets a first subset of candidates (that may
> >> also be empty) would declare failure prematurely.
> >
> > The text gives an example where the receiver (Bob) receives a
> > host-candidate-only offer, and start checks which fail.
> >
> > I think it's quite strange if Bob would reject the call at that
> > point. Because, no matter how many candidates the offer contains,
> > there might still be peer reflexive candidates created later,
> 
> How does Bob know that there's going to be a "later" ? It's just a
> vanilla ICE agent that assumed it received a full set of candidates, it
> checked them all, all checks failed.
> 
> Now, we could rely on Bob not doing anything rash and waiting patiently
> for reINVITEs from Alice in order to get more candidates ... but that
> might be about as risky as relying on empty INVITEs to be handled
> properly by everyone or on OPTIONS to be transmitted end-to-end.
> 
> Besides there are other possible failures, like for example the case
> where I get your server reflexive candidates long before you get mine so
> we perform checks out of sync (the case that I also described in my
> other mail to Martin).
> 
> > once
> > the offerer (Alice) starts sending the STUN binding requests. So, one
> > would think that Bob at least would wait for those.
> >
> >>>> Another option would be for trickle ICE agents to send empty
> >>>> INVITEs that somehow indicate they will be trickling but
> >>>> contain no actual offer. The offer that the remote side then
> >>>> adds in an OK response (or a provisional one) would clearly
> >>>> indicate whether they support vanilla, trickle, or no ICE at
> >>>> all, so the trickle agent would be able to answer accordingly
> >>>> with the ACK.
> >>>
> >>> I don't think we want to rely on empty INVITEs either, because
> >>> there are a number of issues related to that.
> >>
> >> Well, it might be worth investigating exactly what they are. The
> >> same applies to using OPTIONS and 3840.
> >
> > Well, to start with, empty INVITEs will work very badly with legacy.
> 
> You mean, because legacy devices don't properly implement 3261 in that
> regard?
> 
> That might actually be a good thing. An error response at this point
> would be a good indication that there's no trickle ICE support at the
> remote side.

In this way , as christer described, it won't save any time in call establishment. 

> > In addition, there migth be other functions which do not work with
> > empty INVITEs.
> 
> OK, I agree. It's a clumsy solution at best. It would be impossible for
> SIP user agents to translate a user request to start an audio,
> audio/video or some other media session (which is the typical rant you
> get for handling empty INVITEs). It was just a thought :)
> 
> > And, I am not sure how it would work with JSEP.
> 
> You mean, in cases of gatewaying SIP to WebRTC? I suppose it could just
> be translated to some custom signalling that actually does capability
> negotiation and then triggers a remote INVITE ... OK I know, it's a stretch.
> >
> >
> >>>>>> we could do the same for BUNDLE, and we wouldn't have
> >>>>>> issues with re-using the same ports in multiple m- lines
> >>>>>> etc :)
> >>>>>
> >>>>> Well, we are not saying that they should not be addressed at
> >>>>> all, or even now. Just that maybe they shouldn't be addressed
> >>>>> by this specific document.
> >>>>
> >>>> Perhaps we shouldn't say anything about finding out in advance,
> >>>> then. At least not use SHOULD.
> >>>>
> >>>> We CAN describe what may happen if the remote peer does not
> >>>> support trickle ICE, but leave it to that.
> >>>
> >>> What we'd like to avoid is having trickle ICE offers to vanilla
> >>> ICE agents and then having them fail in a user-perceptible way.
> >>>
> >> Maybe we could modify the "SHOULD verify support" to "SHOULD verify
> >> support or provide a mechanism for transparent fallback to vanilla
> >> ICE"
> >
> > In my opinion, if one has to do something extra (e.g. send OPTIONS),
> > the whole idea of trickle-ICE goes away, because at the end of the
> > day you won't save any time in call establishment.
> 
> The OPTIONS request does not need to be sent right before the call. It
> can be done once, upon bootstrap.

If the callee has already in your contact list, of course you can do that, but if you 
call a strange number at the first time, the OPTION request should be sent right 
before the call.


/Shitao

> > Now, if the browser is communicating with a ICE terminating gateway,
> > and if the browser performs SIP registration, then the gateway can
> > indicate trickle-ICE during registration.
> >
> > But, in the peer-to-peer case I don't know how it would work. It's
> > not even sure OPTIONS would reach the same remote peer as the
> > INVITE...
> 
> I agree. Not sure what to say other than, I agree that SIP does not have
> good mechanisms for XMPP like negotiation of entity caps but,
> personally, I do believe that finding one would be helpful here.
> 
> Maybe we can work on making sure that 3840 (or some other mechanism)
> would better allow for caps to be discovered in advance.
> 
> At the very least, if we can't find a way to do this gracefully with
> SIP, we can RECOMMEND it whenever the protocol allows it and try to
> devise a fall back strategy when it does not (e.g. with SIP).
> 
> > Q2: Offer/Answer Alignment: ---------------------------
> >
> >>>>> I assume the offers and answer are sent according to the
> >>>>> rules in RFC 3264.
> >>>>>
> >>>>> If so, when you talk about offers and/or answers "being sent
> >>>>> at any point", I think it needs to be clear that it's within
> >>>>> the rules of 3264.
> >>>>
> >>>> Good point! I think the text is indeed a bit unclear in that
> >>>> regard and we might be making some non-stated assumptions about
> >>>> the relation between 3264 Offer/Answer, the actual call
> >>>> answering, and the connectivity checks phase. We'll fix this.
> >>>
> >>> Thanx! :)
> >
> >
> > Q3: Enough is enough: ---------------------
> >
> >>>>> I think it could be useful for the answerer to tell the
> >>>>> offerer that it doesn't want/need any more candidates.
> >>>>
> >>>> Yes, sounds useful. Do you have any specific use cases in
> >>>> mind?
> >>>
> >>> Well, I guess any case where the remote peer knows it has a
> >>> public IP address (it will most likely be an ICE lite entity).
> >>
> >> Right, but in such cases the offerer would also know that a certain
> >> pair has succeeded so if they continue it might be with the purpose
> >> of finding a better RTT or a higher priority local candidate.
> >>
> >> I guess what I am trying to say is that a Binding Response is
> >> enough of an indication that trickling can stop. If it doesn't then
> >> maybe it's for a reason.
> >
> > Maybe it is enough... In any case I think it would be good to
> > document :)
> 
> OK. Agreed.
> 
> > Also, at least in cases where the remote peer only provide a host
> > candidate (because it has a public IP address), one should be smart
> > enough to figure out that there most likely will be no better
> > alternative.
> 
> I am not sure I got this.
> 
> Cheers,
> Emil
> >
> >
> > Regards,
> >
> > Christer
> >
> >
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic