Overview
Server reflexive candidates (srflx) are discovered using STUN (Session Traversal Utilities for NAT) servers. They represent the public IP address and port mapping allocated by a NAT device, enabling peer-to-peer connections across NATs.CandidateServerReflexive
A server reflexive candidate represents a public address binding allocated by a NAT, discovered through STUN.candidate_server_reflexive.go
candidateBase which provides common functionality like priority calculation, marshaling, and traffic tracking.
Creating Server Reflexive Candidates
NewCandidateServerReflexive
Creates a new server reflexive candidate from the provided configuration.Configuration for the server reflexive candidate.
CandidateServerReflexive or an error if the configuration is invalid (e.g., invalid IP address).
CandidateServerReflexiveConfig
Configuration structure for creating server reflexive candidates.candidate_server_reflexive.go
Configuration Fields
Unique identifier for the candidate. If empty, a UUID will be automatically generated.
Network protocol: “udp”, “tcp”, “udp4”, “udp6”, “tcp4”, or “tcp6”.
The public IP address discovered via STUN (the reflexive address).
Port number of the public address.
Component identifier. Use
ComponentRTP (1) for RTP or ComponentRTCP (2) for RTCP.Custom priority value. If 0, priority will be calculated automatically. Server reflexive candidates have a type preference of 100.
Custom foundation string. If empty, foundation will be calculated as a CRC32 checksum of the candidate type, address, and network type.
The base (local) IP address from which the STUN request was sent.
The port of the base (local) address.
Examples
Creating a Server Reflexive Candidate
Accessing Related Address
Creating an IPv6 Server Reflexive Candidate
STUN Usage
Server reflexive candidates are discovered through the STUN protocol. The typical discovery process is:- Send STUN Binding Request - Send a STUN request from a local interface to a STUN server
- Receive STUN Response - The STUN server responds with the public IP and port it observed
- Create Candidate - Create a server reflexive candidate with the discovered address
- Set Related Address - Record the local interface as the related address
Example STUN Integration
Priority Calculation
Server reflexive candidates have a type preference of 100:When to Use Server Reflexive Candidates
Server reflexive candidates are essential when:- Peers are behind different NATs
- Direct peer-to-peer connections need NAT traversal
- You want to avoid TURN server overhead
- The NAT allows inbound traffic after outbound binding
- Both peers can reach public STUN servers
NAT Compatibility
Server reflexive candidates work with most NAT types:Works perfectly. Single public binding for all destinations.
Works well. Requires coordination between peers.
Works with ICE connectivity checks.
May require peer reflexive candidates or relay candidates.
Related Address
The related address for a server reflexive candidate is the base (host) candidate from which it was derived:- Debugging NAT behavior
- Understanding address mappings
- Diagnostics and logging
Connection Characteristics
Advantages:- Direct peer-to-peer connectivity through NAT
- No media relay required
- Lower latency than relay candidates
- No server bandwidth costs for media
- Works with most NAT types
- Requires STUN server for discovery
- May not work with symmetric NATs
- Higher priority than relay but lower than host
- Depends on NAT binding timeout
Common Patterns
Multiple STUN Servers
Query multiple STUN servers for redundancy:Caching STUN Results
Cache discovered public addresses to avoid repeated STUN queries:NAT bindings typically have timeouts (often 30-300 seconds). Ensure keepalives are sent to maintain the binding if long-lived connections are needed.
See Also
- Candidate Types - Core candidate interfaces and types
- Host Candidates - Direct local interface candidates
- Peer Reflexive Candidates - Candidates discovered during connectivity checks
- Relay Candidates - TURN-based relay candidates