Re: [rtcweb] When are ICE candidates added to the SDP

Justin Uberti <juberti@google.com> Mon, 19 May 2014 04:14 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56C71A0016 for <rtcweb@ietfa.amsl.com>; Sun, 18 May 2014 21:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level:
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n82ZMtNs0zE9 for <rtcweb@ietfa.amsl.com>; Sun, 18 May 2014 21:14:23 -0700 (PDT)
Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9631A0008 for <rtcweb@ietf.org>; Sun, 18 May 2014 21:14:23 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id ij19so9074362vcb.0 for <rtcweb@ietf.org>; Sun, 18 May 2014 21:14:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1TfkVNhin6YWZvcPT5RV4QrSVVN7t8e/25p+LvFA08I=; b=gRHDR9NM60zDIXeLpcErKgqEKaCqAWymfkDmu1spqmcA9tJn/IvD3ZV2NLpJjnxw41 Titu5jEmDYM+m8PhCDAYnFQCZeUqJMhncut88rR2sXahkOR6XANGhf33XaawRAYBxZGx FesOim81F9JqH3bWsCbIG67yqo4ma6jDhuvkRhCE8X0d0GsTMoUwzeFeLEvHrkOZaU9+ 1H9kKCQ0CbGl5mFhNrtOmjWQJLTWNoQc777EpIOk2dH8atFCMW8AyZW8LH0kpVYxJd/G meuZp56ThSwVs8XlWXzpkJWuIKeolvGhYPUnNQhEXQ5212xqm2OCjwvAwvQq4GWO9fVy szWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1TfkVNhin6YWZvcPT5RV4QrSVVN7t8e/25p+LvFA08I=; b=Am+Fq4Y65gXgxon0fXGnY4rVAZqurXZfDX5VVKryfYAbaR/1gqWG0A8JOwDsEB2SaD iQWvKITLBlRN1/jWqQqNFJSlsjc+JQdJGT9e4GnUsS5OOOPmAbpAxwkV8Iu8LJys1rVH KcinjCFpXrOqfz/e6kGvt9h8HHrjh5mA1VdJUrPEdoBdv55GDNfMNmRo4rsu7xsqWIKO BNo3CWa0WFypGAnUY80+08CaEUJoIpbeOtM3OVR0iNSi1sqIWxGUM6SvzX5wwZ/siDq9 gO6mV1o6UdedENGM41Nyl3EHB3evF2GU7EOHF2OCcn8mhfR33Coo05t4UlWohHJPkYCT 5shQ==
X-Gm-Message-State: ALoCoQkodPgOhiW0xyOV9VS3XS3G/nNkzwtWZEuO9hP8Qb7TV4uRw3kKIG0nuuWwBagzWxEUoYlN
X-Received: by 10.52.13.41 with SMTP id e9mr10350912vdc.21.1400472863086; Sun, 18 May 2014 21:14:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.145.105 with HTTP; Sun, 18 May 2014 21:14:03 -0700 (PDT)
In-Reply-To: <CABcZeBN9o8ngf6P4TQWhGXseJ5bysFgdCGbBtAeXrCx1Sn1zcg@mail.gmail.com>
References: <CABcZeBNUTf42tS9FrjS9Q6Zk8LBkhpKOR1z2v8MHoeNEUf93Mw@mail.gmail.com> <804DCB7A-9D65-4438-82C7-1A553905984B@iii.ca> <CABcZeBN9o8ngf6P4TQWhGXseJ5bysFgdCGbBtAeXrCx1Sn1zcg@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Sun, 18 May 2014 21:14:03 -0700
Message-ID: <CAOJ7v-2KijjfV3VKDGT4yj4FmwQZmrcfFEmTXMHJb2oPS5jiqQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=20cf302efaf685ba6404f9b8ff03
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ot-qjUY7BqK3dsZz7UF6MwsmR3s
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] When are ICE candidates added to the SDP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 May 2014 04:14:26 -0000

Agree with Martin's analysis.

Regarding what we should do after a new setLocalDescription, the
implementation does need to change the value of iceGatheringState if new
gathering is going to occur. As pointed out, since we don't have a callback
for iceGatheringState, firing onicecandidate(null) if no gathering needs to
happen seems reasonable, if inelegant.

But the reason for not having an iceGatheringState callback was because we
felt that it was redundant with onicecandidate. That now seems debatable,
and I'd rather add that callback than pound onicecandidate until it looks
like said callback.


On Sat, May 17, 2014 at 5:28 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
>
> On Sat, May 17, 2014 at 11:19 AM, Cullen Jennings <fluffy@iii.ca> wrote:
>
>>
>> On May 11, 2014, at 6:51 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> > However, we agreed in London that we would do "always trickle", and
>> > that even if there were candidates available at the time when
>> CreateOffer
>> > (because of candidate pooling) was called, they would not be included
>> > in the initial offer.
>>
>> Hmm - did we agree they would not be there or they might not be there?
>>
>
> My memory is that Justin argued that it would be more consistent to
> not have them and I agreed to check to see if that was a big deal
> for Firefox. It's not.
>
>
>
>> Either way, I think that things will work better if we can provide
>> whatever information we have available at the time the  call returns. So my
>> preference would be that if they are in the pool, they are returned as
>> early as possible.
>
>
> We're talking about having the onicecandidate callbacks called immediately
> on setLocal(), so this should't have much latency impact.
>


>
>
>
>
>> I can not really see any good reasons for delaying the return of the
>> candidates that are available.  Even when you are doing trickily ICE, this
>> is going to result in less round trips of “trickle” and result in closer
>> synchronization of the connectivity checks from both sides for the
>> candidates that are returned in the first offer. That will help up the
>> success rate of trickle ICE.
>>
>
> See above. I don't think this analysis is really correct.
>
> -Ekr
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>