WebRTC ICE failed / ICE connection failed

The browser collected local addresses, talked to a STUN/TURN server, and still could not build a working path to the other peer. Media never starts (or dies right after connecting).

What ICE is doing

Interactive Connectivity Establishment (ICE) gathers address candidates (host, server-reflexive via STUN, relay via TURN), exchanges them through your signalling channel, then probes pairs until one works. When every pair fails you see:

ICE failed
// Chrome: iceConnectionState → "failed"
// Firefox: ICE failed, see about:webrtc
// Safari: WebRTC: ICE failed — check console / Web Inspector

Offer/answer may succeed while ICE still fails: SDP negotiated codecs, but packets never arrive.

Checklist (most common first)

1. No STUN / bad STUN — iceServers: [] only works on the same LAN. Use at least one public STUN (e.g. your own or a known public server). Verify with chrome://webrtc-internals / about:webrtc that srflx candidates appear.
2. Symmetric NAT / corporate firewall — host + STUN is not enough. You need a TURN server with credentials (urls: turn:… / turns:…). Coturn and managed TURN products are the usual fix for “works at home, fails on guest Wi‑Fi / mobile data”.
3. UDP blocked — some networks drop UDP entirely. Configure TURN to offer TCP or TLS (turn:?transport=tcp, turns: on 443) so media can relay.
4. Candidates never exchanged — trickle ICE: send every onicecandidate over signalling; call addIceCandidate on the remote. Ending too early (null candidate ignored, or signalling closed) leaves one side with an incomplete set.
5. mDNS / privacy host candidates — browsers may hide LAN IPs behind .local names. Fine same-machine; across networks you still need STUN/TURN.
6. One-way media / wrong direction — transceiver direction, muted tracks, or forgetting addTrack before createOffer. ICE can show connected while you still see a black tile — check tracks separately.
7. VPN / dual-stack surprises — IPv6-only vs IPv4-only peers, or a VPN that black-holes UDP. Try without VPN; prefer TURN when paths differ.

Debug in two minutes

pc.oniceconnectionstatechange = () => console.log(pc.iceConnectionState);
pc.onconnectionstatechange = () => console.log(pc.connectionState);
pc.onicecandidateerror = (e) => console.warn(e.errorCode, e.url, e.errorText);
// Chrome: chrome://webrtc-internals → select the PeerConnection → IceCandidate pair
// Firefox: about:webrtc

Signalling vs media

• Signalling (WebSocket, SSE, HTTP) only carries SDP and candidates. A healthy socket with ICE failed still means the media path is broken.
• Media usually uses UDP to STUN/TURN/peer. Packet loss on a thin pipe makes the call blocky or frozen — see the free lesson why video calls go blurry (bitrate / compression), separate from ICE failure.

Not the same as

• NotAllowedError getUserMedia — permission / HTTPS / device, before ICE matters.
• WebSocket connection failed — signalling never connected.
• TypeError: Failed to fetch — ordinary HTTP fetch, not PeerConnection.
• ECONNRESET / ETIMEDOUT — server-side TCP errors; different stack.

Related

WebSocket connection failed · NotAllowedError getUserMedia · Failed to fetch · ERR_NAME_NOT_RESOLVED · CORS error explained · Wirebook: video-call compression

Questions

Published 6 November 2026.