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

Eric Rescorla <ekr@rtfm.com> Sun, 18 May 2014 00:29 UTC

Return-Path: <ekr@rtfm.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 605BE1A023E for <rtcweb@ietfa.amsl.com>; Sat, 17 May 2014 17:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 CouTL04BuyxQ for <rtcweb@ietfa.amsl.com>; Sat, 17 May 2014 17:29:39 -0700 (PDT)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8601A01C4 for <rtcweb@ietf.org>; Sat, 17 May 2014 17:29:39 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id m15so6549622wgh.16 for <rtcweb@ietf.org>; Sat, 17 May 2014 17:29:37 -0700 (PDT)
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=Yh6VZC3DvoWM3oi3FafJ8Kri97pcDOyIDLF/g8W0v0M=; b=fQvQ1yqrxzotB1pyNyyD9fQEfKl5bvjFOeuQgaz8CBXJQ3GVlXaZ6l6B8+LsyquyWE nICkUX6f6tlGcKn6Ep8oOXw3d0cBFACofZjqTwNjAXVy63paJXoh1/RwdRabDd7bQ7Zt b6vIZvVb82b/g7Znik/7xj4Lgg6uW87K4myzv2uXVpsspGmYZIfx7ew0Ol3ZZlOOMxZa aUQtL9dpHNC5V/6w9HtDx5tXXq5qOY9hY/B1wnBm7jcUylWBQGorju/lImtV9cAx0dmT zIbAP6AnW1DSgNfFYiP3VBFXX9cjjHhTGs0nEeIaZ6JpjucaqJNudMvah055HtOvdhCM IPRA==
X-Gm-Message-State: ALoCoQn7o0at5r9DAu477dCiFnEhVS3NSKYTM+M+/GtcGZSFXvI9/QTXQxMk/1NLW6lKXdguEYwG
X-Received: by 10.180.36.212 with SMTP id s20mr5374056wij.18.1400372977884; Sat, 17 May 2014 17:29:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Sat, 17 May 2014 17:28:57 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <804DCB7A-9D65-4438-82C7-1A553905984B@iii.ca>
References: <CABcZeBNUTf42tS9FrjS9Q6Zk8LBkhpKOR1z2v8MHoeNEUf93Mw@mail.gmail.com> <804DCB7A-9D65-4438-82C7-1A553905984B@iii.ca>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 17 May 2014 17:28:57 -0700
Message-ID: <CABcZeBN9o8ngf6P4TQWhGXseJ5bysFgdCGbBtAeXrCx1Sn1zcg@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Content-Type: multipart/alternative; boundary=e89a8f6473c5e67a7f04f9a1bd6e
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6xEEtoo9KimAtHSpi1aFDOdPRCU
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: Sun, 18 May 2014 00:29:41 -0000

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