Expert Reference Series of White Papers Voice Architectures and Deployment Models 1-800-COURSES www.globalknowledge.com
Voice Architectures and Deployment Models Bernie Gardiner, Global Knowledge Certified Cisco Instructor Introduction In traditional telephony, the design of voice implementations followed more standard, PSTN-like architectures. End devices, such as phones, had no intelligence built in and were controlled by centralized components such as telephony switches or PBXs. Call control protocols were defined based on physical connection types or proprietary vendor-based protocols. Remote site PBXs connected to Head Office PBX using tie-lines, and data transport was handled by a completely separate network infrastructure. As companies migrate from traditional telephony to Voice over IP, there are more design decisions to make when choosing the most appropriate implementation type. The choices include variations of centralized or distributed architectures, as well as a choice of call control protocols. The design decision may be based on corporate policies (centralize control of infrastructure and services or providing autonomy to each site by distributing control), or the decision may be based on application and service requirements which may dictate one voice control protocol over another. Common deployment models include: Single Site Multi-site Centralized Multi-site Distributed Distributed Single Cluster In addition to the deployment model, a thorough understanding of call control protocols and how they fit within the deployment model is required. Depending on the goal of the telephony implementation, one call control protocol may be chosen over another. The overall design decision will need to encompass both call control protocol and deployment model type. Call Control Protocols The choice of deployment models is closely coupled with the choice of call control protocols. Dominant call control protocols include H.323, Media Gateway Control Protocol (MGCP), Session Initiation Protocol (SIP), and Skinny Call Control Protocol (SCCP). Call control protocols fall into one of 2 groups: peer-to-peer control protocols or client-server control protocols. Peer-to-Peer Protocols mandate that each device in the network has the capability to process a call without having to query a central server, but can choose to use a central server if one is configured. Since the intelligence may be distributed across many devices, peer-to-peer protocols are often associated with distributed voice architectures. H.323 and SIP are examples of peer-to-peer protocols. H.323 devices include voice Copyright 2008 Global Knowledge Training LLC. All rights reserved. Page 2
gateways and telephony applications, such as soft phones, which run on a PC. SIP devices include SIP phones, as well as SIP-enabled telephony applications. Distributed intelligence provides the benefit of autonomy and gives each location flexibility to implement and configure these devices independent of other locations. However, since each device must be capable of processing calls without outside assistance, that also means each device must contain a comprehensive configuration which defines all other reachable devices. For small installations, this may not be an issue, but for larger installations requiring scalability, this type of configuration requirement does not work well. To solve this issue, both H.323 and SIP, even though they are at heart peer-to-peer protocols, provide centralized configuration and control components. In H.323, the centralized component is the gatekeeper device. The gatekeeper is a device that contains call routing information for multiple voice gateways. The gatekeeper can also provide other functionality such as call admission control and bandwidth management. In the SIP environment, the centralized component is the SIP Proxy/Redirect Server, which works in concert with the registration server and the location database to reduce the need for extensive individual endpoint configuration. In most corporate implementations, some form of centralized intelligence is always implemented to provide a scalable solution. Client-Server protocols mandate that clients do not need to have much intelligence locally but rely on the presence of a central server to orchestrate call setup and teardown. MGCP and SCCP are examples of clientserver protocols. Although these protocols are often used in centralized architectures, they can also be used in a distributed fashion with servers being placed in multiple locations. The benefit of using client-server implementations is that they centralize provisioning, call control and management functions. In the case of MGCP, a central server referred to as a call agent controls voice gateway ports. The call agent is configured with all of the details of how that gateway port will process voice. A single call routing configuration is placed on the call agent and can be accessed to process calls on behalf of many voice ports. This simplifies the configuration task tremendously. A practical comparison would go as follows: A company has 100 remote locations, each with a single PSTN gateway port. A basic peer-to-peer implementation would mean that each of the 100 gateways would need a dial plan configuration that defines how to reach all of the other 99 locations. A client-server implementation would require minimal configuration on each of the 100 gateways defining the address of the call agent. The call agent is configured to know about each of the 100 gateway ports and a single dial plan is configured defining access to each of the 100 locations. SCCP is a Cisco proprietary client-server call control protocol that is used for communication between the Cisco Communications Manager (CM) and the IP phones. When an event, such as off-hook, occurs, the IP phone will query the CM server for direction as to what action to take. The CM will inform the IP phone to provide dial tone and to await a dialed digit. When the IP phone detects a dialed digit, it informs the CM server who responds with the direction to stop playing dial tone and to wait for more digits. This type of back and forth communication continues until the call has been set up, at which time the voice connection is set up directly from one IP phone to the other. Copyright 2008 Global Knowledge Training LLC. All rights reserved. Page 3
Understanding the difference between call control protocols and the benefits and drawbacks of each is key to a successful implementation of IP telephony. Each company will have its own reasons for choosing one over another, and in many cases, there will be multiple protocols present. The other major decision in IP Telephony design is to determine where the servers and endpoints will be placed. The two major options in use are Centralized or Distributed deployment. In many cases there may be a mix of the two within the corporate environment. Single Site Deployment Model The single site deployment provides local call processing capabilities for a single campus or location over a LAN or MAN environment. The call processing agent located at this site is dedicated to call processing for this location only. All intrasite voice calls will travel over the LAN or MAN and any calls needing to be set up to other locations will be directed to the PSTN. If a WAN is present, it will carry only user data and not voice traffic. Single site deployment allows each location to operate as a stand-alone location and is not dependant on the availability of call processing agents in other locations, nor on the availability of the WAN to process those calls. Benefits include: No dependence on external processing Autonomy of implementation Local control of configuration Simplified dial plan Use of single codec across entire site (G.711) and, therefore, no need for transcoder resources Implementation Guidelines: Complete a voice analysis to determine whether most of the calls originate and terminate within the local site. Single site deployment is the correct choice if this is the case Use MGCP where possible to control ports connecting the location to the PSTN. This provides centralized configuration across all ports and promotes the use of a central dial plan. Perform internal capacity planning to determine bandwidth requirements for Quality of Service configurations Implement an infrastructure that supports high availability, sufficient power provisioning (PoE to the phone), and QoS for consistent high quality voice Implement security across all areas of infrastructure to ensure availability Plan for additional services such as access to voice mail and conferencing Multisite Centralized Deployment Model Figure 1 As the name suggests, the multi-site centralized model provides central call processing capabilities to multiple sites across a wan environment. The call processing agent, and possibly other services, such as voice mail, are Copyright 2008 Global Knowledge Training LLC. All rights reserved. Page 4
located centrally at a single location, while endpoints, such as IP phones, are located across multiple locations. The distributed endpoints rely on the presence of an IP path (typically across the WAN) to be able to reach the centralized call processing agent and other services. Figure 2 This model is suitable for a corporate environment with multiple small sites where services and IT administration and maintenance are centralized at head office. This type of deployment strongly relies on the availability of a QoS enable network that can carry both voice and call control traffic between headquarters and remote locations. Benefits include: Simplified configuration and maintenance through the use of a single dial-plan on the central call agent Centralized administration and maintenance of the call processing agent and other services such as voice mail and IVR servers Centrally configured call admission control to ensure high quality of service for all completed voice calls Consistent implementation of features and services Implementation Guidelines: Complete a voice analysis to determine the number of concurrent calls required between all locations Determine bandwidth requirements based on required call capacity and codec used Use a high bandwidth codec (e.g., G.711) for all internal calls and a low bandwidth codec (e.g., G.729) for all calls crossing the WAN Use MGCP where possible to control ports connecting each location to the PSTN. This provides centralized configuration across all ports and promotes the use of a central dial plan. Implement an infrastructure that supports high availability, sufficient power provisioning (PoE to the phone), and QoS for consistent high quality voice and call signaling Implement security across all areas of infrastructure to ensure availability Plan for additional services such as access to voice mail and conferencing Plan for Remote Site Survivability as a backup if WAN failure occurs Copyright 2008 Global Knowledge Training LLC. All rights reserved. Page 5
Multisite Distributed Deployment Model For companies with large campus locations (more than 30,000 devices) or larger remote locations, a distributed approach is typically the answer. A cluster of call processing agents is located at each location, similar to the single-site deployment. The main difference is that calls between sites travel across the WAN in a multisite distributed environment as opposed to traveling across the PSTN as in the single-site deployment. This approach calls for a stable, highly available network infrastructure to support the inter-site calls and call signaling. In a distributed environment, the call processing agents are distributed, but other services, such as voice mail or IVR servers may be centralized or distributed. In the presence of multiple clusters, each cluster must be configured to know about the existence of other clusters, as well as what number ranges each cluster supports. If the number of locations is such that this configuration is prohibitive on the call agent, then H.323 gatekeepers can be implemented to provide scalability in large installations. Figure 3 Benefits include: Cost savings when passing inter site calls over the WAN as opposed to the PSTN Cost savings when passing long distance PSTN calls across the WAN to a local drop-off point (referred to as tail-end hop-off or TEHO) Independent intra-site call processing, removing reliance on external call processing agents for call setup Maximized utilization of WAN facilities when carrying voice, video and data across a common infrastructure Highly scalable Copyright 2008 Global Knowledge Training LLC. All rights reserved. Page 6
Implementation Guidelines: Complete a voice analysis to determine the number of concurrent calls required between all locations Determine bandwidth requirements based on required call capacity and codec used Use a high bandwidth codec (e.g., G.711) for all internal calls and low bandwidth codec (e.g., G.729) for all calls crossing the WAN Use H.323 gatekeepers to provide address resolution and call admission control between locations Implement an infrastructure that supports high availability, sufficient power provisioning (PoE to the phone), and QoS for consistent high quality voice and call signaling Implement security across all areas of infrastructure to ensure availability Plan for additional services such as access to voice mail and conferencing Plan for Remote Site Survivability as a backup if WAN failure occurs Distributed Single Cluster In instances where there is a low number of smaller locations, a single Communications Manager cluster can be distributed across these multiple locations. Individual servers from the cluster can be placed at different locations as long as the connecting WAN can support clustering requirements. Figure 4 Clustering requirements include: Maximum round trip delay between any CM must be 40ms or less. Jitter must be controlled through the use of QoS policies Adequate bandwidth for Intracluster Communications Signaling Benefits of clustering over the IP WAN include: A centrally administered dial plan Extension mobility across multiple locations Local call processing Depending on the number of remote sites, each site can have one or more servers installed. For sites with a single server, failover occurs over the WAN, while for locations with multiple servers, failover occurs locally. Copyright 2008 Global Knowledge Training LLC. All rights reserved. Page 7
Summary Telephony design requires a solid understanding of the drivers for Voice over IP, corporate policies for infrastructure design, and telephone components. Planning phases should include capacity planning, bandwidth calculations and defining QoS policies to ensure consistent high quality in the telephony environment. Learn More Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge. Check out the following Global Knowledge courses: CIPT1 v4.1 - Cisco IP Telephony Part 1 v4.1 CIPT1 v6.0 - Implementing Cisco Unified Communications IP Telephony Part 1 CIPT2 v4.1 - Cisco IP Telephony Part 2 v4.1 CIPT2 v6.0 - Implementing Cisco Unified Communications IP Telephony Part 2 CUCMBC v4.1 - Cisco Unified Communications Manager Boot Camp v4.1 CUCMBC v6.0 - Cisco Unified Communications Manager Boot Camp v6.0/v5.1 For more information or to register, visit www.globalknowledge.com or call 1-800-COURSES to speak with a sales representative. Our courses and enhanced, hands-on labs offer practical skills and tips that you can immediately put to use. Our expert instructors draw upon their experiences to help you understand key concepts and how to apply them to your specific work situation. Choose from our more than 700 courses, delivered through Classrooms, e-learning, and On-site sessions, to meet your IT and management training needs. About the Author Berni Gardiner is a Certified Cisco Instructor and has taught for Global Knowledge since 1998. Berni's 30+ years of technical expertise spans software development, network design and implementation and Voice over IP design and implementation. Over the past nine years, Berni has focused on converged network design, integrating voice technologies into data networks. Berni teaches a variety of Cisco courses including Implementing Cisco QoS, CVoice, Cisco IP Telephony I and II, and IP Telephony Express. Berni has worked with Global Knowledge and Cisco as the Subject Matter Expert (SME) developing material for multiple Cisco Instructor Led Training courses (ILT) and Global Knowledge Self-Paced elearning courses (SPeL) in the voice arena. Her realworld experience includes working with local and national ISPs for network provisioning, as well as consulting on VoIP implementations across North America. Copyright 2008 Global Knowledge Training LLC. All rights reserved. Page 8