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

On 05/03/2015 08:41 PM, Stefan Håkansson LK wrote:
> On 03/05/15 18:07, Harald Alvestrand wrote:
>> The problem we're facing is caused by an interesting omission:
>> None of addTrack or createOffer specifies what, if any, action is
>> performed in a synchronous part before the asynchronous part starts.
>> The text says
>> The general idea is to have only one among createOffer,
>> setLocalDescription, createAnswer and setRemoteDescription executing at
>> any given time. If subsequent calls are made while one of them is still
>> executing, they are added to a queue and processed when the previous
>> operation is fully completed.
>> This *seems* to indicate that every piece of the method is executed in
>> the asynchronous part - including the adding of tracks to the list that
>> createOffer reads from.
>> That means that Jan-Ivar's resolution is simply wrong: If you call
>>>>>>>      var senderX = pc.addTrack(trackX);
>>>>>>>      pc.createOffer();
>>>>>>>      var senderY = pc.addTrack(trackY);
>> then the following will happen:
>> - the JS will run to completion
>> - addTrack(trackX) will execute, and its promise will resolve
> AFAIK addTrack is synchronous, and there is no promise to resolve 
> (instead a RTPSender is synchronously returned).
> This means to me that Jan-Ivar's resolution can be correct unless we 
> change addTrack.

Ouch. I misread this part. We are changing the tracks structure outside
the operations queue by AddTrack.

I think that's a mistake, but I can't argue that it's not in the spec :-(

Received on Sunday, 3 May 2015 20:53:14 UTC