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

On 4/23/15 8:34 AM, Stefan Håkansson LK wrote:
> The current spec is pretty clear on how addTrack works in isolation:
>
> a RTPSender is synchronously returned.
>
> However, how addTrack relates to related (enqueued) operations is less
> clear.
>
> As an example, for the sequence
>
> var senderX = pc.addTrack(trackX);
> pc.createOffer();
> var senderY = pc.addTrack(trackY);
>
> 1. would track/senderY be represented in the offer in any case?
> 2. if so, would it be consistently represented in the offer or would it
> depend on e.g. queue status?

Sadly, I think this is nondeterministic today because of how our 
operations array is defined [1]: "If the length of the |operations| 
array is exactly 1, execute the function from the front of the queue 
asynchronously."

Meaning the outcome can vary from run to run.

> One way to spec this would be to say that createOffer takes a snapshot
> of the current senders when called, and changes between that snapshot
> and the actual execution of createOffer are not taken into account.

Since JavaScript is a run-to-completion language, another (common?) 
approach would be to queue a (micro) task to execute the asynchronous 
operation, as I've just proposed today here in another thread.

Not only would this unify behavior between when something is on the 
queue vs. when nothing is on the queue, but it would make the following 
deterministic:

   var senderX = pc.addTrack(trackX);
   pc.createOffer();
   var senderY = pc.addTrack(trackY);
   // Both trackX and trackY will always be in the offer.

No copying of state needed.

> Is this the way we should go?
>
> (This relates to github Issue #156 for webrtc)
>
> Stefan

.: Jan-Ivar :.

[1] http://w3c.github.io/webrtc-pc/#operation