W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > June 2017

Re: [webrtc-pc] Inconsistencies and race conditions in updating negotiation-needed flag

From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
Date: Wed, 07 Jun 2017 05:38:01 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-306691874-1496813880-sysbot+gh@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

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:44 UTC