Prompt and scope
Two browsers need an audio, video, or data connection. They may be on the same LAN, behind different NATs, or on networks that block UDP. Explain the setup path and the failure path. The answer should distinguish the signaling channel that exchanges descriptions from ICE, which discovers and checks possible network paths.
Credmark’s public WebRTC interview guide explicitly asks candidates to explain ICE and the roles of STUN and TURN. RFC 8445 defines ICE’s candidate, checklist, and connectivity-check procedures; WebRTC.org documents how a peer connection uses STUN or TURN servers to gather candidates.
What the interviewer evaluates
- Whether you separate signaling, candidate gathering, connectivity checks, and media encryption.
- Whether you explain host, server-reflexive, and relay candidates without promising that STUN “opens a port.”
- Whether you can trade direct-path latency against TURN bandwidth, privacy, and operational cost.
The key signal is a causal timeline: descriptions and candidates move through signaling, checks run over candidate pairs, and only then does the selected path carry encrypted media or data.
Clarifications before answering
- Is signaling already available? ICE does not define your application’s WebSocket, HTTP, or messaging signaling transport.
- Are peers browser-to-browser or behind an SFU? An SFU changes media topology but still needs connectivity to each peer.
- Are UDP and TCP 443 allowed? Firewall policy changes whether host, reflexive, or relay candidates can succeed.
- What is the cost target? A TURN relay carries traffic, so video bitrate and relay percentage determine spend.
A 30-second answer
“Signaling exchanges the SDP offer and answer plus trickled ICE candidates; it is application-specific. Each peer gathers host candidates, asks STUN for a server-reflexive address, and obtains TURN relay candidates when direct paths may fail. ICE forms candidate pairs, sends authenticated connectivity checks, and nominates a working pair. DTLS then authenticates and derives keys for media or data. STUN helps discover a mapped address; TURN relays bytes. A symmetric NAT, blocked UDP, or restrictive firewall may force TURN, so I would measure candidate-pair success, time to connected, relay ratio, and failure by network type.”
Step-by-step deep answer
Step 1: Exchange descriptions through signaling.
The caller creates an offer containing media sections and ICE credentials, then sends it through the application’s signaling service. The callee returns an answer. Signaling also transports trickled candidates and end-of-candidates markers. A signaling server does not carry media merely because it forwards SDP.
Step 2: Gather candidate types.
Host candidates represent local interfaces. A STUN binding request lets the peer learn a server-reflexive candidate containing the public mapped address and port observed by that STUN server. TURN allocation creates a relay candidate; the TURN server becomes the traffic endpoint. Candidate priority and foundation help ICE compare paths, but they do not guarantee that a higher-priority pair will pass.
Step 3: Form and check candidate pairs.
Each side combines its local and remote candidates. ICE orders pairs into a checklist, sends STUN connectivity checks using the ICE credentials, and records responses. A successful check proves that traffic can traverse that pair at that moment; it does not prove future availability. The controlling agent nominates a valid pair, and both peers converge on it.
Step 4: Secure the selected path.
After ICE connectivity, DTLS authenticates the peer and derives keys. SRTP protects audio and video; SCTP over DTLS carries a data channel. ICE chooses reachability; it does not encrypt application payloads. Browser APIs expose connection state and selected-candidate statistics, which are essential for diagnosis.
Step 5: Explain common NAT outcomes.
Same-LAN host candidates often work. A full-cone or compatible NAT may allow server-reflexive candidates. Symmetric NAT mappings, endpoint-dependent filtering, or blocked UDP can make direct candidates fail. TURN over UDP, TCP, or TLS on port 443 provides a relay fallback, with more latency, bandwidth cost, and a larger trust surface.
Step 6: Diagnose failure with evidence.
Log the signaling state, ICE gathering state, ICE connection state, candidate types, pair checks, selected candidate pair, RTT, consent freshness, and network family. Use a controlled matrix of LAN, mobile, symmetric-NAT, VPN, and UDP-blocked networks. If gathering succeeds but checks fail, inspect firewall and NAT policy; if only relay succeeds, improve direct-path policy only after measuring relay cost and call quality.
High-quality sample answer
“I would draw four boundaries. The application signaling service exchanges SDP, ICE credentials, candidates, and end-of-candidates; it is not the media path. Host candidates describe local interfaces, STUN produces server-reflexive mappings, and TURN allocates a relay. ICE combines local and remote candidates, checks pairs with authenticated STUN messages, and nominates a pair. After that, DTLS derives keys, SRTP carries audio/video, and SCTP carries data channels.
Direct host or reflexive paths have lower cost and often lower latency, but symmetric NATs and blocked UDP can require TURN. I would instrument candidate gathering, pair-check errors, time to connected, selected candidate type, relay ratio, RTT, and consent loss by network class. That distinguishes missing signaling from failed NAT traversal and from a connected call with a poor media path.”
Common mistakes
- Calling STUN a relay → STUN reports a mapped address but does not carry the session → reserve relay semantics for TURN.
- Saying signaling establishes media → signaling only transports descriptions and candidates → trace the later ICE checks and selected pair.
- Assuming a successful STUN response proves connectivity → the peer pair may still fail due to filtering → run ICE checks between both candidates.
- Using TURN for every call without measuring → relay bandwidth and latency can dominate cost and quality → prefer direct paths and monitor relay ratio.
- Treating ICE as encryption → ICE checks reachability, not confidentiality → explain DTLS and SRTP/SCTP separately.
Follow-ups and responses
Follow-up 1: Why can STUN work while the peer connection still fails?
STUN only shows that a server observed a mapping from one side. The remote peer may be unable to send to that mapping because the NAT uses endpoint-dependent mappings or filtering, or because a firewall blocks the protocol. ICE must test the complete pair; a successful STUN request is not a path guarantee.
Follow-up 2: When should the system force TURN?
Force or prefer TURN when policy forbids peer addresses, direct checks repeatedly fail, or a controlled network class is known to block UDP. Use short-lived credentials, regional relays, rate limits, and capacity alarms. Forcing TURN globally hides direct-path regressions and raises bandwidth cost, so make it an explicit policy with measurements.
Follow-up 3: The call connects but video is poor. What do you inspect?
Read the selected candidate pair and whether it is relay, RTT, packet loss, jitter, consent freshness, and bitrate adaptation. Compare the same call on direct and relay paths, inspect CPU and encoder queues, and check whether the SFU or TURN region is distant. ICE success proves reachability; it does not prove sufficient capacity or media quality.