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

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

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Thu, 30 Apr 2015 12:10:17 -0400
Message-ID: <554253E9.2030502@mozilla.com>
To: Justin Uberti <juberti@google.com>
CC: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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?

.: 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 16:10:48 UTC

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