Filter
Top Products
Network design
302 Avaya Application Solutions IP Telephony Deployment Guide
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.