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

Eric Rescorla <> Sun, 18 May 2014 00:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 605BE1A023E for <>; Sat, 17 May 2014 17:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CouTL04BuyxQ for <>; Sat, 17 May 2014 17:29:39 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E8601A01C4 for <>; Sat, 17 May 2014 17:29:39 -0700 (PDT)
Received: by with SMTP id m15so6549622wgh.16 for <>; Sat, 17 May 2014 17:29:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id s20mr5374056wij.18.1400372977884; Sat, 17 May 2014 17:29:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 17 May 2014 17:28:57 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Sat, 17 May 2014 17:28:57 -0700
Message-ID: <>
To: Cullen Jennings <>
Content-Type: multipart/alternative; boundary=e89a8f6473c5e67a7f04f9a1bd6e
Cc: "" <>
Subject: Re: [rtcweb] When are ICE candidates added to the SDP
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 May 2014 00:29:41 -0000

On Sat, May 17, 2014 at 11:19 AM, Cullen Jennings <> wrote:

> On May 11, 2014, at 6:51 PM, Eric Rescorla <> 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.