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

Martin Thomson <> Tue, 13 May 2014 16:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EBBDA1A013F for <>; Tue, 13 May 2014 09:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4tNLrGJ9hoaw for <>; Tue, 13 May 2014 09:45:20 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::233]) by (Postfix) with ESMTP id 165851A008E for <>; Tue, 13 May 2014 09:45:19 -0700 (PDT)
Received: by with SMTP id bs8so956300wib.12 for <>; Tue, 13 May 2014 09:45:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x8ggPpdlJhE867ugnlc6ugmtbSdlG8ggUplNkzwn3Y4=; b=MOv+5dbu5grNbmnfCwypMwiXeECCXEIDBP6gFWlOpuhs3lAJU5r/HEga/u3x1MZUZu TW2WlChh927Mt1QAX1ov15WCAO2prsPok+5B6D0spdt7MFwre0Z/MkFQsNkrT/n4TlAW blG5vG+lefrkauh+l54NjQut0wp824dneAJ7X0SsX38OV9qb6ecHJm8O6rPjPtWwZD61 qE8LT8qNoUCbV/4XZj5lYL4p6w+YPsCL6AFaUAY6W5AjZ0ZKZCUEUUs05Epa8FPsIKxq lps2NtV3VNKJeafuAxaVL4JS1ceYAFfDD8CRXv980ZZTXL78Wlbhfw4OWa9FiymafV19 BzOg==
MIME-Version: 1.0
X-Received: by with SMTP id cf15mr28306304wjb.5.1399999513293; Tue, 13 May 2014 09:45:13 -0700 (PDT)
Received: by with HTTP; Tue, 13 May 2014 09:45:13 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 13 May 2014 09:45:13 -0700
Message-ID: <>
From: Martin Thomson <>
To: Silvia Pfeiffer <>
Content-Type: text/plain; charset=UTF-8
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: Tue, 13 May 2014 16:45:22 -0000

On 13 May 2014 00:54, Silvia Pfeiffer <> wrote:
>> The name "createOffer" implies that the SDP delivered as the result of
>> createOffer is the one to use as an offer in negotiation. Looking at the way
>> this mechanism has evolved, this is probably only true anymore if one is
>> prepared to send the offer immediately, and then to trickle ICE candidates.
>> To obtain an SDP to use as an offer in negotiations without trickle ICE, one
>> has to call setLocal, wait for "end of candidates" and then read
>> pc.localDescription.
>> So "createOffer" in fact does not create an offer, but an initial (or
>> updated) local description that is then fed into setLocalDescription to
>> start the ICE gathering.
>> Do you agree with this observation? If you do, shouldn't we rename
>> createOffer to something more generic like "createLocalDescription" or
>> similar? "createOffer" does not create the offer (at least it does not do so
>> in case of non-trickling) but the input to setLocal...
> I agree, the name is very misleading now.

I disagree.  Though I don't find any of this particularly intuitive,
the response to createOffer is still an offer that can be used to
negotiate a session.  The fact that it cannot be used immediately with
some classes of peer is unfortunate, but it's still good for
negotiating with browsers.

So yes, this new createOffer is only good for negotiating with a peer
that supports trickle ICE.  I think that's better than what we had
previously, which is *no idea what the browser was supposed to do*, as
demonstrated by the fact that the only two implementations in
existence did the complete opposite thing.