# 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.

```mermaid
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.

```mermaid
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.

```mermaid
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

```mermaid
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.

```mermaid
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.

```mermaid
    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)**

```mermaid
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.