What Is a STUN Server? NAT Traversal for SIP and WebRTC

A STUN server exists to answer one question for a device sitting behind a router: what does my address look like from the outside? A phone or a browser on a private network knows its own local IP, but that address means nothing to a peer on the public internet. Network Address Translation (NAT) rewrites the source address on the way out, so the endpoint has no way to know the public IP and port a remote party would actually send media to. STUN closes that gap.

STUN (Session Traversal Utilities for NAT) is a small protocol that lets an endpoint discover its own public-facing address and, in some cases, the type of NAT in front of it. It is one of three cooperating pieces of NAT traversal, alongside TURN and ICE, and it shows up constantly in WebRTC and occasionally in SIP. In this article, we’ll walk you through what a STUN server actually does on the wire, how STUN, TURN, and ICE divide the work, and why the SIP world and the WebRTC world solve the same NAT problem in very different ways. If you run voice infrastructure or build browser-based communications, this is the piece that explains why some calls connect instantly and others fail with one-way audio.

The Problem STUN Solves: NAT Hides Your Real Address

Most endpoints do not have a public IP address. A softphone on an office LAN, a browser on home Wi-Fi, or a mobile handset on a carrier network all sit behind at least one layer of NAT. The router hands the device a private address (something in the 10.x, 172.16.x, or 192.168.x ranges) and translates it to a shared public address on the way out.

That works fine for the request-response pattern of web browsing, where the device always initiates and the server only ever replies on the same connection. Real-time voice and video break the pattern. In a call, each side has to tell the other where to send media, and the address a device knows about itself is the private one the NAT will discard. If a browser puts 192.168.1.40 in its media offer, a peer on the public internet has nowhere to send packets. The result is the classic failure mode: signaling completes, the phone rings, someone answers, and then there is silence in one or both directions.

The reason one-way audio is so common is that the two halves of a call traverse NAT independently. The RTP media travels on different ports than the SIP signaling, and the media ports have to be reachable from the outside for audio to flow. NAT that permits the signaling can still block or misdirect the media. To go deeper on how signaling and media separate in a SIP call, SIP Signaling Fundamentals walks through the message flow that sets up the media path.

How a STUN Server Works

STUN is deliberately simple. The endpoint sends a Binding request to a STUN server that has a public IP. The server looks at the source address of the packet as it arrived, which is the public address and port the NAT assigned, and copies that into a Binding response. When the endpoint reads the response, it learns its own server-reflexive address: the address the outside world sees.

The exchange is a single round trip in the common case. The endpoint now knows a public address it can advertise to peers, and because the NAT created a mapping when the request went out, packets arriving at that address from the same destination can usually flow back in. STUN runs over UDP on port 3478 by default, with STUN over TLS-over-TCP on 5349 for the encrypted variant. The protocol was originally defined in RFC 3489 (“classic STUN”), RFC 5389 and modernized in RFC 8489.

Why STUN alone is not always enough

STUN works when the NAT keeps the same external mapping regardless of who the endpoint is talking to. Many home and small-office routers behave this way, and for them a single STUN query is enough to make a direct peer-to-peer path work. Symmetric NAT is common on corporate firewalls and mobile carrier networks, and it is the single biggest reason a direct path fails and the call has to fall back to a relay.

STUN also tells the endpoint nothing about the peer’s NAT. Both sides have to succeed for a direct path to exist, so even a perfect STUN result on one side does not guarantee connectivity. This is why STUN is almost never used on its own in production; it is the cheap first attempt inside the larger ICE process.

STUN vs TURN vs ICE: How the Three Fit Together

These three are often named in the same breath and just as often confused. They are not competing options; they are layers of one strategy, from simplest to most reliable.

STUN discovers your public address so a direct peer-to-peer path can be attempted. It adds no ongoing cost once the call is up, because the media flows directly between endpoints and the STUN server drops out of the picture after setup.

TURN is the fallback for when a direct path cannot be built, which happens whenever symmetric NAT or a restrictive firewall blocks the server-reflexive candidates. A TURN server relays every media packet for the whole call, so it consumes real bandwidth and has to be scaled to the fraction of calls that need it. TURN is defined in RFC 8656, and a TURN server can answer plain STUN queries too, which is why the two are usually deployed as one service.

ICE is the decision engine that ties everything together. An endpoint gathers candidates from all sources: its host addresses, its server-reflexive addresses from STUN, and its relayed addresses from TURN. It exchanges that list with the peer, pairs the candidates, and runs connectivity checks to find the best pair that actually works. ICE prefers the direct path and falls back to the relay only when it must. The full framework is specified in RFC 8445.

The practical takeaway: you deploy STUN and TURN, and ICE decides per call which one wins. Plan TURN capacity for the worst-case fraction of users who cannot find a direct path, not the average. In deployments with heavy enterprise or mobile traffic, that fraction is regularly above 20 percent.

STUN and WebRTC: NAT Traversal Is Built In

WebRTC bakes NAT traversal into the platform. Every browser PeerConnection runs ICE, gathers STUN and TURN candidates, and negotiates connectivity automatically. A network manager configures the STUN and TURN server addresses in the iceServers array and the browser handles the rest, including Trickle ICE, where candidates are sent to the peer as they are discovered rather than waiting for the full list.

This is by design. WebRTC assumes the two endpoints will solve NAT themselves, which is the right call when both ends are smart browsers that can run the full ICE state machine. Public STUN servers are cheap and plentiful, so discovering a server-reflexive address costs almost nothing. TURN is the part that costs money, because a browser behind a restrictive corporate NAT will relay its media for the entire call, and the operator pays for those bytes in both directions.

