- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Sun, 03 May 2015 18:04:29 +0200
- To: public-webrtc@w3.org
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 - 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 16:05:00 UTC