STUN, TURN, and Why Your Video Call Sometimes Works (or Not)

Plain-language STUN/TURN basics for browser chat users: NAT traversal, why symmetric networks struggle, and what operators configure behind VoiceChatMate.

If you only remember one acronym pair for browser chat, make it STUN and TURN. They exist because most users sit behind NATs that hide their true network layout from the open internet.

STUN: “What is my public address?”

A STUN server tells your browser how the world sees your UDP port. That information goes into ICE candidates so another peer can attempt a direct path. STUN is lightweight and cheap to run—Google’s public STUN is common in demos—but it is not a privacy VPN; it sees your IP when you query it.

TURN: “Please relay my packets”

When direct UDP fails—symmetric NATs, strict firewalls—browsers fall back to TURN, which relays encrypted media through a relay host. That increases latency and operator cost, but it is often the difference between “call works” and “spinning forever.”

Why you still see signaling on the app server

Even with STUN/TURN, peers must exchange candidates through signaling. The app server therefore learns who matched whom and timing metadata even if audio/video bytes bypass it.

Practical takeaway

If video fails on hotel Wi‑Fi but works at home, STUN/TURN behavior is a likely culprit—not “bad luck.” Try voice or text, or switch networks.


Continue: Browser voice internals · Video permissions guide

Try VoiceChatMate

Open the lobby to pick a display name, then text, voice, or video.