Peer Reflexive Candidate

How it works

Peer reflexive candidates are created by the ICE agent when a STUN Binding Request arrives from a source address that doesn't match any known remote candidate. The receiving agent creates a prflx candidate for the observed address and uses it in connectivity checks.

When prflx candidates appear: 1. ICE checks are running using a srflx candidate address 2. Due to symmetric NAT, the actual source port in the STUN check differs from the srflx candidate 3. The remote peer's ICE agent discovers the new address and creates a prflx candidate

In practice: - Most connections don't use prflx candidates – they are an artifact of symmetric NAT interaction - Prflx candidates have higher priority than srflx because they represent a more specific observed path - The WebRTC spec requires support for recognizing and using prflx candidates - Developers rarely need to handle prflx explicitly – the RTCPeerConnection handles it internally

The prflx candidate type appears in RTCIceCandidatePairStats when a prflx path was selected.

SDP Example

# Peer reflexive candidates do NOT appear in the initial SDP offer/answer
# They are discovered during ICE connectivity checks
# and reported via RTCPeerConnection stats

// Check if prflx was used:
const stats = await pc.getStats();
stats.forEach(report => {
  if (report.type === 'candidate-pair' && report.state === 'succeeded') {
    console.log('local candidate type:',
      stats.get(report.localCandidateId)?.candidateType); // may be "prflx"
  }
});