Status

 

  +1 855 802 6465    +1 888 483 5723    +61 1300 314 150
Stun Protocol

The STUN Protocol

ClearlyIP’s Tips and Tricks

 

One of the advantages of Telephony over IP, is having remote users or extensions logging into our Telephony System. This enabled a lot of possibilities such as remote workers from home or from another location, remote monitoring, remote collaboration, Unified communications, etc, and many features like calling a coworker or a provider from home or even establishing a video conference with a sales partner across the globe.

Regardless of the design of our Unified Communications deployment (“cloud” or on premise), when dealing with different networks, private or public, and firewalls/routers we must deal with NAT or Network Address Translator.

Any router uses a NAT table to translate any private IP and port into a public IP and port for outbound network traffic and vice versa when network traffic is inbound. This is done by rewriting the headers of the data packets. With this any incoming traffic through the router will know the destination IP and port in the private network, for instance.

The problem with Unified Communications arises when routers cannot efficiently rewrite these headers, especially for SIP protocol. SIP protocol is very sensitive and if a port or IP is not rewritten correctly, users may experience call drops, one way audio, registration failures or cannot even place a call at all.

There are many ways to solve this issue. In this article we will talk about the STUN protocol.

STUN protocol is a standard and according to the RFC5389 specification the “ Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal.”

STUN is a mechanism for providing an endpoint (softphone, IP-Phone, etc.) a way to determine the IP address and port allocated by a NAT that corresponds to its private IP address and port. It also helps an endpoint keep a NAT binding alive and even perform connectivity checks between two endpoints.

The image below shows a simple STUN request and response:

STUN diagram

We have 3 steps in this process.
  1. The endpoint, in this case an IP Phone using SIP protocol with private IP 192.168.1.25 sends a STUN request through router (192.168.1.254) to the STUN server (66.185.18.43) using source port 5060.
  2. The router (192.168.1.254) retransmits the request to the STUN server (66.185.18.43) and changes the port from 5060 to 14060.
  3. The STUN Server (66.185.18.43) replies to the endpoint, sending the information to the router’s external IP 66.185.18.42 specifying that the request was received from the router’s public IP and port 14060

When the endpoint tries to establish a SIP session with an entity outside the private network, for example an IP-PBX or a SIP provider, it will notify that entity to send responses back to it on IP 66.185.18.42 and port 14060.

As you can see, STUN helps any endpoint and router, receive SIP messages, for example, to the right external IP and port and then resend the SIP messages internally to the right endpoint using the right internal port.

If you would like to use a STUN server to mitigate the NAT issues in your Unified Communications deployment, you can search for any free STUN server online or install your own.

 

For more Tips and Tricks Visit:
https://www.clearlyip.com/tips-and-tricks/