Hacker News Reader

Comment by fulafel | Hacker News Reader

If you are talking to a websocket like server endpoint, hopefully it won't be behind NAT?

Actually, I'm currently working on an app using WebRTC, and from everything I've read you actually still need a STUN and in some cases a TURN server, even if you have a public IP:

https://bloggeek.me/turn-public-ip-address/

To be perfectly honest, I'm still fuzzy on the why, but numerous blog posts, stack overflow questions, and the Kurento forums agree. This being Hacker News maybe someone with chime in with the technical reasoning.

You are probably right. But sounds like this would still be better solved by this light tweak to webrtc than by a new protocol.

This article is essentially claiming that for WebRTC to use TCP you have to be using TURN. While I am willing to believe I am wrong here (our product feels a bit crippled over TCP to the point where I just recommend you not use it, so if it isn't working I might not even notice), I am nearly certain this is not true.

You are right, ICE does support TCP. Not all ICE implementations support it though, probably where the incorrect anecdote comes from.

ICE TCP did get a little more limited recently in Chromium though [0] because of the TCP port scanning issue [1]

I have also heard that some gateways/firewalls/$x don't allow any non-TLS traffic, so you can't even establish ICE. In those cases the DTLS/TLS transport of TURN is nice.

[0] https://lists.w3.org/Archives/Public/public-webrtc/2020Feb/0...

[1] https://medium.com/tenable-techblog/using-webrtc-ice-servers...

WebRTC negotiates a peer-to-peer protocol which operates like client/server but has issues with NAT/PAT and firewall traversal. Each peer will realistically only know about its local network and there will also likely be limitations on the peers even being able to communicate with one another directly.

STUN and TURN allow the negotiation to include services outside the local network so that you can relay signaling and stream data to a set of endpoints that both peers can use to communicate with one another. This could be the peers directly or it could be a set of 3rd party servers run by Google or someone open to the public and you can't assume any particular network topology.

Exactly. If WebSockets were an option, then WebRTC will be pretty trivial and absolutely doesn't require any STUN/TURN.

(The main issue, and this has nothing to do with the client API, is that WebRTC implementations tend to end up assuming unique ports for each user--which would be needed to help with NAT--but if you aren't behind NAT then the ICE layer already has a connection ID so you should be able to multiplex them all over a single open port.)

One big issue was also being able to demux DTLS traffic. You could do it off the 3-tuple of the remote host, but that would fall down sometimes.

I am really excited for DTLS connection ids[0] to land. Then you will have everything you need to run ICE+DTLS (and SCTP over that) and be able to demux/load balance it easier.

[0] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connect...

Reply on news.ycombinator.com