- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 Jun 2017 05:38:01 +0000
- To: public-webrtc-logs@w3.org
Actually, I realized a potential race condition when looking at the example code. Suppose `getUserMedia` leads to `addTrack`, which leads to `negotiationneeded` if the signaling state is `stable`, which leads to `createOffer`, etc. And also, the application is prepared to receive a remote offer, triggering `setRemoteDescription`, `createAnswer`, etc. Now, suppose the remote offer arrives first, and `getUserMedia` finishes *while the `setRemoteDescription` promise is still unresolved*. Then `negotiationneeded` will fire, and the `createOffer` operation will be added to the operations queue after the `setRemoteDescription` operation. Which would lead to an "invalid signaling state" error when `setLocalDescription(offer)` is called later. I think. @jan-ivar, can you confirm? In short: It's not quite enough to say "abort these steps if the signaling state isn't `stable`". We really would need to do something like "abort these steps if the signaling state isn't `stable` *or the operations queue isn't empty*". Then, we'd also need to move the delayed "negotiation needed?" check from "when applying a description transitions the signaling state to `stable`" to "when the last operation is removed from the operations queue and the signaling state is `stable`". -- GitHub Notification of comment by taylor-b Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1332#issuecomment-306691874 using your GitHub account
Received on Wednesday, 7 June 2017 05:38:08 UTC