Hacker News Reader

Comment by Volundr | Hacker News Reader

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.

View on HN

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.

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...

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

Reply on news.ycombinator.com