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

> 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