Re: [rtcweb] When are ICE candidates added to the SDP
"Rauschenbach, Uwe (NSN - DE/Munich)" <uwe.rauschenbach@nsn.com> Tue, 13 May 2014 03:47 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 2A6361A0823 for <rtcweb@ietfa.amsl.com>; Mon, 12 May 2014 20:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0pFgAzoCHsip for <rtcweb@ietfa.amsl.com>; Mon, 12 May 2014 20:46:59 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA461A0821 for <rtcweb@ietf.org>; Mon, 12 May 2014 20:46:59 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s4D3klW5013785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 May 2014 03:46:47 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s4D3kk8M028527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 05:46:46 +0200
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 13 May 2014 05:46:46 +0200
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.67]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0181.006; Tue, 13 May 2014 05:46:45 +0200
From: "Rauschenbach, Uwe (NSN - DE/Munich)" <uwe.rauschenbach@nsn.com>
To: ext Martin Thomson <martin.thomson@gmail.com>, Harald Alvestrand <harald@alvestrand.no>
Thread-Topic: [rtcweb] When are ICE candidates added to the SDP
Thread-Index: AQHPbXQT9TjLMQgt4EuqU8TdRTYSi5s8fWuAgABEhwCAABQtgIAAF/KAgAAP34CAAC45AIAAsTXg
Date: Tue, 13 May 2014 03:46:45 +0000
Message-ID: <56C2F665D49E0341B9DF5938005ACDF82F8091@DEMUMBX005.nsn-intra.net>
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> <5370F349.7050006@alvestrand.no> <CABkgnnWfAYTUBrrbu=m_j0=S3uBw4Cf7PBDi3ZmAGHsUMBX1kQ@mail.gmail.com>
In-Reply-To: <CABkgnnWfAYTUBrrbu=m_j0=S3uBw4Cf7PBDi3ZmAGHsUMBX1kQ@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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: 10080
X-purgate-ID: 151667::1399952808-00001564-32433976/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/k-gtP3FVfqFnXvZDoVEWp768NKg
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:47:02 -0000
Hi Martin, Ok with your proposed flow as long as the SDP obtained in step 6 via the API contains the candidates (currently the W3C spec states they are included when using pc.localDescription). A question on step 6 and your statement below the sequence: What would be the difference between an SDP created by pc.createOffer in step 6 and one obtained by getting pc.localDescription in step 6? Why do you consider multiple pc.createOffer calls nasty? Thanks, Uwe > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Martin > Thomson > Sent: Tuesday, May 13, 2014 3:59 AM > To: Harald Alvestrand > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] When are ICE candidates added to the SDP > > Why not: > > 1. pc.createOffer(...) > 2. success callback fires (0 candidates) > 3. pc.setLocalDescription(offer) > 4. onicecandidate fires some number of times > 5. onicecandidate fires with a null candidate > 6. send pc.localDescription (as opposed to the original offer) > > No need to run multiple rounds of createOffer or anything nasty like > that. > > Note that we don't have an onicegatheringstatechange event that would > let us monitor that state more directly, but the actual code cost is > identical either way. > > > On 12 May 2014 09:14, Harald Alvestrand <harald@alvestrand.no> wrote: > > On 05/12/2014 05:17 PM, Eric Rescorla wrote: > > > > > > > > > > On Mon, May 12, 2014 at 6:51 AM, Harald Alvestrand > <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> 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] On Behalf Of ext Eric > >>> Rescorla > >>> Sent: Monday, May 12, 2014 8:52 AM > >>> To: 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 > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > >> > >> > >> -- > >> Surveillance is pervasive. Go Dark. > >> > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > 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