STUN stands for Session Traversal Utilities for NAT.

Session Traversal Utilities for NAT is a standard method of NAT traversal used in WebRTC. The definition is in IETF RFC 5389.

It is one of two NAT traversal servers that are used in WebRTC (the other one is TURN).

At its core, it’s purpose is to answer the question “what is my IP address?” It does that by using a STUN server.

What is a STUN server?

It is a client-server protocol.

A STUN server is a server that runs on the public network and replies to incoming requests. The responses sent out include the public IP address the request was sent to him from. This effectively answers the question “what is my IP address?”

In most cases, the STUN servers aren’t installed and managed as separate entities but are rather installed together with TURN servers.

While there are free public servers that can be used (such as the one Google operates), it isn’t advisable to use them in commercial services as your main NAT traversal mechanism.

Using a STUN server

A WebRTC client has to know its public IP address in order to get more sessions connected successfully. For that purpose, WebRTC sends a request to a STUN server asking for its public IP address. The server replies back to the WebRTC client with the public IP address the request came from. This way, the WebRTC client learns what its public IP address is.

The WebRTC client then shares the public IP address it received from the server with its peer.

It might not always work. With some network architecture and NAT device types, the public IP address obtained via STUN will not work. This is why we use it in conjunction with TURN and ICE.

As a protocol, it is lightweight and simple, making the availability of public, free and open servers possible.

Free and public Session Traversal Utilities for NAT server

There are various free STUN servers available out there.

It is lightweight and carry no real authentication mechanism to it. This makes it simple for developers to connect to freeservers without any technical hurdles. It is not advisable to do so.

• These free STUN servers might not be there for you tomorrow, and there is no one that offers support for them or even guarantees that they will be there
• You will usually also need TURN servers and these aren’t free. As a result TURN servers also double as STUN servers and you will need to deploy or pay for those, just use them for STUN as well
• Using too many STUN and TURN servers in the iceServers list is counterproductive, often causing delays in connectivity and increasing network congestion instead of improving your chances to connect

Best practices

• STUN doesn’t cost much to operate, which is why there are various free servers you can connect to. Accordingly if you are using a free or a public server (like the famous stun.l.google.com:19302 server), expect it to go down from time to time as you have no control or an SLA for it
• STUN is usually deployed with TURN servers. Focus on a TURN server solution and STUN “will follow”
• Basically configuring TURN/UDP implicitly also implements the STUN protocol. As a result if you use a TURN/UDP server, you can do away with explicitly stating the server in the iceServers configuration of a peer connection

See also the episode of “WebRTC Insights”: