What is WebRTC and How Does its Networking Work?
Learn what WebRTC is, how STUN and TURN work with ICE for NAT traversal, and how peer-to-peer media stays encrypted.
Expected Interview Answer
WebRTC is a set of browser and mobile APIs and protocols that enable real-time, peer-to-peer audio, video, and data communication directly between clients, using ICE to negotiate the best network path (often via STUN for NAT traversal, falling back to a TURN relay when a direct path is impossible), with SRTP encrypting the actual media.
Because most devices sit behind NAT and cannot be reached directly by a public IP, WebRTC uses the ICE (Interactive Connectivity Establishment) framework to gather a set of candidate addresses — local, server-reflexive (via STUN), and relayed (via TURN) — and tries each pairing to find the lowest-latency path that actually works between two peers. STUN simply tells a client what its public IP and port look like from the outside, letting many NAT types be traversed with a direct peer-to-peer connection and no relay involved. When NAT or firewall rules make a direct path impossible (symmetric NAT, restrictive corporate firewalls), ICE falls back to a TURN server that relays all media traffic, which works everywhere but costs bandwidth and adds latency since traffic no longer travels the shortest path. Once a path is chosen, WebRTC signals session details (SDP offers/answers) out-of-band over any transport the application chooses (commonly WebSockets), then sends the actual audio/video over SRTP (encrypted RTP) and arbitrary data over SCTP-over-DTLS data channels, all mandatory encryption by design.
- Enables direct peer-to-peer media without routing through a central server when possible
- ICE automatically finds the best-working network path across NATs
- STUN keeps most connections peer-to-peer and low-latency
- TURN relay guarantees connectivity even through restrictive NATs, as a fallback
AI Mentor Explanation
WebRTC is like two teams trying to arrange a friendly match directly rather than through a governing board: they first try calling each other's ground directly (a STUN-style check of the true address), and if that fails because one ground's gate rules block outside calls, they fall back to booking a neutral third venue that relays messages between them (a TURN-style relay). The direct call is faster and cheaper, but the neutral venue guarantees the match still happens even when direct contact is blocked. This exact fallback logic — try direct, then relay — is how ICE finds a working path for WebRTC.
Step-by-Step Explanation
Step 1
Signaling
Peers exchange SDP offer/answer and network candidates over an out-of-band channel like WebSockets.
Step 2
Candidate gathering
Each peer collects local, STUN-reflexive, and TURN-relayed address candidates via ICE.
Step 3
Connectivity checks
ICE tests candidate pairs and selects the lowest-latency path that actually works, direct when possible.
Step 4
Encrypted media/data
Audio/video flows over SRTP and arbitrary data over SCTP/DTLS data channels, both encrypted by default.
What Interviewer Expects
- Explains WebRTC enables peer-to-peer real-time audio/video/data
- Correctly distinguishes STUN (NAT discovery) from TURN (relay fallback) within ICE
- Understands signaling (SDP exchange) is separate from the media path
- Knows media is encrypted via SRTP/DTLS by default
Common Mistakes
- Confusing STUN and TURN, or thinking TURN is only used for signaling
- Believing WebRTC has no signaling server requirement at all
- Thinking all WebRTC traffic is always peer-to-peer with no relay fallback
- Forgetting that WebRTC media is encrypted by design, unlike plain RTP
Best Answer (HR Friendly)
“WebRTC is the technology behind browser-based video calls, like a video chat app that connects two people directly without routing every frame through a company's server. It works by first trying to find each user's real network address using a helper server called STUN, and if that direct connection is blocked by a firewall, it falls back to a relay server called TURN so the call still goes through, all while the audio and video stay encrypted the whole time.”
Code Example
# Python pseudo-config passed to a WebRTC client library
ice_servers = [
{"urls": "stun:stun.l.google.com:19302"}, # STUN: discover public address
{
"urls": "turn:turn.example.com:3478", # TURN: relay fallback
"username": "webrtc_user",
"credential": "webrtc_secret",
},
]
# ICE will try direct/STUN candidates first, then fall back to
# the TURN relay only if no direct path succeeds.
peer_config = {"iceServers": ice_servers}
print(peer_config)Follow-up Questions
- What is the difference between STUN and TURN?
- How does ICE choose the best candidate pair?
- What role does SDP play in WebRTC signaling?
- Why does WebRTC require encryption by default?
MCQ Practice
1. What does STUN primarily help a WebRTC client discover?
STUN tells a client how it appears from outside its NAT, enabling direct peer-to-peer connections in most cases.
2. When is a TURN server used in WebRTC?
TURN relays all media traffic when NAT/firewall restrictions prevent a direct connection.
3. How is WebRTC media traffic protected?
WebRTC mandates encryption for media (SRTP) and data channels (DTLS/SCTP) by design.
Flash Cards
What does WebRTC enable? — Real-time peer-to-peer audio, video, and data communication directly between browsers/clients.
STUN vs TURN? — STUN discovers a client's public address for direct connections; TURN relays traffic when direct connection fails.
What framework negotiates the network path? — ICE (Interactive Connectivity Establishment), testing candidate pairs to find a working route.
Is WebRTC media encrypted? — Yes, mandatorily, via SRTP for media and DTLS/SCTP for data channels.