Host vs Server Reflexive vs Relay ICE Candidates

This article explains the technical differences between host, server reflexive (srflx), and relay (relay) ICE candidates within the WebRTC framework. We will examine how Interactive Connectivity Establishment (ICE) gathers these candidates, the distinct roles of STUN and TURN servers, and how WebRTC peers utilize these different candidate types to successfully traverse NATs and firewalls to establish a real-time connection.

What is an ICE Candidate?

In WebRTC, an Interactive Connectivity Establishment (ICE) candidate represents a potential network path (an IP address, port, and transport protocol) that a device can use to receive data. During the connection establishment phase, WebRTC peers gather and exchange these candidates to find the most efficient and reliable path for peer-to-peer (P2P) communication.

There are three primary types of ICE candidates used in this process, each generated through a different networking mechanism.

1. Host Candidates

A Host Candidate represents the actual physical or virtual network interface of the local device.

• How they are gathered: The WebRTC agent queries the local operating system to list all active network interface cards (NICs), such as Wi-Fi adapters, Ethernet ports, or VPN tunnels.
• IP Address Type: These are typically private IP addresses (e.g., 192.168.x.x or 10.x.x.x) assigned by a local router, though they can be public IP addresses if the device is connected directly to the internet without a router.
• Use Case: Host candidates are used when both WebRTC peers are on the same local network (LAN).
• Priority: Host candidates have the highest priority in the ICE negotiation process because they offer the lowest latency and bypass external routing.

2. Server Reflexive (srflx) Candidates

A Server Reflexive Candidate represents the public IP address and port allocated to a device by a Network Address Translator (NAT) or router.

• How they are gathered: Because a device behind a NAT does not know its own public IP address, it sends a binding request to an external STUN (Session Traversal Utilities for NAT) server. The STUN server observes the source IP address and port of the incoming packet and sends this information back to the client in the response.
• IP Address Type: A public IP address and a mapped port assigned by the local NAT/firewall.
• Use Case: Used when peers are located behind different NATs (e.g., two users in different homes) but the NAT behavior allows direct incoming traffic once an outbound connection is initiated.
• Priority: Server reflexive candidates have medium priority. They are preferred over relay candidates because, once established, the traffic still flows directly peer-to-peer without an intermediary server.

3. Relay Candidates

A Relay Candidate represents a public IP address and port hosted on a third-party server that relays traffic between the two peers.

• How they are gathered: The client connects to a TURN (Traversal Using Relays around NAT) server and requests an allocation. The TURN server reserves a specific IP address and port on its own system for the client’s session.
• IP Address Type: The public IP address and port of the TURN server itself.
• Use Case: Used as a fallback when peers are behind restrictive firewalls or symmetric NATs. In a symmetric NAT scenario, the NAT changes the port mapping for every destination, preventing STUN from working. If direct peer-to-peer communication is impossible, the TURN server acts as a proxy, receiving media from Peer A and forwarding it to Peer B.
• Priority: Relay candidates have the lowest priority. Because traffic must pass through an intermediate server, it increases latency, introduces server bandwidth costs, and is no longer strictly peer-to-peer.

Summary of Differences