ICE Candidate: what it is, candidate types and how it works

What is an ICE Candidate?

ICE Candidate (Interactive Connectivity Establishment Candidate) is a fundamental unit in the process of establishing a P2P connection via the WebRTC protocol. It represents an IP address + port pair that can be used for data transmission between two peers. Each candidate contains information about the transport protocol (UDP, TCP), connection type, and priority.

An ICE Candidate is generated on each device individually. The device collects all available network interfaces, requests an external address via a STUN server, and adds a relay address from a TURN server. The resulting list of candidates is sent to the remote peer through a signaling channel in SDP (Session Description Protocol) format.

According to RFC 8445 (IETF, 2018), ICE uses a nominated pairs mechanism: after gathering all candidates, they are tested pairwise through STUN requests. The pair that passes the check first is declared nominated and used for multimedia transmission. The remaining pairs stay on reserve in case the connection drops.

The Role of ICE in the WebRTC Stack

WebRTC is an open standard for P2P communications, but a direct connection between devices is often impossible due to NAT (Network Address Translation) and firewalls. ICE Candidate solves this problem by offering several alternative connection paths. The ICE (Interactive Connectivity Establishment) protocol is a mandatory component of WebRTC and is described in the W3C WebRTC specification (2025).

Many mobile application developers use WebRTC libraries such as Google WebRTC (for Android) and native wrappers for iOS. In each of them, the ICE process is managed automatically, but understanding candidate types allows the developer to configure server infrastructure and optimize connection quality.

SDP Format with ICE Candidates

An ICE Candidate is transmitted within an SDP message as a=candidate attributes. Each line contains a foundation, component ID, transport protocol, priority, IP address, port, and candidate type. Below is an example of an SDP fragment with three candidates of different types:

// Sample SDP with ICE candidates
a=candidate:1 1 UDP 2130706431 192.168.1.10 54321 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.5 54322 typ srflx
a=candidate:3 1 TCP 1019212287 198.51.100.7 54323 typ relay raddr 203.0.113.5 rport 3478

The priority field determines the order of candidate testing. The higher the priority, the earlier the candidate will be checked. Host candidates always have the highest priority, relay candidates the lowest.

Types of ICE Candidates

The RFC 8445 specification defines four types of ICE candidates, each corresponding to a specific way of reaching a remote peer. The candidate type affects its priority, connection setup time, and server infrastructure requirements.

Host Candidates

A host candidate is formed from the IP address of the device's local network interface. If the device is on the same local network as a peer, the host candidate provides a direct connection with minimal latency. For mobile devices, host candidates are generated for the WiFi interface, cellular LTE/5G connection, and if necessary — for VPN tunnels.

Host candidates have the highest priority (2130706431 for UDP) and are tested first. If both peers are behind NAT, their host candidates will be private addresses (192.168.x.x, 10.x.x.x) and a direct connection via them is impossible. ICE then proceeds to test srflx and relay candidates.

SRFLX and PRFLX Candidates

An SRFLX (Server Reflexive) candidate is an external IP address and port obtained from a STUN server. When a device sends a STUN request, the server sees its public address after NAT and returns it back. This candidate allows establishing a direct connection between peers behind different NATs, if their NAT devices support Hairpinning.

A PRFLX (Peer Reflexive) candidate is discovered dynamically when a STUN request from one peer arrives at an unexpected address. This type occurs when both peers send requests simultaneously and NAT creates a temporary binding. A PRFLX candidate has higher priority than srflx but lower than host.

In mobile applications, srflx candidates are especially important when switching between WiFi and cellular networks. When a device changes network, the IP address changes, and ICE must re-gather candidates. This process is called an ICE restart and requires sending a new SDP.

Relay Candidates via TURN

A relay candidate is an address on a TURN server through which traffic is relayed from one peer to another. This type is used as a fallback when a direct P2P connection is impossible (symmetric NAT, corporate firewall). A relay channel adds latency and increases server load, so in optimal configurations, the TURN server is used for only 10–15% of all sessions.

Popular TURN server implementations include: coturn (open source), Twilio Network Traversal, Metered TURN. The choice of TURN provider affects media connection quality in mobile applications — the server should be geographically close to users to minimize additional latency.

How the ICE Process Works

The ICE process is a multi-stage protocol that guarantees establishing a reliable P2P connection in conditions of network topology uncertainty. The algorithm is described in RFC 8445 and includes four mandatory phases: candidate gathering, sorting, testing, and nomination.

Phase 1: Candidate Gathering

Each device gathers all available network addresses. To do this, the WebRTC engine enumerates local interfaces (host), sends a request to a STUN server (srflx), and requests a relay address from a TURN server. Simultaneously, the device may discover a prflx candidate if it receives an incoming STUN request from a peer.

In mobile development, this stage is critical for connection setup time. On iOS and Android, candidate gathering can take from 200 ms to 2 seconds depending on network speed, STUN/TURN server availability, and the number of active network interfaces.

Phase 2: Pair Formation and Sorting

After receiving the list of candidates from the remote peer via the signaling channel, the local ICE engine forms all possible candidate pairs (local + remote). Each pair receives a priority according to the formula from RFC 8445, taking into account the priorities of both candidates and the direction (incoming/outgoing).

Pairs are sorted in descending order of priority. The best pairs are tested first. The algorithm guarantees that a host-host pair will be checked before a host-srflx, host-relay, or relay-relay pair, minimizing connection delay in simple network configurations.

