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

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

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Sun, 3 May 2015 18:41:47 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D1F91C5@ESESSMB209.ericsson.se>
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.

> - createOffer() will execute, and its promise will resolve
> - addTrack(trackY) will execute, and its promise will resolve
>
> The created offer will not contain trackY.
>
> The only way to get both trackX and trackY into the offer is to assume
> that adding tracks to the description happens in a synchronous part
> executed before the promises start resolving. No such split is described
> in the current document.
>
> We CAN change the document to say that. But why should we?
>
>
>
>
>
> Den 03. mai 2015 13:13, skrev Stefan Håkansson LK:
>> On 30/04/15 23:30, Jan-Ivar Bruaroey wrote:
>>> 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.
>>
>> Personally, I'd be fine with this (most important to me is that we spec
>> it out clearly enough to make all implementations behave in the same,
>> and consistent, way). I guess we have better wording for "the current run".
>>
>>>
>>> I see no reason to conflate the above with what happens after that (but
>>> I'll speak to it since you asked):
>>
>> Perhaps that should be a separate discussion, but I respond further
>> below anyway.
>>
>>>
>>>>>    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.
>>
>> I my original question [a] I said that one possibility is that a
>> snapshot is taken of current RTPSenders - meaning that any new
>> senders/tracks or any fiddling with their settings would not be taken
>> into account.
>>
>> I don't know if that makes sense or not. Another possibility could be
>> that when createOffer is eventually run it takes the senders (and their
>> settings) at that time into account.
>>
>> [a] https://lists.w3.org/Archives/Public/public-webrtc/2015Apr/0135.html
>>
>>>
>>> .: Jan-Ivar :.
>>>
>>> [1] https://github.com/w3c/webrtc-pc/pull/222
>>>
>>
>>
>
>
>
Received on Sunday, 3 May 2015 18:42:14 UTC

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