The design decisions behind WebRTC’s mandatory ICE, encryption, and codec choices are covered in WebRTC vs SIP: Differences and Use Cases, which is the right starting point if you are choosing between the two stacks for a new project.

STUN and SIP: A Different Philosophy

SIP predates the ICE framework and takes the opposite approach to NAT. Where WebRTC pushes traversal into the endpoints, classic SIP assumes the network operator will solve it. Most SIP endpoints do not run ICE at all. Some support STUN as a standalone setting so a phone can learn its public address and rewrite the SDP accordingly, but this is fragile: it breaks on symmetric NAT, it depends on every device being configured, and it puts the burden on endpoints that are often locked-down desk phones with no ICE state machine.

In practice, carrier and enterprise SIP networks handle NAT at the edge with a Session Border Controller instead of asking endpoints to traverse it themselves. The SBC presents a single, static public address to the outside world and anchors all media through it. Because an SBC is a B2BUA that fully terminates and re-originates each call, it controls the media path on both legs and never has to guess an endpoint’s public address from the SDP.

How an SBC handles NAT without STUN or ICE

The key technique is far-end NAT traversal. When media arrives from an endpoint behind NAT, the SBC ignores the private address the endpoint wrote into its SDP and instead learns the real public source address from the packets as they arrive, then sends return media to that observed address. This is the same insight STUN uses, applied at the network edge by the SBC rather than by the endpoint. Combined with topology hiding, which conceals internal addresses, the SBC becomes the one element with a stable public identity that every peer can reach.

This is also why a plain SIP proxy cannot solve NAT the way an SBC can. A proxy forwards signaling without touching media, so it has no way to anchor the media path or observe the real source address. The proxy-versus-B2BUA distinction is exactly what determines whether a device can handle NAT at all, and it is worth understanding before choosing an edge element.

Where the Two Worlds Meet: WebRTC-to-SIP

The interesting case is a call that starts in a browser and ends on a SIP trunk or the PSTN. The browser side runs full ICE and expects STUN and TURN; the SIP side expects a single static address and no ICE. A WebRTC-to-SIP gateway bridges the two by running ICE on the browser leg and presenting a fixed RTP socket on the SIP leg, absorbing the asymmetry so neither side has to change.

In the common two-tier production pattern, a dedicated WebRTC gateway (Janus, Kamailio, OpenSIPS, or a CPaaS application server) terminates the browser-facing leg with its own STUN and TURN infrastructure, then hands a normalized SIP session to an SBC that handles the carrier-facing leg. The full breakdown of that boundary, including how ICE termination and media re-keying work, is in WebRTC-to-SIP Gateway Architecture.

ProSBC sits on the SIP-facing side of that pattern. It does not terminate WebSocket signaling or run browser-side ICE; the WebRTC gateway in front of it does. ProSBC takes the normalized SIP session and applies the carrier-side work: presenting a stable public address, far-end NAT traversal for SIP endpoints, SIP over TLS, SRTP for media, and per-trunk-group SIP header manipulation so each carrier gets the SDP it expects.

Common STUN and NAT Traversal Failures

When NAT traversal goes wrong, the symptoms cluster into a few recognizable patterns. Reading them correctly saves hours of guessing.

Call hold/resume/termination procedures are not functioning correctly happens because each one is a new SIP request and the NAT does not associate the request as being a part of an existing transaction, which leads to call drops or zombie quests.

One-way or no audio after a call connects is the signature of a media path that never opened, usually because one side advertised a private address that the other could not reach and no relay was available. On WebRTC this points at a missing or unreachable TURN server; on SIP it points at an endpoint doing its own broken STUN behind symmetric NAT.

Calls that work internally but fail across the internet tell you the direct path succeeds on a shared LAN but there is no working server-reflexive or relayed candidate once real NAT is in the way. The fix is almost always to confirm TURN is deployed and reachable, since it is the fallback that works through nearly any restrictive network.

Intermittent failures on mobile or corporate networks are the fingerprint of symmetric NAT. A share of users on those networks will never find a direct path, which is why TURN capacity has to be planned for the worst case rather than the average.

One more trap worth naming: SIP ALG. Many consumer and small-business routers include a “SIP Application Layer Gateway” that tries to rewrite SIP and SDP addresses to help NAT traversal, and it very often corrupts the messages instead, producing the same one-way-audio and registration failures it claims to prevent. The usual fix is to disable SIP ALG on the router and let a proper SBC handle NAT at the edge, a point covered in depth in SIP Firewall vs SBC.

Frequently Asked Questions

Conclusion

A STUN server does one small, essential job: it tells an endpoint what its public address looks like so a direct media path can be attempted. STUN, TURN, and ICE then work as a single strategy, with ICE choosing the direct STUN path when it can and the TURN relay when it must. WebRTC builds this in and expects every endpoint to run it; SIP takes the opposite view and lets the network edge solve NAT with a Session Border Controller that anchors media on a stable public address.

The practical decision comes down to where your endpoints live. If they are browsers, deploy STUN and TURN and size the relay for the worst-case share of users behind symmetric NAT. If they are SIP phones or trunks, an SBC doing far-end NAT traversal removes the need for endpoint-side traversal entirely. And when a call crosses from one world to the other, a WebRTC gateway plus an SBC lets each side keep the NAT model it was designed for.