WebRTC, ICE, STUN and TURN explained

WebRTC negotiates a possible path rather than simply opening a port#

A browser usually runs behind NAT, often without knowledge of its public address or network policy. The other endpoint may be on another network, behind another NAT or in carrier infrastructure. ICE organises finding a pair of addresses that can carry media.

In simplified terms, an endpoint gathers candidates, exchanges them through signalling, tests connections and selects a working pair. Signalling may use SIP over WebSocket, a custom API or another channel. ICE does not define how the offer is delivered between endpoints.

Three main candidate types#

An ICE candidate includes an address, port, transport, priority and type. The most common are:

Example line:

a=candidate:1 1 UDP 2122260223 192.168.1.20 54436 typ host

A host candidate can work on the same LAN or over a VPN. An srflx candidate permits attempts through a NAT mapping. A relay candidate is the most broadly applicable because both sides communicate with a reachable TURN server.

STUN discovers a mapping but does not guarantee a path#

The client sends a Binding Request to a STUN server and receives its externally visible address and port. This produces a server-reflexive candidate. If NAT and firewall policies permit the peer to send packets to that mapping, media can flow without a relay.

The mapping may, however, depend on the destination. An address discovered through STUN need not behave the same way towards another peer. The network may also block incoming UDP, have a short timeout or use CGNAT.

TURN provides a controlled relay point#

TURN allocates an address on its server to the client. The other endpoint sends media to that address, and TURN forwards it to the client. This improves reliability on restrictive networks but consumes server bandwidth and adds another hop.

TURN should offer at least UDP and often TCP and TLS as fallback paths. Typical listening ports are 3478 for STUN/TURN and 5349 for TURN over TLS, but the control connection alone is insufficient. Open the relay range from which the server allocates ports.

Example topology:

Browser A ----\
               TURN relay ---- Media gateway / Browser B
Browser B ----/

TURN credentials should not be permanent secrets embedded indefinitely in public JavaScript. Production systems should generate short-lived credentials or retrieve them after user authentication.

ICE checks and candidate pair selection#

After exchanging candidates, endpoints create a list of pairs. Connectivity checks use STUN to verify that packets pass in both directions. One side is controlling, the other controlled. The selected pair becomes the media path.

Priorities generally prefer direct connections, with relay as a fallback. Do not diagnose solely from candidate order in SDP. Inspect the actual pair using:

• Chrome: chrome://webrtc-internals,
• Firefox: about:webrtc,
• the RTCPeerConnection.getStats() API,
• WebRTC library or gateway logs.

Look for selectedCandidatePair, local and remote candidate types, sent/received byte counts, RTT and ICE state changes.

Trickle ICE is faster but needs correct signalling#

Without trickle ICE, the application waits until candidate gathering finishes before sending the full offer. Trickle ICE sends candidates as they are discovered. It shortens setup, but the signalling channel must correctly handle additional messages and completion of gathering.

Common errors:

• candidates arrive before the remote description is created,
• the application loses candidates during a WebSocket reconnect,
• end-of-candidates is not handled,
• the gateway does not support trickle while the client uses it,
• an mDNS candidate is treated like a normal DNS address.

If a connection works only on its second attempt, check the order of setLocalDescription, setRemoteDescription and addIceCandidate.

DTLS-SRTP: reachability is not yet media#

After selecting a path, WebRTC establishes DTLS, agrees keys and protects RTP with SRTP. The SDP fingerprint binds the DTLS certificate to the negotiation. An ICE state of connected therefore does not guarantee audio. DTLS may fail to complete its handshake, the fingerprint may mismatch or the gateway may use the wrong role.

Diagnostic order:

1. Did signalling exchange complete SDP?
2. Did ICE select a candidate pair?
3. Do STUN packets arrive in both directions?
4. Did the DTLS handshake succeed?
5. Are SRTP packets present and byte counters increasing?
6. Is the track active and not muted by the application?

This order separates networking, cryptography and application logic.

Ports and firewalls in practice#

For a TURN server, check three traffic groups:

• client → TURN ports for UDP/TCP/TLS,
• the relay range used by allocations,
• TURN → peer or media gateway communication.

In a cloud environment, the host firewall may be correct while a security group still blocks the range. Publishing only 3478 in Docker does not automatically publish relay ports. If coturn runs without host networking, mapping a wide range requires deliberate configuration and performance assessment.

WebSocket signalling also needs correct WSS, a certificate and a reverse proxy supporting Upgrade. A signalling error can resemble ICE failure because candidates never reach the other endpoint.

Common failure patterns#

Works on the LAN, fails from the Internet#

Usually a host candidate is being used while srflx or relay is unavailable. Check iceServers, DNS, credentials and TURN ports.

Works over Wi-Fi, fails on a corporate network#

The network may block UDP. TURN over TCP/TLS is needed, often on a port allowed by organisation policy. Also assess proxies, TLS inspection and timeouts.

ICE connected, but no audio#

Move to DTLS-SRTP, tracks, codecs and the sendrecv direction. Check whether the selected pair's bytesSent and bytesReceived increase.

The connection drops after a network change#

Switching from Wi-Fi to LTE may require an ICE restart. The application and gateway must handle a new generation of credentials and candidates.

Minimum production checklist#

• At least two independent TURN addresses or a high-availability mechanism.
• UDP as the preferred path and TCP/TLS as fallback.
• A bounded, explicit relay port range.
• Short-lived credentials and abuse controls.
• Monitoring of allocations, bandwidth, authentication errors and response time.
• Tests from LTE, CGNAT, corporate networks and restrictive Wi-Fi.
• Recording of the selected candidate pair in client diagnostics.
• Alerts for absent relay candidates or a rising share of failed ICE connections.

WebRTC becomes predictable when ICE stops being a black box. Candidates describe options, connectivity checks confirm the path, DTLS protects media, and statistics show what was actually selected.