Is there anyway I can listen to ‘connectionstatechange’ event on transport on server side?
I was able to listen on this event on client side but couldn’t find a way to do the same on server side.
I am working on re-connectivity part of the call where I need to check when a participant’s peer connection state is changed to ‘failed’ and then trigger the re-connection part of my code. I was able to do this on client side.
But now I need to show ‘connecting…’ on that disconnected participant’s video box for that I need something on server which can tell me that the connection for that specific transport of participant is lost. But couldn’t find anyway so far may be because mediasoup is ice-lite as mentioned here:
One way I can think of is via socket ‘disconnected’ event, so whenever a participant’s ‘disconnected’ event is fired on socket then I will wait for ‘7 seconds’ for ‘connected’ event on socket, as peer state is changed to ‘failed’ around 7 seconds after ‘disconnected’ state if not auto reconnected, if not received then I will emit ‘reconnecting’ event to all other participants and on that event on client side I will show ‘connecting…’ for that participant’s video box.
Web Socket Server (Chat/Signaling):
Your Web Sockets will know if a user had closed connection or had timed-out (disconnected via heartbeat).
These two states should generally be treated the same and end with user data/transport termination as well as a message to all the other users that someone left (additional clean-up if necessary).
Broadcasts (Producers):
This is best handled both server-sided and client-sided when handling connection issues.
Server Sided: You monitor for DTLS state connected (ONLY). When user broadcast comes in you set a timeout of several seconds when the transport is created. If DTLS state becomes connected you delete the timeout otherwise in several seconds the transport will be destroyed and the user will be thrown an error that stream was unavailable, try again.
Client Sided: The user will monitor connectionstatechange for connected and disconnected, if it becomes disconnected there will be attempts to recover automatically however after several seconds if connection does not restore send a request to restart ice. This mechanism can be automated or manual (by click for instance).
DTLS state is important to monitor for transports of producers as there can at times be issues delivering the devices. The timeout ensures that the user is closed and informed properly of their delivery issue. As long as state is connected at least once the stream is AOK and we can for most part recover as explained in the notes.
Viewers (Consumers):
This is best handled client-sided when handling connection issues.
Client Sided: The user will monitor connectionstatechange for connected and disconnected, if it becomes disconnected there will be attempts to recover automatically however after several seconds if connection does not restore send a request to restart ice. This mechanism can be automated or manual (by click for instance).
There’s not much of a need to monitor a transport for consumers DTLS state… We can assume the user will be connected.
This is only applicable when producer is being created but if producer is created already and user’s network goes off then connection fails then this DTLS state on server side will still be in ‘connected’ state as far I have checked. So right now there is no way on server side to check whether transport gets disconnected or not.
Restart Ice doesn’t work if rtc connection is in ‘failed’ state. So I have to destroy the old transport, producer, consumer and create fresh ones to make the things work.
Yes, you’d only want to just ensure that DTLS is connected at least once to ensure the stream is produced correctly and ready to be consumed that’s all.
The client can better monitor the connectionstate from there on out for any stream including their own and request to restartIce.
You shouldn’t need to monitor the failed state at all. Issues with restarting ice would be a different problem imo.
As for how to restore rtc connection after it goes to ‘failure’ state:
You will have to manually close the transport and it’s producers and consumers and then create a new transport and producers and consumer on top of that to achieve reflow of streams.