Routers, NAT and VoIP

NAT and PAT Why are they necessary?

Network Address Translation (NAT)

When network host A sends a request to another network host B, network host A will be expecting a reply to his request. When both network hosts reside on a Public IP addresses, the exchange is direct, and simple enough.

If one of  the network hosts resides on a Private IP address, however, things start to become complicated, because the network environment is not a NAT/PAT environment. If network host A is in a NAT/PAT environment, when it sends a request to network host B,  host A will build its request using the only IP address it knows – its private IP address. The problem here is that private IP addresses are NOT routable over the public internet.

However, we should still be able to see the responses coming back because, as the traffic crosses the WAN-to-LAN device, the WAN-to-LAN device will manipulate the “Source IP address” packet headers, and translate the private IP address (  to the public IP address before sending it on its way – hence the term NAT, or Network Address Translation – which means that the traffic goes out with the Public IP Address ( in this case). The WAN-to-LAN device will keep a record of this manipulation. The list of such manipulations made by the WAN-to-LAN device is typically called a NAT Mapping table. We can visualise what a NAT Mapping entry could look like in the example here:

Network Address Translation (NAT)

WAN Side LAN Side
IP address Port number IP address Port number ANY ANY

When a response is send to the request send earlier, the WAN-to-LAN device will perform the same manipulation  in reverse on the “Destination IP Address”. That means that the destination IP address in the packet header would need to be changed from “” to “” and then forwarded into the LAN, where network host with IP address “” would process it.

Port Address Translation (PAT)

Very often, the WAN-to-LAN device is handling multiple simultaneous requests from multiple network hosts on the LAN side, and may see a request from two LAN devices where the Source Port Number is the same. Without some mechanism to handle this situation, the WAN-to-LAN device would not be able to satisfy the second request – because it would result in something like the following (impossible) NAT Mapping table:

WAN Side LAN Side
IP Address Port Number IP Address Port number 5060 5060 5060 5060

In this case when a response to one of the requests arrives, with the “Destination IP Address” in the packet header reading “”, it would have two possible network hosts ( and  to send the packet to on the LAN side, and no way to discern which is the correct one.

The solution is for the WAN-to-LAN device to perform PAT (Port Address Translation), sometimes also called NAT Overload – effectively not only translating the private IP Address to the public IP Address, but also translating the original source port number.

WAN Side LAN Side
IP Address Port Number IP Address Port number 5060 5060 6060 6060

This allows the WAN-to-LAN device to correctly route responses as they return from the remote network host. So now any traffic coming  in with Destination  and port 6060 will be forwarded on the LAN side to IP address and port 6060 and any traffic coming in with in with Destination  and port 5060 will be forwarded on the LAN side to IP address and port 5060 .

Remember, SIP/VoIP can not work with port remapping as the ports on how VoIP works are within the packages and not defined by its transport!

WAN Side LAN Side
IP Address Port Number IP Address Port number 5060 5060 6060 5060

Ports to forward

Here is a brief overview of ports which might need to be forwarded depending on the installation. To determine which ports are needed in you setup refer to this guide :

Protocol Port  Description Port Forwarding Required
TCP 5001 or 443 HTTPs Port Yes – if you intend on using a ECLOUD client, Bridge Presence, Remote IP Phones from outside your LAN and ECLOUD WebMeeting functionality.
TCP 5015 Web Config Tool Port Optional – During the installation process when the Web-Based installer is used from external source
UDP & TCP 5060 SIP Port Yes – if you intend on using VoIP Providers, WebRTC and Remote Extensions that are NOT using the ECLOUD Tunnel Protocol
TCP 5061 Secure SIP Port Yes – if you intend on using Secure SIP remote extensions
UDP & TCP 5090 Tunnel Port Yes -if you intend on using remote extensions using the ECLOUD Tunnel Protocol (within the ECLOUD clients for Windows / Android / iOS) or when using the ECLOUD Session Border Controller
UDP 9000-9500 (default) Media Port (audio/video/fax) Yes – if you intend on using remote extensions or a VoIP Provider

Keep-Alive Packets

Keep in mind that every entry created in the NAT Mappings table on the WAN-to-LAN device has a validity period of typically 20 to 60 seconds (TTL or Time-To-Live). Every time a packet traverses the WAN-to-LAN boundary from the same LAN IP Address and Port to the same WAN IP Address and Port while the particulat NAT Mapping entry is still alive, the TTL is reset and the WAN-to-LAN device starts counting down the validity period again.

When a SIP Client, such as a SIP Phone, registers itself with a SIP Server for example, an entry in the NAT Mapping table is created. However, if no further traffic is exchanged before the TTL timeout, then the NAT Mapping expires, and any traffic originating from the WAN side towards the SIP Phone will not be able to reach it because the NAT Mapping entry no longer exists. So a SIP Client should also be configured to send Keep-Alive messages to the SIP Server, with an interval of about 15 seconds (which should be good enough for all reasonable NAT/PAT implementations). The SIP Client will send a SIP Message to the SIP Server that is syntactically correct (compelling the Server to respond), but requesting some service or function that the SIP Server will not have available. This would generate a “Method Not Implemented” response from the SIP Server. This is by default enabled for STUN provisioned SIP Phones.

Functionally this achieves no purpose, but is sufficient to ensure that the NAT Mapping set up over the WAN-to-LAN boundary never expires (stays alive hence the name), and ensures that the SIP Server will be able to contact the SIP Client via NAT Mapping.

SIP – Why NAT and/or PAT is Insufficient

There are a number of fundamental reasons why simple NAT and PAT are insufficient to resolve NAT traversal issues for VoIP traffic in general and for SIP Signalling more specifically. A small subset of the reasons:

  • The SIP Standard requires a number of header fields to be specified, some of which need to contain the IP Address where responses need to be sent to. Since NAT and PAT operate only on the IP headers, and not on the UDP Payload, the WAN-to-LAN device does not address this issue at all.
  • SIP does not only perform the tasks of setting up, adjusting calls, and tearing down calls, but also incorporates the media codec negotiation phase inside an embedded protocol called SDP (Session Description Protocol). Again, the WAN-to-LAN device does not address this additional content at NAT or PAT level.

SIP ALGs or SIP Helpers

Some WAN-to-LAN devices have a SIP ALG or Helper implemented which attempts to correct for NAT Traversal difficulties by manipulating the contents of the SIP Header fields.

As SIP Standards and SIP devices have evolved, more robust mechanisms have been out into place (the use of additional “VIA” lines being the most commonplace, and also extensions to this functionality typically referred to as “Rport” or as RFC3581 extensions.

In most cases, leaving the SIP ALG enabled on a WAN-to-LAN device is likely to break SIP functionality because it interferes negatively with the SIP VIA + Rport extensions. You would be well advised to leave this feature disabled at all times, unless you have a very specific situation to handle, and you are extremely proficient at dealing with technical challenges, since leaving SIP ALGs enabled is unsupported.

STUN – A Brief Introduction

In the original definition for STUN in RFC 3489, “STUN” was an acronym for “Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs)”. Since the publication of RFC 3489, it was found that the methods described were insufficient to correctly identify NAT implementation behavior. This has resulted in the publication of an updated set of methods in RFC 5389 titled “Session Traversal Utilities for NAT”.

With the new RFC, the acronym is unchanged, and the problems STUN attempts to resolve are the same, but some of the older methods have been deprecated, and the stance of the new RFC is no longer to attempt to be complete NAT traversal solution, but rather one tool-set to be used in the context of a NAT traversal solution.

In a STUN exchange, a STUN Client (typically any VoIP endpoint, such as a phone or a PBX, can be a STUN client) will make a series of requests to a STUN Server (typically a service on a network host in the public Internet, dedicated only to responding to STUN requests). The responses will indicate to the client:

  • which IP Address the STUN Server saw the request coming from (which will be a Public IP Address since a WAN-to-LAN device will have performed NAT/PAT on the outgoing traffic)
  • which Port Number Translations would be in effect for a particular type of exchanged UDP traffic

This information allows a SIP phone for example, to identify the Public IP Address and Port Number that would be placed in the IP Headers AFTER translation, so that when building the CONTENT of the SIP packet (and also the embedded SDP exchange, when present), the TRANSLATED IP Address and Port Numbers will be declared. This way, the phone ensures that if the remote SIP endpoint uses the CONTENT of the SIP packet to identify the return Addresses and Ports, it will have the correct information.