5 ms·
Maybe I could allocate a port to use for an additional low priority tcp candidate via configuration, or would I need to dive into the code for this? For exampl
by supermatt 7y ago
Maybe I could allocate a port to use for an additional low priority tcp candidate via configuration, or would I need to dive into the code for this?
For example, I could supply the generated udp and tcp candidates in addition to a tcp:443?
What are your thoughts?
- ibc 7y agoYou cannot select a specific listening port for a specific transport, because each WebRTC transport requires, at least, a different listening port in the server: https://mediasoup.org/documentation/v3/mediasoup/api/#WebRtcTransportOptions https://mediasoup.org/documentation/v3/mediasoup/api/#WebRtc... YouIf you want to listen in TLS 443 for all clients, add a TURN server into your backend. Just that.
- supermatt 7y agoIs there a reason for the restriction of one connection per port? I would have thought you would be able to use the same port for each peer source ip/port tuple? Not doubting you - but I never experienced this limitation with other client/server applications. I have an http server serving over 200k concurrent websockets on port 443, for example. I'm happy to help out with this if I can.
- ibc 7y agoMajority of RTP media server listen into a separate port for each connection. That's how RTP typically works. This is not TCP connections.
- supermatt 7y agorfc3550 states that it is per destination ip/port tuple. So you should be able to support multiple connections per local port. Is it possible this is an oversight in the current implementation? I appreciate this isn’t TCP, which is why I have just read through all relevant RFCs.
- ibc 7y agoWhy is that so important? As I said, choosing a specific port is not enough. This is not TLS. An aggressive firewall may drop those TCP connections because there is no TLS data on them.
- supermatt 7y agoTLS port was just a thought, as I want to reduce cases where turn server is used because of a limitation with scalability (65k connection limit per turn server due to a shared source ip). But our discussion has raised another issue regarding mediasoups limitation of one source per local port - which compounds the issue. I’m replacing a web socket server with a data channel server. If I use mediasoup then I will need to listen over 4 ip4 addresses to support the 200k clients I can currently support on 1 ip address with web sockets. Not a huge deal right now, but if I want to support millions of user it means managing 40 or so ip addresses instead of 1 or 2. Not knocking mediasoup at all, just now aware of a limitation that sounds like it doesn’t need to exist so seeing if we can do something about it.
- ibc 7y agoThis is RTP not WebSocket or HTTP. Media servers need a separate port for each RTP communication. A hack could be done to make all WebRTC endpoints to use a single port in mediasoup side. However mediasoup also support plain RTP endpoints and, in those, you need to be ready to listen for RTP from any remote IP:port (you don't know it in advance due to NATs). In WebRTC we can use ICE user/pwd (previously given to the server via signaling) but that's not possible with plain/regular RTP (no ICE).
- supermatt 7y agoIsn’t that what the SSRC is for? I.e you use the SSRC (sent as part of media in the SDP) to identify the stream, rather than trusting an authentic stream is the only one to send to an open port? At least, that is how I understood the (multiple) rfcs. Not an expert here by any means.