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

On 03/05/15 22:55, Harald Alvestrand wrote:
> 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 :-(

Perhaps add/removeTrack should be part of the same queue.

(I was thinking about a more radical proposal: remove the queue and 
force the application to wait for promises to resolve before moving on. 
THis would be more in line with the vein of JSEP ("move the state 
handling to the app") IMO. But I think there are cases that makes this a 
bad idea.)

Received on Monday, 4 May 2015 06:40:17 UTC