Re: [MMUSIC] Trickle ICE

Emil Ivov <emcho@jitsi.org> Thu, 11 October 2012 12:17 UTC

Return-Path: <emil@sip-communicator.org>
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 AE03521F853A for <mmusic@ietfa.amsl.com>; Thu, 11 Oct 2012 05:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 UuwVmMqMuFPH for <mmusic@ietfa.amsl.com>; Thu, 11 Oct 2012 05:17:42 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B15021F84E2 for <mmusic@ietf.org>; Thu, 11 Oct 2012 05:17:42 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id hq12so6869500wib.13 for <mmusic@ietf.org>; Thu, 11 Oct 2012 05:17:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=hF4RPsVXrcOxSLhsBohL50hG+NtjO+L2R1vAmbKa5Yc=; b=aZtOAEU1fRR0QPWBy2w2/rI81i2tJqqawWY2jeLzwFGqtzYv1pHSF7Wn1P6epc2HEj zoTCo1W/R8jDscDnCxsqzVzcV7pJqCYF9XIOiLYx9E3vD1LktwlqWHpdynjY51rrOLkq ENn0lmlqGbnydkpkXwWsBO3PxJ4YvRdzJ/3RsvpxjjYf8soSkJZXUTvtSHpVOsV/zZn4 aYLaQ4f9oYn46uYJjzyHXuS73SUni7uk+dJJHXSFqjF8ao6Y4INTrYlCc4FToIbWIqZe ORZxio5i9/6CBccqXCsEqxCMD32xX7aZbtbxVBSEzxq9szt8hqrfE+jzvOakg7QKURar sewQ==
Received: by 10.180.84.202 with SMTP id b10mr1894555wiz.13.1349957861444; Thu, 11 Oct 2012 05:17:41 -0700 (PDT)
Received: from camionet.local ([2a01:e35:2e2c:f600:d4bd:893b:9d69:213d]) by mx.google.com with ESMTPS id ei1sm8415354wid.7.2012.10.11.05.17.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Oct 2012 05:17:40 -0700 (PDT)
Message-ID: <5076B8E4.6050307@jitsi.org>
Date: Thu, 11 Oct 2012 14:17:40 +0200
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
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>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQmpzHLcPgE+vNZY6jZK+M0n87RDra5gqU3y4YTFYMQQjL5nfW7en3WbwTmobvJx932IuYUD
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: Thu, 11 Oct 2012 12:17:43 -0000

Hey Christer,

On 11.10.12, 11:53, Christer Holmberg wrote:
> 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.

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

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

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

Cheers,
Emil

>> I am also wondering what would happen if the answerer says "enough" too
>> early in the process and causes negotiation to fail. Is there a reason
>> why an agent would be willing to risk that? Or are we going to say that
>> it would only do that after finding at least one valid pair for every
>> component?
> 
> Well, the indication could mean please-try-whether-the-candidate-works-before-you-send-me-additional-ones :)
> 
> Regards,
> 
> Christer
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                      FAX:   +33.1.77.62.47.31