IP telephony cannot work across Network Address Translation (NAT) because if private IP addresses (RFC-1918) are exchanged in signaling messages, these addresses are not reachable from the public side of the NAT and cannot be used for the media sessions.

The problem is not encountered in all VoIP scenarios. It is not used for VPN-based remote access, and NATs are usually not needed internally within the enterprise network. VoIP has to traverse NAT usually at the border between the enterprise and a VoIP trunk to a service provider as well as in hosted VoIP service.

If the network design includes a firewall within the enterprise network to protect certain servers or some part of the network so that IP telephony traffic has to traverse the internal firewall, then the firewall should not perform a NAT function. IP telephony will then work across the firewall once the appropriate ports are open on the firewall. For information on the list of needed ports for any Avaya product, go to the Avaya Support website at https://support.avaya.com to refer current documentation and knowledge articles related to opening a service request.

When you connect the enterprise to an IPT SP through a VoIP trunk, either SIP or H.323, a NAT is done at the enterprise border. The solution for this scenario is to deploy a Session Border Controller (SBC) near the NAT, for example, in the enterprise DMZ. SBCs from multiple vendors have been tested for interoperability with Avaya’s IP telephony solutions.

Alternatively, in certain cases, you can use an Application Layer Gateway (ALG).

Solutions based on standards such as ICE and STUN are expected to be supported in some NAT traversal scenarios.