Thanks for the mediasoup update that more accurately identifies the failed state of a transport!
Now… with a failed transport, I’m unsure of the best approach and would like to ask for some clarity. I’ll do my best here to stick to mediasoup and not webrtc questions.
Let me start with the things I understand.
A transport will recover from a disconnected state ‘automatically’ if the disruption is less than 15 seconds, depending on the browser.
A transport will enter the failed state after 15 seconds of no network
Conducting a server-side then client-side re-ice will ‘fix’ the connection, but its better to understand the underlying issue than to skip it with re-ice.
A transport can be closed/cleared and a new transport made on a failure, but like re-ice, skips the underlying problem.
Reloading the browser on failed transport state will clear everything back to the start, but again, skips the underlying issue.
Is it possible to re-use a failed transport, or recover from failed transport state? The ‘connect’ event is only fired once, even after failed state. If I call produce on the transport, it will act like it succeeds, but the transport remains failed. Is there a method I am overlooking that will re-establish the connection using the data it used to connect the first time? Or maybe a reconnected event that gets thrown instead of the connected event when there is a re-try on the transport?
ICE connection state: new => checking => connected => disconnected
Connection state: new => connecting => connected => disconnected => failed
Signaling state: new => have-local-offer => stable => have-local-offer => stable
Is there a different technique I have not considered perhaps?
Does conducting a re-ice on failed transport fixed the transport connection and makes the stream to flow again?
As far as I have experimented whenever a transport is gone to failed state then there is no way to reuse that same transport. So what I do is whenever a transport is failed then I close that transport completely and then create new transport and produce/consume from that new transport again.
But what you are saying is opposite, you are saying that you are able to recover the transport from failed state after re-ice? What do you mean by that? If you are able to recover that transport with re-ice then all is good what is the issue?
The issue is that resetting the ice only solves the problem because it triggers other events in the chain that solve the error. In my thinking, it would be better to know the error state and have a routine for recovering from it directly instead of as a chain reaction as in the re-ice. I suppose you could call that a philosophical problem LOL
In my understanding, the re-ice would only really need to be used if the mediasoup server changed is announce IP address somehow or another.
Of course. It just contains local DTLS parameters that do not change despite ICE fails or reconnects.
Other than that, Transport emits “connectionstatechange” with the very same values than the PeerConnection so no special rules for mediasoup-client, it just proxies and exposes the native “connectionstatechange” event.
To understand the underlying issue, you will have to dig into server logs to see what is happening but most of the time if transport is getting failed it is because of the network conditions.
And if this is because of network conditions then the only thing you need to do is ‘restartIce’ like after every 10 seconds and when ‘connectionstatechange’ event tells you that it is connected then stop that restartIce process.
This is all so listen for this ‘connectionstatechange’ event, as mentioned by ibc, it should go to ‘connected’ state after successful restartIce:
