W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2015

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Sun, 03 May 2015 22:52:45 +0200
Message-ID: <55468A9D.5080200@alvestrand.no>
To: public-webrtc@w3.org
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

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