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 17:30:20 -0400
Message-ID: <55429EEC.8080304@mozilla.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 4/30/15 12:48 PM, Jan-Ivar Bruaroey wrote:
> On 4/30/15 2:42 AM, Stefan Håkansson LK wrote:
>> On 24/04/15 17:38, Jan-Ivar Bruaroey wrote:
>>>     var senderX = pc.addTrack(trackX);
>>>     pc.createOffer();
>>>     var senderY = pc.addTrack(trackY);
>>>     // Both trackX and trackY will always be in the offer.
>> How does that work?
> See my answer to Justin's post in this thread (tl;dr because 
> createOffer() is queued to run later).

To reiterate, I think the important guarantee is the one above, which 
would extend to the end of the current run. This would be deterministic, 
and today we don't have that.

I see no reason to conflate the above with what happens after that (but 
I'll speak to it since you asked):

>>   And what determines if trackY is represented in the
>> offer or not (in the example it is added right after createOffer is
>> called, but there can be many scenarios here, like a bit later or in
>> another context)?

If trackY is added later or in another context, then one /could/ 
determine whether it is before the queued createOffer starts:

  * If pc.signalingState == stable, then createOffer will start after
    the current run completes (it's on the promise micro-task queue),
    before the next event on the main task queue.

  * If pc.signalingState != stable, then use pc.onsignalingstatechange.

But ultimately, once createOffer has started it runs asynchronously, so 
there's a window of undeterminism there, but neither this PR [1] nor 
your original question was about solving that, I believe.

.: Jan-Ivar :.

[1] https://github.com/w3c/webrtc-pc/pull/222
Received on Thursday, 30 April 2015 21:30:51 UTC

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