I just have built my first meeting app using mediasoup. And I created just one recvTransport for receiving every participants tracks in my app.
I want to ask whether this is a recommended way to use recvTransport or not.
Is there anyone who experience performance/stability issues with using a single recvTransport or too many recvTransport(1 recvTransport for each peer).
I vaguely understand that WebRTC support ‘unified-plan’ so we can send multiple tracks via single RTCPeerConnection. But is this technique stable in every platform?
I suddenly realize that this question is not for mediasoup users but for WebRTC users.
But if anyone know the answer, please let me know.
You can not use a single Transport (i.e. RTCPeerConnection) for multiple peers but you may have multiple consumers (i.e MediaTrack) over a single Transport. So every peer would need one consuming transport at least.
I am afraid that I probably gave unclear description of my situation.
I mean I created a single recvTransport in client app for multiple tracks from multiple remote peers.
So every client app have one busy recvTransport and one sendTransport. And it works perfectly.
My questions is that if there is recommended way between ‘using single recvTransport for every remote peers’ and ‘creating recvTransport everytime a remote peer join in’ in terms of performance/stability on both sides of client and server.
I mean I created a single recvTransport in client app for multiple tracks from multiple remote peers.
So every client app have one busy recvTransport and one sendTransport. And it works perfectly.
I don’t understand! Each Transport (send or receive) is responsible for only one point-to-point connection (two peers). How could you manage connecting a client to multiple remote peers using just one Transport?
Mediasoup can collect all tracks from remote peers and then send it to another peer. As I undertood, it is what SFUs provide.
So each peers (client side) don’t need to establish multiple recvTransports for every remote peers. It just need to connect with mediasoup-server even via single SRTP connection for receiving every tracks of remote peers.
Surely, you can create multiple recvTransport for every remote peers. But it’s not necessary.
I don’t understand! Each Transport (send or receive) is responsible for only one point-to-point connection (two peers). How could you manage connecting a client to multiple remote peers using just one Transport?
Maybe he would like to say that client app is client-side app like react or angular app with mediasoup-client. As you said, multiples transports is responsible for connection on media server with mediasoup but client app like react app has only one send transport and one receive transport which communicate with media server.
Yes, you should use a single transport for receiving all Consumers. That way the bandwidth estimator of mediasoup will work better than if there are N transports (so each of one would have a bandwidth estimator competing with the others).
BTW we’ll release soon a new version of mediasoup with transport-cc support, which will improve dramatically how mediasoup estimates the downlink bandwidth estimation of each receiver. So yes, use a single transport for receiving all Consumers.
@rocketboy2015
To be clear, clients are not connected directly together but via a server in the middle. So each client is connected only to one remote peer (which is the mediasoup server) not multiple peers. And yes one Transport is enough for receiving all the other client’s media.