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 supports renegotiation, so for firefox, i just close the connection and create new peer connection, but after I check both sides are chrome and change mode,

• If I am changing mode of only one peer at a time, it works smoothly.
• but when, message comes from server, both peers try to renegotiate simultaneously and it didn't work, I got something like wrong state : STATE_SENTINITIATE
• To handle that problem, I did a workaround where, whenever peerconnection has to renegotiate, it checks if it is the caller
  • if yes, it goes ahead with renegotiation.
  • else(if it is answerer), it would change the offered stream and signal the caller to renegotiate.
• The above workaround works for few renegotiations, but for some cases, it throws error at setting local description on the answerer's side, claiming wrong state to be either STATE_INPROGRESS or STATE_SENTACCEPT.

how do I resolve this issue?

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.