- 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>
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