Re: [MMUSIC] Trickle ICE

[Christer Holmberg <[e-mail]>]

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

In addition, there migth be other functions which do not work with empty INVITEs.

And, I am not sure how it would work with JSEP.


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

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


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

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.


Regards,

Christer