Newport Networks Sesson Border Controller



White Paper - NAT Traversal Solutions for Multimedia over IP Services

The 'NAT Problem'

NAT devices translate IP addresses and port numbers in private address ranges into public addresses when traffic traverses between private and public networks. This allows a limited number of public IP addresses to serve the needs of even the largest corporation.

NAT problem
Figure 2 The NAT traversal problem

Each device in the network has its own private IP address. Traffic (a media stream, for example) sent to a device on the public network is dynamically assigned a specific port number at the public address by the NAT. The NAT maintains a 'table' that links private and public addresses and port numbers. It is important to note that these 'bindings' can only be initiated by outgoing traffic.

The NAT acts in a similar way to a PABX. Users of the PABX can dial out using one of the few public telephone lines (equivalent to public IP Addresses) that are available. The line that is used (the port number) is automatically selected and invisible to the user. Receiving an incoming call is more difficult, because the internal extension numbers are unknown to the public network. Users dialling in must be routed to an attendant to be connected to the correct extension. Clearly in the case of a NAT, there is no equivalent of an attendant so unsolicited incoming calls cannot be supported.

end-to-end media flow is broken
Figure 3 NAT breaks end-to-end media flow

To complicate matters further, the end-to-end SIP messaging between clients contains details of the private IP addresses and ports that the clients (User Agents) want to use for the media flows. When the clients attempt to use these private addresses to send/receive media, the connection fails because they are un-routable. This issue also applies to other signalling protocols such as H.323 and MGCP.

Any approach to solving this problem must allow secure two-way communication - including unsolicited incoming calls - and minimise dependence on upgrading NATs or even using any specific vendor's NAT device.

NAT traversal solutions

In this White Paper, we will describe a range of proposed solutions to NAT traversal and consider the implications of each with regard to security (i.e. how it solves the 'Firewall problem').

The current proposals for solving NAT traversal are:

  • Universal Plug and Play (UPnP)
  • Simple Traversal of UDP Through Network Address Translation devices (STUN)
  • Application Layer Gateway
  • Manual Configuration
  • Tunnel Techniques
  • Automatic Channel Mapping

Universal Plug and Play - UPnP

UPnP is a technology predominantly targeted at home-office users and residential installations. One of the driving forces behind UPnP is Microsoft Corporation.

The UPnP architecture is addresses a number of general issues - not just VoIP - and is designed to allow simple configuration of small networks by un-skilled people. UPnP allows client applications to discover and configure network components, including NATs and Firewalls, which are equipped with UPnP software.

VoIP applications need to discover and use the external IP address and port that the NAT selects for signalling and media flows. Once this information is known, the VoIP client (a SoftPhone or a standalone SIP phone) can put this information into the VoIP signalling to establish the call. This ensures that the call is established using public, routable addresses and ports, and ensures end-to-end connectivity.

To achieve this, the VoIP clients and NAT must be UPnP enabled. While many small end NAT vendors are committed to supporting UPnP, there are few UPnP VoIP clients available from many manufacturers yet. However, it is only a matter of time before these devices are available and many small companies (and residential subscribers) will find them useful.

The main disadvantage of this approach is related to security. It does not satisfactorily solve the 'Firewall problem'.

UPnP relies on the NAT opening pinholes to the outside world under the dynamic control of the UPnP client - maybe a SoftPhone on a PC. This capability is most likely contrary to most security policies and therefore may not be accepted by communications managers of corporate customers.

In addition, there are presently only a small number of NAT and Firewall vendors committed to supporting UPnP.

In summary, this method is likely to be limited to small installations.


Continued
1 | 2 | 3 | 4 | 5 | 6 | Next Page



Page 2 of 6