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: Sat, 9 May 2015 04:45:51 +0000
To: Jan-Ivar Bruaroey <jib@mozilla.com>, Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D1FE2C9@ESESSMB209.ericsson.se>
On 08/05/15 23:23, Jan-Ivar Bruaroey wrote:
> On 5/8/15 9:43 AM, Stefan Håkansson LK wrote:
>> Trying to summarize this discussion:
>> It seems that there is agreement:
>> * the offer created by createOffer will only take into account the
>> senders (and their respective settings) that exist at the time when
>> createOffer is called - anything that happens after will not be reflected
>> Is this right?
> Not quite I fear. Depends on your definition of "the time when
> createOffer is called".
> Lets call this A:
> Since createOffer is queued in the operations chain, what I realized in
> this thread, and agree is needed at a minimum, is that, to avoid
> non-determinism, createOffer must take into account the senders that
> exist at the time when it comes off the queue and is executed, rather
> than any time later.
> This would simply require wording under createOffer, ideally as steps in
> a processing model, which is sorely needed anyways. It would not require
> createOffer-specific changes to the description of the operations chain.
> It would not change much else, which means it still requires accepting
> PR 222 to fix the "sometimes y is added, sometimes it is not" surprise.
> E.g. for pc.addTrack(X); pc.createOffer(); pc.addTrack(Y) the offer
> would always contain X and Y (regardless of what's on the queue).
> I agree with Martin where he says [1]: "One thing that I like about this
> is that it removes the synchronous step. Having a function run
> synchronously or asynchronously depending on something that has happened
> elsewhere is a very good way to ensure that surprises happen. Allowing
> the current execution context to run to completion before executing any
> potentially asynchronous operation is always better than having surprises."
> (Martin, sorry for quoting you here, but I thought it was a good point
> that got lost in the older PR [1]).
> I could see us doing this. I suspect it is not what you meant.
> Lets call this B:
> I think what you mean is have createOffer take into account the senders
> that exist at the time when the content JS calls createOffer. The only
> benefit I see to this (and correct me if I'm wrong) would be to try to
> have the offer never contain Y in the common (not queued) case, and
> ignore the non-common (queued) case, since essentially "people, quit
> doing that!"
> It seems to me this would require createOffer-specific changes to the
> description of the operations chain (not to mention the other methods we
> haven't talked about). And you still have the "sometimes y is added,
> sometimes it is not" surprise.
> You would therefore not want PR 222 here.
> Lets call this C:
> Same as B, plus rip out the operations queue, and have methods throw if
> called at the wrong time. This removes the need for the queue and solves
> the "offer never contains Y" problem that way.
> I think I like A and C the best.

Thanks for outlining the options.

I interpreted the conversation as that you and Harald had agreed on B, 
and that is what I meant. That does not seem to be the case :).

I'd be fine with any of the models, I'm just after clarity.

> .: Jan-Ivar :.
> [1] https://github.com/w3c/webrtc-pc/pull/165
Received on Saturday, 9 May 2015 04:46:19 UTC

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