W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2015

Re: Question: how should addTrack work in relation to createOffer et. al.?

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 30 Apr 2015 17:35:14 +0000
To: Jan-Ivar Bruaroey <jib@mozilla.com>, Justin Uberti <juberti@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D1F8480@ESESSMB209.ericsson.se>
On 30/04/15 18:10, Jan-Ivar Bruaroey wrote:
> On 4/30/15 12:52 AM, Justin Uberti wrote:
>> Obviously I prefer a deterministic outcome. But I think it would be
>> better to not include trackY in the createOffer output - it seems
>> unintuitive.
>
> I think we're forgetting that createOffer is queued. By (sometimes *)
> queueing createOffer until later, we've made a choice about the state
> createOffer should run in, and it's not the current state!
>
> As a result, copying anything from the current state seems
> counter-intuitive to me (which properties get copied and which don't?)
>
> In the following example, createOffer runs in stable state, with both
> tracks added prior:
>
> function received(offer) {
>     pc.setRemoteDescription(offer);
>     pc.createAnswer().then(answer => {
>       pc.setLocalDescription(answer);
>
>       pc.addTrack(trackX);
>       pc.createOffer(); // queued until stable state!
>       pc.addTrack(trackY);
>     });
> }
>
>
> Excluding trackY here would be a feat, as it gets added way before
> createOffer runs (in have-remote-offer). Also, why want that?

I agree. And in this example, createOffer would be queued until 
pc.setLocalDescription(answer) resolves as well, right? (And ideally I 
guess the app should make sure that setLocal(answer) didn't fail before 
moving on with adding tracks and making a new offer).

>
> .: Jan-Ivar :.
>
> *) "sometimes" is Zalgo. See
> https://github.com/oren/oren.github.io/blob/master/posts/zalgo.md
>
> https://github.com/w3c/webrtc-pc/pull/222 is about removing "sometimes".
>
>
Received on Thursday, 30 April 2015 17:35:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC