Emitted when [object] is closed for whatever reason.
This implies that “whatever reason” means also when closed on server side, so they are being propagated to client side. But on mediasoup :: Communication Between Client and Server, it’s being specified that the application should signal the close, pause, resume and layerschange events. For the latest ones I somewhat understand it, but for close event, I assumed it would be send implicitly inwire because the connection socket gets closed, but reading on the source code there’s nothing that notifies Transport objects that they got closed server side, and for Producer and Consumer they are just only being called when closed on the Transport. More annoying is on Device object, where close event seems to not being emitted at all (maybe I’m looking on the wrong place) although being documented, so I want to ask:
Is the documentation of Mediasoup client API wrong on this topic?
Are Mediasoup client events only emitted due to calls on the client-side objects?
Does I need to propagate the server side events myself? Is there no alternative?
Could some events like close being detected and emitted implicitly by the library? Or is there a technological limitation on RTP that doesn’t allow to do it and we need to use a side channel for them? If not, why are they not propagated?
Then I misunderstood the Mediasoup documentation, I though close event would be automatically emited at least on lost connections too. Is this something that could / should be implemented?
By the way, it’s rather strange that a ‘close’ event is mentioned there for the observer of the Device class, because there is no such a thing. This observer emits only one event - ‘newtransport’.
mediasoup is a ICE Lite server so it doesn’t send ICE Binding requests nor it expects ICE responses for them from endpoints, so there is no way for mediasoup to realize of ICE/network disconnections. This is not accurate since if the ICE goes over TCP then mediasoup does emit “disconnected” on WebRtcTransport, but that’s an exception due to the fact that in TCP we know that. In UDP we don’t. You can, at app level, establish a DataChannel connection between endpoints and mediasoup and make you mediasoup app send “PING” as DC messages to endpoints and assume the transport is closed if “PONG” is not replied by the endpoint after N seconds.
Good point, didn’t though about UDP, I’m too much used to TCP
Sound hack-ish, but I like it. Does DataChannels / SCTP connections protocol a ping message the same way as WebSockets has, or must it be implemented at application level too?
The Device class is just a holder of the capabilities data, which is used to create the transports. It does not “connect” anywhere itself, so it is not even right to say that the ‘close’ event is not implemented, because there is nothing to implement.
