Re: [MMUSIC] Trickle ICE

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 12 October 2012 08:08 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E23121F8527 for <mmusic@ietfa.amsl.com>; Fri, 12 Oct 2012 01:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.132
X-Spam-Level:
X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqDGGJMCQJDF for <mmusic@ietfa.amsl.com>; Fri, 12 Oct 2012 01:08:19 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8E93A21F8503 for <mmusic@ietf.org>; Fri, 12 Oct 2012 01:08:18 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-91-5077cff19b62
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 87.D8.04547.1FFC7705; Fri, 12 Oct 2012 10:08:17 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 12 Oct 2012 10:08:17 +0200
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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre7H8+UBBnc/iVms2TmBxWLq8scs DkweS5b8ZPL4/yYwgCmKyyYlNSezLLVI3y6BK+NPU1zBDe2KjndX2BoYHyt1MXJySAiYSNz9 t5gFwhaTuHBvPVsXIxeHkMApRom9N46xQjgLGSX+H2gAynBwsAlYSHT/0wZpEBGQl+huW8QE YjMLqEjsu3eDEcRmEVCVeHTgIRuILSygKHHr+CY2iHoliefPJ7FC2EYSS7tnMIPYvALhErcm HmOC2LWYWWLOjkawoZwCmhJv5z0CsxmBrvt+ag3UMnGJW0/mM0FcLSCxZM95ZghbVOLl43+s EPWiEnfa1zNC1OtILNj9iQ3C1pZYtvA11GJBiZMzn7BMYBSbhWTsLCQts5C0zELSsoCRZRWj cG5iZk56uZFealFmcnFxfp5eceomRmDkHNzyW3UH451zIocYpTlYlMR5rbfu8RcSSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAaNPhrftWePkBRZaq38Z7Zm/SOCBjbj6b9YjI8c0lOUWX8teG TajcmNAnHxe8LkLOY7Gta/k9ztKd19u1sqw43r+U3cS9zFJ/2YLlSbtZ5z0W2GWrHTf/QLXj Ot2258x/CpjEb4b8mHZyolP+WvNLPxzM5rp1vppy7vCUzfc0z3pGBMq1dNs+UWIpzkg01GIu Kk4EAOJyhSxqAgAA
Cc: MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Oct 2012 08:08:20 -0000

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.

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

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. 

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

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


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.

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

Regards,

Christer