Are there plans to support a TCP candidate so a TURN server isn't needed at all? It feels a bit wasteful to effectively use a TURN server as a TCP->UDP proxy for a publicly accessible server.
> TCP candidate so a TURN server isn't needed at all?
This is not true. A router may still block TCP traffic different than TLS or traffic that does not have destinatiuon port 80 or 443. So ICE TCP candidates do not avoid the need for a TURN server in certain cases.
You cannot select a specific listening port for a specific transport, because each WebRTC transport requires, at least, a different listening port in the server:
Is 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.
rfc3550 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.
https://mediasoup.org/documentation/v3/mediasoup/api/#WebRtc...
> TCP candidate so a TURN server isn't needed at all?
This is not true. A router may still block TCP traffic different than TLS or traffic that does not have destinatiuon port 80 or 443. So ICE TCP candidates do not avoid the need for a TURN server in certain cases.