PlayInfoBox

Home /Network /How WebRTC, STUN, TURN, and ICE Make Browser Video Calls Work

How WebRTC, STUN, TURN, and ICE Make Browser Video Calls Work

Getting two browsers behind separate home routers to talk directly to each other is harder than it sounds—WebRTC, STUN, TURN, and ICE are the pieces that make it work.

WebRTC lets browsers connect peer-to-peer without a plugin

Web Real-Time Communication is a browser standard that enables direct audio, video, and data connections between two devices without requiring a browser extension or separate installed app, powering most in-browser video calling.

Home routers and NAT stand in the way of a direct connection

Most devices sit behind a router performing Network Address Translation, which hides their real network address from the outside world, meaning two devices on separate home networks cannot simply connect directly without first solving that addressing problem.

STUN discovers your public-facing address

A Session Traversal Utilities for NAT server tells a device what its public IP address and port look like from the outside, information the device needs before it can tell the other side of a call how to reach it.

TURN relays traffic when a direct connection is impossible

When NAT or firewall restrictions are too strict for a direct peer-to-peer connection, a Traversal Using Relays around NAT server sits in the middle and relays traffic between both sides, at the cost of extra latency compared to a direct connection.

ICE gathers and tests every possible path to find the best one

Interactive Connectivity Establishment collects candidate connection paths, gathered via STUN and TURN among other sources, then tests them and selects the best working option, falling back to a TURN relay only if no direct path succeeds.

Signaling itself is a separate step that WebRTC does not define

Before STUN, TURN, and ICE can do their work, the two sides need an initial way to exchange connection information, called signaling, which WebRTC deliberately leaves up to the application to implement, often over a regular WebSocket or server connection.

Why a direct video call is not as simple as it looks

Two people on separate home networks, each behind a router doing NAT, cannot simply dial each other's local IP address, since that address is meaningless outside their own home network. The STUN, TURN, and ICE stack exists specifically to solve this addressing and reachability problem so that WebRTC can attempt a direct connection whenever possible.

Why most calls prefer direct connection over a TURN relay

A direct peer-to-peer connection, found via STUN and confirmed by ICE, has lower latency and does not depend on a third-party relay server staying available and fast. TURN exists purely as a fallback for the cases, common on restrictive corporate or mobile networks, where a direct path genuinely cannot be established.

Frequently Asked Questions

Why do some video calls suddenly need a TURN server?

When both sides are on networks with strict firewall or NAT configurations that block direct peer-to-peer connections, ICE cannot find a working direct path and falls back to relaying all traffic through a TURN server instead, which can add noticeable latency.

Is WebRTC always fully peer-to-peer?

Not necessarily—a call is peer-to-peer only when a direct path is found. Group calls with more than two participants and any call that falls back to a TURN relay are not strictly peer-to-peer, even though they still use the WebRTC standard.