Here’s the scenario of change in webrtc connection state before Chrome 76:
connecting > connected > block transport > disconnected > failed
Tested on both Chrome 76 and 77, the ‘failed’ state never is met.
Unfortunately it’s a Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=982793
I was using ‘failed’ state to establish a new connection. 
You can call transport.restartIce() in both server and client to provide the PeerConnection with new ICE username and password. You should not need it unless network changes. Not sure if this will re-enable the PeerConnection after ICE “failed” event (which is a bit painful).
transport.restartIce() works well on Chrome but not in Firefox and I have to close the transport and establish a new one.
That’s supposed to be fixed in Firefox modern versions (maybe not yet in stable), I reported it and they fixed it.
With this bug restartIce() is completely useless since the ‘failed’ state is never met after unsuccessful ICE restart and it stucks at ‘disconnected’ state. 
It’s not useless. You do need to call restartIce() if your network local IP changes or you move from Wi-Fi to 4G or vice-versa. The fact that you depend on the connectionstatechange is a different history 
Sorry I didn’t mean it. I’m just talking about the topic subject, recovering from lost connection. 
I hope you can also detect disconnection via WebSocket event.
That’s possible but not accurate. I ended up using a timeout after the disconnection and consider it as failed.
I think you should blame Firefox in this case. We cannot be responsible of every bug in browsers.
Absolutely not mediasoup fault, I’m just sharing my test results. 
1 Like