Cisco IP Telephony Solution Reference Network Design Guide

Cisco IP Telephony Solution Reference Network Design Guide
Cisco CallManager Release 3.1 and 3.2 July 2003
Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100
Customer Order Number: 956378 Text Part Number: EDCS-197018
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCBs public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries. All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0304R)
Cisco IP Telephony Solution Reference Network Design Guide Copyright 2002, Cisco Systems, Inc. All rights reserved.
CONTENTS
Preface Scope
xiii xiii xiii xiii xiii
Purpose Audience
Organization
Obtaining Documentation xv World Wide Web xv Documentation CD-ROM xv Ordering Documentation xv Documentation Feedback xv Obtaining Technical Assistance xvi Cisco.com xvi Technical Assistance Center xvi Cisco TAC Web Site xvii Cisco TAC Escalation Center xvii
1
CHA PTER
Overview of Cisco AVVID IP Telephony Solutions Why IP Telephony?

1-1
1-1
Architecture Overview 1-3 Security 1-4 Quality of Service 1-4 Network Management 1-4 Cisco CallManager Deployment Models 1-5 Single-Site Call Processing Model 1-5 Multi-Site WAN Model with Centralized Call Processing Multi-Site WAN Model with Distributed Call Processing Clustering Over the IP WAN 1-6 Applications 1-7 Cisco IP SoftPhone 1-7 Extension Mobility 1-7 Multi-Party Voice Conferencing 1-8 Unified Messaging 1-8 Web Services for IP Phones 1-8 Cisco Personal Assistant 1-9
Cisco IP Telephony Solution Reference Network Design Guide EDCS-197018
1-5 1-6
iii
Contents
Cisco Customer Response Solutions Platform 1-10 Cisco IP Integrated Contact Distribution (IP ICD) 1-10 Cisco IP Interactive Voice Response (IP IVR) 1-11 Components That Apply to All Deployment Models Voice, Fax, and Modem Gateways 1-11 Station Devices 1-12 Emergency Services (911 and E911) 1-12
2
1-11
CHA PTER
IP Telephony Deployment Models Single Site 2-2 Solution Benefits 2-3 Best Practices 2-4 Dial Plan 2-4
2-1
Multi-Site WAN with Centralized Call Processing 2-4 Solution Benefits 2-6 Best Practices 2-6 Remote Site Survivability 2-7 Call Admission Control 2-9 Recommendations for Locations and Call Admission Control Gateways 2-11 Dial Plan 2-11 Multi-Site WAN with Distributed Call Processing Solution Benefits 2-15 Best Practices 2-15 Call Processing Agents 2-15 Call Admission Control 2-16 Dial Plan 2-17 Site Dial Plan 2-18 Gatekeeper Dial Plan 2-20 Hybrid Dial Plan 2-20 Clustering Over the IP WAN 2-21 Local Failover Deployment Model 2-22 Cisco CallManager Provisioning 2-23 Gateways 2-24 Voice Mail 2-24 Music on Hold 2-24 Remote Failover Deployment Model 2-25 Cisco CallManager Provisioning 2-26 Gateways 2-26
2-11
2-13
iv
EDCS-197018
Contents
Voice Mail 2-27 Music on Hold 2-27

3
CHA PTER
Network Infrastructure Requirements for IP Telephony LAN Infrastructure 3-3 Traffic Classification 3-4 Interface Queuing 3-4 Bandwidth Provisioning 3-4
3-1
WAN Infrastructure 3-5 Bandwidth Provisioning 3-6 Provisioning for Voice Bearer Traffic 3-7 Provisioning for Call Control Traffic with Centralized Call Processing Provisioning for Call Control Traffic with Distributed Call Processing Traffic Prioritization 3-12 Link Efficiency Techniques 3-13 Traffic Shaping 3-15
4
3-8 3-10
CHA PTER
Choosing a Cisco IP Telephony Gateway Understanding Cisco Gateways 4-1 Cisco Access Analog Gateways 4-1 Cisco Access Digital Trunk Gateways Gateway Requirements
4-2
4-1
4-2
Gateway Protocols 4-2 Selecting the Gateway Protocol
4-3
Gateway Protocol and Core Feature Requirements 4-4 DTMF Relay 4-5 SCCP Gateways 4-5 H.323 Gateways 4-5 MGCP Gateway 4-5 Supplementary Services 4-5 SCCP Gateways 4-6 H.323 Gateways 4-6 MGCP Gateway 4-7 Cisco CallManager Redundancy 4-8 SCCP Gateways 4-8 H.323 Gateways 4-9 MGCP Gateway 4-9 Call Survivability in Cisco CallManager 4-10 Endpoint Rules for Gateway Call Survivability 4-10
Contents
Site-Specific Gateway Requirements 4-11 Q.SIG Support 4-12 Site Specific Gateway Features Summary Summary
5
4-16
4-13
CHA PTER
Transcoding, Conferencing, and MTP Resources Media Resource Types 5-1 Media Termination Point (MTP) 5-1 Transcoder 5-2 Unicast Conference Bridge 5-2
5-1
MTP and Transcoding Resources 5-3 Software MTP Resources 5-4 Hardware MTP and Transcoding Resources 5-4 Catalyst 4000 MTP and Transcoding Services 5-5 Catalyst 6000 MTP and Transcoding Services 5-5 Cisco Catalyst MTP Constraints 5-6 Cisco VG200 MTP and Transcoding Services 5-7 Cisco ICS 7750 MTP and Transcoding Services 5-7 Provisioning MTP and Transcoding Resources 5-8 Application Scenarios 5-9 Single-Site Deployments 5-10 Multi-Site WAN Deployments with Centralized Call Processing Multi-Site WAN Deployments with Distributed Call Processing IP PSTN Access 5-12 Conferencing Resources 5-13 Software Conferencing Resources 5-15 Hardware Conferencing Resources 5-16 Catalyst 4000 Conferencing Services 5-16 Catalyst 6000 Conferencing Services 5-17 Cisco VG200 Conferencing Services 5-18 Provisioning Conference Resources 5-19 Application Scenarios 5-19 Single-Site Deployments 5-19 Multi-Site WAN Deployments with Centralized Call Processing Multi-Site WAN Deployments with Distributed Call Processing
6
5-10 5-11
5-19 5-22
CHA PTER
Call Processing with Cisco CallManager Cluster Operation and Scalability Guidelines Device Weights 6-3
6-1 6-1
vi
EDCS-197018
Contents
Server Memory Requirements 6-7 Intracluster Communication 6-7 Cisco CallManager Redundancy 6-8 Redundancy Group Configuration 6-9 Device Pool Configuration 6-10 Clustering Guidelines
6-12
Intercluster Communication 6-13 Cluster Provisioning for the Campus 6-14 Clusters for Multi-site WAN with Distributed Call Processing Clusters for Multi-site WAN with Centralized Call Processing The Effects of Network Delay on Call Processing 6-18 Clustering Over the WAN 6-19 WAN Considerations 6-19 Intra-Cluster Communications 6-20 Local Failover Deployment Model 6-21 Remote Failover Deployment Model 6-24 Common Design Guidelines for Clustering over the WAN Media Resources 6-33 Survivable Remote Site Telephony (SRST) 6-35 SRST Features and Requirements 6-37 SRST Design Considerations 6-38 SRST with Automated Attendant 6-40
7
6-16 6-18
6-26
CHA PTER
Call Admission Control Bandwidth Calculations
7-1 7-2 7-2
Call Admission Control with Cisco CallManager Locations Call Admission Control with a Gatekeeper 7-4 Gatekeeper Operations 7-5 Gatekeeper Discovery 7-5 Registration Process 7-6 Admission Requests 7-7 Disengage Request 7-8 Bandwidth Requests 7-8 Technology Prefix 7-9 E.164 Address Resolution 7-9 ARQ Parsing Order 7-10 Cisco IOS Gatekeeper Commands 7-10 Debug Commands 7-11 Cisco CallManager Configuration 7-11
vii
Contents
Gatekeeper Used for Call Admission Control Gateway Configuration 7-13 Intercluster Trunk Gateways 7-16 Summary of Call Admission Control
8
7-18
7-12
CHA PTER
Dial Plan
8-1 8-2
Overview of IP Telephony Dial Plans
Dial Plan Components and Operation 8-4 External Route Pattern Architecture 8-5 Route Patterns 8-7 Route Lists 8-11 Route Groups 8-14 Devices 8-15 Calling Restrictions 8-16 Partitions 8-16 Calling Search Spaces 8-16 Translation Patterns 8-19 Voice Mail Integration and Cisco CallManager Dial Plans Voice Mail Integration via SCCP 8-23 Voice Mail Integration via SMDI 8-23
8-21
Dial Plan Guidelines for IP Telephony Deployment Models 8-25 Single-Site Deployment 8-26 Multi-Site IP WAN with Distributed Call Processing 8-28 Route Pattern Structure 8-29 Partitions and Calling Search Spaces 8-30 Multi-Site IP WAN with Centralized Call Processing 8-30 Route Pattern Structure 8-31 Partitions and Calling Search Spaces 8-32 Multi-Site IP WAN with Overlapping Extensions 8-33 Partitions and Calling Search Spaces 8-34 Outbound Calls 8-35 Inter-Site Calls 8-35 Incoming Calls 8-36 Voice Mail Considerations 8-36
9
CHA PTER
Voice Mail Integration with Cisco CallManager Cisco CallManager and Voice Mail
9-1 9-4
9-1
Existing Versus New Voice Mail Systems
Voice Mail and Cisco CallManager Release 3.2

9-6
viii
EDCS-197018
Contents
Cisco Unity
9-7
Cisco Digital PBX Adapter (DPA) 9-9 Understanding How the DPA Works 9-10 Why is the DPA Needed? 9-10 Can I Just Use SMDI? 9-10 What If I Cannot Use SMDI? 9-10 Choosing an Integration Mode 9-11 Using the Simple Integration Mode 9-11 Using the Hybrid Integration Mode 9-12 Using the Multiple Integration Mode 9-13
10
CHA PTER
Migration to an IP Telephony Network Network Models

10-1
10-1
PBX and Voice Messaging Interfaces and Protocols Simple IP Network Migration Sequence
10-3
10-2
Reference Models for Migration Configurations Detailed Discussion of Model A 10-6 Detailed Discussion of Model B 10-9 Detailed Discussion of Model C 10-11 Detailed Discussion of Model D 10-13
10-5
Cisco Digital PBX Adapter (DPA) 10-14 Understanding How the DPA 7630 Works 10-15 Why is the DPA 7630 Needed? 10-15 Can I Just Use SMDI? 10-15 What If I Cannot Use SMDI? 10-15 Choosing an Integration Mode 10-16 Using the Simple Integration Mode 10-16 Using the Hybrid Integration Mode 10-17 Using the Multiple Integration Mode 10-18
11
CHA PTER
CTI Applications Architecture and Design
11-1
Cisco CallManager Application Interfaces 11-1 CTI Architecture 11-3 Cisco CallManager Server 11-3 CTI Application Platform 11-4 CTI Devices 11-4 CTI Manager 11-5 CTI Manager Configuration 11-7 CTI Manager Provisioning 11-8
ix
Contents
Ensuring Normal Operations CTI Redundancy 11-12 CTI Fail-Back 11-14
11-12
CTI Design Consideration 11-14 Scalability 11-14 Application Scalability 11-15 Cisco CallManager Scalability 11-15 Grouping CTI devices 11-21 Redundancy 11-22 General Redundancy Considerations 11-22 Redundancy Considerations for Single-Site Call Processing Deployments 11-23 Redundancy Considerations for a Multi-Site WAN with Centralized Call Processing Redundancy Considerations for a Multi-Site WAN with Distributed Call Processing Quality of Service 11-26 Example of CTI Provisioning for Scalability and Redundancy 11-27 System Profile 11-28 Design Assumptions 11-28 Design Approach 11-29 Identify CTI Resources 11-29 Calculate Package Weights for Each Application 11-29 Group the CTI Devices into Device Pools 11-31 Provision the CTI Resources on the Cisco CallManager and CTI Manager Servers Provision Backup Servers for Failover Conditions 11-33 Summary
12
11-35
11-23 11-25
11-31
CHA PTER
Cisco IP IVR System Design Considerations IP IVR Architecture

12-1
12-1
Cisco CallManager Device Weight Provisioning for IP IVR 12-2 Additional IP-IVR Scalability Considerations 12-3 IP IVR Co-Resident with Cisco CallManager 12-3 Standalone IP IVR Configuration 12-3 Redundancy Considerations 12-4 CTI Manager Fails 12-4 Cisco CallManager Server Fails 12-6 IVR Application Fails 12-6 Summary
12-8
EDCS-197018
Contents
CHA PTER
13
Cisco IP SoftPhone Design Considerations
13-1
Provisioning Guidelines for Cisco IP SoftPhone 13-1 Scalability Considerations 13-3 Example Device Weight Calculation 13-3 Maximum Cisco IP SoftPhone Configuration Limits Redundancy Considerations 13-4 Bandwidth Provisioning Considerations 13-6 Call Admission Control 13-6
14
13-3
CHA PTER
Directory Access for Cisco IP Telephony Endpoints Directory Access and Directory Integration
14-1
14-1
Configuring Directory Access 14-3 Directory Access for Cisco IP Phones 14-3 Directory Access for Cisco IP SoftPhone 14-5 Additional References
15
14-6
CHA PTER
Security Recommendations for IP Telephony IP Telephony Security Guidelines Establish Physical Security
15-2 15-1
15-1
Protect the Network Elements 15-3 Secure Login Access 15-3 Follow Sound Password and Authentication Practices 15-3 Assign Unique PVID to all 802.1Q Trunking Ports 15-4 Ensure Unused Router Services Are Turned Off 15-4 Securely Configure Network Management Functions 15-4 Use Logging Services to Track Access and Configuration Changes Design a Secure IP Network 15-5 Creating and Assigning VLANs and Broadcast Domains Implementing Packet Filters 15-7 Directed Broadcasts 15-7 Source-Routed Packets 15-7 IP Spoofing 15-7 ICMP Redirects 15-8 TCP Intercept 15-8 Permitting Other Services 15-8 Protecting the VoIP Gateways 15-10 Firewalls 15-10 Secure the Cisco CallManager Server
15-12 15-5
15-5
xi
Contents
Turn off Unnecessary Services 15-12 Secure the NTFS File System 15-13 Enable System Auditing and Logging 15-14 Configure Certificate Authority 15-15 Secure the IIS Service 15-15 Enable Certificate Authentication Only 15-16 Enable W3C Extended Logging Format 15-16 Clear Indexing 15-16 Remove IIS Virtual Directories 15-16 Remove All Sample Application Directories 15-16 Set Appropriate Virtual Directory Permissions in Web Application Space Set Appropriate IIS Log File Permissions 15-17 Set the Security Access Permissions 15-17 Force the Use of HTTPs Only 15-17 Secure the SQL Server 15-18 Use a Separate Group for SQL Server Administration 15-18 Set the SQL Server to Use Windows 2000 Authentication Mode 15-18 Enable SQL Server Auditing 15-18 Remove Any Software MTP and Conferencing Services 15-18 Configure Cisco CallManager SNMP Securely 15-19 Additional References
16
15-19
15-17
CHA PTER
Network Management Recommendations for IP Telephony Voice Management Overview 16-1 Voice Management Basics 16-1 CiscoWorks Voice Management Tools and Architecture 16-2 CiscoWorks IP Telephony Management Tools 16-2 Cisco Network Management Architecture 16-3 Deployment Considerations 16-4 Cisco CallManager Settings 16-4 System Requirements 16-5 Network Analysis Module Deployment 16-5
16-1
CiscoWorks Network Management Best Practices 16-6 Best Practices for Using CiscoWorks LAN Management Solution (LMS) 16-6 Best Practices for Using CiscoWorks VoIP Health Monitor (VHM) 16-7 Best Practices for Using CiscoWorks QoS Policy Manager (QPM) 16-8 Best Practices for Using CiscoWorks Service Level Manager (SLM) 16-8 Best Practices for Using CiscoWorks Internetwork Performance Monitor (IPM) Additional References
16-9
16-8
xii
EDCS-197018
Preface
This preface describes the purpose, scope, intended audience, and general organization of this Cisco IP Telephony Solution Reference Network Design Guide. It also provides information on how to order documentation from Cisco Systems.
Purpose
This document provides guidelines, recommendations, and best practices to help you design an IP telephony solution for your enterprise using the Cisco Architecture for Voice, Video, and Integrated Data (AVVID).
Scope
This document describes the products and features used to build an IP telephony system, and it gives recommendations on how to combine those elements into an effective solution for your enterprise. However, this document does not contain specific implementation or configuration details for the products and features. For details about a particular product or feature, refer to the technical documentation available online at Cisco.com. (See Obtaining Documentation, page xv.)
Note
Unless stated otherwise, the solution designs presented in this document require Cisco CallManager Release 3.1 or 3.2, and the information presented here applies only to those releases.
Audience
This document is intended for Cisco customers, partners, and systems engineers who will be designing and implementing an IP telephony system in the enterprise environment.
Organization
This guide contains the chapters and information listed in the following table.
xiii
Preface Organization
Note
Cisco strongly recommends that you carefully read chapters 1, 2, and 3 before attempting to design an IP telephony solution and before reading any other sections of this guide.
Chapter 1 2
Title Overview of Cisco AVVID IP Telephony Solutions IP Telephony Deployment Models
Description Provides an overview of Cisco AVVID and some of the available Cisco products for creating an IP telephony solution. Describes the primary models used to deploy an IP telephony solution and explains when to use each model.
Note
This guide makes frequent references to these deployment models. Cisco recommends that you read this chapter carefully and understand the main characteristics of each model.
3 4 5 6 7 8 9
Network Infrastructure Requirements for IP Telephony Choosing a Cisco IP Telephony Gateway Transcoding, Conferencing, and MTP Resources Call Processing with Cisco CallManager Call Admission Control Dial Plan Voice Mail Integration with Cisco CallManager
Describes key Quality of Service (QoS) features of the Cisco AVVID network infrastructure and how they apply to IP telephony. Presents guidelines and recommendations on how to select the appropriate gateways for your IP telephony network. Explains how Cisco CallManager handles media streams and describes the resources available for processing the streams. Describes the call processing resources available in Cisco CallManager and gives guidelines for provisioning those resources. Explains how to maintain voice quality for calls across the IP WAN. Lists important considerations for designing a good dial plan and explains some of the implementation mechanisms available. Describes a number of possible solutions for integrating both traditional voice mail systems and unified messaging systems with Cisco CallManager.
10 11 12 13 14
Migration to an IP Telephony Network Presents various models and scenarios for migrating from a traditional PBX system to an IP telephony system. CTI Applications Architecture and Design Cisco IP IVR System Design Considerations Cisco IP SoftPhone Design Considerations Directory Access for Cisco IP Telephony Endpoints Security Recommendations for IP Telephony Network Management Recommendations for IP Telephony Describes the Computer Telephony Interface (CTI) and how to provision it to handle the applications that will use it. Describes the IP IVR architecture and how it affects call processing with Cisco CallManager. Lists a few key design considerations for deploying Cisco IP SoftPhones in your IP telephony system. Describes how to provide Cisco IP Telephony endpoints, such as Cisco IP Phones and Cisco IP SoftPhone, with access to a corporate LDAP directory. Presents various considerations and options for securing your IP telephony system. Describes some of the tools available for managing your IP telephony network.
15 16
xiv
EDCS-197018
Preface Obtaining Documentation
Obtaining Documentation
The following sections explain how to obtain documentation from Cisco Systems.
World Wide Web

You can access the most current Cisco documentation on the World Wide Web at the following URL: http://www.cisco.com Translated documentation is available at the following URL: http://www.cisco.com/public/countries_languages.shtml
Documentation CD-ROM
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.
Ordering Documentation
Cisco documentation is available in the following ways:
Registered Cisco Direct Customers can order Cisco product documentation from the Networking Products MarketPlace: http://www.cisco.com/cgi-bin/order/order_root.pl
Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store: http://www.cisco.com/go/subscription
Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
Documentation Feedback
If you are reading Cisco product documentation on Cisco.com, you can submit technical comments electronically. Click Leave Feedback at the bottom of the Cisco Documentation home page. After you complete the form, print it out and fax it to Cisco at 408 527-0730. You can e-mail your comments to bug-doc@cisco.com. To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address: Cisco Systems Attn: Document Resource Connection 170 West Tasman Drive San Jose, CA 95134-9883
xv
Preface Obtaining Technical Assistance
We appreciate your comments.
Obtaining Technical Assistance

Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.
Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world. Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you to

Streamline business processes and improve productivity Resolve technical issues with online support Download and test software packages Order Cisco learning materials and merchandise Register for online skill assessment, training, and certification programs
You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com, go to the following URL: http://www.cisco.com
Technical Assistance Center

The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center. Inquiries to Cisco TAC are categorized according to the urgency of the issue:

Priority level 4 (P4)You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration. Priority level 3 (P3)Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue. Priority level 2 (P2)Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available. Priority level 1 (P1)Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.
Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.
xvi
EDCS-197018
Cisco TAC Web Site

The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to the following URL: http://www.cisco.com/tac All customers, partners, and resellers who have a valid Cisco services contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to the following URL to register: http://www.cisco.com/register/ If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com registered user, you can open a case online by using the TAC Case Open tool at the following URL: http://www.cisco.com/tac/caseopen If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.
Cisco TAC Escalation Center

The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; these classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer will automatically open a case. To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following URL: http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). In addition, please have available your service agreement number and your product serial number.
xvii
xviii
EDCS-197018
C H A P T E R
Overview of Cisco AVVID IP Telephony Solutions

IP telephony refers to the technology for transmitting voice communications over a network using standards-based Internet Protocol (IP). The Cisco Architecture for Voice, Video, and Integrated Data (AVVID) provides the infrastructure and feature set for creating a single converged network that can handle voice, video, and data traffic simultaneously. Cisco AVVID provides this capability while maintaining a high level of availability, quality of service (QoS), and security for your network. Built on the Cisco AVVID Network Infrastructure, a Cisco AVVID IP Telephony solution delivers high-quality IP voice and fully integrated communications by allowing data, voice, and video to be transmitted over a single network infrastructure. Leveraging the framework provided by Cisco AVVID, the Cisco AVVID IP Telephony solution delivers unparalleled performance and capabilities to address current and emerging communications needs in the enterprise environment. Cisco AVVID IP Telephony solutions are designed to optimize feature functionality, reduce configuration and maintenance requirements, and provide interoperability with a wide variety of other applications. This chapter presents an overview of the Cisco AVVID IP Telephony solution and its major components. This chapter contains the following main sections:

Why IP Telephony?, page 1-1 Architecture Overview, page 1-3 Cisco CallManager Deployment Models, page 1-5 Applications, page 1-7 Components That Apply to All Deployment Models, page 1-11
Note
Unless stated otherwise, the information in this solutions guide applies to Cisco CallManager releases 3.1 and 3.2.
Why IP Telephony?
It is widely accepted and acknowledged by the communications industry and by industry analysts as a whole, that IP will become the universal transport of the future. The rapid adoption and migration of vendors to IP as a transport for data, voice, and video applications further endorses this transition to a converged networking paradigm. This migration even includes those vendors who have historically used time-division multiplexing (TDM) infrastructures and relied upon traditional practices. The message is clear: the move toward IP is happening now.
1-1
Chapter 1 Why IP Telephony?
Cisco provides an end-to-end IP network solution based on open standards, with an established portfolio of applications and an ecosystem of partners to support your transition. The Cisco AVVID IP Telephony solution is the leading converged network telephony solution for organizations that want to increase productivity and reduce costs associated with managing and maintaining separate voice and data networks. The flexibility and sophisticated functionality of the Cisco AVVID Network Infrastructure provides the framework that permits rapid deployment of emerging applications such as desktop IP telephony, unified messaging, desktop collaboration, enterprise application integration with IP phone displays, and collaborative IP contact centers. These applications enhance productivity and increase enterprise revenues. Figure 1-1 illustrates a typical IP telephony solution employing the Cisco AVVID network infrastructure, with Cisco CallManager as the call processing agent.
Figure 1-1 Typical IP Telephony Solution
Headquarters
Applications (Voice mail, IVR, ICD, ...)
Branch (with Call Processing and Applications)
M M M M M M
Cisco CallManager cluster
V GK
PSTN IP IP
V
IP IP IP WAN
Branch (with SRST and Applications)
1-2
EDCS-197018
74350
Rest of world
IP
IP
Chapter 1
Overview of Cisco AVVID IP Telephony Solutions Architecture Overview
Architecture Overview
The foundation architecture of the Cisco AVVID IP Telephony solution consists of four primary components (see Figure 1-1):
Cisco AVVID Network Infrastructure The infrastructure includes public switched telephone network (PSTN) gateways, analog phone support, and digital signal processor (DSP) farms. The infrastructure can support multiple client types such as hardware phones, software phones, and video devices. Infrastructure also includes the interfaces and features necessary to integrate legacy PBX, voice mail, and directory systems. Typical products used to build the infrastructure include Cisco voice gateways (non-routing, routing, and integrated), Cisco Catalyst switches, and Cisco routers.
Communication endpoints A communication endpoint is a user instrument either a desk phone or even a software phone application that runs on a PC. In the IP environment, each phone has an Ethernet connection. IP phones have all functions you expect from a telephone as well as more complicated features, such as the ability to access World Wide Web sites. Typical user instruments include Cisco IP Phones and Cisco IP SoftPhones.
Call processing agent At the heart of the IP telephony system is Cisco CallManager, the call processing agent. Cisco CallManager software extends enterprise telephony features and capabilities to packet telephony network devices such as IP phones, media processing devices, voice-over-IP (VoIP) gateways, and multimedia applications. Additional data, voice, and video services such as unified messaging, multimedia conferencing, collaborative contact centers, and interactive multimedia response systems interact with the IP telephony solution through Cisco CallManager's open telephony application programming interfaces (APIs).
Applications As defined by Cisco AVVID, applications are physically independent from the call processing and voice processing infrastructure, and they may reside anywhere within your network Applications improve the end-to-end capabilities of the Cisco AVVID IP Telephony solution by adding sophisticated telephony and converged network features, such as the following:
Cisco IP SoftPhone Extension mobility Multi-party voice conferencing Unified messaging Web services for IP phones Cisco Personal Assistant Cisco Customer Response Solutions (CRS) platform Cisco IP Integrated Contact Distribution (IP ICD) Cisco IP Interactive Voice Response (IP IVR)
1-3
Chapter 1 Architecture Overview
Security
The Cisco AVVID IP Telephony solution addresses security in the following categories:

Physical security for restricting physical access to important application servers and network components Network access security to prevent hostile logins or attacks Careful network design and management to enhance security Security measures for Cisco CallManager
Quality of Service
Voice, as a class of IP network traffic, has strict requirements concerning packet loss, delay, and delay variation (also known as jitter). To meet these requirements for voice traffic, the Cisco AVVID IP Telephony solution includes quality-of-service (QoS) features such as classification, queuing, traffic shaping, compressed Real-Time Transport Protocol (cRTP), and Transmission Control Protocol (TCP) header compression. The QoS components of the Cisco AVVID IP Telephony solution are provided through the rich IP traffic management, queueing, and shaping capabilities of the Cisco AVVID Network Infrastructure. Key elements of this infrastructure that enable QoS for IP telephony include:

Traffic marking Enhanced queuing services (Catalyst 3500 and 4000 switches) Link fragmentation and interleaving (LFI) Compressed RTP (cRTP) Low latency queuing (LLQ) Link efficiency Traffic shaping Call admission control
Network Management
The Cisco AVVID Network Infrastructure offers a number of network management, QoS, and security management tools that support the IP Telephony solution. CiscoWorks2000 includes a number of network management tools to manage the operations, administration, and maintenance of IP telephony networks. Cisco CallManager also offers enhanced software and configuration management tools that leverage the strength and flexibility of IP networks. The Cisco CallManager user interface simplifies the most common subscriber and telephony configuration tasks by building upon legacy telephony administration systems and adding software and web-based applications.
1-4
EDCS-197018
Chapter 1
Overview of Cisco AVVID IP Telephony Solutions Cisco CallManager Deployment Models
Cisco CallManager Deployment Models

Cisco CallManager is the core call processing software for the Cisco AVVID IP Telephony solution. It builds call processing capabilities on top of the Cisco AVVID Network Infrastructure. Cisco CallManager software extends enterprise telephony features and capabilities to packet telephony network devices such as IP phones, media processing devices, voice-over-IP (VoIP) gateways, and multimedia applications. There are several basic models for deploying the call processing capabilities of Cisco CallManager, depending on the size, geographical distribution, and functional requirements of your enterprise:

Single-Site Call Processing Model, page 1-5 Multi-Site WAN Model with Centralized Call Processing, page 1-5 Multi-Site WAN Model with Distributed Call Processing, page 1-6 Clustering Over the IP WAN, page 1-6
Single-Site Call Processing Model

In the single-site model, each site or campus has its own Cisco CallManager or Cisco CallManager cluster to perform call processing functions. No voice traffic travels over the IP WAN. Instead, external calls or calls to remote sites use the public switched telephone network (PSTN). The single-site model has the following characteristics:

Support for 10,000 users Cisco CallManager cluster for redundancy and system scaling Inline power to IP phone sets Single cable for connecting both IP phone and PC Quality of service from the desktop IP addressing for easy adds, moves, and changes
Multi-Site WAN Model with Centralized Call Processing

In the multi-site WAN model with centralized call processing, the Cisco CallManager cluster resides at the main (or central) campus, and communication with remote branch offices normally takes place over the IP WAN. If either the central site or the IP WAN is down, the remote sites can continue to have service through a feature called Survivable Remote Site Telephony (SRST), which runs on Cisco IOS gateways. The remote sites can also place calls over the PSTN if the IP WAN is temporarily oversubscribed. Each central site can support up to 10,000 users, and you can interconnect a number of central sites with intercluster trunks. In summary, the multi-site WAN model with centralized call processing has the following characteristics:

Support for 10,000 users per central site Cisco CallManager and voice mail at the central site Centralized dial plan and administration Call admission control based on locations, to protect voice quality of IP WAN calls
1-5
Chapter 1 Cisco CallManager Deployment Models
Survivable Remote Site Telephony for branch sites Intercluster trunks to connect multiple central sites
Multi-Site WAN Model with Distributed Call Processing

In the multi-site WAN model with distributed call processing, each site has its own Cisco CallManager cluster for call processing. Communication between sites normally takes place over the IP WAN, with the PSTN serving as a backup voice path. Each site can support up to 10,000 users, and you can interconnect any number of sites across the IP WAN. In summary, the multi-site WAN model with distributed call processing has the following characteristics:

Support for 10,000 users per site Cisco CallManager and voice mail at the each site No limit to the number of sites interconnected across the IP WAN Transparent use of the PSTN if the IP WAN is not available Cisco IOS gatekeeper for call admission control and E.164 address resolution
Clustering Over the IP WAN

You may deploy a single Cisco CallManager cluster across multiple sites that are connected by an IP WAN with QoS features enabled. Clustering over the WAN can support two types of deployments:
Local failover deployment model Local failover requires that you place the Cisco CallManager subscriber and backup servers at the same site, with no WAN between them. This deployment model is ideal for two or three sites with Cisco CallManager servers and a maximum of 5000 or 2500 IP phones per site, respectively. This model allows for up to 10,000 IP phones in the two-site configuration and 7,500 IP phones in the three-site configuration.
Remote failover deployment model Remote failover allows you to deploy the backup servers over the WAN. Using this deployment model, you may have up to six sites with Cisco CallManager subscribers and one or two sites containing the Cisco CallManager backup servers. This deployment allows for up to 10,000 IP phones shared over the required number of sites.
The key advantages of clustering over the WAN are:

Single point of administration for IP phones for all sites within the cluster Feature transparency Shared line appearances Extension mobility within the cluster Unified dial plan
These advantages make clustering over the WAN well suited as a disaster recovery plan for business continuance sites or as a single solution for small or medium sites. For further information on clustering over the WAN, refer to the chapter on Call Processing with Cisco CallManager.
1-6
EDCS-197018
Chapter 1
Overview of Cisco AVVID IP Telephony Solutions Applications
Applications
The following applications enhance the capabilities of the Cisco AVVID IP Telephony solution:

Cisco IP SoftPhone, page 1-7 Extension Mobility, page 1-7 Multi-Party Voice Conferencing, page 1-8 Unified Messaging, page 1-8 Web Services for IP Phones, page 1-8 Cisco Personal Assistant, page 1-9 Cisco Customer Response Solutions Platform, page 1-10 Cisco IP Integrated Contact Distribution (IP ICD), page 1-10 Cisco IP Interactive Voice Response (IP IVR), page 1-11
Cisco IP SoftPhone
Cisco IP SoftPhone is a desktop application that turns your computer into a full-feature telephone with the added advantages of call tracking, desktop collaboration, and one-click dialing from online directories. You can also use Cisco IP SoftPhone in tandem with a Cisco IP Phone to place, receive and control calls from your desktop PC. All features are functional in both modes of operation. The Cisco IP SoftPhone offers users the great benefit of having a portable office IP phone to use anywhere an Internet connection is available. For example, a wireless connection with a Cisco Aironet card to the CallManager allows you to have your office phone with you when you travel. Calls made via the Cisco IP SoftPhone in this roaming mode are routed through the same gateway as your office phone. This capability saves your enterprise the call processing bandwidth of managing multiple legs of a call that would otherwise go through a different trunk and be re-routed through the network, thus saving on long-distance toll charges. For more information about Cisco IP SoftPhone, refer to the product literature at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/ip_7960/softphon/ver_1_2/eng/i ndex.htm
Extension Mobility
The Cisco CallManager Extension Mobility feature allows users within a Cisco CallManager cluster to configure any Cisco IP Phone 7960 or 7940 as their own, temporarily, by logging in to that phone. Once logged in, the phone adopts the user's personal phone number(s), speed dials, services links and other user-specific properties. After logout, the phone adopts the original user profile. With Cisco CallManager Extension Mobility, several employees can share office space on a rotational basis instead of having a designated office. This approach is commonly used in work environments such as sales offices and consulting firms where employees do not routinely conduct business in the same place or keep the same hours every day. For more information on Extension Mobility, refer to the documentation at http://www.cisco.com/univercd/cc/td/doc/product/voice/serv_fea/ext_serv/index.htm
1-7
Chapter 1 Applications
Multi-Party Voice Conferencing

Cisco Conference Connection enhances the on-demand conferencing features of Cisco CallManager with a highly cost-effective conferencing application that supports both scheduled or meet-me conferences. For more information, refer to the Cisco Conference Connection product literature at http://www.cisco.com/univercd/cc/td/doc/product/voice/cccdocs/index.htm
Unified Messaging
Cisco Unity is the premier unified communications solution for enterprise organizations. It delivers powerful unified messaging (email, voice, and fax messages sent to one inbox) and intelligent voice messaging (full-featured voice mail providing advanced functionality) to improve communications, boost productivity, and enhance customer service capabilities across your organization. Infrastructure is decreased because a single application can now provide voice, email, and fax. Productivity is increased because what were once disparate message types are now available via the users most convenient or preferred interface. Cisco Unity provides advanced, convergence-based communication services and integrates them with the desktop applications you use every day. With Cisco Unity Unified Messaging, you can listen to your email over the telephone, check voice messages from the Internet, and (when integrated with a supported third- party fax server) send faxes anywhere. Cisco Unity Voice Messaging features robust automated attendant functionality that includes intelligent routing and easily customizable call screening and message notification options. In summary, Cisco Unity provides:

True unified messaging Automated attendant features Browser-based personal and system administration interfaces Convergence-ready communications Advanced features, including text-to-speech conversion and mobile message notification Integration with Microsoft Outlook and Exchange email systems
For more information, refer to the Cisco Unity product literature at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/index.htm
Web Services for IP Phones

You can use Cisco IP Phones, such as the Cisco IP Phone 7960 and 7940, to deploy customized client services with which users can interact via the keypad and display. Services are deployed using the HTTP protocol from standard web servers, such as Microsoft IIS. You can create applications for Cisco IP Phone services by using the eXtensible Markup Language (XML) Application Programming Interface (API). Some typical services that might be supplied to an IP phone include:

Employee alerts Weather forecasts Stock information
1-8
EDCS-197018
Chapter 1
Overview of Cisco AVVID IP Telephony Solutions Applications
Contact information Company news To-do lists Daily schedule
For more information on developing service applications for IP phones, refer to the documentation at http://www.cisco.com/univercd/cc/td/doc/product/voice/vpdd/cdd/3_1/ipphsrvs.htm
Cisco Personal Assistant

Cisco Personal Assistant functions like a virtual assistant, selectively forwarding and screening incoming calls and helping users make outgoing calls. Personal Assistant provides the following features:
Rule-Based Call Routing Personal Assistant can forward and screen incoming calls based on rules that users devise. Incoming calls can be handled according to caller ID, date and time of day, or the user's meeting status based on the user's calendar (such as office hours, meeting schedules, vacations, holidays, and so forth). Personal Assistant can also selectively route calls to other telephone numbers. Thus, an incoming call to a desk phone can be routed to a cell phone, home phone, or other phone, based on the call routing rules that users create. An incoming call can even generate an email-based page.
Speech-Enabled Directory Dialing Users can dial phone numbers by telling Personal Assistant the person's name. Personal Assistant obtains the telephone number from the corporate directory or personal address book.
Speech-Enabled Voice-Mail Browsing Users can use voice commands to browse, listen to, and delete voice-mail messages.
Speech-Enabled Simple Ad Hoc Conferencing Users can initiate conference calls by telling Personal Assistant to set up a conference call with the desired participants or groups.
Follow-Me Call Transferring Users can tell Personal Assistant to use an alternate telephone number as their primary location for a period of time. Personal Assistant routes calls to the follow-me telephone. For example, a user could route calls to a hotel room telephone during a business trip.
Simple Automated Attendant for Dial by Name You can set up a simple automated attendant to allow callers to reach people by saying their names rather than having to know their phone numbers.
Support for Multiple Locales You can support users or outside callers that speak different languages. Personal Assistant uses the language they select through the user web interface. If you create a Personal Assistant automated attendant, callers can switch between supported locales.
For more information on Personal Assistant, refer to the documentation at http://www.cisco.com/univercd/cc/td/doc/product/voice/assist/index.htm
1-9
Chapter 1 Applications
Cisco Customer Response Solutions Platform

Cisco IP Telephony Solutions for the Enterprise provides all of the components you need to design and deploy a complete IP telephony solution. The Cisco Customer Response Solutions (CRS) platform builds on this foundation to provide interactive telephony and multimedia services for your customers. The Cisco CRS platform provides a multimedia (voice/data/Web) IP-enabled customer care application environment. The Cisco CRS platform uses Voice over IP (VoIP) technology, so your telephony network can share resources with your data network. Because the CR Platform uses an open architecture that supports industry standards, you can integrate your applications with a wide variety of technologies and products, including integrate agent-assisted and self-service customer assistance applications. The Cisco CRS platform significantly reduces the need for costly T1/E1 equipment required to deploy traditional Interactive Voice Response (IVR) and private branch exchange (PBX) integrations. You can replace bulky and expensive telephony hardware with Windows 2000-based computers, and you can upgrade simply by installing new software. You can position your CR Platform application server anywhere on the IP network, and you can administer your applications using a web browser on any computer on the IP network. Each product in the Cisco Customer Response Solutions (CRS) family includes everything you need to automate interactions with your customers, from design-time to run-time. Because the Cisco CRS Editor does not use a complicated programming language, you can use its graphical user interface to easily create and debug application scripts for automating your customer interactions. Cisco CRS includes an industry-standard Lightweight Directory Access Protocol (LDAP) directory to store the application scripts you build with the editor (or you can also use Microsoft Active Directory). For more information on the Cisco CRS platform, refer to the documentation at http://www.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/apps_22/index.htm
Cisco IP Integrated Contact Distribution (IP ICD)

Cisco IP Integrated Contact Distribution (IP ICD) is an inexpensive, easy-to-install, and easy-to-use automatic call distribution (ACD) system for enterprise organizations. Cisco IP ICD is one of a series of solutions built on the Cisco Customer Response Solutions (CRS) platform, an open platform for customer response applications. Cisco IP ICD can integrate seamlessly with all other Cisco customer response applications, including Cisco IP Interactive Voice Response (IP IVR) and Cisco IP Automated Attendant (IP AA). IP ICD provides the following key benefits:

Low-cost, entry-level ACD that is easy to install, administer, and use Support for multimedia (voice, data, and Web) access when used with Cisco IP IVR Complete customization tools for call flow scripts Seamless integration with any current or future Cisco customer response applications
For more information about IP ICD, refer to the product literature at http://www.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/apps_22/index.htm
1-10
EDCS-197018
Chapter 1
Overview of Cisco AVVID IP Telephony Solutions Components That Apply to All Deployment Models
Cisco IP Interactive Voice Response (IP IVR)

Cisco IP Interactive Voice Response (IP IVR) is a multimedia (voice/data/Web) IP-enabled Interactive Voice Response solution that offers an open and feature-rich foundation for the creation and delivery of IVR applications via Internet technology. In addition to handling traditional telephony contacts, you can create IP IVR applications to respond to HTTP requests and send email. Cisco IP IVR automates call handling by autonomously interacting with users. It also processes user commands to facilitate command response features such as access to checking account information or user-directed call routers. The IP IVR also performs "prompt and collect" functions to obtain user data like passwords or account identification. Cisco IP IVR is one of a series of solutions built on the Cisco Customer Response Solutions (CRS) platform, an open platform for customer response applications. IP IVR supports Open Database Connectivity (ODBC) access to Microsoft Structured Query Language (SQL) Servers, Oracle, Sybase, and IBM DB2 databases. You can use IP IVR to extract and parse Web-based content and present the data to users through a telephony or HTTP interface. For more information about IP IVR, refer to the product literature at http://www.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/apps_22/index.htm
Components That Apply to All Deployment Models

The components and features described in this section apply equally to each of the deployment models described in this document.
Voice, Fax, and Modem Gateways

Gateways provide access to other voice networks. Gateway selection depends on the following requirements:

Voice, fax, and modem capabilities Analog or digital access Signaling protocol (PRI, CAS, etc.) The protocol used to control the gateways, which can provide additional functionality that is desirable
Each site could have different requirements for functionality and support. In addition, gateway selection might depend on the type of platform already deployed. For example, a large campus with many Cisco Catalyst 6000 switches may opt to use the cards that fit within that chassis. A small site might use an existing Cisco IOS router with voice interface modules as an integrated solution. Non-IP voice mail system might also require gateways, which, in most cases, would be MGCP gateway.
1-11
Chapter 1 Components That Apply to All Deployment Models
Station Devices
The station devices required by the end users greatly influence the telephony infrastructure. These devices can range from fully functional IP phones and integrated soft phones on a PC to simple analogue handsets, fax machines, or conference stations. The selection of either the call processing agent or a particular type of station device also influences the design of the infrastructure. A high-quantity soft phone, for example, requires a Cisco CallManager or Cisco ICS 7750 to provide service. The number of station devices also plays a critical role in the design of the telephony infrastructure. Each type of device consumes a particular amount of Cisco CallManager resources according to its relative device weight. For example, an analog gateway port consumes more call processing resources than an IP phone. Therefore, the number and types of station devices you deploy will affect the size of the Cisco CallManager cluster required to support those devices. For more information on call processing resources and relative device weights, refer to the chapter on Call Processing with Cisco CallManager.
Emergency Services (911 and E911)

Access to emergency services (911 and E911) is required by law in most areas. Because emergency services have requirements that can affect the overall design of your network, you should consider them early in the design phase. Gateways for 911 and E911 services must be highly available, and you can distribute them in many locations to meet this requirement. You can also install redundant gateways at each location to connect to the PSTN and provide routing of 911 calls.
1-12
EDCS-197018
C H A P T E R
IP Telephony Deployment Models

This chapter describes the following basic models used to deploy IP telephony solutions in the enterprise:
Single Site, page 2-2 The single-site model for IP telephony consists of a call processing agent located at a single site and a LAN or metropolitan area network (MAN) to carry voice traffic throughout the site. Calls beyond the LAN or MAN use the Public Switched Telephone Network (PSTN). If an IP WAN is incorporated into the single-site model, it is for data traffic only; no telephony services are provided over the WAN.
Multi-Site WAN with Centralized Call Processing, page 2-4 The multi-site WAN model with centralized call processing consists of a single call processing agent that provides services for many sites and uses the IP WAN to transport VoIP traffic between the sites. The IP WAN also carries call control signaling between the central site and the remote sites.
Multi-Site WAN with Distributed Call Processing, page 2-13 The multi-site WAN model with distributed call processing consists of multiple independent sites, each with its own call processing agent connected to an IP WAN that carries voice traffic between the distributed sites. The IP WAN in this model does not carry call control signaling between the sites because each site has its own call processing agent.
Clustering Over the IP WAN, page 2-21 This model deploys a single Cisco CallManager cluster across multiple sites that are connected by an IP WAN with QoS features enabled.
Your choice of which model to use depends on many factors, such as:

Number of users Number and types of devices (IP phones, gateways, analog ports, etc.) Geographical distribution of users and devices Features and services desired Ease of administration Scalability requirements Disaster recovery (redundancy) requirements
2-1
Chapter 2 Single Site
This chapter summarizes the key factors that apply to each of the basic deployment models. Even though the models are described separately here, you can use them in various combinations to create a complete IP telephony solution for your enterprise. Therefore, Cisco strongly recommends that you read this entire chapter to understand all the deployment models, so that you can more easily determine which features and factors are most important for the current and future needs of your enterprise.
Single Site
The single-site model for IP telephony consists of a call processing agent located at a single site, with no telephony services provided over an IP WAN. An enterprise would typically deploy the single-site model over a LAN or metropolitan area network (MAN), which carries the Voice over IP (VoIP) traffic within the site. In this model, calls beyond the LAN or MAN use the Public Switched Telephone Network (PSTN). The single-site model has the following design characteristics:

Single Cisco CallManager or Cisco CallManager cluster Maximum of 10,000 IP phones per cluster PSTN for all external calls Digital signal processor (DSP) resources for conferencing, transcoding, and Media Termination Point (MTP) Voice mail and unified messaging components A single G.711 codec for all IP phone calls (80 kbps of IP bandwidth per call, uncompressed) Capability to integrate with legacy private branch exchange (PBX) and voice mail systems
Figure 2-1 illustrates the model for an IP telephony network within a single campus or site.
2-2
EDCS-197018
Chapter 2
IP Telephony Deployment Models Single Site
Figure 2-1
Single-Site Model
Msg store
Msg store LDAP directory Cisco Unity
Cisco CallManager cluster
M M M
IP IP
IP WAN
IP IP Catalyst backbone
PSTN
Catalyst wiring closet
Solution Benefits
A single infrastructure for a converged network solution provides significant cost benefits and enables IP telephony to take advantage of the many IP-based applications in the enterprise. Single-site deployment also allows each site to be completely self-contained. There is no dependency for service in the event of an IP WAN failure or insufficient bandwidth, and there is no loss of call processing service or functionality. In summary, the main benefits of the single-site model are:

Ease of deployment A common infrastructure for a converged solution Simplified dial plan No transcoding resources required, due to the use of only G.711 codecs
74351
2-3
Chapter 2 Multi-Site WAN with Centralized Call Processing
Best Practices
A highly available, fault-tolerant infrastructure, based on a common infrastructure philosophy, is essential for easier migration to IP telephony, integration with applications such as video streaming and video conferencing, and expansion of your IP telephony deployment across the WAN or to multiple Cisco CallManager clusters. Follow these guidelines and best practices when implementing the single-site model:

Know the calling patterns for your enterprise. Use the single-site model if most of the calls from your enterprise are within the same site or to PSTN users outside of your enterprise. Use G.711 codecs for all endpoints. This practice eliminates the consumption of digital signal processor (DSP) resources for transcoding, and those resources can be allocated to other functions such as conferencing and Media Termination Points (MTPs). Use Media Gateway Control Protocol (MGCP) gateways for the PSTN if you do not require H.323 functionality. This practice simplifies the dial plan configuration. H.323 might be required to support specific functionality not offered with MGCP, such as support for Signaling System 7 (SS7) or Non-Facility Associated Signaling (NFAS). Refer to the chapter on Choosing a Cisco IP Telephony Gateway for more information. Implement the recommended network infrastructure for high availability, connectivity options for phones (in-line power), Quality of Service (QoS) mechanisms, and security. Follow the provisioning recommendations listed in the chapter on Call Processing with Cisco CallManager.
Dial Plan
The dial plan for the single-site model is usually the simplest of all the deployment models because of reliance on the PSTN for all off-net calls. However, there are some requirements on the dial plan for a single site, mainly to offer various classes of service, calling restrictions, 911 and E911 services, and security. The Cisco CallManager dial plan architecture can handle the following general types of calls:

All internal calls within the site External calls through a PSTN gateway
The complexity of your dial plan configuration depends on the number of classes of service required by your specific enterprise policy. A class of service is a set of calling restrictions applied to a certain group of devices. Some examples are:

Internal calls only Internal and local PSTN calls (no long-distance PSTN) Unrestricted calls (internal, local and long-distance PSTN)
Use partitions and calling search spaces to implement classes of service in Cisco CallManager.
Multi-Site WAN with Centralized Call Processing

The multi-site WAN model with centralized call processing consists of a single call processing agent that provides services for many sites and uses the IP WAN to transport IP telephony traffic between the sites. The IP WAN also carries call control signaling between the central site and the remote sites. Figure 2-2
2-4
EDCS-197018
Chapter 2
IP Telephony Deployment Models Multi-Site WAN with Centralized Call Processing
illustrates a typical centralized call processing deployment, with a Cisco CallManager cluster as the call processing agent at the central site and an IP WAN with QoS enabled to connect all the sites. The remote sites rely on the centralized Cisco CallManager cluster to handle their call processing. Applications such as voice mail and Interactive Voice Response (IVR) systems are typically centralized as well to reduce the overall costs of administration and maintenance.
Note
In each solution for the centralized call processing model presented in this section, the various sites connect to an IP WAN with QoS enabled.
Figure 2-2 Centralized Call Processing Deployment Model
Central site
Branch offices
V
ISDN backup
M
IP IP IP
Cluster
PSTN IP IP IP WAN IP
IP IP IP
74352
Connectivity options for the IP WAN include:

Leased lines Frame Relay Asynchronous Transfer Mode (ATM) ATM and Frame Relay Service Inter-Working (SIW)
Routers that reside at the WAN edges require quality of service (QoS) mechanisms, such as priority queuing and traffic shaping, to protect the voice traffic from the data traffic across the WAN, where bandwidth is typically scarce. In addition, a call admission control scheme is needed to avoid oversubscribing the WAN links with voice traffic and deteriorating the quality of established calls. For centralized call processing deployments, the locations construct within Cisco CallManager provides call admission control. (Refer to the Call Admission Control chapter for more information on locations.)
2-5
A variety of Cisco gateways can provide the remote sites with PSTN access. When the IP WAN is down, or if all the available bandwidth on the IP WAN has been used, users at the remote sites can dial the PSTN access code and place their calls through the PSTN. The Survivable Remote Site Telephony (SRST) feature, available for Cisco IOS gateways, provides call processing at the branch offices in the event of a WAN failure.
Note
It is possible to use other WAN technologies that lack some of the QoS features required for converged voice and data traffic, but these technologies have special design considerations that are beyond the scope of this document. In addition, those other technologies usually do not maintain good voice quality due to their lack of QoS features.
Solution Benefits
The primary advantage of this model is centralized call processing and applications. Centralized services reduce the equipment required at the remote sites and eliminate the administration and maintenance costs of multiple PBXs or key systems used in traditional telephony systems. In summary, the multi-site WAN model with centralized call processing provides the following benefits:

Simplified management and administration No need for a specialized support staff at the remote sites Lower maintenance costs Seamless WAN connectivity of all remote sites (toll bypass savings) Unified dial plan Survivable Remote Site Telephony (SRST) that provides basic call processing at remote sites in the event of an IP WAN failure
Note
In deployments where IP WAN bandwidth is either scarce or expensive with respect to PSTN charges, you can configure a remote site to place all external calls through the PSTN. In this scenario, the WAN link carries only regular data and call control signaling between the centralized Cisco CallManager cluster and the remote IP phones and gateways. With the centralized call processing approach, there is no need for PBX equipment at the remote sites.
Best Practices
Follow these guidelines and best practices when implementing the multi-site WAN model with centralized call processing:
Minimize delay between Cisco CallManager and remote locations to reduce voice cut-through delays (also known as clipping). For further information, refer to the chapter on Choosing a Cisco IP Telephony Gateway. Use a hub-and-spoke topology for the sites. The locations mechanism for call admission control relies on this topology and records only the bandwidth into and out of each location. Limit the remote sites to the number of phones supported by the SRST feature on the branch router. For example, a Cisco 7200 Series router with SRST can support 480 IP phones at a remote site, but smaller platforms have lower limits. Refer to the chapter on Call Processing with Cisco CallManager for more information on SRST.
2-6
EDCS-197018
Chapter 2
Because the locations mechanism works across multiple servers in Cisco CallManager Release 3.1 (and later), you can configure up to four active Cisco CallManagers in the central cluster for call processing. This configuration can support a maximum of 10,000 IP phones (or 20,000 device units) when Cisco CallManager runs on the largest supported server. Devices such as gateways, conferencing resources, voice mail, and other applications consume device units according to their relative device weights. Refer to the chapter on Call Processing with Cisco CallManager for more information on device weights.
Each Cisco CallManager cluster can support up to 500 locations configured with call admission control. If you need more remote sites, add Cisco CallManager clusters and connect them using intercluster trunks, as in the distributed call processing model. For more details, see Multi-Site WAN with Distributed Call Processing, page 2-13.
Remote Site Survivability

When deploying IP Telephony across a WAN with the centralized call processing model, you should take additional steps to ensure that data and voice services at the remote sites are highly available. Table 2-1 summarizes the different strategies for providing high availability at the remote sites. The choice of one of these strategies may depend on several factors, such as specific business or application requirements, the priorities associated with highly available data and voice services, and cost considerations.
Table 2-1 Strategies for High Availability at the Remote Sites
Strategy Redundant IP WAN links in branch router Redundant branch router platforms + Redundant IP WAN links Survivable Remote Site Telephony (SRST) only Data-only ISDN backup + SRST Data and voice ISDN backup
High Availability for Data Services? Yes Yes No Yes Yes
High Availability for Voice Services? Yes Yes Yes Yes Yes (see rules below)
The first two solutions listed in Table 2-1 provide high availability at the network infrastructure layer by adding redundancy to the IP WAN access points, thus maintaining IP connectivity between the remote IP phones and the centralized Cisco CallManager at all times. These solutions apply to both data and voice services, and are entirely transparent to the call processing layer. The options range from adding a redundant IP WAN link at the branch router to adding a second branch router platform with a redundant IP WAN link. The third solution listed in Table 2-1, Survivable Remote Site Telephony (SRST), provides high availability for voice services only, by providing a subset of the call processing capabilities within the remote office router and enhancing the IP phones with the ability to re-home to the call processing functions in the local router if a WAN failure is detected. Figure 2-3 illustrates a typical call scenario with SRST.
2-7
Figure 2-3
Survivable Remote Site Telephony (SRST) Application Scenario
Central site IP IP IP
CallManager cluster
M M M M
CallManager cluster
M M
ISDN backup IP WAN
PSTN
ISDN backup IP WAN
PSTN
Voice traffic
Voice traffic
Signaling IP Branch office IP
Normal operation
WAN failure
Under normal operations shown in the left part of Figure 2-3, the branch office connects to the central site via an IP WAN, which carries data traffic, voice traffic, and call signaling. The IP phones at the branch office exchange call signaling information with the Cisco CallManager cluster at the central site and place their calls across the IP WAN. The branch router or gateway forwards both types of traffic (call signaling and voice) transparently and has no knowledge of the IP phones.
2-8
74353
EDCS-197018
Chapter 2
If the WAN link to the branch office fails, or if some other event causes loss of connectivity to the Cisco CallManager cluster, the branch IP phones re-register with the branch router. The branch router queries the IP phones for their configuration and uses this information to build its own configuration automatically. The branch IP phones can then make and receive calls either internally or through the PSTN. The phone displays the message CM fallback mode, and some advanced Cisco CallManager features are unavailable and are grayed out on the phone display. When WAN connectivity to the central site is reestablished, the branch IP phones automatically re-register with the Cisco CallManager cluster and resume normal operation. The branch router deletes its information about the IP phones and reverts to its standard routing or gateway configuration. The last two solutions in Table 2-1 use an ISDN backup link to provide survivability during WAN failures. The two deployment options for ISDN backup are:
Data-only ISDN backup With this option, ISDN is used for data survivability only, while SRST is used for voice survivability. Note that you should configure an access control list on the branch router to prevent Skinny Client Control Protocol (SCCP) traffic from entering the ISDN interface, so that signaling from the IP phones does not reach the Cisco CallManager at the central site.
Data and voice ISDN backup With this option, ISDN is used for both data and voice survivability. In this case, SRST is not used because the IP phones maintain IP connectivity to the Cisco CallManager cluster at all times. However, Cisco recommends that you use ISDN to transport data and voice traffic only if all of the following conditions are true:
The bandwidth allocated to voice traffic on the ISDN link is the same as the bandwidth allocated
to voice traffic on the IP WAN link.

The ISDN link bandwidth is fixed. All the required QoS features have been deployed on the router's ISDN interfaces. Refer to the
chapter on Network Infrastructure Requirements for IP Telephony for more details on QoS.
Call Admission Control

IP telephony deployments require some form of call admission control if they use the IP WAN to transport voice traffic. Call admission control guarantees that the quality of service (QoS) provided to a new call does not negatively impact QoS for established calls on the WAN. Call admission control ensures that network resources are available on a call-by-call basis before establishing the new call. In a converged network, all traffic types (voice, video, and data) travel over a common IP infrastructure. Because of this mixture of traffic types, the network must be able to handle the requirements of each individual traffic type with respect to packet loss, latency, and jitter. In such an environment, it is important to perform two main tasks:

Prioritize one traffic type over another by using QoS mechanisms such as traffic classification, marking, and separate queuing. Use call admission control to prevent real-time traffic, such as voice and video, from oversubscribing the network bandwidth.
All IP phones have an open IP path to the WAN, whereas toll bypass networks can limit the number of physical trunks eligible to initiate calls across the WAN. This difference amplifies the need for call admission control in IP telephony networks, as illustrated in Figure 2-4.
2-9
Figure 2-4
Why Call Admission Control is Needed
WAN bandwidth can only support 2 calls. What happens when 3rd call attempted?
Call #1 IP
M M
IP
Call #2 IP VoIP data network Call #3 causes poor quality for all calls IP
IP
IP
For centralized call processing systems, you can implement call admission control with the locations mechanism in Cisco CallManager. A location configured in Cisco CallManager usually corresponds to a geographical location, such as a branch office or a postal zip code, serviced by a WAN link. (See Figure 2-5.) You configure each location and specify the maximum bandwidth available for calls to and from that location. You then configure device pools to assign the station devices to their respective locations.
Figure 2-5 Cisco CallManager Location Configuration
The centralized Cisco CallManager keeps track of the current bandwidth consumed at each location. If a new call across the IP WAN tries to exceed the bandwidth limit, the caller hears a busy signal (and sees a message such as Not Enough Bandwidth on devices with a display). If the call cannot go through the IP WAN, the caller can either wait until more bandwidth becomes available or dial the access code for the PSTN gateway.
Note
When configuring a location, set the bandwidth to a value less than or equal to the size of the voice queue on the WAN links.
2-10
EDCS-197018
74354
Chapter 2
Recommendations for Locations and Call Admission Control

When using the locations mechanism for call admission control, follow these recommendations:
You can install gateways at the central site only, at the remote sites only, or at both the central and remote sites. Use the locations mechanism to provide call admission control for the gateways at the remote sites but not at the central site. You do not need a Cisco IOS gatekeeper under these circumstances. Do not move devices between locations because Cisco CallManager keeps track of the bandwidth only for the configured location of the device and not for the physical location. Use a hub-and-spoke topology for a centralized call processing system with Cisco CallManager. If you have more than one circuit or virtual circuit in a spoke location, set the bandwidth according to the dedicated resources allocated on the smallest link.
Gateways
In a centralized call processing system, you can install the gateways exclusively at the central site or at the central site and at each of the remote sites. For gateways at the central site, use MGCP or H.323 gateways. MGCP gateways have the advantage of being centrally controlled and configured from Cisco CallManager. For gateways at the remote branches, use H.323 gateways because they are the only ones that can still operate after losing connectivity to the Cisco CallManager cluster. In addition, use the Survivable Remote Site Telephony (SRST) feature on the H.323 gateway to provide PSTN access under failure conditions. In this case, however, you have to configure the dial plan in two separate parts of the network, at the Cisco CallManager cluster and at the Cisco H.323 gateways.
Dial Plan
The centralized call processing model allows for a relatively simple dial plan that resides mainly within Cisco CallManager. The Cisco CallManager cluster located at the central site must be able to handle the following types of calls:
Intra-cluster calls These calls are between IP phones within the same cluster, but possibly at different locations. Intra-cluster calls do not require any special dial plan configuration.
PSTN calls These calls pass through a local PSTN gateway at each site. You can configure the same access number for each site to use in making PSTN calls. Use partitions and calling search spaces in Cisco CallManager to select the local gateway, as illustrated by the example in Table 2-2 and Table 2-3.
Because the local branch gateway selection also depends on these constructs, you need to configure partitions and calling search spaces for each location. The total number of calling search spaces you need to configure in Cisco CallManager is equal to: (Number of locations) x (Number of classes of service) For the example network depicted in Figure 2-6, assume that the desired operation is to permit all users to call each other within the cluster and also to permit a subset of the users to make PSTN calls.
2-11
Figure 2-6
IP WAN with Three Branches
Central site
Branch offices
V
ISDN backup
M
IP IP IP
Cluster
PSTN IP IP IP WAN IP
IP IP IP
74356
Table 2-2 lists the partitions required for the network in Figure 2-6 to provide users with access either to all intra-cluster locations or to all intra-cluster locations and a local PSTN gateway.
Table 2-2 Required Partitions for Intra-cluster and Local Gateway Access in Figure 2-6
Partition Name Cluster-X Users Cluster-X Hub PSTN Access Cluster-X Branch 1 PSTN Access Cluster-X Branch 2 PSTN Access Cluster-X Branch 3 PSTN Access
Designated Devices Assigned to Partition All IP phones within the cluster PSTN gateway(s) at hub location PSTN gateway at Branch 1 PSTN gateway at Branch 2 PSTN gateway at Branch 3
Table 2-3 lists the calling party search spaces for the network in Figure 2-6. These calling search spaces assign the users ability to dial either numbers within the cluster only or all numbers within the cluster and PSTN calls through the local gateway.
2-12
EDCS-197018
Chapter 2
IP Telephony Deployment Models Multi-Site WAN with Distributed Call Processing
Table 2-3
Calling Search Space and Partition Assignments for Figure 2-6
Calling Search Space Cluster-X Internal Only Cluster-X Hub Unrestricted
Partitions Cluster-X Users Cluster-X Users Cluster-X Hub PSTN Access
Assigned To Devices that can make only internal calls Internal calls and PSTN calls through hub location gateways Internal calls and PSTN calls through Branch 1 gateway Internal calls and PSTN calls through Branch 2 gateway Internal calls and PSTN calls through Branch 3 gateway
Cluster-X Branch 1 Unrestricted Cluster-X Users Cluster-X Branch 1 PSTN Access Cluster-X Branch 2 Unrestricted Cluster-X Users Cluster-X Branch 2 PSTN Access Cluster-X Branch 3 Unrestricted Cluster-X Users Cluster-X Branch 3 PSTN Access
The preceding example presents one of the simplest configurations for multi-site WAN local call processing. The dial plan consists of a single pattern for PSTN calls, typically just the digit 9. Gateway selection depends entirely upon the partition and calling search space of the calling device. When using H.323 gateways, it is important to note that part of the dial plan actually resides in the gateway itself. In general, the dial plan on the gateway is a simple configuration that includes two dial peers:

The Cisco CallManager for on-net calls The PSTN for off-net calls
Multi-Site WAN with Distributed Call Processing

The multi-site WAN model with distributed call processing consists of multiple independent sites, each with its own call processing agent connected to an IP WAN that carries voice traffic between the distributed sites. Unlike the centralized call processing model, however, the IP WAN in the distributed model does not carry call control signaling between the sites because each site has its own call processing agent. Figure 2-7 illustrates a typical distributed call processing deployment. Each site in the distributed call processing model can be one of the following:

A single site with its own call processing agent, which can be either Cisco CallManager, Cisco IOS Telephony Services (ITS), or other IP PBX A centralized call processing site and all of its associated remote sites A legacy PBX with VoIP gateway
An IP WAN interconnects all the distributed call processing sites. Typically, the PSTN serves as a backup connection between the sites in case the IP WAN connection fails or does not have any more available bandwidth. A site connected only through the PSTN is a standalone site and is not covered by the distributed call processing model. (See Single Site, page 2-2.)
2-13
Chapter 2 Multi-Site WAN with Distributed Call Processing
Connectivity options for the IP WAN include:

Leased lines Frame Relay Asynchronous Transfer Mode (ATM) ATM and Frame Relay Service Inter-Working (SIW)
A Distributed Call Processing Deployment
Figure 2-7
Directory
Voice/E-mail
Branch offices
Conf Directory Voice/E-mail Gatekeeper(s) MTP

M M M M M
V
Conf
M M M M M
IP IP IP
MTP
Directory PSTN IP IP IP
Voice/E-mail
V
IP WAN primary voice path Conf
IP IP IP
Headquarters MTP
2-14
EDCS-197018
74357
Chapter 2
Solution Benefits
The multi-site WAN model with distributed call processing provides the following benefits:

Cost savings when using the IP WAN for calls between sites. Use of the IP WAN to bypass toll charges by routing calls through remote site gateways, closer to the PSTN number dialed. This practice is known as tail-end-hop-off (TEHO). Maximum utilization of available bandwidth by allowing VoIP to share the IP WAN with other types of traffic. No loss of functionality during IP WAN failure because there is a call processing agent at each site. Scalability to hundreds of sites.
Best Practices
A multi-site WAN with distributed call processing has many of the same requirements as a single site and a multi-site WAN with centralized call processing. Follow the best practices from these other models in addition to the ones listed here for the distributed call processing model. (See Single Site, page 2-2, and Multi-Site WAN with Centralized Call Processing, page 2-4.) A gatekeeper is one of the key elements in the multi-site WAN model with distributed call processing. A gatekeeper is an H.323 device that provides call admission control and E.164 dial plan resolution. The following best practices apply to the use of a gatekeeper:

Use a logical hub-and-spoke topology for the gatekeeper. A gatekeeper can manage the bandwidth into and out of a site, or between zones within a site, but it is not aware of the topology. To provide high availability of the gatekeeper, use Hot Standby Router Protocol (HSRP) gatekeeper pairs, gatekeeper clustering, and alternate gatekeeper support. In addition, use multiple gatekeepers to provide redundancy within the network. Use a single WAN codec because the H.323 specification does not allow for Layer 2, IP, User Data Protocol (UDP), or Real-time Transport Protocol (RTP) header overhead in the bandwidth request. (Header overhead is allowed only in the payload or encoded voice part of the packet.) Use of one type of codec on the WAN simplifies capacity planning by eliminating the need to over-provision the IP WAN to allow for the worst-case scenario. Gatekeeper networks can scale to hundreds of sites, and the design is limited only by the hub-and-spoke topology.
Call Processing Agents

Your choice of call processing agent will vary, based on many factors. The main factors, for the purpose of design, are the size of the site and the functionality required. For a distributed call processing deployment, each site has its own call processing agent. The design of each site varies with the call processing agent, the functionality required, and the fault tolerance required. For example, in a site with 500 phones, a Cisco CallManager cluster containing two servers can provide one-to-one redundancy, with the backup server being used as a publisher and TFTP (Trivial File Transfer Protocol) server. The requirement for IP-based applications also greatly affects the choice of call processing agent because only Cisco CallManager provides the required support for many Cisco IP applications. Table 2-4 lists recommended call processing agents.
2-15
Table 2-4
Recommended Call Processing Agents
Call Processing Agent Cisco IOS Telephony Services (ITS) Cisco CallManager
Recommended Size Up to 48 phones 50 to 10,000 (or more) phones Depends on PBX
Comments

For remote sites Depends on Cisco IOS router platform Small to large campus, depending on the size of the Cisco CallManager cluster Supports centralized or distributed call processing Number of IP WAN calls and functionality depend on the PBX-to-VoIP gateway protocol and the gateway platform
Legacy PBX with VoIP Gateway

A distributed call processing system requires call admission control for the same reasons that a centralized call processing system requires it. (See Call Admission Control, page 2-9.) However, the mechanism for implementing call admission control differs greatly in these two types of systems. For distributed call processing systems, you can implement call admission control with an H.323 gatekeeper. In this design, the call processing agent registers with the Cisco IOS gatekeeper, also known as the Multimedia Conference Manager (MCM), and queries it each time the agent wants to place an IP WAN call. The Cisco IOS gatekeeper associates each call processing agent with a zone that has specific bandwidth limitations. Thus, the Cisco IOS gatekeeper can limit the maximum amount of bandwidth consumed by IP WAN voice calls into or out of a zone. Figure 2-8 illustrates call admission control with a gatekeeper. In brief, when the call processing agent wants to place an IP WAN call, it first requests permission from the gatekeeper. If the gatekeeper grants permission, the call processing agent places the call across the IP WAN. If the gatekeeper denies the request, the call processing agent can try a secondary path (the PSTN, for example) or can simply fail the call. This design essentially consists of a call accounting method for providing admission control, in which the gatekeeper keeps track of the bandwidth consumed by the IP WAN calls. When you set the maximum bandwidth for a zone, take into account the limitation that voice traffic should not consume more than 75% of the WAN link.
2-16
EDCS-197018
Chapter 2
Figure 2-8
Call Admission Control Using a Gatekeeper
Gatekeeper(s)
ARQ "May I make a call?"
ACF "Yes, there is enough bandwidth."
M M M M M
M M M M M
IP IP
PSTN IP IP IP IP WAN IP Zone 2
61111 61112 61113 (408) 526-XXXX Zone 1
H.323 RAS signaling
In summary, the major design implications for gatekeeper call admission control are as follows:

The gatekeeper provides support for hundreds of sites in a multi-site, distributed call processing environment. The gatekeeper tracks the used bandwidth into and out of a zone. The amount of bandwidth consumed by each call depends on the amount requested by the call processing agent and on the type of codec used for the call. Bandwidth calculations for the call Admission Request (ARQ) do not include Compressed Real-time Transport Protocol (cRTP) or any other transport overhead. The topology is a logical hub and spoke, based on the gatekeeper zone concept.
Dial Plan
A unified and scalable dial plan is critical to the overall ease of use of the IP telephony network. Within the distributed call processing model, there are various mechanisms for scaling the dial plan. For example, you can configure the dial plan completely within the call processing agent (as with a conventional PBX), within the gatekeeper network, or a hybrid of the two. The final choice depends on the required functionality and ease of administration.
74358
Call flow
2-17
This section briefly discusses the following types of dial plans for the distributed call processing model:

Site Dial Plan, page 2-18 Gatekeeper Dial Plan, page 2-20 Hybrid Dial Plan, page 2-20
Site Dial Plan

The site dial plan model requires the call processing agent at each site to have knowledge about all other sites and the possible paths to them. The administrative overhead grows exponentially as the number of sites increases. In this model, the gatekeeper provides only the call admission control and no dial plan resolution. This model closely resembles the standard model used today in traditional PBXs. For each destination, the call processing agent requires a list of possible routes. At a minimum, this list would include an IP WAN route and a PSTN route. For a deployment of 101 sites, the route list might involve 200 routes at each site. If you change just one site, 100 other site could require modifications to their dial plans. In summary, the site dial plan model has the following characteristics:

Completely self-contained knowledge of the dial plan. Automatic overflow and failover to the PSTN, using the gatekeeper only for call admission control to the IP WAN. Required configuration of multiple routes to a given site via the IP WAN when using redundant call processing agents. (This requirement depends on the type of call processing agent used.) This configuration requirement can become very extensive with increases in the number of call processing agents at a site. Minimum of two routes required for each destination, one for the IP WAN and one for the PSTN. Manual reconfiguration of every site if a new site is added or the dial plan changes.
Figure 2-9 shows an example of a simple site dial plan using Cisco CallManager as the call processing agent. In this example, users dial five digits for internal calls and seven digits for calls between sites across the IP WAN. If the IP WAN is down or has insufficient resources, calls between sites are routed transparently over the PSTN. For long-distance calls directed to the PSTN, users dial the access code 9 followed by 1 + area code and the 7-digit number. Users dialing local PSTN calls dial 9 plus the 7-digit number. The goal of this example dial plan is to dial the San Jose location using only seven digits, where calls take the IP WAN as the first choice and the PSTN as the second choice. Thus, users in Philadelphia can dial San Jose users at 408-526-XXXX by simply dialing 526XXXX. This example configuration begins at the route pattern. A route pattern is configured as 52.6XXXX, with the assigned route list SJ. The location of the dot (.) signifies that all digits to the left are the access code for this route pattern. Also, no digit manipulation is selected or required because each route group needs to invoke its own manipulation.
2-18
EDCS-197018
Chapter 2
Figure 2-9
Site Dial Plan Using Cisco CallManager as the Call Processing Agent to Route Calls
Secondary voice path Prepend "1408" and send to PSTN Gatekeeper(s)
Users required to dial 7 digits for internal calls "526-1111"
San Jose
M M M M M M M
M M M
IP IP
PSTN IP IP IP IP WAN IP Philadelphia
(408) 526-XXXX 5-digit internal dialing
Primary voice path Strip "1408" and Deliver 61111 to Remote CallManager Route pattern 52.6XXXX Route list "SJ" Philadelphia route pattern configuration
First choice: discard access code "52" H.323 device, Route group "SJ-IPWAN" gatekeeper controlled
Second choice: prepend "1408" Route group "PHL-PSTN"
V V
74359
IP WAN
PSTN
As shown in Figure 2-9, the route list contains two route groups, SJ-IPWAN and PHL-PSTN, listed in order of priority. The SJ-IPWAN route group is listed first (highest priority) and points to the San Jose Cisco CallManager. The digit manipulation specified in route pattern SJ-IPWAN discards the access code (52). This ensures that, when the call is sent across the IP WAN, five digits are delivered to the remote Cisco CallManager because this is the internal dial plan length. The inter-cluster trunk gateway associated with the remote Cisco CallManager must be configured to be gatekeeper controlled to provide
2-19
call admission control for calls across the IP WAN. If the gatekeeper rejects the call, the route list uses the next route group, PHL-PSTN. This route group is configured to prepend 1408 to the dialed number to ensure that the call transparently reaches the other end. Cisco IOS H.323-based call processing agents use the dial-peer priority to provide alternative routing when a destination is not available. Within each dial-peer, flexible number translation is possible to manipulate the final called number. All call processing agents have a very high degree of flexibility and power to provide a transparent, user-friendly system, but you should plan a simple and well-structured dial plan for the long term.
Gatekeeper Dial Plan

The gatekeeper dial plan model, even in the hybrid form, greatly reduces configuration and administration overhead. In this model, each site uses the gatekeeper to resolve the E.164 address and return the IP address of the call processing agent at another site. E.164 address resolution occurs during the call admission request, normally used only for bandwidth requests to the gatekeeper. If the admission request is successful, the call is placed to the other site. The gatekeeper can also be used in a well-designed network to provide automatic access to both local and remote gateways for sites that have no more capacity over the IP WAN or for standalone sites that can be accessed only via the PSTN. Cisco CallManager provides the anonymous device mechanism, which uses the gatekeeper to perform address resolution for inter-cluster trunk calls, thus simplifying the dial plans at the individual sites. Cisco IOS H.323 gateways and call processing agents provide session ras: as the equivalent mechanism in ITS and legacy PBX gateway sites. A Cisco CallManager cluster registers only once with the gatekeeper, and up to 100 Cisco CallManager clusters can register with a single gatekeeper. (Additional gatekeepers allow you to scale the system to hundreds of Cisco CallManager clusters.) Each site registers in its own zone within the gatekeeper. This allows the gatekeeper to maintain strict bandwidth control into and out off a site. In summary, the gatekeeper dial plan model has the following characteristics:

Manual overflow or failover to the PSTN, using the gatekeeper for call admission control and the inter-site dial plan. For H.323-based call processing agents, automatic PSTN failover and overflow, with load balancing and resource-based least cost routing. Configuration of only one anonymous device in each Cisco CallManager cluster to access all remote sites. Configuration of only two route patterns, one for intercluster calls to all sites and one for PSTN access, in a Cisco CallManager deployment. For Cisco IOS-based call processing agents, configuration of only a minimum number of dial-peers to provide access to the entire distributed deployment. Dial plan configured in the gatekeeper (not in every call processing agent) to route inter-site calls. Dial plan changes normally configured in the gatekeeper only, and not at each site.
Hybrid Dial Plan

The hybrid dial plan model uses a combination of call routing by both the call processing agent and the gatekeeper. The biggest advantage of using the call processing agent to route calls is that you can customize the dial plan at each site on the basis of call destination. The disadvantage is the administrative overhead of maintaining such a complex dial plan at each site. As the number of sites increases, administrative overhead increases exponentially. The gatekeeper model, on the other hand, greatly
2-20
EDCS-197018
Chapter 2
IP Telephony Deployment Models Clustering Over the IP WAN
simplifies the inter-site configuration to a single point of administration for all sites. The hybrid model tries to combine the advantages of both the site and gatekeeper dial plans while eliminating most of the disadvantages. In summary, the hybrid dial plan model has the following characteristics:

Automatic overflow and failover to the PSTN, using the gatekeeper for call admission control and the inter-site dial plan. Configuration of only one anonymous device in each Cisco CallManager cluster to access all remote sites. Configuration of only one dial peer in the Cisco IOS-based call agents when using a unified dial plan. Dial plan customization for sites that require it, and simple administration for other sites. Some duplication of the dial plan in both the gatekeeper and the call processing agent.
Dial plans can become cumbersome very quickly as they evolve. A well-designed, structured, and (above all) simple dial plan provides for a foolproof, scalable solution, no matter how many sites you have.
Clustering Over the IP WAN

You may deploy a single Cisco CallManager cluster across multiple sites that are connected by an IP WAN with QoS features enabled. This section provides a brief overview of clustering over the WAN. For further information, refer to the chapter on Call Processing with Cisco CallManager. Clustering over the WAN can support two types of deployments:
Local Failover Deployment Model, page 2-22 Local failover requires that you place the Cisco CallManager subscriber and backup servers at the same site, with no WAN between them. This deployment model is ideal for two or three sites with Cisco CallManager servers and a maximum of 5000 or 2500 IP phones per site, respectively. This model allows for up to 10,000 IP phones in the two-site configuration and 7,500 IP phones in the three-site configuration.
Remote Failover Deployment Model, page 2-25 Remote failover allows you to deploy the backup servers over the WAN. Using this deployment model, you may have up to six sites with Cisco CallManager subscribers and one or two sites containing the Cisco CallManager backup server. This deployment allows for up to 10,000 IP phones shared over the required number of sites.

These features make this solution ideal as a disaster recovery plan for business continuance sites or as a single solution for small or medium sites.
2-21
Chapter 2 Clustering Over the IP WAN
Local Failover Deployment Model

The local failover deployment model provides the most resilience for clustering over the WAN. Each of the sites in this model contains at least one primary Cisco CallManager subscriber and one backup subscriber. This configuration allows for either a two-site deployment with 5000 IP phones per site or a three-site deployment with 2500 IP phones per site. (See Figure 2-10.)
Figure 2-10 Local Failover Model with Two Sites
Site A
Publisher/TFTP server
M
Site B
Sub A
M M
Sub B
M
Sub A
M M
Sub B
M
Backup Voice Mail Server
WAN
Gateway
MOH
Gateway
MOH
V
Conf JTAPI IP-AA/IVR
V
Xcode
IP Phone IP
Xcode
IP Phone IP
In summary, observe the following guidelines when implementing the local failover model:

Configure each site to contain at least one primary Cisco CallManager subscriber and one backup subscriber. Configure Cisco CallManager groups and device pools to allow devices within the site to register with only the servers at that site under all conditions. Cisco highly recommends that you replicate key services (TFTP, DNS, DHCP, LDAP, and IP Phone Services), all media resources (conference bridges and MOH), and gateways at each site to provide the highest level of resiliency. You could also extend this practice to include a voice mail system at each site. Under a WAN failure condition, only sites without access to the publisher database might loose a small amount of functionality.
2-22
74360
TAPI SoftPhone
TAPI SoftPhone
EDCS-197018
Chapter 2
Every 10,000 busy hour call attempts (BHCA) in the cluster requires 900 kbps of bandwidth for Intra-Cluster Communication Signaling (ICCS). This is a minimum bandwidth requirement, and bandwidth is allocated in multiples of 900 kbps. In addition to the real-time ICCS bandwidth, intracluster bandwidth is required for the SQL, CTI Manager, and LDAP traffic. The amount of additional bandwidth is dependant on the use of the system. For instance, the use of Extension Mobility increases the amount of SQL traffic between servers. A maximum Round Trip Time (RTT) of 40 ms is allowed between any two servers in the Cisco CallManager cluster. This time equates to a 20 ms maximum one-way delay, or a transmission distance of approximately 1860 miles (3000 km) under ideal conditions. The local failover model requires Cisco CallManager Release 3.1 or later.
Cisco CallManager Provisioning

Provisioning of the Cisco CallManager cluster for the local failover model should follow the design guidelines for device weights outlined previously in this chapter. If calls are allowed across the WAN between the sites, then you must configure Cisco CallManager locations in addition to the default location for the other sites, to provide call admission control between the sites. If the bandwidth is over-provisioned for the number of devices, it is still best to configure call admission control based on locations. Because call admission control based on locations does not provide automatic failover to the PSTN, Cisco recommends that you over-provision the WAN for inter-site calls. As the delay increases between the Cisco CallManager servers, the bandwidth information shared between the servers for call admission control will also be delayed, possibly allowing additional calls to be set up until the ICCS bandwidth message arrives. This situation is a small risk because, even at full capacity, only a few additional calls might be set up before the bandwidth information arrives. To provide for this situation, Cisco recommends that you over-provision the priority queue for voice traffic by a few extra calls. For more information on call admission control, see the Call Admission Control chapter. To improve redundancy, Cisco recommends that you enable the Cisco Trivial File Transfer Protocol (TFTP) service on at least one of the Cisco CallManager servers at each location. You can run the TFTP service on either a publisher or a subscriber server, depending on the site. The TFTP server option must be correctly set on the DHCP servers for each site. If DHCP is not in use or the TFTP server is manually configured, you should configure the correct address for the site. Other services, which may affect normal operation of Cisco CallManager during WAN outages, should also be replicated at all sites to ensure uninterrupted service. These services include DHCP servers, DNS servers, corporate directories, and IP phone services. On each DHCP server, set the DNS server address correctly for each location. IP phones may have shared line appearances between the sites. The ICCS bandwidth provisioned between the sites allows for the additional ICCS traffic that shared line appearances generate. During a WAN outage, call control for each line appearance is segmented, but call control returns to a single Cisco CallManager server once the WAN is restored. During the WAN restoration period, there is extra traffic between the two sites. If this situation occurs during a period of high call volume, the shared lines might not operate as expected during that period. This situation should not last more than a few minutes, but if it is a concern, you can provision an extra 2 Mbps of bandwidth to minimize the effects.
2-23
Gateways
Normally, gateways should be provided at all sites for access to the PSTN. The device pools should be configured to register the gateways with the Cisco CallManager servers at the same site. Partitions and calling search spaces should also be configured to select the local gateways at the site as the first choice for PSTN access and the other site gateways as a second choice for overflow. Take special care to ensure emergency service access at each site. You can centralize access to the PSTN gateways if access is not required during a WAN failure and if sufficient additional bandwidth is configured for the number of calls across the WAN. For E911 requirements, additional gateways may be needed at each site.
Voice Mail
Cisco Unity can be deployed at all sites and integrated into the Cisco CallManager cluster. This configuration provides voice mail access even during a WAN failure and without using the PSTN. With Cisco CallManager Release 3.1, only one system-wide Voice Mail Number can be configured. Because Cisco Unity requires a unique pilot number, you have to configure a translation pattern at each location to translate the virtual Messages number at each site to the correct pilot number. You should place this translation pattern in a partition that is in the calling search space for the devices at that location. If Extension Mobility is not being used, then users from one site who are visiting another site will have to dial the voice mail pilot number directly.
Music on Hold
Music on hold (MOH) servers should be provisioned at each site, with sufficient capacity for the expected load. Through the use of media resource groups (MRGs) and media resource group lists (MRGLs), MOH is provided by the on-site resource and is available during a WAN failure.
2-24
EDCS-197018
Chapter 2
Remote Failover Deployment Model

The remote failover deployment model provides flexibility for the placement of backup servers. Each of the sites contains at least one primary Cisco CallManager subscriber and may or may not have a backup subscriber. This allows for a deployment of three to six sites with IP phones and other devices normally registered with a maximum of four servers. (See Figure 2-11.)
Figure 2-11 Remote Failover Model with Four Sites
M
Publisher / TFTP
M M
IP IP WAN IP
IP
IP IP IP
IP
74361

Configure each site to contain at least one primary Cisco CallManager subscriber and an optional backup subscriber if desired. You may configure Cisco CallManager groups and device pools to allow devices to register with servers over the WAN. Cisco highly recommends that you replicate key services (TFTP, DNS, DHCP, LDAP, and IP Phone Services), all media resources (conference bridges and MOH), and gateways at each site with IP phones to provide the highest level of resiliency. You could also extend this practice to include a voice mail system at each site. Under a WAN failure condition, only sites without access to the publisher database might loose a small amount of functionality. Every 10,000 busy hour call attempts (BHCA) in the cluster requires 900 kbps of bandwidth for Intra-Cluster Communication Signaling (ICCS). This is a minimum bandwidth requirement, and bandwidth is allocated in multiples of 900 kbps. In addition to the real-time ICCS bandwidth, intracluster bandwidth is required for the SQL, CTI Manager, and LDAP traffic. The amount of additional bandwidth is dependant on the use of the system. For instance, the use of Extension Mobility increases the amount of SQL traffic between servers.
2-25
Signalling or Control Plane traffic requires additional bandwidth when devices are registered across the WAN with a remote Cisco CallManager server within the same cluster. A maximum Round Trip Time (RTT) of 40 ms is allowed between any two servers in the Cisco CallManager cluster. This time equates to a 20 ms maximum one-way delay, or a transmission distance of approximately 1860 miles (3000 km) under ideal conditions. The remote failover model requires Cisco CallManager Release 3.1 or later.

If calls are allowed across the WAN between the sites, then you must configure Cisco CallManager locations in addition to the default location for the other sites, to provide call admission control between the sites. If the bandwidth is over-provisioned for the number of devices, it is still best to configure call admission control based on locations. Because call admission control based on locations does not provide automatic failover to the PSTN, Cisco recommends that you over-provision the WAN for inter-site calls. As the delay increases between the Cisco CallManager servers, the bandwidth information shared between the servers for call admission control will also be delayed, possibly allowing additional calls to be set up until the ICCS bandwidth message arrives. This situation is a small risk because, even at full capacity, only a few additional calls might be set up before the bandwidth information arrives. To provide for this situation, Cisco recommends that you over-provision the priority queue for voice traffic by a few extra calls. For more information on call admission control, see the Call Admission Control chapter. To improve redundancy, Cisco recommends that you enable the Cisco Trivial File Transfer Protocol (TFTP) service on at least one of the Cisco CallManager servers at each location. You can run the TFTP service on either a publisher or a subscriber server, depending on the site. The TFTP server option must be correctly set on the DHCP servers for each site. If DHCP is not in use or the TFTP server is manually configured, you should configure the correct address for the site. Other services, which may affect normal operation of Cisco CallManager during WAN outages, should also be replicated at all sites to ensure uninterrupted service. These services include DHCP servers, DNS servers, corporate directories, and IP phone services. On each DHCP server, set the DNS server address correctly for each location. IP phones may have shared line appearances between the sites. The ICCS bandwidth provisioned between the sites allows for the additional ICCS traffic that shared line appearances generate. During a WAN outage, call control for each line appearance is segmented, but call control returns to a single Cisco CallManager server once the WAN is restored. During the WAN restoration period, there is extra traffic between the two sites. If this situation occurs during a period of high call volume, the shared lines might not operate as expected during that period. This situation should not last more than a few minutes, but if it is a concern, you can provision an extra 2 Mbps of bandwidth to minimize the effects.
Gateways
Normally, gateways should be provided at all user sites for access to the PSTN. The device pools may be configured to allow the gateways to register with a remote Cisco CallManager server as backup if the local Cisco CallManager server is unavailable. Partitions and calling search spaces should also be configured to select the local gateways at the site as the first choice for PSTN access and the other site gateways as a second choice for overflow. Take special care to ensure emergency service access at each site. You can centralize access to the PSTN gateways if access is not required during a WAN failure and if sufficient additional bandwidth is configured for the number of calls across the WAN. For E911 requirements, additional gateways may be needed at each site.
2-26
EDCS-197018
Chapter 2
Voice Mail
Music on Hold
2-27
2-28
EDCS-197018
C H A P T E R
Network Infrastructure Requirements for IP Telephony

This chapter describes the infrastructure components and features needed to build an IP telephony solution in an enterprise campus environment using the Cisco Architecture for Voice, Video, and Integrated Data (AVVID). IP telephony places strict requirements on IP packet loss, packet delay, and delay variation (or jitter). Therefore, you need to enable most of the Quality of Service (QoS) mechanisms available on Cisco switches and routers throughout the network. For the same reasons, quick convergence after network failures or changes is also important. Figure 3-1 identifies the roles of devices that form the network infrastructure, and Table 3-1 summarizes the features required for each of these roles. (Refer to the appendix on network roles and product recommendations, available in a future release of this document, for more details on which Cisco platforms support the required features for each network role.) The following sections describe the network infrastructure features as they relate to:

LAN Infrastructure, page 3-3 WAN Infrastructure, page 3-5
3-1
Chapter 3
Figure 3-1
Typical Campus Network Infrastructure
Central Site IP IP IP Campus access layer IP IP IP IP IP IP IP IP IP
Campus distribution layer
Campus core layer WAN aggregation
ISDN backup
IP WAN
PSTN
Branch router Branch switch IP
Branch offices
3-2
EDCS-197018
77290
IP
IP
IP
IP
IP
IP
IP
IP
Chapter 3
Network Infrastructure Requirements for IP Telephony LAN Infrastructure
Table 3-1
Required Features for Each Role in the Network Infrastructure
Infrastructure Role Campus Access Switch
Required Features

In-Line Power Multiple Queue Support 802.1p and 802.1q Fast Link Convergence Multiple Queue Support 802.1p and 802.1q Traffic Classification Traffic Reclassification Multiple Queue Support Traffic Shaping Link Fragmentation and Interleaving (LFI) Link Efficiency Traffic Classification Traffic Reclassification 802.1p and 802.1q Multiple Queue Support LFI Link Efficiency Traffic Classification Traffic Reclassification 802.1p and 802.1q In-Line Power Multiple Queue Support 802.1p and 802.1q
Campus Distribution or Core Switch
WAN Aggregation Router (Site that is at the hub of the network)
Branch Router (Spoke site)
Branch or Smaller Site Switch
LAN Infrastructure
Until recently, quality of service was not an issue in the enterprise campus due to the bursty nature of data traffic and the ability of network devices to withstand buffer overflow and packet loss. However, with new applications such as voice and video, which are sensitive to packet loss and delay, buffers and not bandwidth are the key quality-of-service issue in the enterprise campus. Buffers can fill instantaneously, causing packets to drop when they attempt to enter the interface buffer. For applications such as voice, this packet loss results in severe voice quality degradation. Therefore, QoS tools are required to manage these buffers and to minimize packet loss, delay, and delay variation.
3-3
Chapter 3 LAN Infrastructure
Campus QoS involves three areas of configuration, which are discussed in the following sections:

Traffic Classification, page 3-4 Interface Queuing, page 3-4 Bandwidth Provisioning, page 3-4
Traffic Classification
It has always been an integral part of the Cisco network design architecture to classify or mark traffic as close to the edge of the network as possible. Traffic classification is an entrance criterion for access into the various queuing schemes used within the campus switches and WAN interfaces. When you connect an IP phone using a single cable, the phone becomes the edge of the managed network. As such, the IP phone can and should classify traffic flows. Table 3-2 lists the traffic classification guidelines for Cisco Architecture for Voice, Video, and Integrated Data (AVVID).
Table 3-2 Traffic Classification Guidelines for Various Types of AVVID Network Traffic
Traffic Type Voice control signaling Video Data
Layer 2 Class of Service (CoS) 3 4 0, 1, 2
Layer 3 IP Precedence 5 3 4 0, 1, 2
Layer 3 Differentiated Services Code Point (DSCP) EF AF31 AF41 0 to AF23
Voice Real-Time Transport Protocol (RTP) 5
Interface Queuing
To guarantee voice quality, you must design for QoS and enable it within the campus infrastructure. By enabling QoS on campus switches, you can configure all voice traffic to use separate queues, thus virtually eliminating the possibility of dropped voice packets when an interface buffer fills instantaneously. Although network management tools may show that the campus network is not congested, QoS tools are still required to guarantee voice quality. Network management tools show only the average congestion over a sample time span. While useful, this average does not show the congestion peaks on a campus interface. Transmit interface buffers within a campus tend to congest in small, finite intervals as a result of the bursty nature of network traffic. When this congestion occurs, any packets destined for that transmit interface are dropped. The only way to prevent dropped voice traffic is to configure multiple queues on campus switches. Most Cisco Ethernet switches support the enhanced queuing services that can guarantee voice quality in the campus.
Bandwidth Provisioning
In the campus LAN, bandwidth provisioning recommendations can be summarized by the motto, Over provision and under subscribe. This motto implies careful planning of the LAN infrastructure so that the available bandwidth is always considerably higher than the load and there is no steady-state congestion over the LAN links.
3-4
EDCS-197018
Chapter 3
Network Infrastructure Requirements for IP Telephony WAN Infrastructure
WAN Infrastructure
WAN QoS techniques depend on the speeds of the links. At speeds above 768 kbps, voice priority queuing is required to reduce jitter and possible packet loss if a burst of traffic oversubscribes a buffer. This queuing requirement is similar to the one for the LAN infrastructure. In addition, the WAN requires traffic shaping for two reasons:

To remain within the contracted traffic agreement with the ATM or Frame Relay network to avoid being policed and incurring dropped packets. To maintain comparable traffic speeds between sites linked to the Frame Relay or ATM network by different line speeds. For example, the headquarters site might use DS-3 and the other sites use DS-1, which can result in buffer overruns within the network and, thus, in packet loss. Traffic shaping helps prevent buffer overruns and packet loss.
At lower link speeds (less than 768 kbps), you can use other link efficiency techniques to minimize the effects of serialization delays. (See Link Efficiency Techniques, page 3-13.) Before placing voice and video traffic on a network, ensure that there is adequate bandwidth for all required applications. Once you have provided sufficient bandwidth, design the WAN to reduce delay, packet loss, and jitter for the voice traffic. To achieve these goals, use the QoS features and tools listed in Table 3-3.
Table 3-3 QoS Features and Tools Required to Support IP Telephony for each WAN Technology and Link Speed
WAN Technology Leased Lines
Link Speed 56 kbps to 768 kbps

Link Speed Greater than 768 kbps
Multilink Point-to-Point Protocol (MLP) Link Fragmentation and Interleaving (LFI) Low Latency Queuing (LLQ) Compressed Real-Time Transport Protocol (cRTP) Traffic Shaping LFI LLQ cRTP TX-ring buffer changes MLP over ATM LFI LLQ TX-ring buffer changes MLP over ATM and FR LFI LLQ
LLQ
Frame Relay (FR)
Traffic Shaping LLQ
Asynchronous Transfer Mode (ATM)
TX-ring buffer changes LLQ
Frame Relay and ATM Service Inter-Working (SIW)
TX-ring buffer changes LLQ
3-5
Chapter 3 WAN Infrastructure
The following sections highlight some of the most important features and techniques to keep in mind when designing a WAN to support both voice and data traffic:

Bandwidth Provisioning, page 3-6 Traffic Prioritization, page 3-12 Link Efficiency Techniques, page 3-13 Traffic Shaping, page 3-15
Bandwidth Provisioning
Properly provisioning the network bandwidth is a major component of designing a successful Cisco AVVID network. You can calculate the required bandwidth by adding the bandwidth requirements for each major application (for example, voice, video, and data). This sum then represents the minimum bandwidth requirement for any given link, and it should not exceed approximately 75% of the total available bandwidth for the link. This 75% rule assumes that some bandwidth is required for overhead traffic, such as routing and Layer 2 keepalives, as well as for additional applications such as email, HTTP traffic, monitoring or management traffic, and other data traffic that is not so easily measured. Figure 3-2 illustrates this bandwidth provisioning process.
Figure 3-2 Link Bandwidth Provisioning
Voice
Video
Voice/Video Control
Data
Routing etc.
0.75 x link capacity
Reserved
From a traffic standpoint, an IP telephony call consists of two parts:

The voice carrier stream, which consists of Real-Time Transport Protocol (RTP) packets that contain the actual voice samples. The call control signaling, which consists of packets belonging to one of several protocols, according to the endpoints involved in the call (for example, H.323, MGCP, SCCP, or (J)TAPI). Call control functions are, for instance, those used to set up, maintain, tear down, or redirect a call.
Bandwidth provisioning should include not only the voice stream traffic but also the call control traffic. In fact, in multi-site WAN deployments, the call control traffic (as well as the voice stream) must traverse the WAN, and failure to allocate sufficient bandwidth for it can adversely affect the user experience.
3-6
77291
Link capacity
EDCS-197018
Chapter 3
The next three sub-sections describe the bandwidth provisioning recommendations for the following types of traffic:

Voice bearer traffic in all multi-site WAN deployments (see Provisioning for Voice Bearer Traffic, page 3-7) Call control traffic in multi-site WAN deployments with centralized call processing (see Provisioning for Call Control Traffic with Centralized Call Processing, page 3-8) Call control traffic in multi-site WAN deployments with distributed call processing (see Provisioning for Call Control Traffic with Distributed Call Processing, page 3-10)
Provisioning for Voice Bearer Traffic

As illustrated in Figure 3-3, a VoIP packet consists of the payload, IP header, User Datagram Protocol (UDP) header, Real-Time Transport Protocol (RTP) header, and Layer 2 Link header. At the default packetization rate of 20 ms, VoIP packets have a 160-byte payload for G.711 or a 20-byte payload for G.729. The IP header is 20 bytes, the UDP header is 8 bytes, and the RTP header is 12 bytes. The link header varies in size according to the Layer 2 media used.
Figure 3-3 Typical VoIP Packet
VoIP Packet
77292
Voice payload X bytes
RTP Header 12 bytes
UDP Header 8 bytes
IP Header 20 bytes
Link Header X bytes
The bandwidth consumed by VoIP streams is calculated by adding the packet payload and all headers (in bits), then multiplying by the packet rate per second (default of 50 packets per second). Table 3-4 details the bandwidth per VoIP flow at a default packet rate of 50 packets per second (pps). Table 3-4 does not include Layer 2 header overhead and does not take into account any possible compression schemes, such as compressed Real-Time Transport Protocol (cRTP). You can use the Service Parameters menu in Cisco CallManager Administration to adjust the packet rate.
Note
While it is possible to configure the sampling rate above 30 ms, doing so usually results in very poor voice quality.
Table 3-4 Bandwidth Consumption for Voice Payload Only
CODEC G.711 G.711 G.729A G.729A
Sampling Rate 20 ms 30 ms 20 ms 30 ms
Voice Payload in Bytes 160 240 20 30
Packets per Second 50 33 50 33
Bandwidth per Conversation 80 kbps 74 kbps 24 kbps 18 kbps
A more accurate method for provisioning is to include the Layer 2 headers in the bandwidth calculations, as shown in Table 3-5.
3-7
Table 3-5
Bandwidth Consumption with Headers Included
CODEC G.711 at 50 pps G.711 at 33 pps
Ethernet 14 Bytes of Header 85.6 kbps 56.5 kbps
PPP 6 Bytes of Header 82.4 kbps 54.4 kbps 26.4 kbps 17.4 kbps
ATM 53-Byte Cells with a Frame-Relay 48-Byte Payload 4 Bytes of Header 106 kbps 70 kbps 42.4 kbps 28 kbps 81.6 kbps 75 kbps 25.6 kbps 19.5 kbps
G.729A at 50 pps 29.6 kbps G.729A at 33 pps 19.5 kbps
Provisioning for Call Control Traffic with Centralized Call Processing

In a centralized call processing deployment, the Cisco CallManager cluster and the applications (such as voice mail) are located at the central site, while several remote sites are connected through an IP WAN. The remote sites rely on the centralized Cisco CallManagers to handle their call processing. The following considerations apply to this deployment model:

Each time a remote branch phone places a call, the control traffic traverses the IP WAN (even if the call is local to the branch) to reach the Cisco CallManager at the central site. The signaling protocols that may traverse the IP WAN in this deployment model are SCCP, H.323, MGCP, and TAPI. All the control traffic is exchanged between a Cisco CallManager at the central site and endpoints or gateways at the remote branches.
As a consequence, the area where you must provision bandwidth for control traffic lies between the branch routers and the WAN aggregation router at the central site (see Figure 3-4).
Figure 3-4 Area Where Bandwidth is a Concern for Centralized Call Processing Deployments
Voice mail server
Cisco CallManager Cluster

M
Router/GW IP IP WAN
Router/GW IP
IP Central Site Area where bandwidth must be provisioned Remote Branch

77293
It is important to note that the control traffic that traverses the WAN in this scenario can be split into two categories:

Quiescent traffic, which consists of keep-alive messages periodically exchanged between the branch IP phones and Cisco CallManager, regardless of phone activity. Call-related traffic, which consists of signaling messages exchanged between the branch IP phones and/or gateways and the Cisco CallManager at the central site when a call needs to be set up, torn down, forwarded, and so on.
3-8
EDCS-197018
Chapter 3
To obtain an estimate of the generated call control traffic, it is therefore necessary to make some assumptions regarding the average number of calls per hour made by each branch IP phone. In the interest of simplicity, the calculations in this section assume an average of 10 calls per hour per phone.
Note
If this average number does not satisfy the needs of a specific deployment, it is possible to calculate the recommended bandwidth by using the advanced formulas provided in Advanced Formulas, page 3-10. Given the assumptions made, and initially considering the case of a remote branch where no TAPI applications (such as Cisco SoftPhone) are deployed, the recommended bandwidth needed for call control traffic can be obtained by the following formula: Equation 1: Recommended Bandwidth Needed for Control Traffic, with No TAPI Applications Bandwidth (bps) = 150 x (Number of IP phones and gateways in the branch) If a TAPI application (such as Cisco SoftPhone) is deployed at the remote branches, the recommended bandwidth is affected because the TAPI protocol requires more messages to be exchanged between Cisco CallManager and the endpoints. The following formula takes into account the impact of a TAPI application: Equation 2: Recommended Bandwidth Needed for Control Traffic, with TAPI Applications Bandwidth with TAPI (bps) = 225 x (Number of IP phones and gateways in the branch) If we now take into account the fact that the smallest bandwidth that can be assigned to a queue on a Cisco IOS router is 8 kbps, we can summarize the values of minimum and recommended bandwidth for different branch office sizes, as shown in Table 3-6.
Table 3-6 Recommended Bandwidth for Call Control Traffic With and Without TAPI Applications
Branch Office Size (Number of IP Phones and Gateways) 1 to 30 40 50 60 70 80 90 100 110 120 130 140 150
Recommended Bandwidth for Control Traffic (no TAPI) 8 kbps 8 kbps 8 kbps 9 kbps 11 kbps 12 kbps 14 kbps 15 kbps 17 kbps 18 kbps 20 kbps 21 kbps 23 kbps
Recommended Bandwidth for Control Traffic (TAPI) 8 kbps 9 kbps 11 kbps 14 kbps 16 kbps 18 kbps 21 kbps 23 kbps 25 kbps 27 kbps 30 kbps 32 kbps 34 kbps
Note
These values reflect Layer 3 bandwidth. When provisioning a WAN link, you must add Layer 2 overhead to these numbers according to the Layer 2 technology used.
3-9
Advanced Formulas
The formulas presented in this section assume an average call rate per phone of 10 calls per hour. However, this might not correspond to your deployment if the call patterns are significantly different (for example, call center agents at the branches). To calculate call control bandwidth requirements in these cases, use the following formulas, which contain an additional variable (CH) that represents the average calls per hour per phone: Equation 3: Recommended Bandwidth for a Branch with No TAPI Applications Bandwidth (bps) = (39 + 10.8 x CH) x (Number of IP phones and gateways in the branch) Equation 4: Recommended Bandwidth for a Remote Branch with TAPI Applications Bandwidth with TAPI (bps) = (39 + 18.3 x CH) x (Number of IP phones and gateways in the branch)
Provisioning for Call Control Traffic with Distributed Call Processing

In distributed call processing deployments, several sites are connected through an IP WAN. Each site contains a Cisco CallManager cluster and can follow either the single site model or the centralized call processing model. A gatekeeper may be used for call admission control between sites. The following considerations apply to this deployment model:

The signaling protocol used to place a call across the WAN is H.323. Control traffic is exchanged between Cisco CallManager clusters at each site and the Cisco IOS gatekeeper, as well as between the Cisco CallManager clusters.
Therefore, bandwidth for control traffic must be provisioned on the WAN links between Cisco CallManagers as well as between each Cisco CallManager and the gatekeeper. Because the topology is limited to hub-and-spoke, with the gatekeeper typically located at the hub, the WAN link that connects each site to the other sites usually coincides with the link that connects it to the gatekeeper, as shown in Figure 3-5.
3-10
EDCS-197018
Chapter 3
Figure 3-5
Areas Where Bandwidth is a Concern for Distributed Call Processing Deployments
Voice Mail server

M
IP IP Router/GW
V
Gatekeeper Areas where bandwidth must be provisioned
IP WAN Router/GW
Router/GW
V
IP IP
M M
V
IP IP
Cisco CallManager Cluster Voice Mail server

77294
Voice Mail server
It is important to note that the control traffic that traverses the WAN belongs to one of the following categories:

Quiescent traffic, which consists of registration messages periodically exchanged between each Cisco CallManager and the gatekeeper Call-related traffic, which in turn consists of two types of traffic:
Call admission control traffic exchanged between the Cisco CallManagers and the gatekeeper
before a call can be set up and after it has been torn down
H.225 or H.245 signaling traffic exchanged between two Cisco CallManagers when a call needs
to be set up, torn down, forwarded, and so on Because the total amount of control traffic depends on the number of calls that are set up and torn down at any given time, it is necessary to make some assumptions about the call patterns and the link utilization. The WAN links that connect each of the spoke sites to the hub site are normally provisioned to accommodate different types of traffic (for example, data, voice, and video). Using a traditional telephony analogy, we can view the portion of the WAN link that has been provisioned for voice as a number of virtual tie lines.
3-11
Assuming an average call duration of 2 minutes and 100 percent utilization of each virtual tie line, we can derive that each tie line carries a volume of 30 calls per hour. This assumption allows us to obtain the following formula that expresses the recommended bandwidth for call control traffic as a function of the number of virtual tie lines: Equation 5: Recommended Bandwidth Based on Number of Virtual Tie Lines Recommended Bandwidth (bps) = 116 x (Number of virtual tie lines) If we now take into account the fact that the smallest bandwidth that can be assigned to a queue on a Cisco IOS router is 8 kbps, we can deduce that a minimum size queue of 8 kbps can accommodate the call control traffic generated by up to 70 virtual tie lines. This amount should be sufficient for most large enterprise deployments.
Traffic Prioritization
In choosing from among the many available prioritization schemes, the major factors to consider include the type of traffic involved and the type of media on the WAN. For multiservice traffic over an IP WAN, Cisco recommends low-latency queuing (LLQ) for low-speed links. This allows up to 64 traffic classes with the ability to specify, for example, priority queuing behavior for voice and interactive video, a minimum bandwidth for Systems Network Architecture (SNA) data and market data feeds, and weighted fair queuing for other traffic types. Figure 3-6 shows the following prioritization scheme:
Voice is placed into a queue with priority queuing capabilities and is allocated the required amount of bandwidth. The entrance criterion for this queue is the differentiated services code point (DSCP) value of EF, or IP precedence value of 5. Traffic in excess of the configured bandwidth limit is dropped if the interface becomes congested. Therefore, an admission control mechanism must be used to ensure that this value is not exceeded. Video conferencing traffic is placed into a queue with priority queuing capabilities and is allocated the required amount of bandwidth. The entrance criterion for this queue is a DSCP value of AF41, or IP precedence value of 4. Traffic in excess of the configured bandwidth limit is dropped if the interface becomes congested. It is therefore imperative, as in the case of voice, to use an admission control mechanism to ensure that this value is not exceeded. Note that one-way video traffic, such as IP/TV, should use a class-based weighted fair queuing scheme because that type of traffic has a much higher delay tolerance. As the WAN links become congested, it is possible to starve the voice control signaling protocols, thereby eliminating the ability of the IP phones to complete calls across the IP WAN. Voice control protocols, such as H.323 and SCCP, require their own class-based weighted fair queue with a minimum configurable bandwidth equal to a DSCP value of AF31 (which corresponds to an IP precedence value of 3). IBM Systems Network Architecture (SNA) traffic and other mission-critical data traffic is placed into a queue that has the required amount of bandwidth. The queuing scheme within this class is first-in-first-out (FIFO) with a minimum allocated bandwidth. Traffic in this class that exceeds the configured bandwidth limit is placed in the default queue. The entrance criterion for this queue could be a Transmission Control Protocol (TCP) port number, a Layer 3 address, an IP precedence value, or a DSCP value. All remaining traffic can be placed in a default queue. If you specify the bandwidth, the queuing operation would be FIFO. Alternatively, if you specify the keyword fair, the operation would be weighted fair queuing (WFQ).
3-12
EDCS-197018
Chapter 3
Figure 3-6
Optimized Queuing for VoIP over the WAN
Layer 3 Queuing Subsystem Packets in 1 1 1 1 2 2 3 3 4 4 4 0 0 0 0 WFQ Low Latency Queuing PQ Voice PQ Voice Class = X Class = Y CBWFQ Default Police
Layer 2 Queuing Subsystem Link Fragmentation and Interleave Packets out TX 0 4 3 2 1 1 Ring Packets out
77295
Interleave Fragment
Link Efficiency Techniques

Because wide-area bandwidth is often prohibitively expensive, only low-speed circuits might be available or cost effective when interconnecting remote sites. In these cases, it is important to achieve maximum bandwidth savings by transmitting as many voice calls as possible over the low-speed link. Many compression schemes, such as G.729, can compress a 64-kbps call into an 8-kbps payload. Cisco gateways and IP phones support a range of codecs that can enhance efficiency on these low-speed links. You can increase link efficiency further by using Compressed Real-Time Transport Protocol (cRTP). This protocol compresses a 40-byte IP, User Datagram Protocol (UDP), and RTP header to approximately two to four bytes. Use cRTP on a particular link only if that link meets all of the following conditions:

Voice traffic represents more than 30% of the load on the specific link. The link uses a low bit-rate codec (such as G.729). No other real-time application (such as video conferencing) is using the same link.
If the link fails to meet any one of the preceding conditions, then cRTP is not effective and you should not use it on that link. Another important parameter to consider before using cRTP is router CPU utilization, which is adversely affected by compression and decompression operations. Voice activity detection (VAD) is another feature for improving link efficiency. VAD takes advantage of the fact that, in most conversations, only one party is talking at a time. VAD recovers this empty time and allows data to use the recovered bandwidth. For low-speed links (less than 768 kbps), it is necessary to use techniques that provide link fragmentation and interleaving (LFI). This technique limits jitter by preventing voice traffic from being delayed behind large data frames, as illustrated in Figure 3-7. The three techniques that exist for this purpose are Multilink Point-to-Point Protocol (MLP) for point-to-point serial links, FRF.12 for Frame Relay, and MLP over ATM for ATM connections.
3-13
Figure 3-7
Link Fragmentation and Interleaving (LFI) Operation
Before
Voice
Data 214-ms serialization delay for 1500-byte frame at 56 kbps
After
Data
Data
Voice
Data
3-14
77296
EDCS-197018
Chapter 3
Traffic Shaping
Traffic shaping is required for multiple access, non-broadcast media such as ATM and Frame Relay, where the physical access speed varies between two endpoints and several branch sites are typically aggregated to a single router interface at the central site. Figure 3-8 illustrates the main reasons why traffic shaping is needed when transporting voice and data on the same IP WAN.
Figure 3-8 Traffic Shaping with Frame Relay and ATM
Central Site
Traffic Shaping: Why? 1. 1 Line speed mismatch 2. Remote to central site over-
2 subscription
3. 3 To prevent bursting above Committed Rate (CIR

T1 Frame Relay or ATM
CIR = 64 kbps
64kbps
T1
T1
T1
2
Remote Sites
3
77297
Figure 3-8 shows three different scenarios:

1.
Line speed mismatch While the central site interface is typically a high-speed one (such as T1 or higher), smaller remote branch interfaces may have significantly lower line speeds, such as 64 kbps. If data is sent at full rate from the central site to a slow-speed remote site, the interface at the remote site may become congested and degrade voice performance.
3-15
2.
Remote-to-central-site oversubscription It is common practice in Frame Relay or ATM networks to oversubscribe bandwidth when aggregating many remote sites to a single central site. For example, there may be multiple remote sites that connect to the WAN with a T1 interface, yet the central site only has a single T1 interface. While this configuration allows the deployment to benefit from statistical multiplexing, the router interface at the central site may become congested during traffic bursts, thus degrading voice quality.
3.
Bursting above Committed Information Rate (CIR) Another common configuration is to allow traffic bursts above the CIR, which represents the rate that the service provider has guaranteed to transport across its network with no loss and low delay. For example, a remote site with a T1 interface may have a CIR of only 64 kbps. When more than 64 kbps worth of traffic is sent across the WAN, the provider marks the additional traffic as discard eligible. If congestion occurs in the provider network, this traffic will be dropped. Again, this may affect voice quality.
Traffic shaping provides a solution to these issues by limiting the traffic sent out an interface to a rate lower than the line rate, thus ensuring that no congestion occurs on either end of the WAN. Figure 3-9 illustrates this mechanism with a generic example, where R is the rate with traffic shaping applied.
Figure 3-9 Traffic Shaping Mechanism
Line Rate R
without Traffic Shaping with Traffic Shaping
3-16
77298
EDCS-197018
C H A P T E R
Choosing a Cisco IP Telephony Gateway

There are a number of methods for connecting an IP telephony network to the Public Switched Telephone Network (PSTN), a legacy PBX, or key systems. Gateways range from specialized, entry-level and stand-alone voice gateways to high-end, feature-rich integrated router and Cisco Catalyst gateways, and choosing the right one for your application can be daunting at first. However, by listing the required features in combination with the long-term needs of your enterprise, you can find an effective gateway solution. This chapter discusses the following topics on selecting a gateway:

Understanding Cisco Gateways, page 4-1 Gateway Requirements, page 4-2 Gateway Protocols, page 4-2 Gateway Protocol and Core Feature Requirements, page 4-4 Site-Specific Gateway Requirements, page 4-11
Understanding Cisco Gateways

Cisco access gateways allow Cisco CallManager to communicate with non-IP telecommunications devices. There are two types of Cisco access gateways, analog and digital.
Cisco Access Analog Gateways

There are two categories of Cisco access analog gateways, trunk gateways and station gateways.
Access Analog Station Gateways Analog station gateways connect Cisco CallManager to Plain Old Telephone Service (POTS) analog telephones, interactive voice response (IVR) systems, fax machines, and voice mail systems. Station gateways provide Foreign Exchange Station (FXS) ports.
Access Analog Trunk Gateways Analog trunk gateways connect Cisco CallManager to PSTN central office (CO) or PBX trunks. Trunk gateways provide Foreign Exchange Office (FXO) ports for PSTN or PBX access and E&M (recEive and transMit, or ear and mouth) ports for analog trunk connection to a legacy PBX. Whenever possible, use digital gateways to minimize any answer and disconnect supervision issues. Analog Direct Inward Dialing (DID) is also available for PSTN connectivity.
4-1
Chapter 4 Gateway Requirements
Cisco Access Digital Trunk Gateways

A Cisco access digital trunk gateway connects Cisco CallManager to the PSTN or to a PBX via digital trunks such as Primary Rate Interface (PRI) or T1 Channel Associated Signaling (CAS). Digital T1 PRI trunks may also be use to connect to certain legacy voice mail systems.
Gateway Requirements
When selecting an IP telephony gateway, consider the common or core requirements as well as site and implementation-specific features. IP telephony gateways must meet the following core requirements:
Dual tone multifrequency (DTMF) relay capabilities DTMF relay capability, specifically out-of-band DTMF, separates DTMF digits from the voice stream and sends them as signaling indications through the gateway protocol (H.323, SCCP, or MGCP) signaling channel instead of as part of the voice stream or bearer traffic. Out-of-band DTMF is needed when using a low bit rate codec for voice compression because the potential exists for DTMF signal loss or distortion.
Supplementary services support Supplementary services are typically basic telephony functions such as hold, transfer, and conferencing.
Cisco CallManager redundancy support Cisco Architecture for Voice, Video, and Integrated Data (AVVID) for IP telephony is based on a distributed model for high availability. Cisco CallManager clusters provide for Cisco CallManager redundancy. The gateways must support the ability to re-home to a secondary Cisco CallManager in the event that a primary Cisco CallManager fails. This differs from call survivability in the event of a Cisco CallManager or network failure. See Call Survivability in Cisco CallManager, page 4-10.
Any IP telephony gateway selected for an enterprise deployment should support the preceding core requirements. Additionally, every IP telephony implementation has its own site-specific feature requirements, such as analog or digital access, DID, and capacity requirements. See Site-Specific Gateway Requirements, page 4-11.
Gateway Protocols
With Cisco CallManager Release 3.0 and later, the following gateway protocols are supported:

H.323 Skinny Client Control Protocol (SCCP) Media Gateway Control Protocol (MGCP)
Cisco IP Phones and integrated switch gateways such as the Catalyst 6000 gateway modules use SCCP, which is a lighter-weight protocol. SCCP uses a master/slave model while H.323 is a peer-to-peer model. MGCP also follows a master/slave model.
4-2
EDCS-197018
Chapter 4
Choosing a Cisco IP Telephony Gateway Gateway Protocols
Selecting the Gateway Protocol

Protocol selection depends on site-specific requirements and the installed base of equipment. For example, most remote branch locations have Cisco 2600 or 3600 series routers installed. These routers support H.323 and MGCP 0.1 with Cisco IOS Release 12.2.2(XN) and Cisco CallManager Release 3.1 or later. For gateway configuration, MGCP might be preferred to H.323 due to simpler configuration or support for call survivability during a Cisco CallManager switchover from a primary to a secondary Cisco CallManager. On the other hand, H.323 might be preferred over MGCP because of the robustness of the interfaces supported. Simplified Message Desk Interface (SMDI) is a de facto standard for integrating voice mail systems to PBXs or Centrex systems. Connecting to a voice mail system via SMDI and using either analog FXS or digital T1 PRI would require either SCCP or MGCP protocol because H.323 devices do not identify the specific line being used from a group of ports. Use of H.323 gateways for this purpose means the Cisco Message Interface cannot correctly correlate the SMDI information with the actual port or channel being used for an incoming call. In addition, the Cisco CallManager deployment model being used can influence gateway protocol selection. (Refer to the chapter on IP Telephony Deployment Models.) Table 4-1 shows which gateways support a given protocol. Each of these protocols follows a slightly different methodology to provide support for the core gateway requirements. Gateway Protocol and Core Feature Requirements, page 4-4, describes how each protocol provides these requirements.
Table 4-1 Supported Gateway Protocols and Cisco IP Telephony Gateways
Cisco Gateway VG200
MGCP 0.1 Yes Supported with:

H.323 Yes
SCCP No
FXS/FXO T1 CAS (E&M Wink Start; Delay Dial only) T1/E1 PRI No No Yes, supported for FXS Yes Yes Yes Yes Yes No No Yes No No No
VG248 DE-30+, DT-24+ Cisco 827 Cisco ATA186 Cisco 1751 Cisco 3810 V3 Cisco 2600
No Yes No No No Yes Yes Supported with:

FXS/FXO T1 CAS (E&M Wink Start; Delay Dial only) T1/E1 PRI
4-3
Chapter 4 Gateway Protocol and Core Feature Requirements
Table 4-1
Supported Gateway Protocols and Cisco IP Telephony Gateways (continued)
Cisco Gateway Cisco 3600
MGCP 0.1 Yes Supported with:

H.323 Yes
SCCP No
FXS/FXO T1 CAS (E&M Wink Start; Delay Dial only) T1/E1 PRI Yes Yes, Cisco IOS release 12.1(5) and 12.2(2)XA Yes Future support Yes Yes Yes No No No No No No No
Cisco 5300 Cisco AS5350 Cisco AS5400 Cisco AS5800 Cisco AS5850 Cisco 7200 Cisco 7500 Catalyst 4000 WS-X4604-GWY Gateway Module Catalyst 6000 WS-X6608-x1 Gateway Module and FXS Module WS-X6624 Catalyst 4224 Cisco ICS7750-MRP Cisco ICS7750-ASI
No No No No No No Yes
Yes Supported with:

No
No
T1 CAS T1/E1 PRI FXS with WS-6624 Yes Yes Yes No No No
Yes No No
Note
Prior to deployment, check the Cisco IOS software release notes to confirm feature or interface support.
Gateway Protocol and Core Feature Requirements

This section describes how each protocol (SCCP, H.323, and MGCP) supports the following gateway feature requirements:

DTMF Relay, page 4-5 Supplementary Services, page 4-5 Cisco CallManager Redundancy, page 4-8 Call Survivability in Cisco CallManager, page 4-10
4-4
EDCS-197018
Chapter 4
Choosing a Cisco IP Telephony Gateway Gateway Protocol and Core Feature Requirements
DTMF Relay
Dual-Tone Multifrequency (DTMF) is a signaling method that uses specific pairs of frequencies within the voice band for signals. A 64 kbps pulse code modulation (PCM) voice channel can carry these signals without difficulty. However, when using a low bite-rate codec for voice compression, the potential exists for DTMF signal loss or distortion. An out-of-band signaling method for carrying DTMF tones across a Voice over IP (VoIP) infrastructure provides an elegant solution for these codec-induced symptoms.
SCCP Gateways
The SCCP gateways, such as the Cisco VG248, carry DTMF signals out-of-band using Transmission Control Protocol (TCP) port 2002. Out-of-band DTMF is the default gateway configuration mode for the VG248.
H.323 Gateways
The H.323 gateways, such as the Cisco 3600 series products, can communicate with Cisco CallManager using the enhanced H.245 capability for exchanging DTMF signals out-of-band. The following is an example out-of-band DTMF configuration on a Cisco IOS gateway:
dial-peer voice 100 voip destination-pattern 555. session target ipv4:10.1.1.1 CODEC g729ar8 dtmf-relay h245-alphanumeric preference 0
MGCP Gateway
The Cisco IOS-based VG200, 2600, and 3600 platforms use MGCP for Cisco CallManager communication. Within the MGCP protocol is the concept of packages. The MGCP gateway loads the DTMF package upon start-up. The MGCP gateway sends symbols over the control channel to represent any DTMF tones it receives. Cisco CallManager then interprets these signals and passes on the DTMF signals, out-of-band, to the signaling endpoint. The global configuration command for DTMF relay is:
mgcp dtmf-relay CODEC all mode out-of-band
You must enter additional configuration parameters in the Cisco CallManager MGCP gateway configuration interface. The Catalyst 6000, DE-30+, and DT-24+ all support MGCP with Cisco CallManager Release 3.1 and later. DTMF relay is enabled by default and does not need additional configuration.
Supplementary Services
Supplementary services provide user functions such as hold, transfer, and conferencing. These are considered fundamental requirements of any voice installation. Each gateway evaluated for use in an IP telephony network should provide support for supplementary services natively, without the use of a software media termination point (MTP).
4-5
SCCP Gateways
The Cisco VG248 and ATA 186 gateways provide full supplementary service support. The SCCP gateways use the Gateway-to-Cisco CallManager signaling channel and SCCP to exchange call control parameters.
H.323 Gateways
H.323v2 implements Open/Close LogicalChannel and the emptyCapabilitySet features. The use of H.323v2 by H.323 gateways, beginning in Cisco IOS Release 12.0(7)T and Cisco CallManager Release 3.0 and later, eliminates the requirement for an MTP to provide supplementary services. With Cisco CallManager Release 3.1 and later, a transcoder is allocated dynamically only if required during a call to provide access to G.711-only devices while still maintaining a G.729 stream across the WAN. Full support for H.323v2 is available in Cisco IOS Release 12.1.1T. Once an H.323v2 call is set up between a Cisco IOS gateway and an IP phone, using the Cisco CallManager as an H.323 proxy, the IP phone can request to modify the bearer connection. Because the Real-Time Transport Protocol (RTP) stream is directly connected to the IP phone from the Cisco IOS gateway, a supported voice codec can be negotiated. Figure 4-1 and the following steps illustrate a call transfer between two IP phones:
1. 2. 3. 4.
If IP Phone 1 wishes to transfer the call from the Cisco IOS gateway to Phone 2, it issues a transfer request to Cisco CallManager using SCCP. Cisco CallManager translates this request into an H.323v2 CloseLogicalChannel request to the Cisco IOS gateway for the appropriate SessionID. The Cisco IOS gateway closes the RTP channel to Phone 1. Cisco CallManager issues a request to Phone 2, using SCCP, to set up an RTP connection to the Cisco IOS gateway. At the same time, Cisco CallManager issues an OpenLogicalChannel request to the Cisco IOS gateway with the new destination parameters, but using the same SessionID. After the Cisco IOS gateway acknowledges the request, an RTP voice bearer channel is established between Phone 2 and the Cisco IOS gateway.
5.
4-6
EDCS-197018
Chapter 4
Figure 4-1
H.323 Gateway Supplementary Service Support
Cisco CallManager
Step 1 Phone 1
M
Step 2 IP PSTN
V
Phone 2 IP Cisco CallManager Step 4 Phone 1 Step 3 IP
M
H.323 gateway
V
Phone 2 IP Step 5
PSTN
H.323 gateway
Skinny Client Control Protocol (SCCP) H.323v2 Voice/RTP path
MGCP Gateway
The MGCP gateways provide full support for the hold, transfer, and conference features through the MGCP protocol. Because MGCP is a master/slave protocol with Cisco CallManager controlling all session intelligence, Cisco CallManager can easily manipulate MGCP gateway voice connections. If an IP telephony endpoint (for example, an IP phone) needs to modify the session (for example, transfer the call to another endpoint), the endpoint would notify Cisco CallManager using SCCP. Cisco CallManager then informs the MGCP gateway, using the MGCP User Datagram Protocol (UDP) control connection, to terminate the current RTP stream associated with the Session ID and to start a new media session with the new endpoint information. Figure 4-2 illustrates the protocols exchanged between the MGCP gateway, endpoints, and Cisco CallManager.
77299
4-7
Figure 4-2
MGCP Gateway Supplementary Service Support
Direct call from MGCP gateway to IP phone. MTP is not required. Cisco CallManager
M
Phone 1
IP PSTN
V
Phone 2 IP
MGCP gateway
Cisco CallManager
M
Phone 1
IP
V
Phone 2 IP MGCP gateway
PSTN
The MGCP gateway supports supplementary services such as call transfer. Skinny Client Control Protocol MGCP Voice path
77300
Cisco CallManager Redundancy

An integral piece of the IP telephony architecture is the provisioning of low-cost, distributed PC-based systems to replace expensive and proprietary legacy PBX systems. This distributed design lends itself to the robust fault tolerant architecture of clustered Cisco CallManagers. Even in its most simplistic form (a two-system cluster), a secondary Cisco CallManager should be able to pick up control of all gateways initially managed by the primary Cisco CallManager.
SCCP Gateways
Upon boot-up, the Cisco VG248 and ATA 186 gateways are provisioned with Cisco CallManager server information. When these gateways initialize, a list of Cisco CallManagers is downloaded to the gateways. This list is prioritized into a primary Cisco CallManager and secondary Cisco CallManager. In the event that the primary Cisco CallManager becomes unreachable, the gateway registers with the secondary Cisco CallManager.
4-8
EDCS-197018
Chapter 4
H.323 Gateways
Using several enhancements to the dial-peer and voice class command sets in Cisco IOS Release 12.1(2)T, Cisco H.323 gateways support redundant Cisco CallManagers. A new command, H.225 tcp timeout <seconds>, has been added. This command tracks the time it takes for the H.323 gateway to establish an H.225 control connection for H.323 call setup. If the H.323 gateway cannot establish an H.225 connection to the primary Cisco CallManager, it tries a second Cisco CallManager defined in another dial-peer statement. The H.323 gateway shifts to the dial-peer statement with next highest preference setting. The following commands allow you to configure Cisco CallManager redundancy for a H.323 gateway:
dial-peer voice 101 voip destination-pattern 1111 session target ipv4:10.1.1.101 preference 0 voice class h323 1 dial-peer voice 102 voip destination-pattern 1111 session target ipv4:10.1.1.102 preference 1 voice class h323 1 voice class h323 1 h225 tcp timeout <1-30 sec>
Note
Cisco CallManager redundancy does not imply call survivability. If the primary Cisco CallManager fails, any call between an IP phone and a phone connected via an H.323 gateway is terminated. Refer to Call Survivability in Cisco CallManager, page 4-10, for more information on call survivability.
MGCP Gateway
MGCP gateways also have the ability to fail over to a secondary Cisco CallManager in the event of communication loss with the primary Cisco CallManager. When the failover occurs, active calls are preserved. Within the MGCP gateway configuration file, the primary Cisco CallManager is identified using the call-agent <hostname> command, and a list of secondary Cisco CallManager is added using the ccm-manager redundant-host command. Keepalives with the primary Cisco CallManager are through the MGCP application-level keepalive mechanism, whereby the MGCP gateway sends an empty MGCP notify (NTFY) message to Cisco CallManager and waits for an acknowledgement. Keepalive with the backup Cisco CallManagers is through the TCP keepalive mechanism. If the primary Cisco CallManager becomes available at a later time, the MGCP gateway can re-home, or switch back to the original Cisco CallManager. This re-homing can occur either immediately, after a configurable amount of time, or only when all connected sessions have been released. This is enabled through the following global configuration commands:
ccm-manager redundant-host <hostname1 | ipaddress1 > <hostname2 | ipaddress2> [no] call-manager redundancy switchback [immediate|graceful|delay <delay_time>]
4-9
Call Survivability in Cisco CallManager

This section describes some general rules for call survivability using H.323, SCCP, and MGCP gateways. Call survivability means that the RTP bearer stream (the voice conversation) between two IP endpoints is preserved even if the Cisco CallManager that originally established the stream between the endpoints is no longer reachable. Endpoints may be categorized as survivable or non-survivable, as indicated in Table 4-2.
Table 4-2 Endpoint Survivability
Survivable Endpoints IP Phones (SCCP) MGCP gateways
Non-Survivable Endpoints H.323 gateways H.323 endpoints or trunks TAPI endpoints. (IP SoftPhone, IVR, AA, and other Cisco applications)
The following types of failures can occur:

Cisco CallManager failure Failures that render Cisco CallManager incapable of responding to call signalling. Network failure Any event in the network that prevents communications between Cisco CallManager and the endpoints (for example, gateways or IP phones).
Note
Call failure may mean that the phone goes on-hook, receives reorder tone, or in some cases simply goes silent (for example, if the streaming connection is terminated).
Endpoint Rules for Gateway Call Survivability

The following rules apply for various endpoint and Cisco Call Manager failure scenarios:
If the call involves only non-survivable endpoints, the call fails if there is a failure in any of the Cisco Call Managers to which one of the endpoints is registered. This is true regardless of whether a conference bridge, an MTP, or a transcoder is involved in the call and regardless of which Cisco CallManager (when there are more than one) fails. If the call involves one non-survivable endpoint and one survivable endpoint, the call fails only if the Cisco CallManager associated with the non-survivable endpoint fails. If the call involves only survivable endpoints and one or more Cisco CallManagers fail, the streaming connection between the endpoints is maintained. However, the endpoints do not have call processing services available to them after the failure. For example, the unavailable services would include transfer, conference, hold, park, pickup, and resume.
In general, MGCP gateways provide the highest degree of call survivability. In Cisco CallManager Release 3.1 and later, the Catalyst 6000 T1/E1 gateway modules use MGCP supporting PRI and T1 CAS, thus enhancing call survivability when an SCCP-based IP phone and an MGCP gateway are the two endpoints.
4-10
EDCS-197018
Chapter 4
Choosing a Cisco IP Telephony Gateway Site-Specific Gateway Requirements
Site-Specific Gateway Requirements

Each IP telephony implementation has its own gateway and site-specific requirements. The following questions can help you with IP telephony gateway selection:

Is the PSTN (or PBX) access analog or digital? What type of analog (FXO, FXS, E&M) or digital (T1, E1, CAS, CCS) interface is required for the PSTN or PBX? If the PSTN access is digital, what type of signaling is required (T1 CAS, Q.931 PRI, E1 CAS, or R2)? What type of signaling does the PBX currently use?
FXO or FXS: loop start or ground start E&M: wink-start, delay-start, or immediate-start E&M: type I, II, III, IV, or V T1: CAS, Q.931 PRI (User-Side or Network-Side), Q.SIG, DPNSS, or Proprietary d-channel
(CCS) signaling
E1: CAS, R2, Q.931 PRI (User-Side or Network-Side), Q.SIG, DPNSS, Proprietary d-channel
(CCS) signaling, or R2

What type of framing (SF, ESF, or G.704) and line encoding (B8ZS, AMI, CRC-4, or HDB3) does the PBX currently use? Does the PBX require passing proprietary signaling? If so, which time slot is the signaling passed on, and is it HDLC-framed? What is the required capacity of the gateway; that is, how many channels are required? (Typically, if 12 or more voice channels are required, then digital is more cost effective.) Is Direct Inward Dialing (DID) required? If so, specify analog or digital. Is Calling Line ID (CLID) needed? What types of fax and modem support are required? What types of voice compression are required? What types of supplementary services are required? Will the PBX provide clocking, or will it expect the Cisco gateway to provide clocking? Is rack space available for all needed gateways, routers, and switches?
Note
Direct Inward Dial (DID) refers to a private branch exchange (PBX) or Centrex feature that permits external calls to be placed directly to a station line without use of an operator.
Note
Calling Line Identification (CLI, CLID, or ANI) refers to a service available on digital phone networks to display the calling number to the called party. The central office equipment identifies the phone number of the caller, enabling information about the caller to be sent along with the call itself. CLID is synonymous with ANI (Automatic Number Identification). Cisco IP telephony gateways are able to inter-operate with most major PBX vendors, and they are EIA/TIA-464B compliant.
4-11
Chapter 4 Site-Specific Gateway Requirements
Q.SIG Support
Q.SIG is a suite of international standards designed to provide flexibility in connecting PBX equipment in a corporate network. Among its other features, Q.SIG provides an open, standards-based method for interconnecting PBX equipment from different vendors. Detailing the benefits of Q.SIG is beyond the scope of this document, but for more information, refer to the Q.SIG documentation at http://www.Q.SIG.ie/ Q.SIG is currently supported in H.323 gateways in a pass-through mode. The H.323 gateways provide full Q.SIG feature transparency for Q.SIG information elements. Basic call setup and teardown are supported using H.323 Q.SIG gateways as shown in Figure 4-3.
Figure 4-3 H.323 Gateway Q.SIG Support
QSIG E-1/T-1 signal
Current QSIG support
QSIG E-1/T-1 signal
PBX
Cisco IOS gateway
Cisco IOS gateway
PBX
Q.SIG protocol support allows Cisco voice gateways to connect PBXs, key systems, and central office switches that communicate using the Q.SIG protocol, which is becoming the standard for PBX interoperability in Europe and North America. Q.SIG is a variant of ISDN D-channel signaling. With Q.SIG, Cisco networks emulate the functionality of the PSTN, and Q.SIG signaling messages allow the dynamic establishment of voice connections across a WAN to a peer router, which can then transport the signaling and voice packets to a second PBX that uses Q.SIG. Table 4-3 summarizes Q.SIG support in Cisco H.323 gateways.
Table 4-3 Q.SIG Support on H.323 Gateways
Platform Cisco 2600 and 3600 Series Cisco 3810 Cisco 7200 Cisco 7500 Cisco 5300 Cisco AS5350 Cisco AS5400
Media BRI and T1/E1 Q.SIG BRI and T1/E1 Q.SIG T1/E1 Q.SIG T1/E1 Q.SIG T1/E1 T1/E1 and CT3
Minimum Cisco IOS Software Release Required 12.0.7XK 12.1.2T 12.0.4T 12.0.7XK 12.1.2T 12.1.3T 12.0.7T 12.1(5)XM
For more information on Q.SIG support on Cisco IOS gateways, refer to http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/dt_qsig.ht m#xtocid116542
4-12
77301
EDCS-197018
Chapter 4
Q.SIG currently is not supported on Cisco CallManager or on the Catalyst 6000 or 4000 gateways. When a PBX is connected to the H.323 gateway using Q.SIG and calls are made between phones on the PBX and IP phones attached to the Cisco CallManager, basic PRI functionality is provided via H.323 as shown in Figure 4-4. The basic functionality includes Calling Line Identifier (CLID) and Direct Inward Dialed (DID) number.
Figure 4-4 Cisco CallManager, H.323 Gateway, and Q.SIG Support
QSIG
Cisco CallManager H.323
V
PBX
IP
Cisco CallManager support for Q.SIG would be needed to provide feature transparency between IP phones and Q.SIG connected devices. Q.SIG will be supported in a future release of Cisco CallManager.
Site Specific Gateway Features Summary

The site-specific and core gateway requirements are a good start to help narrow the possible choices. Once you have defined the required features, you can make a gateway selection for each of the pertinent configurations, whether they are single-site enterprise deployments of various sizes and complexities or multi-site enterprise deployments. Table 4-4 and Table 4-5 list supported telephony features relating to analog and digital gateways.
Table 4-4 Cisco IP Telephony Gateway Analog Interfaces
77302
Some functionality as PRI CLID DID
Gateway VG200 VG248 ATA 186 DE-30+ and DT-24+ Cisco 827 Cisco 1750 Cisco 1751 Cisco 3810 V3 Cisco 2600 Cisco 3600 Cisco 7200 Cisco 7500 Cisco 5300 Cisco AS5350 Cisco AS5400
FXS Yes Yes Yes No Yes Yes Yes Yes Yes No No No No No
FXO Yes No No No No Yes Yes Yes Yes No No No No No
E&M Yes No No No No Yes Yes Yes Yes No No No No No
Analog DID/CLID1 Yes/Yes No/Yes No/No N/A No/No Yes/Yes No/Yes 12.1(5)XM/12.2.1T 12.1(5)XM/12.2.1T No/No No/No No/No No/No No/No
4-13
Chapter 4 Site-Specific Gateway Requirements
Table 4-4
Cisco IP Telephony Gateway Analog Interfaces (continued)
Gateway Cisco AS5800 Cisco AS5850 Catalyst 4224 Catalyst 6000 WS-X6624 Cisco ICS7750-MRP Cisco ICS7750-ASI
FXS No No Yes Yes Yes Yes
FXO No No Yes Yes No Yes Yes
E&M No No Yes Future No Yes Yes
Analog DID/CLID1 No/No No/No No/No Future/Future No/Yes 12.2.(1)XD2 12.2.(1)XD2
Catalyst 4000 WS-X4604-GWY Yes
1. Analog DID requires a DID voice interface card (VIC). CLID is supported only with H.323. All Cisco IOS versions are minimum requirements.
Table 4-5
Cisco IP Telephony Gateway Digital Interfaces and Cisco IOS Software Releases
Gateway
VG200 1 DE-30+ and DT-24+ Cisco 1750 Cisco 3810 V3 Cisco 2600
T1 CAS E1/R2
Yes, FG-D No No Yes Yes FG-D Future No No No
E1 CAS
Yes R2 No No Yes
User Side PRI

Yes Yes No No
Network Side PRI Yes Yes No No

12.1(2)XH 12.1.(3)T 12.1(2)XH 3 12.1.(3)T 12.1(3)T3
3
User Network Digital Q.SIG Side BRI Side BRI DID/CLID PRI/BRI
Yes No Yes Yes Yes Yes No Yes No Yes 12.1.(5)T Yes Yes 12.1.(5)T No No Yes/Yes2 Yes/NA 2 Yes/NA 2 Yes/No N/A Yes Yes/NA
2
Future Future No Yes/Yes Yes/Yes 12.07XK/ 12.1.2T Yes/Yes 12.07XK/ 12.1.2T Yes/No 12.07XK/ 12.1.2T (no BRI)
12.1.(2)XH 12.1(2)XH 12.1(2)XH 12.1.(3)T 12.1(2)XH 12.1.(3)T 12.1.(3)T 12.1.(3)T
Cisco 3600
Yes FG-D
12.1(2)XH 12.1(2)XH 12.1.(3)T 12.1.(3)T 12.1(3)T
Cisco 7200
Yes FG-D 12.1.(3)T 12.1.(3)T
Cisco 7500
Yes FG-D 12.1.(3)T 12.1.(3)T 12.1.(3)T 12.1.(3)T

3
No
No
Yes/Yes2
Yes/No 12.07XK/ 12.1.2T (no BRI)
Cisco 5300
Yes FG-D FG-B
Yes
Yes
Yes
12.0.7T 3
No
No
Yes/Yes
Yes/No 12.0.7T (no BRI)
Cisco AS5350 Cisco AS5400 Cisco AS5800 Cisco AS5850
Yes Yes Yes Yes
Yes Yes Yes Yes
Yes Yes Yes Yes
Yes Yes Yes Yes
Yes Yes Yes Yes
No No No No
No No No No
Yes Yes Yes Yes
Yes No No No
4-14
EDCS-197018
Chapter 4
Table 4-5
Cisco IP Telephony Gateway Digital Interfaces and Cisco IOS Software Releases (continued)
Gateway
Catalyst 4224 Catalyst 4000 WS-X4604-GWY Catalyst 6000 WS-X6608-x1
T1 CAS E1/R2
Yes Yes Yes Future Yes No No No
E1 CAS
Yes Yes No No No
User Side PRI

Yes (Voice only) Yes Yes Yes Yes
Network Side PRI

Yes (Voice only) Yes Yes Yes Yes
User Network Digital Q.SIG Side BRI Side BRI DID/CLID PRI/BRI
Yes Future No Yes Yes Yes Future No Yes Yes Yes/No Yes/No Yes/No Yes Yes Future Future Future No No
Cisco ICS7750-MRP Yes Cisco ICS7750-ASI

1. In H.323 mode.
Yes
2. For T1 CAS CLID, FG-D or FG-B is required. See DDTS, CSCdu28690 for Cisco 2600, 3600, and VG200. If FG-B, then ANI/CLID delimiter feature is required to get CLID. For E1, R2 is required. 3. Net 5 & NI.
Note
DASS and DPNSS are currently not supported on any Cisco gateways. ISDN non-facility associated signaling (NFAS) is currently supported on the gateways listed in Table 4-6.
Table 4-6 NFAS Support by PRI Interface Type
Gateway Cisco AS5300, 5350, 5400, and 5800 Cisco 7200 Cisco 7500
4ESS Yes
National ISDN (NI-2) Yes
5ESS No
DMS100, DMS250 Yes
NTT No
TS014 No
Net5 No
Yes Yes
Yes Yes
No No
Yes Yes
No No
No No
No No
NFAS support is planned for the Cisco 2600 and 3600 series products in a future Cisco IOS software release.
4-15
Chapter 4 Summary
Summary
The task of selecting the most appropriate gateway for your application task can be simplified by observing the guidelines suggested in this chapter for the following key areas:

Core gateway requirements Site-specific gateway requirements Gateway signaling protocol characteristics Cisco CallManager deployment model being used
In addition, be sure to use the appropriate Cisco CallManager and Cisco IOS software releases for the required feature support.
4-16
EDCS-197018
C H A P T E R
Transcoding, Conferencing, and MTP Resources

This chapter describes how to design and provision transcoding, conferencing, and Media Termination Point (MTP) resources for Cisco IP telephony deployments in the enterprise environment. Cisco CallManager provides access to a variety of media resources. A media resource is a software-based or hardware-based entity that performs media processing functions on the voice data streams to which it is connected. Media processing functions include mixing multiple streams to create one output stream, passing the stream from one connection to another, or transcoding the data stream from one compression type to another, and so forth. Cisco CallManager allocates and uses the following types of media resources:

Media Termination Point (MTP) resources (See MTP and Transcoding Resources, page 5-3.) Transcoding resources (See MTP and Transcoding Resources, page 5-3.) Unicast conferencing resources (See Conferencing Resources, page 5-13.) Music on hold (MOH) resources (Refer to the Music on Hold chapter, available in a future release of this document.)
This chapter focuses on MTP, transcoding, and conferencing resources.
Media Resource Types

The following sections provide definitions of the major media resource types discussed in this chapter.
Media Termination Point (MTP)

A Media Termination Point (MTP) is an entity that accepts two full-duplex G.711 stream connections. It bridges the media streams between the two connections and allows the streaming connections to be set up and torn down independently. The streaming data received from the input stream on one connection is passed to the output stream on the other connection, and vice versa. In addition, the MTP transcodes a-law to mu-law and vice versa, and adjusts packet sizes as required by the two connections. MTPs are used to extend supplementary services to H.323 endpoints that do not support the H.323v2 OpenLogicalChannel and CloseLogicalChannel request features with the EmptyCapabilitiesSet feature. When needed, an MTP is allocated and connected into a call on behalf of an H.323 endpoint. Once inserted, the media streams are connected between the MTP and the H.323 device, and these connections are present for the duration of the call. The media streams connected to the other side of the MTP can be connected and disconnected as needed to implement features such as hold, transfer, and so forth.
5-1
Chapter 5 Media Resource Types
There are two types of MTPs:
Software MTP A software MTP is a device that is implemented by installing the Cisco IP Voice Media Streaming Application on a server. When the installed application is configured as an MTP application, it registers with a Cisco CallManager node and informs Cisco CallManager of how many MTP resources it supports. A software MTP device supports only G.711 streams.
Hardware MTP A hardware MTP is a device implemented on a hardware blade that is plugged into a hardware switching platform, such as a Cisco Catalyst 6000, a Cisco Catalyst 4000, a Cisco VG200 DSP farm, or the multiservice route processor (MRP) of the Cisco ICS 7750. A hardware MTP is really a transcoder used as an MTP because transcoders have MTP capabilities. The device registers with a Cisco CallManager node as a transcoder and informs Cisco CallManager of how many resources it supports.
Transcoder
Transcoding is the process used to compress and decompress voice streams to maximize use of WAN resources for voice over IP (VoIP) traffic. A transcoder is a device that takes the output stream of one codec and converts it in real time (transcodes it) into an input stream for a different codec type. In other words, a transcoder converts a stream of one compression type into a stream of another compression type. Transcoding is, in effect, an IP-to-IP voice gateway service. A transcoding node can convert a G.711 voice stream into a low bit-rate (LBR) compressed voice stream, such as G.729a. This is critical for enabling applications such as Cisco IP Integrated Voice Response (IVR), voice messaging, and conference calls over low-speed IP WANs. MTP transcoding is currently supported only on the hardware-based MTP resources provided by Cisco Catalyst voice gateways, the DSP farm on the Cisco VG200, and the Packet Voice/Data Modules (PVDMs) located on the MRP card within the ICS 7750. In addition, a transcoder provides the capabilities of an MTP and may be used to enable supplementary services for H.323 endpoints when required.
Unicast Conference Bridge

A unicast conference bridge is a device that accepts multiple connections for a given conference. It can accept any number of connections for a given conference, up to the maximum number of streams allowed for a single conference on that device. There is a one-to-one correspondence between media streams connected to a conference and participants connected to the conference. The conference bridge mixes the streams together and creates a unique output stream for each connected party. The output stream for a given party is usually the composite of the streams from all connected parties minus their own input stream. Some conference bridges mix only the three loudest talkers on the conference and distribute that composite stream to each participant (minus their own input stream if they are one of the talkers). There are two types of conference bridges:
Software conference bridge A software unicast conference bridge is a standard conference mixer that is capable of mixing G.711 audio streams. Both a-law and mu-law streams may be connected to the same conference. The number of parties that can be supported on a given conference depends on the server where the conference bridge software is running and the configuration for that device.
5-2
EDCS-197018
Chapter 5
Transcoding, Conferencing, and MTP Resources MTP and Transcoding Resources
Hardware conference bridge A hardware conference bridge has all the capabilities of a software conference bridge. In addition, some hardware conference bridges can support multiple low bit-rate (LBR) stream types such as G.729, GSM, or G.723. This allows some hardware conference bridges to handle mixed-mode conferences. In a mixed-mode conference, the hardware conference bridge transcodes G.729, GSM, and G.723 streams into G.711 streams, mixes them, and then encodes the resulting stream into the appropriate stream type for transmission back to the user. Some hardware conference bridges support only G.711 conferences.
MTP and Transcoding Resources

As mentioned previously, MTP resources can be either software-based or hardware-based. While all device types provide the original MTP functionality, only hardware-based resources are also capable of transcoding. Table 5-1 lists the supported codecs and the maximum number of simultaneous sessions for each device type in a Cisco CallManager deployment.
Table 5-1 Maximum Number of MTP Sessions per Device Type
Device Type Cisco Catalyst 4000 WS-X4604-GWY Cisco Catalyst 6000 WS-6608-T1 or WS-6608-E1
Codecs Supported

Maximum Number of MTP Sessions G.729 to G.711:
G.711 (a-law and mu-law) G.729a G.711 (a-law and mu-law) G.723 G.729a GSM-FR GSM-EFR
16 MTP transcoding sessions 24 MTP transcoding sessions per physical port 192 sessions per module
G.711 to any supported codec:

Any single supported codec (no transcoding):

24 MTP sessions per physical port 192 sessions per module 2 MTP transcoding sessions per DSP (PVDM) port Maximum 10 DSPs supported per MRP for transcoding Total of 20 transcoding sessions per MRP
Cisco ICS 7750 MRP with WICs
G.711 (a-law and mu-law) G.723.1 G.726 G.728 G.729a GSM-FR GSM-EFR
G.711 to any supported codec:

5-3
Chapter 5 MTP and Transcoding Resources
Table 5-1
Maximum Number of MTP Sessions per Device Type (continued)
Cisco VG200 DSP Farm NM-HDV-DSP
G.711 (a-law and mu-law) G.729a, G.729b, G.729ab GSM-FR GSM-EFR
G.711 to G.729

4 transcoding sessions per DSP Maximum of 15 DSPs Total of 60 transcoding sessions per platform
G.711 to GSM:

3 transcoding sessions per DSP Maximum of 15 DSPs Total of 45 transcoding sessions per platform
G.711 only (no transcoding):
32 MTP sessions supported in software 24 MTP sessions if on the same server as Cisco CallManager 48 MTP sessions if running on a standalone server
Software MTP (Cisco IP Voice Media Streaming Application)
G.711 (a-law and mu-law)
G.711 only (no transcoding):

Software MTP Resources

The software-based MTP provided by the Cisco IP Voice Media Streaming Application is suited for single-site deployments, where transcoding is typically not required. In such deployments, the MTP resources are needed only to support devices that are not compliant with H.323v2 (for example, Microsoft NetMeeting prior to version 3.1). These software MTP resources have the following characteristics:

G.711 is the only supported codec. The maximum number of simultaneous sessions supported is 24 if the Cisco IP Voice Media Streaming Application resides on the same server as Cisco CallManager, or 48 if it runs on a separate, dedicated server. Cisco recommends running this application on a dedicated server. If several media resources (such as software MTP, conferencing, and MOH) reside on the same server as Cisco CallManager, the total number of sessions should not exceed 24. Security issues should be considered if the Cisco IP Voice Media Streaming Application is running on the same server as Cisco CallManager because this implies allowing User Datagram Protocol (UDP) traffic to and from Cisco CallManager. Running the Cisco IP Voice Media Streaming Application on the same server as Cisco CallManager increases the CPU load and might adversely impact call processing performance.
Hardware MTP and Transcoding Resources

Introducing a WAN into an IP telephony implementation raises the issue of voice compression. In a single-site deployment, all campus-oriented voice was uncompressed (G.711) to provide the highest quality while incurring the fewest complications. Once a WAN-enabled network is implemented, voice compression may be required to conserve WAN bandwidth. How can WAN users then use the
5-4
EDCS-197018
Chapter 5
conferencing services or IP-enabled applications, which support only G.711 voice connections? The solution is to use hardware-based MTP transcoding services to convert the compressed voice streams into G.711.
Catalyst 4000 MTP and Transcoding Services

The Public Switched Telephone Network (PSTN) gateway and voice services module for the Cisco Catalyst 4003 and 4006 switches supports three analog voice interface cards (VICs) with two ports each or one T1/E1 card with two ports and two analog VICs. The VIC interfaces can be provisioned in any combination of Foreign Exchange Office (FXO), Foreign Exchange Station (FXS), or Ear & Mouth (E&M). Additionally, when configured as an IP telephony gateway from the command line interface (CLI), this module can support conferencing and transcoding services. The Cisco Catalyst 4000 voice gateway module can be configured in either toll bypass or gateway mode. However, the module conferencing and transcoding resources can be configured only in gateway mode. Once gateway mode is enabled, the modules 24 Digital Signal Processors (DSPs), consisting of four Single Inline Memory Modules (SIMMs) for each of six DSPs, are automatically allocated as follows:

PSTN gateway: 96 channels for G.711 voice Conferencing: 24 channels for G.711 conferencing MTP transcoding: 16 channels for LBR-G.711 transcoding
Gateway mode is the default configuration. The following configuration notes apply to the Cisco Catalyst 4000 module:
The Cisco WS-X4604-GWY gateway uses a Cisco IOS Software interface for initial device configuration. All additional configuration of voice features takes place in Cisco CallManager. For all PSTN gateway functions, the Cisco Catalyst 4000 module uses H.323v2 and is configured identically to a Cisco IOS gateway. From the Cisco CallManager configuration screen, simply add the Cisco Catalyst 4000 gateway as an H.323 gateway. The WS-X4604-GWY can operate as a PSTN gateway (toll bypass mode) as well as a hardware-based transcoder or conference bridge (gateway mode). To configure this module as a DSP farm (gateway mode), enter one or both of the following CLI commands:
voicecard conference voicecard transcode
The WS-X4604-GWY requires its own local IP address in addition to the IP address for Cisco CallManager. It is also good practice to specify a loopback IP address for the local Skinny Client Control Protocol (SCCP). A primary, secondary, and tertiary Cisco CallManager can be defined for both the conferencing services and MTP transcoding services.
Catalyst 6000 MTP and Transcoding Services

The Cisco WS-6608-T1 module (or WS-6608-E1 for European countries) is the same module that provides T1 or E1 PSTN gateway support for the Cisco Catalyst 6000. Once this card has been added from Cisco CallManager as a voice gateway, it can be configured as a conferencing or MTP transcoding node. Each port acts independently of the other ports on the module. Specifically, each port can be configured either as a PSTN gateway interface, a conferencing node, or an MTP transcoding node. Whether acting as a PSTN gateway, a conferencing resource, or an MTP transcoding resource, each port on the module requires its own IP address. The port can be configured to have either a static IP address or an IP address provided by Dynamic Host Configuration Protocol (DHCP). If a static IP address is
5-5
entered, a Trivial File Transfer Protocol (TFTP) server address must also be added because the ports retrieve all configuration information from the downloaded TFTP configuration file. Once configured through the Cisco CallManager interface, each port can support one of the following configurations:

PSTN gateway mode: 23 PRI or 24 CAS sessions on the WS-6608-T1 module; 30 sessions on the WS-6608-E1 Conferencing mode: 32 conferencing sessions for G.711, G.723, or G.729 MTP mode: 24 MTP transcoding sessions for G.723 to G.711 or G.729 to G.711
Figure 5-1 shows one possible configuration of the Cisco Catalyst 6000 voice gateway module. In this diagram, the module has two of its eight ports configured in PSTN gateway mode, three ports in conferencing mode, and three ports in MTP transcoding mode.
Note
Each port is considered a separate resource, and can be assigned to a different VLAN. This means one module could be shared by several Cisco CallManager clusters.
Figure 5-1 Cisco Catalyst 6000 Voice Gateway Module
PSTN T1/E1 G.711 gateway
PSTN
Cisco Catalyst MTP Constraints

The following constraints apply to Cisco Catalyst 4000 and 6000 MTP transcoding:

Cisco Catalyst MTP transcoding service supports only LBR codec-to-G.711 conversion and vice versa. There is no support for LBR-to-LBR codec conversion. If all n MTP transcoding sessions are in use, and an n+1 connection is attempted, that call will complete without using the MTP transcoding resource. If this call attempts to use the software MTP function to provide supplementary services, the call would connect, but any attempt to use supplementary services would fail and could result in call disconnection. If the call attempts to use the transcoding features, the call would connect directly, but audio would not be available.
5-6
77305
PSTN T1/E1 G.711 gateway
MTP/transcoding services
Conferencing Services
EDCS-197018
Chapter 5
Cisco VG200 MTP and Transcoding Services

The Cisco Voice Gateway 200 (VG200) can be equipped with an optional DSP Farm network module to provide hardware-based conferencing and transcoding DSP services in a single rack unit (RU). This module is supported by Cisco IOS Release 12.1(5)YH1 or later. The DSP Farm can contain up to five SIMMs, each of which contains three DSPs, for a total of 15 DSPs maximum. The DSP Farm registers with Cisco CallManager using Skinny Client Control protocol (SCCP). DSP resources may be shared among Cisco CallManagers in a cluster through the use of media resource groups and lists. The following considerations apply to the VG200-DSP when used for MTP and transcoding services:

A maximum of 60 G.711-to-G.729 MTP transcoding sessions can be supported in hardware using the DSP resources (4 transcoding sessions per DSP, and a maximum of 15 DSPs per platform). A maximum of 45 G.711-to-GSM MTP transcoding sessions can be supported in hardware using the DSP resources (3 transcoding sessions per DSP, and a maximum of 15 DSPs per platform). A maximum of 32 G.711-only MTP sessions can be supported in software (no DSP resources are used). For G.711, the VG200-DSP supports 10 and 20 ms packets for conferencing and transcoding. For G.729, the VG200-DSP supports 10, 20, and 30 ms packets for conferencing and transcoding. The VG200 supports call preservation during a switchover to a secondary Cisco CallManager upon disconnect from the primary Cisco CallManager. You can use Cisco IOS CLI commands to allocate the DSP channels between conferencing, MTP, and transcoding.
To configure the VG200-DSP for transcoding only, use the following Cisco IOS CLI commands:
VG200-DSP(config)#dspfarm transcoder maximum sessions 60 VG200-DSP(config)#dspfarm VG200-DSP(config)#sccp ccm 10.10.10.100 priority 1 VG200-DSP(config)#sccp ccm 10.10.10.101 priority 2 VG200-DSP(config)#sccp local FastEthernet0/0 VG200-DSP(config)#sccp
To configure the software-based MTP functionality (no transcoding involved), use the following IOS CLI command:
VG200-DSP(config)#sccp mtp sessions ? <1-32> Select the number of MTP sessions to be supported
The default number of software MTP sessions is 12, and the maximum number of sessions supported is 32.
Cisco ICS 7750 MTP and Transcoding Services

The voice services for the Cisco ICS 7750 are located on the multiservice route processor (MRP) card. Up to five MRP cards can be installed within a single ICS 7750 system. Each MRP card has two slots that can be used for various voice interface cards (VICs) or for WAN interface cards (WICs). There are also two positions on the MRP card for installing the Packet Voice/Data Modules (PVDMs). PVDMs provide the DSP hardware functionality for the ICS 7750. PVDMs can be used for processing MTPs and transcoding. Each module can support 1 to 5 DSPs for a maximum total of 10 DSPs per blade. VICs and VWICs installed in MRP cards might require additional digital signal processors (DSPs) for processing higher complexity codecs.
5-7
The PVDM 20 can be used if one of the interfaces is a Multiflex Trunk (MFT) E1 with 30 channels or if sharing between analog and digital interfaces. DSP resource allocation is as follows:

Fixed DSP resources get first priority. The MRP determines how many DSP resources are available for transcoding. If all DSPs are needed for the fixed slots, such as interfaces on slot 0 and 1, then none will be available for any transcoding. DSP resources are reserved for fixed interfaces even if they are not being used. Flexible interfaces (MFTs) and transcoding share the rest of the DSPs.
The following are examples of the various interface types and their maximum supported number of channels:

PSTN Digital Interface: 24/30 channels of G.711 (One PVDM-256K-20) PSTN Analog Interface: 2 channels of G.711 (One PVDM-256K-4) Analog Station Ports with MRP: 2 channels of G.711 (One PVDM-256K-4) Analog Station MRP cards (ASI 81 and 160): 8/16 channels for G.711 ICS 7750 Supported WICs: Up to 10 channels of transcoding per WIC from G.711 to any of the following codecs (require PVDM-256K-20): G.726, G.729A(B), G.723.1, G.728, GSM-FR, GSM-EFR
The ASI 81 and ASI 160 are in effect an MRP with FXS ports and DSP modules all on to a single board. The ASI 81 has a slot for a VWIC, VIC, or WIC. For example, a VWIC-1MFT-T1 could be installed within, but the VWIC requires a PVDM-256K-20. Transcoding can be enabled from the CLI as follows:
[no] sccp local <INT> [port <PORT_NB>] [no] sccp manager <IP|DNS> [port <PORT_NB>] [priority <PRIORITY>] [no] sccp transcode [ip-precedence <VALUE>] [channels <NUM>]
Transcoding in the MRP is controlled by Cisco CallManager, which uses the Skinny Client Control Protocol (SCCP). The MRP registers itself with Cisco CallManager as a transcoder that is using an SCCP session. You can add a maximum of four Cisco CallManagers that may be used for transcoding. Enter the IP address of a Cisco CallManager next to the priority you wish to assign it, with a value of 1 being the highest priority. The Cisco CallManager with the highest priority is the one that is used for transcoding. In case of its failure, the Cisco CallManager with the next highest priority will take over. The MRP can process TDM voice calls and transcoding at the same time. You can specify how many full-duplex transcoding channels are needed by entering the following CLI command:
sccp transcode channels <NUM>
The MRP will reserve necessary DSP resources for the transcoding channels. If channel <NUM> is omitted in the sccp transcode command, the MRP will reserve all the available DSP resources for transcoding.
Provisioning MTP and Transcoding Resources

One of the most crucial aspects to consider when deploying MTP and transcoding resources is provisioning. Proper provisioning requires careful analysis of call load patterns and of the network topology. You must also consider whether resources need to be local or centralized and how many WAN sites will use low bit-rate codecs (such as G.729 or G.723).
5-8
EDCS-197018
Chapter 5
Cisco CallManager employs the concept of a Media Resource Group (MRG), which allows multiple servers within the same Cisco CallManager cluster to share resources such as MTPs, transcoders, conferencing resources, and music on hold (MOH) servers. The following definitions apply to media resource provisioning in Cisco CallManager:
Media Resource Group (MRG) an ordered group of media resources, possibly of different types (for example, MTP, conferencing, and MOH), which are logically bundled for load-sharing purposes (see Figure 5-2). Media Resource Group List (MRGL) an ordered list of Media Resource Groups, used for redundancy purposes.
Media Resource Groups with Cisco CallManager
M
Figure 5-2
Pub lisher & TFTP Ser er v
MRG=C1
MRG=CXM1
Backup
M
M M
1 to 2500 2501 to 5000
Conf
Conf
Conf
Xcode MRG=CXM2
MOH
MRG=X1
Xcode Backup
M M M
Xcode
Conf
Xcode MRG=CXM3
MOH
1 to 7500 7501 to 10,000
MRG=M1
MOH
MOH .
MOH
You configure MRGs and MRGLs for a Cisco CallManager cluster. You can then place the end devices such as IP phones into device pools, which in turn are assigned to a specific MRGL. The main advantages of this mechanism are as follows

Sharing resources among servers within a cluster provides better resource utilization than assigning the resources statically to each active Cisco CallManager server in the cluster. In multi-site WAN deployments, calls between sites use MTP resources only if one of the two endpoints is not capable of using a low bit-rate (LBR) codec such as G.729. Otherwise, both endpoints use the LBR codec, and no MTP is used.
Application Scenarios
This section examines where and when the MTP and transcoding resources are used within the following three enterprise IP telephony deployment models plus a fourth application scenario:

Single-site deployments consist of one or more call processing agents within a single site, with no voice traffic carried over the IP WAN. Multi-site WAN deployments with centralized call processing consist of a single call processing agent that provides service for many sites connected through an IP WAN.
5-9
77303
Conf
Xcode
Multi-site WAN deployments with distributed call processing consist of call processing agents residing at each of several remote sites connected through an IP WAN. IP PSTN access is another scenario that requires MTP resources, and it applies to all of the preceding deployment models.
Single-Site Deployments
In a single-site deployment, there is no need for transcoding because there are no low-speed links to justify the use of a low bit-rate (LBR) codec. Some MTP resources might be required in the presence of a significant number of non-H.323v2 compliant devices such as older versions of Microsoft NetMeeting or certain video devices. Another case in which MTP resources might be needed is that of a single site accessing the PSTN via an IP PSTN provider (see IP PSTN Access, page 5-12).
Multi-Site WAN Deployments with Centralized Call Processing

In a centralized call processing deployment, the Cisco CallManager cluster and the applications (such as voice mail and IVR) are located at the central site, while several remote sites are connected through an IP WAN. The remote sites rely on the centralized Cisco CallManagers to handle their call processing. Because WAN bandwidth is typically limited, calls are configured to use a low bit-rate codec, such as G.729, when traversing the WAN. See Figure 5-3. Voice compression between IP phones is easily configured through the use of regions and locations in Cisco CallManager. A region defines the type of compression (for example, G.711 or G.729) used by the devices in that region, and a location specifies the total amount of bandwidth available for calls to and from devices at that location. However, some Cisco Catalyst conferencing services and some applications (such as Cisco IP IVR, Cisco Personal Assistant, and Cisco IP Integrated Contact Distribution) currently support only G.711, or uncompressed, connections. These situations require either MTP transcoding or IP-to-IP voice gateway functionality.
Figure 5-3 Transcoding for the WAN with Centralized Call Processing
VM/UM Server CallManager G.711 only Cluster

M
Router/GW IP IP Xcode IP WAN
Router/GW IP
Compressed Call Leg G.711 Call Leg DSP Farm Xcode

77304
5-10
EDCS-197018
Chapter 5
Cisco CallManager uses media resource groups (MRGs) to enable sharing of MTP and transcoding resources among the Cisco CallManager servers within a cluster. In addition, when using an LBR codec (for example, G.729) for calls that traverse different regions, the transcoding resources are used only if one (or both) of the endpoints is unable to use the LBR codec. This means that, even with G.711-only applications at the central site and H.323 gateways at the remote sites, the gateways are not always required to go through a transcoder.
Note
The MTP and transcoding resources must be located at the central site with the Cisco CallManager cluster because they cannot be configured in a location for call admission control. In summary, Cisco CallManager provides the following features:

Optimum utilization of the transcoding resources through resource sharing across the Cisco CallManager cluster Efficient utilization of the resources through dynamic allocation of transcoding resources only when required by one or both of the endpoints
Multi-Site WAN Deployments with Distributed Call Processing

In distributed call processing deployments, several sites are connected through an IP WAN. Each site contains a Cisco CallManager cluster that can, in turn, follow the single-site model or the centralized call processing model. A gatekeeper may be used for call admission control between sites. Because WAN bandwidth is typically limited, calls between sites are configured to use an LBR codec (such as G.729) when traversing the WAN. H.323v2 intercluster trunks are used to connect Cisco CallManager clusters. Cisco CallManager also supports compressed voice call connections through the MTP service if a hardware MTP is used. (See Figure 5-4.) A distributed call processing deployment might need transcoding and MTP services for the following reasons:

Some endpoints (for example, Cisco Personal Assistant, Cisco IP-IVR, Cisco IP Auto-Attendant, Cisco IP Intelligent Call Distribution) cannot use an LBR codec. Some endpoints (for example, video endpoints) do not support the H.323v2 features.
5-11
Figure 5-4
Intercluster Call Flow with Transcoding
Region A G.711 only IVR CallManager A

M
Region B CallManager B
M
IP
Router/GW IP WAN
Router/GW
IP
IP Xcode Transcoding Region BW M atrix A to A = G.711 A to B = G.729 Xcode Co m pressed Call Leg G.711 Call Leg = DSP Fa rm Xcode
IP
Regi on BW M atrix
77306
B to B = G.711 B to A = G.729
Cisco CallManager uses media resource groups (MRGs) to enable sharing of MTP and transcoding resources among the Cisco CallManager servers within a cluster. In addition, for calls across intercluster trunks, MTP and transcoding resources are used only when needed, thus eliminating the need to configure the MTP service for applications that do not support LBR codecs. The following characteristics apply to distributed call processing deployments:

Only the intercluster calls that require transcoding will use the MTP service. For example, if both endpoints of a call are capable of using a G.729 codec, no transcoding resources will be used. Sharing MTP resources among servers within a cluster provides more efficient resource utilization.
IP PSTN Access
The fourth application scenario for MTP and transcoding resources involves a service provider that provides its customers with access to an IP PSTN, instead of the traditional PSTN. In such a scenario, the gatekeepers reside in the service provider network. In order to simplify the dial plan, each customer is required to use an MTP to anchor its calls, so that the individual IP addresses assigned to the endpoints can be hidden. The service providers central office can then relay through the traditional PSTN and/or provide IP connectivity to other customers. Figure 5-5 illustrates this deployment model.
5-12
EDCS-197018
Chapter 5
Transcoding, Conferencing, and MTP Resources Conferencing Resources
Figure 5-5
IP PSTN Access Example
IP
IP DSP Other Customer Gatekeeper(s)
V
IP PSTN
V V V
IP
PSTN s.
V
Central Office
77307
IP DSP Customer Site
Note that the customer site in Figure 5-5 can use any of the previous three deployment models: single site, multi-site WAN with centralized call processing, or multi-site WAN with distributed call processing. The H.323 trunk from the customer site to the IP PSTN must be configured with MTP so that the endpoint IP addresses remain masked. Thus, all external calls use the MTP resources. However, MTP resources can be shared within the Cisco CallManager cluster to achieve more efficient use of the resources.
Conferencing Resources
As stated previously, the Cisco IP Telephony solution supports both software and hardware conference bridges. All conference bridges (both hardware and software) that are under the control of Cisco CallManager use Skinny Client Control Protocol (SCCP) to communicate with Cisco CallManager. The software conference bridge is provided by the Cisco IP Voice Media Streaming Application, while the hardware conference services are provided by the voice services module in the Catalyst 4000 and 6000 series switches and the DSP farm in the Cisco VG200 voice gateway. Table 5-2 lists the maximum number of conference participants for each type of conference bridge device and codec.
5-13
Chapter 5 Conferencing Resources
Table 5-2
Maximum Number of Conference Sessions Per Device Type
Device Type Cisco Catalyst 4000 WS-X4604-GWY Cisco Catalyst 6000 WS-6608-T1 or WS-6608-E1
Maximum Number of Participants for G.711 only

Maximum Number of Participants for G.729 only

Maximum Number of Participants for all GSM NA 192 participants total per module 24 per port 6 per conference bridge 30 participants total 6 per conference bridge
24 participants total 6 per conference bridge 256 participants total per module 32 per port 6 per conference bridge 90 participants total 6 per conference bridge 24 participants if on the same server as Cisco CallManager 48 participants if running on a standalone server
16 participants total 6 per conference bridge 256 participants total per module 32 per port 6 per conference bridge 90 participants total 6 per conference bridge
Cisco VG200 DSP Farm NM-HDV-DSP Software conference bridge (Cisco IP Voice Media Streaming Application)
NA
NA
Cisco CallManager allocates a conference bridge from a conferencing resource that is registered with the Cisco CallManager cluster. Both hardware and software conferencing resources may register with Cisco CallManager at the same time, and Cisco CallManager can allocate and use conference bridges from either resource. Cisco CallManager does not distinguish between the types of conference bridges when it processes a conference allocation request. Cisco CallManager allocates a unicast conference bridge when a user presses the Confrn or MeetMe soft key on their phone. Unicast conference bridges can be used for both Ad Hoc and Meet-Me conferences. An Ad Hoc conference is established by using the Confrn soft key or button on the phone. The person who sets up the conference is referred to as the conference controller. The conference controller adds each participant to the conference, and therefore has complete control over who joins the conference. Once the conference controller adds a participant to the conference, the participant cannot be forced to leave the conference. The conference participants may drop out of the conference any time they desire by hanging up the phone. Also, beginning with Cisco CallManager Release 3.2, the conference controller can drop the last party from a conference call. As long as there are two or more participants remaining in the conference, the conference bridge is still active, and the conference call is maintained. When an Ad Hoc conference has only one remaining participant, the conference call is terminated, and the remaining participant is disconnected. There are several variations on the basic method of setting up a conference, but a conference controller always establishes an Ad Hoc conference. The conference controller sets up the conference by pressing the Confrn button during a call, calling a third person, and then pressing the Confrn button a second time to allocate a conference bridge and stream the respective media. The conference controller can continue to add participants to the conference until either the conference bridge is out of resources or the maximum number of participants specified in the system configuration are added. The maximum number of participants per Ad Hoc conference is six. A Meet-Me conference is established by using the MeetMe soft key or button on the phone. The person who sets up the conference is referred to as the conference controller. Unlike an Ad Hoc conference, the Meet-Me conference does not give the conference controller complete control over who joins the conference. The Meet-Me conference controller selects one of the Meet-Me conference numbers from the range specified for the Cisco CallManager node that is controlling the call. The conference controller
5-14
EDCS-197018
Chapter 5
then initiates the Meet-Me conference by selecting the MeetMe button on the IP phone and entering the Meet-Me conference number. Once the conference is established, anyone who calls that particular Meet-Me conference number is immediately connected to the conference. The maximum number of participants per Meet-Me conference bridge is six, and it does not support scheduling features. Figure 5-6 depicts the configuration of a Meet-Me bridge in Cisco CallManager. For scalable Meet-Me conferencing and for scheduling features, use the Cisco Conference Connection or other third-party H.323 conferencing systems (refer to the conferencing system product documentation for details).
Figure 5-6 Configuring a Meet-Me Conference in Cisco CallManager
Software Conferencing Resources

The software conference service is the Cisco IP Voice Media Streaming Application, and it runs on any approved platform for Cisco CallManager. (See the chapter on Call Processing with Cisco CallManager for a list of approved platforms.) This application can be configured to operate and register with Cisco CallManager as three different device types: software conference bridge, media termination point (MTP), and music on hold (MOH) server. The Cisco IP Voice Media Streaming Application uses the IP Voice Media Streaming Driver to do real-time voice media streaming. This application also obtains the configuration information both for itself and for the IP Voice Media Streaming Driver. Because the software conference bridge supports only G.711 codecs, it is best suited for single-site deployments, where transcoding is not needed for conference calls. The software conference bridge can support 24 participants if it is on the same server as Cisco CallManager, or 48 participants if it is on a standalone server. It is a relatively scalable solution for a software conferencing service that does not require scheduling features. Software conference bridges have the following characteristics:

Support for G.711 (a-law or mu-law) Maximum of 6 participants per conference call All low bit-rate (LBR) calls must be transcoded prior to joining the conference call
5-15
Hardware Conferencing Resources

To scale IP telephony systems in large enterprise environments, hardware conferencing is required. DSP resources in the Cisco VG200 voice gateway and voice modules for the Cisco Catalyst 4000 and 6000 series switches provide the hardware conferencing features needed for large systems, and they support the following characteristics:
Through the use of media resource groups (MRGs) and media resources group lists (MRGLs), Cisco CallManager permits sharing of the hardware conference ports among the Cisco CallManager servers in a cluster. Cisco CallManager uses Skinny Client Control Protocol (SCCP) to communicate with the VG200 and Catalyst 4000 and 6000 conference bridges, but the gateway services on those platforms use Media Gateway Control Protocol (MGCP).
Catalyst 4000 Conferencing Services

The Catalyst 4000 voice service module, the WS-X4604-GWY, can support up to four simultaneous conference calls of six callers each. On the Catalyst 4000, only G.711 (uncompressed) calls join a conference call. When the conferencing service registers with Cisco CallManager using Skinny Client Control Protocol (SCCP), it indicates that only G.711 voice calls can be connected. If any compressed calls request to join a conference call, Cisco CallManager connects them to a transcoding port first to convert the compressed voice call to G.711.
Note
If all conference participants are G.729 endpoints, a corresponding number of transcoding sessions must be established before the streams can join the conferencing DSP. If the transcoding resources are being provided by the same Catalyst 4000 voice service module, this limits the supported number of conference calls per module to 16 participants total (with a maximum of 6 callers per conference call). Once the G.711 connections are associated with a particular conferencing session, the call is converted to a time-division multiplexing (TDM) stream and passed to the summing logic, which combines the streams. The WS-X4604-GWY module sums only the three dominant speakers. It determines dominance primarily by voice volume, not including any background noise, and it dynamically adjusts for the dominant speakers. The WS-X4604-GWY module can functions as a PSTN gateway as well as a hardware conference bridge. To the configure the Catalyst 4000 DSP farm for conferencing resources, enter the following CLI commands:
interface Loopback0 ip address 10.10.10.1 255.255.255.255 ! voicecard sccp manager 10.10.10.4 port 2000 voicecard sccp manager 10.10.10.5 port 2000 voicecard sccp local Loopback0 voicecard conference
The WS-X4604-GWY module requires its own local IP address to associate with Cisco CallManager for control signalling purposes. For redundancy, the appropriate Cisco CallManagers can also be specified as primary, secondary, and tertiary, if needed. Figure 5-7 illustrates the WS-X4604-GWY module, and Table 5-2 lists the codecs and conferencing capabilities that it supports.
5-16
EDCS-197018
Chapter 5
Figure 5-7
Catalyst 4000 Voice Service Module, WS-X4604-GWY
SIMM DSP Resources
= G.711 PSTN Gateway (96 calls)

77309 77310
= MTP Transcoding (16 calls) = Conferencing Resources (24 Participants)
To view the current conference configuration on a WS-X4604-GWY module, use the following CLI command:
show voicecard conference
Catalyst 6000 Conferencing Services

The Catalyst 6000 voice conferencing solution consists of two PSTN gateway modules, WS-X6608-T1 and WS-X6608-E1. These modules can support both compressed and uncompressed conference calls and also have the ability to support MTP and gateway functionality. After the WS-X6608 has been added as a T1 or E1 Cisco AVVID gateway, it can be configured on a per-port basis for conferencing services. The WS-X6608 can mix all conference call participants irrespective of codec type, and it can transcode and mix the conference streams on the same DSP port. Table 5-2 lists the codecs and conferencing capabilities supported by the WS-X6608 module. Figure 5-8 illustrates one possible configuration for the module, with three ports configured for MTP transcoding, three ports for conferencing, and two ports for PSTN gateway functionality.
Note
A single conference bridge cannot span multiple ports.

Figure 5-8
MTP/Transcoding MTP/Transcoding
Catalyst 6000 Voice Service Module, WS-X6608

PSTN T1/E1 G.711 PSTN T1/E1 G.711 MTP/Transcoding
To view the current port configuration on the WS-X6608 module, use the following CLI command
sh port voice active
Conferencing
Conferencing
Conferencing
5-17
Cisco VG200 Conferencing Services

The Cisco Voice Gateway 200 (VG200) can be equipped with an optional DSP Farm network module to provide hardware-based conferencing and transcoding DSP services in a single rack unit (RU). This module is supported by Cisco IOS Release 12.1(5)YH1 or later. The DSP Farm can contain up to five SIMMs, each of which contains three DSPs, for a total of 15 DSPs maximum. The DSP Farm registers with Cisco CallManager using Skinny Client Control protocol (SCCP). DSP resources may be shared among Cisco CallManagers in a cluster through the use of media resource groups and lists. The following considerations apply to the VG200-DSP when used for conferencing services:
A maximum of 15 conference calls (with a maximum of 6 participants each) are supported for G.711 and G.729 endpoints. Dedicated transcoding resources are not needed even if the conference endpoints use different codecs. A maximum of 5 conference calls (with a maximum of 6 participants each) are supported for GSM-only endpoints. This is referred to as mixed-mode conferencing, and it needs additional DSPs for transcoding. The VG200 supports call preservation during a switchover to a secondary Cisco CallManager upon disconnect from the primary Cisco CallManager. You can use Cisco IOS CLI commands to allocate the DSP channels between conferencing, MTP, and transcoding.
To configure the VG200-DSP for conferencing only, use the following Cisco IOS CLI commands:
VG200-DSP(config)#dspfarm confbridge maximum sessions 15 VG200-DSP(config)#dspfarm VG200-DSP(config)#sccp ccm 10.10.10.100 priority 1 VG200-DSP(config)#sccp ccm 10.10.10.101 priority 2 VG200-DSP(config)#sccp local FastEthernet0/0 VG200-DSP(config)#sccp
If you anticipate that any of the conference calls will involve a GSM endpoint, allocate a transcoding DSP resource using the following command:
VG200-DSP(config)#dspfarm confbridge maximum mixed-mode sessions 3
The preceding command allows a maximum of 3 of the 60 total endpoints to use a GSM codec in the conference call.
Note
If you have already configured transcoding resource for independent transcoding sessions, you do not have to configure mixed mode conferencing explicitly because the DSP channels needed for a GSM call will be allocated dynamically from the transcoding DSPs. See Cisco VG200 MTP and Transcoding Services, page 5-7, for more details. The VG200-DSP supports the following features:

For G.711, 10 and 20 ms packets are supported for conferencing and transcoding. For G.729, 10, 20, and 30 ms packets are supported for conferencing and transcoding. The same DSP can support a conference call involving G.711 (20 ms) and G.729 (30 ms) endpoints. Microsoft NetMeeting is not supported because it uses 32 ms packets.
5-18
EDCS-197018
Chapter 5
Provisioning Conference Resources

Provisioning for conference resources has the same considerations and mechanism as provisioning for MTP and transcoding resources. See Provisioning MTP and Transcoding Resources, page 5-8, for details. In addition to the general guidelines for provisioning media resources, Cisco recommends that you provide the following minimum conferencing resources for your users:

Ad Hoc conferencing resources for at least 5% of the user base Meet-Me conferencing resources for at least 5% of the user base
For example, in a system supporting 200 users, you should allocate at least 10 (5% x 200) conference ports and 10 Meet-Me conference numbers (or patterns). This allocation would be able to accommodate 10 conference bridges with a maximum of 6 participants each, or 20 conference bridges with 3 participants each, and so forth.
Application Scenarios
This section examines where and when conferencing resources are used within the following three enterprise IP telephony deployment models:

Single-site deployments consist of one or more call processing agents within a single site, with no voice traffic carried over the IP WAN. Multi-site WAN deployments with centralized call processing consist of a single call processing agent that provides service for many sites connected through an IP WAN. Multi-site WAN deployments with distributed call processing consist of call processing agents residing at each of several remote sites connected through an IP WAN.
Single-Site Deployments
In a single-site deployment, no voice traffic travels over the IP WAN, and only one type of codec (usually G.711) is used. Therefore, this type of deployment does not require transcoding resources for conference calls, so you can use software conferencing. If more conferencing capacity is needed, you can add hardware conferencing resources.
Multi-Site WAN Deployments with Centralized Call Processing

In a centralized call processing model, most resources are localized at the central site, thus requiring use of the WAN for basic MTP, transcoding, and conferencing services. Because most remote WAN sites use LBR codecs across the WAN, conference calls in a centralized call processing model generally require transcoding resources as well. A hardware conferencing resource is the ideal choice in this scenario. All centralized call processing deployments use the locations mechanism in Cisco CallManager to provide call admission control. Cisco CallManager uses locations in conjunction with regions to define the characteristics of a network link. Regions define the type of compression used on the link, and locations define the amount of available bandwidth for the link. Figure 5-9 depicts a typical centralized call processing model with locations that are constrained by the amount of bandwidth allocated for voice calls. Because of the bandwidth limitations, the regions in this configuration use a low-bit-rate codec such as G.729. Each LBR call uses approximately 24 kbps instead of the 80 kbps required for a G.711 call.
5-19
Figure 5-9
Locations-Based Call Admission Control for Centralized Call Processing Deployments
Central Site
IP
IP Conf
M M M
Location 1
PSTN Remote sites
WAN
IP
IP
IP
IP
Location 2
Location 3
Media Resource Groups and Lists

Through the use of media resource groups and lists in Cisco CallManager, you can provide conferencing resources at the remote sites, thus minimizing bandwidth usage on the WAN. (See Figure 5-10.) Call admission control based on locations is still required to ensure that WAN bandwidth is not oversubscribed.
5-20
77311
EDCS-197018
Chapter 5
Figure 5-10 Localized Conferencing Resources in a Centralized Call Processing Deployment
Central site CallManager cluster X Branch PSTN

M M M M M
IP IP A IP B
Conf
IP WAN
V
MRG2 MRG3
IP
IP
Conf Conf
Conf
77312
MRG1
Conf
In Figure 5-10, the phones at the remote branch site are assigned a media resource group list (MRGL) that contains the media resource group MRG1, which in turn contains the conference bridge resource at that site. This configuration allows for conferencing within that site without using any WAN bandwidth. For example, assume Phone X calls Phone A, and Phone A conferences Phone B. At this point, conferencing resources are requested by Cisco CallManager to host the conference call. Because of the MRG and MRGL configuration, Cisco CallManager selects the conference bridge at the branch site for this conference call.
Media Resource Allocation in Cisco CallManager

It is imperative to understand how Cisco CallManager allocates resources in a media resource group (MRG). As noted previously, an MRG is part of a media resource group list (MRGL), and the MRGL is associated with a device pool. When allocating resources, Cisco CallManager first selects the appropriate MRG according to the order specified in the MRGL. Within an MRG, resources are listed alphabetically by name regardless of the order in which you added the resources to the MRG, and Cisco CallManager allocates resources from the MRG in the order listed (that is, alphabetically). Therefore, if you require prioritized allocation of a resource (such as hardware conference bridges before software conference bridges), you have to name those resources properly in the MRGs and/or configure the appropriate MRGLs to define the desired order. For example, Figure 5-11 illustrates an MRG with hardware and software conference bridges listed in alphabetical order. In this scenario, all software conference bridges follow the naming convention CFB_<Cisco CallManager hostname>, and all hardware conference bridges are named CFB<MAC address>. When sorted alphabetically, all the software conference bridges appear before the hardware conference bridges in the MRG. Therefore, Cisco CallManager allocates the selected software conference bridges before the hardware conference bridges in this example.
5-21
Figure 5-11 Configuring a Media Resource Group
As an alternative to the solution in Figure 5-11, you could configure separate MRGs for hardware and software conference bridges, and place the MRGs in an MRGL in the order desired. Cisco CallManager would then allocate resources according to the order specified in the MRGL. Cisco CallManager tries to balance the load across the resources in the MRGL by picking the least used resource to allocate next.
Multi-Site WAN Deployments with Distributed Call Processing

In distributed call processing deployments, several sites are connected through an IP WAN. Each site contains its own call processing entity, such as a Cisco CallManager cluster, and can in turn follow the single-site model or the centralized call processing model. A gatekeeper may be used for call admission control between sites. Also in this case, WAN bandwidth is typically limited, so inter-site calls are usually configured to use a low bit-rate codec (such as G.729) when traversing the WAN. With conferencing across multiple Cisco CallManager clusters, it is important to keep in mind that the identity of the conference initiator determines which conferencing resources are going to be allocated for the conference call. Figure 5-12 provides an example of how conferencing resource allocation works across different Cisco CallManager clusters.
5-22
EDCS-197018
Chapter 5
Figure 5-12 Localized Resources for a Distributed Call Processing Deployment
Site 1 CallManager cluster

M M M M M

M
PSTN
M M M
IP A IP B D
Conf Conf
IP C
IP WAN
V
IP
77314
In this example, two Cisco CallManager clusters at Site 1 and Site 2 are connected through an IP WAN and intercluster trunks. Each site has its own conferencing resources that are assigned to individual IP phones through MRGs and MRGLs. Assume that phone A at Site 1 calls phone C at Site 2 and then conferences phone D at Site 2. Because the conference initiator is controlled by the Cisco CallManager cluster at Site 1, the conference bridge allocated to this call is one located at Site 1. This means that there are now two streams traversing the WAN, one between phone A and phone C and another between phone A and phone D. If, on the other hand, the conference had been initiate by phone C, which is controlled by the Cisco CallManager cluster at Site 2, the call would have been assigned the conference bridge located at Site 2, and only one stream (between phone C and phone A) would have traversed the WAN. Note that when a conference call crosses multiple Cisco CallManager clusters, it is possible to have more than 6 conference participants on the same call. Consider the following example, based on Figure 5-12: Phone A at Site 1 sets up a 6-party conference call, which includes phone C at Site 2, using a conference bridge located at Site 1. Phone C can now set up another conference call for another 5 parties and join the two conferences together using a conference bridge located at Site 2 (assuming that there is sufficient bandwidth to accommodate all voice streams).
Note
If all resources in the MRGL are exhausted, Cisco CallManager looks for media resources in the default, or <None>, MRG.
5-23
5-24
EDCS-197018
C H A P T E R
Call Processing with Cisco CallManager

This chapter discusses the concepts, provisioning, and configuration of Cisco CallManager clusters. Clusters provide a mechanism for distributing call processing seamlessly across a converged IP network infrastructure to support IP telephony, facilitate redundancy, and provide feature transparency and scalability. This chapter covers the operation of clusters within both campus and WAN environments and proposes reference designs for implementation. The following sections cover these main topics:

Cluster Operation and Scalability Guidelines, page 6-1 Clustering Guidelines, page 6-12 Intercluster Communication, page 6-13 Survivable Remote Site Telephony (SRST), page 6-35
Cluster Operation and Scalability Guidelines

Beginning with Cisco CallManager Release 3.1, a cluster may contain as many as 12 servers, of which a maximum of six may run the Cisco CallManager service that provides call processing. The other servers may be configured as a dedicated database publisher, a dedicated Trivial File Transfer Protocol (TFTP) server, music on hold (MoH) servers, or Computer Telephony Interface (CTI) Managers. Media streaming applications (conference bridge or media termination point) may also be installed on a separate server that registers with the cluster. The media streaming servers are in addition to the maximum 12 servers allowed in a cluster. Figure 6-1 illustrates a typical Cisco CallManager cluster. The database publisher is used to make all configuration changes and also to produce call detail records. The TFTP server facilitates the downloading of configuration files, device loads (operating code), and ring types. MoH servers provide the music on hold, and the CTI Manager servers are used for the management of TAPI, JTAPI, or CTI devices. (CTI Manager is currently supported only as a co-resident service.) For large systems, Cisco recommends a dedicated database publisher and either a dedicated TFTP server or multiple load-balanced TFTP servers co-resident with Cisco CallManager. For smaller systems, the function of database publisher and the TFTP server can be combined. Table 6-1 provides guidelines for scaling devices with Cisco CallManager clusters. Dedicated or multiple co-resident MoH servers, are recommended for clusters that require many MoH streams. Further details can be found in the MoH chapter, available in a future release of this document.
Note
Standalone CTI Managers are not supported at this time.
6-1
Chapter 6 Cluster Operation and Scalability Guidelines
The following general guidelines apply to all clusters:

A cluster may contain a mix of server platforms, but the cluster may not contain a mixture of Cisco CallManager software versions. Within a cluster, a maximum of 6 servers may be enabled with the Cisco CallManager Service, and other servers may be used for more dedicated functions such as TFTP, database publisher, MoH, and so forth. All services that are not required on a server should be disabled to maximize the server's capabilities. For example, disabling Microsoft IIS on all servers except the database publisher. You may configure up to 800 CTI connections or associations per server, or a maximum of 3200 per cluster if they are equally balanced between servers. Refer to the CTI Applications Architecture and Design chapter for more information. You may have up to 500 H.323 (gateway and client) and digital MGCP gateway devices per cluster. All members of the cluster are normally within the same LAN or metropolitan area network (MAN). There are specific guidelines for a cluster spanning an IP WAN. See Clustering Over the WAN, page 6-19. Cisco CallManager Release 3.1 can support up to 500 H.323 calls per H.323 device, and Cisco CallManager Release 3.2 can support up to 1000.
Typical Cisco CallManager Cluster
Figure 6-1
This symbol represents Cisco CallManager installed on any supported server platform.
M
Publisher/TFTP server JTAPI IP-AA/IVR Conf

M M
Primary CallManagers
Voice mail server

M
Conf
Xcode
Backup CallManager
Xcode
V
Gateway
V
Gateway
6-2
76126
EDCS-197018
Chapter 6
Call Processing with Cisco CallManager Cluster Operation and Scalability Guidelines
Table 6-1
Scaling Recommendations for Cisco CallManager Clusters
Desired Number of IP Phones Within a Cluster 1000
Recommended Number of Cisco CallManagers Two servers total:

Maximum Number of IP Phones per Cisco CallManager 1000
Combined publisher, TFTP, and backup server One primary Cisco CallManager 2500 Combined publisher and TFTP server One primary Cisco CallManager One backup Cisco CallManager 2500 Combined publisher and TFTP server Two primary Cisco CallManagers One backup Cisco CallManager 2500 Database publisher TFTP server Four primary Cisco CallManagers Two backup Cisco CallManagers
2500
Three servers total:

5000
Four servers total:

10,000
Eight servers total:

The recommendations in Table 6-1 provide an optimum solution based on the largest approved server. It is possible to reduce the amount of redundancy, and hence use fewer servers. For small systems, you may combine the database publisher, TFTP server, and Cisco CallManager backup functions. The MoH server requirements were not considered in Table 6-1 because those requirements are dependant on the specific deployment. The maximum available device units on the largest server is 5000, including a maximum of 2500 IP phones. (See Device Weights, page 6-3.) Gateways and digital signaling processor (DSP) devices, such as transcoding and conferencing resources, consume additional device units. In the event that one of the Cisco CallManagers within the cluster fails, the maximum number of device units remains 5000 per server in the case of the largest servers.
Device Weights
Many types of devices can register with Cisco CallManager; for example, IP phones, voice mail ports, CTI (TAPI or JTAPI) devices, gateways, and DSP resources such as transcoding and conferencing. Each of these devices carries a different weight based on the amount of resources it requires from the server platform with which it is registered. The required resources include memory, processor, and I/O. Each device then consumes additional server resources during transactions, which are normally in the form of calls. For example, a device that makes only 6 calls per hour consumes fewer resources than a device making 12 calls per hour. As a common starting point, the base weight of a device is calculated with the assumption that it makes 6 or fewer calls per hour during its busiest hour, or 6 Busy Hour Call Completions (BHCC).
6-3
Table 6-2 shows the base weight for each of the device types, based on the consumption of memory and central processing unit (CPU) resources.
Table 6-2 Base Device Weights
Device type IP phone Analog MGCP ports Analog SCCP ports CTI route point CTI client port CTI server port CTI third-party control CTI agent phone H.323 client Intercluster trunk gateway H.323 gateway Digital MGCP T1gateway ports Digital MGCP E1gateway ports MoH stream Transcoding resource Media Termination Point (MTP) (software) Conference resource (hardware) Conference resource (software)
2. Includes the associated IP phone.
2 2
Weight per Session or Voice Channel 1 3 1 2 2 2 3 6 3 3 3 3 3 10 3 3 3 3
Session or DS0 per Device 1 Varies Varies Varies 1 1 1 1 Varies Varies Varies 24 30 20 Varies 24 Varies 24
Cumulative Device Weight 1 3 per DS0 1 per DS0 Varies1 2 2 3 6 3 per call 3 per call 3 per call 72 per T1 90 per E1 200 3 3 per session 72 4 3 per session 72 4
1. Cumulative weight of CTI route point depends on the associated CTI ports used by the application. 3. When MoH is installed on the same server as Cisco CallManager, the maximum number of streams is 20. 4. When installed on the same server as Cisco CallManager, the maximum number of sessions is 24.
As mentioned, the base weight of each device is calculated using 6 or fewer BHCC. As the quantity of BHCC increases, so also does the number of transactions the servers are required to process and, therefore, the weight of the device on that platform. Each device requiring more than 6 BHCC has a multiplier applied to its base weight. The multiplier is calculated by dividing the BHCC by 6 and rounding up to the nearest whole number. For Example, an IP phone that is making 15 BHCC would have a multiplier of 3 (15/6 = 2.5, rounded up to 3). The total weight of the IP phone with 15 BHCC is equal to its base weight multiplied by 3.
Note
The multiplier is applied only to station or client devices and not devices that are a media resource or gateway. Table 6-3 illustrates the effect of the BHCC multiplier.
6-4
EDCS-197018
Chapter 6
Table 6-3
Effect of BHCC Multiplier
0 to 6 BHCC Multiplier Example IP phone Example CTI client port 1 1 2
7 to 12 BHCC 2 2 4
13 to 18 BHCC 3 3 6
19 to 24 BHCC 4 4 8
25 to 30 BHCC 5 5 10
The total number of device units that a single Cisco CallManager can control depends on the server platform, as indicated in Table 6-4.
Table 6-4 Maximum Number of Devices per Server Platform
Server Platform Characteristics Cisco MCS-7835 (All Models) Pentium III (733-1266MHz), 1-2GB RAM Cisco MCS-7830 Pentium PIII (500MHz), 1GB RAM Cisco MCS-7830 Pentium PIII (500MHz), 512MB RAM Cisco MCS-7825-1133 Pentium PIII (1.133GHz), 1GB RAM Cisco MCS-7825-800 Pentium PIII (800MHz), 512MB RAM Cisco MCS-7822 Pentium PIII (550MHz), 512MB RAM Cisco MCS-7820 Pentium PIII (500MHz), 512MB RAM Cisco SPE 310 Pentium III (700MHz), 512MB RAM Compaq DL380 All Cisco approved models Compaq DL320 All Cisco approved models IBM xSeries 340 All Cisco approved models IBM xSeries 330 All Cisco approved models
Maximum Device Units per Server 5000 3000 1000 2000 2000 1000 1000 2000 5000 2000 5000 2000
Maximum IP Phones per High Availability Server Platform 1 2500 1500 500 1000 1000 500 500 1000 2500 1000 2500 1000 Yes Yes Yes No No No No No Yes No Yes No
1. A high availability server supports redundancy for both the power supplies and the hard disks.
Note
The maximum supported non-redundant installation on platforms that are not highly available is 500 IP phones.
6-5
The maximum number of IP phones that can register with a single Cisco CallManager is 2500 on the largest server platforms, even if only IP phones are registered. To calculate the number of IP phones that can register with a Cisco CallManager in a specific deployment, subtract the weighted value of non-IP phone resources from the maximum number of device units allowed for that platform. The maximum number of IP phones may be lower than this calculated number, depending on the call volume per phone. In the case of the largest servers, the maximum number of device units is 5000. The co-resident CTI Manager allows a maximum of 800 CTI connections or associations per server, or a maximum of 3200 CTI connections or associations per cluster when they are equally shared between the four active Cisco CallManager servers. Associations are defined as devices that have been associated with a particular user in the Cisco CallManager User configuration. CTI route points require some additional consideration. The base weight is 2, but the multiplier is based on the number of BHCC. To calculate the BHCC of a route point, we need to know how many calls we can expect to redirect to other ports through the route point. For example, in a typical IP IVR application, the IP IVR is expected to handle 10 simultaneous calls. The configuration for this requires a CTI route point and 10 CTI ports. If each IP IVR port expects 6 BHCC, then the route point can expect to redirect 6 calls per hour for each port. This is a total of 60 calls per hour for the route point in this case. The multiplier for a CTI route point is calculated by taking the sum of the BHCC for all the ports associated with the CTI route point, dividing that sum by 6, and rounding up to the nearest whole number. For additional information on CTI route points, see the chapter on CTI Applications Architecture and Design. Standalone media resource servers may be configured as part of the cluster, and they typically provide higher performance than their co-resident equivalents. Do not run the Cisco CallManager Service on any standalone resource server. Table 6-5 indicates the capacity of each resource server.
Table 6-5 Maximum Media Resource Sessions per Server Platform
Standalone Server Platform
Music on Hold
Conference Bridge 128 128 128 128 128 128 128 128 128
Media Termination Point (MTP) 48 48 48 48 48 48 48 48 48
Cisco MCS-7835 (All Models) 250 Pentium III (733-1266MHz), 1-2GB RAM Cisco MCS-7830 Pentium PIII (500MHz), 1GB RAM Cisco MCS-7830 Pentium PIII (500MHz), 512MB RAM Cisco MCS-7825-1133 Pentium PIII (1.133GHz), 1GB RAM Cisco MCS-7825-800 Pentium PIII (800MHz), 512MB RAM Cisco MCS-7822 Pentium PIII (550MHz), 512MB RAM Cisco MCS-7820 Pentium PIII (500MHz), 512MB RAM Cisco SPE 310 Pentium III (700MHz), 512MB RAM Compaq DL380 All Cisco approved models 50 50 50 50 50 50 50 250
6-6
EDCS-197018
Chapter 6
Table 6-5
Maximum Media Resource Sessions per Server Platform (continued)
Standalone Server Platform Compaq DL320 All Cisco approved models IBM xSeries 340 All Cisco approved models IBM xSeries 330 All Cisco approved models
Music on Hold 50 250 50
Conference Bridge 128 128 128
Media Termination Point (MTP) 48 48 48
The device weights outlined in this section provide a design guideline for ensuring an expected level of performance for normal operating configurations. Higher levels of performance may be achieved by disabling or reducing other functions that are not directly related to processing calls. Increasing some of these functions may also have an impact on the call processing capabilities of the system. Some of these functions may include tracing, call detail recording, highly complex dial plans, and other services that are co-resident on the server.
Server Memory Requirements

Highly complex dial plans can include multiple line appearances, many partitions, calling search spaces, route patterns, translations, route groups, route lists, extensive use of Call Forward, co-resident services, and other co-resident applications. All of these functions can consume additional memory resources within the Cisco CallManager server. To improve performance, you can install additional certified memory in the server, up to the maximum supported for the particular platform.
Intracluster Communication
There are two primary kinds of communication within a Cisco CallManager cluster. (See Figure 6-2.) The first is a mechanism for distributing the database that contains all the device configuration information. The configuration database (Microsoft SQL 7.0) is stored on a publisher server and replicated to the subscriber members of the cluster. Changes made on the publisher are communicated to the subscriber databases, ensuring that the configuration is consistent across the members of the cluster, as well as facilitating spatial redundancy of the database. The second intracluster communication is the propagation and replication of run-time data such as registration of devices, locations bandwidth, and shared media resources. This information is shared across all members of a cluster running the Cisco CallManager Service, and it assures the optimum routing of calls between members of the cluster and associated gateways. Lightweight Directory Access Protocol (LDAP) directory information is also replicated between all servers in a cluster. The LDAP directory is replicated by the publisher to all other servers. Cisco CallManager may be integrated into a corporate LDAP directory, such as Microsoft's Active Directory or Netscape Directory. The replication is then dependant on the integration method deployed and is outside the scope of this document. For more information on directory integration, refer to the chapter on Directory Access for Cisco IP Telephony Endpoints.
6-7
Figure 6-2
Intracluster Communications
Intra-Cluster Communication Signaling (ICCS)

Dedicated publisher
M M M M M
SQL and directory replication

Dedicated publisher
M
Dedicated TFTP server

M M M M M
Dedicated TFTP server

M
Subscribers
Subscribers
Cisco CallManager Redundancy

Within a cluster, most registered devices can be assigned a prioritized list of up to three Cisco CallManagers with which it can register for call processing. IP phones, CTI ports, CTI route points, and shared resources (such as gateways, transcoding, and conferencing) are all capable of using this redundancy scheme. Peer-to-peer protocols such as H.323 also facilitate redundancy using other mechanisms, which may include gatekeepers and prioritized lists. Figure 6-3 depicts the redundancy scheme using three Cisco CallManagers.
Figure 6-3 Cisco CallManager Redundancy Group
M
Primary Secondary Tertiary

76128
IP
Each device maintains active Transmission Control Protocol (TCP) sessions with its primary and secondary Cisco CallManagers. This configuration facilitates switchover in the event of failure of the primary Cisco CallManager. Upon restoration of the primary, the devices revert to their primary Cisco CallManager. The restoration time and point will vary with device type and configuration. CTI connections to Cisco CallManager require the configuration of a primary and secondary CTI Manager on the external device to provide failover from one server to another. The CTI Manager maintains the redundancy of the individual CTI ports and CTI route points for the external CTI device. A highly available Cisco CallManager solution can be built using multiple servers in a cluster to provide spatial redundancy. Servers should be connected to different Ethernet switches and different power feeds with an uninterruptible power supply (UPS) to maximize this design. The use of server platforms with additional redundancy features, such as multiple power supplies and RAID Hard Disk systems, further increases the system availability.
6-8
EDCS-197018
76127
Chapter 6
Services such as CTI Manager, TFTP server, MoH server, and other media resources may be enabled on multiple servers within the cluster. The distributing of the services with correct configuration to utilize them also increases the availability and scalability of the cluster.
Note
Cisco highly recommends the use of at least two servers, along with the redundancy mechanisms provided by the Cisco CallManager application, to provide the expected high availability of such a system.
Redundancy Group Configuration

You can design the system to provide call processing redundancy by configuring Cisco CallManager redundancy groups. A Cisco CallManager redundancy group is a prioritized list of up to three Cisco CallManagers. Individual devices are then assigned to a specific Cisco CallManager redundancy group. A Cisco CallManager redundancy group is a subset of a cluster, and all members of a redundancy group are also members of a cluster. The following recommendations apply to the configuration of redundancy groups and are the maximum number of IP phones per cluster using the largest servers. Lower capacity clusters can be built using the same guidelines, with fewer IP phones and other devices. See Table 6-4 for further information.
Cisco CallManager cluster for up to 1000 IP phones:

Server A is the database publisher, TFTP server, and backup Cisco CallManager. Server B is the primary Cisco CallManager for all registered devices.
In this configuration, only a single Cisco CallManager redundancy group is required for servers A and B.
Cisco CallManager cluster for up to 2500 IP phones:

Server A is a dedicated database publisher and TFTP server. Server B is the primary Cisco CallManager for all registered devices. Server C is the backup Cisco CallManager for all registered devices.
In this configuration, only a single Cisco CallManager redundancy group is required for servers B and C.
Cisco CallManager cluster for up to 5000 IP Phones:

Server A is a dedicated database publisher and TFTP server. Server B is the primary Cisco CallManager for IP phones 1 through 2500. Server C is the primary Cisco CallManager for IP phones 2501 through 5000. Server D is the backup Cisco CallManager for all registered devices.
In this configuration, two Cisco CallManager redundancy groups are required for servers BD and CD.
Cisco CallManager cluster for up to 10, 000 IP phones:

Server A is a dedicated database publisher. Server B is a dedicated TFTP server (or may be distributed on other servers). Server C is the primary Cisco CallManager for IP phones 1 through 2500. Server D is the primary Cisco CallManager for IP phones 2501 through 5000. Server E is the backup Cisco CallManager for IP phones 1 through 5000.
6-9
Server F is the primary Cisco CallManager for IP phones 5001 through 7500. Server G is the primary Cisco CallManager for IP phones 7501 through 10,000. Server H is the backup Cisco CallManager for IP phones 5001 through 10,000.
In this configuration, four Cisco CallManager redundancy groups are required for servers CE, DE, FH and GH. Figure 6-4 illustrates this configuration. Triple redundancy is also possible in this case by configuring the redundancy groups as CEH, DEH, FHE and GHE.
Figure 6-4 Redundancy Groups
To 2,500 IP phones Optional dedicated publisher and TFTP server

M
To 5,000 IP phones Dedicated publisher and TFTP server
To 10,000 IP phones
M
Dedicated publisher and TFTP server 1 to 2500 2501 to 5000
Backup Publisher, backup, and TFTP server' or backup only Primary CM 1 to 2500
M M
M M
Backup
M
M M
1 to 2500 2501 to 5000 Backup

M
M M
5001 to 7500
76129
7501 to 10000
Note
In the event of a Cisco CallManager failure, calls might be dropped and might need to be re-established.
Device Pool Configuration

You can use device pools to scale and simplify the distribution of Cisco CallManager redundancy groups. A device pool allows you to assign the following primary attributes globally to devices:

Region Required only if multiple voice codecs are used within an enterprise. Date/Time Group Specifies date and time zone for a device. Cisco CallManager Group Specifies a prioritized list of up to three Cisco CallManagers, which can be used for call processing redundancy.
Figure 6-5 shows an example of a device pool configuration page. The calling search space for auto-registration is relevant only if auto-registration of IP phones is enabled. This calling search space can be used, for example, to prohibit auto-registered phones from accessing the Public Switched Telephone Network (PSTN). Auto-registration is a valuable tool for the initial provisioning of IP phones.
6-10
EDCS-197018
Chapter 6
Figure 6-5
Device Pool Configuration
In Figure 6-5, a device pool called SJC_Campus_Phones is configured with the following characteristics:

It is assigned the region SJC_Campus. It is assigned to the appropriate date/time group. It is assigned the Cisco CallManager redundancy group ABC.
A second device pool (not shown) called Branch_1 is configured with the following characteristics:

It is assigned the region Branch 1. This region contains all devices located in the Branch_1 location. It is assigned to the appropriate date/time group for the geographical location of that site. It is assigned the Cisco CallManager redundancy group CBA, where Cisco CallManager C is the primary, B is the secondary, and A is the tertiary. This configuration allows for some load balancing between subscribers.
Once the two regions have been configured, we can configure which codec(s) are allowed within the region (SJC_Campus or Branch 1), or intra-region, and between the sites (across the WAN between the two locations), or inter-region. Figure 6-6 illustrates the configuration of the Branch 1 region, with the following characteristics:

Intra-region communication uses G.711. Inter-region communication uses G.729 across the WAN.
76130
6-11
Chapter 6 Clustering Guidelines
Figure 6-6
Region Configuration
The exact clustering model and device pool configurations depend on the deployment model used. However, typical device pool configurations have the following characteristics:
Single-site cluster with no voice connectivity to the WAN

Device pool configurations are based only on Cisco CallManager redundancy groups.
Single-site cluster with voice connectivity to the WAN (Voice over IP Long Distance, VoIP_LD or IP PSTN)
Device pools are configured as above, but with the addition of regions for codec selection. Each
cluster could have a G.711 and G.729 region per Cisco CallManager redundancy group.
Total device pools = (Number of regions) x (Number of Cisco CallManager redundancy
groups).
Multi-site WAN with centralized call processing

This configuration uses a minimum of one Cisco CallManager redundancy group per site and a
possible maximum of four. It also uses one G.711 region per site for intra-site calls. Inter-site calls use G.729.
Total device pools = (Number of regions) x (Number of Cisco CallManager groups per site)
Clustering Guidelines
All members of a Cisco CallManager cluster are normally interconnected via a LAN or MAN. Cisco CallManager releases 3.1 and 3.2 allow for clustering over the IP WAN under specific conditions outlined later in Clustering Over the WAN, page 6-19. The following considerations apply to clusters when configuring an IP telephony network:

Maximum of 12 servers per cluster Maximum of 20,000 device units per cluster
6-12
76131
EDCS-197018
Chapter 6
Call Processing with Cisco CallManager Intercluster Communication
Maximum of 2500 registered IP phones per Cisco CallManager server, including devices registered under failure conditions Maximum of 6 servers with the Cisco CallManager Service running Switched infrastructure (shared media is not supported)
Within a switched campus infrastructure, you can generally assume that the bandwidth is over-provisioned and under-subscribed for voice applications. This bandwidth availability depends upon appropriate design and capacity planning within the campus in addition to the establishment of a trust boundary and the required queuing. There is no requirement for call admission control within a campus cluster. Cisco CallManager servers should be distributed within the campus to provide spatial redundancy and resiliency. Many metropolitan sites and campus buildings may have only a single conduit providing IP connectivity to other members of the cluster. In this case, if IP connectivity fails, local call processing must be maintained by means of a local server. In cases where diverse routing of fiber cable negates the requirement for a local Cisco CallManager, all call processing could be located in one or more data centers. Gateway resources for PSTN access should likewise be placed strategically to provide the highest possible availability. Resources such as transcoding and conferencing DSPs are shared within a Cisco CallManager Release 3.1 or 3.2 cluster. Once again, where fault tolerance is required, these resources require duplication, and spatial redundancy is recommended. You can achieve these objectives by positioning the resources in strategically placed multi-layer switches.
Intercluster Communication
This sections discuss intercluster communications, and it addresses issues in cluster provisioning for isolated campus deployments, multi-site WAN deployments with distributed call processing, multi-site WAN deployments with centralized call processing, and clustering over the WAN. The distributed architecture of a Cisco CallManager cluster provides the following primary benefits for call processing:

Spatial redundancy Resiliency Availability Survivability
In addition, a cluster provides transparent support of user features across all devices in the cluster. This enables distributed IP telephony to span an entire campus or high-speed metropolitan area network (MAN) with full features. Intercluster communication provided by H.323v2 permits a subset of the features to be extended between clusters. The following features are currently available between clusters:

Basic call setup G.711, G.729, and G.723 calls Multiparty conference Call hold Call transfer
6-13
Chapter 6 Intercluster Communication
Call forward Calling line ID Music on hold Calling name and number Redirected dialed number identification service (RDNIS) for centralized voice mail
Features currently unavailable between clusters include:

Call park and call pickup Shared line appearances Tone on hold Message waiting indicator (MWI) (Cisco Unity has additional functionality to allow for centralizing the voice mail system.)
Cluster Provisioning for the Campus

Where the requirement for a campus network exceeds 10,000 users, additional clusters are required. Similarly, if local call processing in each site or building requires more than the maximum number of Cisco CallManagers permitted in one cluster, additional clusters are needed. Communication between clusters is achieved using standards-based H.323 signaling. With a large campus or MAN, where bandwidth is typically over-provisioned and under-subscribed, intercluster call admission control is not required. Figure 6-7 demonstrates this connectivity between clusters within a local area environment.
6-14
EDCS-197018
Chapter 6
Figure 6-7
Campus Intercluster Communication Using H.323
Cluster 2
M
1 Backup 2
M
Route groups Cluster 1 Backup 1

M M M
Publisher 3 Backup 4
M M
M M
Publisher
M
526-xxxx Cluster 3
Backup 3
M
M M
1
M
4 525-xxxx
M M
2 Backup Publisher
M
M M
3
M
4 Backup 527-xxxx
76132
In Figure 6-7, the circled lines represent the H.323 intercluster links to each server in a cluster. The cluster on the left has six intercluster trunks defined to each of the two clusters on the right. The six intercluster trunks target all possible servers that are running the Cisco CallManager service (that is, the subscriber servers). This configuration provides total redundancy in the event of loss of IP connectivity to any member of the other cluster. Cisco recommends limiting intercluster configuration to three peers. In the majority of situations, this is sufficient to provide adequate resiliency without incurring long call setup delays in the event that many servers are unreachable. (At worst, the call will time out and fail before all Cisco CallManagers are attempted.) For deployments where a gatekeeper is used, Cisco recommends a single H.323 connection (the AnonymousDevice) per cluster. You can implement redundancy by assigning a Cisco CallManager group to the gatekeepers device pool. Cisco CallManager does not require the use of a media termination point (MTP) to allow supplementary services for H.323 devices. Cisco CallManager uses the "empty capabilities set" of H.323v2 to facilitate the opening and closing of logical channels between H.323 devices such as Cisco CallManager clusters and Cisco IOS gateways running Cisco IOS Release 12.0(7)T or greater.
6-15
Clusters for Multi-site WAN with Distributed Call Processing

Where clusters are interconnected over a WAN, there is a pinch point for congestion between clusters, and the network should be engineered to accommodate the required volume of voice traffic. In such cases, some method of providing call admission control is required. Because clusters are interconnected using H.323, a Cisco IOS Multimedia Conference Manager (MCM) can be added to facilitate this gatekeeper function. Each cluster can be designated as a zone with a maximum configured bandwidth for voice calls. When using a gatekeeper, Cisco CallManager requests 128 kbps of bandwidth per G.711 intercluster call and 20 kbps of bandwidth per G.729a intercluster call. In general, Cisco recommends configuring only one type of codec for calls that traverse the WAN because this greatly simplifies the provisioning of bandwidth. The use of gatekeepers provides both inbound and outbound call admission control. Cisco CallManager releases 3.1 and 3.2 allow a maximum of 100 Cisco CallManagers clusters to register with a single gatekeeper. The use of multiple gatekeepers or directory gatekeepers allows hundreds of Cisco CallManager clusters to be interconnected. Redundancy for a cluster can be achieved by using the Hot Standby Routing Protocol (HSRP) between two gatekeepers. Gatekeeper call admission control is a policy-based scheme. It requires static configuration of available resources and is not aware of network topology. It is, therefore, necessary to restrict gatekeeper call admission control schemes to hub-and-spoke topologies with the redundant gatekeeper or gatekeepers (using HSRP) located at the hub. HSRP requires both gatekeepers to be on the same subnet to operate correctly. The WAN must be provisioned accordingly, and the voice priority queue must be dimensioned to support all admitted calls. Figure 6-8 illustrates this deployment model.
6-16
EDCS-197018
Chapter 6
Figure 6-8
Intercluster Communication Using Gatekeepers
Branch A CallManager cluster

M M M
Headquarters
M M
CallManager cluster
M M M
V
IP Gatekeeper PSTN Branch B CallManager cluster IP WAN
M M M
IP
IP
V
IP IP
IP
V
76133
IP
IP
IP
6-17
Clusters for Multi-site WAN with Centralized Call Processing

Cisco CallManager also provides locations-based call admission control that enables provisioning of branch and telecommuter solutions where remote call processing is acceptable. (See Figure 6-9.) In the event of an IP WAN failure that isolates the remote branch, backup call processing is available by using Survivable Remote Site Telephony (SRST) functionality that is available in selected Cisco IOS routers. (For additional information, refer to the Call Admission Control chapter.)
Figure 6-9 Locations-Based Call Admission Control
Branch 1 Central site IP

M M
IP Branch 2
V V
IP IP WAN
IP Branch 3
IP Branch N
76134
IP
In the scheme depicted in Figure 6-9, call processing is maintained only at the central site, and the devices at the branches are configured as belonging to a location. For example, remote site 1 might have 12 IP phones, each configured to be in the location Branch 1. Cisco CallManager is then able to track the used and unused bandwidth per location, and admit or deny WAN calls accordingly. With Cisco CallManager Release 3.1 and later, this scheme has been expanded to allow centralized call processing for as many as 10,000 remote IP phones and other devices. Prior to Cisco CallManager Release 3.1, only a single Cisco CallManager server could be active in a cluster. This restriction has been removed from Cisco CallManager Release 3.1 and later, allowing for 6 Cisco CallManagers in a cluster, with up to 4 of them active.
The Effects of Network Delay on Call Processing

In a centralized call processing deployment, Cisco CallManager is the central entity for all control information or signaling between devices. Although the media or voice packets do not pass through the Cisco CallManager, the signaling does. The media connections are controlled by Cisco CallManager and are therefore affected by any delay the network may introduce. When a call is answered, Cisco CallManager signals to each device in the call to start connecting the media paths for the voice traffic. When this signaling is delayed, the media paths take longer to set up, and some of the initial conversation can be lost. Generally, this affects only calls to analog or IP phones. Cisco applications such as IP IVR, Unity, and Personal Assistant wait until the media path is in place before playing out any audio message. Phone users invariably start to talk once they pick up the phone. This may result in the calling party missing the first part of the greeting. Minimizing the delay in the network and using Skinny Client Control Protocol (SCCP) or Media Gateway Control Protocol (MGCP) devices will minimize the effect on the media cut-through time. H.323 devices currently take twice as long as other devices to complete the media path, even with the same delay between Cisco CallManager and the end device.
6-18
EDCS-197018
Chapter 6
Clustering Over the WAN

You may deploy a single Cisco CallManager cluster across multiple sites that are connected by an IP WAN with QoS features enabled. Clustering over the WAN can support two types of deployments:
Local failover Local failover requires that you place the Cisco CallManager subscriber and backup servers at the same site, with no WAN between them. This deployment model is ideal for two or three sites with Cisco CallManager servers and a maximum of 5000 or 2500 IP phones per site, respectively. This model allows for up to 10,000 IP phones in the two-site configuration and 7,500 IP phones in the three-site configuration.
Remote failover Remote failover allows you to deploy the backup servers over the WAN. Using this deployment model, you may have up to four sites with Cisco CallManager subscribers and one or two sites containing the Cisco CallManager backup server. This deployment allows for up to 10,000 IP phones shared over the required number of sites.

These features make this solution ideal as a disaster recovery plan for business continuance sites or as a single solution for up to four small or medium sites.
WAN Considerations
For clustering over the WAN to be successful, you must carefully planned, designed, and implemented various characteristics of the WAN itself. The Intra-Cluster Communication Signaling (ICCS) between Cisco CallManager servers consists of many traffic types. The ICCS traffic types are classified as either priority or best effort. Priority ICCS traffic is marked with IP Precedence 3 (DSCP 26 or PHB AF31). Best-effort ICCS traffic is marked with IP Precedence 0 (DSCP 0 or PHB BE). The various types of ICCS traffic are described in Intra-Cluster Communications, page 6-20, which also provides further guidelines for provisioning. The following design guidelines apply to the indicated WAN characteristics:
Delay The maximum one way delay between any Cisco CallManager server for all priority ICCS traffic should not exceed 20 ms, or 40 ms Round Trip Time (RTT). Delay for other ICCS traffic should be kept reasonable to provide timely database and directory access. Measuring the delay is covered in Delay Testing, page 6-31. Propagation delay between two sites introduces 6 microseconds per kilometer without any other network delays being considered. This equates to a theoretical maximum distance of approximately 3000 km for 20 ms delay or approximately 1860 miles. These distances are provided only as relative guidelines and in reality will be shorter due to other delay incurred within the network.
Jitter Jitter is the varying delay that packets incur through the network due to processing, queue, buffer, congestion, or path variation delay. Jitter for the IP Precedence 3 ICCS traffic must be minimized using Quality of Service (QoS) features.
6-19
Packet loss and errors The network should be engineered for zero percent packet loss and errors for all ICCS, especially the priority ICCS traffic, because packet loss and errors will have adverse effects on the real-time call processing within the cluster.
Bandwidth Provision the correct amount of bandwidth between each server for the expected call volume, type of devices, and number of devices. This bandwidth is in addition to any other bandwidth for other applications sharing the network, including voice and video traffic between the sites. The bandwidth provisioned must have QoS enabled to provide the prioritization and scheduling for the different classes of traffic. For further information on bandwidth, see Bandwidth, page 6-29. The general rule of thumb for bandwidth is to over-provision and under-subscribe.
Quality of Service The network infrastructure, as with other deployments of the Cisco Architecture for Voice, Video, and Integrated Data (AVVID), relies on QoS engineering to provide consistent and predictable end-to-end levels of service for traffic. Neither QoS nor bandwidth alone is the solution; rather, QoS-enabled bandwidth must be engineered into the network infrastructure. QoS is described in further detail and with examples in Quality of Service (QoS), page 6-30.
Intra-Cluster Communications
In general, intra-cluster communications means all traffic between servers. There is also a real-time protocol called Intra-Cluster Communication Signaling (ICCS), which provides the communications with the Cisco CallManager Service process that is at the heart of the call processing in each server or node within the cluster. The intra-cluster traffic between the servers consists of the following (see Figure 6-10):
Database traffic from the SQL database that provides the main configuration information. The SQL database is replicated from the publisher server to all other servers in the cluster using Best Effort. The SQL traffic may be re-prioritized in line with Cisco AVVID QoS recommendations to a higher priority data service (for example, IP Precedence 1 if required by the particular business needs). An example of this is extensive use of extension mobility, which relies on SQL database configuration. Directory traffic from the Lightweight Directory Access Protocol (LDAP) directory provides user and application authentication and some additional specific user or application configuration information. LDAP traffic is sent Best Effort by default. ICCS real-time traffic, which consists of signalling, call admission control, and other information regarding calls as they are initiated and completed. ICCS uses a Transmission Control Protocol (TCP) connection between all servers that have the Cisco CallManager Service enabled. The connections are a full mesh between these servers. Because only six servers may have the Cisco CallManager Service enabled in a cluster, there may be up to five connections on each server. This traffic is priority ICCS traffic and is marked IP Precedence 3. CTI Manager real-time traffic is used for CTI devices involved in calls or for controlling or monitoring other third-party devices on the Cisco CallManager servers. This traffic is marked IP Precedence 3 and exists between the Cisco CallManager server with the CTI Manager and the Cisco CallManager server with the CTI device.
6-20
EDCS-197018
Chapter 6
Figure 6-10 Intra-Cluster Communications
Publisher
M
Publisher
M
Subscriber
M M M
Subscriber
M
Subscriber
Subscriber
SQL database and LDAP
CallManager ICCS
Local Failover Deployment Model

The local failover deployment model provides the most resilience for clustering over the WAN. Each of the sites in this model contains at least one primary Cisco CallManager subscriber and one backup subscriber. This configuration allows for either a two-site deployment with 5000 IP phones per site or a three-site deployment with 2500 IP phones per site. (See Figure 6-11.)
76136
Subscriber
Subscriber
Subscriber
Subscriber
6-21
Figure 6-11 Local Failover Model with Two Sites
Site A
Publisher/TFTP server
M
Site B
Sub A
M M
Sub B
M
Sub A
M M
Sub B
M
WAN
Gateway
MOH
Gateway
MOH
V
V
Xcode
IP Phone IP
Xcode
IP Phone IP

Configure each site to contain at least one primary Cisco CallManager subscriber and one backup subscriber. Configure Cisco CallManager groups and device pools to allow devices within the site to register with only the servers at that site under all conditions. Cisco highly recommends that you replicate key services (TFTP, DNS, DHCP, LDAP, and IP Phone Services), all media resources (conference bridges and MOH), and gateways at each site to provide the highest level of resiliency. You could also extend this practice to include a voice mail system at each site. Under a WAN failure condition, only sites without access to the publisher database might loose a small amount of functionality. Every 10,000 busy hour call attempts (BHCA) in the cluster requires 900 kbps of bandwidth for Intra-Cluster Communication Signaling (ICCS). This is a minimum bandwidth requirement, and bandwidth is allocated in multiples of 900 kbps. In addition to the real-time ICCS bandwidth, intracluster bandwidth is required for the SQL, CTI Manager, and LDAP traffic. The amount of additional bandwidth is dependant on the use of the system. For instance, the use of Extension Mobility increases the amount of SQL traffic between servers.
6-22
74360
TAPI SoftPhone
TAPI SoftPhone
EDCS-197018
Chapter 6
A maximum Round Trip Time (RTT) of 40 ms is allowed between any two servers in the Cisco CallManager cluster. This time equates to a 20 ms maximum one-way delay, or a transmission distance of approximately 1860 miles (3000 km) under ideal conditions. The local failover model requires Cisco CallManager Release 3.1 or later.

If calls are allowed across the WAN between the sites, then you must configure Cisco CallManager locations in addition to the default location for the other sites, to provide call admission control between the sites. If the bandwidth is over-provisioned for the number of devices, it is still best to configure call admission control based on locations. Because call admission control based on locations does not provide automatic failover to the PSTN, Cisco recommends that you over-provision the WAN for inter-site calls. As the delay increases between the Cisco CallManager servers, the bandwidth information shared between the servers for call admission control will also be delayed, possibly allowing additional calls to be set up until the ICCS bandwidth message arrives. This situation is a small risk because, even at full capacity, only a few additional calls might be set up before the bandwidth information arrives. To provide for this situation, Cisco recommends that you over-provision the priority queue for voice traffic by a few extra calls. For more information on call admission control, see the Call Admission Control chapter. To improve redundancy, Cisco recommends that you enable the Cisco Trivial File Transfer Protocol (TFTP) service on at least one of the Cisco CallManager servers at each location. You can run the TFTP service on either a publisher or a subscriber server, depending on the site. The TFTP server option must be correctly set on the DHCP servers for each site. If DHCP is not in use or the TFTP server is manually configured, you should configure the correct address for the site. Other services, which may affect normal operation of Cisco CallManager during WAN outages, should also be replicated at all sites to ensure uninterrupted service. These services include DHCP servers, DNS servers, corporate directories, and IP phone services. On each DHCP server, set the DNS server address correctly for each location. IP phones may have shared line appearances between the sites. The ICCS bandwidth provisioned between the sites allows for the additional ICCS traffic that shared line appearances generate. During a WAN outage, call control for each line appearance is segmented, but call control returns to a single Cisco CallManager server once the WAN is restored. During the WAN restoration period, there is extra traffic between the two sites. If this situation occurs during a period of high call volume, the shared lines might not operate as expected during that period. This situation should not last more than a few minutes, but if it is a concern, you can provision an extra 2 Mbps of bandwidth to minimize the effects.
Gateways
Normally, gateways should be provided at all sites for access to the PSTN. The device pools should be configured to register the gateways with the Cisco CallManager servers at the same site. Partitions and calling search spaces should also be configured to select the local gateways at the site as the first choice for PSTN access and the other site gateways as a second choice for overflow. Take special care to ensure emergency service access at each site. You can centralize access to the PSTN gateways if access is not required during a WAN failure and if sufficient additional bandwidth is configured for the number of calls across the WAN. For E911 requirements, additional gateways may be needed at each site.
6-23
Voice Mail
Music on Hold
Remote Failover Deployment Model

The remote failover deployment model provides flexibility for the placement of backup servers. Each of the sites contains at least one primary Cisco CallManager subscriber and may or may not have a backup subscriber. This allows for a deployment of three to six sites with IP phones and other devices normally registered with a maximum of four servers. (See Figure 6-12.)
Figure 6-12 Remote Failover Model with Four Sites
M
Publisher / TFTP
M M
IP IP WAN IP
IP
IP IP IP
IP
74361
6-24
EDCS-197018
Chapter 6

Configure each site to contain at least one primary Cisco CallManager subscriber and an optional backup subscriber if desired. You may configure Cisco CallManager groups and device pools to allow devices to register with servers over the WAN. Cisco highly recommends that you replicate key services (TFTP, DNS, DHCP, LDAP, and IP Phone Services), all media resources (conference bridges and MOH), and gateways at each site with IP phones to provide the highest level of resiliency. You could also extend this practice to include a voice mail system at each site. Under a WAN failure condition, only sites without access to the publisher database might loose a small amount of functionality. Every 10,000 busy hour call attempts (BHCA) in the cluster requires 900 kbps of bandwidth for Intra-Cluster Communication Signaling (ICCS). This is a minimum bandwidth requirement, and bandwidth is allocated in multiples of 900 kbps. In addition to the real-time ICCS bandwidth, intracluster bandwidth is required for the SQL, CTI Manager, and LDAP traffic. The amount of additional bandwidth is dependant on the use of the system. For instance, the use of Extension Mobility increases the amount of SQL traffic between servers. Signalling or Control Plane traffic requires additional bandwidth when devices are registered across the WAN with a remote Cisco CallManager server within the same cluster. A maximum Round Trip Time (RTT) of 40 ms is allowed between any two servers in the Cisco CallManager cluster. This time equates to a 20 ms maximum one-way delay, or a transmission distance of approximately 1860 miles (3000 km) under ideal conditions. The remote failover model requires Cisco CallManager Release 3.1 or later.

If calls are allowed across the WAN between the sites, then you must configure Cisco CallManager locations in addition to the default location for the other sites, to provide call admission control between the sites. If the bandwidth is over-provisioned for the number of devices, it is still best to configure call admission control based on locations. Because call admission control based on locations does not provide automatic failover to the PSTN, Cisco recommends that you over-provision the WAN for inter-site calls. As the delay increases between the Cisco CallManager servers, the bandwidth information shared between the servers for call admission control will also be delayed, possibly allowing additional calls to be set up until the ICCS bandwidth message arrives. This situation is a small risk because, even at full capacity, only a few additional calls might be set up before the bandwidth information arrives. To provide for this situation, Cisco recommends that you over-provision the priority queue for voice traffic by a few extra calls. For more information on call admission control, see the Call Admission Control chapter. To improve redundancy, Cisco recommends that you enable the Cisco Trivial File Transfer Protocol (TFTP) service on at least one of the Cisco CallManager servers at each location. You can run the TFTP service on either a publisher or a subscriber server, depending on the site. The TFTP server option must be correctly set on the DHCP servers for each site. If DHCP is not in use or the TFTP server is manually configured, you should configure the correct address for the site. Other services, which may affect normal operation of Cisco CallManager during WAN outages, should also be replicated at all sites to ensure uninterrupted service. These services include DHCP servers, DNS servers, corporate directories, and IP phone services. On each DHCP server, set the DNS server address correctly for each location.
6-25
IP phones may have shared line appearances between the sites. The ICCS bandwidth provisioned between the sites allows for the additional ICCS traffic that shared line appearances generate. During a WAN outage, call control for each line appearance is segmented, but call control returns to a single Cisco CallManager server once the WAN is restored. During the WAN restoration period, there is extra traffic between the two sites. If this situation occurs during a period of high call volume, the shared lines might not operate as expected during that period. This situation should not last more than a few minutes, but if it is a concern, you can provision an extra 2 Mbps of bandwidth to minimize the effects.
Gateways
Normally, gateways should be provided at all user sites for access to the PSTN. The device pools may be configured to allow the gateways to register with a remote Cisco CallManager server as backup if the local Cisco CallManager server is unavailable. Partitions and calling search spaces should also be configured to select the local gateways at the site as the first choice for PSTN access and the other site gateways as a second choice for overflow. Take special care to ensure emergency service access at each site. You can centralize access to the PSTN gateways if access is not required during a WAN failure and if sufficient additional bandwidth is configured for the number of calls across the WAN. For E911 requirements, additional gateways may be needed at each site.
Voice Mail
Music on Hold
Common Design Guidelines for Clustering over the WAN

This section provides general guidelines for provisioning the following components and features as they relate to clustering over the WAN:

Failover Between Subscriber Servers, page 6-27 Cisco CallManager Publisher, page 6-27 Call Detail Records (CDR), page 6-27 Call Admission Control, page 6-28 Centralized Call Processing., page 6-28 Bandwidth, page 6-29 Quality of Service (QoS), page 6-30 Delay Testing, page 6-31
6-26
EDCS-197018
Chapter 6
Error Rate, page 6-32 Server Upgrades and Installation, page 6-32 Troubleshooting, page 6-33
Failover Between Subscriber Servers

With Cisco CallManager Release 3.1 and later, failover behavior is dependant on the reachability of the publisher and the delay between the subscriber and the publisher. If the publisher is reachable, the subscriber will request the relevant device configuration records directly from the publisher during device registration. The round trip delay and the available bandwidth for the SQL database traffic will affect the speed of registrations. The effect of this is that failover for devices at remote locations to the publisher may experience delays of approximately 20 minutes before all devices on a full server complete the failover process. If the publisher is unreachable during failover, the subscriber will use its own most recent copy of the database for the configuration information. Because there is no incurred delay for the subscriber to access its own database, the failover time in this case is approximately 5 minutes for a full server.
Cisco CallManager Publisher

The publisher replicates a read-only copy of the master database to all other servers in the cluster. If changes are made in the publishers master database during a period when another server in the cluster is unreachable, the publisher will replicate the updated database when communications are re-established. During any period when the publisher is unreachable or offline, no changes can be made to the configuration database. All subscriber databases are read-only and may not be modified. Most normal operations of the cluster will not be affected during this period, including the following:

Call processing Failover Installation registration of previously configured devices
There are some features and functions that require access to the master database on the publisher because they make modifications to records and therefore need write access. The publisher is the only server in a Cisco CallManager cluster that has a read and write configuration database. The main features and functions that require access to the publisher for write access include:

Configuration additions, changes, and deletions Extension mobility User speed dials Cisco CallManager User page options requiring the database Cisco CallManager software upgrades Call Forward All
Call Detail Records (CDR)

Call detail records, when enabled, are collected by each subscriber and uploaded to the publisher periodically. During a period that the publisher is unreachable, the CDRs are stored on the subscribers local hard disk. When connectivity is re-established to the publisher, all outstanding CDRs are uploaded to the publisher.
6-27

Call admission control is required whenever the number of calls to and from an area or site needs to be controlled due to limited bandwidth for voice traffic. Cisco CallManager has two mechanisms for providing call admission control:
Locations Locations are an integral feature of Cisco CallManager, and they are used to define an area or site that requires bandwidth control. When a Cisco CallManager cluster is deployed across multiple sites, there will most likely be calls or media between the sites. Within a cluster the use of locations for call admission control is required to control the number of calls admitted across each WAN link. Locations require a hub-and-spoke topology, and the cluster must be deployed with this topology unless no calls or media are using the WAN. To implement the required topology, one site must be the hub site, and it is defined by the location None in Cisco CallManager Administration. All other sites are spokes. All devices must be assigned a location so that call admission control based on the locations can function correctly.
Note
Transcoders and media termination points (MTPs) always reside at the hub, or None location. Therefore, any devices that require transcoding or MTP resources should also be assigned to the hub, or None location.
Gatekeeper An H.323 gatekeeper is an external device that provides bandwidth control for intercluster trunks used between Cisco CallManager clusters as well as between other H.323 devices. The gatekeeper uses zones to define an area or site that requires bandwidth control. A Cisco CallManager cluster registers with the gatekeeper as a single endpoint in a single zone. Therefore, all calls via the gatekeeper to the Cisco CallManager cluster are considered to be within a single zone. Cisco recommends that all gatekeeper-controlled devices be placed within a single site to avoid the possibility of over-subscribing the WAN links to servers within the cluster at other sites.
Locations and gatekeepers both require a hub-and-spoke network because they both track bandwidth used to and from a location or zone. Both call admission control mechanisms are unaware of the actual path taken. Therefore, if a call actually traverses an intermediate location or zone, the call admission control mechanism does not account for this, and over-subscription may occur.
Centralized Call Processing.

Centralized call processing uses locations for call admission control, to control the number of calls to and from a remote site. As previously mentioned, locations require a hub-and-spoke topology and assume that the hub site is location None in Cisco CallManager Administration. Therefore, any remote sites that are deployed using centralized call processing must be spokes with respect to the site that is location None, or the hub site (Location 0) as depicted in Figure 6-13. Remote branches connected to any other location or site will cause locations-based call admission control to work incorrectly.
6-28
EDCS-197018
Chapter 6
Figure 6-13 Locations for a Centralized Call Processing Deployment
Location 0
M M M M M
Location 1
IP IP
Location 1 IP IP
Location 2
V V
=
IP IP Location 3
Location 0
Location 2
Location 3
Location 4 Location 4
76137
IP IP IP
IP
Bandwidth
The bandwidth required for the priority ICCS traffic depends on the busy hour call attempts (BHCA) of the entire cluster. For every 10,000 BHCA, a total of 900 kbps is required, and the minimum bandwidth requirement for ICCS is 900 kbps. Additional bandwidth is required for additional SQL and LDAP traffic. All other traffic, including calls that traverse the WAN, is in addition to this requirement. Cisco recommends that you provision at least 1.544 Mbps for intra-cluster traffic, which provides 900 kbps for priority ICCS and additional bandwidth for SQL database synchronization and LDAP transactions. In addition to the intra-cluster bandwidth, you must calculate any additional signalling traffic between devices and Cisco CallManager servers over the WAN. The amount of bandwidth will vary based on protocol and call rate (BHCA). Table 6-6 lists the minimum bandwidth required for priority ICCS traffic. Table 6-7 lists bandwidth requirements for signalling protocols that share the same queue as the priority ICCS traffic. Cisco AVVID QoS guidelines define all voice and video call signaling is tagged with IP Precedence 3 (DSCP 26 or PHB AF31), which is the same as the priority ICCS traffic. The queue defined for this class of traffic is the sum of the priority ICCS, voice, and video signalling and any other applications using this QoS class.
Table 6-6 Minimum Bandwidth Required for Priority ICCS Traffic
Cluster BHCA 10,000 20,000 30,000 40,000 50,000
Bandwidth in kbps for Priority ICCS Traffic 900 1800 2700 3600 4500
6-29
Table 6-6
Minimum Bandwidth Required for Priority ICCS Traffic (continued)
Cluster BHCA 60,000 70,000
Bandwidth in kbps for Priority ICCS Traffic 5400 6300
Table 6-7
Bandwidth Required for Voice and Video Signaling
Number of Devices Signaling over WAN 100 250 500 1000 2500 3200 5000 7500
Bandwidth (kbps) for IP Phones and Gateways at 10 BHCA (no CTI) 15 37.5 75 150 375 480 750 1125
Bandwidth (kbps) for CTI at 10 BHCA 23 57 113 225 563 720 N/A N/A
Bandwidth (kbps) for Inter-cluster Trunk Calls at 30 BHCA 12 28 56 112 280 359 N/A N/A
Table 6-7 provides a guideline for the bandwidth used by a number of devices at a specific BHCA. The higher the BHCA, the higher the bandwidth requirement. The bandwidth values in Table 6-7 are derived from the following equations:
For IP phones, SCCP devices, H.323 devices, and MGCP at 10 BHCA: Bandwidth in bps = 150 x (Number of IP phones and gateway ports)
For CTI (TAPI / JTAPI) devices. CTI Softphone, IVR and other CTI Applications at 10 BHCA Bandwidth in bps = 225 x (Number of CTI devices)
For intercluster trunks or virtual tie lines, per call at 30 BHCA: Bandwidth in bps = 112 x (Number of intercluster trunk calls)
Quality of Service (QoS)

This section provides an outline of the QoS requirements for the WAN when deploying a Cisco CallManager cluster over the WAN. For a more complete guide on deploying QoS in a Cisco AVVID network, refer to the documentation at http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/avvidqos/index.htm The voice and video media streams are tagged IP Precedence 5 and 4 respectively, which allows them to be admitted into a Priority Queue (PQ) via two separate policies that strictly enforce the bandwidth consumption. Any traffic that exceeds the configured bandwidth parameters is dropped. All other non-real time traffic (that is, not interactive voice or video media streams) is prioritized using Class Based Weighted Fair Queueing (CBWFQ). The scheduling of the class-based queues is weighted by the amount of bandwidth assigned. If more bandwidth is required than can be serviced by the queue, the overflow is sent as best effort. The correct provisioning of the PQ and the CBWFQs provides the predictable traffic characteristics required in a multiservice network.
6-30
EDCS-197018
Chapter 6
If the CBWFQ used by ICCS is shared with other traffic (for example, other voice signalling traffic), the total capacity should allow for ICCS traffic and the total bandwidth for the other signalling traffic over the WAN. The following is a partial configuration example to illustrate the principles of provisioning QoS in a Cisco IOS router. The first commands define an access list for all voice media packets that will be tagged with IP Precedence 5 (access list 100):
! ToS VoIP Media Stream Classification: either IP Prec or DSCP access-list 100 permit ip any any precedence 5 access-list 100 permit ip any any dscp ef !
The following access list is for all traffic tagged with IP Precedence 3 (access list 101):
! Priority ICCS Traffic and SCCP, MGCP and H.323 call control traffic. access-list 101 permit ip any any precedence 3 access-list 101 permit ip any any dscp 26
The next commands associate the access list for voice media (100) with a class called VoIP-RTP:
class-map VoIP-RTP match access-group 100
The following commands associate the access list for ICCS and voice signaling traffic (101) with a class called ICCS:
class-map ICCS match access-group 101
The following commands link the two classes with a default, best effort queue as a QoS policy called QoS-Policy-CoW:
policy-map QoS-Policy-CoW class VoIP-RTP priority 400 class ICCS bandwidth 2048 class class-default fair-queue
In the above policy, VoIP media traffic is allowed 400 kbps and is defined as a priority queue. The CBWFQ for ICCS is 2048 kbps. Once defined, the QoS policy can be applied to the desired WAN interface.
Delay Testing
The maximum Round Trip Time (RTT) between any two servers must not exceed 40 ms at any time. This time limit must include all delays in the transmission path between the two servers. Verifying the round trip delay using the ping utility on the Cisco CallManager server will not provide an accurate result. The ping is sent as a best-effort tagged packet and is not transported using the same QoS-enabled path as the ICCS traffic. Therefore, Cisco recommends that you verify the delay by using the closest network device to the Cisco CallManager servers, ideally the access switch to which the server is attached. Cisco IOS provides a extended ping capable to set the Layer 3 type of service (ToS) bits to make sure the ping packet is sent on the same QoS-enabled path that the ICCS traffic will traverse. The time recorded by the extended ping is the Round Trip Time (RTT), or the time it takes to traverse the communications path and return. The maximum RTT between any two Cisco CallManager servers is 40 ms, and therefore the maximum one-way delay would be 20 ms. This delay is critical to the performance of the call processing capabilities of the Cisco CallManager cluster and must be strictly enforced.
6-31
The following is an example of a Cisco IOS extended ping with the ToS bit (IP Precedence) set to 3:
A ccess_SW #ping Protocol [ip]: T arget IP address: 10.10.10.10 Repeat count [5]: D atagram size [100]: T im eout in seconds [2]: Extended com m ands [n]: y Source address or interface: T ype of service [0]: 3 Set D F bit in IP header? [no]: V alidate reply data? [no]: D ata pattern [0xA BCD ]: Loose, Strict, Record, Tim estam p, Verbose[none]: Sweep range of sizes [n]: T ype escape sequence to abort. Sending 5, 100-byte ICM P Echos to 10.10.10.10, tim eout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip m in/avg/m ax = 1/2/4 m s
Error Rate
The expected error rate should be zero. Any errors, dropped packets, or other impairments to the IP network can have an impact to the call processing performance of the cluster. This may be noticeable by delay in dial tone, slow key or display response on the IP phone, or delay from off-hook to connection of the voice path. Although Cisco CallManager will tolerate random errors, they should be avoided to avoid impairing the performance of the cluster.
Server Upgrades and Installation

The Cisco CallManager server may be installed and upgraded over the WAN if connectivity to the publisher is available and adequate bandwidth is provisioned for the SQL traffic to allow for the expected upgrade period. The amount of bandwidth required will dependant on the size of the publishers database. A typical upgrade carried out over a 1.544 Mbps WAN, with no other traffic and a 40 ms RTT (20 ms one-way delay), can completed in approximately the same time as a subscriber located on the LAN with the publisher. A indication of the bandwidth required can be based on the size of the SQL database located on the publishers hard disk, with a period of 30 minutes to transmit the records over the WAN. Cisco CallManager Release 3.2(2) introduces ICCS version checking of its peers. This mechanism allows the Cisco CallManager Service to communicate only with other servers in the cluster that use the same ICCS version. During an upgrade of a Cisco CallManager cluster that is distributed over a WAN, devices may be unable to communicate with other devices on a Cisco CallManager server that is operating with a different version of software. Essentially, the cluster will be segmented until the upgrade process is complete at all sites involved with the distributed cluster.
6-32
EDCS-197018
Chapter 6
Troubleshooting
If the Cisco CallManager subscribers in a cluster are experiencing impairment of the ICCS communication due to higher than expected delay, errors, or dropped packets, some of the following symptoms may be observed:

IP phones, gateways, or other devices on a remote Cisco CallManager server within the cluster may temporarily be unreachable. Calls may be disconnected or may fail during call setup. Users may experience longer than expected delays before hearing dial tone. Busy Hour Call Completions (BHCC) may be low. The ICCS (SDL session) may be reset or disconnected. The following shows a Cisco CallManager SDL trace of a remote server VO30-7835-8 going Out of Service and the devices that were reachable by that server being removed as available destinations:
RemoteCMOutOfService: Ip address: VO30-7835-8 remoteClusterId VO30-7835-1-Cluster|<CLID::VO30-7835-1Cluster><NID::VO30-7835-2> |Delete entries from SsManagerTable, now this table has 75 entries|<CLID::VO30-7835-1-Cluster><NID::VO30-78352><CT::0,0,0,0.0><IP::><DEV::> |Delete entries from FeatActTable, now this table has 70 entries|<CLID::VO30-7835-1-Cluster><NID::VO30-78352><CT::0,0,0,0.0><IP::><DEV::> |Digit analysis: Remove remote pattern /5000020 , PID: 7:34:1|<CLID::VO30-7835-1-Cluster><NID::VO30-78352><CT::0,0,0,0.0><IP::><DEV::> |Digit analysis: Remove remote pattern /5000066 , PID: 7:34:2|<CLID::VO30-7835-1-Cluster><NID::VO30-78352><CT::0,0,0,0.0><IP::><DEV::>
. . .
|Digit analysis: Remove remote pattern /5001002 , PID: 7:34:106|<CLID::VO30-7835-1-Cluster><NID::VO30-78352><CT::0,0,0,0.0><IP::><DEV::>
In summary, perform the following tasks to troubleshoot ICCS communication problems:

Verify the delay between the servers Check all links for errors or dropped packets Verify that QoS is correctly configured Verify that sufficient bandwidth is provisioned for the queues and across the WAN to support all the traffic
Media Resources
Media resources include conferencing, transcoding, media termination points (MTPs) and Music on Hold (MoH) servers. Prior to Cisco CallManager Release 3.1, media resources could not be shared between Cisco CallManager servers within a cluster. Each Cisco CallManager server required the media resource to be registered to the server before it was available for its use. This precluded another server in the cluster from using the media resource unless the first Cisco CallManager server failed and its media resource failed over to the other server. With Cisco CallManager Release 3.1 and later, all media resources are shared within the cluster, thus allowing the same levels of redundancy with greatly improved efficiency.
6-33
By default all media resources are placed is a default group that is used by any devices that do not have a media resource group list (MRGL) set. Media resources placed into a media resource group (MRG) are removed from the default group and then need to be placed into an MRGL before a device may utilize them. Using the Services menu, you can configure the MoH, conference bridge, transcoding, and MTP media resources. Once configured, the media resources are added to an MRG in logical groupings. The grouping may be based on media resource type, physical location, or device pool assignment. The selection order of media resources in an MRG is alphabetical. MRGs are configured under the Services menu. Media resources may be a member of a single MRG or multiple MRGs. Once the MRGs have been configured, they can be added to a media resource group list (MRGL), which is also configured through the Services menu. MRGs in an MRGL are selected in the order of their assigned priority in the list. To provide a desired order for which media resources are selected, you can use specific alphabetical names or you place each media resource in an individual MRG. MRGLs are assigned to devices either through device pools (for groups of devices) or on the device configuration page (for individual devices). The device MRGL configuration has priority over the setting in the device pool associated with the device. Figure 6-14 illustrates an MRG, and Figure 6-15 illustrates the MRG being assigned to an MRGL.
Figure 6-14 Media Resource Group (MRG)
6-34
76138
EDCS-197018
Chapter 6
Call Processing with Cisco CallManager Survivable Remote Site Telephony (SRST)
Figure 6-15 Media Resource Group List (MRGL)
Cisco highly recommends that MRGLs contain MRGs with every type of media required. Each device pool configured within the Cisco CallManager cluster should be assigned an MRGL. All devices in a device pool have the same primary, secondary, and tertiary Cisco CallManager servers defined. The media resources used by that device pool also use the same failover redundancy.
Survivable Remote Site Telephony (SRST)

The centralized call processing deployment model allows you to deploy an IP telephony solution across multiple remote sites connected via an IP WAN, while centralizing administration and call processing functionality at a single site. For such deployments, Survivable Remote Site Telephony (SRST) provides high availability for the voice services at the remote sites by providing a subset of the call processing capabilities within the remote office router and enhancing the IP phones with the ability to re-home to the call processing functions in the local router if a WAN failure is detected. SRST is illustrated in Figure 6-16.
76139
6-35
Chapter 6 Survivable Remote Site Telephony (SRST)
Figure 6-16 Survivable Remote Site Telephony (SRST) Basic Operation
CallManager cluster
M M M M
CallManager cluster
M M
ISDN backup IP WAN
PSTN
ISDN backup IP WAN
PSTN
Voice traffic
Voice traffic
Normal operation
WAN failure
The SRST software operates by taking advantage of the keepalive packets emanating from both the centralized Cisco CallManager cluster and the remote site IP phones. During normal operations, Cisco CallManager receives keepalive packets from the IP phones. Cisco CallManager performs call setup and processing, call maintenance, and call termination. If the WAN link fails or the Cisco CallManager cluster becomes unreachable, the Cisco IP Phones detect that they are no longer receiving keepalive packets from Cisco CallManager. The Cisco IP Phones then register with the router. In this instance, the SRST software is automatically activated and builds a local database of all Cisco IP Phones attached to it (up to the limit supported on the router platform). The IP
6-36
74353
EDCS-197018
Chapter 6
Phones are configured to query the router as a backup call-processing source when the central Cisco CallManager does not acknowledge keepalive packets. The SRST router then performs call setup and processing, call maintenance, and call termination. When the WAN link is restored, the IP Phones detect keepalive packets from the central Cisco CallManager and revert to it for primary call setup and processing. As IP Phones re-home to Cisco CallManager, the SRST router purges its call processing database and reverts to standby mode. Calls in progress are not interrupted because they are managed by the router gateway function. Phones in use during WAN link recovery will re-home to Cisco CallManager after the calls terminate.
SRST Features and Requirements

SRST currently supports the following types of phones at the remote site:

Cisco 7910 IP Phones Cisco 7940 IP Phones Cisco 7960 IP phones Analog phones (connected to FXS ports on the SRST router)
SRST currently supports the following router interfaces:
WAN link types:

Frame Relay ATM Serial
PSTN trunk types:

T1 and E1 CAS XT, and Cisco IOS Release 12.2.8T adds PRI support ISDN BRI
SRST currently supports the following features for the remote site phones:

Extension-to-extension dialing Extension-to-PSTN dialing Primary line on phone Direct Inward Dial Direct Outward Dial Calling Party ID (Caller ID) Display Calling Party Name Display Speed Dialing Last Number Redial Transfer without consult Call Hold and Resume Multiple extensions per IP phone (depending on phone capabilities) Multiple line appearances (up to 24 appearances per system) Distinctive Ringing Extension Class of Service
6-37
Full inter-working with Cisco Gatekeeper functionality Billing Support (using Call Detail Recording) Hunt-stop support Tone on Hold Class of Restriction Forward to central-site voice mail across PSTN during Cisco CallManager fallback Simple automated attendant (AA) and Interactive Voice Response (IVR), based on Tool Command Language (TCL), on local gateway (SRST router) Transfer of Cisco endpoints across H.323 network Alias lists for single number to be designated for unregistered phones
The maximum number of IP Phones supported by SRST varies according to the branch router platform selected and the amount of memory available. Table 6-8 lists the maximum number of IP Phones supported by the various router platforms.
Table 6-8 Maximum number of IP Phones per Router Platform
Router Platform Cisco 1750 and 1751 Cisco IAD 2400 Cisco 2600 Cisco 3620 Cisco 3640 Cisco Catalyst 4224 Cisco Catalyst 4000 AGM Cisco 3660 Cisco 7200
Number of IP Phones Supported Up to 24
Number of Lines Available 96
Up to 48
192
Up to 144 Up to 480
288 960
SRST Design Considerations

The following expected behavior and design considerations apply to SRST during WAN failures:

If media resources (such as hardware conferencing resources or music on hold servers) are deployed at the remote sites, they become unavailable during WAN failures. If CTI-based applications (such as Cisco IP IVR or Cisco IP SoftPhone) are deployed at the remote sites, they become unavailable during WAN failures. IP phones at the remote site can transparently place calls to the other sites using the internal extensions. This assumes that the appropriate dial plan information has been configured in the SRST router. If voice mail is present, calls placed from IP phones at the central site to IP phones at the remote site using the internal abbreviated dialing are immediately redirected to voice mail. However, it is possible to reach the remote site users by dialing their full PSTN number.
6-38
EDCS-197018
Chapter 6
Calls from external PSTN callers or other IP phones at the remote site can be forwarded via the PSTN to the centralized voice mail system when the called party is busy or not answering. However, callers will hear the generic voice mail system prompt, and they will have to specify the called party extension before leaving a message. Figure 6-17 illustrates this scenario. Similarly, users at the remote site can retrieve their voice mail messages via the PSTN by simply pressing the Messages button on their IP phone. However, they will hear the generic voice mail system prompt, and they will have to specify their own extension before retrieving their messages. Figure 6-17 also illustrates this scenario.
Figure 6-17 SRST Interaction with a Centralized Voice Mail System
Central site CallManager cluster

M
Voice Mail Server
IP
X leaves message (generic prompt)
Remote site PSTN
IP IP IP
IP A IP
V
IP WAN
A checks voice mail (generic prompt)
The following example lists a basic Cisco IOS configuration for SRST:
call-manager-fallback access-code fxo 9 default-destination pattern 2001 dialplan-pattern 1 345. ip source-address 10.10.10.10 port 2000 keepalive 30 max-ephones 24 max-dn 48 voicemail 914085554800 call-forward busy 914085554800 call-forward noanswer 914085554800
In the preceding example, 10.10.10.10 is the IP address of the SRST router (typically the address of one of the Ethernet ports on the router). The default-destination pattern 2001 is used to forward all calls to unknown extensions within the DN range. The voicemail parameter specifies the PSTN number of the voice mail pilot to be programmed on the Messages button of the IP phones. The call-forward busy and noanswer parameters must also be programmed on the IP phones to forward calls correctly to voice mail through the PSTN.
76140
6-39
SRST with Automated Attendant

SRST also provides support for an automated attendant (AA) application that you can program using the Tool Command Language (TCL) Interactive Voice Response (IVR) application programming interface that is part of the Cisco IOS software running on the SRST router. This application is capable of handling inbound calls on FXO PRI ports and outbound calls on IP phones and analog phones connected to FXS ports. Through a TCL script configured on the SRST router, an external caller can hear the prompts, dial the digits, and then be transferred to the person whom the caller wishes to reach. For more information on TCL IVR Version 2.0, refer to the documentation available on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/tclivrv2.htm Figure 6-18 illustrates a typical application scenario for the automated attendant application in the SRST router.
Figure 6-18 SRST with Automated Attendant Application
Central site Normal operation CallManager cluster

M
IP-VIR Server
IP
Remote site
SRST router with TCL IVR PSTN
IP IP IP
IP IP
IP WAN
Central site WAN failure CallManager cluster

M
IP-VIR Server
IP
Remote site
SRST router with TCL IVR PSTN
IP IP IP
IP IP
IP WAN
6-40
76141
EDCS-197018
Chapter 6
In Figure 6-18, a centralized TCL IVR provides the automated attendant functionality and possibly other features such as store hours information and customer announcements. In this example, the TCL IVR automated attendant application is also running on the SRST router at the remote site, and the expected behavior is as follows:
During normal operation, calls from the remote site IP phones or PSTN calls via the remote site gateway are forwarded to the centralized TCL IVR by the TCL IVR automated attendant application running on the remote site SRST router. During WAN failures, calls from the remote site IP phones or PSTN calls via the remote site gateway are intercepted by the TCL IVR automated attendant application running on the SRST router at the remote site. This application can play prompts, collect digits, and place calls to the appropriate extensions. The prompts can be configured to faithfully reproduce those played by the centralized TCL IVR, thus providing the callers with the same look-and-feel.
The TCL IVR Version 2.0 automated attendant (AA) feature is currently supported by the following SRST router platforms:

Cisco 1750 and 1751 Cisco 2600 series Cisco 3600 series
The following example shows the Cisco IOS commands used to configure the SRST router:
call application voice TCL_AA call application voice TCL_AA call application voice TCL_AA call application voice TCL_AA call application voice TCL_AA call application voice TCL_AA ! dial-peer voice 2000 pots application TCL_AA port 1/0/0 forward-digits all flash/slot0:vespa_aa_srst_2.1.tcl language 1 en cm-pilot 8000 aa-pilot 2000 operator 1000 set-location en 0 flash:
In the preceding example, 8000 is the pilot number for the centralized TCL IVR. When WAN connectivity is lost and the centralized pilot number becomes unreachable, the local application and prompts are used.
6-41
6-42
EDCS-197018
C H A P T E R

Call admission control (CAC) is an important mechanism to protect the network, with Quality of Service (QoS) enabled, from being oversubscribed and unable to provide the level of service required for voice. A specific amount of priority bandwidth for voice must be provisioned on each given link in the path. Call admission control provides mechanisms to control the number of calls between two endpoints, thereby also enabling you to control the amount of bandwidth that is required between these two endpoints. This capability is key to maintaining voice quality for all existing calls and any new ones. Because the network is provisioned to carry a specific amount of voice traffic, exceeding this bandwidth will subject the voice traffic to delay, jitter, and possibly packet loss, resulting in unacceptable voice quality for all calls. Multi-site deployments of IP telephony require some form of call admission control for voice traffic that travels over the IP WAN, where bandwidth is typically limited. Voice traffic that travels over a LAN or a metropolitan area network (MAN) generally does not require call admission control because bandwidth is more readily available on those networks. Cisco CallManager uses two different mechanisms for call admission control, described in the following sections:
Call Admission Control with Cisco CallManager Locations, page 7-2 Use this type of call admission control for multi-site WAN deployments with centralized call processing. For additional information on centralized call processing, refer to the chapter on IP Telephony Deployment Models.
Call Admission Control with a Gatekeeper, page 7-4 Use this type of call admission control for multi-site WAN deployments with distributed call processing. Gatekeeper call admission control can be used with Cisco CallManager intercluster trunks or with H.323 Cisco IOS gateways. For additional information on distributed call processing, refer to the chapter on IP Telephony Deployment Models.
You can also design your network to use a third type of call admission control that relies on a physical limit to the number of calls that can be placed across a link. An example of this is a single gateway. Based on how many calls the gateway can physically connect from the PSTN, you can determine how many calls could be placed to the IP side of the gateway. This chapter also includes a section on Bandwidth Calculations, page 7-2, which describes the approximations used to calculate bandwidth usage for purposes of call admission control.
7-1
Chapter 7 Bandwidth Calculations
Bandwidth Calculations
This section provides the bandwidth figures used for the call admission control techniques described in this chapter. The values used here may not be the same as the actual bandwidth used on the network because the values shown here do not include the additional overhead for protocol headers used to transport the media. Bandwidth calculations for call admission control depend on the type of codec used for the call. Cisco CallManager uses the bandwidth values for each codec type as indicated in Table 7-1.
Table 7-1 Bandwidth Values Used for Call Admission Control
Codec Type Codec bit rate Cisco CallManager locations Cisco CallManager gatekeeper Cisco IOS H.323 gateways (old Cisco behavior)
1
G.711 64 kbps 80 kbps 128 kbps 64 kbps 128 kbps
G.729 8 kbps 24 kbps 20 kbps 64 kbps 16 kbps
Cisco IOS H.323 gateways (new ITU behavior)1
1. This behavior is configurable in Cisco IOS Release 12.2.2XA and later.
The additional protocol overhead can make a considerable difference in the amount of bandwidth actually used for the call. For example: When Cisco CallManager requests bandwidth from the gatekeeper during an admission request (ARQ) or bandwidth request (BRQ), it requests the maximum transmit and receive bandwidth. Therefore, for G.711 and G.729, it will use 128 kbps and 20 kbps respectively. L If, for example, the gatekeeper is configured to admit 256 kbps of bandwidth, it would allow two calls with G.711. When we factor in the IP, User Datagram Protocol (UDP), and Real-Time Transport Protocol (RTP) headers, bandwidth usage would be approximately 80 kbps per call in each direction, or a total of 160 kbps. If the same configuration is used and all the calls are G.729, the gatekeeper will admit 12 calls. With the overhead, the bandwidth usage would be approximately 24 kbps per call, or a total of 288 kbps in each direction. To maintain QoS in the WAN for this example, we would have to engineer the links to factor in this variance, resulting in under-subscription during the use of G.711 or heterogeneous use of codecs. The use of compressed RTP (cRTP) minimizes much of the overhead error; however, this is on a hop-by-hop basis, and each router interface that the call traverses must expand and compress the RTP packet. As the speed of the link and quantity of RTP traffic increase, the use of cRTP becomes less desirable.
Note
Use only one type of codec to simplify the design of your IP telephony network.
Call Admission Control with Cisco CallManager Locations

Cisco CallManager provides a simple mechanism know as locations for implementing call admission control in centralized call processing systems with a hub-and-spoke network topology. When configuring a device in Cisco CallManager, you assign it to a location. You also allocate the amount of bandwidth available for calls to or from each location.
7-2
EDCS-197018
Chapter 7
Call Admission Control Call Admission Control with Cisco CallManager Locations
The locations that you configure in Cisco CallManager are virtual locations and not real, physical locations. Cisco CallManager has no knowledge of the physical locations of devices. Therefore, if you move a device from one physical location to another, you must also update its location information in Cisco CallManager so that Cisco CallManager can correctly calculate bandwidth allocation for that device.
Note
Prior to Cisco CallManager Release 3.1, you could have only one primary (active) Cisco CallManager server in the cluster when using call admission control based on locations. With Cisco CallManager Release 3.1 and later, the locations bandwidth is shared among all Cisco CallManager subscribers in the cluster, thus enabling you to use the locations mechanism with any size cluster. Before assigning devices to locations, you have to define the locations and allocate the available for each one. To configure a location, as illustrated in Figure 7-1, select System > Location in Cisco CallManager Administration.
Figure 7-1 Defining a Location in Cisco CallManager
Figure 7-1 shows the configuration for the location Branch_1, with 256 kbps of available bandwidth. This location can support up to three G.711 calls (at 80 kbps per call) or ten G.729 calls (at 24 kbps per call) or a mixture of both. After defining the locations with their available bandwidth, you can assign devices to them. The types of devices you can assign to a location include IP phones, Computer Telephony Interface (CTI) ports, H.323 clients, CTI route points, conference bridges, Music on Hold servers, and gateways. Figure 7-2 shows the configuration for gateway Branch_1_GW assigned to location Branch_1. Cisco CallManager admits each call placed to or from this gateway if there is sufficient bandwidth available at Branch_1 to support the call. If Branch_1 does not have sufficient bandwidth to support the call, that call fails and the calling device receives a busy tone. If the calling device is an IP phone with a display, that device also displays the message Not Enough BW.
76106
7-3
Chapter 7 Call Admission Control with a Gatekeeper
Figure 7-2
Assigning a Device to a Location
When a call is placed from one location to another, Cisco CallManager deducts the appropriate amount of bandwidth from the available bandwidth at both locations. For example, if a device in Branch_1 places a G.711 call to a device in Branch_2, Cisco CallManager deducts 80 kbps from the available bandwidth at both branches. When the call has completed, Cisco CallManager returns the bandwidth to the affected locations. Call admission control does not apply to calls between devices within the same location.
Note
The locations mechanism does not provide automatic rerouting of calls to the Public Switched Telephone Network (PSTN). If a call fails due to insufficient bandwidth, the caller must redial the remote location using the PSTN access number, if one is available.
Call Admission Control with a Gatekeeper

In a distributed call processing system, you can implement call admission control with a Cisco IOS gatekeeper, also known as a Multimedia Conference Manager (MCM). The gatekeeper provides call admission control only for H.323 endpoints, which include Cisco IOS H.323 gateways and trunks between Cisco CallManager clusters (know as intercluster trunks).
7-4
EDCS-197018
76107
Chapter 7
Call Admission Control Call Admission Control with a Gatekeeper
The gatekeeper can also provide call routing if you design you dial plan to take advantage of this capability. This section describes the main features and general operations of a gatekeeper, and it is organized as follows:
Gatekeeper Operations, page 7-5

Gatekeeper Discovery, page 7-5 Registration Process, page 7-6 Admission Requests, page 7-7 Disengage Request, page 7-8 Bandwidth Requests, page 7-8 Technology Prefix, page 7-9 E.164 Address Resolution, page 7-9
ARQ Parsing Order, page 7-10

Cisco IOS Gatekeeper Commands, page 7-10 Debug Commands, page 7-11
Cisco CallManager Configuration, page 7-11

Gatekeeper Used for Call Admission Control, page 7-12 Gateway Configuration, page 7-13 Intercluster Trunk Gateways, page 7-16
Gatekeeper Operations
This section describes how a gatekeeper operates in conjunction with the endpoints connected to it.
Gatekeeper Discovery
An endpoint must first establish contact with the gatekeeper through a process known as gatekeeper discovery. (See Figure 7-3.) Gatekeeper discovery can happen automatically or manually. In automatic discovery, the endpoint sends a multicast gatekeeper request (GRQ), and any gatekeeper that can accept the request returns a gatekeeper confirm (GCF). If a gatekeeper cannot accept the request, it returns a gatekeeper reject (GRJ). Manual discovery requires you to configure the gatekeeper IP address or name in the endpoint device. The endpoint then sends a unicast GRQ to the gatekeeper. The gatekeeper returns a GCF to accept the request or a GRJ to refuse it. Once the endpoint has discovered the gatekeeper, the endpoint attempts to registers, as described in the next section.
Note
Cisco CallManager does not use gatekeeper discovery.
7-5
Figure 7-3
Gatekeeper Discovery
GRQ (1) GCF/GRJ (2)

76108 76109
H.323 Endpoint
Gatekeeper
Registration Process
Cisco IOS gatekeepers support two types of registration:

Full Registration, page 7-6 Lightweight Registration, page 7-7
An endpoint must always use a full registration during the initial registration process, but it may use lightweight registration to maintain registration. If an endpoint becomes unregistered with the gatekeeper, it must use full registration again.
Full Registration
Full registration requires the endpoint to register any E.164 address, H.323 ID, device type, and possible other parameters, every time it registers. These parameters involve an additional processing load on the gatekeeper every time an endpoint registers or renews its registration. The endpoint sends its time between registration renewals, or Time to Live (TTL), in the registration request (RRQ), and the gatekeeper may replace the value or return it unchanged. With Cisco IOS Release 12.1(5)T or later, you can configure the returned TTL value. A low TTL value can cause an excessive registration processing load on the gatekeeper. A high TTL value can cause the gatekeeper to be unaware that an endpoint has lost connectivity or has failed. Cisco recommends a TTL value of 30 to 300 seconds, depending on design requirements. When an endpoint sends a full registration request (RRQ) to the gatekeeper, the gatekeeper responds with a registration confirm (RCF) to accept or a registration reject (RRJ) to refuse. (See Figure 7-4.) The gatekeeper may refuse the registration for many reasons, such as duplicate E.164 or H323 IDs or ambiguous information.
Figure 7-4 Gatekeeper Registration
RRQ (1)
M
H.323 Endpoint
RCF/RRJ (2)
Gatekeeper
Registration has a finite life, so the endpoint must renew its registration by sending an RRQ prior to expiration of its TTL. If the TTL expires and the gatekeeper has not received an RRQ from the endpoint, that endpoint becomes unregistered.
7-6
EDCS-197018
Chapter 7
Lightweight Registration
Lightweight registration reduces the processing load on the gatekeeper during registration renewal. The endpoint sends an RRQ containing a keepalive bit and the minimum required registration information. If the gatekeeper accepts the renewal, it returns an RCF and resets the TTL timer. If the gatekeeper rejects the renewal, it sends an RRJ, and the endpoint becomes unregistered. Once an endpoint becomes unregistered, it must start the gatekeeper discovery and registration process again.
Unregistration
At any time, either an endpoint or a gatekeeper may cancel a registration with an unregistration request (URQ). An endpoint or gatekeeper normally sends an unregistration request during changes to its configuration. The responding device sends an unregistration confirmation (UCF) to accept the request. (See Figure 7-5.) If an unregistered endpoint sends an URQ to a gatekeeper, the gatekeeper responds with a unregistration reject (URJ) to indicate an error. (See Figure 7-6.) Cisco IOS gatekeepers, Cisco IOS gateways, and Cisco CallManager all support lightweight registration.
Figure 7-5 Gatekeeper Initiated Unregistration Request
URQ (1) UCF (2)

76110 76111
H.323 Endpoint
Gatekeeper
Figure 7-6
Endpoint Initiated Unregistration Request
URQ (1)
M
H.323 Endpoint
UCF/URJ (2)
Gatekeeper
Admission Requests
To initiate a call, an endpoint sends an admission request (ARQ) to the gatekeeper. The ARQ contains either an H.323 ID or the E.164 address of the destination, or called party, as well as the E.164 address or H.323 ID of the source, or calling party. The ARQ also contains the requested call bandwidth, which should be the upper limit of both the transmitted and received bit rates for all video and voice channels. The bandwidth does not allow for any transport, IP, or RTP overhead. If the ARQ contains the E.164 address (with Cisco CallManager, the ARQ always will contain an E.164 address), the ARQ may or may not contain the technology prefix. If the ARQ does not contain the technology prefix, the gatekeeper uses the default technology prefix if one is configured. See the gw-type-prefix command in the section Cisco IOS Gatekeeper Commands, page 7-10. The gatekeeper responds to the ARQ with an admission confirm (ACF) if the requested bandwidth is available and the called endpoint is registered with the gatekeeper. The ACF will contain the IP address of the destination endpoint. If the bandwidth is unavailable or the called endpoint is not registered, the gatekeeper returns an admission reject (ARJ) to the calling endpoint.
7-7
Upon receipt of an ACF from the gatekeeper, the source endpoint can send a setup message directly to the destination endpoint by using the IP address returned in the ACF. Figure 7-7 illustrates the call admission request sequence.
Figure 7-7 Admission Request
Endpoint 1 ARQ (1) ACF/ARJ (2) Setup (3)
Gatekeeper 1
Endpoint 2
Call proceeding (4) ARQ (5) ACF/ARJ (6) Alerting (7) Connect (8) RAS messages Call signaling messages
76112
Disengage Request
When an endpoint terminates a call, it must indicate this to the gatekeeper and return the bandwidth. An endpoint indicates call termination with a disengage request (DRQ) to the gatekeeper. The gatekeeper responds with a disengage confirmation (DCF) and returns the previously used bandwidth to the pool of available bandwidth. (See Figure 7-8.) The gatekeeper can also clear the call by sending a DRQ to the endpoint, forcing that endpoint to terminate the call with the other endpoint and return a DCF to the gatekeeper.
Figure 7-8 Disengage Request
DRQ (1) DCF (2) Gatekeeper

76113
H.323 Endpoint
Bandwidth Requests
If the bandwidth requirement changes during a call due to a codec change or to additional media channels being opened or closed, the endpoint can request additional bandwidth (or release excess bandwidth) by sending a bandwidth request (BRQ). The gatekeeper responds with a bandwidth confirm (BCF) if the additional bandwidth is available, or it refuses the request with a bandwidth reject (BRJ) if the bandwidth is not available. (See Figure 7-9.)
7-8
EDCS-197018
Chapter 7
Figure 7-9
Bandwidth Request
BRQ (1) BCF/BRJ (2)

76114
H.323 Endpoint
Gatekeeper
Technology Prefix
Cisco IOS gatekeepers use technology prefixes to classify endpoints by their type. An endpoint can send its technology prefix to the gatekeeper during the registration process, or you can statically configure the technology prefix in the gatekeeper. Because the technology prefix allows the gatekeeper to distinguish between endpoint capabilities, the gatekeeper can use this prefix to route calls to the correct type of gateway.
Note
The technology prefix value is an arbitrary character string, and there are no standards for defining it. You can set the prefix to any value, but always use the same prefix to represent a given technology in both the gatekeeper and Cisco CallManager. An endpoint can register with more than one technology prefix. For example, a gateway endpoint could be capable of supporting any of the following technology types:

Voice Video FAX Voice band data (modem)
For example, assume a deployment with one gateway that can support only voice calls, another gateway that supports FAX, and both provide PSTN access to the 408 area code. The voice gateway could use a technology prefix of 1# to register with the gatekeeper, and the FAX gateway could use a prefix of 2#. An E.164 address of 1#4085551234 would then be routed to the voice gateway, while an E.164 address of 2#4085551234 would be routed to the FAX gateway. Note that both calls are for the same 4085551234 destination.
E.164 Address Resolution

E.164 addresses are like telephone numbers. The gatekeeper uses the E.164 address to find the IP address of the endpoint with that E.164 address. An endpoint can register its E.164 address during the registration process, but it can register only a fully qualified E.164 address and not ranges. You can manually configure E.164 address ranges for a gatekeeper zone. You can configure more than one E.164 address range per zone, but you cannot use the same E.164 address range in more than one zone.
7-9
ARQ Parsing Order

Figure 7-10 illustrates the operations performed by the gatekeeper process when it receives an admission request (ARQ) from an endpoint.
Figure 7-10 ARQ Parsing Order
GK Address Resolution on ARQ 1) Tech Prefix match? N 2) Zone Prefix match? Y target-zone = matched zone N Y N Hop-off Tech Prefix? Strip tech prefix Is "arq reject-unknown-prefix" set? Y N target-zone = local zone Send ARJ Y Send LRQ
3) Is target-zone local? Y 4) Was a Tech Prefix found in Step 1? Y N 5) Is target address registered? N 6) Is a default Tech Prefix set? Y
Send LRQ
Find local GW with Tech Prefix
Y N
Send ACF
Send ACF
Send ARJ
Send ARJ
Cisco IOS Gatekeeper Commands

This section briefly describes some of the common Cisco IOS gatekeeper commands. For more information on these and other commands, refer to the Cisco IOS command reference documentation available through Cisco.com.
gatekeeper
Use this command to enter the gatekeeper global configuration mode.

gw-type-prefix
Use this command to configure a technology prefix in the gatekeeper. To remove the technology prefix, use the no form of the command
show gatekeeper calls
Use this command to show the status of all call of which the gatekeeper is aware.
show gatekeeper endpoints
Use this command to display the status of all endpoints registered with the gatekeeper.
show gatekeeper gw-type-prefix
Use this command to display the gateway technology prefix table.
7-10
EDCS-197018
76115
Select local GW with Tech Prefix N N
Send ACF
Chapter 7
show gatekeeper status
Use this command to display the overall status of the gatekeeper.

show gatekeeper zone prefix
Use this command to display the gatekeeper zone prefix table.

show gatekeeper zone status
Use this command to display the status of the zones for the gatekeeper.
shutdown
Use this command to disable the gatekeeper.

zone bw
Use this command to set the maximum bandwidth allowed in a gatekeeper zone at any one time.
zone local
Use this command to specify a zone controlled by this gatekeeper

zone prefix
Use this command to configure a local or remote zone prefix.

zone remote
Use this command to define a remote zone statically.

zone subnet
Use this command to configure a gatekeeper to accept discovery and registration messages sent by endpoints in designated subnets.
Debug Commands
This section briefly describes some of the common debug commands for Cisco IOS gatekeepers. For more information on these and other commands, refer to the Cisco IOS command reference documentation available through Cisco.com.
debug h225 asn1
Use this EXEC command to display ASN1 contents of RAS and Q.931 messages.
debug h225 events
Use this EXEC command to display Q.931 events.

debug ras
Use this EXEC command to display RAS events.
Cisco CallManager Configuration

Cisco CallManager can use a gatekeeper for call admission control only or for call admission control and E.164 address resolution. When used for call admission control only, the gatekeeper can support calls from one Cisco CallManager to another Cisco CallManager or to an H.323 gateway. When used for E.164 address resolution, the gatekeeper can support calls between Cisco CallManager clusters. If you are using the gatekeeper for E.164 address resolution, you can centralize the dial plan administration by configuring the dial plan on the gatekeeper rather than at each Cisco CallManager cluster.
7-11
Cisco CallManager allows you to configure two varieties of H.323 gateways:

H.225 device for connectivity to Cisco IOS H.323 gateways Intercluster trunks for connectivity between Cisco CallManager clusters
A third type of gateway, the Anonymous Device, provides gatekeeper E.164 address resolution for calls between Cisco CallManager clusters. For more information about the Anonymous Device, see Intercluster Trunk Gateways, page 7-16 The following sections describe how to configure the various components of gatekeeper call admission control in Cisco CallManager:

Gatekeeper Used for Call Admission Control, page 7-12 Gateway Configuration, page 7-13 Intercluster Trunk Gateways, page 7-16
Gatekeeper Used for Call Admission Control

To use gatekeeper call admission control with Cisco CallManager, first you have to define the gatekeeper in the Cisco CallManager configuration database, as illustrated in Figure 7-11. To configure the gatekeeper, select Device > Gatekeeper in Cisco CallManager Administration.
Figure 7-11 Configuring the Gatekeeper Device
When configuring a gatekeeper device, you enter the following parameters:
Gatekeeper Name This is either the IP address of the gatekeeper or its domain name system (DNS) name if you are using DNS. Cisco recommends using the IP address to avoid DNS lookup latency or dependencies.
Description A text description for your administrative use.
Registration Request Time To Live The timeout period (in seconds) for gatekeeper registration. If an endpoint does not send a registration request before this timer expires, the gatekeeper will unregister the endpoint.
7-12
76116
EDCS-197018
Chapter 7
Registration Retry Timeout The time (in seconds) that Cisco CallManager will wait between failed registration attempts.
Terminal Type The Terminal type for Cisco CallManager when it registers with the gatekeeper. Cisco CallManager can register as either a Gateway or a Terminal. Always set the terminal type to Gateway, unless you have specific requirements for Cisco CallManager to register as a Terminal.
Device Pool The name of the device pool to which you want to assign the gatekeeper. All devices in the device pool share the same Cisco CallManager redundancy group, time zone, and codec type.
Technology Prefix The technology prefix that Cisco CallManager uses to register with the gatekeeper.
Zone The gatekeeper zone where Cisco CallManager registers.
When you save the gatekeeper configuration, Cisco CallManager gives you the option to reset or restart the gatekeeper device and activate it with the new parameters.
Gateway Configuration
After configuring the gatekeeper in Cisco CallManager, you can configure a PSTN gateway that uses the gatekeeper for call admission control. This gateway configuration involves two phases:

Gateway Configuration in Cisco CallManager, page 7-13 Gateway Configuration on the Gateway, page 7-15
Gateway Configuration in Cisco CallManager

Figure 7-12 illustrates how to add a gateway to the Cisco CallManager database. Select Device > Gateway in Cisco CallManager Administration, select the option to add a new gateway, and select H.323 as the gateway type. Cisco CallManager also requires you to select the Device Protocol for the gateway device. Select H.225 protocol if the device is a Cisco IOS H.323 gateway or select Inter-Cluster Trunk protocol if the device is another Cisco CallManager.
Figure 7-12 Adding a New Gateway Device
76117
7-13
After selecting the device protocol and clicking Next, you enter the additional gateway parameters illustrated in Figure 7-13.
Figure 7-13 Configuring Gateway Parameters
Most of the parameters in Figure 7-13 apply to all gateway configurations. However, the Gatekeeper Name parameter applies only to gateways that are subject to gatekeeper call admission control. Cisco CallManager supports only one gatekeeper configuration per cluster. To configure the gateway for call admission control, select the gatekeeper name from the drop-down listed. The gatekeeper provides call admission control for all calls between Cisco CallManager and this gateway. Do not check the Media Termination Point Required box unless an MTP is specifically required for an H.323v1 endpoint that does not support supplementary services or for providing other features, such as enabling a private (RFC 1918) address used in the IP telephony deployment to be translated to a public address assigned to the MTP so that the media can be routed to a public network. Prior to Cisco CallManager Release 3.1, MTP had to be enabled if a transcoder might be required in a call on either an intercluster trunk or a gateway, but this requirement does not apply to Release 3.1 and later. Refer to the Transcoding, Conferencing, and MTP Resources chapter for more information. To route calls from Cisco CallManager to the gateway, use either a route pattern or route group, as illustrated in Figure 7-14.
7-14
76118
EDCS-197018
Chapter 7
Figure 7-14 Routing calls to the Gateway
Note
The IP address of the H.323 gateway defined in Cisco CallManager must be the source address of any H.323 (H.225) call setup messages. That is, it must be the IP address defined by the h323-gateway voip bind srcaddr command. If the IP address is not one that is defined as a valid H.323 gateway in Cisco CallManager, it might not be acknowledged, or the Anonymous Device might handle it. Both of these results are undesirable.
Gateway Configuration on the Gateway

The Cisco IOS gateway requires a dial-peer that uses session target ras to place calls via the gatekeeper. This is the simplest configuration that allows for gatekeeper call admission control and automatic redundancy for the gateway to the Cisco CallManager servers. You can also use dial-peers with session target ipv4:callmanager_ip_address to place calls from the gateway directly to Cisco CallManager without using the gatekeeper for call admission control. This approach is used in centralized call processing, where Cisco CallManager locations is the recommended form of call admission control for the gateway as well as for other non-H.323 devices at the branch that cannot use the gatekeeper. When using locations in this way, if the Cisco CallManager server that you have targeted in the dial-peer is part of a cluster and that server becomes unavailable, you need to configure additional dial-peers with a preference to target other Cisco CallManager servers in the cluster. The configuration in Example 7-1 defines a H.323 gateway with a source IP address of 10.1.1.101 and an H.323 ID of 408_gw. (The H.323 ID is not really required, but it makes it easier to identify each endpoint that registers with the gatekeeper.) This configuration registers the gateway with a gatekeeper at IP address 192.168.222.130, in a zone called DALLAS. The technology prefix is defined as 1#.
76119
7-15
Example 7-1
Cisco IOS Gateway Configuration
gateway interface Fa0/0 ip address 10.1.1.101 255.255.255.0 h323-gateway voip interface h323-gateway voip id DALLAS ipaddr 192.168.222.130 1718 h323-gateway voip h323-id 408_gw h323-gateway voip tech-prefix 1# h323-gateway voip bind srcaddr 10.1.1.101
The configuration in Example 7-2 directs calls to numbers in the range 4000 to 4999 through a gatekeeper to the correct Cisco CallManager server in the correct cluster. Codecs other than G.711 require the Dual Tone Multi-Frequency (DTMF) relay option. Cisco recommends the IP precedence setting of 5 to mark all Real-Time Transport Protocol (RTP) streams for the correct quality of service (QoS).
Example 7-2 Recommended Dial-Peer Configuration
dial-peer voice 4 voip destination-pattern 4... session target ras dtmf-relay h245-alphanumeric ip qos dscp af31 signaling ip qos dscp ef media
Intercluster Trunk Gateways

Intercluster trunk gateways have some special configuration requirements. For example, the Device Name that you enter for the gateway is the IP address of the Cisco CallManager server in the destination cluster. If there is more than one Cisco CallManager server in the destination cluster (as is usually the case), then you have to configure an intercluster trunk for each of the remote servers. This arrangement provides redundancy in case one of the servers in the remote cluster fails. You also have to configure a corresponding set of intercluster gateways at the remote cluster so that it can call all the Cisco CallManager servers in the local cluster. (See Figure 7-15.) Without this symmetrical configuration, there would be only one-way calling paths and no fault tolerance in the design.
Figure 7-15 Intercluster Gateways (Simplified Representation)
M
76120
Cluster 1
Cluster 2
As an alternative to the multiple, point-to-point intercluster trunk gateways, you can enable the Allow Anonymous Calls feature when you configure the gatekeeper in Cisco CallManager, as illustrated in Figure 7-16. This feature creates a special gateway called the AnonymousDevice, which functions as a point-to-multipoint intercluster trunk.
7-16
EDCS-197018
Chapter 7
Figure 7-16 Enabling the Anonymous Device
The AnonymousDevice appears in the gateway list in the Route Pattern and Route Group configuration pages of Cisco CallManager. The advantage of the AnonymousDevice is each Cisco CallManager cluster needs only a single intercluster trunk gateway to connect to all other Cisco CallManager clusters, as shown in Figure 7-17.
Figure 7-17 Single AnonymousDevice Intercluster Trunk Gateway
76121
Cluster 1
Cluster 2
The AnonymousDevice provides both inbound and outbound intercluster trunk gateway service for the cluster. The AnonymousDevice is linked with the Gatekeeper Device in the Cisco CallManager cluster. At any given time, the same Cisco CallManager server runs both the Gatekeeper Device and the AnonymousDevice. If that server fails, then a backup Cisco CallManager server will take over the responsibility if a backup is provided.
76122
7-17
Chapter 7 Summary of Call Admission Control
Only the currently active Cisco CallManager server that is running the Gatekeeper Device and AnonymousDevice will register with the gatekeeper. If that server fails, the backup server registers with the gatekeeper. When the failed server recovers, it takes over the gatekeeper control again. When using the AnonymousDevice, you must configure the gatekeeper to allow for various Cisco CallManager servers to register in a zone at different times. There are two approaches to configuring the gatekeeper for this purpose. The first approach provides a very simple configuration that allows any endpoint to register with the gatekeeper zone. Once registered, the endpoint has access to the H.323 network for placing calls. This approach, illustrated in Example 7-3, is not secure.
Example 7-3 Simple Gatekeeper Zone Definition
zone local CM30X cisco.com
The second approach allows only specific IP addresses to register with the zone. Although this approach requires additional configuration, it provides a higher level of security. For instance, the configuration in Example 7-4 defines four IP addresses that are allowed to register in the CM30X zone. The addresses are of the Cisco CallManager servers. The last line in the configuration restricts all other IP addresses from registering.
Example 7-4 Recommended Gatekeeper Zone Configuration
zone local CM30X cisco.com ! zone subnet CM30X 10.1.1.2/32 enable zone subnet CM30X 10.1.1.3/32 enable zone subnet CM30X 10.1.1.4/32 enable zone subnet CM30X 10.1.1.5/32 enable no zone subnet CM30X 0.0.0.0/0 enable
Summary of Call Admission Control

The basis for any call admission control mechanism is the logical placement of endpoints in locations or zones. Logically grouping endpoints based on a geographical boundary, such as a building, is the simplest design. (See Figure 7-18.) Call admission control requirements will depend on your network topology, but the obvious boundaries are at WAN connections. If you require bandwidth control between two endpoints, you must place those endpoints into different logical locations or zones. Once you have grouped the endpoints by their call admission control requirements, you can assign them to Cisco CallManager locations or gatekeeper zones.
Note
Each logical group of endpoints must be fully contained within a single Cisco CallManager location or gatekeeper zone.
7-18
EDCS-197018
Chapter 7
Call Admission Control Summary of Call Admission Control
Figure 7-18 Locations or Zones
IP WAN
Location/Zone 1
Location/Zone 3
76123
Location/Zone 2
Call admission control (CAC) does not affect any calls between endpoints within the same location or zone. Call admission control applies only to calls between endpoints in different locations or zones. You can combine Cisco CallManager locations and gatekeeper zones to form a hierarchical call admission control system, as illustrated in Figure 7-19.
Figure 7-19 Hierarchical Call Admission Control
Gatekeeper
Gatekeeper based CAC Cisco CallManager clusters

M M M
"Locations" based CAC Location X Location Y

76124
You could potentially expand the hierarchical approach in Figure 7-19 to provide call admission control for hundreds of Cisco CallManager clusters, as illustrated in Figure 7-20. The only limits to this approach are the requirements to maintain a logical hub-and-spoke topology and to scale the dial plan.
7-19
Chapter 7 Summary of Call Admission Control
Figure 7-20 Expanded Hierarchical Gatekeeper Deployment
IOS directory Gatekeeper
IOS Gatekeepers Gatekeeper based CAC Cisco CallManagers

M M M M M M M M M
"Locations" based CAC Location X Location Y

76125
7-20
EDCS-197018
C H A P T E R
Dial Plan
This chapter presents some design guidelines and recommendations for dial plans in Cisco CallManager deployments. It focuses on the following major topics:

Overview of IP Telephony Dial Plans, page 8-2 Dial Plan Components and Operation, page 8-4
External Route Pattern Architecture, page 8-5 Calling Restrictions, page 8-16 Translation Patterns, page 8-19 Voice Mail Integration and Cisco CallManager Dial Plans, page 8-21
Dial Plan Guidelines for IP Telephony Deployment Models, page 8-25

Single-Site Deployment, page 8-26 Multi-Site IP WAN with Distributed Call Processing, page 8-28 Multi-Site IP WAN with Centralized Call Processing, page 8-30 Multi-Site IP WAN with Overlapping Extensions, page 8-33
8-1
Chapter 8 Overview of IP Telephony Dial Plans
Dial Plan
Overview of IP Telephony Dial Plans

A well designed dial plan is a vital component of any IP telephony network, and all the other network elements rely on it in some fashion. The dial plan is essentially the IP routing for voice calls, as illustrated in Figure 8-1. IP routing and IP telephony dial plans perform similar functions in that both provide endpoint addressing, alternate path routing, and enforcement of policy restrictions.
Figure 8-1 Call Routing by a Dial Plan
Router
IP route 1st choice
10.1.X.X 10.2.X.X
IP route 2nd choice
Local hosts
Routing table
1000 IP
CallManager
215-555-XXXX 408-555-XXXX Router/GW
IP WAN 1st choice
V
1001 IP
74363
PSTN 2nd choice
One of the fundamental attributes of a dial plan is its ability to route a call transparently to the dialed destination, irrespective of the physical voice path available, as illustrated in Figure 8-2.
8-2
EDCS-197018
Chapter 8
Dial Plan Overview of IP Telephony Dial Plans
Figure 8-2
Basic IP Telephony Dial Plan Attributes
User dials 526-4000 1000 IP
1. IP WAN available Gatekeeper CallManager places call across IP WAN as the primary voice path strips off dialed digits as required for remote site CallManager IP WAN 1st choice "526" removed "4000" sent to remote site over IP WAN "526-4000" pre-pended with "1308" for PSTN
74364
Router/GW
V
1001 IP PSTN 2nd choice
2. IP WAN unavailable CallManager places call across PSTN if IP WAN unavailable transparently to the user prefixes dialed digits as required for PSTN
IP telephony dial plans provide the following primary benefits:

Transparent routing of calls to dialed destinations, with alternate path routing if there are multiple paths to a given destination. Device redundancy in the event of a failure in a network element such as a gateway, a voice mail server, or an application. Calling policies to control which destinations selected IP phones and users can dial. Digit manipulation to strip or add digits to the dialed E.164 number, based on the voice path taken (whether over the IP WAN or the PSTN). Partitioned dial plans, which can be used to support overlapping dial plans.
8-3
Chapter 8 Dial Plan Components and Operation
Dial Plan
Dial Plan Components and Operation

This section describes the dial plan components you can configure in Cisco CallManager, and it explains how a Cisco CallManager dial plan operates. When it routes calls, Cisco CallManager distinguishes between internal and external calls, as illustrated in Figure 8-3. Routing of internal calls is based on registration of the IP phone with Cisco CallManager, while routing of external calls is based on the route patterns you have configured in Cisco CallManager.
Figure 8-3 Routing of Internal and External Calls
Gatekeeper
1000 IP Internal 1001 IP
CallManager
Router/GW
IP WAN 1st choice
External
V
PSTN 2nd choice
External calls - Routing based on an external route pattern match
Internal Calls
When an IP phone dials a number to place a call, Cisco CallManager first analyzes the dialed number to determine if it is the number of a registered IP phone. If the dialed number matches the number of a registered IP phone, then the call is placed as long as the class of service (CoS) configuration allows for the call to be placed. (Classes of service for IP telephony are more accurately termed calling restrictions. See Calling Restrictions, page 8-16, for more information.) In the analogy with IP routing, this scenario is very similar to that of two IP hosts on the same subnet sending packets to each other; in this case, the router does not have to look up the destination in its routing table. When the IP phone registers with Cisco CallManager, it effectively updates Cisco CallManager dynamically with its new IP address while maintaining its same phone number. Other devices that register with Cisco Call Manager in this way and maintain a directory number (DN) include Cisco IP SoftPhone and analog phones attached to MGCP gateways. You can configure the internal dial length (number of digits dialed) for internal calls.
External Calls
When an IP Phone dials a number that does not match a registered IP phone, Cisco CallManager assumes that the call is an external call and it looks in its external route table to determine where to route the call. Cisco CallManager uses route pattern and translation pattern tables to determine where and how to route a call. This method is very similar to the IP routing concept of static IP routes. The following sections explain the external route pattern architecture and operation in more detail.
8-4
74365
Internal calls - Routing based on whether the destination IP phone is registered with CallManager
EDCS-197018
Chapter 8
Dial Plan Dial Plan Components and Operation
External Route Pattern Architecture

The external route pattern construct in Cisco CallManager is based upon a three-tiered architecture that allows for multiple layers of call routing as well as digit manipulation. Cisco CallManager searches for a configured route pattern that matches the external dialed string and uses it to select a corresponding route list, which is a prioritized list of the available paths for the call. These paths are known as route groups and are very similar to trunk groups in traditional PBX terminology. A route pattern is best thought of as a static route which multiple paths. Figure 8-4 depicts the three-tiered architecture of Cisco CallManager dial plans.
Figure 8-4 External Route Pattern Architecture
Route Pattern Matches a dialed number for external calls, performs digit manipulation (optional), points to route list for routing Route List Chooses path for call routing, points to prioritized route groups
Route pattern Route list 1st choice No try 2nd choice 2nd choice No try 3rd choice (if available)
Route Group Like a trunk group can perform digital manipulation, points to devices (gateways, gatekeepers, remote CallManagers, etc.)
Route group
Route group
V
IP WAN PSTN
V
M
74366
Remote site
In most cases, the route pattern directs calls to a PSTN gateway or, in the case of an IP WAN call, to an H.323 gatekeeper for delivery to a remote Cisco CallManager and gateway. In addition to providing multiple prioritized paths for a call, the Cisco CallManager dial plan can also provide unique digit manipulations for these paths, based on your network requirements. Digit manipulation involves appending or removing digits from the original dialed number to accommodate user dialing habits or gateway needs. For instance, for a given dialed number, Carrier A may require 7 digits whereas Carrier B may require 10 digits. Cisco CallManager can provide this manipulation transparent to the user. Route groups function as trunk groups that provide access to the gateways. Route lists effectively provide path redundancy by defining a prioritized list of route groups.
8-5
Dial Plan
A typical use of a Cisco CallManager route plan is to route a given dialed number to the IP WAN as the first path choice or to the PSTN as the second path choice if the IP WAN is down or has insufficient resources. You can configure call admission control to indicate that the IP WAN cannot accept the call, thus prompting the dial plan to select an alternate route for the call. (Refer to the Call Admission Control chapter for details.)
Note
Specifying alternate paths to dialed destinations applies only to route patterns and not to destinations that are IP phones in the same Cisco CallManager cluster. Figure 8-5 illustrates a practical example of a Cisco CallManager route pattern.
Figure 8-5 External Route Pattern Example
1
User dials 9-1-408-526-4000, route pattern match, no digit manipulation
Philadelphia Route pattern "9.@" Route list "NY_IPWAN_RL"
4
2nd choice route group pre-pend "1408"
2
1st choice route group, discard access code "9-1", points to remote CallManager via GK Route group "GK_RG" Gatekeeper Route group "NY_PSTN_RG"
V 3
Send "408-526-6400" over IP WAN to remote CallManager
V
IP WAN PSTN
V
1 (408) 526-4000 sent over PSTN to remote site
5
Remote site San Jose
74367
In Figure 8-5, the route pattern 9.@ points to a route list that selects the prioritized paths for the call. In this case, the route list NY_IPWAN_RL attempts to send the call across the IP WAN route group GK_RG as the first-choice path or across the PSTN route group NY_PSTN_RG as the second choice. The route groups then point to individual devices such as VoIP gateways. Digit manipulation (stripping or adding digits) can be done in both the route pattern and the route group. However, Cisco recommends that you perform digit manipulation in the route group (viewed from within the route list) because digit manipulation requirements may differ depending on the voice path selected.
8-6
EDCS-197018
Chapter 8
Note
The route pattern can point directly to a gateway for routing calls, but Cisco strongly recommends that you use the complete route pattern, route list, and route group construct because it provides the greatest flexibility for call routing, digit manipulation, and future dial plan growth. Cisco CallManager performs external routing operations in the order shown in Figure 8-5, but you configure the components in Cisco CallManager in the following order:
1. 2. 3. 4.
Devices such as gateways and phones Route groups Route lists Route patterns
Route Patterns
A route pattern is a static route for dialed E.164 numbers that Cisco CallManager tries to match when determining how to route a call. Route patterns are typically used for external calls, they can also be used to route calls to entities such as voice mail gateways or H.323 conference servers. A given route pattern points to a specific route list that selects the destination path for the call.
Pattern Matching
Cisco CallManager route patterns use a combination of specific digits and several types of wildcards to find a match for a dialed number in order to route a call. The purpose of using wildcards is to reduce the number of route patterns you have to configure. For example, a single route pattern of 1XXX matches all numbers from 1000 to 1999. The following are the most common wildcards used in route patterns: X [n-m] Represents a single digit in the range 0 to 9. Represents a range of digits. For example, the pattern [2-9] matches any single digit in the range 2 to 9. Matches any dialed digits in the North American Numbering Plan (NANP) for 10-digit dialing. When the @ symbol appears in a dial plan, Cisco CallManager knows that the end of dialing is complete after 1+10 or just 10 digits (local area codes without the 1). You can use route filters for areas that have 7-digit dialing in North America. Represents one or more digits in the range 0 to 9. Delineates the end of the access code and the beginning of the directory number. Represents the end of dialing and instructs Cisco CallManager to process the dialed digits immediately.
! . (dot) #
If there is any overlap in the route patterns, Cisco CallManager selects the pattern with the closest match (most specific match). For example, the dialed digits 1111 are a closer match for the pattern 11XX than for the pattern 1XXX, so Cisco CallManager would use the pattern 11XX to route the call in this case.
8-7
Dial Plan
IP phones or other devices registered with Cisco CallManager are a special case of maximum-length route pattern. In the previous example, if the Cisco CallManager cluster has an IP phone registered with DN 1111, it will prefer this destination to the 11XX route pattern.
9.@ and Route Filters
Route filters are used only with the @ route pattern (most commonly, 9.@). They help reduce the number of route patterns required by filtering what is included in the 9.@ route pattern. Route filters are complex and described here is their most common use, which is with local 7-digit dialing in North America. (Note that most areas on North America are moving to full 1+10 or 10-digit E.164 dialing.) By default, Cisco CallManager knows that the end of dialing is complete after 1+10 or just 10 digits (local area codes without the 1). Cisco CallManager considers anything that does not begin with a 1 to be a local area code, and it considers dialing complete after 10 digits. In an area where 7-digit dialing is used for local dialing, Cisco CallManager has no way of knowing which office exchange codes (NXXs) to route to unless they are specifically coded as route patterns. Typically many NXXs exist in a given area code, and they are not arranged in a contiguous fashion so that wild cards could be used. Coding these individual route patterns for NXXs would be administratively burdensome, but route filters simplify the task. A route filter called 7-digit dialing is pre-configured in Cisco CallManager. You should assign this route filter to any 9.@ route pattern in an area that uses 7-digit dialing. This route filter will filter out all local area codes so that, if a dialed number does not begin with a 1, Cisco CallManager will treat it as a 7-digit number and will consider dialing complete after 7 digits. You still must configure the local area codes as separate route patterns, but this task is not administratively burdensome because there are only a few area codes in each geographical region. Figure 8-6 shows the 9.@ route pattern with the route filter 7-digit dialing. This is a very common route pattern construct used in North America for external dialing. You can also configure other route patterns on your deployment requirements.
Figure 8-6 Route Pattern for Seven-Digit Dialing
8-8
EDCS-197018
Chapter 8
The following notes apply to the example in Figure 8-6:
The route pattern is 9.@, where the dot (.) delimits the access code. The location of the dot determines how many digits are discarded from the dialed number. In this case, only one digit (the access code 9) is discarded. The Partition identifies where this route pattern is located for the purposes of calling restrictions that define who can dial 9.@. The route pattern points to a single route list that specifies how the call will be routed to a route group. If the Provide Outside Dial Tone box is checked, Cisco CallManager plays dial tone after the access code is dialed. Cisco recommends that you check this box so that uses hear dial tone after dialing an external access code. If the Urgent Priority box is checked, Cisco CallManager sends the call as soon as it detects a match, regardless of any other matches that might be possible. This feature is typically used for 911 or emergency calls, which must go through immediately even if other matches exist that require further dialing.
The following sections describe the other route patterns listed on the left in Figure 8-6.
911 and 9.911
Both of these emergency route patterns are configured in Figure 8-6 because users in an emergency might not remember that they have to dial 9 first to access an outside line. These two route patterns ensure that emergency calls will go through, no matter how they are dialed.
9.011! and 9.011!#
For international dialing, the 011 in this route pattern represents the international access code (for North America) and the ! represents a match of more than one digit in the range 0 to 9. Because international dialed numbers can be of varying lengths depending on the country dialed, Cisco CallManager does not know when the dialing is complete and will wait for 15 seconds before sending the call. You can reduce this 15-second delay in any of the following ways:

Reduce the 15-second timer to a lower value to indicate end of dialing. Do not set this timer lower than 4 seconds to prevent premature dialing of the call before the user is finished dialing. Instruct the users to dial # to indicate end of dialing. This action is analogous to hitting the send button on a cell phone. For this method, you must include the # to be at the end of the route pattern, which then becomes 9.011!#.
9.212XXXXXXX
This route pattern represents a local area code. When using 7-digit local dialing with the 7-digit dialing route filter, you must configure any local area codes as separate route patterns.
7005
In this example, the 7005 route pattern is the voice mail pilot number for a time-division multiplexing (TDM) voice mail system such as an Octel system. This route pattern routes calls to the gateways connecting to the Octel system. For international deployments, the PSTN access codes can vary and in many cases are 0. Because most countries have different E.164 dialing lengths than North America (and some countries have multiple dialing lengths as well), Cisco CallManager does not know when dialing is complete. In these situations, if the PSTN access code is 0, use a route pattern of 0.! or 0.!#.
8-9
Dial Plan
Digit Manipulation in Route Patterns

You can specify digit manipulation in both the route pattern and the route group under the route list. However, Cisco recommends that you configure digit manipulation only in the route group because digit manipulation requirements often depend on the path taken by the call. In addition, digit manipulation in the route group completely overrides any digit manipulation done in the route pattern.
Calling Line ID
The calling line ID presented to the called party can be altered or restricted, based on site requirements. The calling line ID presentation can be enabled or disable on the gateway and also can be manipulated in the route pattern. A typical requirement is for customers to send out the direct inward dial (DID) number as the calling line ID or the main number for the site if a non-DID is making the call. If you check the Use Calling Party's External Phone Number Mask box, then the external call uses the calling line ID specified for the IP phone placing the call. If this box is not checked, then the mask placed in the Calling Party Transform Mask field is used to generate the calling party ID.
CDR Information
Call detail records (CDRs) capture billing information. If you are using digit manipulation in the route pattern, the CDR records the dialed number after the digit manipulation has occurred. If you are using digit manipulation only in the route group, the CDR records the actual dialed number prior to the digit manipulation. This is another reason for using digit manipulation only in the route group. Figure 8-7 summarizes a common method of deploying a Cisco CallManager dial plan. This figure shows the external route patterns, together with the underlying route lists and route groups. Note that additional route patterns for local area codes or remote corporate sites may be added.
Figure 8-7 Typical Route Pattern Structure for a Multi-Site Deployment
Route pattern 911 9.911
Route pattern 9.[2-9]XX XXXX
Route pattern 9.1 [2-9]XX [2-9]XX XXXX
Route pattern 9.011! 9.011!#
Route list PSTN-RL 2nd choice Route group PSTN-RG PSTN Gateway
Route list IPWAN-RL 1st choice Route group IPWAN-RG Anonymous device
V
PSTN
V
IP WAN
74369
8-10
EDCS-197018
Chapter 8
Route Lists
A route list is a prioritized list of eligible paths (route groups) for an outbound call. Typically, a route list is associated with a remote location, and multiple route patterns may point to it. Figure 8-8 illustrates a route list that specifies two paths for a remote destination: the first-choice path is across the IP WAN using the route group GK_RG, and the second-choice path is through the local PSTN gateways using the NY_PSTN_RG route group.
Figure 8-8 Route List Example
Route lists have the following characteristics:

Multiple route patterns may point to the same route list. A route list is a prioritized list of route groups that function as alternate paths to a given destination. For example, you can use a route list to provide least-cost routing, where the primary route group in the list offers a lower cost per call and the secondary route group is used only if the primary is unavailable due to an "all trunks busy" condition or insufficient IP WAN resources. Each route group in the route list can have its own digit manipulation. For example, if the route pattern is 9.@ and a user dials 9-1-408-555-4000, the IP WAN route group can strip off the 9-1 while the PSTN route group may be required to strip off just the 9. Multiple route lists can contain the same route group. The digit manipulation for the route group is associated with the specific route list that contains the group.
Figure 8-9 depicts the digit manipulations configured for a particular route list and route group combination. In this example, the digit manipulation is configured to remove the 9-1 by first removing the PreDot digits and then converting an 11-digit number to a 10-digit number. This transformation ensures that the full 10-digit E.164 number is sent to the H.323 gatekeeper and the remote destination.
8-11
Dial Plan
Figure 8-9
Route Group Within a Route List
Digit Manipulation
If you are performing several digit manipulations in a route pattern or a route group, the order in which the transformation are performed can impact the resulting E.164 number. Cisco CallManager performs the following major types of digit manipulations in the order indicated:
1. 2. 3.
Discarding digits Called party transformations Prefixing digits
There are many possible digit discard choices, and Figure 8-10 illustrates some of the most commonly used ones.
Figure 8-10 Common Digit Discard Instructions
8-12
EDCS-197018
Chapter 8
Digit manipulation requirements can vary quite a bit from site to site, but the following examples illustrate some common scenarios. For these examples, assume: 10-digit dialing (7-digit dialing would require only minor adjustments to the configuration); on-net calls use the IPWAN as the first choice and the PSTN as the second choice; international calls go through the local PSTN.
Gatekeepers For route groups associated with a gatekeeper, the recommended digit discard instruction is PreDot This ensures that a 10-digit E.164 address is always sent to the gatekeeper and the destination.
11D->10D .
Gateways For route groups associated with gateways, typically the only discard instruction is PreDot Trailing # so that the full E.164 address (including a 1 if needed) can be sent to the PSTN. For gateways using Media Gateway Control Protocol (MGCP), the entire dial plan configuration is in Cisco CallManager, and the digit manipulation results simply get passed through the gateway to the PSTN. However, H.323 gateways have their own version of a dial plan and therefore require dial-peers for both incoming and outgoing calls to the PSTN. On an H.323 gateway, the E.164 address range coming from the PSTN might overlap with the one going to the PSTN. In this case the, gateway route group can prefix a 1* to the E.164 number sent to the H.323 gateway so that the gateway can use this 1* prefix to determine that this call is for the external PSTN. Although this method is not mandatory, it is especially useful in multi-tenant environments where many E.164 ranges may be present. Figure 8-11 depicts a route group for an H.323 gateway, in which a 1* is prefixed to the E.164 number so that the gateway knows the call is destined for the PSTN. Figure 8-12 shows the corresponding H.323 gateway configuration for this case.
Figure 8-11 Route Group for H.323 Gateways
8-13
Dial Plan
Figure 8-12 H.323 Gateway Configuration Using a 1* Prefix for Outgoing Calls
M
dial-peer voice 101 voip destination-pattern.......... session target ipv4:10.1.20.25 dtmf-relay h245-alphanumeric codec g711ulaw ip qos dscp af31 signaling ip qos dscp ef media ! dial-peer voice 1 pots destination-pattern 1*1.......... port 3/1/1 (Long Distance) prefix 1 ! dial-peer voice 2 pots destination-pattern 1*944 port 3/1/1 (Emergency) prefix 911 ! dial-peer voice 3 pots destination-pattern 1*215....... port 3/1/1 (Local Area Code) prefix 215 ! dial-peer voice 5 pots destination-pattern 1*....... (Local 7 digit dialing) port 3/1/1 ! dial-peer voice 6 pots destination-pattern 1*011T port 3/1/1 (Intl Dialing) prefix 011
CallManager
PSTN
V
GW IP
Incoming Dial Peer(s) Point to CallManagerCluster (CM Redundancy not shown) Outgoing Dial Peer(s) Must match outgoing String lengths. Ensure specific digit matches are sent out to PSTN be added if required.
74374
Unique Prefix can be added (1*) from CallManager to avoid overlapping dial peers
Route Groups
Route groups serve the same purpose as trunk groups in traditional PBX systems. Each route group sends calls to a prioritized list of devices such as gateways, as depicted in Figure 8-13. This example shows only one gateway, but the prioritization field is still visible.
Figure 8-13 Route Group Configuration (Standalone View, Not Within a Route List)
Route groups control and point to specific devices, which are typically gateways, gatekeepers ("Anonymous Device" gateways) or remote Cisco CallManagers. Gateways may use MGCP or H.323. Endpoints such as remote Cisco CallManagers across the IP WAN are also configured as H.323 gateways.
8-14
74375
EDCS-197018
Chapter 8
The route group points to one or more devices and can select the devices for call routing based on preference. The route group can direct all calls to the primary device and use the secondary devices when the primary is unavailable. This capability serves effectively as a trunk group. One or more route lists can point to the same route group. All devices in a given route group have the same characteristics, such as path and digit manipulation. As previously mentioned, each route group has its own digit manipulation instructions based on its parent route list, and these instructions override any digit manipulations performed in the route pattern.
Devices
Devices are the endpoints accessed by route groups, and they typically consist of gateways or remote Cisco CallManagers. You can configure the following types of devices in Cisco CallManager:

H.323 gateways H.323 gateway with H.225 trunk. Remote Cisco CallManager H.323 gateway with intercluster trunk. Anonymous Device (gatekeeper) Intercluster or H.225 trunk. Use the H.225 trunk only if all devices accessed through the gatekeeper are actual H.323 gateways (not Cisco CallManagers).
Figure 8-14 depicts a typical Cisco CallManager device configuration for an H.323 gateway. (Only elements that pertain to the dial plan are illustrated here.)
Figure 8-14 Dial Plan Elements in H.323 Gateway Configuration
The following fields shown in Figure 8-14 pertain to the dial plan configuration:
Device Name This is the IP address or Domain Name System (DNS) name of the physical device listed in the route groups. Cisco recommends that you use IP addresses for this field.
Calling Search Space This field defines which extension numbers the gateway may reach for calls coming in from the PSTN. Essentially this is the "policy" given to the device for incoming calls. For more information on calling search spaces, see Calling Search Spaces, page 8-16.
Calling Party Section This field determines the calling line ID (CLID) sent for outgoing calls. Typically you should select the Originator option to use the CLID of the person making the call.
8-15
Dial Plan
Presentation Bit This field determines whether Cisco CallManager will pass along the CLIDs for calls from this gateway to an external destination. If you select the Allowed option for this field, Cisco CallManager passes along the CLIDs for all outbound calls through this gateway. If you want to pass along some user CLIDs to the Central Office (CO) but not others, set the Presentation Bit to Allowed and, in the route pattern configuration, check the box for Use Calling Party's External Phone Number Mask. This configuration allows you to control the outbound CLID individually for each line by configuring the External Phone Number Mask field in the Directory Number Configuration pages. This field may be set to the central attendant number for those users who do not wish to pass along their CLID.
Sig Digits and Num Digits Together, these two fields determine how many digits are used for the DN of an incoming call. If the Sig Digits box is checked, Cisco CallManager strips non-significant digits from the destination number of incoming calls to this gateway. Num Digits specifies how many significant digits to retain as the destination DN. For example, if the Sig Digits box is checked, Num Digits is set to 4, and the dialed number of an incoming call is 212-555-1212, then the resultant destination DN would be 1212.
Prefix DN This field prepends the specified digits to the destination DN of all incoming calls to this device.
Calling Restrictions
Cisco CallManager provides the ability to restrict calls on each phone individually or on groups of phones in the same Cisco CallManager cluster. Users can be grouped into communities of interest on the same Cisco CallManager, yet share the same gateways and have overlapping dial plans. These capabilities help support multi-site IP WAN deployments with centralized call processing and multi-tenant deployments. To implement calling restrictions, Cisco CallManager uses partitions and calling search spaces.
Partitions
Partitions are groups of devices with similar accessibility. The devices in a partition are all the entities associated with the directory numbers (DNs) that users can dial, and they include IP phones, directory numbers, and route patterns. When naming a partition, choose a name that has some meaningful correlation to the group of users it represents. For example, for users located in Building D in San Jose, you could create a partition called SJ-D.
Calling Search Spaces

A calling search space defines which users can access which partitions. It serves the same function as an access list for a subnet. Calling search spaces are assigned to devices that can initiate calls, such as IP phones, Cisco IP SoftPhones, and gateways. The calling search space determines which destinations its member devices can call. Members of a calling search space can access only the partitions listed in their calling search space. Attempts to dial a DN in a partition outside the calling search space will fail, and the caller will hear a busy signal. If there are overlapping route patterns in different partitions within the same calling search space, Cisco CallManager chooses the matching route pattern of the partition listed first in the calling search space. Otherwise, closest match rules apply.
8-16
EDCS-197018
Chapter 8
Partitions and calling search spaces are analogous to routers with access lists, as illustrated in Figure 8-15. The partition is like an IP subnet where you place users, and a calling search space is like an inbound access list that determines which subnets the users can reach.
Figure 8-15 Partitions and Calling Search Spaces Compared to IP Subnets and Access Lists
Access list/ Calling search space permit B permit C (implicit) deny D Subnet/Partition A
Subnet/Partition B
Subnet/Partition C
Subnet/Partition D
74377
Figure 8-16 shows the configuration of a calling search space and the associated partitions that the devices assigned to that calling search space can reach.
Figure 8-16 Calling Search Space and Associated Partitions
Cisco recommends that you give careful though to the naming conventions used for partitions and calling search spaces so that administrators can see their purpose at a glance. For example, in Figure 8-16 the Tenant1_International calling search space is for Tenant1 users who can dial internationally. Likewise, the NY_911 partition contains the 911 route patterns. In many cases it is helpful to have a composite view of the whole calling search space and partition structure, with the users and route patterns in place. Figure 8-17 shows a composite view of a common Cisco CallManager dial plan for a single-site deployment.
8-17
Dial Plan
Figure 8-17 Composite View of a Typical Dial Plan Structure for a Single-Site Deployment
Calling search spaces
Partitions
Route lists
Route groups
Devices
Calling search space assigned to IP phone based on policy
Internal All IP phones Internal only 911 9.911 Local Local 9.[2-9]XXXXXX National National 9.1 [2-9]XX [2-9]XXX XXXX International International 9.011!
74379
Route patterns
IP
PSTN RL
PSTN RG
PSTN
9.011!#
Figure 8-17 illustrates the following points:
External route patterns are placed in partitions associated with the destinations they can call. While you could place all route patterns in one big partition, you can achieve more refined call restriction policies by associating the route patterns with partitions according to the destinations they can call. For example, if you place local and international route patterns in the same partition, then all users can reach both local and international destinations, which might not be desirable. Figure 8-17 contains four calling search spaces (policies), and each is configured to be able to reach only the partitions associated with its call restriction policy. For example, the Local calling search space is pointing to the Internal and Local partitions, so that users assigned to this calling search space can place only local calls.
Cisco recommends the following best practices for configuring calling search spaces on IP phones:

Configure the calling search space on the IP phone itself and not on the individual lines of the phone. This practice prevents users from selecting another line on the phone to bypass calling restrictions. Be careful when configuring multiple calling search spaces on the same IP phone, and understand how Cisco CallManager resolves call restriction policies in those cases. For example, if you configure different calling search spaces on both the IP phone itself and an individual line of the phone, that line will be able to reach all partitions in both calling search spaces. In addition, if a dialed string matches a different route pattern in each of these two calling search spaces, Cisco CallManager routes the call according to the route pattern in the calling search space of the IP phone itself. (However, if the dialed string matches route patterns in different partitions within the same calling search space, Cisco CallManager routes the call according to the route pattern of the partition listed first in the calling search space.)
8-18
EDCS-197018
Chapter 8
When configuring call forward features on an IP phone line, do not select a calling search space that can reach the PSTN. This practice prevents users from forwarding their IP phone lines to a long distance number and dialing their local IP phone number to bypass long distance toll charges on personal calls. See Figure 8-18.
Figure 8-18 Calling Search Space Recommendations for Call Forward Features
Translation Patterns
Cisco CallManager provides digit translation, which is the ability to transform a called or calling number into another number. Digit translation can be used on internal as well as external calls, whether inbound or outbound. Digit translation is typically used in situations such as routing a call to an attendant at extension 1111 whenever a user dials 0, routing a call to a recorded message if the call tries to reach an unassigned direct inward dial (DID) number, or routing all external inbound calls to an interactive voice response (IVR) system. Translation patterns follow the same general rules and use the same wildcards as route patterns. (See Route Patterns, page 8-7.) You assign a translation pattern to a partition. When a device in that partition places a call, Cisco CallManager applies the translation pattern to the dialed digits before routing the call. If the dialed digits match the translation pattern, Cisco CallManager performs the translation then routes the call again, this time using the calling search space configured within the translation pattern. If the dialed digits do not match the translation pattern, Cisco CallManager routes the call according to the dialed digits. Figure 8-19 shows the configuration of a translation pattern that matches all DNs in the range 1000 to 1999 and converts them to 1111.
8-19
Dial Plan
Figure 8-19 Translation Pattern Configuration
To better understand how translation patterns operate, see the example in Figure 8-20, which uses the composite view approach previously introduced in Figure 8-17.
Figure 8-20 Use of Translation Patterns for Inter-Site Calling with Overlapping Extensions
Delivers 1XXX Calling search spaces IP Site 1 Loc. code 1 Ext. 1XXX Site1_Internal Partitions Site1_Internal Site 1 IP phones On_Cluster 81.1XXX [Discard PreDot] 82.1XXX [Discard PreDot] 83.2XXX [Discard PreDot] IP Site 2 Loc. code 2 Ext. 1XXX Site2_Internal Site2_Internal Site 2 IP phones Delivers 1XXX To Site3_Internal Translation patterns force a second lookup using a different calling search space
Figure 8-20 shows how translation patterns can be used to provide inter-site dialing in the presence of overlapping extensions. For instance, if both Site 1 and Site 2 have extensions in the range 1XXX, partitions must be used to separate their overlapping directory numbers. To allow communication between sites, a set of translation patterns (one per site) is defined in a common partition that is visible to all users. When the user with extension 1000 at Site 1 wishes to dial the user with extension 1000 at Site 2, the user at Site 1 first dials the inter-site access code (8 in this example) followed by the destination site code (2) followed by the 4-digit extension of the other party (1000). This string, 821000, matches a translation pattern in the On_Cluster partition, which strips 82 and delivers 1000 to the Site2_Internal calling search space, which has access to Site 2s directory numbers. Refer to Multi-Site IP WAN with Overlapping Extensions, page 8-33, for more details on how to design dial plans in the presence of overlapping extensions.
8-20
74382
EDCS-197018
Chapter 8
Voice Mail Integration and Cisco CallManager Dial Plans

This section focuses on the aspects of dial plan design that pertain to voice mail integration. Different types of voice mail systems affect the CallManager dial plan differently. For more detailed information on voice mail integration, refer to the chapter on Voice Mail Integration with Cisco CallManager. Figure 8-21 illustrates the following supported methods for integrating Cisco CallManager with various types of voice mail systems:
Skinny Client Control Protocol (SCCP) Cisco CallManager uses SCCP to communicate with the Cisco Unity voice mail system.
Simple Message Desk Interface (SMDI) This integration method is supported for any SMDI-capable Voice Mail system. With this method, you can use either of the following integration options:
Use SMDI to connect Cisco CallManager directly to the voice mail system, and use an MGCP
gateway to connect to the voice mail ports.

Use SMDI to connect the Cisco VG-248 Analog Phone Gateway to the voice mail system. This
gateway also provides connectivity to the voice mail ports, and Cisco CallManager then uses SCCP to communicate with the Cisco VG-248.
Cisco DPA-7600 This integration method is supported for Avaya Octel and Nortel CallPilot voice mail systems. With this method, the Cisco DPA-7600 uses Digital Set Emulation to communicate with the voice mail system, and Cisco CallManager uses SCCP to communicate with the Cisco DPA-7600.
Computer Telephony Interface (CTI) This integration method is supported for voice mail systems that support TAPI or JTAPI.
8-21
Dial Plan
Figure 8-21 Methods for Integrating Cisco CallManager with a Voice Mail System
Cisco Unity VM/UM server
SMDI-capable VM system
Octel VM/ CallPilot VM
(J)TAPI-based VM system
Analog trunks SCCP SMDI
SMDI
Analog trunks
Digital set emulation CTI+ SCCP DPA7600
V
MGCP gateway SCCP
V
VG-248 gateway SCCP
M
CallManager
IP SCCP Integration
IP
IP
IP SMDI Integration
IP
IP
IP
IP
IP CTI Integration
IP
74383
DPA Integration
Beginning with Cisco CallManager Release 3.2, you can integrate a single Cisco CallManager cluster with multiple voice mail systems and can assign each DN to a particular voice mail system. For this type of integration, you define voice mail profiles in Cisco CallManager and assign each DN to a particular voice mail profile. Refer to the chapter on Voice Mail Integration with Cisco CallManager for further details. From the perspective of the Cisco CallManager dial plan, these voice mail integration options fall under one of the following categories:

Integration via SCCP, either to Cisco Unity directly or to other voice mail systems through the Cisco VG-248, the Cisco DPA-7600, or CTI ports Integration via SMDI, directly connecting Cisco CallManager to the voice mail system through SMDI and using an MGCP gateway for the voice path
The following sections provide dial plan design considerations for each of these integration methods.
8-22
EDCS-197018
Chapter 8
Voice Mail Integration via SCCP

Observe the following general guidelines when using SCCP to integrate a voice mail system:
Voice Mail Pilot Number The voice mail pilot number should be a DID so that users can dial into the voice mail system from an external location. Configure this voice mail pilot number in the Call Forward No Answer field of each IP phone.
Voice Mail Ports Voice mail ports are created through the Voice Mail Port Wizard within Cisco CallManager. Assign the voice mail pilot number as the DN of the first voice mail port.
Message Waiting Indicator DNs These DNs are used to enable SCCP-based voice mail systems to light and extinguish the message waiting indicator (MWI) light on the IP phone. In Cisco CallManager Release 3.1, these DNs must be unique across the entire cluster. Starting with Cisco CallManager Release 3.2, you can assign individual MWI DNs to each line as part of the voice mail profile for that line.
Messages Button DN This is the number dialed by every IP phone when a user presses the Messages button. In Cisco CallManager Release 3.1, this number is a global setting and must be unique across the entire cluster. Starting with Cisco CallManager Release 3.2, you can specify an individual Messages button DN for each line as part of the voice mail profile for that line.
Voice Mail Port Calling Search Space If you want the voice mail system to have any sort of out-dialing capability, you must assign the voice mail ports to a calling search space that has the proper permissions to make outgoing calls.
Note
Choose the MWI On and MWI Off DNs so that the first digit does not match the external call access code. For example, if the PSTN access code is 9, do not use 9001 and 9002 for MWI DNs.
Voice Mail Integration via SMDI

This section discusses the dial plan design when Cisco CallManager integrates directly to a voice mail system using SMDI.
Note
If you are using a Cisco VG-248 Analog Phone Gateway for voice mail integration, the SMDI connection to the voice mail system terminates at the gateway, and Cisco CallManager uses SCCP to communicate with the gateway. From the perspective of the dial plan, this case is equivalent to that for SCCP described in the previous section, Voice Mail Integration via SCCP, page 8-23. When using SMDI to integrate Cisco CallManager to a voice mail system, MGCP gateways are required to provide the voice path to the voice mail system. It is not possible to use H.323 gateways because SMDI messaging requires that Cisco CallManager be aware of the specific gateway port that is sending and retrieving messages. This information cannot be provided by H.323 gateways because H.323 is a peer-to-peer protocol.
8-23
Dial Plan
You must configure the appropriate route pattern with associated route lists and route groups to route calls to the voice mail system. This route pattern uses the same DN as the voice mail pilot number, which is configured in the Messages button of the IP phones and in the Call Forward No Answer field for each DN. Figure 8-22 depicts the voice mail route pattern and the associated route list and route group.
Figure 8-22 Route Pattern Construct for SMDI Voice Mail Integration
VM server
Route pattern "7005"
MGCP gateway
SMDI link
Route list "VM-SMDI-RL"
Route Group "VM-SMDI-RG"
IP
IP
When adding the voice mail ports to the route group, ensure that the port selection order matches the physical port numbering on the voice mail system. This ordering ensures that the port number indicated in the SMDI message matches the physical port number on the voice mail system. In SMDI terms, a port is identified by a logical terminal number (LTN). Figure 8-23 illustrates the port selection order in a voice mail route group. The order of the port in the route group configuration is also its LTN in the SMDI message sent to the voice mail system.
Figure 8-23 Voice Mail Route Group Configuration
8-24
74384
MGCP gateway
EDCS-197018
Chapter 8
Dial Plan Dial Plan Guidelines for IP Telephony Deployment Models
Cisco Messaging Interface (CMI)

The Cisco Messaging Interface (CMI) is the interface associated with the SMDI port on Cisco CallManager. CMI is a software service that runs on Cisco CallManager servers, and it is responsible for the following basic functions with regards to SMDI integration:
CMI binds the SMDI port to the voice mail route pattern DN. When calls are sent to this DN, an SMDI message is generated with the proper call data and sent to the voice mail system. (Call data includes port number, original call number, and forward reason.) CMI enables Cisco CallManager to provide MWI to the IP phones in response to SMDI messages received from the voice mail system.
Observe the following guidelines when using SMDI under the CMI:
The default behavior for both Cisco CallManager and the voice mail system with regard to SMDI is that the number of digits sent over the SMDI link is the same as the internal dial plan length. For example, if 4-digit dialing is used, then 4 digits will be sent in the SMDI messages. It is possible to configure Cisco CallManager so that the SMDI digit string can be expanded to the full E.164 address (or to another configurable digit string) for both sending to voice mail and receiving MWI messages. This method is typically used in deployments with overlapping dial plans, where the DNs are not unique and partitions are used to distinguish them. To bind the voice mail route pattern to the SMDI port, configure the voice mail pilot number in the VoiceMailDn service parameter under the CMI service in Cisco CallManager. If you are using partitions and calling search spaces, also configure the MwiSearchSpace service parameter so that the voice mail system can reach all IP phones that need MWI. Note that this parameter accepts a colon-separated list of partitions, not calling search spaces as the name might imply.
Note
With Cisco CallManager Release 3.2 and later, you can integrate a maximum of four SMDI-based voice mail systems per Cisco CallManager cluster. Enable the CMI service only on active Cisco CallManager servers in the cluster, and run only one instance of the CMI service on any given server.
Dial Plan Guidelines for IP Telephony Deployment Models

This section describes some best practices for implementing dial plans in the flowering deployment models:

Single-Site Deployment, page 8-26 Multi-Site IP WAN with Distributed Call Processing, page 8-28 Multi-Site IP WAN with Centralized Call Processing, page 8-30 Multi-Site IP WAN with Overlapping Extensions, page 8-33
8-25
Chapter 8 Dial Plan Guidelines for IP Telephony Deployment Models
Dial Plan
Single-Site Deployment
A single- site deployment is the simplest with respect to the dial plan because it typically uses only one path, the PSTN, for all external calls. Figure 8-24 illustrates the route pattern design for a single-site deployment, where a single route list is used for all route patterns.
Figure 8-24 Route Pattern Structure for a Single-Site Deployment
Route list "PSTN-RL"
Discard PreDot Discard Trailing #
Route group "PSTN-RG" Local area code route patterns may be added
PSTN Gateway(s)
V
74386
PSTN
Although each dial plan deployment has it own special characteristics, the following general considerations apply to the configuration in Figure 8-24:
This example uses a single route list that contains only one route group because there is only one path to the PSTN. You could configure multiple route groups if some PSTN trunks connected to Carrier A and some to Carrier B, where Carrier A might be the preferred carrier. This example uses a single PSTN gateway. To add capacity or provide redundancy, you could configure multiple gateways as devices within the route group. This example uses the route pattern 9.[2-9]XXXXXX to allow 7-digit dialing and to implement a call restriction policy that limits some users to dial local calls only. The 9.[2-9]XXXXXX route pattern is placed in a different partition than the 9.1[2-9]XX[2-9]XXXXXX route pattern, and the restricted users' calling search space is configured to contain only the partition with the 7-digit dialing route pattern. Note that an alternative to defining the 9.[2-9]XXXXXX route pattern would be to apply the pre-configured 7-digit dialing route filter to the 9.@ route pattern. The PreDot and Trailing # digit discard instructions are performed in the route group. The PreDot instruction strips the access code 9, and the Trailing # instruction removes the # that users may dial to signify end of dialing for international calls.
Figure 8-25 depicts the partitions and calling search spaces configured for this example, together with the route pattern construct described above.
8-26
EDCS-197018
Chapter 8
Figure 8-25 Composite Dial Plan View for a Single-Site Deployment
Partitions
Route lists
Route groups
Devices
Internal All IP phones Internal only 911 9.911 Local Local 9.[2-9]XXXXXX National National 9.1 [2-9]XX [2-9]XXX XXXX International International 9.011!
74379
Route patterns
IP
PSTN RL
PSTN RG
PSTN
9.011!#
The partitions and calling search spaces in Figure 8-25 exhibit the following characteristics:
Route patterns are placed in partitions based on the granularity of the policies created by the calling search spaces. This is why the 9.[2-9]XXXXXX route pattern is placed in its own partition and not with the national and international route patterns. This example uses four call restriction policies: Internal Only, Local, National, and International. The calling search spaces that make up these policies point to the respective partitions as needed. All IP phones in this example are placed in the Internal partition, which is reachable from all calling search spaces This configuration allows any IP phone to dial any other IP phone.
8-27
Dial Plan
Multi-Site IP WAN with Distributed Call Processing

In a multi-site IP WAN deployment with distributed call processing, the dial plan is typically configured to use the IP WAN as the first choice for on-net calls and the PSTN as the second choice if the IP WAN is not available or cannot handle additional voice calls. Figure 8-26 illustrates this deployment model.
Figure 8-26 Multi-Site IP WAN Deployment with DIstributed Call Processing
Voice mail Gatekeeper
Voice mail
M M
CallManager cluster
M M M
Secondary voice path PSTN
M M M
CallManager cluster
IP IP IP
V
IP WAN Primary voice path
IP IP IP
(408) 526-XXXX ext. 6XXXX
San Jose
New York
(212) 555-XXXX ext. 5XXXX
5-digit dialing within a site
5-digit dialing within a site

74387
Full E.164 dialing for all external calls
It is a common requirement for this type of deployment that intra-site calls use some sort of abbreviated dialing (for example, 5-digit dialing), while inter-site calls, either across the IP WAN or to the PSTN, use the full E.164 numbers.
8-28
EDCS-197018
Chapter 8
Route Pattern Structure

Although there are many possible configurations, Figure 8-27 illustrates the typical route pattern structure for a multi-site WAN with distributed call processing. The route patterns that route on-net calls to the IP WAN as the primary voice path all use the IP_WAN_RL route list to make the path selection.
Figure 8-27 Route Pattern Structure for a Multi-Site WAN with Distributed Call Processing
Route list PSTN-RL 2nd choice Route group PSTN-RG PSTN Gateway
Route list IPWAN-RL 1st choice Route group IPWAN-RG Anonymous device
V
PSTN
V
IP WAN
74369
Observe the following best practices when designing a dial plan for a multi-site WAN with distributed call processing:

Use the IP WAN for on-net internal company calls only. It is possible to provide remote hop-off to save long distance costs, but this practice complicates the dial plan configuration. It is common practice to send the full E.164 address to the gatekeeper and the remote Cisco CallManager or gateway, leaving it up to the terminating device to strip off all but the significant digits. This practice eliminates the need to configure the local (calling) Cisco CallManager with dial length information for each remote site. This example shows generic route patterns, but you can add more complex route patterns based on site requirements as needed.
8-29
Dial Plan
Partitions and Calling Search Spaces

The dial plans are very similar for a multi-site IP WAN deployment with distributed call processing and for a single-site deployment. The only major difference is that the multi-site deployment can access remote sites across the IP WAN. Figure 8-28 depicts the partitions and calling search spaces, together with two route lists: the PSTN_RL route list always uses the PSTN, while the IPWAN_RL route list uses the IP WAN as the first-choice path for on-net calls and the PSTN as the second-choice path if the IP WAN is not available.
Figure 8-28 Composite Dial Plan View for a Multi-Site WAN with Distributed Call Processing
Partitions
Route lists
Route groups
Devices
Internal All IP phones InternalOnly 911 9.911 Local Local 9.[2-9]XXXXXX National National 9.1 [2-9]XX [2-9]XX XXXX International International 9.011! 9.011!# IP WAN RL 2nd choice IP WAN RG PSTN PSTN RL PSTN RG PSTN Route patterns
IP
1st choice
74388
Multi-Site IP WAN with Centralized Call Processing

The multi-site IP WAN with centralized call processing differs from the previous deployment models in that the call processing and applications such as voice mail are centralized, yet the dial plan is configured such that multiple sites can be handled individually. Typically, PSTN gateways are distributed across the remote sites. If this is the case, users at those sites expect their calls to go out the local PSTN gateway when they dial the PSTN access code. In addition, emergency calls such as 911 must go through the local PSTN gateway. Figure 8-29 depicts the basic characteristics of this deployment model.
Note
This section assumes that there are no overlapping extensions among the sites. For design considerations in the presence of overlapping extensions, see Multi-Site IP WAN with Overlapping Extensions, page 8-33.
8-30
EDCS-197018
Chapter 8
Figure 8-29 Multi-Site IP WAN with Centralized Call Processing
Voice mail
M M M M M
SRSTenabled router CallManager cluster PSTN Access Code: 9
IP
IP PSTN Access Code: 9 PSTN Philadelphia
IP IP IP San Jose
V
IP WAN primary voice path PSTN Access Code: 9 New York IP
Route Pattern Structure

In most cases, each site requires that its emergency calls use the local PSTN. To implement this requirement, configure a separate set of route patterns for each remote site, and place the route patterns in a partition that can be reached only by the users at that particular remote site. Figure 8-30 illustrates this type of configuration with overlapping route patterns, each placed in a unique partition associated with a particular remote site. For example, if a user in Philadelphia dials 911, Cisco CallManager matches the dialed string with the 911 route pattern contained in the PHL911 partition, which uses the PHL PSTN route list to route the call through the Philadelphia PSTN gateway. Note that this example assumes the PSTN gateways are located at each site. If all PSTN gateways were centralized at the hub site, the dial plan configuration would become identical to that for a single-site deployment.
74389
IP
8-31
Dial Plan
Figure 8-30 Composite Dial Plan View for a Multi-Site WAN with Centralized Call Processing
Partitions PHL911 911 9.911
Route lists
Route groups
Devices
PHLInternal IP PHL phones PHLAllCalls
PHLPSTN 9.[2-9]XXXXXX 9.1[2-9]XX[2-9]XXXXXXX 9.011! 9.011!# OnCluster All IP Phones
Route patterns PHL PSTN PHL PSTN
PHL Gateways
V
PSTN
NYCInternal NYC911 IP NYC phones NCYAllCalls 911 9.911 NYCPSTN 9.[2-9]XXXXXX 9.1[2-9]XX[2-9]XXXXXXX 9.011! NYC PSTN NYC PSTN
NYC Gateways
V
PSTN

In most cases, users in a centralized call processing deployment expect to be able to call a remote site by simply dialing the internal extension of a remote user. The example in Figure 8-30 shows how to implement this type of internal dialing between sites. For visual simplicity, the example in Figure 8-30 depicts only two calling policies per site (Internal and AllCalls). The following dial plan characteristics apply to the example in Figure 8-30:
To facilitate on-net dialing between sites, all IP phones in this example are placed in the OnCluster partition, which can be reached from the calling search spaces of all remote sites. Note that this model does not allow for overlapping dial extensions among remote sites. Each remote site has its own set of partitions and route patterns. The number of partitions per remote site depends on the number of calling restriction policies associated with the route patterns. This example shows only two calling restriction policies, Internal and AllCalls. Each site has its own set of calling search spaces for its IP phones. The calling search spaces point to the OnCluster partition as well as the appropriate local route pattern partitions.
8-32
74390
9.011!#
EDCS-197018
Chapter 8
Use the following formulas to calculate the total number of calling search spaces and partitions needed: Total Partitions = (Number of calling restriction policies) x (Number of sites) + 1 Partition for all IP phones Total Calling Search Spaces = (Number of calling restriction policies per site) x (Number of sites)
Multi-Site IP WAN with Overlapping Extensions

A multi-site WAN deployment with overlapping extensions is a special case of the centralized call processing model with the same IP phone extensions used at several different sites. For example, Figure 8-31 shows two sites that have an IP phone with DN 20000.
Figure 8-31 Multi-Site IP WAN with Centralized Call Processing and Overlapping Extensions
Voice mail
DN 20000 IP
M M M M M
IP
IP
IP WAN
IP IP Site N
5-digit dialing within a site Full E.164 dialing between sites
74391
DN 20000
IP
8-33
Dial Plan
The flexibility of the Cisco CallManager architecture allows you to partition your dial plan in order to support overlapping extensions. The following considerations apply to this deployment model:
Several sites can share a single Cisco CallManager cluster and a single voice mail or unified messaging system (similarly to the way a simple centralized call processing deployment shares resources). Intra-site calls may be placed using abbreviated dialing (typically 4 or 5 digits). Inter-site calls may be placed using either full E.164 dialing or an access code followed by a site code and the extension. For example, if the internal site-to-site access code is 8 and two digits are used for the site code, a user may dial 8-55-20000 to call extension 20000 in site 55.
Support for overlapping extensions increases the complexity of the Cisco CallManager dial plan configuration. However, this type of dial plan may be required in scenarios where extension DNs cannot be changed and abbreviated dialing must be preserved (such as in pre-existing legacy systems, company acquisitions, or mergers).
Note
From a dial plan perspective, the same considerations made for enterprise deployments with overlapping extensions also apply to single-site multi-tenant deployments.

The architecture for the partitions and calling search spaces in an overlapping dial plan requires that the IP phones at each site are placed in a separate partition. For each site, you can define additional partitions to hold the local PSTN route patterns. The number of these partitions you need depends on the number of classes of service (or calling policies) you want to implement. Figure 8-32 shows one possible design model for the partitions and calling search spaces.
Figure 8-32 Partitions and Calling Search Spaces for Deployments with Overlapping Extensions
Calling search spaces Calling search space assigned to IP phone based on policy
Partitions
Site1_Internal
Site1Phones On_Cluster
Site 1 IP phones On-cluster translations Shared resources (voice mail, media resources)
Site1_Local IP Site 1 Site1_National
Shared Site1911 Site1Local
External route patterns Site1National

74392
Site1_International
Site1International
8-34
EDCS-197018
Chapter 8
Figure 8-32 shows two types of partitions:
Site-specific partitions:
Site1Phones holds the DNs of all IP phones located at site 1. Site1911, Site1Local, Site1National, and Site1International hold the local route patterns for,
respectively, emergency calls, local calls, national calls, and international calls.
Common partitions
The Shared partition provides access to shared resources such as voice mail, media resources,
and applications.
The On_Cluster partition holds the translation patterns needed to provide inter-site calls.
IP phones are then assigned a calling search space that contains a subset of these partitions, according to the calling policy assigned to them. Note that this configuration differs from that adopted for non-overlapping centralized call processing deployments, where all IP phones were placed in the same partition. In this case, the IP phones must be placed in different partitions because their DNs are not unique. If they were all placed in the same partition, they would automatically become shared line appearances.
Outbound Calls
The route pattern configuration to provide access to the PSTN follows the same principles outlined in Multi-Site IP WAN with Centralized Call Processing, page 8-30. Each site typically requires that emergency and local PSTN calls use the local branch PSTN gateway. You can implement this policy by placing the corresponding route patterns in partitions that are reachable only from that sites IP phones.
Inter-Site Calls
With overlapping dial plans, Inter-site calls are placed either by dialing the full E.164 number of the destination or by using an inter-site access code followed by a site code and the extension number. The example in this section assumes that the full E.164 is used, but the same considerations also apply to the use of an inter-site access code. To provide connectivity between sites and partitions, use translation patterns according to the following guidelines:

Define one translation pattern for each site, and place them all in the On_Cluster partition. Each pattern should match a sites E.164 address range. The resulting called numbers after translation should match the sites extensions. The calling search space where the call is sent after translation should include the partition that contains the sites IP phones.
These guidelines are illustrated in Figure 8-33.
8-35
Dial Plan
Figure 8-33 Overlapping Extensions - Translation Patterns for Inter-site Calls.
Calling search spaces Delivers 1XXX
Partitions
Site1_Internal IP Site 1 (215) 555 1XXX Site1_Internal Site 1 IP phones On_Cluster 91215555.1XXX [Discard PreDot] 91408555.1XXX [Discard PreDot] 9121255.52XXX [Discard PreDot] IP Site 1 (408) 555 1XXX Delivers 1XXX To Site3_Internal Site2_Internal Site2Phones Site 2 IP phones Translation pattern per site's E.164 address range
In Figure 8-33, when the user with extension 1000 at Site 1 wants to dial the user with extension 1000 at Site 2, they use the PSTN access code 9 followed by the E.164 number of the destination, which in this case is 1-408-5551000. This string matches a translation pattern in the On_Cluster partition, which discards everything but the last four digits and sends 1000 to the Site2_Internal calling search space. This calling search space contains the Site2Phones partition, where all Site 2 IP phones are placed. The call can then be completed to DN 1000 at Site 2.
Incoming Calls
To dispatch incoming PSTN calls to the appropriate extension, you can re-use the translation patterns in the On_Cluster partition mentioned previously. It is sufficient to assign all PSTN gateways a calling search space that contains only the On_Cluster partition, making sure that the gateways also prepend a 9 to the dialed number to match the already defined translation patterns.
Voice Mail Considerations

Voice mail integration requires special attention to the following requirements in the presence of overlapping extensions:

Voice mail boxes must have unique identifiers. This means that the IP phone extension cannot be used as a voice mail box, and some sort of digit manipulation is needed to obtain a unique number. Message waiting indicator (MWI) messages from the voice mail system must be able to reach the right IP phone even in the presence of non-unique extensions.
8-36
74393
EDCS-197018
Chapter 8
The first issue is addressed in Cisco CallManager by the use of the Voice Mail Box Mask field in the Voice Mail Profile Configuration page. This parameter, when configured, is used to communicate with the voice mail system and uniquely identify the user. For example, the Voice Mail Box Mask parameter can be set to the full E.164 number associated with the user. The second issue is addressed by re-using the translation patterns in the On_Cluster partition. If the voice mail system has been configured with the full E.164 numbers, it is sufficient to prepend 9 to the E.164 number in order to match the translation patterns previously defined to ensure proper inter-site communication. In this way, the MWI messages coming from the voice mail system with the full E.164 number will be translated to the appropriate extension in the specific partition.
Note
This scenario requires the configuration of two service parameters within Cisco CallManager. The MultiTenantMwiMode parameter within the Cisco CallManager service must be set to True, and the ValidateDNs parameter within the Cisco Messaging Interface (CMI) service must be set to False.
8-37
Dial Plan
8-38
EDCS-197018
C H A P T E R
Voice Mail Integration with Cisco CallManager

This chapter describes the various ways in which Cisco CallManager offers support for voice mail systems, including Cisco Unity as well as third-party systems. This chapter also discusses integration methods, the way in which Cisco CallManager and the voice mail system are physically connected. However, this chapter does not discuss voice mail networking, the ability to exchange messages between voice mail systems. This chapter contains the following major sections:

Cisco CallManager and Voice Mail, page 9-1 Existing Versus New Voice Mail Systems, page 9-4 Voice Mail and Cisco CallManager Release 3.2, page 9-6 Cisco Unity, page 9-7 Cisco Digital PBX Adapter (DPA), page 9-9
Cisco CallManager and Voice Mail

Cisco CallManager can support virtually any third-party voice mail system that uses the BellCore and Telcordia standard known as Simplified Message Desk Interface (SMDI). (See Figure 9-1.) SMDI provides the intelligence necessary for integration. Each time a call is presented by Cisco CallManager to a voice mail system, relevant call data (such as who the calling party is and whom they are calling) is sent to the voice mail system in SMDI format over an RS-232 serial link. (See Figure 9-2.) Once the voice mail system retrieves the SMDI information, it is then able to answer the call correctly and in the appropriate manner. The SMDI protocol is provided either by a Cisco CallManager server running the Cisco Messaging Interface (CMI) service or directly from an SMDI gateway such as the Cisco VG248. Typically the voice path is provided by analog FXS ports from either a Skinny Client Control Protocol (SCCP) or Media Gateway Control Protocol (MGCP) gateway such as the Catalyst WS-X6624-FXS.
9-1
Chapter 9 Cisco CallManager and Voice Mail
Figure 9-1
Voice Mail Dial Plan Integration Using SMDI
VM server
Route pattern "7005"
MGCP gateway
SMDI link
Route list "VM-SMDI-RL"
Route Group "VM-SMDI-RG"
IP
IP
Figure 9-2
SMDI Protocol
Voice path PBX VM/UM

74428
Serial data path
SMDI defines three primary message types:
Call history messages (from PBX to voice mail system) md-num ltn-port fwd-type Message-Desk, reference number for the call (000-999) Logical Terminal Number (the analog port for the call) The reason the call was forwarded to voice mail: D - direct call A - forward all calls B - forwarded on busy (supported in Cisco CallManager Release 3.1 and later) N - forwarded on no answer (supported in Cisco CallManager Release 3.1 and later) U - forwarded for unknown reason (supported in Cisco CallManager Release 3.1 and later) fwd-sta source-num The original called (dialed) number The original calling number
9-2
74384
MGCP gateway
EDCS-197018
Chapter 9
Voice Mail Integration with Cisco CallManager Cisco CallManager and Voice Mail
Message Waiting Indicator (MWI) messages (from voice mail system to PBX) mwi-on mwi-off Contains station number Contains station number
Error messages (from PBX to voice mail system) INV BLK MWI message was for unknown station Too busy to process MWI message
Cisco CallManager supports the BellCore and Telcordia SMDI specification, and Cisco CallManager Release 3.1 introduced support for forward on busy and forward on no answer. Voice mail integration is also possible to some other third-party systems using other protocols, such as the Telephony Application Programming Interface (TAPI) or PBX digital set-emulation, as illustrated in Figure 9-3.
Figure 9-3 Methods of Voice Mail Integration
Cisco Unity VM/UM server
Octel VM/ CallPilot VM
(J)TAPI-based VM system
Analog trunks SCCP SMDI
SMDI
Analog trunks
Digital set emulation CTI+ SCCP DPA7600
V
MGCP gateway SCCP
V
VG-248 gateway SCCP
M
CallManager
IP SCCP Integration
IP
IP
IP SMDI Integration
IP
IP
IP
IP
IP CTI Integration
IP
74383
DPA Integration
9-3
Chapter 9 Existing Versus New Voice Mail Systems
Existing Versus New Voice Mail Systems

In many cases, the question of how to support an existing voice mail system with Cisco CallManager depends on how the voice mail system is currently connected to the incumbent PBX. Cisco CallManager can support SMDI, SCCP, and TAPI. In the case of Octel Aria and Serenade systems that use digital set-emulation, the Digital PBX Adapter (DPA) can be used to integrate the voice mail system with Cisco CallManager. It is important to understand how the voice mail system is currently connected to the existing PBX because this implementation will influence the method used to connect the voice mail system to Cisco CallManager. For example, it is more cost effective to deploy the DPA for integration to Cisco CallManager if an Octel Aria 350 is currently integrated to an Avaya Definity G3 using digital set-emulation (PIC-A) than it would be to convert the Octel to SMDI with analog FXS ports. (See Figure 9-4.)
Figure 9-4 Using DPA to Integrate Octel Voice Mail with Cisco CallManager
Octel voice mail
24 PIC interfaces
DPA
M
Skinny client control protocol

M
CallManager Gateway
74429
IP IP IP PSTN
You may, of course, choose to deploy a new voice mail system concurrently with a new Cisco CallManager deployment. In such a case numerous integration methods are possible, ranging from SMDI with analog FXS ports to SCCP, TAPI, or the DPA. In summary, consider the following questions and guidelines before deploying voice mail in a Cisco CallManager system:
Will this be a new voice mail system or a re-deployment of an existing system? A new voice mail system can integrate with Cisco CallManager through either SMDI with analog FXS ports, SCCP, TAPI, or the DPA. An existing voice mail system must be capable of supporting at least one of these integration methods to connect with Cisco CallManager. If one of these methods is already in use with the incumbent PBX, it is probably best to use this same method for Cisco CallManager to avoid re-engineering costs
9-4
EDCS-197018
Chapter 9
Voice Mail Integration with Cisco CallManager Existing Versus New Voice Mail Systems
Which gateways can you deploy for analog FXS ports? Only MGCP or SCCP gateways can be used with SMDI due to the amount of control that they allow Cisco CallManager in selecting which port to use for the call. Suitable gateways include the Cisco VG200 (4 ports), the Catalyst WS-X6624-FXS (24 ports), the VG248 (48 ports), or the IAD2400 (16 ports).
Which DPA do you need for an Octel system that is currently connected to by PBX using digital set-emulation? The Cisco DPA is available in two models, the DPA 7610 for Nortel systems or the DPA 7630 for Lucent and Avaya systems. For more information on the DPA, see Cisco Digital PBX Adapter (DPA), page 9-9.
How many voice mail systems can you connect to Cisco CallManager? Prior to Cisco CallManager Release 3.2, only one voice mail system is supported. With Cisco CallManager Release 3.2 and later, up to four voice mail systems are supported, and they can be a mixture of types (SMDI with analog FXS ports, SCCP, TAPI, or DPA).
With Cisco CallManager Release 3.2, how many SMDI Voice Mail systems can you have? You can have as many SMDI systems as you can support from SMDI sources, up to the overall limit of four voice mail systems. For example, you could have one Cisco CallManager server with SMDI derived independently from four VG248 gateways, and each VG248 could connect to its own voice mail system.
Is it possible for multiple lines on the same IP phone to forward to different voice mail systems? With Cisco CallManager Release 3.2 and later, you can forward each line of an IP phone to a different voice mail system by configuring a separate Voice Mail Profile for each line appearance.
9-5
Chapter 9 Voice Mail and Cisco CallManager Release 3.2
Voice Mail and Cisco CallManager Release 3.2

Prior to Cisco CallManager Release 3.2, each Cisco CallManager cluster supported only one voice mail system. You can create a workaround for this limitation by using Cisco CallManagers extensive dial plan capabilities (for example, by using a combination of calling search spaces, partitions, and translation patterns), but this approach is complex and does not allow the dial plan to scale well. Beginning with Cisco CallManager Release 3.2, each cluster can support up to four voice mail systems. The voice mail systems can even be of different types (SMDI with analog FXS ports, SCCP, TAPI, or DPA). To achieve this capability, Cisco CallManager Release 3.2 allows you to associate each directory number or line appearance with a particular Voice Mail Profile. (See Figure 9-5.)
Figure 9-5 Voice Mail Enhancements in Cisco CallManager Release 3.2
Cisco Unity
Cisco Unity
Avaya Nortel Octel CallPilot
M M M M M
IP
IP
IP
74430
In summary, Cisco CallManager Release 3.2 provides the following enhancements (illustrated in Figure 9-5) for voice mail integration:

Support for up to four voice mail systems per Cisco CallManager cluster Ability to select a particular voice mail system for each DN individually Ability to configure Message Waiting Indicator (MWI) behavior for each IP phone individually
9-6
EDCS-197018
Chapter 9
Voice Mail Integration with Cisco CallManager Cisco Unity
Cisco Unity
Cisco Unity integrates with Cisco CallManager using Skinny Client Control Protocol (SCCP). This method has a major advantage over SMDI in that SCCP is IP-based, therefore no analog ports are used for the voice path. Thus, this method simplifies both server and network design. (See Figure 9-6.)
Figure 9-6 Voice Mail Integration with Cisco Unity
Unity Unity pilot number 1990
M M M M M
CallManager cluster
1111
1112
Voice mail integration through Cisco Unity provides the following features and capabilities:

Integration with Cisco CallManager through SCCP (similar to an IP phone) Use of the Voice Port Wizard in Cisco CallManager to assign DNs and configure voice mail ports Messages button on IP phones to dial the voice mail pilot number automatically (multiple pilot numbers are also possible) Multiple MWI on/off DNs within the same Cisco CallManager cluster
Cisco Unity can also support multiple Cisco CallManager clusters, thereby offering a centralized voice mail service. (See Figure 9-7.)
74431
IP
IP
9-7
Chapter 9 Cisco Unity
Figure 9-7
Centralized Voice Mail Service with Cisco Unity
Exchange message store Messaging server voice/email Messaging server voice/email Messaging server voice/email Messaging server voice/email
Cisco Unity server
CallManager cluster A
CallManager cluster B
CallManager cluster C
M M M M M M M
M M M M M
M M M
IP IP IP
IP
IP IP IP
IP
IP IP IP
IP
SCCP session for MWI LAN
Cisco Unity also provides the capability to integrate with both a traditional time division multiplexing (TDM) PBX system and Cisco CallManager simultaneously. (See Figure 9-8.) This dual integration capability can assist you in migrating from a traditional PBX system to Cisco CallManager and, if desired, in moving to Cisco Unity prior to deploying Cisco CallManager. Cisco Unity supports dual integration with the following PBX systems:

Lucent or Avaya Definity G3 (Analog) Lucent or Avaya Definity Gx (Digital PBX Link) Nortel Meridian 1 (Digital PBX Link) NEC NEAX2000 (MCI) NEC NEAX2400 (MCI) Centrex (SMDI)
AT&T 1AESS AT&T 5ESS Nortel Networks DMS100
9-8
EDCS-197018
74432
Chapter 9
Voice Mail Integration with Cisco CallManager Cisco Digital PBX Adapter (DPA)
Ericsson MD-110 (Serial) Mitel (Analog ONS)

SX200 SX2000
Figure 9-8
Cisco Unity Dual Switch Integration
Legacy phone
Legacy PBX
SMDI link
Cisco Unity server Exchange message store
Analog lines IP SCCP T1 line PSTN 3600 Router
Workstation with Outlook
CallManager
IP phones
For more information on deploying Cisco Unity, refer to the Unity product documentation available online at Cisco.com.
Cisco Digital PBX Adapter (DPA)

The Cisco Digital PBX Adapter (DPA) enables you to integrate Cisco CallManager systems with Octel voice mail systems, which might also be connected to either a Lucent Definity G3 or a Nortel Meridian 1. You might want to do this if you have these existing third-party telephony systems in your network and you want to continue to use them along with a Cisco IP Telephony system. For example, you can ensure that features such as message waiting indicators (MWI) for Octel voice messages are properly set on Cisco CallManager IP phones as well as traditional telephony phones. Using the DPA, you can integrate the following systems:

Cisco CallManager Octel Serenade 200 and 300 voice messaging systems (using APIC integration) Octel Aria 250 and 350 voice messaging systems (using FLT-A/PIC-A integration)
The following sections provide an overview of the DPA and its interactions with the other components in traditional and IP telephony networks:

Understanding How the DPA Works, page 9-10 Choosing an Integration Mode, page 9-11
74433
IP
IP
9-9
Chapter 9 Cisco Digital PBX Adapter (DPA)
Understanding How the DPA Works

The Cisco DPA enables you to integrate cisco CallManager with your existing Octel voice mail and either Lucent Definity G3 or Nortel Meridian 1 PBX systems. The DPA functions by emulating digital phones or a PBX system. This capability allows the DPA to appear like these devices to Cisco CallManager, Octel, and Lucent or Nortel systems.
Why is the DPA Needed?

If you want to migrate your telephony system from a Lucent Definity G3 or Nortel Meridian 1 PBX to Cisco CallManager, you must decide whether to do a complete cutover to Cisco CallManager or to migrate slowly. If you do a complete cutover to Cisco CallManager and Cisco Unity (Ciscos voice mail solution), you do not need the DPA. However, if you are slowly migrating your systems, you might want to maintain some phones on the Lucent or Nortel PBX while installing new phones on the Cisco CallManager system. You might want to use your existing Octel voice mail system with your Cisco CallManager system. In these cases, the DPA can assist your migration to Cisco CallManager.
Can I Just Use SMDI?

One difficulty with migration is that voice mail systems such as Octel were designed to integrate to only one PBX at a time. To resolve this difficulty, many systems use Simplified Message Desk Interface (SMDI), which was designed to enable integrated voice mail services to multiple clients. However, to use SMDI, the voice mail system must meet the following qualifications:

It must be able to associate each mailbox with the correct PBX in order to send MWI information on the correct link. It must be possible to physically connect the IP network to the voice messaging system while maintaining the existing physical link to the PBX. It must support analog integration. SMDI is primarily an analog technology.
Additionally, SMDI may require reconfiguration of your existing telephony network.
What If I Cannot Use SMDI?

SMDI might not be an option for you, particularly if you are using a digital interface on an Octel system. Octel systems with digital line cards emulate digital phones, appearing to the PBX as digital extensions, referred to as Per-port Integration Cards (PICs). On PIC systems, the voice and data are delivered on the same path. MWI is set and cleared via feature access codes on dedicated ports. Because these PIC ports use proprietary interfaces, you cannot use standard interfaces to connect them to the Cisco CallManager system. However, the DPA can translate these interfaces to enable communication among the Octel, Lucent or Nortel, and Cisco CallManager systems. Depending on the needs of your network, you can choose among several different integration methods.
9-10
EDCS-197018
Chapter 9
Choosing an Integration Mode

Select one of the following DPA integration modes, based on the needs of your IP telephony network:
Simple Used to integrate Cisco CallManager with existing Octel voice mail systems. In this solution, you are not using a Lucent or Nortel PBX system, or you are choosing not to integrate it with your IP telephony system. See Using the Simple Integration Mode, page 9-11. Hybrid Used to integrate Cisco CallManager with existing Octel voice mail systems and Lucent or Nortel PBX systems. See Using the Hybrid Integration Mode, page 9-12. Multiple Used to integrate the systems in larger networks using a combination of simple and hybrid scenarios, which requires multiple DPA systems. See Using the Multiple Integration Mode, page 9-13.
Using the Simple Integration Mode

In the simple integration mode, the DPA handles all processing and signaling between the Octel and Cisco CallManager systems (see Figure 9-9).
Figure 9-9 Simple Integration of Cisco CallManager and Octel Systems
Octel Voice Mail
Cisco 7630 DPA IP Gateway PSTN
IP
Cisco CallManager
74422
9-11
Using the Hybrid Integration Mode

If you want to connect Cisco CallManager to Octel voice mail and Lucent or Nortel PBX systems, you must use the hybrid integration mode. In the hybrid configuration, the DPA handles processing and signaling among the Octel, Lucent or Nortel, and Cisco CallManager systems (see Figure 9-10).
Figure 9-10 Hybrid Integration of Cisco CallManager, Octel, and Lucent or Nortel Systems
Octel Voice Mail
Cisco DPA 7630 Cisco CallManager
Lucent PBX Gateway
IP telephony network
Legacy PBX
9-12
74423
IP
IP
IP
EDCS-197018
Chapter 9
Using the Multiple Integration Mode

If your system requires more than the hybrid integration mode provides, you might want to add multiple DPA systems to your network (see Figure 9-11).
Figure 9-11 Multiple Integration Using Multiple DPA Systems
Octel Voice Mail DPA 7630 in simple mode PIC
Cisco CallManager
DPA 7630 in hybrid mode
IP (skinny client control protocol)
PIC Lucent PBX PSTN
V
Gateway
Legacy PBX
You might add multiple DPA systems to your network if you are using the DPA to capacity, and you need the following capability:
More than eight MWI ports to the Lucent or Nortel system. If you need more MWI ports to the Lucent or Nortel system, add an additional DPA in hybrid mode. However, you cannot use all 24 ports for Lucent or Nortel MWIs. You must configure the DPA by following the guidelines for the hybrid integration, using up to eight ports.
More than eight ports for call processing between the Cisco CallManager and Octel systems. If you need more than eight ports for handling calls between Cisco CallManager and the Octel systems, add another DPA in simple mode. This would provide another full 24 ports dedicated to call processing between the two systems.
Alternatively, you might also use an additional DPA to achieve a higher level of fault tolerance. In this situation, you can use two DPA devices in parallel, sharing the MWI lines between the two units. If one unit fails, the Octel system would use only the lines that were still operational, allowing voice mail to function normally.
74424
IP
IP
IP
9-13
9-14
EDCS-197018
C H A P T E R
10
Migration to an IP Telephony Network

This document explains how an enterprise can migrate from a conventional PBX and its adjunct systems (principally, voice messaging) to an IP telephony network. Four migration models are presented, encompassing various feature sets, and the steps for implementing each model are outlined. This document contains the following major sections:

Network Models, page 10-1 PBX and Voice Messaging Interfaces and Protocols, page 10-2 Simple IP Network Migration Sequence, page 10-3 Reference Models for Migration Configurations, page 10-5 Cisco Digital PBX Adapter (DPA), page 10-14
Network Models
Conventional voice networks to be migrated to IP networks contain, at a minimum, a single PBX and often several PBXs, which can be geographically dispersed. A network of PBXs can use a specialized, proprietary networking protocol to provide features across the different PBXs. If voice messaging is a part of the voice network, the voice messaging systems are connected to the PBX using a protocol and hardware interface. If there are several voice messaging systems in the network, they might be networked to appear to the user as a single messaging system. Generally the protocols used to connect to and network between voice messaging systems are proprietary. See Figure 10-1.
10-1
Chapter 10 PBX and Voice Messaging Interfaces and Protocols
Figure 10-1 Closed Versus Open Protocols in a Voice Network
Proprietary voice mail networking Voice mail system Networked voice mail Voice mail system
Proprietary voice mail/PBX interconnect Proprietary CCS Legacy PBX
Proprietary voice mail/PBX interconnect
Legacy PBX
PBX and Voice Messaging Interfaces and Protocols

When an IP network is introduced into the PBX environment, the users on the IP network generally can use IP features when calling other IP network users. Similarly, PBX users can use the features provided by the PBX when calling other PBX users. However, calls between IP and PBX users can use only a subset of the features provided by each system, and that subset is defined by the level of complexity of the voice interface between the IP network and the PBX. Similarly, IP network users can access a voice messaging system behind the PBX, but usually with a reduced set of features. If IP messaging is used, you might be able to network it with the conventional voice messaging system to some degree. The level of feature support for all these functions is defined by the protocols and interfaces by which the IP network can connect to the conventional voice network. Table 10-1 summarizes some of the more commonly used interfaces and protocols for PBX and voice mail system networking.
Table 10-1 Interfaces and Protocols for PBX and Voice Mail System Networking
Vendor Cisco Avaya
Protocols, PBX to PBX PRI - NI-2, CAS PRI - DCS, DPNSS, QSIG
Interfaces, PBX to Voice Mail SMDI, analog

Networking, Voice Mail to Voice Mail

AMIS-A 1 OctelNet AUDIX Digital Networking AMIS-A Meridian Mail Networking VPIM AMIS-A
Digital set emulation Proprietary, X.25/C-LAN
Nortel
PRI - MCDN, DPNSS, QSIG Proprietary (IVMS)
10-2
74413
EDCS-197018
Chapter 10
Migration to an IP Telephony Network Simple IP Network Migration Sequence
Table 10-1 Interfaces and Protocols for PBX and Voice Mail System Networking (continued)
Vendor Siemens
Protocols, PBX to PBX
Interfaces, PBX to Voice Mail
Networking, Voice Mail to Voice Mail

PRI - CorNet, DPNSS, QSIG PRI or BRI with proprietary extensions PRI - ABC, QSIG PRI - CCIS, QSIG unknown
PhoneMail Long Distance Networking (LDN) AMIS-A
Alcatel NEC
unknown
Proprietary Message Center Interface unknown (MCI)
1. Cisco supports AMIS-A beginning with Cisco Unity Release 3.0.
While conventional voice networks use proprietary, closed protocols internally, they can be connected to IP networks only through open protocols. This would also be the case when networking equipment from different vendors. The most powerful interfaces currently available are PRI (or QSIG) between PBXs, analog Simplified Message Desk Interface (SMDI) between PBXs and voice mail systems, and Audio Messaging Interchange Specification Analog (AMIS-A) between voice systems.
Simple IP Network Migration Sequence

The following three figures illustrate the phases in migrating from a conventional voice network to an all-IP system. Figure 10-2 shows the initial conventional voice network.
Figure 10-2 Initial Conventional Voice Network
Voice messaging system PBX
Figure 10-3 shows the migration phase, with users moving in blocks from PBX to IP network.
74414
PSTN
10-3
Chapter 10 Simple IP Network Migration Sequence
Figure 10-3 Migration Phase
Voice messaging system IP PBX Gateway V Gateway LAN IP
IP
PSTN Pilot user migration
PSTN
74415
Figure 10-4 shows the network when migration is completed and the PBX is retired.
Figure 10-4 Migration Completed
IP LAN IP
IP
Usually the transition from a conventional voice network to an IP network occurs in stages, as follows:
1.
Pilot stage the IP network is introduced, and a very limited number of users are given IP service. In this initial deployment, which often includes the telecom or IT group, users sometimes retain their conventional phones side-by-side with IP phones. Usually, however, they move immediately onto the new system. When the pilot trial is stable and satisfactory for a number of weeks, it can be expanded. User block migration a block of users is moved (usually over a weekend) from the conventional voice network to the IP network. The block can be chosen as a geographical group, a group sharing a block of directory numbers (DNs), or a community of common interest, such as the purchasing department.
2.
10-4
74416
PSTN
EDCS-197018
Chapter 10
Migration to an IP Telephony Network Reference Models for Migration Configurations
3.
Further user block migration the number of users moved in a block is determined by the maximum number of users the telecom staff can move over a weekend, and the number of weekends the telecom department plans to work. In general, migration should be completed as quickly as possible.
Of course, there are many other considerations when planning a migration, such as DN assignments, user training, billing systems, special features, fallback plans, and more.
Reference Models for Migration Configurations

This section describes four basic migration models, as depicted in Figure 10-5.
Figure 10-5 Migration Models
Model A Voice mail CallManager PBX V IP IP PBX
Model C
CallManager V
V IP IP
Voice mail
Model B
Voice mail
Model D Cisco Unity Voice mail networking
CallManager PBX V IP IP PBX
CallManager V
74417
IP
IP
The models shown in Figure 10-5 have the following characteristics:

Model A is the simplest; it is concerned only with PBX services and does not address voice messaging. Model B includes a voice messaging system behind the PBX and assumes that the voice mail system does not offer an open interface for connection to an IP network. Therefore, all voice mail traffic from the IP network must travel through the PBX. Model C includes a voice messaging system that can connect to an IP network, providing a stronger feature set for IP users. Model D introduces unified IP messaging at the same time as IP telephony, replacing a conventional PBX and voice mail combination.
10-5
Chapter 10 Reference Models for Migration Configurations
Detailed Discussion of Model A

Figure 10-6 shows the topology for model A, which includes a PBX but no voice messaging.
Figure 10-6 Migration Model A PBX Only
IP LAN V IP
IP
PSTN Migration
74418
Model A poses two main questions for consideration:

Should the trunk connections remain on the PBX until the end of the migration, or should some trunks be moved to the IP network along with users? What type of connection should be used between the PBX and the IP network?
Table 10-2 shows the feature set supported by each type of connection.
Table 10-2 Connection Types and Feature Sets Supported
Connection Type FXO/FXS E&M/R2 BRI/PRI QSIG Digital set emulation PBX WAN protocol
Calling Number No No Yes Yes Yes Yes
Called Number Yes Yes Yes Yes Yes Yes
Calling Name No No Yes Yes Yes Yes
Diversion Reason No No No Yes Yes Yes
MWI1 On/Off No No No Yes Yes Yes
Both-Ways Origination No Yes Yes Yes Yes Yes
Relative Cost Very small Small Medium to Large Large Small Large
1. MWI = Message waiting indicator
The following points briefly explain the importance of the features in Table 10-2:

Calling number, in addition to being displayed on the called phone, can be used for billing and voice mail purposes. Called number is important if the receiving switch is going to route the call directly to a phone, rather than terminating it first at an attendant. The called number is also used for voice mail.
10-6
EDCS-197018
Chapter 10
Calling name is displayed on the called phone. Diversion reason (busy, ring-no-answer) can be used by voice mail systems to play different greetings. MWI on/off can instruct the receiving switch to illuminate the message waiting indicator on a phone when the user has a new message. Without this capability on the link, MWI cannot be available on the switch remote from the voice messaging system. Both-ways origination refers to the capability to initiate and answer a call on the same trunk. This would normally be desirable for traffic purposes to avoid the need for more trunk connections.
Note
QSIG is not available in Cisco CallManager as of Release 3.1(2). PRI provides the best feature set currently available. Table 10-2 indicates which elements are normally passed across the trunk interface. Different PBXs, however, might not use the information to implement all available features for a given trunk type. Table 10-3 provides an approximate guide to feature availability when using PRI.
Table 10-3 Feature Availability with PRI
Feature Transfer Conference Calling name display Called name display Call pickup groups Music on hold Camp-on features Operator services
PBX-PBX Yes Yes Yes Yes Yes Yes Yes Yes
IP-IP Yes Yes Yes Yes Yes Yes Yes No No
IP-PBX Yes (on originators system) Yes (on originators system) Yes (can depend on PBX configuration) Yes No No Yes No No (unless a separate Cisco AVVID attendant is configured)
Calling number display Yes
If calls originate on one system, are passed to the other and then forwarded back, two channels are used on the PRI and remain in use (tromboned) until the call is torn down or released. The implication for traffic engineering in a T1 environment is that only 11 such calls could use the entire PRI link. If the trunks remain on the PBX, so that billing can be done at one point, it can be difficult to identify IP-originated calls by calling number. Perform the following configuration steps for the type A system:
Step 1
Configure the PRI link.

a. b. c.
Add the PRI gateway and configure it in Cisco CallManager. Add the PBX PRI card and cable to the IP network, and configure the PRI on the PBX. Add a Cisco CallManager route group to direct outgoing calls to the PRI trunk.
10-7
Step 2
Migrate each user.

a. b. c.
Delete the appropriate user phones in the PBX. Modify the PBX trunk routes to direct user calls to the IP network. Add user phones in Cisco CallManager.
Step 3
Move the PSTN trunks from the PBX to the IP network.

a. b. c. d. e. f.
Delete the appropriate trunks and routes from the PBX database. Add trunk groups on the PBX to direct outgoing calls to the IP network. Configure the IP gateway hardware and software. Move trunk connections to the IP network. Configure appropriate trunk groups and routes in Cisco CallManager. Configure Call Detail Recording (CDR) for the IP network.
This configuration scenario assumes that users retain the same DNs after the migration and that trunks are moved after the users have migrated. Otherwise, it would be possible to preconfigure the IP phones and to allow users to have two working phones on their desks throughout the migration period. However, most users with Direct Inward Dialing (DID) service want to keep their original DN. The following list summarizes the cost of the type A system: Required Hardware

Required Software

PRI gateway for IP network PRI card on PBX
Nothing extra on Cisco CallManager PRI software on PBX
The following list summarizes the pros and cons of the type A system: Pros

Cons
Easy and inexpensive to implement. Minimal reconfiguration of the PBX.
Without QSIG, display set users in particular will notice a lack of feature support on IP-PBX calls. Billing is difficult to reconcile across the two systems.
10-8
EDCS-197018
Chapter 10
Detailed Discussion of Model B

Figure 10-7 shows the topology for model B, which includes both a PBX and voice messaging.
Figure 10-7 Migration Model B PBX with Voice Messaging
Voice messaging system IP PBX V LAN IP
IP PSTN
74419
Migration
The considerations for telephony features in model B are the same as for model A, but the introduction of voice messaging brings a number of extra considerations. In general, voice messaging systems provide call answering and call retrieval services. They also command the PBX to switch message waiting indicators on and off, and they can provide calling services by which users can transfer themselves out of a voice mailbox to another phone. (This feature is also a function of an automated attendant, which is often built into the voice messaging system.) There are three important requirements for IP telephony applications in model B networks:
When a party calls an IP phone and the call is forwarded to voice mail, the caller should hear the IP users greeting for call answering. This can be a problem because, if the PBX sees the call from the IP network as a trunk call, it might not preserve the original called number on the call. In this case, the caller would hear the general greeting (for example, Welcome to Cisco). When IP users press their message key, they should be prompted for their password. That is, the voice messaging system should be passed the information to associate the call with a users calling number to identify the right mailbox. The MWI on the IP phone should be switched on and off to reflect the state of the users voice mailbox.
In general, none of these three features can be achieved in a simple type B system, where the link between the IP network and the PBX is PRI and where the configuration sequence for a type A system is used. However, by using a more complex configuration change on the PBX, you can achieve the first two features. This model B implementation requires configuring a phantom telephone user on the PBX. For ease of maintenance, it is convenient to choose a block of DNs that relate to the IP user DNs. For example, for IP DNs 32XX, you could create equivalent PBX phantom users of 52XX. The phantom phone is permanently forwarded to voice messaging. On the IP network, the phone is configured to forward to the phantom DN for voice messaging, with a speed-dial key on the phone to dial the phantom DN. This key can be labeled for voice messaging (except on the Cisco IP Phone 7960). Now, both call answering and message retrieval calls go straight to the users voice mailbox.
10-9
There are drawbacks with this workaround. It requires extra administration and user effort, and the IP users voice mailbox must have a different number from the DN of the phone. Also, on some PBXs, it is necessary to configure real line cards for the phantom phones. It might be easier to administer if the users PBX DN were retained on the PBX as the phantom DN during migration, and the user could be assigned a new DN on the IP network. The original DID number could be retained if the trunks are switched to the IP network and an incoming digit translation is used. However, this would perpetuate a situation in which the users DN, DID number, and voice mailbox number do not match. It is not possible for the voice messaging system to select the proper greeting (busy, no answer, or all calls) for IP users because that information is not sent across the PRI to the PBX. It is also not possible for MWI information to traverse the PRI from the PBX to the IP network. The message indication feature would, therefore, not be available to IP users in a type B system. The following configuration steps for the type B system include the workaround just described:
Step 1 Step 2 Step 3
Configure PRI link same as for type A system. Migrate each use same as for type A system. Configure the phantom DN on the PBX.
a. b. c.
Add the phantom phone to the PBX and forward it to voice mail. Configure a speed-dial key on the IP phone to access voice mail via the phantom DN. Modify the IP trunk routes to send forwarded calls to the PBX.
Step 4
Move the PSTN trunks from the PBX to the IP network same as for type A system.
The following list summarizes the cost of the type B system: Required Hardware

Required Software

The following list summarizes the pros and cons of the type B system: Pros

Cons

IP users get access to voice messaging as they migrate from the PBX. Relatively inexpensive to implement.
Same voice feature shortfall as type A systems. No MWI support for IP users. Workaround entails administration complexity and possibly extra PBX hardware.
10-10
EDCS-197018
Chapter 10
Detailed Discussion of Model C

Figure 10-8 shows the topology for model C, which includes a PBX and voice messaging, with extra Simplified Message Desk Interface (SMDI) and analog links from the voice messaging system directly to the IP network.
Figure 10-8 Model C PBX and Voice Messaging System with Separate Links to the IP Network
Voice messaging system Analog PBX
SMDI
IP V LAN IP
IP PSTN
74420
Migration
The considerations for telephony features for model C are the same as for model A. For voice messaging, model C fixes the drawbacks of model B. Because the voice messaging system deals with the PBX and the IP network as separate systems, calls that reach the IP network can be forwarded directly into voice messaging without being routed back through the PBX. This should allow all normal call answering and message retrieval functions. In addition, since the voice messaging system is connected to the IP network directly with SMDI, the voice messaging system can send MWI messages to the IP network for appropriate control of the indicators on the IP phones. For this model to work, the voice messaging system must meet two qualification:

It must be able to support two PBXs simultaneously in its database and associate each mailbox with the correct PBX so that it can send MWI information on the correct link. It must be possible to connect the IP network physically to the voice messaging system while maintaining the existing link to the PBX.
Not all voice messaging systems can support this type of integration, and customers should therefore check with their voice mail vendor before proceeding with this type of scenario. Perform the following configuration steps for the type C system:
Step 1 Step 2 Step 3 Step 4
Configure the PRI link same as for type A system. Migrate each user same as for type A system. Migrate each user in voice mail by changing the mailbox to reference the link to the IP network rather than the PBX. Move the PSTN trunks from the PBX to the IP network same as for type A system.
10-11
The following list summarizes the cost of the type C system: Required Hardware

Required Software

PRI gateway for IP network PRI card on PBX Analog gateways for IP network for voice messaging Analog cards on voice messaging system SMDI interface on voice messaging system
The following list summarizes the pros and cons of the type C system: Pros

Cons

IP users can maintain access to voice messaging as they migrate from the PBX. Relatively inexpensive to implement.
Same voice feature shortfall as type A systems. More complex administration of voice messaging system than the type B system, but simpler administration of the PBX. Ideally, DID trunks would be moved from PBX to IP network to follow the users. Otherwise, some features might be lost.
10-12
EDCS-197018
Chapter 10
Detailed Discussion of Model D

Figure 10-9 shows the topology for model D, which includes a PBX with voice messaging system that migrates to an IP network with Cisco Unity unified messaging. The discussion of this model considers only the voice messaging component of Cisco Unity.
Figure 10-9 Model D PBX with Voice Messaging and Migration to Cisco Unity
Voice messaging system IP PBX Gateway V LAN IP
IP PSTN
74421
Migration
The considerations for telephony features for model D are the same as for model A. For voice messaging, IP users are on the Cisco Unity system, while the PBX users remain on the legacy voice messaging system. When a PBX user is moved to the IP network, the voice mailbox is deleted from the legacy voice messaging system, and a new one is added on Cisco Unity. Because there is no linking between Cisco Unity and the legacy voice messaging system, the two user groups are separate and cannot interact in voice messaging. For instance, if a legacy voice messaging user has a distribution list, IP users cannot be included on it. Similarly, the reply to sender function does not work between the two groups, nor do a number of other features. If the legacy voice messaging system is to be replaced by Cisco Unity, however, this situation is only temporary. Audio Messaging Interchange Specification Analog (AMIS-A) networking of voice messaging systems is planned for a future release of Cisco Unity. When it is available, if both Cisco Unity and the legacy voice messaging system are configured for networking, it will be possible to provide basic voice mail messaging functionality across the systems (provided the legacy voice messaging system supports AMIS-A). Perform the following configuration steps for the type D system:
Configure the PRI link same as for type A system. Migrate each user same as for type A system. Migrate each user in voice mail.
a. b.
Delete the mailboxes on the legacy voice messaging system. Add users in Cisco Unity.
Step 4
Move the PSTN trunks from the PBX to the IP network same as for type A system.
10-13
The following list summarizes the cost of the type D system: Required Hardware

Required Software

The following list summarizes the pros and cons of the type D system: Pros

Cons

IP users get access to voice messaging as they migrate from the PBX. Relatively inexpensive to implement.
Same voice feature shortfall as type A systems. No voice mail interaction between legacy voice mail system and Cisco Unity. Ideally, DID trunks would be moved from PBX to IP network to follow the users. Otherwise, some features might be lost.
Cisco Digital PBX Adapter (DPA)

The Cisco Digital PBX Adapter 7630 (DPA 7630) enables you to integrate Cisco CallManager systems with Octel voice mail systems, which might also be connected to a Lucent Definity PBX system. You might want to do this if you have these existing third-party telephony systems in your network and you want to continue to use them along with your Cisco IP Telephony system. For example, you can ensure that features such as message waiting indicators (MWI) for Octel voice messages are properly set on Cisco IP Phones (connected to Cisco CallManager) and traditional telephony phones (connected to Lucent PBX systems). Using the DPA 7630, you can integrate the following systems:

Cisco CallManager Octel 200 and 300 voice messaging systems (using APIC integration) Octel 250 and 350 voice messaging systems (using FLT-A/PIC-A integration) Lucent Definity G3 PBX systems
The following sections provide an overview of the DPA 7630 and its interactions with the other components in traditional and IP telephony networks:

Understanding How the DPA 7630 Works, page 10-15 Choosing an Integration Mode, page 10-16
10-14
EDCS-197018
Chapter 10
Migration to an IP Telephony Network Cisco Digital PBX Adapter (DPA)
Understanding How the DPA 7630 Works

The Cisco DPA 7630 enables you to integrate existing Octel voice mail and Lucent PBX systems with Cisco CallManager. The DPA 7630 functions by emulating digital phones or a PBX system. This capability allows it to appear like these devices to Cisco CallManager, Octel, and Lucent systems.
Why is the DPA 7630 Needed?

If you want to migrate your telephony system from a Lucent Definity G3 PBX to Cisco CallManager, you must decide whether to do a complete cutover to Cisco CallManager or to migrate slowly. If you do a complete cutover to Cisco CallManager and Cisco Unity (Ciscos voice mail solution), you do not need the DPA 7630. However, if you are slowly migrating your systems, you might want to maintain some phones on the Lucent PBX while installing new phones on the Cisco CallManager system. You might want to use your existing Octel voice mail system with your Cisco CallManager system. In these cases, the DPA 7630 can assist your migration to Cisco CallManager.
Can I Just Use SMDI?

One difficulty with migration is that voice mail systems such as Octel were designed to integrate to only one PBX at a time. To resolve this difficulty, many systems use Simplified Message Desk Interface (SMDI), which was designed to enable integrated voice mail services to multiple clients. However, to use SMDI, the voice mail system must meet the following qualifications:

It must have sufficient database capacity to support two PBX systems simultaneously and to associate each mailbox with the correct PBX in order to send MWI information on the correct link. It must be possible to physically connect the IP network to the voice messaging system while maintaining the existing physical link to the PBX. It must support analog integration. SMDI is primarily an analog technology.
Additionally, SMDI requires reconfiguration of your existing telephony network.
What If I Cannot Use SMDI?

SMDI might not be an option for you, particularly if you are using a digital interface on Octel systems. Octel systems with digital line cards emulate digital phones, appearing to the PBX as digital extensions, referred to as per-port or PBX Integration Cards (PICs). On PIC systems, the voice and data are on the same path. MWI is set and cleared via feature access codes on dedicated ports. Because these PIC ports use proprietary interfaces, you cannot use standard interfaces to connect them to the Cisco CallManager system. However, the DPA 7630 can translate these interfaces to enable communication among the Octel, Lucent, and Cisco CallManager systems. Depending on the needs of your network, you can choose among several different integration methods.
10-15
Choosing an Integration Mode

Select one of the following integration modes, based on the needs of your IP telephony network:
Simple Used to integrate Cisco CallManager with existing Octel voice mail systems. In this solution, you are not using a Lucent PBX system, or you are choosing not to integrate it with your IP telephony system. See Using the Simple Integration Mode, page 10-16. Hybrid Used to integrate Cisco CallManager with existing Octel voice mail systems and Lucent PBX systems. See Using the Hybrid Integration Mode, page 10-17. Multiple Used to integrate the systems in larger networks using a combination of simple and hybrid scenarios, which requires multiple DPA 7630 systems. See Using the Multiple Integration Mode, page 10-18.
Using the Simple Integration Mode

In the simple integration mode, the DPA 7630 handles all processing and signaling between the Octel and Cisco CallManager systems (see Figure 10-10).
Figure 10-10 Simple Integration of Cisco CallManager and Octel Systems
Octel Voice Mail
Cisco 7630 DPA IP Gateway PSTN
IP
Cisco CallManager
10-16
74422
EDCS-197018
Chapter 10
Migration to an IP Telephony Network Cisco Digital PBX Adapter (DPA)
Using the Hybrid Integration Mode

If you want to connect Cisco CallManager to Octel voice mail and Lucent PBX systems, you must use the hybrid integration mode. In the hybrid configuration, the DPA 7630 handles processing and signaling among the Octel, Lucent, and Cisco CallManager systems (see Figure 10-11).
Figure 10-11 Hybrid Integration of Cisco CallManager, Octel, and Lucent Systems
Octel Voice Mail
Cisco DPA 7630 Cisco CallManager
Lucent PBX Gateway
Legacy PBX
74423
IP
IP
IP
10-17
Using the Multiple Integration Mode

If your system requires more than the hybrid integration mode provides, you might want to add multiple DPA 7630 systems to your network (see Figure 10-12).
Figure 10-12 Multiple Integration Using Multiple DPA 7630 Systems
Octel Voice Mail DPA 7630 in simple mode PIC
Cisco CallManager
DPA 7630 in hybrid mode
IP (skinny client control protocol)
PIC Lucent PBX PSTN
V
Gateway
Legacy PBX
You might add multiple DPA 7630 systems to your network if you are using the DPA 7630 to capacity, and you need the following capability:
More than eight MWI ports to the Lucent system. If you need more MWI ports to the Lucent system, add an additional DPA 7630 in hybrid mode. However, you cannot use all 24 ports for Lucent MWIs. You must configure the DPA 7630 by following the guidelines for the hybrid integration, using up to eight ports.
More than eight ports for call processing between the Cisco CallManager and Octel systems. If you need more than eight ports for handling calls between Cisco CallManager and the Octel systems, add another DPA 7630 in simple mode. This would provide another full 24 ports dedicated to call processing between the two systems.
Alternatively, you might also use an additional DPA 7630 to achieve a higher level of fault tolerance. In this situation, you can use two DPA 7630 devices in parallel, sharing the MWI lines between the two units. If one unit fails, the Octel system would use only the lines that were still operational, allowing voice mail to function normally.
10-18
74424
IP
IP
IP
EDCS-197018
C H A P T E R
11

This chapter describes the Computer Telephony Interface (CTI) for Cisco CallManager. The CTI provides an interface for external applications to communicate with Cisco CallManager. This chapter explains the CTI architecture and addresses scalability and redundancy issues that you should consider when designing your IP telephony network. This chapter contains the following major sections:

Cisco CallManager Application Interfaces, page 11-1 CTI Design Consideration, page 11-14 Example of CTI Provisioning for Scalability and Redundancy, page 11-27 Summary, page 11-35
Cisco CallManager Application Interfaces

Cisco CallManager contains a number of interfaces that enable communications with external applications. Figure 11-1 illustrates the following types of interfaces and some common applications that can be developed using them:
Telephony Application Programming Interface (TAPI) and Java Telephony Application Programming Interface (JTAPI) Applications connect to Cisco CallManager through Computer Telephony Interface (CTI) protocol that runs over TCP/IP for either client or server CTI applications. Common CTI applications include Unified Messaging, Call Center, E-Conferencing, and interactive voice response (IVR) systems.
Lightweight Directory Access Protocol (LDAP) This interface provides access to directory services through queries that enable Call Authentication within an enterprise application.
Call Detail Records (CDR) This interface provides access to the Cisco CallManager CDR database to record and update call statistics. Call accounting and billing applications can query the CDR by using the Open DataBase Connectivity (ODBC) application programming interface or direct Structured Query Language (SQL) calls. CDR fields contain information such as the following:
Original called party number Number of the last redirected call
11-1
Chapter 11 Cisco CallManager Application Interfaces
Duration of the call Disconnect cause code
Cisco CallManager database access Applications can query and modify device and routing information contained in the Cisco CallManager database using a Cisco SOAP-based API called the Aupair XML Layer (AXL).
EXtensible Markup Language (XML) through HyperText Transfer Protocol (HTTP) messages Cisco 7940 and 7960 IP Phones provide web client capabilities through IP Phone Services. The 133x65-pixel LCD display on the Cisco 7940 and 7960 IP Phones can display web content, thus allowing the phone to function as a web appliance. IP phone applications include the ability to view up-to-date stock quotes, airline flight status, news headlines, and personal directory searches, as just a few examples.
H.323 and Skinny Client Control Protocol (SCCP) Cisco CallManager supports H.323 or SCCP endpoints for applications that can manage end-clients such as E-Conferencing, or virtual phone applications.
You can combine these interfaces within a single application to develop enterprise applications with more robust features.
Figure 11-1 Application Interfaces in Cisco CallManager
PSTN
H.323, MGCP, SCCP
CallManager Corporate directory Call processing protocol access LDAP
V
IP WAN
Authentication
ODBC/ SQL Client endpoints H.323, SCCP CTI layer
Call acounting/ billing
SCCP XML over HTTP Internet Web server IP IP phone services
CTI (TAPI/JTAPI)
AXL over SOAP Applications/policy management
CTI applications Unified messaging Call center IVR / AA
11-2
74435
EDCS-197018
Chapter 11
CTI Applications Architecture and Design Cisco CallManager Application Interfaces
Table 11-1 lists Cisco CallManager applications and their respective application interfaces. Any other applications that use the same Cisco CallManager interface will also experience the same Cisco CallManager behavior and device or port limitations.
Table 11-1 Cisco CallManager Interfaces for Cisco IP Telephony Applications
Cisco Application Cisco IP SoftPhone Cisco Customer Response System (CRS) Cisco Unity
Cisco CallManager Application Interface CTI (TAPI) CTI (JTAPI)
Comments CRS uses the Cisco CallManager CTI to connect its Telephony Subsystem. It can use other Cisco CallManager interfaces, depending upon the developed application (for example, LDAP or ODBC). Cisco Unity is actually a TAPI application that uses a different TAPI Service Provider (TSP) than the one included with Cisco CallManager. This custom TSP translates TAPI functions to SCCP messages instead of CTIQBE. As a result, the Cisco Unity ports are treated as SCCP devices.
SCCP
Cisco Personal Assistant (PA)
CTI (JTAPI) and SCCP Cisco PA uses the CTI interface to handle incoming calls through a CTI route point. Each media session is handled by a separate SCCP provider. The remainder of this chapter focuses on the architecture, behavior, and design considerations for applications that use TAPI or JTAPI through the Cisco CallManager CTI interface.
CTI Architecture
At the system level, the Cisco CTI architecture consists of the following components, described in this section:

Cisco CallManager Server, page 11-3 CTI Application Platform, page 11-4 CTI Devices, page 11-4
Cisco CallManager Server

The Cisco CallManager server is the center of all call processing. To the application, Cisco CallManager server is the source of call requests and responses. The Cisco CallManager server contains a suite of services for enabling CTI applications.
11-3
CTI Application Platform

Each application platform requires a provider that defines the application on the Cisco CallManager server. You specify an application provider in Cisco CallManager Administration by defining a user account in the Global Directory. Figure 11-2 shows an example user account for an application provider, along with the associated CTI devices controlled by the application.
Figure 11-2 User Control Information for an Application Provider
CTI Devices
CTI applications can control any of the following devices configured in Cisco CallManager:

IP phones Applications can monitor as well as control devices such as IP phones. CTI ports CTI ports are virtual devices that act as handles to an application. For example, a Cisco IP SoftPhone connects to Cisco CallManager through a CTI port. CTI route points A CTI route point is a virtual device that can handle multiple calls simultaneously, all on the same line. Applications typically use CTI route points to hold calls before routing them. For example, a CTI route point could be a 1800 number that receives calls and routes them to the appropriate CTI ports.
The Cisco CallManager Directory Service must authenticate the CTI application before the application can initialize successfully. After authenticating the CTI application, Cisco CallManager passes a list of controlled devices, in the form of CTI device and CTI line handles, to the application. The application logic can then perform operations on this user control list. Figure 11-3 shows the CTI components and Cisco CallManager interactions with two CTI applications, one using JTAPI and the other using TAPI.
11-4
74436
EDCS-197018
Chapter 11
Figure 11-3 CTI Applications and Controlled Devices
CallManager Applications API (JTAPI) Application provider CTIQBE over TCP/IP

M
Applications API (TAPI)
TAPISVR TSP
CTI port
CTI route point
IP IP phone
74437
Application provider
Devices controllable through CTI
Both TAPI and JTAPI application platforms interface with Cisco CallManager through a translated set of CTI protocol messages (CTIQBE) passed over a TCP/IP link. (Cisco does not expose the CTIQBE message protocol for use by third-party applications.) Cisco CallManager does not distinguish between TAPI and JTAPI applications. Instead, the Cisco TAPI Service Provider (TSP), or the JTAPI implementation of it, translates the APIs called by the application to CTIQBE messages that are understood by Cisco CallManager.
CTI Manager
TAPI and JTAPI applications that use the CTI interface prior to Cisco CallManager Release 3.1 did not support redundancy among the Cisco CallManager servers in a cluster. In those earlier releases, a CTI application provider was bound to a specific Cisco CallManager server. If the assigned server failed, then the CTI application would have to close its application provider, restart its process, and authenticate and re-initialize with the backup Cisco CallManager. With Cisco CallManager Release 3.1 and later, the CTI Manager provides a number of benefits:

Load balancing CTI resource distribution across Cisco CallManager servers in a cluster Redundancy Redistribution of CTI resources across Cisco CallManager servers in a cluster during a failover condition Single CTI interface for an application provider Application connections to any Cisco CallManager server in the cluster. There is a single CTI Manager per Cisco CallManager server. Transparent cluster architecture. Applications do not have to be aware of how many Cisco CallManagers there are in the cluster.
The CTI Manager acts as an application broker and abstracts the physical binding of the application to a particular Cisco CallManager server to handle all its CTI resources. The CTI Manager keeps track of which Cisco CallManager server is assigned to the application. Thus, the application can remain unaware of which physical Cisco CallManager server is handling its CTI route points and CTI ports. Keep-alive signals, or application heartbeats, are sent between the CTI Manager and each CTI application to ensure that the system is operating normally. You can configure the heartbeat interval in the Cisco CallManager server as well as in each CTI client. (For configuration specifics, refer to the Cisco CallManager online help and the developer guides for TAPI and JTAPI, available at Cisco.com.)
11-5
The heartbeat interval is passed to the application provider during CTI initialization. It is then up to the application to send the keepalive request to the CTI Manager within the configured heartbeat interval. The CTI Manager must respond to the request within its response interval. If the CTI application fails to receive two consecutive heartbeats, it can assume that the system is down and can proceed to one of the failover scenarios described in the section on Redundancy, page 11-22. For an explanation of how the CTI Manager assigns and reassigns application resources during a failover condition, refer to the section on Redundancy, page 11-22. Operationally, the CTI Manager is a Windows 2000 service (CTIM.EXE) that you enable via the Cisco CallManager Service Activation page, as illustrated in Figure 11-4.
Figure 11-4 Cisco CallManager Service Activation Page
Two main processes (see Figure 11-5) handle call processing for a CTI application:

The Cisco CallManager Call Processing Service, CCM.EXE, performs the actual call processing and supplementary functions for the IP phone, such as setting the message waiting indicator (MWI). The CTI Manager Service, CTIM.EXE, handles all CTI messaging to and from a CTI application. All CTI messages are sent using CTIQBE over TCP/IP.
11-6
74438
EDCS-197018
Chapter 11
Figure 11-5 Relationship Between Cisco CallManager and CTI Manager
CallManager server CTI Manager (CTIM.EXE) CallManager (CCM.EXE) SDL CTI devices
Application provider CTI device control list
Directory server CTIQBE
LDAP
Application Provider CTI device control list CTI service parameters CTI application platform
74439
When a CTI application starts, it authenticates via LDAP with the Directory Service configured for the Cisco CallManager. This Directory Service can be either the DC Directory server that comes with the Cisco CallManager software or an external corporate directory containing one of the supported directory services (Microsoft Active Directory or Netscape Directory Server). Once the application successfully authenticates with the directory server, the CTI application provider is registered with the CTI Manager. A list of controlled devices associated with the application provider is passed back to the CTI application for call handling. This list of controlled devices is the same list of devices added in the Cisco CallManager User Preferences page. (Refer to the Cisco CallManager online help for configuration specifics.)
Note
In Figure 11-5, CTI Manager holds an instance of the CTI application provider. For the rest of this chapter, we refer to the Application Provider as the provider instance on the CTI Manager. Recall that the CTI Manager is an application broker, but it is not the source of CTI provisioning. The CTI Manager is, instead, the intermediary between the application and the Cisco CallManager server that you configure to allocate the CTI devices. CTI ports configured in the Cisco CallManager servers register with the CTI Manager. The CTI Manager, in turn, allocates available CTI ports to the application requesting a CTI connection. Cisco CallManager handles the actual call processing, and the CTI Manager handles CTI events to and from the application. Consequently, you provision Cisco CallManager call processing and CTI Manager processing separately, as described in CTI Manager Provisioning, page 11-8.
CTI Manager Configuration

You configure the application provider for a primary CTI Manager via the TAPI TSP or JTAPI JTPrefs client. You can enable this CTI Manager service on any one of the Cisco CallManager servers in the cluster. Currently, the TSP and JTPrefs configuration allows for two CTI Managers, a primary and a
11-7
backup, per application provider. Figure 11-6 shows a sample JTPrefs menu for configuring the primary and backup CTI Managers on the client or server JTAPI application platform. The TSP contains a similar user interface for CTI Manager configuration. Refer to the Cisco CallManager online help for more details on CTI Manager configuration and its associated service parameters.
Figure 11-6 JTAPI Application-Side CTI Manager Configuration
CTI Manager Provisioning

This section presents two different ways to provision the CTI Manager within a cluster:

Option 1: CTI Manager Handles CTI Devices Provisioned Across Different Cisco CallManager Servers, page 11-8 Option 2: CTI Application Provider Resources Dedicated to a Co-Resident CTI Manager and Cisco CallManager, page 11-11
Option 1: CTI Manager Handles CTI Devices Provisioned Across Different Cisco CallManager Servers
With Option 1, the CTI Manager is the resource manager for all of the CTI devices within a cluster. Once the CTI Manager is identified, all the other Cisco CallManager nodes within the cluster refer to the designated CTI Manager for authentication for that particular application. You might want to provision your system in this way to minimize the server impact on a Cisco CallManager node that processes calls for non-CTI devices. One advantage of using Option 1 is the ability to load balance the applications CTI devices across multiple Cisco CallManager nodes within a cluster. Figure 11-7 illustrates this point with a CTI Manager (CTIM) that manages devices provisioned on different Cisco CallManager (CCM) nodes within the cluster.
11-8
74440
EDCS-197018
Chapter 11
Figure 11-7 CTI Manager Handling Devices on Different Servers (Option 1)
CallManager cluster CallManager server (CM1) CTIM App provider (AP1) CTIQBE d1 d2 CCM AP1 d1 d2 CCM d2 d1 d4 CTIM CallManager server (CM2)
App provider (AP2) CTIQBE d3 d4
CallManager server (CM3) AP2 d3 d4 CCM d3 CTIM
Logical CTI handle to configured CTI device
As illustrated in Figure 11-7, the CTI Manager can service multiple CTI application providers. In this example, the CTI Manager service within CM1 contains two CTI applications with their application providers. The devices, however, are distributed to CCM.EXE processes residing on different Cisco CallManager servers. In this case, the application provider AP1 with the CTI device d1 is provisioned from the CCM.EXE process on Cisco CallManager server CM2, and a second CTI device, d2, is provisioned from the co-resident CCM.EXE process on Cisco CallManager server CM1. Figure 11-8 shows how you could accomplish this distribution by using Cisco CallManager groups and device pools.
74441
Configured CTI device
11-9
Figure 11-8 Distributing CTI Resources Across Different Cisco CallManager Servers Within a Cluster
Application side
Call processing side
CTI application Application provider
CTIM 1 (co-resident in CM1) Application provider 1 CTI devices Device pool 1 CallManager group A 2 1 CTI devices Device pool 2 CallManager group B 2
CallManager cluster CM1

M
CM2
M
CM backup
M
74442
In Figure 11-8, CTIM 1 is the CTI Manager service enabled in the CM1 server. (It is depicted as a box outside of the CM1 node for simplicity.) As previously mentioned, the CTI application retrieves its list of controlled CTI devices from its User Preference configuration. A logical handle to these devices is passed back to the application. These controlled devices can be grouped into device pools and assigned to different Cisco CallManager groups. Cisco CallManager groups, in turn, are assigned a priority of Cisco CallManager hardware servers for their resources. This means of distributing resources is similar to the way you can provision IP phone resources in Cisco CallManager. For more information about configuring device pools, refer to the Cisco CallManager online help. In Figure 11-8, the CTI application can allocate a number of its devices, via Device Pool 1 and Cisco CallManager Group A, to Cisco CallManager CM1. Similarly, the application can have another group of CTI devices assigned, via Device Pool 2 and Cisco CallManager Group B, to CM2. This configuration splits the resources from one provider across different Cisco CallManager servers. Option 1 is limited in the number of CTI connections it can handle for event processing and resource handling. As a result, this provisioning model is suited for small to medium sized solutions that contain less than 1200 CTI connections. For larger systems, consider Option 2.
11-10
EDCS-197018
Chapter 11
Option 2: CTI Application Provider Resources Dedicated to a Co-Resident CTI Manager and Cisco CallManager
Figure 11-9 shows the CTI Manager (CTIM) and Cisco CallManager (CCM) services enabled on the same server. In this configuration, the CTI application performs all of its CTI device provisioning on a single Cisco CallManager server running both the Cisco CallManager and CTI Manager services. The same server handles the call processing and CTI messaging for the application.
Figure 11-9 CTI Application Provider Resources Dedicated to a Co-Resident CTI Manager and Cisco CallManager (Option 2)
CallManager cluster CM server CTIQBE CTIM CTI application 1 CM server Application provider CTIM CCM CM server CTIQBE CTIM CCM CCM
CTI application 2 Application provider
CTI application 3 Application provider
Note
It is also possible to configure a Media Convergence Server (MCS) with only the CTI Manager service enabled and to dedicate that MCS to handle CTI events for all CTI applications configured in that Cisco CallManager cluster. This configuration, however, has not been tested and is not supported at this time. Whether to choose Option 1 or Option 2 depends on the total number of CTI devices needed for your solution. Figure 11-10 shows the decision tree to consider for your choice.
74443
11-11
Figure 11-10 CTI Provisioning Options
Determine total # of CTI controlled devices needed for the solution
No
Total CTI controlled devices > 1200 ?
Yes
CTI manager option 1 1 CTIM for the entire cluster Choose the least provisioned CM server in the cluster for the primary CTIM Choose the CTI manager co-resident on the hot standby backup server
Ensuring Normal Operations

Keep-alive signals, or application heartbeats, are sent between the CTI Manager and each CTI application to ensure that the system is operating normally. You can configure the heartbeat interval in the Cisco CallManager server as well as in each CTI client. (For configuration specifics, refer to the Cisco CallManager online help and the developer guides for TAPI and JTAPI, available at Cisco.com.) The heartbeat interval is passed to the application provider during CTI initialization. It is then up to the application to send the keepalive request to the CTI Manager within the configured heartbeat interval. The CTI Manager must respond to the request within its response interval. If the CTI application fails to receive two consecutive heartbeats, it can assume that the system is down and can proceed to one of the failover scenarios described in the section on Redundancy, page 11-22. For an explanation of how the CTI Manager assigns and reassigns application resources during a failover condition, refer to the section on Redundancy, page 11-22.
CTI Redundancy
CTI redundancy is preserved in the following scenarios:

Failure of Cisco CallManager Server Handling the Application CTI Device(s), page 11-13 Failure of CTI Manager, page 11-13 Failure of CTI Application, page 11-14
Regardless of the failure scenario, the following conditions apply during failover:

Calls that are already connected stay connected. Calls that already have a media stream in session are dropped.
11-12
EDCS-197018
74444
CTI manager option 2 1 CTIM per active CM server configured to handle CTI devices Equally provision CTI devices across active CM servers within the cluster Multiple providers or connections to different CTIMs Choose the CTI manager co-resident on the hot standby backup server CTI application dedicates all of its provisioned devices to 1 co-resident CM/CTI Manager server
Chapter 11
Calls in progress (not connected yet) are lost. Calls that are already connected at the time of failure are redirected to the Call Forward on Failure (CFoF) number of the failed device. New incoming calls to the failed Cisco CallManager server are routed to the Call Forward No Answer (CFNA) number of the failed device.
Failure of Cisco CallManager Server Handling the Application CTI Device(s)

This scenario involves a failure of the Cisco CallManager assigned to handle the CTI connection to the application. The application is not aware of which Cisco CallManager server is handling the CTI connection, and the CTI Manager is responsible for determining which CTI port failed. When a failure occurs, the CTI Manager sends an OUT_OF_SERVICE message to notify the application that the CTI device is out of service. While the application handles this event, the CTI Manager contacts the next Cisco CallManager server in the CTI port priority list. The CTI Manager determines the secondary Cisco CallManager server from the Cisco CallManager group list configuration, and it re-registers the CTI devices from the failed Cisco CallManager service to the secondary Cisco CallManager service. After all of the CTI devices are re-registered to the secondary Cisco CallManager service, the CTI Manager sends an IN_SERVICE message back to the application. The new CTI connection is restored with the application for processing calls. Basically, IP phones will re-register with their primary Cisco CallManager, while CTI ports and route points will be facilitated by the CTI Manager. Throughout this recovery, the application is not aware of which Cisco CallManager server is now handling the CTI devices, but the CTI Manager is aware of this information. The application knows only that resources are now available to handle calls.
Failure of CTI Manager

This scenario involves a failure of the CTI Manager (CTIM) handling all of the CTI connections for the application provider, as illustrated in Figure 11-11.
Figure 11-11 Example of CTI Manager Failover
CTI application
CTIM primary
CallManager cluster CM server 1 CTIM primary CCM
CTI device CTI device CTI device CTIM backup
CTI device failover
CTI device CTI device CTI device
CM server 2 CTIM backup CCM
74445
11-13
Chapter 11 CTI Design Consideration
If the CTI Manager fails, JTAPI, TAPI, or applications directly connected to CTI can connect to another CTI Manager in the cluster to resume operations. All initialization must be redone at the new CTI Manager. When the CTI Manager fails, the CTI application re-registers with the backup CTI Manager that is specified in its TSP configuration.
Failure of CTI Application

When an application fails (provider closed by CTI Manager or CTI Manager failure), the following conditions apply:
Calls at CTI ports and route points in the connected state (not yet terminated) are redirected to their configured Call Forward on Failure (CFoF) number. You specify the CFoF number in the CTI port and route point configuration in Cisco CallManager Administration, in the same place where you configure the other forward numbers (no answer and busy). New calls to CTI ports and route points that are not opened by an application are routed to their Call Forward No Answer (CFNA) number.
CTI Fail-Back
In CTI fail-back, CTI devices re-register with their original primary Cisco CallManager or CTI Manager server once the primary server becomes operational again. CTI devices do not fail back to their primary server until all servers in the cluster are not actively processing calls. This idle state might never occur for some sites that are continuously busy processing calls. In such a case, you will have to schedule manual re-initialization during a planned maintenance period.
CTI Design Consideration

This section focuses on the following CTI design considerations:

Scalability, page 11-14 Redundancy, page 11-22 Quality of Service, page 11-26
Scalability
Scalability of CTI applications involves two main aspects:
Application Scalability, page 11-15

How many CTI ports or devices are needed to support the application? What is the maximum number of CTI ports or devices required per application? If the application is server based, can the provisioned CTI devices be off-loaded to other servers
through some load balancing scheme?
Cisco CallManager Scalability, page 11-15

Are there any other basic services running on the server? Example services include, but are not
limited to, the CTI Manager, music on hold (MOH), User Login Service, IP Voice Media Services, and the Telephony Call Dispatcher (TCD).
What other non-CTI devices are already allocated on the Cisco CallManager server?
11-14
EDCS-197018
Chapter 11
CTI Applications Architecture and Design CTI Design Consideration
Application Scalability
Application scalability entails device limits on the application client or application server platform. CTI applications that interface with Cisco CallManager request one or more of the following resources:

CTI route points CTI ports IP phones controlled by third-party applications (Examples include monitoring and controlling of agent phones within a call center.)
Each type of application has different resource requirements based on the nature of the application. For example, an IP-IVR application typically requires one CTI route point and a certain number of CTI ports. Although an IP-ICD application uses the same hardware platform, it might include a route point, a number of CTI ports, and possibly third-party control of IP phones to monitor an agent status.
Cisco CallManager Scalability

Once you have determined which CTI resources are needed to run the application, you can determine how many Cisco CallManager resources are needed by performing the following steps:
Step 1
Determine the total number of CTI devices (CTI route points, CTI ports, and third-party controlled IP phones) needed per application server. Table 11-2 lists some Cisco applications and the types of Cisco CallManager CTI devices needed for each application.
Step 2
Estimate the average number of Busy Hour Call Attempts (BHCA) per device. You can estimate BHCA for your enterprise through traffic engineering or PBX call statistics. If these baseline measurement tools are not available, you can use the average metrics shown in Table 11-3. Note that these numbers do not apply directly for all solutions. Use them only as a baseline estimate, and reassess capacity by monitoring the Voice over IP (VoIP) network. Always over-provision the BHCA rate if you are uncertain about the campus telephony environment.
Step 3
Use the formula in Figure 11-12 to determine the package weight of the application CTI devices assigned to the same device pool.
Table 11-2
CTI Device Requirements for Cisco Applications
Application Cisco IP SoftPhone Cisco Personal Assistant Cisco Customer Response Platform
Cisco CallManager CTI Interface TAPI JTAPI
CTI Devices Required for the Application CTI port CTI route point Skinny Client Control Protocol (SCCP) port
Number of Devices Required per Client or Server Average BHCA per Application Device 1 Varies Varies 1 per service Varies Varies Varies 6 Varies
JTAPI
CTI route point CTI port
11-15
Table 11-3
Average BHCA for Various CTI Devices
Device CTI port (client) CTI port (server)
Average BHCA 6 Varies
Comments Cisco IP SoftPhone is an example of a CTI client port. A CTI port on the IP-IVR is an example of a CTI server port. The average BHCA on the CTI server port depends on the number of ports associated with a CTI route point. The average BHCA for a CTI route point depends on the number of calls expected by the enterprise application. For example, an ACD application for a five-person help desk on a 100-user campus will probably have a much lower BHCA rate than a 50-person help desk of a 5000-user campus. One example of a third-party controlled IP phone is a Cisco IP Softphone that is assigned to a users hardware IP phone.
CTI route point
Varies
Third-party controlled IP phone
Figure 11-12 Formula for Calculating Package Weight
Package Weight =
(
Where:
Base Device Weight BHCA per Controlled Device Number of Devices CTI Call Handling Multiplier BHCA Factor
Base Device Weight = 1 for each IP phone 2 for each CTI port 2 for each CTI route point 3 for each IP phone controlled by a CTI application BHCA Factor increases by 1 for every 6 BHCA. For example, BHCA Factor = 1 if BHCA is <= 6 2 if BHCA is between 7 and 12 3 if BHCA is between 13 and 18 and so forth CTI Call Handling Multiplier = 1 for simple call 1 for redirected call 2 for blind transfer 2 for conference
In simpler terms, the CTI package weight is the sum of the individual device weights for all the devices required to support the application or service function. Refer to the chapter on Call Processing with Cisco CallManager for general considerations on device weights and system scalability.
11-16
EDCS-197018
Chapter 11
The CTI Call Handling Multiplier in Figure 11-12 accounts for the CTI memory and processing overhead required to handle transfer and conferencing operations during a call. Possible settings for the CTI Call Handling Multiplier include:
Simple call The CTI device handles call setup or teardown of an inbound or outbound call. The CTI device does not perform any supplementary call operations (such as three-way conference) for this type of call. Redirected call The CTI device receives an incoming call and redirects the call to another CTI device without establishing a connection with the incoming call. CTI route points commonly issue redirect messages from incoming calls to another device. Blind transfer The CTI device answers an incoming call and establishes a connect session. The CTI device then issues a blind transfer of the call to the desired extension. Conference Also known as transfer with consult or supervised transfer.
To determine whether you need to use the CTI Call Handling Multiplier, you must know in advance what the particular CTI application does. For example, a voice portal application may just receive incoming calls for its session and then disconnect the call. This voice portal application does not need a call transfer multiplier because there is only one connection session. An Automated Attendant (AA) application, however, receives incoming calls and transfers them to other phone extensions. In this case, you would have to include a factor of 2 for the additional messaging required to process a call transfer for every incoming call.
Device Weight Calculation for CTI Route Point with Assigned CTI Ports
The package weight calculation shown in Figure 11-12 accounts for the base device weight of a CTI route point (RP) with no assigned CTI ports. This calculation would apply to applications such as Cisco Intelligent Contact Manager (ICM), where you can configure a route point without associated CTI ports. In most cases, however, applications such as IP-IVR contain CTI route points with associated CTI ports. In those cases, the formula in Figure 11-13 yields a more accurate calculation of the route point device weight.
Figure 11-13 Formula for Calculating Route Point Device Weight with Assigned CTI Ports Route Point with CTI Port Device Weight = Base Device Weight
(All RP Controlled Devices BHCA per Controlled Device) CTI Call Handling Multiplier
BHCA Factor
Where: Route Point Base Device Weight = ( (CTI RP Base Weight = 2) * BHCA Factor * Call Handling Multiplier)
For example, if a CTI server application has one route point and 10 assigned CTI ports, the total package weight of the application would be: [1 Device * CTI Route Point with CTI port Device Weight] + [10 Devices * CTI port Device Weight] The CTI route point device weight calculation requires the addition of the assigned CTI ports, even though we have already accounted for the device weight for each CTI port, because of the way the CTI route point operates. The CTI route point handles two sets of CTI messages, illustrated in Figure 11-14:

The routed call from the PSTN via Cisco CallManager The redirected call to the available CTI port
11-17
Figure 11-14 Message Paths for CTI Route Point
Route point establishes CTIQBE call establishment messages CM server CTIM Route point CCM
Route point establishes CTIQBE call "Redirect" messages
CTI port
CTI port establishes CTIQBE call establishment messages
The CTI route point in this case acts almost as a tandem call router, except that the call transaction occurs through CTI messages between the CIsco CallManager server and the application. Figure 11-14 shows two sets of messages for the CTI port to emphasize the point that, even if the CTI port is assigned to the route point, Cisco CallManager still treats that CTI port as a separate entity.
Device Weight Calculation for CTI Route Point with Assigned SCCP Ports
Generally, the CTI route point acts as a grouping of other device types. For example, in the Cisco Personal Assistant (PA) architecture, the route point handles incoming calls, authenticates the user, and then redirects the call to a PA session that is controlled with Skinny Client Control Protocol (SCCP) ports. This operation is different than the IP-IVR, which redirects calls to assigned CTI ports for each IVR session, but the weight calculation for the CTI route point is similar in both cases, as illustrated in Figure 11-15.
Figure 11-15 Formula for Calculating Route Point Device Weight with Assigned SCCP Ports Route Point with CTI Port Device Weight = Route Point Base Device Weight + (Device Weights of All SCCP Ports Assigned to the Route Point)
Where: Route Point Base Device Weight = ((CTI RP Base Weight = 2) * BHCA Factor * Call Handling Multiplier)
11-18
EDCS-197018
74446
Chapter 11
CTI Connection Limits

In addition to the package weight calculations, you have to consider the hard limits supported for CTI connections on an individual Cisco CallManager server and within a Cisco CallManager cluster. Table 11-4 lists those limits.
Table 11-4 Limits for Cisco CallManager CTI Connections
Device or Feature
Maximum Number Supported by Cisco CallManager
Comments
CTI connections or devices per 800 Cisco CallManager server CTI connections or devices per 3200 Cisco CallManager cluster CTI devices per application provider (JTAPI or TAPI) Active Cisco CallManager servers per cluster 2000 See the explanation following this table. This number includes all CTI devices on one application provider, even if the devices are distributed across the Cisco CallManager servers in the cluster. A server is the active Cisco CallManager server if it is currently running CCM.EXE for call processing and is generating intra-cluster communication signaling (ICCS).
Note that the maximum number of CTI connections per cluster is not strictly proportional to the maximum number of CTI connections per server. The maximum limit for the entire cluster is reduced somewhat to account for intra-cluster messaging between the CTI Manager and the other Cisco CallManager servers in the cluster. For more information on the CTI Manager, see Redundancy, page 11-22. Also, the maximum number of 3200 CTI connections in a cluster is a best-case scenario that assumes the Cisco CallManager servers are configured with only CTI client ports processing an average of 6 BHCA per port. It does not consider mixed configurations with IP phones, gateways, or other supported Cisco CallManager devices. To illustrate, consider two cases of CTI provisioning for a cluster of four active Cisco CallManager servers. Assume that the CTI devices are equally distributed across the four servers, with each server having 800 CTI connections. In the first case, assume that all of the CTI ports are processing an average of 6 BHCA. In the second case, assume that all of the CTI ports are processing an average of 30 BHCA. Figure 11-16 shows the device weight calculations for these two cases.
11-19
Figure 11-16 Device Weight Calculations for Two Example Clusters
Case 1: 3200 CTI Connections @ 6 BHCA Total Device Weight for a cluster 3200 Connections * [(Base Device Weight = 3) * (BHCA Factor = 6/6 =1)] = 3200 * 3 = 9,600 Ok. Within 20,000 device weight limit per cluster
Case 2: 3200 CTI Connections @ 30 BHCA Total Device Weight for a cluster 3200 Connections * [(Base Device Weight = 3) * (BHCA Factor = 30/6 =5)] = 3200 * 15 = 48,000 Exceeds max of 20,000 device weight per cluster
The first case in Figure 11-16 is within the device weight limit of 20,000 units for an entire Cisco CallManager cluster, as specified in the chapter on Call Processing with Cisco CallManager. In the second case, increasing the average BHCA per CTI connection from 6 to 30 yields a device weight that exceeds the maximum allowed for a cluster. To bring the second case into compliance with the device weight limits, you could either decrease the number of CTI connections while leaving the BHCA rate unchanged, or decrease the average BHCA for each CTI port.
Package Weight Calculation Example

The example in this section uses an IP-IVR application that runs one application script, or IVR service. Details of IVR script development and configuration are beyond the scope of this document. Refer to the Customer Response Applications Developers Guide and the Customer Response Applications Administrators Guide (available online at Cisco.com) for technical details on the IP-IVR environment. For this simple example, assume the following about the IP-IVR application:

The IP-IVR application has one main directory number to handle all incoming calls. The application supports a maximum of 10 simultaneous sessions. The application must be able to handle calls at a rate of 30 BHCA. The application runs on a dedicated MCS-7835 application server.
Based on the above assumptions, we can determine that the IP-IVR application requires the following resources from Cisco CallManager:

One CTI route point to handle the incoming calls at the main directory number. Ten CTI ports assigned to the CTI route point. The CTI route point routes the calls to its allocated CTI ports based on port availability. The requirement is for the CTI route point to process approximately 30 calls per hour, which is an average of 3 BHCA per assigned CTI port. The assumption for this example is that all CTI ports are handling approximately the same connection time per session.
Table 11-5 shows the resource requirements and package weight calculations for this example. The table lists the required device types, their average BHCA, and the package weight formula used to determine the weight of each device required for the application.
11-20
74447
EDCS-197018
Chapter 11
Table 11-5
Package Weight Calculations for Each Device Type
Device Type CTI ports
Number of Devices 10
Average BHCA 3
Device Weight 20
Comments

BHCA Factor = (3/6) <= 1 Device Weight = 10 Devices * (2=CTI port Base Weight) * (1=BHCA Factor) = 20 BHCA Factor = 30/6 = 5 Device Weight = [(1 Device * 2=CTI Route Point Base Weight * 5=BHCA Factor) + (20=CTI port Device Weight)] = 30
CTI route point
30
30
Total for all devices 11
50
This is the total package weight for this IP-IVR single-service example.
The actual package weight for the application is the sum of all the device weights required to support the application because the IP-IVR application needs both CTI route points and CTI ports in order to operate. Therefore, for the IP-IVR we bundle the required devices in one device pool and treat the bundle as one entity. The section on Redundancy, page 11-22, gives a more comprehensive example of calculating package weights for capacity planning and failover design.
Grouping CTI devices

After determining which CTI resources you need, the next step is to group these devices for distribution across the Cisco CallManager servers in the cluster. You assign the CTI ports and route points to a Cisco CallManager device pool, similar to the way you assign the IP phones to their respective device pools. You then assign the device pool to a Cisco CallManager group, which is a prioritized list of the Cisco CallManager servers in a cluster that handle the controlled devices. The group list determines which Cisco CallManager server is the primary server for the group and which is the backup. Refer to the Cisco CallManager online help for more information on configuring device pools and Cisco CallManager groups. Figure 11-17 illustrates a device pool for CTI devices. The CTI Manager services CTIM Primary and CTIM Backup run on Cisco CallManager servers CM1 Primary and CM2 Backup, respectively, but are shown as separate blocks in this figure for clarity.
Figure 11-17 Device Pool Provisioning
Application provider CTIM primary

M
CallManager device pool Primary CM server
CallManager group
CTI route points
CTI route points
CM primary Secondary CM server

M
CTI ports
M
CTI ports CTIM backup
CM backup
74448
CTI application
11-21
In Figure 11-17, the application could be something like an IP-IVR that uses the route point as its main number and the CTI ports for its IP-IVR sessions. Assume that the CTI application in this example has already successfully authenticated with the Directory Server and registered its CTI devices. The application provider contains handles that are mapped to the device pool DP1, and DP1 is assigned to the Cisco CallManager group with CM1 Primary as the primary server. While CTIM Primary handles CTI messages to the application, it is CM1 Primary that does the actual call processing for all of the devices grouped within DP1. It is important to keep in mind that the CTI Manager is not a repository of CTI devices. Rather, the CTI Manager acts as the intermediary broker, keeping track of which assigned Cisco CallManager server is handling the CTI resources configured for a particular application. Therefore, even though the CTI application directly interfaces with the CTI Manager, you must still know which Cisco CallManager server to configure with the CTI devices for the application.
Redundancy
This section explains how to chose and provision CTI resources to ensure high availability. This section includes the following topics:

General Redundancy Considerations, page 11-22 Redundancy Considerations for Single-Site Call Processing Deployments, page 11-23 Redundancy Considerations for a Multi-Site WAN with Centralized Call Processing, page 11-23 Redundancy Considerations for a Multi-Site WAN with Distributed Call Processing, page 11-25
General Redundancy Considerations

Perform the following steps to provision CTI devices for redundancy:
Determine the number of CTI ports and route points needed for the CTI application. Calculate the CTI package weight for the application, as described in Cisco CallManager Scalability, page 11-15. Follow the same system design conventions that you used to provide IP phone redundancy. The main difference is that, during a failover condition, the entire package weight of the CTI device group shifts from the primary Cisco CallManager server to the backup server.
Note
You also need to consider the affect of other services that are running on the same server as the CTI Manager. These services include music on hold, Trivial File Transfer Protocol (TFTP), Extension Mobility, and others. While these other services do not affect the value of the CTI device weight, they can cause a performance impact that reduces the call processing rate on that server. Refer to the chapter on Call Processing with Cisco CallManager for more details.
11-22
EDCS-197018
Chapter 11
In addition to the general redundancy considerations listed in this section, there are particular considerations for the IP telephony deployment model you are using, as described in the following sections:

Redundancy Considerations for Single-Site Call Processing Deployments, page 11-23 Redundancy Considerations for a Multi-Site WAN with Centralized Call Processing, page 11-23 Redundancy Considerations for a Multi-Site WAN with Distributed Call Processing, page 11-25
Redundancy Considerations for Single-Site Call Processing Deployments

In the single-site call processing model, local calls use the local campus network and calls to remote or external sites use the Public Switched Telephone Network (PSTN) through a voice gateway. No calls are processed over the IP WAN. Cisco recommends the following CTI guidelines for the single-site model:

Install CTI applications on the same network segment as the Cisco CallManager cluster. Follow the general CTI redundancy design considerations listed in General Redundancy Considerations, page 11-22.
Redundancy Considerations for a Multi-Site WAN with Centralized Call Processing

A multi-site WAN deployment with centralized call processing consists of a central site that houses the Cisco CallManager cluster and remote branches that contain the peripherals (such as IP phones, CTI connections, and gateways), which interface with the central site through the IP WAN connection. Refer to the chapter on Call Processing with Cisco CallManager for more details. Cisco recommends the following CTI guidelines for a multi-site WAN deployment with centralized call processing:
At the central site: Follow the single-site CTI guidelines listed in Redundancy Considerations for Single-Site Call Processing Deployments, page 11-23.
At the remote branch sites: Because all remote branches connect to the central site, all CTI connections are lost if the IP WAN link is broken, and there would be no application redundancy in this configuration. To maintain a limited connection to the central site, use the Survivable Remote Site Telephony (SRST) feature, illustrated in Figure 11-18.
11-23
Figure 11-18 SRST in a Multi-Site WAN with Centralized Call Processing
Central site CRA CMCTI

M
Branch office
CMCTI
M
2 SoftPhone
SoftPhone IP IP WAN IP IP
CMCTI IP IP IP
74449
PSTN
V
SRST
Figure 11-18 depicts the following scenario:
At the Central Site:

Cisco CallManager #1 is the primary CTI Manager. Cisco CallManager #2 is the backup CTI Manager. According to general design guidelines, the
CTI backup server is also the Cisco CallManager database publisher for the cluster.
At the remote Branch Office:

Each remote site contains a router that supports the SRST feature. SRST at each remote site consists of a simple interactive voice response (IVR) or automated
attendant (AA) script within Flash memory to handle remote survivability.

SRST provides both IP WAN and PSTN connectivity between the remote sites and the Central
Site. You can also provide a backup ISDN connection to the central site to preserve data connectivity, but do not use an ISDN connection for voice connectivity. If you want to use IP Phone Services to preserve data connectivity, configure the SRST access lists to permit HTTP traffic to access Cisco CallManager for redirection to the services location. If the IP WAN link fails for any reason, the following behavior occurs:

At the central site, the IP SoftPhone and applications server continue normal operation. At the remote office, the SoftPhone is no longer operational because it has lost its link to both the primary and backup CTI Managers at the central site. IP Phone Services are treated as network data traffic. These services can use an ISDN Dial on Demand Routing (DDR) backup, using the same link as data traffic, to reach the Cisco CallManager at the Central Site. To use this type of ISDN backup, you must configure the Cisco IOS access lists to allow HTTP traffic to pass through the ISDN DDR.
11-24
EDCS-197018
Chapter 11
Incoming calls to the remote branches are routed to the IP Phones. The IVR or AA scripts activated within SRST handle incoming calls from the PSTN and route them to the designated CTI route point phone number. For technical details on developing and configuring IVR scripts for SRST, refer to Configuring Interactive Voice Response for Cisco Access Platforms, available at http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5400/sw_conf/ios_121/pull_i vr.htm
SRST routes calls from remote branch site IP phones to central site IP phones through the PSTN.
When the IP WAN link is re-established, the following behavior occurs:

SRST reverts back to pass-through mode. All AA and IVR calls are processed by the applications server at the central site. All calls between IP phones at the central and remote sites use the IP WAN. IP Phone Services use the IP WAN for initial service requests.
Redundancy Considerations for a Multi-Site WAN with Distributed Call Processing

A multi-site WAN deployment with distributed call processing contains a separate Cisco CallManager cluster at each site, as shown in Figure 11-19. A gatekeeper manages call admission control between the sites. Refer to the chapter on IP Telephony Deployment Models for overall design considerations. For each site in the distributed call processing deployment, follow the single-site CTI guidelines listed in Redundancy Considerations for Single-Site Call Processing Deployments, page 11-23.
11-25
Figure 11-19 Multi-Site WAN Deployment with Distributed Call Processing
Site B
B Site A P
M M M M M
B
M M M M M
V
P
IP IP
PSTN
DSP
IP
IP IP IP
Site C
DSP IP WAN (Primary voice path) P

M M
B
M M M
P = Primary CTIM B = Backup CTIM

M M M M M
Gatekeeper
IP IP
74450
= Cisco CallManager cluster or ICS 7750 per site
DSP
IP
Quality of Service
Cisco CallManager Administration allows you to modify the service parameters that control quality of service (QoS) settings for all CTI applications that use the Cisco CallManager CTI. Table 11-6 lists the service parameters for the CTI.
11-26
EDCS-197018
Chapter 11
CTI Applications Architecture and Design Example of CTI Provisioning for Scalability and Redundancy
Table 11-6
Service Parameters that Control QoS for the CTI
Service Parameter IpTosCm2Cm
Default Value 3
Description and Comments This parameter specifies the class of service (CoS) for IP packets sent and received between Cisco CallManagers. Valid values for IpTosCm2Cm are 0 to 7, with 0 being the lowest priority and 7 being the highest. Each value represents a particular CoS, as follows: 0 1 2 3 4 5 6 7 = routine = priority = immediate = flash = flashover = critical = internet = network
IpTosCm2Dvce
This parameter specifies the class of service (CoS) for IP packets sent and received between the CTI Manager and Cisco CallManager. Valid values for IpTosCm2Dvce are 0 to 7, with 0 being the lowest priority and 7 being the highest. Each value represents a particular CoS, as follows: 0 1 2 3 4 5 6 7 = routine = priority = immediate = flash = flashover = critical = internet = network
TosBitPosition
This service parameter specifies which bit (0 to 4) to set in the IP type of service (ToS) settings to make them compatible with DIFF-SERV (Differentiated Service).
Note
Modifying the CTI service parameters can adversely affect your network. Do not change these parameters unless your network has a comprehensive QoS design and deployment plan. For more information on QoS design, refer to the QoS Policy Manager documentation available at Cisco.com.
Example of CTI Provisioning for Scalability and Redundancy

This section presents a comprehensive example of CTI provisioning that uses many of the concepts and guidelines explained previously in this chapter. The example includes the following topics:

System Profile, page 11-28 Design Assumptions, page 11-28 Design Approach, page 11-29
11-27
Chapter 11 Example of CTI Provisioning for Scalability and Redundancy
System Profile
This example uses a single-site deployment of 4000 IP phones and two Cisco CallManager servers, CM1 and CM2. The cluster also contains a dedicated backup Cisco CallManager server, CMBK. CM1 and CM2 both process calls for the IP phones on the campus. CMBK becomes active only if one of the other serves fails. The goal of this example is to integrate an IP-based IVR application with Automated Attendant functionality and 100 Cisco IP SoftPhones into the system, as illustrated in Figure 11-20.
Figure 11-20 Example of Single-Site Deployment
IVR application
CM cluster
M M M
4000 IP phones CM1 IP CM2 CM backup IP IP
Design Assumptions
For this example, assume the following IVR requirements:

Must be able to process calls at a rate of 500 BHCA with a Grade of Service at 1 in 1000 (or .001). Must provide redundancy All calls into the IVR have the option to be transferred to a user extension or to the operator
The following assumptions also apply to this example:

The IVR call flow and menu prompts have already been designed. The average IVR session time is 3 minutes. The IVR application uses CTI route points to handle main directory numbers and CTI ports for each individual IVR session. One standalone IVR server can process a maximum of 60 IVR ports. All IP phones and SoftPhones process an average of 6 Busy Hour Call Completions (BHCCs).
11-28
74451
100 SoftPhones
EDCS-197018
Chapter 11
Design Approach
The basic design approach, as described previously, consists of the following steps:

Identify CTI Resources, page 11-29 Calculate Package Weights for Each Application, page 11-29 Group the CTI Devices into Device Pools, page 11-31 Provision the CTI Resources on the Cisco CallManager and CTI Manager Servers, page 11-31 Provision Backup Servers for Failover Conditions, page 11-33
Identify CTI Resources

The call handling requirements to satisfy in this example are 500 BHCA at a .001 Grade of Service and an average handling time of 3 minutes. Using Erlang B calculations, we can determine that we need approximately 36 IVR ports to meet these call requirements. (Erlang B calculations are outside the scope of this chapter and are not covered here.) These calculations also indicate that each IVR port should be able to handle an average of 500/36, or approximately 14 BHCA. Therefore, the example system needs 36 CTI ports, each port processing an average of 14 BHCA in order to satisfy the requirements of an IVR application handling 500 BHCA. If there is a main directory number for the IVR ports, then we can group these IVR ports under a common route point. We could also bundle all 36 CTI ports under one common route point, but this arrangement would not provide redundancy. To provide CTI load balancing and redundancy, we can provision the CTI ports equally between two route points. Thus, this example IVR application has the following CTI resource requirements:

2 route points 36 CTI ports
Calculate Package Weights for Each Application

Table 11-7 summarizes the package weight calculations for each device pool in the example configuration.
Table 11-7 Package Weight Calculations for Each Device Pool
Device Pool 1
Device Type IP phones
Average BHCA 6
Package Weight 2000
Comments

BHCA = 1 per device BHCA Factor = (6/6) = 1 Device weight (2000 Devices * 1=CTI port Base Weight * 1=BHCA Factor) = 2000 BHCA = 1 per device BHCA Factor = (6/6) = 1 Device weight (2000 Devices * 1=CTI port Base Weight * 1=BHCA Factor) = 2000
IP phones
2000
2000
11-29
Table 11-7
Package Weight Calculations for Each Device Pool (continued)
Device Pool 3 (IP-IVR)
Device Type CTI ports
Average BHCA 14
Package Weight 216
Comments

BHCA = 14 per device BHCA Factor = (14/6) = 2.33 = Round up to 3 Device weight (18 Devices * 2=CTI port Base Weight * 3=BHCA Factor * 2=Call Multiplier for Transfer) = 216 Route Point BHCA Factor = (250/6) = 41.6 = Rounded up to 42 Device Weight = [(1 Device * 2=CTI RP Base Weight * 42=BHCA Factor) + 216=CTI port weight] = 300
CTI route point
300 Sum of BHCA for all associated CTI devices 516
Device Pool 3 Totals 4 (IP_IVR) CTI ports 18 14
216 + 300 = 516
216
BHCA = 14 per device BHCA Factor = (14/6) = 2.33 = Round up to 3 Device weight (18 Devices * 2=CTI port Base Weight * 3=BHCA Factor * 2=Call Multiplier for Transfer) = 216 Route Point BHCA Factor = (250/6) = 41.6 = Rounded up to 42 Device Weight = [(1 Device * 2=CTI RP Base Weight * 42=BHCA Factor) + 216=CTI port weight] = 300
CTI route point
300 Sum of BHCA for all associated CTI devices 516
Device Pool 4 Totals 5 (SoftPhones) CTI ports 100 6
216 + 300 = 516
200
BHCA = 6 per device BHCA Factor = (6/6) = 1 Device weight (100 Devices * 2=CTI port Base Weight * 1=BHCA Factor) = 200
11-30
EDCS-197018
Chapter 11
Group the CTI Devices into Device Pools

Table 11-7 leads to the following observations and design notes:
For the IVR route point: As mentioned previously, the route point is a grouping of assigned CTI devices. The route point handles CTI messages between Cisco CallManager and the CTI device that will be used for the call transaction. As a result, the device weight of the route point is the sum of its base device weight and all its assigned CTI devices. For load balancing and redundancy purposes in this example, we defined two route points, each with 18 assigned CTI ports. These route points and CTI ports are distributed equally into two separate device pools, Pool 3 and Pool 4.
For the Cisco IP SoftPhone: Each SoftPhone has a relatively low device weight because its application provider, for the most part, has only one CTI connection. Its call rate of 6 BHCA is also relatively low.
For the IP phones: The IP phones are split into two separate device pools for load balancing and redundancy purposes.
Provision the CTI Resources on the Cisco CallManager and CTI Manager Servers
After determining the package weights of the CTI resources, we can provision those resources across the Cisco CallManager servers in the cluster. The requirements for this example are as follows:

Capability to process 500 BHCA at .001 Grade of Service Average call handling time (AHT) of 3 minutes Transfer to user extensions or operator Provision for scalability and redundancy CTI Manager primary server is the Cisco CallManager server with the fewest devices provisioned on it
Figure 11-21 shows one possible configuration for this example system, but other designs are possible. In Figure 11-21, CM1 is the primary CTI Manager server.
11-31
Figure 11-21 Configuration Design for Example System
2000 IP phones IP IP IP Primary CTI manager (on CM2) CTI devices Device Pool 3 DW = 516 Device Pool 4 DW = 516 1 2 CallManager group A Device Pool 5 DW = 200 CTI devices
M M
Device Pool 1 DW = 2000
CM cluster 1 2 CallManager group A

M
IVR application 1 Route Point (RP1) 18 CTI Ports 1 Route Point (RP2) 18 CTI Ports
CM1
CTI devices
CM2
CTI devices 100 SoftPhones 100 CTI ports
CM backup
CTI devices
CTI devices 2000 IP phones IP IP IP Backup CTI manager (on CM1) Device Pool 2 DW = 2000
74452
Table 11-8 lists the device weight distributions for the configuration shown in Figure 11-21.
Table 11-8 Package Weights and Server Assignments for Device Pools
Device Pool 1 2 3
Package Weight 2000 2000 516
Primary Cisco CallManager Server CM1 CM2 CM1
Primary CTI Manager Server N/A N/A CM1
Backup Server CMBK CMBK CMBK
11-32
EDCS-197018
Chapter 11
Table 11-8
Package Weights and Server Assignments for Device Pools (continued)
Device Pool 4 5
Package Weight 516 200
Primary Cisco CallManager Server CM2 CM2
Primary CTI Manager Server CM1 CM2
Backup Server CMBK CMBK
This example does not distribute the SoftPhones equally across the Cisco CallManager servers for the following reasons:

Unlike the IVR application, Cisco IP SoftPhone is an application client containing a route point that controls multiple CTI devices. Because the total SoftPhone package weight of 200 is low relative to the other devices, we can keep all of the SoftPhones in one device pool for easier administration. If the total package weight is a significantly higher number (above 500), or if the system is approaching the maximum server device weight limit (20,000), then we should distribute the SoftPhones for load balancing purposes.
Table 11-9 lists the device weight distribution per Cisco CallManager server in this example configuration.
Table 11-9 Device Weight Distributions Across the Servers
Cisco CallManager Server CM1 CM2
Associated Device Pools 1, 3 2, 4, 5
Total Device Weight 516 + 2000 = 2516 516 + 2000 + 200 = 2716
Comments Requires at least an MCS-7835 server to run this configuration Requires at least an MCS-7835 server to run this configuration
Provision Backup Servers for Failover Conditions

For this example configuration, we choose server CM1 as the primary CTI Manager because it has the lowest total device weight, as shown in Table 11-9. With this configuration, the following behavior occurs during the indicated failure conditions:
Server CM1 fails: All device pools assigned to Cisco CallManager Group A fail over to server CM2, and CM2 now controls route point RP1 and all of its 18 ports. CMBK acquires all the device weight load of CM2.
Server CM2 fails: All device pools assigned to Cisco CallManager Group B fail over to server CMBK, and CMBK acquires all the device weight load of CM2. The primary CTI Manager associated with the IVR application also fails, and all of the application provider resource management functions transfer to CMBK.
11-33
CTI Manager Fails: Server CM2 becomes the active CTI Manager.
IVR application Fails The example configuration used only one IVR application for simplicity, so there is no application redundancy in this case. However, you can provide application redundancy by adding another application server and following the design guidelines in this document.
11-34
EDCS-197018
Chapter 11
CTI Applications Architecture and Design Summary
Summary
Table 11-10 summarizes the guidelines and considerations for provisioning CTI resources.
Table 11-10 CTI Provisioning Guidelines and Considerations
Cisco CallManager Questions Does the campus already have Cisco CallManager servers installed? If Cisco CallManager servers are already installed, what are the model numbers (for example, MCS-7830, MCS-7835, etc.)? What other IP telephony devices are currently configured for the Cisco CallManager server or cluster? Application Questions How many instances of the application are needed?
Comments
The server model determines the maximum total device weight supported per server. This information identifies which devices to include in the device weight calculations and indicates how the CTI devices can be distributed among the servers. Comments This information determines the number of application providers required. For example, a SoftPhone has many application providers (one per client), whereas a large IVR server application has many sessions but one or few application providers. This information determines the number of CTI devices needed per application provider.
How many user sessions are required per application? What is the average BHCA rate required by the application for this site? Is application redundancy required?
This information determines how many application provider sessions you need and whether you have to create multiple route points to distribute across Cisco CallManager servers in a cluster. This information determines the maximum number of CTI devices allowed per application provider. Supported limits are 2000 CTI devices for JTAPI or 800 for TAPI. Comments
Does the application use TAPI or JTAPI?
Post-CTI Design Questions Does the system design comply with the following CTI limits?

2000 CTI devices per JTAPI or TAPI application provider 800 CTI devices per Cisco CallManager server 3200 CTI devices per Cisco CallManager cluster
11-35
Chapter 11 Summary
11-36
EDCS-197018
C H A P T E R
12
Cisco IP IVR System Design Considerations

Cisco IP Interactive Voice Response (IP IVR) is a multimedia (voice/data/Web) IP-enabled Interactive Voice Response solution that offers an open and feature-rich foundation for the creation and delivery of IVR applications via Internet technology. In addition to handling traditional telephony contacts, you can create IP IVR applications to respond to HTTP requests and send email. This chapter covers the Customer Response Solutions (CRS) architectural design considerations as they apply to the Cisco CallManager CTI (JTAPI) interface to IP IVR. It does not cover specific IP IVR features or application programming guidelines. For more information about IP IVR, refer to the product literature at http://www.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/apps_22/index.htm The following conventions apply throughout this chapter:

IP-IVR refers to Cisco IP-IVR Release 2.2. Cisco CallManager refers to Cisco CallManager Release 3.1. IP-IVR v2.2 is not compatible with Cisco CallManager Release 3.2. The terms CTI ports and IVR ports are used interchangeably.
IP IVR Architecture
IP-IVR is a software bundling option in the Cisco Customer Response Solutions (CRS) platform. The CRS platform itself is actually a Java-based rapid application development (RAD) environment and runtime engine. The CRS architecture consists of various subsystems using the industry standard interfaces (for example, HTTP, SMTP, ODBC, LDAP, and others) enabling you to develop robust voice and data applications. For more details on the CRS architecture, refer to the Cisco Customer Response Applications documentation at http://www.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/apps_22/index.htm IP-IVR is supported on the following server platforms:

MCS-7825-800 MCS-7835-1000 IBM Series x330 IBM Series x340
12-1
Chapter 12 Cisco CallManager Device Weight Provisioning for IP IVR
Cisco CallManager Device Weight Provisioning for IP IVR

IP IVR follows the same provisioning recommendations listed in the chapter on CTI Applications Architecture and Design. The first step in provisioning is to determine what types of CTI resources are required for configuration on the Cisco CallManager server. As an example, consider a typical IP-IVR call flow, shown in Figure 12-1.
Figure 12-1 Typical IP IVR Call Processing Scenario
Dialing 555-5000
IP-WAN/ PSTN
IP-IVR
CTI port CTI route point Main number 5000 CTI redirect Blind transfer IP Attendant phone (ext 5512)
CTI port
CTI port
Figure 12-1 shows that a call coming in from the Public Switched Telephone Network (PSTN) to the IP-IVR will first be routed from the voice gateway to the Cisco CallManager server. Cisco CallManager routes the call to an IVR script written in the IP-IVR server. Route points and CTI ports are configured in the IP-IVR such that all calls received at the directory number 5000 through the CRS JTAPI subsystem will go through its IVR script. Both the Cisco CallManager server and IP-IVR interact with the CTI route points and CTI ports, but the interaction is different in these two cases. In particular, IP-IVR does not handle the internal CTI route point and CTI port messaging. IP-IVR makes CTI requests for Cisco CallManager to handle the call routing. Cisco CallManager processes the CTI Redirect message from the route point to the available CTI port as well as the CTI Blind Transfer messages from the CTI port to a particular extension. This point is relevant to know because the approach to assessing Cisco CallManager scalability is as follows:
Determine how many CTI resources are required by the IP-IVR. Calculate the required device weight for the server. Determine how many device units are consumed by the IP-IVR CTI resources.
12-2
EDCS-197018
72397
Chapter 12
Cisco IP IVR System Design Considerations Cisco CallManager Device Weight Provisioning for IP IVR
Additional IP-IVR Scalability Considerations

The CTI limits for Cisco CallManager Release 3.1 are as follows:

800 CTI devices per Cisco CallManager server 3200 CTI devices per Cisco CallManager cluster Where a CTI device is a CTI route point, a CTI port, or a third-party controlled hardware IP phone or a Cisco IP Softphone.
IP IVR Co-Resident with Cisco CallManager

In this configuration, there is only one server containing both the Cisco CallManager service for call processing, and the CRS for running IP-IVR scripts. This platform is bundled with five IVR ports and is scalable up to a maximum of 10 IVR ports. Table 12-1 summarizes the device weight contributed by the IP-IVR for the supported co-resident Media Convergence Server (MCS) platform configurations.
Table 12-1 Device Weights for IP IVR Co-Resident with Cisco CallManager
Configuration Co-Resident:

Base Server Units 2000
Maximum Supported IP-IVR Device Weight on IP-IVR Ports the Co-resident Server 10
Comments
MCS-7825-800 IBM Series x330 5000 10 MCS-7835-1000 IBM Series x340
148 (14.8% of total server Assuming each IVR port is weight) processing about 20 BHCA.
Co-Resident:

148 (2.97% of total server Assuming each IVR port is weight) processing about 20 BHCA.
The remaining device weights can be used to provision other Cisco CallManager devices such as IP phones, Cisco IP SoftPhones, and Media Gateway Control Protocol (MGCP) gateways. Even though the co-resident server platform may contain a large number of server units remaining, it cannot support non-redundant configurations for more than 500 IP phones. Also, it is possible to have a co-resident IP IVR and Cisco CallManager server as part of a single cluster. Cisco strongly discourages using a co-resident server with more than 200 IP phones as a backup server for other devices within the cluster. The next section covers design considerations when provisioning the IP-IVR for redundancy.
Standalone IP IVR Configuration

In this configuration, the MCS platform is dedicated to the IP IVR functionality and is considered an external server to Cisco CallManager. Other than CTI resource messaging to the Cisco CallManager server, the dedicated IP-IVR has no direct impact on the Cisco CallManager server. Therefore, you need to calculate the device weight only for the CTI resources provisioned for the Cisco CallManager. Refer to the CTI Applications Architecture and Design chapter for more details and for an example that provisions IP-IVR resources for Cisco CallManager scalability and redundancy. Table 12-2 summarizes the device weights consumed by a standalone IP-IVR on the supported MCS platforms.
12-3
Table 12-2 Device Weights for Standalone IP IVR
IP-IVR Platform Standalone:

Base Server Weight 2000
Maximum Number of Supported IVR Ports 48
Device Weight Impact on an Associated Cisco CallManager Server 704
Comments Assuming each IVR port is processing about 20 BHCA Assuming each IVR port is processing about 20 BHCA
MCS7825-800 IBM Series x330 5000 60 880 MCS7835-800 IBM Series x340
Standalone:

Redundancy Considerations
IVR applications are predominantly focused on providing some type of customer service such as bank transactions, customer order statuses, or call center forwarding. In these situations, system unavailability could have a direct impact on business revenue, so IVR applications must maintain a high level of availability to ensure reliable service for business customers. This includes ensuring a seamless transition to redundant systems during a failure scenario. Beginning with Cisco CallManager Release 3.1, IP-IVR applications can be configured for redundancy across Cisco CallManager servers in a single cluster. The major failure scenarios that can occur are as follows:

CTI Manager Fails, page 12-4 Cisco CallManager Server Fails, page 12-6 IVR Application Fails, page 12-6
This section briefly reviews these failure scenarios and the design considerations for providing IP IVR redundancy. For a more technical discussion of CTI redundancy, refer to the CTI Applications Architecture and Design chapter.
CTI Manager Fails

This section describes the CTI Manager and the Cisco CallManager failure in the same example. For a more details on these two failure scenarios, refer to the CTI Applications Architecture and Design chapter. With Cisco CallManager Release 3.1, a single IP-IVR can be provisioned for Cisco CallManager redundancy by configuring two instances of a single IP-IVR script within the CRS server, as shown in Figure 12-2.
12-4
EDCS-197018
Chapter 12
Figure 12-2 IP IVR Redundancy After a Cisco CallManager Failure
IP-IVR Main number x5000 MyIVRScripte. aef CTI route point

M X
#1
Primary CM and CTIM

M
MyIVRScripte. aef
CTI route point Main number x5001
#2 Backup CM and CTIM
CRAE CTI port pool CTI port CTI port CTI port
#1 Failover DN x5001 is configured as forward on busy or forward on failure of the CallManager publisher #2 After failover to backup CallManager is complete, incoming calls get routed back to IP-IVR1 Assumptions: Same IVR script name used for both service creations CTI Manager primary and backup are configured in the CRAE Admin Menus (or via JTPrefs screens)
The following call routing takes place in Figure 12-2:

Each instance of the IP-IVR script is assigned a different route point number. In this example, two instances of the same script, MyIVRScript.aef, are assigned to route points x5000 and x5001. The Call Forward on Failure (CFoF) and Call Forward No Answer (CFNA) directory number (DN) parameters for route point x5000 are set to the second IVR script route point DN, x5001 If the primary CTI Manager fails, the IVR will failover to the backup CTI Manager. The CTI Manager primary and backup settings are configured in the application's JTPrefs parameters under the CRSE Admin menu. As the CTI resources of the first IVR (x5000) fail over from the primary Cisco CallManager server to the backup server, the following events occur:
All existing calls in the first IVR prior to the primary Cisco CallManager failure are dropped. All new calls to x5000 are redirected to the configured Call Forward No Answer (CFNA)
number. In this case, the calls are forwarded to the DN of the second IVR script, x5001.
Once CTI resources for x5000 have successfully registered with the backup Cisco CallManager and CTI Manager, all new incoming calls will be routed to x5000.
72398
12-5
Cisco CallManager Server Fails

Building on the previous example, Figure 12-3 shows a closer look at redundancy provisioning to handle a Cisco CallManager server failure.
Figure 12-3 Another Example of IP IVR Redundancy for Cisco CallManager Failure
CTI manager RP1, IVR ports 1 IVR1 CallMgr 1 group 2 B CallMgr 1 group 2 B
CallManager cluster
Device pool 1 Device pool 2
CM1 CM2
72400 72401
RP2, IVR ports 2
In Figure 12-3, each IVR route point is assigned to separate device pool, which in turn is assigned to a Cisco CallManager redundancy group. The Cisco CallManager group is a prioritized list of Cisco CallManager servers for device provisioning. If the primary (first) Cisco CallManager server in the group fails, the CTI Manager will re-provision the IVR route points and ports within Device Pool 1 to the second Cisco CallManager server in the group. In this case, the second-priority server is the backup server CM2. Call routing behavior during failover from a primary to backup Cisco CallManager server is the same as outlined in the previous section, CTI Manager Fails, page 12-4. Refer to the CTI Applications Architecture and Design chapter for more details on this failover scenario.
IVR Application Fails

The most natural way to provide IVR application redundancy is to add a backup IVR server, as shown in Figure 12-4. Observe the following guidelines from the CTI Applications Architecture and Design chapter when provisioning across Cisco CallManager servers in a cluster:

Provision CTI devices equally across multiple Cisco CallManager servers in a cluster. Enable a CTI Manager on each Cisco CallManager server.
Figure 12-4 Provisioning IP IVR for Redundancy
CTI manager IVR1 RP1, IVR ports 1 CallMgr 1 group 2 B CallMgr 1 group 2 B
CallManager cluster
Device pool 1 Device pool 2
CM1 CM2
M
IVR2 RP2, IVR ports 2
12-6
EDCS-197018
Chapter 12
Figure 12-5 and Figure 12-6 use the Cisco CallManager Device Provisioning Tool to display the device weight values for this example configuration.
Figure 12-5 IP-IVR Device Weight Summary for Redundancy Provisioning
12-7
Chapter 12 Summary
Figure 12-6 MCS Platform Weigh Calculations for IP-IVR Redundancy Design
Figure 12-6 shows equal provisioning of a standalone IP-IVR server for redundancy on two MCS-7835-1000 servers, with IP IVR occupying 8.8% of the available device weight on each server. As a reminder, this example illustrates the device weight contribution from only one standalone IP-IVR running 60 ports at a BHCA of 1200 (60x20 = 1200 BHCA), with provisioning for Cisco CallManager redundancy. This calculation does not cover other Cisco CallManager devices such as IP phones or H.323 gateways that you may be provisioning in a complete IP telephony solution.
Summary
With Cisco CallManager Release 3.1, CTI layer enhancements have increased port scalability and provided applications redundancy with the addition of the CTI Manager. The recommendations in this chapter can help an enterprise to assess capacity planning of the IP-IVR in co-resident and standalone configurations and to provision its CTI resources for high availability through applications redundancy.
12-8
EDCS-197018
C H A P T E R
13

The Cisco IP SoftPhone offers users the great benefit of having a portable office IP phone to use anywhere an Internet connection is available. For example, a company can have a group of telecommuters with a SoftPhone running on their home desktops or laptops. Calls made via the Cisco IP SoftPhone from a remote location can be routed through the same gateway as a users office phone. This capability saves your enterprise the call processing bandwidth of managing multiple legs of a call that would otherwise go through a different trunk and be re-routed through the network, thus saving on long-distance toll charges. This chapter highlights scalability and redundancy considerations for using the Cisco IP SoftPhone with Cisco CallManager. This document contains the following sections:

Provisioning Guidelines for Cisco IP SoftPhone, page 13-1 Scalability Considerations, page 13-3 Redundancy Considerations, page 13-4
For more information about the features, functionality, and benefits of the Cisco IP SoftPhone, refer to the product documentation available online at Cisco.com.
Note
Unless stated otherwise, the information in this chapter applies to Cisco CallManager releases 3.1 and 3.2 and to Cisco IP SoftPhone Version 1.2(2).
Provisioning Guidelines for Cisco IP SoftPhone

The first step in provisioning Cisco IP SoftPhone is to determine what types of call processing resources it requires. Cisco IP SoftPhone is a Telephony Application Programming Interface (TAPI) application that runs on a Cisco CallManager Computer Telephony Interface (CTI) client. This CTI client is normally a desktop or laptop computer. The most common types of Cisco IP SoftPhone users are:
Full-time telecommuters Instead of a hardware IP phone, these users have a standalone Cisco IP SoftPhone on their desktop or laptop PC. In this configuration, you assign each Cisco IP SoftPhone line appearance to a CTI port.
13-1
Chapter 13 Provisioning Guidelines for Cisco IP SoftPhone
Mobile office workers These users already have a hardware IP phone at the office but wish to carry their extensions with them to a remote virtual office, preferably anywhere they have a desktop or laptop PC. In this configuration, you can also provision each hardware phone as a third-party controlled IP phone so that the users can use the same Cisco IP SoftPhone user interface to control their lines when at the office. (See Option 1 in Figure 13-1.) Then, while on the road, they can switch to using the Cisco IP SoftPhone in standalone mode. (See Option 2 in Figure 13-1.)
Figure 13-1 Cisco IP SoftPhone Device Association Options
Dialing 555-8100
IP-WAN/PSTN LDAP user profile configuration third party controlled IP phone (x8110)
V
SCCP port x8110 CTI manager CTI port x8110 CTIQBE Option 2: standalone soft phone Incoming call
IP Phone (ext 8110) IP Option 1: third party control
Soft Phone (ext 8110)
Figure 13-1 shows that the Cisco IP SoftPhone application can either monitor or control the hardware IP phone at the office. In the case of a third-party controlled phone, Cisco IP SoftPhone acts as a virtual extension of the desktop IP phone. The Cisco IP SoftPhone application is able to see and handle incoming and outgoing calls for the hardware phone. From the perspective of provisioning device weights and CTI resources, each user with this configuration would be provisioned as a third-party controlled IP phone. As a CTI port, the IP SoftPhone is a dedicated line to process calls directly to the client machine without the additional control and monitoring of a desktop phone. The Cisco IP SoftPhone is not able to run a CTI port and a third-party control phone with the same directory number (DN) at the same time. As shown in Figure 13-1, the user is able to have x8110 as either a CTI port or a control for their desktop phone. For more information on device weights and CTI resource provisioning, refer to the chapter on CTI Applications Architecture and Design.
13-2
76102
EDCS-197018
Chapter 13
Cisco IP SoftPhone Design Considerations Provisioning Guidelines for Cisco IP SoftPhone
Scalability Considerations
As stated previously, you can provision each Cisco IP SoftPhone line appearance as either a CTI port for a dedicated Cisco IP SoftPhone line or as a third-party controlled IP phone for control of a hardware IP phone. The next step is to calculate the average device weight for each Cisco IP SoftPhone user. Table 13-1 lists the base device weights for the Cisco IP SoftPhone CTI resources.
Table 13-1 Cisco IP SoftPhone Base Device Weights
Cisco IP SoftPhone Configuration Standalone Cisco IP SoftPhone (no associated IP phone) Cisco IP SoftPhone controls an IP phone
Base Device Weight 2 for each line appearance
Comments and Assumptions Base weight is for each CTI port line appearance.
3 for each controlled IP phone Base weight is for each controlled IP phone. The value already includes the device weight of the IP phone.
Observe the following additional guidelines when calculating device weights for the Cisco IP SoftPhone:
Estimate the average busy hour call attempts (BHCA) for each line appearance to determine the BHCA factor. Increase the BHCA factor by 1 for every 6 BHCA. For a typical system, 6 BHCA is a good estimate. Consider the call handling for the majority of the Cisco IP SoftPhone clients. If most of the calls handled per Cisco IP SoftPhone session involve transfers or conferencing, then you must factor in a call handling multiplier. If not, then the call handling multiplier is negligible and can be assigned a value of 1.
For more information on the factors involved in device weight calculations, refer to the chapter on CTI Applications Architecture and Design.
Example Device Weight Calculation

For this example, assume Company XYZ has 50 users with Cisco IP SoftPhones. Each user has two line appearances and makes approximately six calls per hour. Most of the Cisco IP SoftPhone sessions will not involve call transfer or conferencing. The Cisco IP SoftPhone device weight calculation in this case is: Total Device Weight = (50 users) x (Base Device Weight = 2) x (2 line appearances per phone) x (Call Handling Multiplier = 1) = 200 This value fits well within the limits for the supported Cisco CallManager servers, such as the Media Convergence Server (MCS) 7825 or MCS 7835, which can accommodate total device weights up to 1000 and 5000 respectively.
Maximum Cisco IP SoftPhone Configuration Limits

Regardless of the device weight limits allowed per server, there are maximum limits on the number CTI devices you can configure in Cisco CallManager. The CTI device limits as they apply to Cisco IP SoftPhone are as follows:

Maximum of 800 Cisco IP SoftPhones per Cisco CallManager server Maximum of 3200 Cisco IP SoftPhones per Cisco CallManager cluster
13-3
The following assumptions apply to the preceding maximum Cisco IP SoftPhone limits:

Each Cisco IP SoftPhone is configured with 1 line appearance. Each Cisco IP SoftPhone is processing an estimated 6 or fewer BHCA. No other CTI applications requiring CTI devices are configured in the Cisco CallManager cluster.
Redundancy Considerations
To ensure reliable service for the mobile users, you must maintain a high level of system availability with a seamless transition to redundant systems during a failure scenario. Redundancy for the Cisco IP SoftPhone is similar to that of a hardware IP phone, except that the Cisco IP SoftPhone interfaces primarily with the CTI Manager (not Cisco CallManager) for its failover handling. Figure 13-2 illustrates one example of how you can configure the Cisco IP SoftPhone applications for redundancy within a Cisco CallManager cluster.
Figure 13-2 Cisco IP SoftPhone Redundancy Example
CallManager cluster CM server 1
Soft Phone 1 IP
Soft Phone 2 IP
Soft Phone N IP
Device pool 1
CallManager group A 2
X
CTIM CCM CM server backup CTIM CCM CM server 2 CTIM
IP Phone 1
IP Phone 2
IP Phone N Device pool 2 CallManager 2 group B

1
IP IP IP
CCM
76103
General users
Figure 13-2 illustrates the following configurations:
Device Pool 1 consists of all Cisco IP SoftPhones. Users at SPa, SPb, and SPc have dedicated Cisco IP SoftPhone lines configured via CTI ports, while users at SP1, SP2, and SP 3 have Cisco IP SoftPhones that control hardware IP phones PH1, PH2, and PH3. TAPI Service Provider (TSP) client settings for each Cisco IP SoftPhone are configured with CM Server 1 as its primary CTI Manager server and CM Server BK as its backup CTI Manager. Device Pool 2 consists of all hardware IP phones, including those controlled by Cisco IP SoftPhones as well as general enterprise hardware IP phones.
13-4
EDCS-197018
Chapter 13
The current Cisco CallManager call processing guidelines recommend that you provision the CTI Manager and Cisco CallManager on the same server, with the same hot backup server for both. This means that, if either the CTI Manager or the Cisco CallManager service fails on CM Server 1, all of the Cisco IP SoftPhones in Device Pool 1 fail over to CM Server BK. The hardware IP phones controlled by Cisco IP SoftPhones (PH1, PH2, and PH3) continue processing calls via CM Server 2 even though their associated Cisco IP SoftPhones have failed over to CM Server BK. Calls in progress are still routed to the hardware IP Phone. Table 13-2 summarizes the different types of failure scenarios and expected behavior for the example in Figure 13-2.
Table 13-2 Failover Scenarios for Cisco IP SoftPhone
Failure Scenario Cisco CallManager fails CTI Manager fails Cisco IP SoftPhone fails
Behavior Failover to backup Cisco CallManager Failover to backup CTI Manager No redundancy for another Cisco IP SoftPhone on the same PC client
Notes and Comments Cisco IP SoftPhones are combined in device pools and assigned to Cisco CallManager servers in a prioritized Cisco CallManager group list. The primary and backup CTI Managers are assigned in each Cisco IP SoftPhone TAPI Service Provider (TSP) client configuration. For a standalone Cisco IP SoftPhone configuration with a CTI port, calls in progress will be lost. New incoming calls may be preserved by configuring the Call Forward No Answer (CFNA) number to another IP phone extension. For a Cisco IP SoftPhone controlling a hardware IP phone, calls in progress are preserved on the hardware IP phone.
For a summary of CTI redundancy behavior in different types of failure scenarios, refer to the chapter on CTI Applications Architecture and Design.
13-5
Bandwidth Provisioning Considerations

The Cisco IP SoftPhone has two bandwidth codec settings. G.711 is the default setting, with a user-configurable option to select the low bandwidth codec setting of G.729 on the TAPI Service Provider (TSP) client (see Figure 13-3). Refer to the chapter on Network Infrastructure Requirements for IP Telephony for details on provisioning network bandwidth.
Figure 13-3 IP SoftPhone Bandwidth Setting
SoftPhone users with low bandwidth connections over a Virtual Private Network (VPN) should consider selecting this low-bandwidth codec setting.

Call admission control ensures that there is enough bandwidth available to process IP phone calls over the network. While there are several mechanisms for implementing call admission control, Cisco IP SoftPhone uses only the locations mechanism configured in Cisco CallManager. Refer to the chapter on Call Admission Control for more information on Cisco CallManager locations. Call admission control is effective in managing call bandwidth as long as the IP SoftPhones are configured and provisioned at known locations. However, call admission control is not as effective in managing bandwidth for IP SoftPhone users at remote branches that are outside of the known locations. Figure 13-4 illustrates this point.
13-6
76104
EDCS-197018
Chapter 13
Figure 13-4 Effect of Roaming SoftPhone on Call Admission Control
Branch A CallManager A
M
CAC accounts for unused bandwidth
Branch B CallManager B
IP WAN
Call is blocked
X
LAN Used bandwidth unaccounted for by CAC LAN
Call is processed with poor voice quality
IP Phone 1 Soft Phone A
IP Phone 2
76105
In Figure 13-4, both Branch A and Branch B have call admission control (CAC) configured via Cisco CallManager locations. SoftPhone SP-A is a assigned to a location belonging to Cisco CallManager CM-A. If SP-A makes an outbound call, the request for the outbound call is sent to CM-A over the IP WAN through CMCTI. CM-A will count the bandwidth used by SP-A when, in fact, SP-A is using the network bandwidth in Branch B. Moreover, the CAC in CM-B is not aware that this extra bandwidth is being used by SP-A In this scenario, it is impossible to determine accurately how many SoftPhones are at Branch B. If there are enough roaming Branch A SoftPhone users processing calls on Branch B, then the following condition may occur: CAC in Branch A will indicate that the maximum bandwidth has been reached when there really is bandwidth available to process calls. At this point, if PH-1 tries to make an outbound call, that call will be blocked. Conversely, CAC in Branch B will indicate that it still has bandwidth available, so a call from PH-2 will be processed even if there is insufficient bandwidth to process calls and also maintain good voice quality. Refer to the chapter on Call Admission Control for more details on provisioning this feature.
13-7
13-8
EDCS-197018
C H A P T E R
14
Directory Access for Cisco IP Telephony Endpoints

Directories are specialized databases that are optimized for a high number of reads and searches, and occasional writes and updates. They are typically used to store data that does not change often, such as employee information, their user rights on the corporate network, and so on. Another aspect of directories is that they are extensible, which means that the type of information stored in them can be modified and extended. The term directory schema refers to the type of stored information and the rules it obeys. Many directories provide methods for extending the directory schema to accommodate information types defined by different applications. This capability enables enterprises to use the directory as a central repository for user information. The Lightweight Directory Access Protocol (LDAP) provides applications with a standard method for accessing and potentially modifying the information stored in the directory. This capability enables companies to centralize all user information in a single repository, available to several applications, with a remarkable reduction in maintenance costs through the ease of adds, moves, and changes. This chapter describes how to provide Cisco IP Telephony endpoints, such as Cisco IP Phones and Cisco IP SoftPhone, with access to a corporate LDAP directory. This chapter assumes basic LDAP directory knowledge and some familiarity with the Cisco IP Telephony solutions. (See Additional References, page 14-6, for more information on LDAP.)
Directory Access and Directory Integration

It is beneficial to highlight the distinction between providing corporate directory access to a variety of client applications (such as Cisco IP Phones) and achieving directory integration between a directory-enabled server application (such as Cisco CallManager) and a corporate directory. Figure 14-1 illustrates directory access as it is defined in this chapter. (In this example, the access is provided to a Cisco IP Phone.) The client application performs a user search against an LDAP directory, such as the corporate directory of an enterprise, and receives a number of matching entries. In this example, one entry can be selected and used to dial the corresponding person from the Cisco IP Phone.
14-1
Chapter 14 Directory Access and Directory Integration
Figure 14-1 Example of Directory Access for a Cisco IP Phone
User search IP Search results LDAP corporate directory

74608
By contrast, directory integration of several applications with a corporate directory means that these applications actually store their user-related information in a centralized directory instead of using their own embedded databases. Figure 14-2 depicts an example of directory integration as it is defined in this chapter.
Figure 14-2 Example of Directory Integration for Cisco CallManager
User searches
M
IP
M M
CallManager cluster 1 User preferences

M M M
LDAP LDAP corporate directory
CallManager cluster 2
= CallManager-specific information
By default, Cisco CallManager stores user information (such as the speed dials configured on the IP phone and the Call Forward All configuration) in an embedded LDAP directory. However, Cisco CallManager can also be integrated with a corporate LDAP directory, which is normally used to store the general employee information such as email address, office address, and job title. In those cases, Cisco CallManager no longer uses the embedded directory and stores its specific user information in the corporate directory.
Note
As of Cisco CallManager release 3.2(1), directory integration is supported for Microsoft Active Directory and Netscape Directory Server release 4.1.
14-2
74609
EDCS-197018
Chapter 14
Directory Access for Cisco IP Telephony Endpoints Configuring Directory Access
Integrating applications such as Cisco CallManager with a corporate directory also has the following implications, which go beyond simply providing directory access to endpoints:
The directory schema needs to be extended to store the application-specific user attributes in the corporate directory. This operation is not trivial and requires a good knowledge of the directory structure. The applications must be able to contact the directory at all times. Availability of the directory service can impact application functionality. Additional load is introduced on the directory, in terms of both data storage and read/write queries. Careful planning and sizing is recommended to avoid oversubscription of the servers.
While there are numerous advantages in achieving directory integration across applications, it is important to understand all its implications and verify the business needs for each specific deployment. The remainder of this chapter focuses on providing directory access to Cisco IP Telephony endpoints. (For more details on directory integration, refer to the Directory Integration section, available in a future release of this document.)
Configuring Directory Access

As mentioned previously, providing corporate directory access to endpoints such as Cisco IP Phones is logically independent from integrating an application such as Cisco CallManager with the corporate directory. Therefore, the guidelines contained in this chapter apply regardless of whether Cisco CallManager and other IP telephony applications have been integrated to a corporate directory or not. The end-user perception in both cases is the same because the differences affect only the way applications store their user information and how such information is kept consistent across the network. The following sections illustrate how to configure corporate directory access to any LDAP v3 compliant directory server for the following Cisco IP Telephony endpoints:

Cisco IP Phones (7940 and 7960) Cisco IP SoftPhone
Note
If directory integration of Cisco CallManager with the corporate directory is also required, the supported directory servers are Microsoft Active Directory and Netscape Directory Server release 4.1. However, if no integration is needed, any directory server compliant with LDAP v3 can be supported.
Directory Access for Cisco IP Phones

The Cisco IP Phones 7940 and 7960 can search a corporate directory through the Directories button. The LCD screen on the phone displays a page containing the Missed Calls, Received Calls, and Placed Calls lists. This page can be enhanced to provide one or more types of searches against an LDAP directory. The IP Phones use the Hyper Text Transfer Protocol (HTTP) to send requests to a web server. The responses from this server must contain some specific eXtensible Markup Language (XML) objects that can be interpreted and displayed by the phone. In the case of a corporate directory search, the web server operates as a proxy by receiving the request from the phone and translating it into an LDAP request, which is in turn sent to the corporate directory server. The response is then interpreted and sent back to the phone, after having been encapsulated in the appropriate XML objects.
14-3
Chapter 14 Configuring Directory Access
Figure 14-3 illustrates this mechanism in a deployment where Cisco CallManager has not been integrated with the corporate directory. Note that, in this scenario, Cisco CallManager is not involved in the message exchange.
Figure 14-3 Directory Access Mechanism for Cisco IP Phones
Web server
Corporate directory 2. LDAP search
1. HTTP request
3. HTTP response (XML) IP
Not integrated
Embedded directory
The proxy function provided by the web server can be configured using the Cisco IP Phone Services Software Development Kit (SDK) version 2.0, which includes the Cisco LDAP Search COM Server. When you install the SDK, the Cisco LDAP Search COM Server is installed automatically. (Refer to the online product documentation for more details on the installation procedure.) After installing the SDK, you must customize the WWW interface for the server. Some sample files are provided as part of the SDK. By editing these files, you can provide a wide range of directory searches according to the specific needs of your deployment. Example 14-1 shows a simple example of how to customize these files to provide basic directory search service. In this example, the Microsoft Active Server Page (ASP) code for the ldapdirectoryinput.asp file is modified to point to the corporate directory servers name or IP address (in this example, ldap.ese.lab) and perform the search on the appropriate directory subtree where all the users are located (in this example, ou=Users, dc=ese, dc=lab). If users are spread across several OUs, a higher node that includes all of the user subtrees can be specified in this field. If anonymous searches are not permitted on the corporate directory, some authentication credentials can be entered as well.
Example 14-1 Customized ldapdirectoryinput.asp File
[...] // Server Setup s.Server = ldap.ese.lab; s.Port = 389; // Authenticate and set scope s.AuthName = cn=Administrator, cn=Users, dc=ese, dc=lab; s.Password = password; s.SearchBase = ou=Users, dc=ese, dc=lab; [...]
14-4
74612
Cisco CallManager
EDCS-197018
Chapter 14
Directory Access for Cisco IP Telephony Endpoints Configuring Directory Access
Once the WWW pages have been customized, perform the following configuration steps in Cisco CallManager (see Figure 14-4):
Step 1 Step 2
In the System > Enterprise Parameters page, set the URL Directories field must to the location of the ldapdirectory.asp file on the web server. Reset the Cisco IP Phones so that the service can be accessed by the users.
Figure 14-4 Configuration of the Directories URL Enterprise Parameter in Cisco CallManager
Directory Access for Cisco IP SoftPhone

As of Release 1.2, Cisco IP SoftPhone has a built-in mechanism to access and search LDAP directories. Perform the following configuration steps to enable Cisco IP SoftPhone to access any LDAP corporate directory:
From the Settings window, choose the Directories tab, and click on the Add button. This action displays the Directory Service window for configuring the directory settings, shown in Figure 14-5. To access the LDAP directory, enter valid credentials in the Directory Service configuration window. Once you have specified the directory server, you can use the Directories button from the main interface window to search for users in the corporate directory, as shown in Figure 14-6.
74610
14-5
Chapter 14 Additional References
Figure 14-5 Cisco IP SoftPhone Directory Configuration
Figure 14-6 Searching the Corporate Directory Using Cisco IP SoftPhone
Additional References

Tim Howes, Mark C. Smith, and Gordon S. Good; Understanding and Deploying LDAP Directory Services; MacMillan Technical Publishing, 1999. Darrick Deel, Mark Nelson, and Anne Smith; Developing Cisco IP Phone Services: A Cisco AVVID Solution; Cisco Press, 2002.
14-6
EDCS-197018
C H A P T E R
15
Security Recommendations for IP Telephony

The subject of securing voice communications, always a very sensitive topic for todays communications architects, has received even more visibility recently as network convergence becomes the accepted design model. With the advent of IP telephony, which uses IP data network devices for voice communication, the potential exists for malicious attacks on call processing components and telephony applications. To help safeguard against such attacks, you can implement the design and configuration guidelines presented in this document to provide security for each of the following components:
Establish Physical Security, page 15-2 The foundation step in building secure network is to create a secure physical boundary for critical communications equipment. Network designs and software configurations cannot protect a network whose assets are not physically protected from potential malicious threats.
Protect the Network Elements, page 15-3 Routers, Ethernet switches, and VoIP gateways define network boundaries and acts as gateway interfaces to all networks. Securing these vital pieces of the data network is a requirement for securing the data, voice, and video applications running on the infrastructure.
Design a Secure IP Network, page 15-5 Understanding and following sound IP network design principles not only allows the network to scale and perform better, but also increases the security of all attached devices.
Secure the Cisco CallManager Server, page 15-12 Securing the voice call processing platform and installed applications is perhaps the most vital step in securing Cisco AVVID networks.
IP Telephony Security Guidelines

Every enterprise should have a pre-defined security policy for all devices, applications, and users to follow. The strictness of the security policy depends upon the level of caution required. This document does not describe how to establish a security policy for your enterprise, but it does present a set of security guidelines and recommendations to help you configure the IP telephony network to conform to your enterprise security policy. This document is not a complete treatment of network security. Rather, it is a starting point for network managers, system administrators, and systems engineers to use when building IP telephony networks that adhere to the Cisco SAFE security model. Refer to Cisco SAFE White Paper, available at http://www.cisco.com/warp/public/cc/so/cuso/epso/sqfr/safe_wp.htm
15-1
Chapter 15 Establish Physical Security
It is important to keep in mind that securing a network is a continual process that requires keeping abreast of the latest vulnerabilities that can exist in network infrastructure components, server operating systems, or applications deployed throughout the enterprise. The following list summarizes the security guidelines and recommendations described in the remaining sections of this document.
Establish Physical Security, page 15-2

Limit and monitor physical access to all servers, switches, and routers.
Protect the Network Elements, page 15-3

Secure login access. Follow sound password and authentication practices. Ensure that unused router services are turned off. Securely configure any network management functions. Use logging services to track access and configuration changes.
Design a Secure IP Network, page 15-5

Place all Cisco CallManagers, IP telephony servers, and IP phones on logically separate IP
networks.
Use IP filters to limit access from the data network to the IP telephony network. Place firewalls in front of all Cisco CallManager clusters.
Secure the Cisco CallManager Server, page 15-12

Turn off any unused or unnecessary services and applications running on the
Cisco CallManager server.

Apply security settings to the NTFS file structure. Enable system security auditing. Configure the Certificate Authority. Configure IIS settings to enhance security. Secure the SQL Server installation. Remove any software-based conferencing or Media Termination Point (MTP) packages
installed on the Cisco CallManager server.

Securely configure the Cisco CallManager Simple Network Management Protocol (SNMP)
settings.
Establish Physical Security

As with most computing devices, Cisco routers, switches, servers, and other infrastructure components are not designed to provide any protection against penetration or destruction by an attacker with direct physical access. You must take reasonable steps to prevent physical access by unauthorized personnel. Common precautions include restricting access to wiring closets and data centers to staff members that are considered trusted. Generally, most staff members already have direct or indirect logical access to the devices being protected and therefore gain no advantage from physical access. In data centers where untrusted staff may be present, you can use separate locking cabinets for individual items or racks that have more stringent security requirements. When using keyed or electronic locks on doors, consider any facilities, security, and janitorial staff that may have the ability or clearance to bypass the locks.
15-2
EDCS-197018
Chapter 15
Security Recommendations for IP Telephony Protect the Network Elements
You should carefully evaluate the policy defining who has physical access to corporate infrastructure, communications, and power equipment as well as who has system or network administrator login permissions. Carefully maintain physical access logs. In addition, use a synchronized time source, such as the Network Time Protocol (NTP), on the computer that maintains the physical access logs so that you can accurately compare those logs with logs from other computers, network elements, and communications equipment.
Protect the Network Elements

Once you have established physical security, the next step is to secure the actual routers, switches, and voice over IP (VoIP) gateways that make up the communications network. These network elements provide both physical and logical connectivity of the entire enterprise network and, according to the SAFE architecture, should be considered as a target for well-informed attackers. For recommendations and configuration details on securing these infrastructure devices, refer to Improving Security on Cisco Routers, available at http://www.cisco.com/warp/customer/707/21.html To protect the network elements, perform the following tasks:

Secure Login Access, page 15-3 Follow Sound Password and Authentication Practices, page 15-3 Assign Unique PVID to all 802.1Q Trunking Ports, page 15-4 Ensure Unused Router Services Are Turned Off, page 15-4 Securely Configure Network Management Functions, page 15-4 Use Logging Services to Track Access and Configuration Changes, page 15-5
Secure Login Access

Configuration from the Command Line Interface (CLI) via telnet sessions is still the most popular method of managing routers and switches. The first step in securing the network elements is to limit which subnets are able to access the router and switch virtual terminal sessions. Limiting virtual console access to the IP address range(s) of operations staff and network management hosts is a useful method to restrict unauthorized users from accessing network devices, even if a password is discovered.
Follow Sound Password and Authentication Practices

Passwords are another important line of defense against unauthorized access to routers and switches. The best way to handle user passwords is to use a TACACS+ or RADIUS authentication server in conjunction with one-time password systems such as SofToken, SecureID, or DES Gold Cards to prevent an attacker from reusing trusted user passwords. However, many routers still have a locally configured password for privileged access during required maintenance periods. To ensure maximum precautions for limiting router password exposure, use the service password-encryption command to encrypt all passwords Cisco also recommends that you use the enable secret command to hide configuration access even further. For maximum security, use numbers and punctuation symbols, as well as mixed case letters, in passwords. Finally, use an encrypted form of access, such as IPSec or SSH, for administering network devices.
15-3
Chapter 15 Protect the Network Elements
Assign Unique PVID to all 802.1Q Trunking Ports

An often overlooked aspect of designing campus networks is the securing of 802.1Q Ethernet trunks. A trunk is an Ethernet connection between two network devices that carries multiple virtual LANs (VLANs). Potential security threats on 802.1Q VLAN trunk configurations were brought to light in a September 1999 BUGTRAQ alert (BUGTRAQ 801.1Q Security Alert; 9/99 BUGTRAQ@securityfocus.com email; Subject: VLAN Security). This alert pointed out that, if a users native VLAN ID is the same as the port VLAN ID (PVID) of the 802.1Q trunk, then the user can send frames from his VLAN and have them hop to other VLANs. This weakness is part of the 802.1Q specification and does not apply to Cisco ISL trunking ports. The workaround for this threat is to ensure that every 802.1Q trunking port has a PVID, or native VLAN ID, that is unique throughout the campus network.
Ensure Unused Router Services Are Turned Off

Many of the unnecessary services that can run on Cisco routers are turned off by default in Cisco IOS Release 12.1 and later. However, it is always a good practice to audit the network and ensure that these services are disabled. Disable the following services if they are not used:

Hypertext Transfer Protocol (HTTP) Finger User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) Small Server Remote copy protocol (RCP) or remote shell protocol (RSH)
Securely Configure Network Management Functions

Simple Network Management Protocol (SNMP) is widely used for monitoring and configuring network elements. SNMP uses an authentication method based on a community string. This community string is essentially a password used for accessing the network element. Since nearly all of the information viewable or configurable from a virtual console can also be accessed with SNMP, it is essential to restrict this method of access as completely as possible. The following basic rules improve SNMP security:

Never use public and private as community strings. Limit SNMP access to only a few specific hosts or subnets.
15-4
EDCS-197018
Chapter 15
Security Recommendations for IP Telephony Design a Secure IP Network
Use Logging Services to Track Access and Configuration Changes

Accurate logging is still one of the most valuable tools for tracking intruders. Logging all system notices and error messages often provides valuable insight into the operational status of network devices. If you log access list violations, you can also correlate the logs between devices to determine if the network is being probed or if a device has been compromised. To obtain an accurate log, perform the following steps on all network elements:

Configure all devices to use an accurate, centralized time source, such as an authenticated NTP server. Enable timestamping on all Cisco IOS and CatOS devices. Designate a syslog server to receive logging information.
Design a Secure IP Network

Before installing IP phones on the network, spend time on designing a sound and secure IP network. Think about using separate broadcast domains, building logical associations of IP telephony equipment, isolating the IP telephony management servers, establishing security relationships, and building perimeters secure from both outside attackers and internal users. When building a secure IP telephony network, follow these guidelines:
Place all Cisco CallManagers, IP telephony application servers, and IP telephones on their own, separate IP networks. (See Creating and Assigning VLANs and Broadcast Domains, page 15-5.) Ideally, these subnets should use a different major address range than the corporate data networks. Where possible, use RFC 1918 IP address space, which cannot be routed to the Internet, to further separate the IP telephony networks. For example, all data network elements such as PCs and fileservers could use the 171.68.x.x address range, and the IP telephony elements could use the 10.x.x.x address range. Use NAT judiciously to provide translation between the voice and data IP networks, and configure it only where required by Call Center applications, Cisco IP SoftPhone, or Cisco WebAttendant. The Internet gateway router or firewall should not allow NAT translations for Internet-to-IP telephony connectivity.
Use IP filters on the gateway router between the IP telephony network and the enterprise data network to eliminate any well-known, malicious attacks that might originate from within the corporate network. (See Implementing Packet Filters, page 15-7.) Place firewalls in front of the Cisco CallManager clusters. (See Firewalls, page 15-10.)
The following sections provide more details about the preceding guidelines.
Creating and Assigning VLANs and Broadcast Domains

Many IP security solutions can be implemented only if a packet encounters a Layer 3 (IP) device. Due to protocol architecture, the MAC Layer, or Layer 2, offers very little or no inherent security. Because of this, understanding and establishing broadcast domains is one of the fundamental precepts in designing secure IP networks. Many simple yet dangerous attacks can be launched if the attacking device resides within the same broadcast domain as the target system. The Cisco CallManager cluster, IP telephones, VoIP gateways, and network management workstations should always be on their own subnets, separate from the rest of the data network and from each other. In fact, every device should use a separate segment to connect to the network. Using separate segments for devices (in other words, a switched Ethernet infrastructure) prevents any attacker or attacking
15-5
Chapter 15 Design a Secure IP Network
application from snooping or capturing other Ethernet traffic as it traverses the physical wire. By making sure each device connects to the network using a switched infrastructure, you can render packet-sniffing tools less effective for capturing user traffic. In addition, the recommended Cisco AVVID design model uses separate subnets for an IP phone and its attached data PC by using 802.1Q VLAN trunking technology. Figure 15-1 depicts the major components in a typical enterprise network. In this example, all IP telephony components reside on various subnets and VLANs in the voice IP network (10.x.x.x), and all data pieces such as PCs, email servers, and the DHCP server, reside on the data IP network (171.68.x.x). In addition, this network is a 100% switched Ethernet environment with every user and device residing on a separate segment.
Figure 15-1 Typical Enterprise Network
TFTP Server Voice NetMgmt and Syslog VLAN

M
CallManager Cluster VLAN

M M
Data servers TACACS+ VLAN=20
VLAN=100 VLAN=101 VLAN=102 VoIP gateway VLAN PSTN VLAN=21 DHCP server
Voice VLANs 10.x.x.x VVID=110 Data VLANs 171.68.x.x VVID=111 VVID=112
VLAN=10
VLAN=11
VLAN=12
Note
Assigning static IP addresses or using a separate DHCP server for IP telephony, located within the IP telephony subnets, is a more secure solution for IP address management for the IP phones. Exposing the phone IP addresses to the untrusted, internal corporate data network can compromise the voice network DHCP services. Another, more secure, option is to assign IP addresses statically to the IP phones.
15-6
EDCS-197018
72406
Chapter 15
Implementing Packet Filters

Using IP filters has been an integral piece in building secure networks for several years. Cisco highly recommends that you use filters when securing IP telephony networks in order to limit access to the voice network. In most enterprises, you would place these filters on the router connecting the IP telephony and data networks. Filters can help with the following types of security issues:

Directed Broadcasts, page 15-7 Source-Routed Packets, page 15-7 IP Spoofing, page 15-7 ICMP Redirects, page 15-8 TCP Intercept, page 15-8 Permitting Other Services, page 15-8 Protecting the VoIP Gateways, page 15-10
Directed Broadcasts
IP directed broadcasts are used in the popular smurf denial-of-service attack and derivatives thereof. An IP directed broadcast is a datagram that is sent to the broadcast address of a subnet to which the sending machine is not directly attached. The directed broadcast is routed through the network as a unicast packet until it arrives at the target subnet, where it is converted into a link-layer broadcast. Because of the nature of the IP addressing architecture, only the last router in the chain, the one that is connected directly to the target subnet, can conclusively identify a directed broadcast. Directed broadcasts are occasionally used for legitimate purposes, but such use is not common outside the financial services industry. In a smurf attack, the attacker sends Internet Control Message Protocol (ICMP) echo requests from a falsified source address to a directed broadcast address, causing all the hosts on the target subnet to send replies to the falsified source. By sending a continuous stream of such requests, the attacker can create a much larger stream of replies, which can completely inundate the host whose address is being falsified. If a Cisco interface is configured with the no ip directed-broadcast command, directed broadcasts that would otherwise expand into link-layer broadcasts at that interface are dropped instead.
Source-Routed Packets
The IP protocol supports source routing options that allow the sender of an IP packet to control the route that packet takes toward its ultimate destination, and generally the route that any reply takes. These options are rarely used for legitimate purposes in real networks but can be used for attacking hosts on an enterprise network. A Cisco router with no ip source-route set will never forward an IP packet that carries a source routing option. Use this command on the router connected to the Internet as well as on the gateway router connecting the IP telephony and data networks within the enterprise.
IP Spoofing
Many widespread denial-of -service attacks rely on the ability of the attacker to send packets with forged (spoofed) source addresses, which makes it very difficult to track the true source of the attack. To help prevent your site from sourcing these types of attacks, you should block any outbound packets outside of your own address space. Cisco also recommends that the Service Provider network implement RFC 2827 IP address blocking to help prevent spoofed traffic.
15-7
ICMP Redirects
Redirect messages in Internet Control Message Protocol (ICMP) instruct end nodes to use a specific router as the path to an IP destination. In a properly functioning IP network, a router will send redirects only to hosts on its own local subnets, no end node will ever send a redirect, and no redirect will ever be traversed more than one network hop. However, an attacker can violate these rules. In fact, some attacks are based on this mechanism. To help guard against this threat, Cisco recommends using an access list on the border router between the IP telephony network and the data network to filter all ICMP redirects. ICMP redirect filtering prevents only redirect attacks initiated by attackers across at least one network hop. If the attacker is connected to the same subnet, it is still possible to launch this type of attack. This is another reason to ensure that all data devices such as user PCs, UNIX stations, and servers are always on a separate network from all voice devices and end-points.
TCP Intercept
TCP Intercept is a Cisco IOS feature that is specifically designed to protect vulnerable hosts from SYN attacks. These attacks abuse a common flaw in TCP implementations to render the host temporarily unable to accept incoming connections. To help protect the VoIP network from these attacks, configure an access list on the gateway router between the IP telephony and data networks to match any destination IP addresses in the voice network. Then apply the ip tcp intercept list command to the Ethernet interface to look for suspicious TCP SYN traffic.
Permitting Other Services

Enterprises with the most stringent security policies can prohibit any connections between the voice and data networks. This greatly reduces the threat of any attacks. However, many enterprises require at least minimal communication between the data network and IP telephony network for policy, application, or cost reasons. For example, some companies might not want to use a separate Dynamic Host Configuration Protocol (DHCP) server for voice and data devices because of the increased costs and management complications associated with a second server. Table 15-1 lists applications and ports that you might have to leave open on both the data and telephony routers, thus requiring the use of filters.
Table 15-1 Applications and Ports that Use Both Data and Telephony Networks
Application Routing protocol DHCP
Port Protocol dependent UDP 67-68
Direction

Requirement IP routing Single enterprise-wide DHCP used for PCs and IP phones. A more secure alternative is to use static IP addresses for IP phones or a separate DHCP server for IP telephony.
Direction: both ways Source: AVVID network to corporate DHCP server Destination: corporate DHCP server AVVID IP phones Direction: UDP 67 from clients, UDP 68 from server Source/Destination: Network Administration subnet and AVVID network Direction: both ways
ICMP
IP ICMP echo and echo-reply
Basic troubleshooting. Allow this privilege for Network Administrator only.
15-8
EDCS-197018
Chapter 15
Table 15-1 Applications and Ports that Use Both Data and Telephony Networks (continued)
Application NTP
Port TCP 123
Direction
Requirement Synchronized timestamps on all network elements for troubleshooting and tracking
Source: routers, switches, gateways, Cisco CallManagers and management servers Destination: trusted enterprise NTP server Direction: both ways
Telnet
TCP 23
Source: Network Administration subnet Configuration and troubleshooting. Use when SSH is not available. Allow Destination: AVVID network this privilege for Network Direction: both ways Administrator only.

SSH
TCP 22
Source: Network Admin subnet Destination: All routers on all subnets Direction: both ways Source: AVVID network
Configuration and troubleshooting. SSH provides a more secure method of administering network elements.
RADIUS
UDP 1645, 1646, 1812,1813
Router, switch, and VoIP gateway access configuration. Ports depend Destination: Corporate TACACS+ server upon whether it is Direction: one way Cisco IOS (1645-46) or CatOS (1812-13).

TACACS+
TCP 49
Source: AVVID network Destination: Corporate TACACS+ server Direction: one way Source: AVVID network Destination: Corporate DNS servers Direction: one way
Router, switch, and VoIP gateway access configuration
DNS
TCP and UDP 53
Cisco CallManager server lookups, TFTP server lookups, and FTP server lookups IP phones, LDAP gateways, and AVVID network management servers
LDAP
TCP 389 UDP 389
Source: AVVID network Destination: Corporate LDAP servers Direction: one way Source/Destination: Corporate data network and Cisco CallManagers Direction: both ways Source: Softphone client Destination: TCP port 8404 on Cisco CallManager
Cisco CallManager LDAP functionality
SoftPhone
TAPI/JTAPI = TCP 2748 VoIP Media Stream = UDP 16384-32767
SoftPhone residing on user PCs
SoftPhone Directory Lookup
TCP = 8404
Softphone directory services. Softphone also has an LDAP client for querying the corporate LDAP service using TCP 389.
15-9
Table 15-1 Applications and Ports that Use Both Data and Telephony Networks (continued)
Application IP-IVR
Port TAPI/JTAPI = TCP 2748 VoIP Media Stream = UDP 16384-32767
Direction

Requirement Required only if the IP-IVR server is located on the data network instead of the AVVID network. Not recommended. Required only if the IPCC server is located on the data network instead of the AVVID network. Not recommended. Administration of Cisco CallManager service. Allow subnet access for Network Administrator only.
Source: IP-IVR Server Destination: AVVID network Direction: both ways Source: GeoTel IPCC Server Destination: Cisco CallManagers Direction: both ways Source: Corporate data network Destination: AVVID network Direction: one way
IPCC
TAPI/JTAPI = TCP 2748
HTTPS
TCP 443
Protecting the VoIP Gateways

As illustrated in Figure 15-2, it is important to prevent direct call setup attempts to the VoIP gateways from any devices on the data network. The easiest way to do this is through the use of access control lists (ACLs) on either the gateway router or the VoIP gateway itself.
Figure 15-2 Preventing Direct Calls from the Data Network
V
M M M
3640
Voice network 10.x.x.x
Data network 172.21.x.x

72404
Firewalls
Today Internet firewalls are a default piece of network infrastructure. This document assumes that you have already implemented an Internet security policy and architecture using network design, firewalls, and intrusion detection applications. Sound security policies dictate that any partner connections require additional firewall measures. Once these basic firewalls are in place, and you have built the AVVID network and connected it to the existing IP network, you should add another firewall between the Cisco CallManager cluster and the IP telephony and data networks, as illustrated in Figure 15-3.
15-10
EDCS-197018
Chapter 15
Figure 15-3 Building a Firewall Around Cisco CallManager
VLAN 100 CallManager cluster

M
Publisher VLAN Firewall
Data network 172.21.x.x
Subscriber
M M
Subscriber Subscriber
V
SQL database update Intra cluster broadband messaging
Voice network 10.x.x.x

72405
Note
Before adding a firewall in front of the Cisco CallManager cluster, it is important to off-load all VoIP Real-Time Transport Protocol (RTP) applications that use Cisco CallManager to a dedicated server or hardware platform that resides on the voice VLANs. These VoIP RTP applications include conferencing, Media Termination Point (MTP), and transcoding. By placing a firewall between the Cisco CallManager cluster and both the voice and data networks, you greatly reduce the exposure of the most critical component in the Cisco AVVID network, the call processing agent. The firewall acts as a guardian between all IP devices and the Cisco CallManagers, ensuring that only specific transactions are allowed. Table 15-2 lists some transactions that would typically be allowed through the Cisco CallManager cluster firewall.
Table 15-2 Transactions Allowed Through the Cisco CallManager Firewall
Protocol Skinny Client Skinny Gateway (Analog) Skinny Gateway (Digital) H.323 RAS H.323 (H.225) H.323 (H.245) MGCP CTI (TAPI/JTAPI) HTTPS LDAP SoftPhone Directory DNS (optional, configuration dependent)
Port TCP 2000 TCP 2001 TCP 2002 TCP 1719 TCP 1720 TCP 11xxx UDP 2427 and TCP 2428 TCP 2748 TCP 443 TCP/UDP 386 TCP 8404 UDP 53
15-11
Chapter 15 Secure the Cisco CallManager Server
Table 15-2 Transactions Allowed Through the Cisco CallManager Firewall (continued)
Protocol NTP SNMP Syslog
Port UDP 123 UDP 161,162 UDP 514
Secure the Cisco CallManager Server

Once you have completed all of the network design portions of securing the IP telephony network, you can address Cisco CallManager server security. Cisco CallManager runs on a server that uses the Microsoft Windows 2000 Server operating system. Windows 2000 is much more secure than any previous Microsoft operating system because of the default file permission settings, improved TCP/IP stack, and configuration granularity. Nevertheless, you should verify the following server configuration settings in order to minimize potential vulnerabilities:

Turn off Unnecessary Services, page 15-12 Secure the NTFS File System, page 15-13 Enable System Auditing and Logging, page 15-14 Configure Certificate Authority, page 15-15 Secure the IIS Service, page 15-15 Secure the SQL Server, page 15-18 Remove Any Software MTP and Conferencing Services, page 15-18 Configure Cisco CallManager SNMP Securely, page 15-19
Many of these settings have already been added by the Operating System install CD that comes with Cisco CallManager. However, as with the default Cisco IOS settings, it is always a good idea to verify the configuration. For new information on securing Cisco CallManager or any other servers and workstations using Microsoft operating systems, Cisco highly recommends that you make it a routine part of your enterprise security policy to visit the Microsoft security site regularly at http://www.microsoft.com/security
Turn off Unnecessary Services

When the Windows 2000 operating system installs, there are several applications and services enabled by default, but they are not needed on the Cisco CallManager server. One of the fundamental principles of securing a server is that each service running on it can expose potential security vulnerabilities. Since securing every service is difficult and time-consuming, it is best to disable all services that are not mandatory, even if those services are not directly known to have a security hole. To eliminate potential security risks, stop the following services and set them to the Manual state, unless that service is otherwise needed on the system:

Alerter Service Clipbook Server Computer Browser
15-12
EDCS-197018
Chapter 15
Security Recommendations for IP Telephony Secure the Cisco CallManager Server
Distributed File System DHCP Client Messenger Net Logon Network DDE and DDE DSDM Network Monitor Agent Spooler SMTP Service NNTP Service DHCP Service DNS Server Service FTP Publishing Service Fax Service NetMeeting Remote Desktop Sharing
On subscriber servers in the Cisco CallManager cluster, disable the following services in addition to those listed above:

IIS Admin Service World Wide Web Publishing Service
All of the web administration takes place on the publisher server in the Cisco CallManager cluster, so there is no reason to keep these services running on the subscriber servers. The publisher databases have read and write access, while all of the subscriber databases have only read access.
Secure the NTFS File System

There is no reason to allow unknown users to log into the Cisco CallManager system. However, it is still a sound security policy to sanitize the different accounts and apply the proper permissions to the file system structure. Perform the following main tasks to tighten file access security:
Secure the NTFS permissions on the file system. As a general rule, NTFS permissions are cumulative. If someone is a member of two groups that have access to a directory, that person has the higher access of the two groups. The exception is for explicit deny-access settings. If there are two groups assigned to a directory, and one group is explicitly denied, anyone in both groups will be denied because an explicit denial overrides everything.
Provide a secure method of file access. Accessing the file system through IIS is similar to accessing a file remotely through Windows Explorer. A share is set up that allows someone to access a resource. IIS is just another means of sharing a series of files or resources. When someone attempts to access a resource through a share, the access that person has is the cumulative access of any groups given access to that share. However, when someone accesses an NTFS secured resource through a share, the most restrictive access applies. If someone has administrative privileges via IIS but only read access on the file system itself, total access level for that person is read only.
15-13
To secure file access, you have to modify the accounts themselves. Disable the Guest account and remove any users from the Guests group. All accounts except the Administrator account will become locked if someone tries to enter too many wrong passwords. The Administrator account never locks up, so many attacks rely on blindly trying to execute commands as Administrator. By changing the name of the Administrator account to CallmgrAdmin or some other logical name, you can prevent these types of attacks. Another recommended practice to secure Windows 2000 account access is to secure all privileges of the Everyone group. The Everyone group has access to every file be default. Remove this account from the root file system by performing the following steps:
Step 1 Step 2 Step 3 Step 4
Right-click on the c: in Windows Explorer. Select Properties > Security. Add the Administrator group, and check every access box to make sure full access is granted. Remove the Everyone group.
Note
If you set Everyone to No Access, no one, not even the administrator, can access the system.
Enable System Auditing and Logging

Auditing lets you track the usage of many privileged tasks in Windows 2000. When auditing is enabled, regularly reviewing the Event Viewer can help you determine if the system has been compromised. Table 15-3 shows a suggested auditing scheme
Table 15-3 Suggested Auditing Scheme
Description Audit Account Login Events Audit Account Management Audit Directory Service Access Audit Login Events Audit Object Events Audit Policy Change Audit Privilege Use Audit Process Tracking Audit System Events
Log Access Yes Yes Yes Yes No Yes Yes No Yes
Log Failure Yes Yes Yes Yes Yes Yes Yes Yes Yes
Structured Query Language (SQL) Server 7.0 provides a very powerful profiler, which enables the analysis of many internal events that occur within SQL Server. SQL Server Profiler works by capturing all the actions performed on the SQL Server and sending them to the SQL Server Profiler, where they
15-14
EDCS-197018
Chapter 15
can be analyzed. The capture can be viewed in real-time on the screen, saved to a text file, or inserted into a SQL Server table. The SQL Server Profiler allows capturing of virtually all events that take place within SQL Server, including:

Login Failed Locking: Deadlock Object: Closed Stored Procedure: Statement Starting Session: Disconnect RPC: Completed
This information can provide excellent support to establish event time and origin.
Configure Certificate Authority

To establish secure communications between web clients and the IIS Server on the Cisco CallManager database publisher, secure certificates are required. To set up the certificates, perform the following steps:
Step 1 Step 2
Build a Domain Controller and configure it so that a Certificate Authority is in place. Configure IIS to allow only encrypted, certificate-authenticated connections.
If you have an existing Certificate Authority you want to use, simply configure IIS to use certificates. Otherwise, you first have to build a Windows 2000 Domain Controller and Certificate Authority server. You could use this same server as the certificate server for multiple clusters. To take advantage of the integrated Windows authentication, you should add all of the Cisco CallManager servers to the domain.
Secure the IIS Service

Internet Information Server (IIS) is a major component on the Cisco CallManager server. All administration of Cisco CallManager flows through this service. The difficulty lies in the fact that IIS has been a target of several well-known attacks. Because of these attacks, Cisco recommends that you perform the following tasks to enhance IIS security:

Enable Certificate Authentication Only, page 15-16 Enable W3C Extended Logging Format, page 15-16 Clear Indexing, page 15-16 Remove IIS Virtual Directories, page 15-16 Remove All Sample Application Directories, page 15-16 Set Appropriate Virtual Directory Permissions in Web Application Space, page 15-17 Set Appropriate IIS Log File Permissions, page 15-17 Set the Security Access Permissions, page 15-17 Force the Use of HTTPs Only, page 15-17
15-15
Enable Certificate Authentication Only

By enabling certified browsing only, you ensure that the contents of the web pages are encrypted and authenticated during transmission. Once a certificate has been requested and granted, that certificate has to be applied to the web site.
Enable W3C Extended Logging Format

The default logging mechanism does not record enough information to help determine whether a server is under attack. Enable the W3C extended logging format to provide more information.
Clear Indexing
By indexing source code, an attacker can view the content of web pages. To clear indexing, follow these steps:
Start the IIS Microsoft Management Console (MMC) and go to the Web Site Properties by right-clicking on the web site entry and selecting Properties. Select the Home Directory tab. Clear the Index this Directory and the Directory browsing allowed options.
Remove IIS Virtual Directories

Remove the following virtual directories from IIS:

IISAMPWD IISSAMPLES IISADMIN IISHELP
Remove All Sample Application Directories

The following directories contain sample files that you should remove from the system. This will prevent an attacker from exploiting vulnerabilities in one of the sample files to gain access to the system.

\Inetpub\iisamples \Inetpub\scripts\samples \Inetpub\wwroot\samples \Program Files\Common Files\System\msadc\Samples \WINNT\system32\inetsrv\adminsamples \WINNT\system32\inetsrv\iisadmin \WINNT\system32\inetsrv\iisadminpwd
15-16
EDCS-197018
Chapter 15
Set Appropriate Virtual Directory Permissions in Web Application Space

It is important to ensure you apply the correct permissions to the files available on the web server. These permissions vary depending on the type of files being accessed. Table 15-4 provides a rough guideline to follow.
Table 15-4 Web Server File Access Permissions
File Type CGI and related files: .EXE, .DLL, .CMD, .PL Script files: .ASP Include files: .INC, .SHTML, .SHTM Static content: .HTML, .GIF, .JPEG
Access Control List Everyone: Execute Administrators and System: Full Control Everyone: Execute Administrators and System: Full Control Everyone: Execute Administrators and System: Full Control Everyone: Execute Administrators and System: Full Control
Set Appropriate IIS Log File Permissions

To prevent malicious users from deleting log files that expose their activities, set the file permissions on the IIS generated log files (%systemroot%\system32\LogFiles) as shown in Table 15-5.
Table 15-5 IIS Log File Permissions
File Type .LOG files
Access Control List Everyone: Execute Administrators and System: Full Control
Set the Security Access Permissions

To prevent the transmission of clear text passwords, change the security setting from Basic Authentication to Integrated Windows Authentication.
Force the Use of HTTPs Only

Set up the CCMAdmin web site to allow secure connections only.
15-17
Secure the SQL Server

The Structured Query Language (SQL) Server database is a key part of Cisco CallManager. You can make the following simple changes to the SQL Server setup to help tighten overall call processing security:

Use a Separate Group for SQL Server Administration, page 15-18 Set the SQL Server to Use Windows 2000 Authentication Mode, page 15-18 Enable SQL Server Auditing, page 15-18
Do not use the sa account for daily administration, but rather only for emergencies. Once the sa password has been configured, put it in a safe and use an administrative group for all SQL Server administration and configuration.
Use a Separate Group for SQL Server Administration

Instead of using the sa account for administration and database configuration, Cisco recommends that you use a Windows 2000 group for administrative privileges. The administrators are granted access to SQL Server through group-wide Windows 2000 permissions.
Set the SQL Server to Use Windows 2000 Authentication Mode

Using only Windows 2000 Authentication Mode limits the complexity of the SQL Server access configuration, as follows:
Hive: HKEY_LOACL_MACHINE\SOFTWARE Key: \Microsoft\MSSQLServer\MSSQLServer\LoginMode
If the Key value is 0, then Mixed Mode has been configured. If it is a 1, then Windows 2000 Authentication Mode has been selected. If the sa password is blank, an intruder (or the Windows 2000 Administrator) can gain access to the server.
Enable SQL Server Auditing

Using the SQL Server Enterprise Manager, set the server logging to ALL. The auditing information is written to the SQL Server 7.0 error log.
Remove Any Software MTP and Conferencing Services

Cisco recommends that you do not install the software-based Media Termination Point (MTP) and conferencing services on the Cisco CallManager server. These applications terminate Real-Time Transport Protocol (RTP) and User Datagram Protocol (UDP) VoIP streams and mix them together to create another call leg or a conference call. The risk is that UDP is a difficult protocol to secure, and terminating it on the Cisco CallManager server exposures the server to attacks unnecessarily. To mitigate this risk, use either hardware-based MTP and conferencing or install the conferencing software on a separate Windows 2000 server.
15-18
EDCS-197018
Chapter 15
Security Recommendations for IP Telephony Additional References
Configure Cisco CallManager SNMP Securely

If you choose CiscoWorks during the initial Cisco CallManager installation, you enable Simple Network Management Protocol (SNMP) on the Cisco CallManager server. Several vulnerabilities result from starting the SNMP service on a Windows 000 server. Because of this, if SNMP is not required, Cisco recommends that you disable the SNMP service and configuration. However, if SNMP is used to manage the Cisco CallManager and IP telephony network, perform the following tasks to secure the system:
Change the default communities. By default, Windows 2000 installs the READ community as public. Change the READ community to a unique community name. You should treat both the READ and WRITE community strings as passwords, and use the same care to choose these strings as you would to choose any root password or router login.
Configure the IP telephony network management workstation as the only host able to send and receive TRAPs. Only a network management server on the IP telephony network should be allowed to send and receive SNMP TRAPs. Cisco highly recommends that you separate SNMP management servers for the corporate data network and IP telephony network so that no SNMP requests or replies can traverse the firewall.
See IEEE 802.1Q Information at http://grouper.ieee.org/groups/802/1/
15-19
15-20
EDCS-197018
C H A P T E R
16
Network Management Recommendations for IP Telephony

Built on the Cisco AVVID Network Infrastructure, a Cisco AVVID IP Telephony solution brings high-quality IP voice and fully integrated communications to reality by allowing data, voice, and video to be transmitted over a single network infrastructure. As with any networking solution, management is a key component. The CiscoWorks family of tools, Cisco CallManager, and various third-party tools provide management functions for IP telephony networks. This document introduces CiscoWorks voice management tools and discusses options available for Cisco AVVID IP Telephony environments. It contains the following main sections:

Voice Management Overview, page 16-1 CiscoWorks Voice Management Tools and Architecture, page 16-2 CiscoWorks Network Management Best Practices, page 16-6 Additional References, page 16-9
This document also provides a brief overview of network management technologies and the CiscoWorks system architecture, as well as best practices for managing the Cisco AVVID IP Telephony environment.
Voice Management Overview

This section presents an overview of voice management and introduces specific tools used to manage the Cisco AVVID IP Telephony network.
Voice Management Basics

In traditional PBX telephony, there is a distinct set of voice management concepts and processes. The convergence of voice and data has brought about a similar merge of data network and voice-only management. In fact, this merging of management tasks and processes is one of the key benefits of using a converged network as opposed to a dedicated voice-only network. However, it is still necessary to comprehend the traditional voice-only management concepts in order to relate the features available in that technology to the converged network management techniques.
16-1
Chapter 16 CiscoWorks Voice Management Tools and Architecture
Network management of data networks is often summarized by the so-called FCAPS model, defined in the functional model of the Open System Interconnection (OSI) management architecture (see FCAPS model under Additional References, page 16-9). In a traditional PBX environment, the approach to management is usually summarized as OAMP:

Operations Administration Maintenance Provisioning
CiscoWorks Voice Management Tools and Architecture

CiscoWorks voice management tools are used for the operations, administration, and maintenance portions of the OAMP model. This section introduces the individual CiscoWorks tools recommended for voice management, explains the CiscoWorks system architecture, and provides a deployment overview.
CiscoWorks IP Telephony Management Tools

Cisco recommends the following CiscoWorks products for voice management, to provide coverage in the areas of operations, administration, and maintenance:
CiscoWorks LAN Management Solution (LMS) CiscoWorks LMS provides core network management functionality for both the underlying Cisco AVVID network infrastructure and additional voice-related needs. For a detailed explanation of its architecture and a deployment overview, refer to Cisco AVVID Network Infrastructure Network Management (see Additional References, page 16-9).
CiscoWorks VoIP Health Monitor (VHM) VHM provides proactive fault monitoring of Cisco voice elements (Cisco CallManagers, voice gateways, and IP phone switches).
Service Level Manager (SLM) and Internetwork Performance Monitor (IPM) SLM and IPM are tools for measuring traffic characteristics of WAN links; focusing on latency, jitter, and packet loss. These tools leverage the Service Assurance Agent capability of Cisco IOS routers. SLM provides the capability of setting up and monitoring Service Level Agreements, while IPM provides detailed troubleshooting capabilities.
QoS Policy Manager (QPM) QPM provides tools and templates to deploy quality of service (QoS) configuration to network devices, as well as tools to classify and prioritize mission-critical, delay-sensitive applications such as voice.
Catalyst 6000 Network Analysis Module (NAM) The NAM is an integrated monitoring solution for the Catalyst 6500 and 6000 Series that enables greater visibility into all layers of the network. It provides real-time traffic analysis, troubleshooting, and proactive monitoring capabilities for both data and voice networks.
16-2
EDCS-197018
Chapter 16
Network Management Recommendations for IP Telephony CiscoWorks Voice Management Tools and Architecture
Integration with third-party products Other areas of voice management, such as provisioning of user services (phone numbers, services, and voice mail), provisioning and capacity management of voice gateways, as well as call accounting and billing, are not handled by the CiscoWorks family but may be covered by embedded Cisco CallManager tools or third party partner applications.
It is often necessary to expand manageability of the network into a Systems Management framework to encompass non-Cisco devices (such as servers, applications, and storage.) as well as to provide additional services such as accounting. While CiscoWorks network management products provide solid operations, administration, and maintenance functionality, they do not perform all management functions for all types of devices. Although there are facets and segments of network and systems management that CiscoWorks does not currently provide, it is important to note that CiscoWorks provides standard interfaces and APIs to ease its integration into various third-party products. (For further information, see Additional References, page 16-9.)
Cisco Network Management Architecture

The CiscoWorks family of network management products is intended for use as part of a management intranet, co-existing with other management servers. Users access these tools via a web browser interface, which allows managers to access management servers from anywhere in their network. The CiscoWorks architecture consists of a Common Management Framework (CMF) with a web-based desktop as a single point of management. An additional component, the asynchronous network interface (ANI), provides data collection services using Simple Network Management Protocol (SNMP), Cisco Discovery Protocol (CDP), and Interim Local Management Interface (ILMI) tables. Discovery of the network occurs via a seed device, preferably a router or a switch, through which the ANI discovers the network by reading its neighbors' CDP cache tables and SNMP variables. The ANI then uses this information to build a network topology map. The CMF also provides granular security, process control, and device information retrieval via SNMP. The CiscoWorks web server provides 5 levels of user roles, so that users can be restricted to read-only access or can have the ability to make changes to network devices. For detailed information regarding the network management architecture of the Cisco AVVID network infrastructure, refer to Cisco AVVID Network Infrastructure Network Management (see Additional References, page 16-9). In addition to managing the routers and switches of the Cisco AVVID infrastructure, the CiscoWorks tools communicate with devices providing voice services, such as Cisco CallManager, Cisco Conference Connection, and Cisco Emergency Responder, which themselves may provide other voice management services. CiscoWorks VoIP Health Monitor (VHM) proactively monitors Cisco voice servers and polls for reachability, interface status, environmental conditions (power supply, fan, temperature), and application status. In addition to monitoring of the voice server, VHM also verifies the availability of key voice services by performing synthetic transactions, wherein the VHM server emulates the behavior of a Cisco IP Phone and performs a specific transaction. The value of synthetic transactions is that, by actually accessing these critical voice services, it is possible to verify that the services are available. Supported transactions include:

Phone registration Off-hook End-to-end call TFTP download Conference creation
16-3
Chapter 16 CiscoWorks Voice Management Tools and Architecture
Conference join Emergency Responder 911 call
Both Cisco Service Level Manager and Internetwork Performance Monitor interact with the Service Assurance Agent (SA Agent) of Cisco IOS routers (see Additional References, page 16-9). Cisco IOS SA Agent generates synthetic traffic to measure network characteristics such as latency, jitter, and packet loss. It can also create a variety of end-to-end tests with various characteristics (protocol, ToS, and so on), which provide an accurate simulation of how critical traffic such as voice will behave. Latency and packet loss tests can be done from any SA Agent to any IP endpoint; jitter tests can be done between SA Agents. The Cisco Catalyst 6000 Network Analysis Module (NAM) provides visibility into all layers of network traffic by adding remote monitoring functions based on RMON2 and other advanced Management Information Bases (MIBs). Embedded in the NAM is a Web-based traffic analyzer application that provides extensive capabilities to analyze traffic in real time for several attributes, including hosts, conversations, and applications. Network managers can use this information for fault isolation and troubleshooting, managing network performance, and capacity planning. The NAM occupies a slot in a Catalyst 6000 or 6500 switch, and it can monitor traffic through that individual switch or via the Cisco Remote SPAN (RSPAN) feature. The NAM can also monitor traffic in remote Catalyst 6000 or 4000 series switches.
Note
The NAM monitors call setup and teardown messages via SCCP and H.323 traffic. The information seen by the NAM regarding packet loss and jitter for calls is actually collected by the Cisco IP Phone and then included in the Call Diagnostic Record sent back to Cisco CallManager when the call completes. Other key voice management functions are provided by Cisco CallManager, and the overall task of voice management is distributed among a number of servers and management products.
Deployment Considerations
When deploying CiscoWorks applications, use the standard recommended device configuration options for management described in Cisco AVVID Network Infrastructure Network Management (see Additional References, page 16-9).
Cisco CallManager Settings

In addition to the standard device recommendations, configure the following settings in order to manage the Cisco Media Convergence Servers (running Cisco CallManager or other applications):

SNMP RO community string SNMP RW community string Administrative level username and password for login to Cisco CallManager
To enable VHM Synthetic Transactions, configure test phone numbers on each Cisco CallManager. Keep in mind the following considerations when configuring the Cisco CallManager:

Allocate sufficient phone number extensions for synthetic testing. (See the VHM product documentation for details.) Use the appropriate phone type (Cisco IP Phone SP12+ for VHM Release 1.0 or Cisco IP Phone 7960 for VHM Release 1.1).
16-4
EDCS-197018
Chapter 16
Network Management Recommendations for IP Telephony CiscoWorks Voice Management Tools and Architecture
Enter a unique Media Access Control (MAC) address for each test phone. A good practice is to use MAC addresses that consist of the test phone extension number padded with leading zeros. For example, for a test phone with extension number 5-1100, use MAC address 0000.0005.1100.
In addition, for monitoring calls via the Network Analysis Module, configure the following on all Cisco CallManagers:

Call Diagnostic Records enabled (provides packet loss and jitter information) IP Telephone Line Setting Display (internal caller ID)
System Requirements
Another important consideration is the deployment methodology and placement of the many CiscoWorks products. You must determine how many servers will be needed and how to distribute applications across multiple management servers. The deployment methodology also depends on the size of the network (on the number and types of network devices) to be managed. VoIP Health Monitor Release 1.1 requires a dedicated server and does not support running the other CiscoWorks applications on the same server. VoIP Health Monitor is supported only on the Windows 2000 operating system. While it is possible to load the remaining CiscoWorks applications described in this document onto a single server, first take into account the following considerations:

Cisco recommends that you install the nGenius Real-Time Monitor (RTM) tool on a dedicated server for best performance. (RTM is included with the CiscoWorks LMS Bundle.) Depending upon the number of monitored pairs, you might have to install either Service Level Manager (SLM) or Internetwork Performance Monitor (IPM) on a dedicated server. SLM must be installed on top of Resource Manager Essentials (RME), included in the CiscoWorks LMS Bundle, or on top of CiscoWorks CD-Two, included with SLM, a mini-RME providing basic inventory data. QoS Policy Manager (QPM) is supported only on Window NT and Windows 2000 operating systems. QPM Release 3.0 provides a web browser interface; previous versions have a remote client component that can be installed on client systems to provide remote access to QPM.
Additional details on scaling considerations and descriptions of specific system resource usage characteristics for CiscoWorks are available online at Cisco.com. (See Additional References, page 16-9.)
Network Analysis Module Deployment

Deployment of Network Analysis Modules (NAMs), which monitor traffic passing through the Catalyst 6000 and 6500 series switch, must be planned based on traffic monitoring needs. While use of the Cisco RSPAN feature is a way to monitor remote traffic, it may be preferable to deploy NAMs in critical locations of the IP telephony network. The NAM monitors the call setup and teardown information passed in Skinny Client Control Protocol (SCCP) and H.323 traffic, so they should be deployed in locates where such traffic occurs. For example:

Catalyst 6000 access layer switch in data center with all Cisco CallManager and other voice servers directly attached Catalyst 6500 distribution or core layer switches
16-5
Chapter 16 CiscoWorks Network Management Best Practices
CiscoWorks Network Management Best Practices

While the specific needs of a given IP telephony network may vary, you should always perform the following common best practices:
Use a Domain Name System (DNS) server to provide accurate forward and reverse name resolution for all managed devices. Ideally, you should provide a separate DNS server that is used only by network management applications and managers (separate from a corporate or public DNS). Use an authentication, authorization, and accounting (AAA) server (TACACS+ or Radius) for controlling access to network devices. Make use of loopback interfaces on routers in order to have a single "preferrred management address" (and have this reflected in DNS). This interface can then be the source for syslog and Simple Network Management Protocol (SNMP) traps or notifications from the device. Use a Network Time Protocol (NTP) server. Use access lists and IP permit lists to restrict access to managed devices. In addition to CiscoWorks network management applications, use general-purpose performance and fault monitoring tools (for example, MRTG, Cisco Info Center, and HP Open View Network Node Manager).
Best Practices for Using CiscoWorks LAN Management Solution (LMS)

As described previously, CiscoWorks LAN Management Solution (LMS) provides core network management functionality for both the underlying Cisco AVVID network infrastructure and IP telephony needs. Observe the following best practices when using CiscoWorks LMS:

Run the web browser clients on a remote machines, not directly on a CiscoWorks server. Be sure to have sufficient RAM on client machines. In order to minimize or avoid browser problems related to Java and Java applets, be sure to use only a supported browser (refer to the LMS documentation available online at Cisco.com), and be sure that only the recommended Java Plug-In is installed. It is also best to avoid opening a large number of Java-based applications at any one time because more robust performance results from opening a single Java tool, and closing that applet when finished, rather than leaving the application running indefinitely. Do not quit the browser without logging out of the CiscoWorks server first. Use Campus Manager to perform network discovery, and be sure to work through any issues with discovery (finding all devices, ensuring device configuration is correct, ensuring name resolution is correct) before attempting to populate other CiscoWorks applications. Once network discovery is complete, use CiscoWorks server device synchronization options to allow the discovered information to populate the Resource Manager Essentials inventory as well as the Device Fault Manager and Voice Health Monitor inventories. Be sure to configure all device access credentials for Resource Manager Essentials to ensure successful TELNET access to devices. This access is necessary for correct and complete operation of the Configuration Archive and Configuration tools. Use the Change Audit feature to track changes to network devices. Limit syslog message traffic to an appropriate level for the CiscoWorks server. (Note that Change Audit depends upon severity 5 messages for configuration change notification.)
16-6
EDCS-197018
Chapter 16
Network Management Recommendations for IP Telephony CiscoWorks Network Management Best Practices
Do not attempt to schedule jobs for configuration changes or software updates for an excessively large number of devices. Schedule multiple smaller jobs instead. Be sure to turn on scheduled backups of the Resource Manager database. By default, backups are turned off but can easily be enabled so that backups are done automatically and periodically. Merely running system backups to copy server disks to tape will not result in valid backups of the database.
For further information on CiscoWorks LMS best practices for the Cisco AVVID infrastructure, refer to Cisco AVVID Network Infrastructure Network Management (see Additional References, page 16-9).
Best Practices for Using CiscoWorks VoIP Health Monitor (VHM)

Observe the following best practices when using CiscoWorks VoIP Health Monitor (VHM):
VHM (Release 1.1 and later) requires a dedicated server. It is possible for the Device Fault Manager (DFM) component to reside on the same server with VHM or to reside on the LMS server. In order for DFM and VHM to receive inventory information from Resource Manager, use either of the following two deployment options:
Install VHM and DFM on the same server. On the LMS server, do not install the full DFM
product, but instead choose the custom install option and select the DFM RME Adapter option. This option will prompt for the location of DFM and cause inventory information to be propagated from Resource Manager Essentials (RME) on the LMS server to DFM on the VHM server.
Install DFM on the LMS server and not on the VHM server. When installing VHM, you will be
prompted for the location of DFM. This entry will cause inventory information to be propagated from DFM on the LMS server to the VHM server.
Use the DFM and VHM Administration console to "unmanage" any objects (interfaces, power supplies, devices) which do not need to be monitored. By default, all objects that are discovered will be monitored, which may result in unnecessary alarm notifications. For example, if a router has an unused T1 interface, DFM and VHM may generate a fault notification indicating that the interface is administratively down. If no such notification is desired, change the status of the T1 interface from managed to unmanaged in the Administration console. Configure VHM Synthetic Transactions for all Cisco CallManagers and other voice servers, to test availability of voice services. Obviously, if a server is not offering a service (for example, if the Cisco CallManager publisher is not running the TFTP server), there is no need to test for that service on that server. Use DFM and VHM fault notifiers to forward SNMP traps to upstream trap listeners and to send email to a server that can generate pages if desired. DFM and VHM can edit "event subscription" to control and limit which specific events cause these notifications to be sent. There are separate subscriptions for the email and the trap notifiers. It may be appropriate to set up different user logins for the LMS server and the VHM server. For example, if there are different teams managing data networking and voice services, it might be preferable for each team to allow read-only or guest access logins to the other team. The data networking team could have admin-level access to the LMS server, and the voice services team could have admin-level access to the VHM server.
16-7
Chapter 16 CiscoWorks Network Management Best Practices
Best Practices for Using CiscoWorks QoS Policy Manager (QPM)

Observe the following best practices when using CiscoWorks QoS Policy Manager (QPM):
QPM release 2.x does not have a web browser interface, but does include remote client software. Install the remote client on client machines (such as those used to run the browser for accessing the other CiscoWorks applications). QPM can import device inventory information. Resource Manager Essentials can export a comma-separated variable (CSV) format file containing device credentials, which can be imported by QPM. QPM includes IP telephony QoS templates based on recommendations developed by Cisco Engineering. For very large deployments, QPM can create device groups in order to perform configuration updates.
Best Practices for Using CiscoWorks Service Level Manager (SLM)

Observe the following best practices when using CiscoWorks Service Level Manager (SLM):
SLM is part of the CiscoWorks Service Management Solution (SMS) suite. You can install SLM on the same server with Resource Manager (a component of LMS) or on a dedicated server. (Refer to the product documentation for specific prerequisites.) Service Management Solution offers the option of purchasing a CD with a remote collector. By installing the collector on remote systems, you can allow a large number of monitored pairs by distributing the load for polling Service Assurance (SA) Agents. (By default, only a single collector is installed on the server with SLM.) Use SLM to set up SLAs across WAN links to monitor latency, packet loss, and jitter characteristics of voice traffic. It may be useful to set up other similar SLAs for non-voice traffic in order to verify that QoS settings are actually having the intended effect on network traffic. For Service Level Agreement (SLA) monitoring of traffic within a LAN, you can use SA Agent on Catalyst 6000 Multilayer Switch Feature Cards (MSFCs). It may also be useful to deploy small Cisco routers (such as the Cisco 1600 or 800 series) as SA Agent probes at critical points, to act as endpoints for jitter tests. You may prefer to avoid enabling SA Agent on critical production routers for performance or Cisco IOS image reasons. This is another situation where use of small routers as SA Agent probes can be useful.
Best Practices for Using CiscoWorks Internetwork Performance Monitor (IPM)

Observe the following best practices when using CiscoWorks Internetwork Performance Monitor (IPM):

IPM is part of the CiscoWorks Routed WAN Solution, and it can be installed on the same server as LMS or on a standalone server. IPM is best used for troubleshooting when problems are detected, such as by SLA monitoring done by Service Level Manager. IPM can import device inventory information from Resource Manager Essentials, a component of LMS and Routed WAN (RWAN) Management Solution. When troubleshooting, it is very useful to set up multiple tests between two endpoints that use different type of service (ToS) values to verify whether QoS settings are operating as expected.
16-8
EDCS-197018
Chapter 16
Network Management Recommendations for IP Telephony Additional References
Design guides:

Cisco AVVID Network Infrastructure Network Management Integration with third-party products http://www.cisco.com/kobayashi/sw-center/cw2000/cmc3rd.shtml
CiscoWorks in Large-Scale Network Environments http://www.cisco.com/warp/customer/cc/pd/wr2k/prodlit/ckspp_wp.htm
Technology details:
FCAPS model http://nmcons/fundamentals_index.htm
Cisco IOS Service Assurance Agent (SA Agent) http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t2/ft2_apm.h tm
16-9
16-10
EDCS-197018

Cisco IP Telephony Solution Reference Network Design Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco IP Telephony Solution Reference Network Design Guide

Uploaded by

Copyright:

Available Formats

Cisco IP Telephony Solution Reference Network Design Guide

Cisco CallManager Release 3.1 and 3.2 July 2003

Customer Order Number: 956378 Text Part Number: EDCS-197018

Overview of Cisco AVVID IP Telephony Solutions Why IP Telephony?

Voice Mail 2-27 Music on Hold 2-27

Gateway Protocols 4-2 Selecting the Gateway Protocol

Call Admission Control Bandwidth Calculations

7-1 7-2 7-2