Re: [rtcweb] When are ICE candidates added to the SDP
Harald Alvestrand <harald@alvestrand.no> Mon, 12 May 2014 16:14 UTC
Return-Path: <harald@alvestrand.no>
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 ABBDE1A033E for <rtcweb@ietfa.amsl.com>; Mon, 12 May 2014 09:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level:
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 Vte9LdLQ2b8o for <rtcweb@ietfa.amsl.com>; Mon, 12 May 2014 09:14:12 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 090831A0743 for <rtcweb@ietf.org>; Mon, 12 May 2014 09:14:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3903A7C3598; Mon, 12 May 2014 18:14:05 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEX4I7azVxYW; Mon, 12 May 2014 18:14:03 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 479407C3582; Mon, 12 May 2014 18:14:03 +0200 (CEST)
Message-ID: <5370F349.7050006@alvestrand.no>
Date: Mon, 12 May 2014 18:14:01 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
References: <CABcZeBNUTf42tS9FrjS9Q6Zk8LBkhpKOR1z2v8MHoeNEUf93Mw@mail.gmail.com> <56C2F665D49E0341B9DF5938005ACDF82F69E8@DEMUMBX005.nsn-intra.net> <CABcZeBO1Z0SnTUixjV09ekw-mb=YyzHjOV-b-MMUZy7sx32h6Q@mail.gmail.com> <5370D1E3.7040809@alvestrand.no> <CABcZeBNgJ_DP6XQ2L0fdrFEE-YWwuKCjq4f-X5cD6+pK3un8Hw@mail.gmail.com>
In-Reply-To: <CABcZeBNgJ_DP6XQ2L0fdrFEE-YWwuKCjq4f-X5cD6+pK3un8Hw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------060805070600050203030001"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LD0KhvdECgL0K_JaZZsAqj-IwMg
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: Mon, 12 May 2014 16:14:25 -0000
On 05/12/2014 05:17 PM, Eric Rescorla wrote: > > > > On Mon, May 12, 2014 at 6:51 AM, Harald Alvestrand > <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote: > > On 05/12/2014 02:39 PM, Eric Rescorla wrote: >> >> >> >> 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. > > If an application is written as > > 1) CreateOffer() > 2) wait for the end of candidates callback > 3) negotiate > > then I would think it might have trouble if all the candidates are > present in the SDP, and therefore no callbacks were called. > Solution: Always fire the end of candidates callback after calling > the success callback, even if all candidates are in the SDP already. > > > So you mean: > > 1. CreateOffer() > 2. success callback fires. > 3. SetLocal() > 4. onicecandidate(...) > 5. onicecandidate(null) > > Then later (w/ no changes to the MSTs) > > 6. CreateOffer() > 7. success callback fires > 8. SetLocal (????) > 9. onicecandidate(null) > > I believe this would be a change to the W3C API (not that this is > necessarily bad) Something like that, yes. Or in more detail, for a call requiring 2 candidates: 1. CreateOffer() 2. success callback fires (1 candidate present) 3. SetLocal() 4. onicecandidate(...) 5. onicecandidate(null) Then later (w/ no changes to the MSTs) 6. CreateOffer() 7. success callback fires (2 candidates present) 8. SetLocal () 9. onicecandidate(null) Then still later (after having done something that requires a 3rd candidate): 10. CreateOffer() 11. successCallback fires (2 candidates present) 12. SetLocal() 13. onicecandidate(...) 14. onicecandidate(null) If we don't have the null onicecandidate in case 2 (step 9), it gets hard to support case 3 (step 12-14). > > -Ekr > > >> >> -Ekr >> >> 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 >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org <mailto:rtcweb@ietf.org> >> https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org <mailto:rtcweb@ietf.org> > https://www.ietf.org/mailman/listinfo/rtcweb > >
- [rtcweb] When are ICE candidates added to the SDP Eric Rescorla
- Re: [rtcweb] When are ICE candidates added to the… Rauschenbach, Uwe (NSN - DE/Munich)
- Re: [rtcweb] When are ICE candidates added to the… Iñaki Baz Castillo
- Re: [rtcweb] When are ICE candidates added to the… Eric Rescorla
- Re: [rtcweb] When are ICE candidates added to the… Harald Alvestrand
- Re: [rtcweb] When are ICE candidates added to the… Eric Rescorla
- Re: [rtcweb] When are ICE candidates added to the… Harald Alvestrand
- Re: [rtcweb] When are ICE candidates added to the… Martin Thomson
- Re: [rtcweb] When are ICE candidates added to the… Rauschenbach, Uwe (NSN - DE/Munich)
- Re: [rtcweb] When are ICE candidates added to the… Rauschenbach, Uwe (NSN - DE/Munich)
- Re: [rtcweb] When are ICE candidates added to the… Eric Rescorla
- Re: [rtcweb] When are ICE candidates added to the… Martin Thomson
- Re: [rtcweb] When are ICE candidates added to the… Martin Thomson
- Re: [rtcweb] When are ICE candidates added to the… Rauschenbach, Uwe (NSN - DE/Munich)
- Re: [rtcweb] When are ICE candidates added to the… Silvia Pfeiffer
- Re: [rtcweb] When are ICE candidates added to the… Martin Thomson
- Re: [rtcweb] When are ICE candidates added to the… Cullen Jennings
- Re: [rtcweb] When are ICE candidates added to the… Eric Rescorla
- Re: [rtcweb] When are ICE candidates added to the… Justin Uberti
- Re: [rtcweb] When are ICE candidates added to the… Harald Alvestrand
- Re: [rtcweb] When are ICE candidates added to the… Iñaki Baz Castillo
- Re: [rtcweb] When are ICE candidates added to the… Sergio Garcia Murillo
- Re: [rtcweb] When are ICE candidates added to the… Iñaki Baz Castillo