WebRTC: simultaneous renegotiation issue

Question

Use Case: three peers are in video chat with other two in same room, server sends a message and all three change mode to audio,

for now, only chrome sup

Answer 1

Since renegotiation is a state-machine, having both sides initiate renegotiation at the same time can collide, and you end up with invalid-state errors. This is called glare.

Your workaround is one way to deal with glare, essentially using signaling to make sure renegotiation is always initiated from the same end (typically the offerer's side).

You say you're still seeing occasional invalid-state errors even with this workaround. Since renegotiation is a round-trip between peers, there's a window of time where if you're also responding to signaling requests for new renegotiation, I suppose you could still get invalid-state errors if you try to renegotiate again too soon.

You can check the pc.signalingState attribute to know what state your peerConnection is in at any time. I would look at that when you receive incoming messages, to see if this is the problem. If it is, I would hold off on renegotiating until your connection is in the "stable" state again. You can use pc.onsignalingstatechange to react to state changes.

Another solution I've heard of (but not tried) to solve glare would be to let peers renegotiate independently, and when they do glare, let the offerer always win. e.g. the answerer would cancel any attempts it was making on receiving an incoming offer (by somehow reverting itself back to its previous stable state), whereas the offerer would ignore any incoming offers during its own attempt.

By the way, renegotiation is supported in Firefox as well now (38+) so you could try it there as well to see if you get the same problems.