WebRTC

ICE vs STUN vs TURN — Complete WebRTC Networking Guide for Developers

MYLINEHUB Team • 2026-02-21 • 16 min

Confused about ICE, STUN, and TURN? This deep WebRTC networking guide explains NAT traversal, relay behavior, latency tradeoffs, and when TURN becomes mandatory in production.

ICE vs STUN vs TURN — Complete WebRTC Networking Guide for Developers
```html

WebRTC • ICE • STUN • TURN • NAT Traversal • Beginner → Deep Dive

ICE vs STUN vs TURN: Complete WebRTC Networking Guide (Layman First, Deep After)

WebRTC lets a browser send audio/video in real time. But real networks are messy: home routers, office firewalls, mobile carriers, and “carrier-grade NAT” can block direct connectivity. That is why WebRTC has ICE, STUN, and TURN.

In plain English:

  • ICE is the “search strategy” that tries multiple ways to connect.
  • STUN is how a device asks: “What is my public address on the internet?”
  • TURN is a paid “relay helper” when nothing else works.

If you only remember one thing: ICE is the brain, STUN is the mirror, TURN is the backup bridge.

Table of contents

1) The simplest explanation (no jargon) 2) Mini-glossary (what these words mean) 3) Why direct calls fail: NAT & firewalls (visual mental model) 4) Quick comparison table (ICE vs STUN vs TURN) 5) ICE: “try every door until one opens” 6) STUN: “what is my public door number?” 7) TURN: “meet at a public building” 8) ICE candidates explained (host / srflx / relay) 9) When TURN is required (and common myths) 10) Google STUN and public STUN servers (what’s okay, what’s not) 11) TURN security: avoid open-relay abuse 12) Practical configs (browser + server) with explanations 13) Debugging checklist (what to check first) 14) Decision guide: what you need for your product 15) References & further reading

This article is foundational. It explains “why” first, then gives practical setups and debugging.

1) The simplest explanation (no jargon)

Imagine two people want to talk on the phone, but both are inside buildings with security guards (routers/firewalls). They want to pass a note (audio/video packets) back and forth.

ICE is the plan

ICE is like saying: “Let’s try every possible way to exchange notes: through the front door, through the back door, through the mail room, and if all fails we will meet at a café.”

ICE tries multiple candidate routes and picks the first one that works reliably.

STUN is the “public door address” lookup

STUN is like asking a receptionist outside your building: “When people from outside send mail to me, what address do they actually use?”

Many buildings rewrite internal room numbers into a public mailbox number. STUN reveals that.

TURN is the fallback meeting place

If the buildings are too strict and won’t allow direct note passing, TURN says: “Okay, both of you send your notes to the same café (relay), and the café staff will forward them.”

TURN costs money because every note goes through the café (server bandwidth).

Why do we need all this?

Because the internet is not one simple open road. Most users are behind NAT, carrier NAT, or corporate firewalls that block inbound traffic by default.

WebRTC must succeed across real-world networks—ICE/STUN/TURN are how it does that.

Layman summary: ICE chooses a working path, STUN helps find your reachable address, TURN relays when direct paths fail.

2) Mini-glossary (what these words mean)

Term Simple meaning Why it matters in WebRTC
NAT Your router hides many devices behind one public IP Outside devices can’t “directly find” your laptop/phone without help
Firewall Rules that block traffic Some networks block UDP or block inbound connections
UDP Fast packets, less “guaranteed delivery” Real-time audio/video usually uses UDP for low latency
Candidate A possible “IP:port address” to try ICE collects candidates and tests them
Relay A middle server that forwards packets TURN provides relays for hostile networks
Connectivity checks “Are you reachable on this path?” tests ICE performs these checks to select the best candidate pair

3) Why direct calls fail: NAT & firewalls (visual mental model)

A common beginner question is: “Why can’t two browsers just send audio directly?” Sometimes they can. Often they can’t. The reason: most networks allow outbound traffic freely, but block inbound traffic.

User A (Home Wi-Fi) Laptop 192.168.1.20 Router NAT → Public IP Inbound blocked by default User B (Office Network) Phone 10.10.5.7 Firewall + NAT + Policies UDP often restricted Public Internet No “direct map” to private IPs Outbound OK Inbound often blocked

The key problem: User A can send packets out, User B can send packets out, but neither side can reliably accept inbound packets unless a path is negotiated.

ICE uses STUN/TURN to discover and test paths that punch through NAT or use a relay when punching fails.

4) Quick comparison table (ICE vs STUN vs TURN)

Thing What it is What it does Do you “run a server”? Cost impact
ICE Algorithm/process Collects candidates and tests connectivity; chooses a working route No (built into WebRTC stacks) Indirect (determines whether TURN is needed)
STUN Protocol + STUN server Helps discover public mapped address; helps NAT traversal Yes (STUN server), but can use public ones Low (small traffic)
TURN Relay protocol + TURN server Relays media when direct connection fails Yes (TURN server) — you should run your own High (media bandwidth goes through server)

5) ICE: “try every door until one opens”

ICE is the core process that makes WebRTC “just work” most of the time. It does three big things:

ICE step A: Gather candidates

  • Host candidates: local IPs (e.g., 192.168.x.x, 10.x.x.x)
  • Server-reflexive candidates: public mapped address learned via STUN (srflx)
  • Relay candidates: addresses allocated on TURN (relay)

Candidates are simply “possible addresses where I might receive media”.

ICE step B: Exchange candidates

Browsers exchange candidates through signaling (your app’s WebSocket/HTTP flow). ICE does not define signaling; your product does.

Signaling is just “how the two peers share their candidate lists”.

ICE step C: Connectivity checks

ICE then tests candidate pairs: “If I send to your candidate, do you receive it and respond?” This is why ICE can automatically pick the working path.

Think of it like trying multiple phone numbers until someone answers.

ICE chooses the best working path

  • Direct path is preferred (lower latency, no relay cost)
  • If direct fails, TURN relay is used
  • The chosen path can be observed in WebRTC stats (srflx/relay)

Many teams discover TURN is needed only after checking how many calls end up using relay in real traffic.

Beginner myth: “ICE is a server.”

ICE is a strategy used by both sides. The servers you provide are STUN/TURN, which ICE may use.

6) STUN: “what is my public door number?”

If you are inside a private network (like 192.168.1.20), outside people cannot send directly to that address. Your router “maps” your internal connection to a public IP and port. STUN helps discover what that mapping looks like from the outside.

STUN in plain steps

  1. Your browser sends a STUN request to a STUN server on the internet.
  2. The STUN server sees the public source IP:port it came from.
  3. The STUN server replies: “I saw you as 203.0.113.9:52344”.
  4. Your browser uses that as a server-reflexive (srflx) candidate.

“Reflexive” here means: “I learned it by looking in a mirror (the STUN server).”

When STUN is enough

  • Home routers with “friendly NAT” behavior
  • Networks that allow UDP for WebRTC
  • No strict inbound policies blocking the mapped ports

Many casual WebRTC demos succeed with STUN-only because they’re tested on friendly networks.

Important: STUN does not relay your audio/video. It only helps create a reachable address to try.

7) TURN: “meet at a public building”

Some networks will not allow direct WebRTC traffic no matter how hard ICE tries. TURN is the reliable fallback: both sides connect to a relay server that sits on the public internet, and the relay forwards packets.

TURN in plain steps

  1. Your browser asks the TURN server: “Please allocate me a relay address.”
  2. TURN replies with a relay IP:port that is reachable from the internet.
  3. Your browser sends media to that relay address.
  4. The TURN server forwards media to the other side (and vice versa).

TURN is like a mail forwarding office.

Why TURN costs money

  • All media passes through TURN (bandwidth usage)
  • More concurrent calls = more relay traffic
  • TURN must be close to users/edge servers to reduce latency

If your “Talk to Bot” button is important, TURN is not optional—it’s the cost of reliability.

Production truth: You can’t predict which user networks will need TURN. You discover it by observing real traffic.

8) ICE candidates explained (host / srflx / relay)

Candidate type What it looks like Where it comes from Pros Cons
host 192.168.1.20:54012 Your device local interfaces Fast, direct on same LAN Usually not reachable from internet
srflx (server reflexive) 203.0.113.9:52344 STUN mapping discovery Often works across home NAT Fails on strict NAT/firewalls
relay turn.example.com:49152 TURN allocation Most reliable across hostile networks Costs bandwidth; adds latency

Tip for beginners: if you see many calls choosing relay, your TURN server is doing its job.

If you have no TURN at all, those calls won’t “choose srflx instead” — they will just fail.

9) When TURN is required (and common myths)

TURN is often required when

  • Users are on corporate networks with strict firewall policies
  • Users are on mobile networks with carrier-grade NAT
  • UDP is blocked or shaped badly
  • Symmetric NAT prevents stable mappings
  • Hotel Wi-Fi or public Wi-Fi blocks peer connectivity

Common myths (and the reality)

  • Myth: “STUN is enough for everyone.”
    Reality: STUN improves success, doesn’t guarantee it.
  • Myth: “TURN is only for video calls.”
    Reality: audio calls can also need TURN.
  • Myth: “If ICE connects, audio always works.”
    Reality: ICE can connect but codec/media routing issues can still cause no-audio.

Practical rule: If your WebRTC feature is customer-facing, plan TURN from day one, even if your early tests “work fine”.

10) Google STUN and public STUN servers (what’s okay, what’s not)

Many examples use Google STUN (like stun:stun.l.google.com:19302). This is common in demos because it’s easy.

Using public STUN: when it’s okay

  • Prototyping and development
  • Low traffic applications
  • You accept that the service is not “yours” (no business SLA)

STUN traffic is small. It’s mostly “discovery”, not media relay.

Why public STUN is not your reliability plan

  • It does not provide relaying (TURN does)
  • Policies, rate limits, availability can change
  • You have limited observability when users fail

For production reliability, run TURN (and optionally your own STUN as part of TURN).

Recommended approach: you can keep a public STUN entry for convenience, but always include your own TURN servers.

11) TURN security: avoid open-relay abuse

TURN is powerful, and attackers love powerful infrastructure. If you misconfigure TURN, it becomes a free proxy for bad actors.

The “safe TURN” checklist (beginner-friendly)

Security item What it means (simple) Why it matters
Authentication Clients need username/password to use TURN Prevents anonymous abuse
Ephemeral creds Short-lived passwords generated per session Stolen credentials expire quickly
Realm locking TURN is scoped to your domain/realm Makes misrouting and reuse harder
Quotas Limit bandwidth/allocations per user Stops one user from draining your bandwidth
Logging Record allocations + peers Detect abuse early

Layman warning: If TURN is “open”, people can use your server like a free internet tunnel. You will pay the bandwidth bill.

12) Practical configs (browser + server) with explanations

Browser ICE config (what you actually pass to WebRTC)

The browser needs a list of ICE servers. That list includes STUN and TURN. ICE will decide which candidates win. 

// Browser-side (example)
const iceServers = [
  // STUN helps discover srflx candidates
  { urls: ["stun:stun.l.google.com:19302"] },

  // TURN provides relay candidates (reliability)
  {
    urls: [
      "turn:turn.example.com:3478?transport=udp",
      "turn:turn.example.com:3478?transport=tcp",
      "turns:turn.example.com:5349?transport=tcp"
    ],
    username: "<short-lived-username>",
    credential: "<short-lived-password>"
  }
];

const pc = new RTCPeerConnection({
  iceServers,
  // optional:
  // iceTransportPolicy: "all",   // try direct + relay
  // iceTransportPolicy: "relay"  // force TURN only (useful for strict environments)
});

Beginner note: You do not “choose TURN” manually for each call. ICE chooses based on what works.

TURN deployment pattern (simple architecture)

  • Run coturn (TURN server) on a public IP in the same region as your WebRTC edge (e.g., Janus).
  • Expose 3478 UDP/TCP and 5349 TCP (if using TLS).
  • Expose a defined relay port range (so firewall rules are clear).
  • Generate ephemeral credentials from your backend per call session.

Why same region? TURN adds a hop. If TURN is far away, latency gets worse.

“Force TURN only” (when to use it)

Sometimes you may want to force TURN (relay-only) to avoid flaky direct routes. This can be useful when:

  • Enterprise networks behave inconsistently with UDP hole punching
  • You want predictable media paths for compliance/monitoring
  • You prefer paying relay cost over support tickets

Tradeoff: forcing TURN increases bandwidth cost, but improves consistency in difficult networks.

13) Debugging checklist (what to check first)

If the call never connects

  • Check browser console for iceConnectionState = failed
  • Verify TURN credentials are valid and not expired
  • Verify TURN ports are open (3478/5349 + relay range)
  • Try forcing TURN only (iceTransportPolicy: "relay")

If TURN-only fails, it’s almost always firewall/ports/DNS/TLS issues on TURN.

If it connects but audio/video is missing

  • Check selected candidate type (relay vs srflx) in stats
  • Check if media is muted / track not added
  • Check codecs negotiation (Opus vs something else)
  • Check server-side gateway bridging (Janus ↔ SIP ↔ PBX) if using SIP

ICE “connected” only means a path exists. Media can still fail due to codec or routing mistakes.

Fast triage rule: first confirm ICE state. If ICE fails, don’t debug PBX/AI. Fix TURN/ICE first.

14) Decision guide: what you need for your product

Your use-case Minimum recommended Why
Internal demo, same Wi-Fi ICE + STUN Friendly networks, fewer restrictions
Public website voice button ICE + STUN + TURN (your own) Real users have hostile NAT/firewalls; TURN ensures success
Enterprise customers ICE + TURN + option to force relay Enterprises often block UDP/hole punching; relay reduces support
Call center / compliance heavy TURN + logging + regional redundancy Predictable paths, better observability, fewer “random” failures

If you want near-100% call success: run TURN, monitor relay usage, and scale TURN bandwidth like a core dependency.

15) References & further reading

Protocol references (authoritative)

The RFCs are technical, but they’re the source of truth when debugging edge cases.

Try it

Want to see API-driven CRM + Telecom workflows in action? Try the WhatsApp bot or explore the demos.

💬 Try WhatsApp Bot ▶️ Watch CRM YouTube Demos
Tip: Comment “Try the bot” on our YouTube videos to see automation in action.
M
MYLINEHUB Team
Published: 2026-02-21
Quick feedback
Was this helpful? (Yes 0 • No 0)
Reaction

Comments (0)

Be the first to comment.