In some ways, NAT (Network Address Translation) is both a blessing and a curse. The IP addresses in the Local Area Network are concealed thanks to the NAT protocol. Unfortunately, VoIP and NAT don’t get along that well, particularly when it comes to VoIP over UDP. And that’s where STUN comes in.
For communication between endpoints behind NAT gates, the VoIP network use the straightforward but crucial STUN protocol. Aside from when using UDP for VoIP connections, STUN is not actually necessary. Generally, NAT doesn’t pose any issues for connections using the TCP protocol. Contact our support staff to discuss your needs if you need assistance understanding how STUN might impact your VoIP setup.
The STUN (Simple Traversal of UDP over NAT) protocol is a standardized set of methods designed to help UDP packets make it across NAT devices safe and sound. Naturally, one of its key applications is to resolve connection issues in a SIP-based VoIP environment.
As we all know, the Network Addressing Protocol (NAT) is a technology that ensures secure communication over the Internet and efficient use of IP addresses. NAT devices, such as firewalls and routers allow multiple private IPs to use a shared public IP.
SIP (Session Initiation Protocol) is the most popular set of VoIP standards of the day. It allows SIP-enabled VoIP devices to establish stable communication with each other. The protocol helps devices locate each other and agree on which CODEC will be used while transferring media stream.
What is that media stream? Well, most commonly, it is our voice broken into packets by an encoder. This is what CODECs do. They take our voice and break it into packets using a certain technique. Oh, and when those packets arrive to the destination they need to be reassembled back into voice using the same exact technique.
However, the lackluster standards in NAT result in a number of issues during SIP-based communication in VoIP. For instance, it’s common for users to encounter various problems such as phone registration failures/one-way audio (can you hear me now?) when they communicate between two SIP entities through a NAT device. This often happens when these users try to register to an IP PBX or VoIP provider outside their usual workplace network. STUN provides method that helps network administrators resolve these “NAT traversal” issues in their VoIP implementations. In this article, we will discuss how it does that.
The STUN Protocol
In its essence, STUN is a simple server-client protocol. A server using the STUN protocol will rely on both UDP and TCP protocols. These servers usually listen on port 3478.
It’s common for clients to contact STUN servers on specific IPs and ports (i.e., 3478). However, these servers can hint the client to perform tests on alternate port number and IP addresses. As a result, ports and IPs are arbitrary.
Client-Server Requests
On the client side, the STUN protocol gets embedded in the VoIP software inside IP phones or IP PBXs. With the help from the STUN client, VoIP software sends an initial request to the STUN server in order to discover its public port(s) and IP.
After the STUN server responds, both client and server exchange two kinds of requests between each other, the first type of request is a Binding Request that is typically sent over UDP. On the other hand, a Shared Secret Request is sent through a secure TLS channel over TCP.
Shared Secret Requests only ask the STUN server to return temporary sets of credentials. These temporary sets of credential are then used in establishing Binding Requests and Binding Responses. This process ensures message integrity and that the exchange occurs after proper authentication.
Binding requests, on the other hand, are sent from the STUN client to the STUN server to determine which port(s) and IP bindings the NAT has allocated. Moreover, the STUN client sends the STUN server a Binding Request over UDP.
After that, the server examines the port, and IP address of the binding request; copies both of them into a binding response, and then sends it back to the client. There are also other attributes in the request that tell the client to ask for the response to be sent to a different port(s) and IP address.
STUN Request and Response Scenario
The following diagram depicts how a typical STUN request and response functions:
Step #1
On the client side, Computer A sends an initial STUN request through the router-gateway (192.168.1.1) to the STUN server (209.242.0.100) that is listening on port 5061.
Step #2
The router-gateway 192.168.1.1 forwards the request to STUN server from its Internet interface (216.180.64.49) and changes the port 5061 to port 3478.
Step #3
The STUN Server (209.242.0.100) sends a response back to the client-source through the gateway. However, client sees that response was received from IP 216.180.64.49 and port 3478.
When the client (computer A) establishes a session (i.e., SIP-based VoIP call) with an external device; it notifies the external device to send responses to the IP 216.180.64.49 and port 3478. As we can see, the STUN protocol plays a vital role in helping both devices to establish a UDP connection while they run behind a gateway configured with NAT.
Why Is STUN Ideal for SIP-Based VoIP Environment?
STUN makes sure that the SIP device connecting through a NAT discovers its public IP and also determines which type of NAT is running on its connected gateway. The STUN protocol also enables SIP devices to discover which port external SIP devices can establish a connection with.
We know that the Session Initiation Protocol may use UDP as its transport protocol. The obvious advantage of UDP is that it is freaky fast. Put your data in a packet and send it off. No need to receive confirmation that this packet was received – it will just slow things down. Lost a packet or ten along the way? There is no way for the sending device to know.
And this “fire and forget” method, my friends, is how speed is achieved.
TCP, on the other hand, is known for its reliability because it requires a confirmation for every packet received. Reliability always comes with a price and this price is speed.
While TCP can also be used in SIP, UDP is a preferred choice often due to its speed. However, the UDP protocol is not connection-oriented and does not establish logical connections. This means that any device will send packets to some other device without going through prior handshaking.
Establishing a connection between two SIP devices over NAT can be a challenging task. Therefore, STUN is ideal for VoIP environments, and you will commonly find STUN used in SIP-based environments.
Sending a SIP-Based Request without Using STUN Protocol
In the absence of STUN, a SIP-based IP PBX will send its private IP address (e.g., 192.168.1.5) and port number while trying to establish a connection with another SIP-based device outside its network. In response, the remote SIP-based IP phone will send a response back on the same private IP.
Since a private IP is not routable on the internet, it will eventually get dropped by the intermediary gateway. As a result, the response made by the remote IP phone will never reach the local IP PBX, and the connection would not get established.
Sending a SIP-Based Request Using STUN Protocol
The STUN protocol is vital for any SIP-based connection because it routes these connections using a specified STUN server. As a result, the VoIP device only has to communicate with the STUN server once and wait for it to reply.
These initial requests are usually made when the VoIP device is starting up. Other times, it happens before the device tries to communicate with an external SIP-based device.
During the SIP request exchange of a STUN-enabled environment, the local SIP-based IP PBX utilizes the address mapping (IP address and port number) of the STUN server instead of its own IP address and port number. As I mentioned before, this is done before the local IP PBX tries to send a request to a remote VoIP device.
Due to the STUN protocol, the local IP PBX is able to communicate with an external SIP-based VoIP device through the intermediary STUN server. For instance, a local device (IP address 192.168.2.5, port 7205) will connect to the STUN server and adopt its IP address (209.242.0.100) and port (8667) for external connections.
When the local device has to send a connection INVITE to the external device, its request will be traversed through the STUN server. As a result, the external device will receive a request from the IP address (209.242.0.100) and port (8667) instead of the local device’s private address mapping.
The external device will then respond back on the STUN server IP address and port. Since the STUN server IP address (209.242.0.100) and port (8667) are not private, they can be routed on the internet. As a result, the connection request will not get discarded at the NAT gateway.
STUN Use Cases
As we have discussed before, implementing a STUN protocol enables network clients (including SIP phones) to find their public IP while running behind a NAT device. It also helps that device identify the type of NAT being run on by the gateway. As a result, the device has an easier time establishing which port is available for connection to other devices outside the network.
However, we should not forget that routers and gateways don’t do port translations all the time. This depends on which type of NAT the device is running and how it has been configured. For instance, a full-cone NAT configuration will not translate ports.
STUN is also useful in refreshing NAT bindings. The protocol can be used as a keep-alive mechanism while administrators use Port Restricted cone NAT or Restricted Cone NAT. In these NAT configurations, each port and internal address is mapped to a specific port and external address.
However, if these address translations are not utilized after a certain time, their address mapping will get dropped. As a result, the router doesn’t keep assigning the same address mappings (IP and port) the next time the internal device connects to the same external device. This helps in preventing an internal device from over-using a single address mapping.
Limitations of STUN
Though STUN is a great option when it comes to VoIP environments, it still has its limitations. One of its major downsides is that it cannot work effectively with networks that use Symmetric Network Address Translation.
The reason this happens is that Symmetric NAT uses a different method while establishing connections between internal and external hosts.
A Symmetric NAT creates new addresses and port mappings each time an internal device tries to connect to a remote external device. In such a scenario, STUN is not good for relaying connections requests as it needs to know which port client-NAT device will have in upcoming connections.
Conclusion
As we have discussed above, most protocols in the SIP-based VoIP environment usually use UDP as their transport protocol. This especially difficult because the UDP does not establish logical connections.
Therefore, we can conclude that the STUN protocol plays a vital role in helping SIP-based devices establish SIP-based VoIP calls while running behind NAT gateways.
DLS Internet Services offers a comprehensive suite of VoIP-based Unified Communications as-a-service (UCaaS). The company implements the best practices in VoIP and has been delivering innovative business-to-business PBX solutions since 1995.
DLS provides VoIP services such as hosted PBX and virtual PBX phone systems to help organizations optimize their communication. Besides that, the company offers a blend of business ISP services.
For further information on our services, visit our website at https://dls.staging.wpmudev.host/.