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