Mediasoup SFU not emiting close event on transport when client transport closes

mediasoup libraries
1

I am not getting close event on transport in SFU when my transport on client side disconnects. However in debug logs I get -

2022-01-05 16:39:46	2022-01-05T11:09:46.715Z mediasoup:WARN:Channel [pid:43] RTC::DtlsTransport::OnSslInfo() | received DTLS warning alert: close notify
2022-01-05 16:39:46	2022-01-05T11:09:46.715Z mediasoup:WARN:Channel [pid:43] RTC::DtlsTransport::Reset() | resetting DTLS transport
2022-01-05 16:39:46	2022-01-05T11:09:46.715Z mediasoup:WARN:Channel [pid:43] RTC::WebRtcTransport::OnDtlsTransportClosed() | DTLS remotely closed

Does mediasoup not emit event on dtls transport close? If it does, then what is the event message I should listen to in transport?

2

The API documentation will tell you which event to listen. However DTLS “close” event may happen or not depending on whether the client had a chance to send DTLS CLOSE packet or not so you should not rely on it.

3

Already gone through doc. here it says that close event will emit whenever transport gets closed for whatever reason.

So does this not include that client transport have been disconnected so SFU transport should also close itself and emit “close” event?

Can you please tell me better way to know that if client transport is disconnected?

4

Yes.

Don’t rely on your media servers to tell you, that will report false positives when a user lags or has issues connecting. Instead rely on your signaling setup to know the state of which a user is in and is wanting of the server.

So if it’s a chat server (ran on websockets), you would determine through that signaling method if a user is requesting, connecting, connected, producing a broadcast and if they left the room, stopped broadcasting/etc.

No easy answer but you shouldn’t rely on the media servers in that regards.

You could however and I use this method is, if a user has producing glitches occur; you could tell the transport to self destruct if no connection was made initially in the first 15 seconds or something. This helps my broadcasters know if they have a glitch in their video/audio capture through chrome/FF tasks. This just tells the user their producing/consumption could not occur right now, re-try type deal.

For re-starting ICE, I only allow for it if the user has established a DTLS state connected at least once, otherwise it’s a failed transport connection. All this managed at the chat server level for myself however. With ICE restarting allowed, I limit it big-time to like 1 call a user every 20-30 seconds+; users lagging will refresh if it’s so bad or wait it out so I don’t spam that.

Good luck.

5

Thanks @BronzedBroth for the detailed answer. Your method is indeed very helpful.

However I think SFU should send the state if the client transport is disconnected or SFU should do some ping pong like thing with transports. And if timeout hit it should emit the event with timeout hit message or something like that.

6

DTLS connection state will reveal all, but as suggested you should not be using this to accurately determine what it is the user is requesting. Sometimes the user may not be requesting anything and DTLS state changes, so it’s not reliable at all in those regards.

If you had a user lag big time, and DTLS state shows disconnected you could be tricked into thinking they left the chat or something invalid.

It’s best to reference the DTLS to assist connections that need help, as disconnected can mean anything. Knowing that the chat server will inform the media server of users leaving or closing broadcasts we can assume disconnected for us means error(if first connect is not made) or more ice if we had connected already prior.

1 Like