Network design
Conclusion
Moving to a multipurpose
NAT
IP telephony may not work across Network Address Translation (NAT), because if private IP addresses 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 avoided for
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 it is preferable that the firewall not perform a NAT function. IP telephony will then work across the firewall once the appropriate ports are open on the firewall. For more information, see Avaya IP Telephony Implementation Guide: iImplementation_Guide
see appendix B for recommendations regarding list of ports).
When connecting the enterprise to an IPT SP through a VoIP trunk — either SIP or H.323 — there will likely be a NAT at the enterprise border. The recommended 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. For a list of Avaya DeveloperConnection members and Avaya
Alternatively, in certain cases an Application Layer Gateway (ALG) can be used. Another alternative is setting up a