WebRTC, NAT, STUN, TURN A Complete Beginner-Friendly Guide

Real-time communication powers everything we use today video calls, voice calls, live streaming, multiplayer games, and even real-time chat.

But how do two devices talk directly over the internet?

The secret behind all of this is WebRTC.

In this blog, we’ll break down WebRTC from the ground up:

• What WebRTC really does

• What Signaling, SDP, and ICE are

• What Host, STUN, and TURN candidates are

• Why NAT creates problems

• Why mobile network users are always behind NAT

• And why TURN sometimes becomes mandatory

By the end, you’ll understand WebRTC like a pro.

What is WebRTC?

WebRTC (Web Real-Time Communication) is a technology that allows browsers and apps to communicate peer-to-peer without needing a server in the middle for audio/video/data transfer.

WebRTC makes possible:

• Video calling

• Voice calling

• Live screen sharing

• File transfer

• Real-time chat (via DataChannel)

Once the connection is established → the data flows directly between devices.

But establishing that connection is the tricky part.

Why Peer-to-Peer Is So Hard?

Because almost every device on the internet is behind a NAT.

It doesn’t matter if you're using:

• Home WiFi

• Broadband

• Mobile data (SIM)

• Corporate network

• Public WiFi

All of these use some type of NAT or firewall.

To bypass this, WebRTC depends on:

• Signaling

• SDP (Offer/Answer)

• ICE (Connectivity process)

• ICE Candidates (Host / STUN / TURN)

1) What is Signaling?

Signaling is how two devices exchange the initial information needed to start a WebRTC connection.

This includes:

• Their SDP

• Their ICE candidates

• Their media settings

• Their "Hey, I want to connect" messages

Signaling is not part of WebRTC itself — it’s just the method of sending messages between peers.

You can use:

• WebSocket

• Socket.io

• Firebase

• REST API

• Even manual copy-paste (for testing)

Once both devices exchange the required info → signaling is done.

flowchart LR
    A[Device A] -->|Offer SDP + ICE| S(Signaling Server)
    S -->|Forward| B[Device B]
    B -->|Answer SDP + ICE| S
    S -->|Forward| A
    classDef peer fill:#4da6ff,stroke:#333,stroke-width:1px;
    class A,B peer

2) What is SDP?

SDP (Session Description Protocol) is a long text description containing:

• Audio/Video codecs

• Encryption details

• Number of media tracks

• DataChannel info

• Network capabilities

• Offer/Answer details

SDP basically tells:

“Here is how I want to communicate. Tell me how you want to respond.”

WebRTC uses:

• Offer SDP → created by the first device

• Answer SDP → created by the second device

Without SDP, devices won’t understand each other’s capabilities.

sequenceDiagram
    participant A as Device A
    participant S as Signaling Server
    participant B as Device B

    A->>S: Offer SDP
    S->>B: Offer SDP
    B->>S: Answer SDP
    S->>A: Answer SDP

3) What is ICE?

ICE = Interactive Connectivity Establishment

It’s a smart process WebRTC uses to discover:

• How devices can reach each other

• Which path is the fastest

• Which path is even possible

ICE collects different candidates (possible connection routes).

There are 3 types:

1. Host Candidate → local network address

2. STUN Candidate → public IP address

3. TURN Candidate → relay server (last resort)

ICE tests all possibilities and automatically selects the best one.

flowchart TD
    subgraph Candidates
      H[Host Candidate]
      S[STUN Candidate]
      T[TURN Candidate]
    end

    A[Device A] -->|gathers| H
    A -->|gathers| S
    A -->|gathers| T
    B[Device B] -->|gathers| H
    B -->|gathers| S
    B -->|gathers| T

    H -- fastest --> Direct[Direct P2P]
    S -- possible --> Direct
    T -- relay --> Relay[TURN Relay]

4) ICE Candidate Types Explained

A) Host Candidates

These are local IP addresses, like:

• 192.168.x.x

• 10.x.x.x

Used when both devices are:

• On the same WiFi

• On the same LAN

Fastest possible connection.

B) STUN Candidates

A STUN server’s job:

“Tell me what my public IP looks like on the internet.”

Because NAT hides your real public address, STUN helps your device discover it.

Used for normal real-world P2P.

But STUN can fail on:

• Strict firewalls

• Mobile networks

• Corporate networks

sequenceDiagram
    participant C as Client
    participant ST as STUN Server

    C->>ST: Binding request ("what is my public IP?")
    ST-->>C: Binding response (public IP:port)

C) TURN Candidates (Relay)

If direct P2P is impossible, a TURN server becomes a relay:

Device A → TURN → Device B

TURN is slower but guarantees connection.

Required in:

• Mobile data networks

• Corporate networks

• Public WiFi

• CGNAT (Carrier-grade NAT)

• Very strict firewalls

TURN is the last hope of WebRTC.

flowchart LR
    classDef peer fill:#4da6ff,stroke:#222,stroke-width:1px,color:#000;

    A[Device A]:::peer -->|Encrypted Media| TURN[TURN Server]:::peer
    TURN -->|Encrypted Media| B[Device B]:::peer

    Note["TURN relays RTP/DTLS packets"]:::peer
    TURN -.-> Note

NAT in Mobile Data (SIM Internet)

Most people think:

“I don’t have a router, so I don’t have NAT.”

Wrong.

Mobile networks use a massive NAT system called:

CGNAT (Carrier-Grade NAT)

Your phone actually gets a private IP like 10.x.x.x, not a real public IP.

Millions of users share a few public IPs.

This makes mobile networks extremely strict:

• Direct P2P usually fails

• STUN candidates may not work

• TURN becomes necessary

This is why WebRTC sometimes struggles on 4G/5G networks without TURN.

    flowchart LR
Phone["Mobile Phone (10.x.x.x)"] -->|private| CGN["Carrier NAT"]
CGN -->|shared public| Internet["Public Internet"]
Internet -->|routes| Service["Remote Peer"]

Note["Millions of phones share a few public IPs"]
CGN -.-> Note

classDef box fill:#4da6ff,stroke:#222,stroke-width:1px,color:#000;
class Phone,CGN,Internet,Service,Note box;

ICE Connectivity Check (how candidates are tested)

sequenceDiagram
    participant A as Device A
    participant B as Device B

    A->>B: STUN connectivity check (candidate pair)
    B-->>A: STUN success
    A->>B: Confirm and switch media path

This process repeats across candidate pairs until a working pair is found.

---

Summary

Concept	Meaning	When Used
Signaling	Exchange connection info	Before connecting
SDP	Media + network description	Offer/Answer
ICE	Finds best connection path	NAT traversal
Host Candidate	Local IP	Same network
STUN Candidate	Public IP discovery	Normal P2P
TURN Candidate	Relay server	Strict networks
Mobile Data	Always behind CGNAT	Requires TURN

Conclusion

WebRTC is incredibly powerful — enabling P2P communication without needing a central media server.

But to make this work, it must deal with:

• NAT

• Firewalls

• Mobile network restrictions

• Different internet conditions

That’s why WebRTC uses:

• SDP

• ICE

• STUN

• TURN

Together, they create a stable P2P connection under almost every condition.