From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Emil Ivov <emcho@jitsi.org>
Date: Fri, 12 Oct 2012 10:08:15 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2n+DtxGjRhRK0WR4igXHZmBiwAFwAVQZtg
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>,
 <5075864F.3030700@jitsi.org>
 <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>,
 <5075FB20.6070408@jitsi.org>
 <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se>
 <5076B8E4.6050307@jitsi.org>
 <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se>
 <50773B73.6060508@jitsi.org>
In-Reply-To: <50773B73.6060508@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE
Precedence: list

Hi,

Q1: Remote endpoint support (SIP):=20
--------------------------------------------

>>>> Also, I guess I still haven't completely understood the backward=20
>>>> compatibility issue, but I guess I need to do some more reading.
>>>=20
>>> We describe these in Section 3 but the main problem is that a vanilla=20
>>> ICE agent that gets a first subset of candidates (that may also be=20
>>> empty) would declare failure prematurely.
>>=20
>> The text gives an example where the receiver (Bob) receives a=20
>> host-candidate-only offer, and start checks which fail.
>>=20
>> I think it's quite strange if Bob would reject the call at that point.=20
>> Because, no matter how many candidates the offer contains, there might=20
>> still be peer reflexive candidates created later,
>
> How does Bob know that there's going to be a "later" ? It's just a vanill=
a ICE agent that assumed it received a full set of candidates, it checked t=
hem all, all checks failed.

Bob knows that there will be STUN requests coming, and based on those addit=
ional candidates (peer reflexive) might be created.

> Now, we could rely on Bob not doing anything rash and waiting patiently f=
or reINVITEs from Alice in order to get more candidates ...

The peer reflexive candidates will not come in a re-INVITE, they will be cr=
eated based on the STUN requests.

Having said that, I agree that legacy ICE endpoints might not behave that w=
ay, and reject the call, but then we would simply do a fallback to legacy I=
CE.=20

> Besides there are other possible failures, like for example the case wher=
e I get your server reflexive candidates long before you get mine so we per=
form 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=20
>>>>>>> re-using the same ports in multiple m- lines etc :)
>>>>>>=20
>>>>>> Well, we are not saying that they should not be addressed at all,=20
>>>>>> or even now. Just that maybe they shouldn't be addressed by this=20
>>>>>> specific document.
>>>>>=20
>>>>> Perhaps we shouldn't say anything about finding out in advance,=20
>>>>> then. At least not use SHOULD.
>>>>>=20
>>>>> We CAN describe what may happen if the remote peer does not support=20
>>>>> trickle ICE, but leave it to that.
>>>>=20
>>>> What we'd like to avoid is having trickle ICE offers to vanilla ICE=20
>>>> agents and then having them fail in a user-perceptible way.
>>>>=20
>>> Maybe we could modify the "SHOULD verify support" to "SHOULD verify=20
>>> support or provide a mechanism for transparent fallback to vanilla=20
>>> ICE"
>>=20
>> In my opinion, if one has to do something extra (e.g. send OPTIONS),=20
>> the whole idea of trickle-ICE goes away, because at the end of the day=20
>> you won't save any time in call establishment.
>
> The OPTIONS request does not need to be sent right before the call. It ca=
n be done once, upon bootstrap.

Yes, but in that case there is an even less chance that the OPTIONS and INV=
ITE requests will reach the same remote peer (in case of forking).

>> Now, if the browser is communicating with a ICE terminating gateway,=20
>> and if the browser performs SIP registration, then the gateway can=20
>> indicate trickle-ICE during registration.
>>=20
>> But, in the peer-to-peer case I don't know how it would work. It's not=20
>> 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) woul=
d 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 fal=
l back strategy when it does not (e.g. with SIP).

There ARE ways to do it, but they all suck :)


Q3: Enough is enough:=20
---------------------------

>>>>>> I think it could be useful for the answerer to tell the offerer=20
>>>>>> that it doesn't want/need any more candidates.
>>>>>=20
>>>>> Yes, sounds useful. Do you have any specific use cases in mind?
>>>>=20
>>>> Well, I guess any case where the remote peer knows it has a public=20
>>> IP address (it will most likely be an ICE lite entity).
>>>=20
>>> Right, but in such cases the offerer would also know that a certain=20
>>> pair has succeeded so if they continue it might be with the purpose=20
>>> of finding a better RTT or a higher priority local candidate.
>>>=20
>>> I guess what I am trying to say is that a Binding Response is enough=20
>>> of an indication that trickling can stop. If it doesn't then maybe=20
>>> it's for a reason.
>>=20
>> Maybe it is enough... In any case I think it would be good to document=20
>> :)
>
> OK. Agreed.
>
>> Also, at least in cases where the remote peer only provide a host=20
>> candidate (because it has a public IP address), one should be smart=20
>> enough to figure out that there most likely will be no better=20
>> alternative.
>
> I am not sure I got this.

If the remote peer only provides a host candidate, and it works, I think th=
ere won't be any better alternatives.

Anyway, it's not that important, just some brainstorming from my side :)

Regards,

Christer