Re: [MMUSIC] Trickle ICE

[Christer Holmberg <[e-mail]>]

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.

Since Alice supports trickle, we can specify that Alice shall not wait for Bob's checks :)

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

I assume that Bob (since he doesn't support trickle) has provided ALL his available candidates (server reflexive, relay etc) in the SDP answer.

(Just because Bob only got a host candidate in the offer, it doesn't mean he will only return a host candidate in the answer.)


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

I think that's an implementation issue, whether Bob is alerted before a working ICE pair has been found.

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

I think we simply need to accept the fact that the offer may be rejected.

Based on the discussion above, I believe there are cases where things will work even if Bob doesn't support trickle, and in other case we'll just have to send a new non-trickle offer.

Of course, people CAN use OPTIONS, or whatever mechanisms they want to figure out before sending the offer, but I don't think we should have that as a SHOULD.

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

This is not the first time we realize that it would be good to know what the remote peer supports :)


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.

In case Bob has a public IP address, why does Alice need to send an offer with the additional candidates in the first place? Why not simply start using them, and Bob will process them as peer reflexive candidates?

(I can understand that signaling is needed in case per-candidate ufag/pwd values are used, but let's assume a case where the same values are used for all candidates.)

Regards,

Christer