White Paper - Solving the Firewall and NAT Traversal Issues for Multimedia over IP Services

ICE - Interactive Connectivity Establishment

As discussed above, techniques such as STUN and TURN have individual advantages and limitations. The IETF have proposed a framework called ICE - Interactive Connectivity Establishment as yet to be standardised. ICE is not a protocol; it is a framework that pulls together different techniques, such as STUN and TURN, which enables the client to investigate its environment in order to learn how to communicate with the outside world. ICE is currently at a draft status, and has yet to see large scale commercial adoption. However, the joint announcement from Microsoft and Cisco may help move ICE forwards to an issued standard.

Although ICE is client based it relies on one or more external STUN and TURN servers, and SIP extensions, to achieve its connections. ICE clients will exchange reachability information and negotiate to find one or more connection paths between them. If they establish that there is more than one possible connection path, they will attempt to select the best quality connection based on latency and jitter measurements. If the initiating ICE client attempts to call a non-ICE client then the call setup-process will revert to a conventional SIP call requiring NAT traversal to be solved by other means.

Application Layer Gateway (ALG)

The ALG processes the signalling and media streams so it can modify the signalling to reflect the public IP addresses and ports being used by the signalling and media traffic.

As suggested, this technique requires replacement of the existing NAT/Firewall with an ALG. Alternatively, some vendors provide software upgrades to their NAT/Firewalls to support ALG functionality.

ALGs require similar, if not more advanced, configuration and management skills to NATs and Firewalls, which means that upgrades or new installations will not be undertaken lightly. These issues mean that deployment of ALGs is likely to be slow and restricted to larger corporate networks with the associated support staff.

Manual Configuration

In this method, the client is manually configured with details of the public IP addresses and ports that the NAT will use for signalling and media. The NAT is also manually configured with static mappings (or 'bindings') for each client.

This method requires that the client must have a fixed IP address and fixed ports for receiving signalling and media.

Due to the manual and knowledge-based configuration process, as well as the fixed configuration, this is only suitable for very small networks where there is a great deal of experience in configuring and managing the NAT/Firewall.

It is very likely that UPnP, when available, will supersede this manual method.

Tunnel Techniques

This method achieves Firewall/NAT traversal by tunnelling both media and signalling through the existing Firewall/NAT installations to a public address space server.

This method requires a new server within the private network and another in the public network. These devices create a tunnel between them that carries all the SIP traffic through a reconfigured Firewall. The external server modifies the signalling to reflect its outbound port details, thus allowing the VoIP system to both make outgoing calls and accept incoming calls. The tunnel through the existing infrastructure is not usually encrypted.

While this method provides only minimal changes to the existing security policy, it does create additional risks. In particular, the external server is a point of vulnerability, which, if breached, can provide an easy way of reaching the private network.

In addition, this method can create additional delay in the media path - which may reduce voice quality.

• Download PDF copy of the NAT Traversal White Paper
• Back to White Papers Home