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

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