In mediasoup, when restartIce is called on a Consumer Transport that uses TCP, the transport frequently transitions into the failed state and cannot recover.
The same restartIce call on a Producer Transport over TCP works as expected. Additionally, if the transport uses UDP (either for Producer or Consumer), restartIce succeeds without entering the failed state.
This phenomenon is specific to the combination of Consumer role + TCP transport.
This is an unfortunate side effect of how ICE TCP works and the fact that mediasoup-client uses separate transport for sending and receiving. When performing ICE restart in a TCP receive transport, we cannot call pc.createOffer(iceRestart: true) because we need that the SDP offer is always generated by the remote (mediasoup server) and hence we need to initiate ICE restart in server side so the browser reacts to it by closing the current TCP connection, and when that happens the ICE state machine in mediasoup server moves to DISCONNECTED status. You can solve it by NOT calling transport.close() in mediasoup server when transport “icestatechange” event happens if the new state is “disconnected”, but only do this if there is an ongoing ICE restart in progress.
In short, that’s how it all works. TCP vs UDP rules.
For most setups, the client detection of ICESTATE is best and both failed/disconnect don’t represent a user’s true state on the service. User could be still connected and broadcasting, could be a you issue, a them issue a bunch of fun stuff in the network popping off.
For simplicity just assume both failed/disconnect are a means to request new ice from client for that stream, or wait a little while. You may automate this for client to request new ICE after response and wait till calling again to keep system underwhelmed or click to refresh options all sorts.
We typically base the user state off their chat connection, or failure to report back (ping/pong) and all sorts so if those aren’t firing off then we can’t assume the disconnect state of ICESTATE is true, maybe for us but not everyone else viewing!
Hope this helps you think about it, base any trueness off user presence however you keep track and destroy it when they disconnect properly from the server. Media servers are not good indicators if you want to persist and recover nicely.