W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2020

Re: [webrtc-pc] negotiationneeded may still fire when it shouldn't (#2477)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Tue, 18 Feb 2020 18:22:23 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-587607171-1582050142-sysbot+gh@w3.org>
A basic **solution A** to the first problem may be to introduce yet another internal slot: **[[NegotiationBegun]]**, but setting and clearing it may get messy. And it doesn't address the 2nd.

A **solution B** might solve both: (Collapse the whole algorithm into one _queued-then-chained task_)

 _"Queue a task to [chain](https://w3c.github.io/webrtc-pc/#dfn-chain) the following steps to connection's operations chain:_
 1. _If connection.[[IsClosed]] is true, abort these steps._
 2. _If connection's signaling state is not "stable", abort these steps._
 3. _If the result of [checking if negotiation is needed](https://w3c.github.io/webrtc-pc/#dfn-check-if-negotiation-is-needed) is false, clear the negotiation-needed flag by setting connection.[[NegotiationNeeded]] to false, and abort these steps._
 4. _If connection.[[NegotiationNeeded]] is already true, abort these steps._
 5. Set connection.[[NegotiationNeeded]] to true.
 5. _Fire an event named negotiationneeded at connection."_

This is shorter than before (10 → 6 steps), and still respects all required behaviors, I think.

**Bonus:** solution B may also mitigate https://github.com/w3c/webrtc-pc/issues/2476, since the [check if negotiation is needed](https://w3c.github.io/webrtc-pc/#dfn-check-if-negotiation-is-needed) algorithm now seems guaranteed never to run while JSEP is running in parallel.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2477#issuecomment-587607171 using your GitHub account
Received on Tuesday, 18 February 2020 18:22:27 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:50 UTC