Re: [MMUSIC] Trickle ICE

[Emil Ivov <[e-mail]>]

Hey Christer,

On 12.10.12, 10:08, Christer Holmberg wrote:
> Hi,
> 
> Q1: Remote endpoint support (SIP): 
> --------------------------------------------
> 
>>>>> 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.
> 
> Bob knows that there will be STUN requests coming, and based on those
> additional candidates (peer reflexive) might be created.

Chances are that no STUN requests will be arriving unless Bob is also
making simultaneous checks toward Alice's SR candidates, which he isn't
because he doesn't have them.

>> Now, we could rely on Bob not doing anything rash and waiting
>> patiently for reINVITEs from Alice in order to get more candidates
>> ...
> 
> The peer reflexive candidates will not come in a re-INVITE, they will
> be created based on the STUN requests.

That's kind of a corner case. Learning peer-reflexive candidates
implies that Bob can get Alice's conn checks which would only happen if
Bob's addresses are directly reachable from Alice (e.g. Bob has a public
address or a NAT with no endpoint dependent filtering). All in all, not
the most likely scenario.

> Having said that, I agree that legacy ICE endpoints might not behave
> that way, and reject the call, but then we would simply do a fallback
> to legacy ICE.

The problem is that in this case Bob might have been alerted of the call
and witnessed the failure, so a fallback to vanilla ICE would not be
particularly smooth.

>> 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).
> 
> I'll need to re-read that.
> 
>>>>>>>> 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.
> 
> Yes, but in that case there is an even less chance that the OPTIONS
> and INVITE requests will reach the same remote peer (in case of
> forking).

True. Maybe adding gruu-s into the mix could help ... This would indeed
imply that the caller needs prior knowledge of the callee (e.g. adding
them to a contact list) but maybe we can have this and then another
solution for the first call/unknown callee case.

I am pretty much out of ideas for the time being anyway, so if you, or
anyone else, can think of something that would miraculously solve the
issue, I'd be very happy to hear it.

>>> 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).
> 
> There ARE ways to do it, but they all suck :)

Is it realistic to expect that we can improve any of them to do the job?
Or add a new one?

> 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.
> 
> If the remote peer only provides a host candidate, and it works, I
> think there won't be any better alternatives.

I don't know about that. Well, what if the host candidate is actually an
IPv6 (or VPN) tunnel with poor latency and bandwidth and the SR
candidate works better? Or what if it's the address of an 802.11g/b
interface and the same machine has a NATed Ethernet connection with,
again, better bandwidth and latency?

All in all, making assumptions on the receiving end is always a risk. If
the host sending the candidates knows that they are its best/only
candidates, then it could indicated so by sending the end-of-candidates
message we describe in the draft.

Cheers,
Emil

> Anyway, it's not that important, just some brainstorming from my side
> :)
> 
> Regards,
> 
> Christer