How WebRTC Clients Discover Public IPs Using STUN

This article explains how WebRTC clients use STUN (Session Traversal Utilities for NAT) servers to discover their public IP addresses and port numbers. It covers the limitations of local network environments, the step-by-step communication process between a client and a STUN server, and how this discovered information is utilized to establish direct peer-to-peer connections across the internet.

The Challenge of Network Address Translation (NAT)

Most consumer devices do not have unique, public IP addresses. Instead, they operate behind routers that use Network Address Translation (NAT). A router assigns private IP addresses (such as 192.168.1.5) to devices on the local network and shares a single public IP address to communicate with the wider internet.

While this system conserves IPv4 addresses and enhances security, it poses a major obstacle for WebRTC. To establish a direct peer-to-peer (P2P) connection, two devices must know each other’s public-facing IP addresses and port numbers. Because a device inside a local network is unaware of the external NAT mapping, it cannot share its public contact information without external help.

How the STUN Server Acts as a Mirror

A STUN server is a lightweight, public-facing server that assists WebRTC clients in discovering their public network presence. The process is highly efficient and functions similarly to looking into a mirror.

Here is the step-by-step process of how a WebRTC client discovers its public IP using STUN:

  1. The STUN Binding Request: The WebRTC client initiates the process by sending a lightweight UDP packet called a “STUN Binding Request” to the STUN server’s public IP address.
  2. NAT Translation: As the packet passes through the client’s local router (the NAT device), the router modifies the packet’s header. It replaces the client’s private IP and port with the router’s public IP and a dynamically allocated port.
  3. Inspection by the Server: The STUN server receives the packet. Because the packet had to pass through the NAT, the source IP and port displayed in the packet header are the client’s public-facing credentials.
  4. The STUN Binding Response: The STUN server copies this public IP address and port number from the packet header and writes them directly into the body (payload) of a “STUN Binding Response” packet.
  5. Delivery and Discovery: The server sends this response packet back to the client. When the client receives and parses the packet, it reads its own public IP address and port from the payload.

Integrating Discovered IPs into WebRTC Connection Establishment

Once the client successfully extracts its public IP and port from the STUN response, this pair is labeled as a “Server Reflexive Candidate” (srflx).

The client then bundles this candidate, along with its local network candidates, into an Interactive Connectivity Establishment (ICE) candidate list. These candidates are exchanged with the remote peer via a signaling server. The peers then test these address pairs to find the most direct and efficient network path to establish the secure, real-time media or data channel.