Phase 3: Testing and Nomination

ICE sends STUN binding requests for each candidate pair. If a STUN response is received — the pair is valid. The first valid pair is nominated as the primary. The WebRTC engine begins transmitting media over this pair, while the remaining pairs continue to be checked in case the primary fails.

The testing process can take up to several seconds with a large number of candidates. WebRTC uses timers: for host pairs the timer is aggressive (20 ms), for relay pairs — more conservative (200 ms). Mobile application developers can speed up the connection by limiting the number of ICE servers or configuring iceTransportPolicy.

ICE Restart

ICE restart is a restart of the ICE process without recreating the entire RTCPeerConnection. It is necessary when changing networks, losing connection, or switching between WiFi and mobile networks. During a restart, all current candidates are discarded, and the process starts anew with generating new ufrag and pwd.

In iOS development, ICE restart is invoked by the restartIce() method on RTCPeerConnection. On Android, a similar method is used in the PeerConnection class from Google WebRTC. Proper ICE restart handling is a critical requirement for applications running on mobile devices with unstable network connections.

STUN and TURN Servers in ICE

STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT) are key server components without which ICE Candidate cannot guarantee successful connectivity in real internet conditions. Their proper configuration directly affects call quality in mobile applications.

STUN: External Address Discovery

A STUN server allows a device to discover its public IP address and port that NAT allocated for the outgoing connection. The STUN protocol is defined in RFC 8489 and operates over UDP on port 3478, also supporting TCP. Google provides public STUN servers (stun.l.google.com:19302) that can be used for free.

In mobile development, a STUN request is a lightweight operation taking 50–200 ms. However, some corporate and mobile networks block UDP traffic, forcing ICE to use TCP for STUN communication or fall back directly to TURN.

TURN: Traffic Relay

A TURN server is a media traffic relay. When a direct P2P connection is impossible (symmetric NAT, firewall), the device sends data to TURN, which forwards it to the other peer. TURN is a reliable but costly mechanism: it adds latency (30–100 ms) and requires server bandwidth equal to the sum of all media sessions.

According to the WebRTC Stats Report (2025), about 8–15% of WebRTC sessions on mobile networks require TURN. To optimize TURN traffic costs, developers use preliminary connection testing and activate the TURN channel only if P2P fails.

Choosing STUN/TURN for a Mobile Application

When choosing infrastructure for ICE in a mobile project, the following factors are considered: geographical location of servers to minimize latency, UDP and TCP support, TURN traffic cost, and SLA. Popular solutions include: coturn for self-hosting, Twilio, Agora, and LiveKit for cloud-based use.

ICE Candidate in Mobile Development

For mobile developers, understanding ICE Candidate goes beyond theory — it is a practical necessity when building applications with voice and video calls. The iOS and Android platforms provide native WebRTC APIs that automate ICE handling, but the developer is responsible for configuring ICE servers and handling network change events.

ICE Configuration on iOS

On iOS, WebRTC is available through the WebRTC.framework or the GoogleWebRTC library via CocoaPods. ICE servers are configured through an array of RTCIceServer in RTCConfiguration:

let config = RTCConfiguration()
let stunServer = RTCIceServer(urlStrings: ["stun:stun.l.google.com:19302"])
let turnServer = RTCIceServer(urlStrings: ["turn:turn.example.com:3478"],
                                    username: "user",
                                    credential: "pass")
config.iceServers = [stunServer, turnServer]
let pc = RTCPeerConnection(configuration: config)

After creating an RTCPeerConnection and calling offer() or answer(), the engine automatically gathers ICE candidates. The iceGatheringStateChange event notifies about changes in the gathering status, while iceConnectionState reports the connection state.

ICE Configuration on Android

Android uses the same Google WebRTC library. ICE servers are set via PeerConnection.RTCConfiguration. The developer can manage ICE policy through iceTransportsType — the relay mode forcibly uses only TURN, which increases reliability but adds latency:

val iceServers = listOf(
    PeerConnection.IceServer.builder("stun:stun.l.google.com:19302").createIceServer(),
    PeerConnection.IceServer.builder("turn:turn.example.com:3478")
        .setUsername("user")
        .setPassword("pass")
        .createIceServer()
)
val config = PeerConnection.RTCConfiguration(iceServers)
config.iceTransportsType = PeerConnection.IceTransportsType.ALL
config.bundlePolicy = PeerConnection.BundlePolicy.MAXBUNDLE

The bundlePolicy parameter affects the number of ICE candidates — MAXBUNDLE mode combines all media streams into one transport, reducing the total number of candidates and speeding up the connection.

Handling ICE Events in Mobile Applications

Key ICE events that a developer should handle include: ICE connection state, ICE gathering state, and new candidate discovery. After ICE completes gathering and testing, its state transitions to connected or completed.

In mobile networks, switches between WiFi and cellular connectivity are frequent. When the network changes, ICE must perform a restart, otherwise the media stream is interrupted. Developers implement monitoring of NetworkManager (iOS) or ConnectivityManager (Android) to automatically call restartIce().

A successful ICE implementation in a mobile application includes: choosing reliable STUN/TURN servers, proper ICE restart handling on network change, configuring iceConnectionState for UI status display, and monitoring statistics via RTCStatsReport.