Server Reflexive Candidate

How it works

When a device behind NAT sends a STUN Binding Request to a STUN server, the server sees the public IP and port that NAT assigned (the translated address) and reflects it back in the response. This public address is the server reflexive candidate.

Gathering process: 1. ICE agent sends a STUN Binding Request from a host candidate port to the STUN server 2. STUN server responds with the XOR-MAPPED-ADDRESS – the public IP:port it saw 3. ICE agent creates an srflx candidate with that public address 4. The raddr and rport attributes record the original host candidate (for ICE consistency checks)

NAT types where srflx works (RFC 4787): Full-cone NAT: any external host can reach the mapped port Address-restricted cone: any packet from the destination IP is accepted Port-restricted cone: packets only accepted from the specific IP:port already contacted

NAT type where srflx fails: Symmetric NAT: assigns a different external port for each destination – the STUN-discovered port only works for the STUN server, not for the actual peer. Requires TURN relay.

Free STUN servers: Google operates stun.l.google.com:19302 (used by many apps). For production, deploy your own STUN server (Coturn) to avoid dependency on third-party uptime.

SDP Example

# Server reflexive candidate in SDP
a=candidate:2 1 UDP 1686052607 203.0.113.1 54321 typ srflx
  raddr 192.168.1.5 rport 12345 generation 0
#                              ^ raddr/rport: the host candidate it came from
#              ^ public IP seen by STUN server
#                          ^ public port assigned by NAT

# STUN servers in RTCPeerConnection config:
const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
});