Understanding Mediasoup

Deployment & Scalability
1

Can you help me understand the connection cycle in mediasoup?

I have successfully practiced creating a server using express.js, socket.io, and mediasoup. However, I am a bit confused about how to detect a disconnection from mediasoup.

The questions are:

  1. Does the transport close immediately when socket.io is disconnected? Can it not be reconnected?
  2. When is the right time to use restart ice connection?
  3. Provide me with references to understand RTP mux and CoMedia. To comprehend how they work and their functions.
  4. Is the mind map I created correct? I’m a bit confused about pipe transport because I haven’t tried it yet, but that’s how I imagine it.? Connectivity
2
  • Transport doesn’t close automatically, you will have to close the relevant transports based upon app’s logic like when user leaves or call ends. Socket io disconnection and transport disconnection are 2 different things
  • When user’s network is switch like from 4g to 3g you can call restart ice. I also use restart ice to recover the transport once it is failed because of the internet issues on user’s side.
  • Not sure about the RTP mux thing.
1 Like
3

Sir, I created mindmap like this Mediasoup Mindmap and what you think? Is it true?

4

Looks ok, the main point is that if you don’t have producer on your worker, which you want to consume, you must get it from that worker to this worker using pipetransport, which you have mentioned in diagram. Rest depends upon the app logic

1 Like
5

In the context of a media server, connections won’t be automatically closed for any reason; their state will persist until cleared. To determine if a user has finished using the connection, you can employ a chat server. This chat server can monitor changes in their activity using methods like ping/pong (if no pong is received on the second round, the connection can be closed), detecting when the socket is closed, or responding to a server request to terminate the connection.

pipeTransports can get complicated, a media-broker-server is an ideal solution, queue each message received till job is completed. This means if a broadcast comes in, this server will tell mediaserver-A and mediaserver-B to create and connect their transports and then produce/consume the stream. When done complete next job, this prevents global variable state from being untrue at any point.

2 Likes