Avaya 555-245-600 manual Nat, Conclusion

Network design

Conclusion

Moving to a multipurpose packet-based VPN that transports both voice and data with high quality poses a number of significant management challenges. Managers must determine whether to operate the network using an enterprise-based model, an outsourced or carrier-based model, or a hybrid model. They must settle security issues that involve several layers of the network. And they must ensure that they and their vendors can achieve the required QoS levels across these complex networks. Yet the advantages of converged, multipurpose VPNs remain a strong attraction. The opportunity to eliminate separate, duplicate networks and costly dedicated facilities, avoid costly public network long distance charges, and reduce administrative overhead provides a powerful incentive. Most important, by helping integrate voice and data communication, multimedia messaging, supplier and customer relationship management, corporate data stores, and other technologies and resources, converged networks promise to become a key enabler for eBusiness initiatives.

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 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 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 compliance-tested solutions, refer to the solutions directory at: www.devconnectprogram.com.

Alternatively, in certain cases an Application Layer Gateway (ALG) can be used. Another alternative is setting up a C-LAN and a Media Processor card in the DMZ, and using Communication Manager as a proxy server between the internal and external networks.

302 Avaya Application Solutions IP Telephony Deployment Guide