Question about PlainTransportOptions's comedia option

mediasoup libraries
1

The v3 documentation says, Whether remote IP:port should be auto-detected based on first RTP/RTCP packet received. If enabled, connect() must only be called if SRTP is enabled by providing the remote srtpParameters and nothing else.

Consider 1:n video streaming, when there is 1 producer but many consumers, if server side’s RTP port in udp can be set to listen mode like in tcp, then sdk-based client(not webrtc client) can directly pull H264 stream from this RTP port, without need to ask for a dynamic port or calling plainTransport.connect at server side.

2

I don’t really follow what you mean.

3

I mean, as to 1 specific stream producer, multiple consumers can connect to the same RTP port at server-side, they do not need to do any negotiation since they’re custom sdk client, not webrtc client, and then get 0-RTT connect latency…

4

No, sorry. That’s not gonna happen. Each plain or WebRTC transport requires its own port(s) in server side.

5

I know, i’m just wondering~ maybe could put a HAProxy to do server-side load balance…

UDP Loadbalancing · Issue #62 · haproxy/haproxy · GitHub HAProxy seems not supporting UDP LB, but i guess it’s possible~

6

Hi ibc,

when use comedia:true option, how can client send a UDP packet to server’s RTP listen port? Does RTP specify this case? Maybe to combine RTSP + RTP: client first send a RTSP PLAY packet to server’s rtp port, but mediasoup doesn’t support RTSP…

7

I miss-understand the RTP port’s meaning.

RTP normally means UDP, not TCP, so if give a RTP url, like “rtp://ip:port” to a player, the ip is just local machine’s ip, & the port is used for “receiving rtp packets” in listen mode only.

So mediasoup’s comedia:true is normally only used for plain RTP producer, not consumer. Well, I’ve tried use comedia:true for plain RTP consumer clients (since there is no native WebRTC SDK, only web client sdk), but failed due to NAT not do auto reverse port mapping… The problem now hits me.