STUN vs TURN vs ICE: Making WebRTC Work Behind Corporate Firewalls

What STUN, TURN, and ICE each do in WebRTC, and why TURN capacity planning matters in real enterprise networks.

WebRTC promises direct peer-to-peer audio and video in the browser, but the real internet is full of NAT devices, restrictive routers, and corporate firewalls. Two peers cannot simply exchange IP addresses and expect media to flow.

ICE, or Interactive Connectivity Establishment, is the negotiation framework that tries to discover the best possible path between peers. It coordinates candidate gathering and connection testing so WebRTC can adapt to messy real-world network environments.

STUN is the lightweight helper in that process. A client asks a STUN server to reveal its public-facing IP address and port, then shares that information with the remote peer. When the surrounding NAT is permissive enough, that is all WebRTC needs to create a direct connection.

TURN exists for the harder cases. On strict corporate networks and symmetric NATs, a direct path may never succeed even if each peer knows its public identity. In that situation, ICE falls back to a TURN relay that receives media from one side and forwards it to the other.

That fallback is what makes enterprise WebRTC viable, but it also changes the cost model. STUN is cheap, while TURN consumes real bandwidth and infrastructure because it relays the media stream itself.

The practical lesson is to optimize for direct peer-to-peer traffic, but plan your production environment as if a meaningful slice of calls will need TURN. Without solid TURN infrastructure, WebRTC works beautifully in demos and fails exactly where enterprise customers need it most.