- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Mon, 05 Jun 2017 17:52:33 +0000
- To: public-webrtc-logs@w3.org
> So it is not clear when the condition applies for connection's [[needNegotiation]] slot was true both before and after the session description update. It's intended more to handle cases like this: 1. Data channel or track added. "negotiation-needed" flag set. 2. Offer created/sent in response to `negotiationneeded` event. 3. Something happens that requires renegotiation before the answer is received (like adding a track). 4. Answer received. Still needs more negotiation, so `negotiationneeded` fires again. 5. New offer created in response to second `negotiationneeded`. Assuming no more tracks are added, this offer/answer exchange finishes without requiring more negotiation. I agree that there should be an explanation for how `negotiationneeded` is intended to be used (as shown in the examples below). But, if used as intended, I don't see how there could be inconsistencies/race conditions. -- GitHub Notification of comment by taylor-b Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1332#issuecomment-306256980 using your GitHub account
Received on Monday, 5 June 2017 17:52:39 UTC