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.