Correct Router Configuration is a key element in ensuring correct communications between 3CX PhoneSystem and external entities such as external extensions, VoIP Provider services, and other Bridged PBXs.

NAT and/or PAT

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

If one of the network hosts resides on a Private IP Address, however, things start to be come more complex, because the network environment is a NAT/PAT environment.

If network host A is in a NAT/PAT environment, when it sends a request to network host B, it will build its request using the only IP Address it knows – its private IP Address. The difficulty here is that private IP Addresses are NOT routable over the public internet.

However, at this stage, 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. It will keep a record of this manipulation, and 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 here:

So when a response arrives to this request, the WAN-to-LAN device will perform the same manipulation, in reverse, on the “Destination IP Address”. In the previous table, the destination IP Address in the packet header would need to be changed from “212.213.214.215″ to “192.168.0.3″ and then forwarded into the LAN, where network host with IP Address “192.168.0.3″ would process it.

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 2 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:

…and when a response to one of the requests arrives, with the “Destination IP Address” in the packet header reading “212.213.214.215″, it would have 2 possible network hosts 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 to some other port number that does not currently appear in the NAT Mapping table.

This allows the WAN-to-LAN device to correctly route responses as they return from the remote network host.

Keep-Alive Packets

You must keep in mind that every entry created in the NAT Mappings table on the WAN-to-LAN device has a validity period of typically 20s to 60s (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 NAT Mapping entry is still alive, the TTL is reset and the WAN-to-LAN device starts counting down again.

When a SIP Client, such as a SIP Phone, registers itself with a SIP Server, for example, the NAT Mapping 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 the LAN device because the NAT Mapping entry no longer exists.

So a SIP Client can also be configured to send Keep-Alive messages to the SIP Server, with the interval at 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.

Functionally this achieves no scope, but is sufficient to ensure that the NAT Mapping set up over the WAN-to-LAN boundary never expires, and therefore ensuring that the SIP Server will be able to contact the SIP Client via the 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 the 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 disabled at all times, unless you have a very specific situation to handle, and you are very familiar with the 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 behaviour. 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 toolset 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 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), it will declare the TRANSLATED IP Address and Port Numbers. In this way, the phone ensures that if the remote SIP endpoint uses the CONTENT of the SIP packet to identify return Addresses and Ports, it will have the correct information.