ICE, STUN, TURN, and Candidate Gathering

Introduction

In the previous chapter, Alice and Bob successfully completed:

Offer
   ↓
Answer

At that moment they agreed on:

• Audio codecs
• Video codecs
• Encryption mechanisms
• Transport protocols
• Media capabilities

Everything looks good.

Yet:

No audio
No video
No connection

Why?

Because agreement is not connectivity.

Let's use a real-word analogy.

The Meeting Analogy

Imagine Alice says:

Let's have a meeting.

Bob replies:

Agreed

Question:

Where?

Neither person knows.

The meeting cannot happen.

The same problem exists in WebRTC.

Offer/Answer establishes:

Communication Rules

But it does not establish:

Communication Path

This entire problem is solved by:

ICE: Interactive Connectivity Establishment

Why ICE Exists

Remember our NAT discussion.

Alice may have:

192.168.1.10

Bob may have:

192.168.0.20

These addresses are useless on the public Internet.

Neither peer can directly use them.

So WebRTC faces a challenge.

How can two machines connect when:

Private Networks
NAT Devices
Firewalls
Corporate Gateways

stand between them?

ICE exists specifically to solve this challenge.

The Most Important Mental Model

Most beginners think:

ICE finds the connection

This is partially true.

A better description is:

ICE discovers every possible route between peers and then chooses the best one

Think of ICE as:

GPC Navigation System

for network communication.

What Is an ICE Candidate?

A candidate is simply:

A possible network address through which a peer may be reachable.

That's it. Nothing magical. Nothing complicated.

A candidate is merely:

Potential Route

Real-World Analogy

Suppose Alice says:

You can reach me at:

Home Address
Office Address
Hotel Address

These are candidate locations.

Bob can try each one.

Whichever works becomes the meeting location.

ICE candidates work exactly the same way.

Example Candidate

Alice may discover:

192.168.1.10:5000

This becomes a candidate.

She may also discover:

49.37.20.15:62000

Another candidate.

She may also receive:

TURN Server Address

Another candidate.

Each represents a possible route.

Candidate Gathering

After Offer/Answer begins, the browser starts: Candidate Gathering

The goal:

Find Every Possible Address

that could be used for communication.

Candidate Types

There are three major candidate categories.

Host Candidate
Server Reflexive Candidate
Relay Candidate

Understanding these three types is the key to understanding ICE.

Type 1: Host Candidate

Suppose Alice's laptop has:

192.168.1.10

The browser can see this directly.

No STUN, No TURN, No servers required.

The browser simply asks:

What networks interfaces exist?

The operating system replies:

WiFi: 192.168.1.10

VPN: 10.10.0.5

These becomes host candidates.

Host Candidate Example

candidate: 192.168.1.10:5000

This means:

Try reaching me directly here.

When Host Candidates Work

Host candidates work well when:

Same Network

Example:

Office LAN
Home LAN

Alice and Bob can communicate directly.

No NAT traversal needed.

Why Host Candidates Often Fail

Suppose:

Alice: 192.168.1.10

Bob: 192.168.0.20

on different networks.

Bob cannot reach:

192.168.1.10

because it only exists inside Alice's private network.

Host candidates often become unusable across the public Internet.

Type 2: Server Reflexive Candidate

This is where STUN enters.

Remember:

Alice believes she is:

192.168.1.10

 But the Internet sees:

49.37.20.15

How does Alice discover this?

Enter STUN

STUN stands for: Session Traversal Utilities for NAT

The name sounds intimidating.

Its job is actually very simple.

The STUN Question

Alice asks:

Dear STUN Server,

What address do you see me as?

The STUN server responds:

49.37.20.15:62000

Visualizing STUN

Alice
  |
  |
STUN Server

Alice sends:

Who am I?

STUN replies:

You appear as:

49.37.20.15:62000

Why This Matters

Alice now learns:

Public Address

instead of only:

Private Address

This public address becomes another candidate.

Server Reflexive Candidate

The discovered public mapping is called:

Server Reflexive Candidate

often abbreviated:

srflx

because WebRTC engineers love abbreviations.

Example:

Private: 192.168.1.10:5000

Public: 49.37.20.15:620000

