ICE helps VoIP traverse firewalls

One of the biggest benefits of VoIP is the ability to supply remote workers with cost-effective telecom access anywhere a broadband connection exists. But ensuring VoIP connectivity often proves challenging because of the number and variety of network address translation firewalls that might exist between a user and a corporate network.

A number of solutions have been proposed to allow SIP -based VoIP calls to cross firewalls, but each class of NAT firewall requires a different technique. To further complicate matters, the various NAT traversal solutions proposed address only one class of NAT device - as an example, the Simple Traversal of UDP through NAT (STUN) technique will not work with symmetric NATs, which are most often deployed in enterprise environments.

The Interactive Connectivity Establishment (ICE) draft, developed by the IETF's MMUSIC working group, provides a framework to unify the various NAT traversal techniques. This enables SIP-based VoIP clients to successful traverse the variety of firewalls that may exist between a remote user and a network.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

One of the biggest benefits of VoIP is the ability to supply remote workers with cost-effective telecom access anywhere a broadband connection exists. But ensuring VoIP connectivity often proves challenging because of the number and variety of network address translation firewalls that might exist between a user and a corporate network.

A number of solutions have been proposed to allow SIP -based VoIP calls to cross firewalls, but each class of NAT firewall requires a different technique. To further complicate matters, the various NAT traversal solutions proposed address only one class of NAT device - as an example, the Simple Traversal of UDP through NAT (STUN) technique will not work with symmetric NATs, which are most often deployed in enterprise environments.

The Interactive Connectivity Establishment (ICE) draft, developed by the IETF's MMUSIC working group, provides a framework to unify the various NAT traversal techniques. This enables SIP-based VoIP clients to successful traverse the variety of firewalls that may exist between a remote user and a network.

ICE defines a standardized method for SIP-enabled clients (or clients based on other multimedia session protocols) to determine what type of NAT firewall(s) exist between clients and determine a set of IP addresses by which clients can establish contact. Using a number of protocols and network connectivity mechanisms, such as STUN, Traversal Using Relay NAT (TURN) and Realm Specific IP (RSIP), ICE learns about the network topology in which the clients exist and the various sets of network addresses by which these devices can communicate.

When an ICE-enabled client (the initiator) wishes to communicate with another device (the responder), it first collects as many sets of IP addresses as possible from sources such as STUN, TURN, RSIP and locally configured addresses that can provide information on addresses where the client can receive IP traffic. A key benefit that ICE provides is the ability to unify the information provided by these various sources of IP address information to create as many paths as possible by which the endpoints can be reached.

At this point, the initiator client passes this set of addresses to a STUN server and sends an initiate message to the desired responder client. This message contains all the address combinations where the initiator client has learned it can be reached via the earlier discovery process.

When the responder client receives the initiate message, it sends a set of STUN requests back to the initiator for each of these addresses. Typically, at least one STUN request from the responder will reach the initiator because of the network topology and the type of NAT firewall(s) that exist along the path. As the initiator receives these STUN requests, it replies to each in turn. The STUN responses that traverse back to the responder then indicate which addresses the devices can use to communicate. The address with the highest order of preference in the original initiate message is used for further communication between the devices.