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

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 11:13:40 UTC