ICE Stores: 49.37.20.15:62000 as a candidate

Why “Reflexive”?

The STUN server reflects your identity back to you.

You ask:

Who am I?

It reflects the answer.

Hence:

Reflexive

Type 3: Relay Candidate

Unfortunately STUN is not always enough.

Remember:

Some NAT devices are hostile.

Examples:

Symmetric NAT
Corporate Firewalls
Strict Networks

Direct communication may fail.

Enter TURN

TURN stands for: Traversal Using Relays around NAT

TURN provides:

Relay Infrastructure

The TURN Idea

Instead of:

Alice ←→ Bob

we use:

Alice
|
TURN
|
Bob

The TURN server becomes a middleman.

Why TURN Works

Both Alice and Bob can typically reach:

Public TURN Server

Therefore:

Alice -> TURN
BOB -> TURN

always works.

The TURN server relays traffic between them.

Relay Candidate

The TURN server allocates a public address.

Example:

203.0.113.10:55000

This address becomes:

Relay Candidate

Comparing Candidate Types

Candidate Gathering Timeline

Let's watch Alice gather candidates.

Step 1: Host Candidate

192.168.1.10:5000

Step 2: STUN Disovery

49.37.20.15:62000

Step 3: TURN Allocation

203.0.113.10:55000

Result:

Candidate List

1. Host
2. Server Reflexive
3. Relay

Candidate Exchange

Now Alice has candidagtes.

Bob has candidates.

But they still don't know about each other.

Therefore candidates must be exchanged.

How Are Candidates Exchanged?

Through:

Signaling

Alice Browser
     |
WebSocket
     |
Server
     |
Bob Browser

Important Insight

Offer/Answer exchange:

Capabilities

ICE Candidate exchange:

Connectivity Information

These are separate processes.

Many beginners accidentally combine them mentally.

Do not.

Candidate Pairing

Suppose Alice has:

Host
STUN
TURN

Bob also has:

Host
STUN
TURN

ICE forms combinations.

Example:

Alice HOST <--> Bob Host

Another:

Alice STUN  <--> Bob STUN

Another:

Alice TURN <--> Bob TURN

Every possible combination becomes a:

Candidate Pair

Connectivity Checks

Now ICE begins testing:

Question:

Can this pair communicate?

ICE sends small probe packets.

Example:

ICE tests:

Alice Host <--> Bob Host

Result:

Failed

because NAT blocks communication.

Next:

Alice STUN <--> Bob STUN

Result:

Success

Connection possible.

Candidate Prioritization

ICE prefers cheaper and faster routes.

Generally:

Host
   ↓
Server Reflexive
   ↓
Relay

Priority decreases.

Why?

Because:

Direct Connection

is better than:

Relayed Connection

Candidate Selection

Eventually ICE discovers:

This Route Works

The candidate pair becomes:

Selected Candidate Pair

This pair becomes the active connection path.

Example:

Selected pair:

Alice STUN Candidate <---> Bob STUN Candidate

Now communication begins.

What Happens After Selection?

ICE is not finished.

Many developers think:

ICE ends after connection.

Not exactly.

ICE continues:

Connection Monitoring
Keepalive Packets
Path Validation

throughout the session.

Why Keepalives Matter

NAT mappings expire.

Example:

Router: No traffic for 30 seconds?
Close mapping

If the mapping closes:

Call Dies

ICE periodically sends traffic to keep mapping alive.

ICE States

Internally, ICE moves through states.

Simplified:

New
 ↓
Gathering
 ↓
Checking
 ↓
Connected
 ↓
Completed

Real Connection Timeline

Now we can finally see the bigger picture.

Create PeerConnection
        ↓

Add Tracks
        ↓

Create Offer
        ↓

Send Offer
        ↓

Create Answer
        ↓

Send Answer
        ↓

Gather Candidates
        ↓

Exchange Candidates
        ↓

Connectivity Checks
        ↓

Select Candidate Pair
        ↓

Connection Established

Only after all of this can media start flowing.

The Most Important Insight of This Chapter

The correct mental model is:

STUN answers: Who am I on the Internet?

TURN answers: What if direct communication fails?

ICE answers: Which route should we use?