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

"Rauschenbach, Uwe (NSN - DE/Munich)" <> Mon, 12 May 2014 09:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A651F1A0537 for <>; Mon, 12 May 2014 02:03:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a4Wa3mmxO4bT for <>; Mon, 12 May 2014 02:03:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E5C691A0552 for <>; Mon, 12 May 2014 02:03:43 -0700 (PDT)
Received: from ([]) by (8.14.3/8.14.3) with ESMTP id s4C93aDB029744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 May 2014 09:03:36 GMT
Received: from ([]) by ( with ESMTP id s4C93ZJo029954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 11:03:35 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 12 May 2014 11:03:35 +0200
Received: from ([]) by ([]) with mapi id 14.03.0181.006; Mon, 12 May 2014 11:03:35 +0200
From: "Rauschenbach, Uwe (NSN - DE/Munich)" <>
To: ext Eric Rescorla <>, "" <>
Thread-Topic: [rtcweb] When are ICE candidates added to the SDP
Thread-Index: AQHPbXQT9TjLMQgt4EuqU8TdRTYSi5s8fWuA
Date: Mon, 12 May 2014 09:03:34 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF82F69E8DEMUMBX005nsnintr_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-size: 14250
X-purgate-ID: 151667::1399885416-00001326-8D6B11A8/0/0
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: Mon, 12 May 2014 09:03:47 -0000

Hi Eric, all,

Is the consequence of “always trickle” that ICE candidates have to be added by non-trickling applications via SDP manipulation?
I consider this indeed quite inconvenient for non-trickling applications.

A way out would be that the SDP always contains the candidates collected so far (as currently defined in the JSEP snippet cited),
or that a switch in the API allows an application to configure the behavior when adding ICE candidates.

Kind regards,

From: rtcweb [] On Behalf Of ext Eric Rescorla
Sent: Monday, May 12, 2014 8:52 AM
Subject: [rtcweb] When are ICE candidates added to the SDP


Section 3.4 reads:

When a new ICE candidate is available, the ICE Agent will notify the
application via a callback; these candidates will automatically be
added to the local session description. When all candidates have
been gathered, the callback will also be invoked to signal that the
gathering process is complete.

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. Consider the following sequence of events.

0. pc = new RTCPeerConnection();
1. pc.AddStream(stream);
2. pc.CreateOffer();
3. CreateOffer callback fires with offer A, and you call SetLocalDescription();
4. onicecandidate fires with candidate X.
5. pc.CreateOffer()
6. CreateOffer callback fires with offer B.
7. onicecandidate fires with null.

So, in London, I think we agreed that offer A would have no candidates.
The above text implies that if you were to examine localdescription prior
to step #5 or at step #7 it would contain candidate X, and probably that offer B would
also contain candidate X.

Note that it's quite inconvenient for non-trickle applications to never
have any candidates in the SDP, especially after gathering is completed
at step #7. However it also seems kind of inconsistent to only update the
candidates after SetLocal() has been called.