Re: [MMUSIC] Trickle ICE

[Emil Ivov <[e-mail]>]

Hey Shitao,

On 12.10.12, 04:43, Lishitao wrote:
> 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. 

I believe Christer was referring to the case where an extra RTT right
before trickle ICE negotiation.

In this case however we are talking about an extra RTT that happens
before a vanilla ICE session and that is not in anyway blocking
candidate harvesting, so I don't see how it would be a problem.

That said, I already agreed that relying on empty INVITEs has other
disadvantages (same as empty INVITEs outside the context of ICE).

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

Yes, good point!

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

-- 
https://jitsi.org