Here’s the short blog-style version:

How WebRTC Works Under the Hood (Short + Clear)

WebRTC looks like peer-to-peer magic, but it’s really a bunch of small systems working together. The browser can’t just “connect” to another browser — it needs help from servers to find each other, punch through NATs, and agree on how to send encrypted audio/video.

1. Signaling (your server)

WebRTC doesn’t do signaling itself. You use WebSockets/Socket.IO/etc. to exchange:

Offer (SDP)
Answer (SDP)
ICE candidates (network info)

This part is just matchmaking.

2. ICE: finding possible connection paths

After exchanging offer/answer, both browsers gather ICE candidates — basically all possible IP/port combos they could use.

Types:

Host (local LAN IP)
STUN (public IP/port)
TURN (relay fallback)

3. STUN: “What’s my public IP?”

Browser hits a STUN server to discover its public address assigned by the router. If both peers can route UDP to each other → real P2P.

4. TURN: fallback relay

If direct connection fails (strict NAT/firewall), WebRTC uses TURN. TURN relays all media through a server. Slower + costly, but reliable.

5. DTLS + SRTP/SCTP: secure media/data

Once a path is chosen:

DTLS handshake → creates encryption keys
SRTP → encrypted audio/video
SCTP over DTLS → data channels

Now peer-to-peer streaming begins.

TL;DR

WebRTC = P2P connection built through:

Signaling to exchange SDP + ICE
ICE testing connection paths
STUN to get public IP
TURN if direct path fails
DTLS/SRTP for encrypted media/data

It looks magical, but it’s basically: “Find a working route between two devices and stream securely.”