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

"Rauschenbach, Uwe (NSN - DE/Munich)" <uwe.rauschenbach@nsn.com> Tue, 13 May 2014 03:44 UTC

Return-Path: <uwe.rauschenbach@nsn.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 893661A0823 for <rtcweb@ietfa.amsl.com>; Mon, 12 May 2014 20:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mQtaV9Bygut for <rtcweb@ietfa.amsl.com>; Mon, 12 May 2014 20:44:55 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 232A91A0821 for <rtcweb@ietf.org>; Mon, 12 May 2014 20:44:54 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s4D3imAX030549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 May 2014 03:44:48 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s4D3ilDK018552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 05:44:47 +0200
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 13 May 2014 05:44:47 +0200
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.67]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0181.006; Tue, 13 May 2014 05:44:47 +0200
From: "Rauschenbach, Uwe (NSN - DE/Munich)" <uwe.rauschenbach@nsn.com>
To: ext Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [rtcweb] When are ICE candidates added to the SDP
Thread-Index: AQHPbXQT9TjLMQgt4EuqU8TdRTYSi5s8fWuAgABEhwCAAR2aIA==
Date: Tue, 13 May 2014 03:44:46 +0000
Message-ID: <56C2F665D49E0341B9DF5938005ACDF82F807F@DEMUMBX005.nsn-intra.net>
References: <CABcZeBNUTf42tS9FrjS9Q6Zk8LBkhpKOR1z2v8MHoeNEUf93Mw@mail.gmail.com> <56C2F665D49E0341B9DF5938005ACDF82F69E8@DEMUMBX005.nsn-intra.net> <CABcZeBO1Z0SnTUixjV09ekw-mb=YyzHjOV-b-MMUZy7sx32h6Q@mail.gmail.com>
In-Reply-To: <CABcZeBO1Z0SnTUixjV09ekw-mb=YyzHjOV-b-MMUZy7sx32h6Q@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.109]
Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF82F807FDEMUMBX005nsnintr_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 23170
X-purgate-ID: 151667::1399952688-00001326-228B9C78/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NttzvkV-yBiTrNUoIUZmliZ0N6I
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: Tue, 13 May 2014 03:44:58 -0000

On Mon, May 12, 2014 at 2:03 AM, Rauschenbach, Uwe (NSN - DE/Munich) <uwe.rauschenbach@nsn.com<mailto:uwe.rauschenbach@nsn.com>> wrote:
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.

So, my understanding was that we had agreed that no candidates would
be available in the first CreateOffer() no matter how many candidates were
in the pool.

The intent of this message is to ask if that is useful.

-Ekr

Thanks for clarifying. As long as the candidates are in the SDP that can be obtained via the API after the “end of candidates”, I think non-trickling applications should be OK.
I was concerned they would not end up in the SDP anymore.

-- Uwe

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,
Uwe


From: rtcweb [mailto:rtcweb-bounces@ietf.org<mailto:rtcweb-bounces@ietf.org>] On Behalf Of ext Eric Rescorla
Sent: Monday, May 12, 2014 8:52 AM
To: rtcweb@ietf.org<mailto:rtcweb@ietf.org>
Subject: [rtcweb] When are ICE candidates added to the SDP

See: https://github.com/rtcweb-wg/jsep/issues/11

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.

-Ekr