- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Thu, 30 Apr 2015 12:10:17 -0400
- 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