You are on page 1of 234

Cisco IP Contact Center Enterprise Edition Solution Reference Network Design (SRND

)
Cisco IP Contact Center Enterprise Edition Releases 5.0 and 6.0 May 2006

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

Text Part Number: OL-7279-04

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 UCB’s 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.

CCSP, CCVP, the Cisco Square Bridge logo, Follow Me Browsing, 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 Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries. All other trademarks mentioned in this document or Website 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. (0601R)

Cisco IP Contact Center Enterprise Edition SRND Copyright © 2004 Cisco Systems, Inc. All rights reserved.

CONTENTS
Preface
xi xi

Revision History

Obtaining Documentation xii Cisco.com xii Ordering Documentation xii Documentation Feedback
xii

Obtaining Technical Assistance xiii Cisco Technical Support Website xiii Submitting a Service Request xiii Definitions of Service Request Severity

xiv xiv

Obtaining Additional Publications and Information
1

CHA PTER

Architecture Overview Cisco CallManager

1-1 1-1 1-2 1-3 1-3

Cisco Internet Service Node (ISN)

Cisco IP Interactive Voice Response (IP IVR)

Cisco Intelligent Contact Management (ICM) Software Basic IPCC Call and Message Flow 1-4 ICM Software Modules 1-5 IPCC Components, Terminology, and Concepts 1-6 IPCC Agent Desktop 1-6 Administrative Workstation 1-7 JTAPI Communications 1-8 ICM Routing Clients 1-10 Device Targets 1-10 Labels 1-11 Agent Desk Settings 1-11 Agents 1-12 Skill Groups 1-12 Directory (Dialed) Numbers and Routing Scripts Agent Login and State Control 1-12 IPCC Routing 1-12 Translation Routing and Queuing 1-13 Reroute On No Answer (RONA) 1-14

1-12

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

iii

Contents

Combining IP Telephony and IPCC in the Same Cisco CallManager Cluster Queuing in an IPCC Environment
1-15

1-15

Transfers in an IPCC Environment 1-16 Dialed Number Plan 1-16 Dial Plan Type 1-17 Post Route 1-17 Route Request 1-17 Single-Step (Blind) Transfer 1-17 Consultative Transfer 1-18 Reconnect 1-19 Alternate 1-19 Non-ICM Transfers 1-19 Agent-to-Agent Transfers 1-20 Transferring from an IVR to a Specific Agent 1-20 Transfer Reporting 1-20 Combination or Multiple Transfers 1-20 Transfers of Conferenced Calls 1-21 PSTN Transfers (Takeback N Transfer, or Transfer Connect) Call Admission Control 1-21 Gatekeeper Controlled 1-22 Locations Controlled 1-23
2

1-21

CHA PTER

Deployment Models

2-1

Single Site 2-2 Treatment and Queuing with IP IVR 2-3 Treatment and Queuing with ISN 2-3 Transfers 2-3 Multi-Site with Centralized Call Processing 2-4 Centralized Voice Gateways 2-4 Treatment and Queuing with IP IVR 2-6 Treatment and Queuing with ISN 2-6 Transfers 2-6 Distributed Voice Gateways 2-7 Treatment and Queuing with IP IVR 2-9 Treatment and Queuing with ISN 2-9 Transfers 2-9

Cisco IP Contact Center Enterprise Edition SRND

iv

OL-7279-04

Contents Multi-Site with Distributed Call Processing 2-9 Distributed Voice Gateways with Treatment and Queuing Using IP IVR 2-10 Treatment and Queuing 2-11 Transfers 2-12 Distributed Voice Gateways with Treatment and Queuing Using ISN 2-12 Treatment and Queuing 2-13 Transfers 2-14 Distributed ICM Option with Distributed Call Processing Model 2-14 Clustering Over the WAN 2-15 Centralized Voice Gateways with Centralized Call Treatment and Queuing Using IP IVR 2-17 Centralized Voice Gateways with Centralized Call Treatment and Queuing Using ISN 2-18 Distributed Voice Gateways with Distributed Call Treatment and Queuing Using ISN 2-19 Site-to-Site ICM Private Communications Options 2-20 ICM Central Controller Private and Cisco CallManager PG Private Across Dual Links 2-20 ICM Central Controller Private and Cisco CallManager PG Private Across Single Link 2-21 Bandwidth and QoS Requirements for IPCC Clustering Over the WAN 2-22 Highly Available WAN 2-22 ICM Private WAN 2-23 Failure Analysis of IPCC Clustering Over the WAN 2-26 Entire Central Site Loss 2-26 Private Connection Between Site 1 and Site 2 2-26 Connectivity to Central Site from Remote Agent Site 2-26 Highly Available WAN Failure 2-26 Remote Agent Over Broadband 2-27 Remote Agent with IP Phone Deployed via the Business Ready Teleworker Solution IPCC Outbound (Blended Agent) Option Traditional ACD Integration 2-34 2-31 2-30 Traditional IVR Integration 2-35 Using PBX Transfer 2-35 Using PSTN Transfer 2-36 Using IVR Double Trunking 2-37 Using Cisco CallManager Transfer and IVR Double Trunking 3 2-38 CHA PTER Design Considerations for High Availability Designing for High Availability 3-1 3-5 3-1 Data Network Design Considerations Cisco CallManager and CTI Manager Design Considerations Configuring ICM for CTI Manager Redundancy 3-10 3-7 Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 v .

Only CTI Manager Fails 3-26 IPCC Scenarios for Clustering over the WAN 3-28 Scenario 1 .Cisco CallManager PG Side A Fails 3-24 Scenario 3 .Remote Agent Location WAN Fails 3-31 Understanding Failure Recovery 3-31 Cisco CallManager Service 3-31 IP IVR (CRS) 3-32 ICM 3-32 Cisco CallManager PG and CTI Manager Service 3-32 ICM Voice Response Unit PG 3-33 ICM Call Router and Logger 3-34 Admin Workstation Real-Time Distributor (RTD) 3-35 CTI Server 3-37 CTI OS Considerations Other Considerations 4 3-38 3-39 3-28 Cisco Agent Desktop Considerations 3-39 CHA PTER Sizing Call Center Resources 4-1 4-1 4-4 Call Center Basic Traffic Terminology Call Center Resources and the Call Timeline Cisco IP Contact Center Enterprise Edition SRND vi OL-7279-04 .ICM Central Controller or Peripheral Gateway Private Network Fails Scenario 2 .Cisco CallManager and CTI Manager Fail 3-23 Scenario 2 .Visible Network Fails 3-29 Scenario 3 .Only Cisco CallManager Fails 3-25 Scenario 4 .Visible and Private Networks Both Fail (Dual Failure) 3-30 Scenario 4 .Contents IP IVR (CRS) Design Considerations 3-11 IP IVR (CRS) High Availability Using Cisco CallManager IP IVR (CRS) High Availability Using ICM 3-13 Internet Service Node (ISN) Design Considerations 3-13 3-13 Multi-Channel Design Considerations (Cisco Email Manager Option and Cisco Collaboration Server Option) 3-15 Cisco Email Manager Option 3-17 3-18 3-19 Cisco Collaboration Server Option Cisco IPCC Outbound Option Design Considerations Peripheral Gateway Design Considerations 3-20 Cisco CallManager Failure Scenarios 3-22 ICM Failover Scenarios 3-23 Scenario 1 .

Contents Erlang Calculators as Design Tools Erlang-C 4-5 Erlang-B 4-5 4-4 Cisco IPC Resource Calculator 4-6 IPC Resource Calculator Input Fields (What You Must Provide) 4-7 IPC Resource Calculator Output Fields (What You Want to Calculate) Sizing Call Center Agents. IVR Ports. and Trunks 4-11 Basic Call Center Example 4-11 Call Treatment Example 4-13 After-Call Work Time (Wrap-up Time) Example 4-14 Call Center Sizing With Self-Service IVR Applications 4-15 Call Center Example with IVR Self-Service Application 4-16 Sizing ISN Components 4-20 ISN Server Sizing 4-20 Sizing ISN Licenses 4-23 ISN Software Licenses 4-23 ISN Session Licenses 4-23 Alternative Simplified Method for ISN Capacity Sizing Cisco IOS Gateway Sizing 4-24 ICM Peripheral Gateway (PG) Sizing 4-24 Prompt Media Server Sizing 4-24 Agent Staffing Considerations 4-25 4-25 4-8 4-23 Call Center Design Considerations 5 CHA PTER Sizing IPCC Components and Servers 5-1 Sizing Considerations for IPCC 5-1 Core IPCC Components 5-1 Minimum Hardware Configurations for IPCC Core Components Additional Sizing Factors 5-9 Peripheral Gateway and Server Options CTI OS 5-11 5-10 5-8 Cisco Agent Desktop Component Sizing 5-12 Cisco Agent Desktop Base Services 5-13 Cisco Agent Desktop VoIP Monitor Service 5-13 Cisco Agent Desktop Recording and Playback Service Summary 5-14 5-13 Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 vii .

1 and 3.3 and Later Cisco CallManager Platform Capacity Planning with IPCC Cisco CallManager Capacity Tool 6-5 6-4 6-3 6-4 Supported Cisco CallManager Server Platforms for IPCC Enterprise Call Processing Redundancy with IPCC Cluster Configurations for Redundancy Load Balancing With IPCC 6-13 6-9 6-10 6-7 Impact of IPCC Application on Cisco CallManager Performance and Scalability 7 6-13 CHA PTER Agent Desktop and Supervisor Desktop 7-1 Types of IPCC Agent Desktops 7-2 Cisco Agent Desktop and Cisco Supervisor Desktop Cisco Agent Desktop 7-5 IP Phone Agent (IPPA) 7-6 Cisco Supervisor Desktop 7-6 CTI Object Server (CTI OS) Toolkit 7-6 7-3 Additional Information about Cisco Agent Desktop and Supervisor Desktop 8 7-8 CHA PTER Bandwidth Provisioning and QoS Considerations IPCC Network Architecture Overview 8-2 Network Segments 8-3 UDP Heartbeat and TCP Keep-Alive 8-4 IP-Based Prioritization and QoS 8-5 Traffic Flow 8-6 Public Network Traffic Flow 8-6 Private Network Traffic Flow 8-6 Bandwidth and Latency Requirements 8-7 8-1 Network Provisioning 8-8 Quality of Service 8-8 QoS Planning 8-8 Public Network Marking Requirements Configuring QoS on IP Devices 8-9 Performance Monitoring 8-10 8-8 Cisco IP Contact Center Enterprise Edition SRND viii OL-7279-04 .Contents CHA PTER 6 Sizing Cisco CallManager Servers For IPCC Call Processing With IPCC Enterprise IPCC Clustering Guidelines 6-2 6-1 6-1 IPCC Enterprise with Cisco CallManager Releases 3.2 IPCC Enterprise with Cisco CallManager Releases 3.

Contents Bandwidth Sizing 8-10 IPCC Private Network Bandwidth 8-10 IPCC Public Network Bandwidth 8-11 Bandwidth Requirements for CTI OS Agent Desktop 8-11 CTI OS Client/Server Traffic Flows and Bandwidth Requirements 8-11 Best Practices and Options for CTI OS Server and CTI OS Agent Desktop 8-12 Bandwidth Requirements for Cisco Agent Desktop Release 6.0 8-13 Call Control Bandwidth Usage 8-13 Silent Monitoring Bandwidth Usage 8-16 Service Placement Recommendations 8-24 Quality of Service (QoS) Considerations 8-24 Cisco Desktop Component Port Usage 8-25 Integrating Cisco Agent Desktop Release 6.0 GL O S S A R Y INDEX Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 ix .0 into a Citrix Thin-Client Environment 9 8-25 CHA PTER Securing IPCC 9-1 9-1 Introduction to Security Security Best Practices 9-2 Default (Standard) Windows 2000 Server Operating System Installation Cisco-Provided Windows 2000 Server Installation (CIPT OS) 9-3 Patch Management 9-3 Default (Standard) Windows 2000 Server Operating System Installation Cisco-Provided Windows 2000 Server Installation (CIPT OS) 9-3 Antivirus 9-4 9-5 9-6 9-2 9-3 Cisco Security Agent Firewalls and IPSec Firewalls 9-6 IPSec and NAT 9-6 9-8 Security Features in Cisco CallManager Release 4.

Contents Cisco IP Contact Center Enterprise Edition SRND x OL-7279-04 .

Fixed several broken links in the online document. refer to the documentation at the preceding URL.com website periodically and check for documentation updates by comparing the revision date (on the front title page) of your copy with the revision date of the online document. You can obtain the latest version of this document online at http://www. the information in this document applies specifically to Cisco IP Contact Center Enterprise Edition Releases 5.com/go/srnd Visit this Cisco.cisco.com/go/srnd This document assumes that you are already familiar with basic contact center terms and concepts and with the information presented in the Cisco IP Telephony SRND. Corrected various typographical errors in the document. The following table lists the revision history for this document. 2005 March. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 xi .0 and 6. and Integrated Data (AVVID).0 and 6.0. To review IP Telephony terms and concepts. Revision Date May.Preface This document provides design considerations and guidelines for implementing Cisco IP Contact Center (IPCC) Enterprise Edition solutions based on the Cisco Architecture for Voice.cisco. 2005 Comments Corrected a few errors in the text and updated some of the referenced URL. which are available online at http://www. Initial version of this document for Cisco IPCC Enterprise Edition Releases 5. Video. This document may be updated at any time without notice. This document builds upon ideas and concepts presented in the Cisco IP Telephony Solution Reference Network Design (SRND). Revision History Unless stated otherwise. 2006 December.0. 2005 June.

Documentation Feedback You can send comments about technical documentation to bug-doc@cisco.com/public/countries_languages.shtml Ordering Documentation You can find instructions for ordering documentation at this URL: http://www.htm You can access the Cisco website at this URL: http://www.Preface Obtaining Documentation Obtaining Documentation Cisco documentation and additional literature are available on Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California.com/en/US/partner/ordering/index.com You can access the most current Cisco documentation at this URL: http://www.com.shtml • Nonregistered Cisco. You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address: Cisco Systems Attn: Customer Document Ordering 170 West Tasman Drive San Jose. Cisco IP Contact Center Enterprise Edition SRND xii OL-7279-04 . elsewhere in North America.htm You can order Cisco documentation in these ways: • Registered Cisco. Cisco also provides several ways to obtain technical assistance and other technical resources.cisco.cisco. CA 95134-9883 We appreciate your comments. These sections explain how to obtain technical information from Cisco Systems.com/univercd/home/home. USA) at 408 526-7208 or.cisco. Cisco.cisco. by calling 1 800 553-NETS (6387).com You can access international Cisco websites at this URL: http://www.com/univercd/cc/td/doc/es_inpck/pdi.cisco.com users (Cisco direct customers) can order Cisco product documentation from the Ordering tool: http://www.com.

The TAC Service Request Tool is located at this URL: http://www. In addition. The website is available 24 hours a day. or click the Cisco Product Identification Tool link under Alerts & RMAs. the TAC Service Request Tool provides recommended solutions. at this URL: http://www. Submitting a Service Request Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests.com/RPF/register/register. The Cisco Technical Support Website on Cisco. Search results show an illustration of your product with the serial number label location highlighted.cisco. award-winning technical assistance. If you have a valid service contract but do not have a user ID or password. contact the Cisco TAC by telephone. Cisco Technical Support provides 24-hour-a-day.com user ID and password. and distributors who hold valid Cisco service contracts.do Note Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting a web or phone request for service. To open a service request by telephone.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly. go to this URL: http://www. Locate the serial number label on your product and record the information before placing a service call. Cisco Technical Support Website The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. You can access the CPI tool from the Cisco Technical Support Website by clicking the Tools & Resources link under Documentation & Tools.cisco. by copying and pasting show command output.com features extensive online support resources. partners. you can register at this URL: http://tools. use one of the following numbers: Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227) EMEA: +32 2 704 55 55 USA: 1 800 553-2447 For a complete list of Cisco TAC contacts.) After you describe your situation. resellers. contact your reseller. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information. 365 days a year. by tree view. The CPI tool offers three search options: by product ID or model name.Preface Obtaining Technical Assistance Obtaining Technical Assistance For all customers.com/techsupport/servicerequest For S1 or S2 service requests or if you do not have Internet access.cisco. If your issue is not resolved using the recommended resources. Choose Cisco Product Identification Tool from the Alphabetical Index drop-down list.com/techsupport Access to all tools on the Cisco Technical Support Website requires a Cisco.cisco. (S1 or S2 service requests are those in which your production network is down or severely degraded. or for certain products. Cisco Technical Assistance Center (TAC) engineers provide telephone support. your service request is assigned to a Cisco TAC engineer.com/techsupport/contacts Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 xiii . If you do not hold a valid Cisco service contract.

or configuration. technologies. certification and training information. configuration examples. and expand services. You and Cisco will commit full-time resources during normal business hours to resolve the situation.” or there is a critical impact to your business operations. at this URL: http://www. You can access iQ Magazine at this URL: http://www. streamline their business. Cisco has established severity definitions. Access the Cisco Product Catalog at this URL: http://cisco. reference guides. customer case studies. or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products.cisco. Severity 4 (S4)—You require information or assistance with Cisco product capabilities.Preface Obtaining Additional Publications and Information Definitions of Service Request Severity To ensure that all service requests are reported in a standard format. The publication identifies the challenges facing these companies and the technologies to help solve them. Obtaining Additional Publications and Information Information about Cisco products. and network solutions is available from various online and printed sources. You can access Packet magazine at this URL: http://www. You and Cisco will commit all necessary resources around the clock to resolve the situation. as well as network deployment and troubleshooting tips. using real-world case studies and business strategies to help readers make sound technology investment decisions. Both new and experienced users will benefit from these publications.com/go/iqmagazine Cisco IP Contact Center Enterprise Edition SRND xiv OL-7279-04 . as well as ordering and customer support services. but most business operations remain functional. technology breakthroughs. and Cisco products and solutions. installation. the company store.cisco.com/packet • iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue. Packet delivers coverage of the latest industry trends.ciscopress. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels. Each quarter. For current Cisco Press titles and other information. go to Cisco Press at this URL: http://www.com/univercd/cc/td/doc/pcat/ • Cisco Press publishes a wide range of general networking. training and certification titles.com • Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Severity 1 (S1)—Your network is “down. and logo merchandise.cisco. Severity 3 (S3)—Operational performance of your network is impaired. Visit Cisco Marketplace. and links to scores of in-depth online resources.com/go/marketplace/ • The Cisco Product Catalog describes the networking products offered by Cisco Systems. Severity 2 (S2)—Operation of an existing network is severely degraded. • Cisco Marketplace provides a variety of Cisco books. There is little or no effect on your business operations.

com/ipj • World-class networking training is available from Cisco. You can view current offerings at this URL: http://www. developing.html Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 xv .cisco.com/en/US/learning/index. You can access the Internet Protocol Journal at this URL: http://www.Preface Obtaining Additional Publications and Information • Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing.cisco. and operating public and private internets and intranets.

Preface Obtaining Additional Publications and Information Cisco IP Contact Center Enterprise Edition SRND xvi OL-7279-04 .

cisco. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide. IPCC provides an integrated Automatic Call Distribution (ACD). provides the foundation for a Voice over IP (VoIP) solution. Multiple Cisco CallManager servers can be grouped into a cluster to provide for scalability and fault tolerance. and IP phones.com/go/srnd Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 1-1 . The following sections discuss each of the software products in more detail and describe the data communications between each of these components. voice gateways. when combined with the appropriate LAN/WAN infrastructure. available at http://www. The Cisco CallManager software running on a server is referred to as a Cisco CallManager server.com Cisco CallManager Cisco CallManager. IVR. the following Cisco hardware products are required for a complete IPCC deployment: • • • Cisco IP Phones Cisco voice gateways Cisco LAN/WAN infrastructure Once deployed. For more information on a particular product. refer to the specific product documentation available online at http://www. For details on Cisco CallManager call processing capabilities and clustering options.cisco.C H A P T E R 1 Architecture Overview The Cisco IP Contact Center (IPCC) solution consists of four primary Cisco software components: • • • • IP Communications infrastructure: Cisco CallManager Queuing and self-service: Cisco IP Interactive Voice Response (IP IVR) or Cisco Internet Service Node (ISN) Contact center routing and agent management: Cisco Intelligent Contact Management (ICM) Software Agent desktop software: Cisco Agent Desktop or Cisco Toolkit Desktop (CTI Object Server) In addition to these core components. Cisco CallManager is a software application that runs on Intel Pentium-based servers running Microsoft Windows Server operating system software and Microsoft SQL Server relational database management software. and Computer Telephony Integration (CTI) solution.

The Cisco ISN can support multiple grammars for prerecorded announcements. the Cisco ICM removes the call from ISN and routes it elsewhere over the PSTN. External VXML applications can return results and control to the ICM script when complete. Cisco Internet Service Node (ISN) The Cisco Internet Service Node (ISN) provides prompting. An additional PSTN port is also required on an egress gateway if the call is transferred to a PSTN-based destination. Typically when designing an IPCC solution. a Cisco CallManager cluster of servers is capable of supporting thousands of agents. and collect information. The ISN software is tightly integrated with the Cisco ICM software for application control.323 (call control). but it might not be available with all carriers. how many servers and what types of servers are required for the ICM software. fault tolerant. With the Cisco ISN system. The ISN architecture is distributed. but the ISN retains signaling control over the call so that it can bring the call back for additional treatment or transfer it to additional destinations. you first define the deployment scenario. In a fault-tolerant design. Telephone calls can remain queued on Cisco ISN until they are routed to a contact center agent (or external system). • IN Transfer Cisco ICM software temporarily routes PSTN-originated calls to ISN via a Cisco IOS Voice Gateway. With this transfer method. However. Advanced load balancing can be provided by Cisco Content Server Switches (CSS). and so forth. voice is terminated on Cisco IOS® gateways that interact with the ISN application server (Microsoft Windows Server) using VXML (speech) and H. and highly scalable. The Cisco ISN can also access customer databases and applications via the Cisco ICM software. When ISN treatment is finished. a PSTN port is used on the ingress gateway for the life of the call. queuing. the number of agents and the number of busy hour call attempts (BHCA) supported within a cluster varies and must be sized according to guidelines defined in the Cisco IP Telephony Solution Reference Network Design (SRND) guide. The ISN can optionally provide automatic speech recognition and text-to-speech capability. but it might not be available with all carriers. menu. Cisco IP Contact Center Enterprise Edition SRND 1-2 OL-7279-04 . This method eliminates consumption of ports on the gateway for the rest of the call. After defining the deployment scenario. collecting.Chapter 1 Cisco Internet Service Node (ISN) Architecture Overview A single Cisco CallManager server is capable of supporting hundreds of agents. The ICM scripting environment controls the execution of "building block" functions such as play media. you can determine the sizing of the individual components within the IPCC design for such things as how many Cisco CallManager servers are needed within a Cisco CallManager cluster. This method eliminates consumption of ports on the gateway for the rest of the call. The Cisco ISN also provides a queuing platform for the IPCC solution. including arrival point(s) for voice traffic and the location(s) of the contact center agents. how many voice gateways are needed for each site and for the entire enterprise. The Cisco ISN can transfer calls using any of the following methods: • IP Switching The ISN directs the ingress Cisco IOS voice gateway to redirect the call's packet voice path to a new IP-based destination. and call control services using standard web-based technologies. how many IP IVR/ISN servers are needed. • Outpulse Transfer The ISN sends DTMF digits to the PSTN via the ingress gateway to make the PSTN carrier disconnect the call from the gateway and route it elsewhere via the PSTN. play data. The ICM script can also invoke external VXML applications via ISN.

a minimum of two IP IVRs is required. For deployments requiring complete fault tolerance. The IP Queue Manager provides a subset of the IP IVR capability. provides details on server sizing. The database. The IP IVR has no physical telephony trunks or interfaces like a traditional IVR. Note Because the IP IVR and IP Queue Manager are so similar. and the IP IVR communicates with the ICM via the Service Control Interface (SCI). The chapter on Design Considerations for High Availability. page 5-1. collecting. The supported Pentium servers can be single. call routing and queue control. A lower-cost licensing option of the IP IVR is called the IP Queue Manager. or quad Pentium CPU servers with varying amounts of RAM. Cisco Intelligent Contact Management (ICM) Software The Cisco ICM software provides contact center features in conjunction with Cisco CallManager. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 1-3 . the ICM software instructs the IP IVR to transfer the call to the selected agent phone. Each IP IVR server is capable of supporting over 100 logical IP IVR ports. and HTTP subsystems are not included the IP Queue Manager software license. screen pops. and multiple IP IVR servers can be deployed in a single Cisco CallManager cluster. which provides both standard reports and a development environment for custom reporting via Cisco Consulting Engineering Services or a certified reseller. provides details on IPCC fault tolerance. ICM software runs on Intel Pentium servers running Microsoft Windows 2000 operating system software and Microsoft SQL Server database management software. The IP IVR then requests Cisco CallManager to transfer the call to the selected agent phone. and queuing capability for the IPCC solution. The IP IVR communicates with Cisco CallManager via the Java Telephony Application Programming Interface (JTAPI). Java. and contact center reporting. agent selection. The chapter on Sizing IPCC Components and Servers. page 3-1. the remainder of this document refers to the IP IVR only. Cisco IP Interactive Voice Response (IP IVR) The IP IVR provides prompting.Chapter 1 Architecture Overview Cisco IP Interactive Voice Response (IP IVR) Call reporting uses the IPCC reporting infrastructure. The IP Queue Manager provides an integrated mechanism for prompting and collecting input from callers and for playing queuing announcements. Cisco IP IVR is a software application that runs on Intel Pentium-based servers running Microsoft Windows Server operating system software and Microsoft SQL Server relational database management software. page 4-1 discusses how to determine the number of IVR ports required. The telephony trunks are terminated at the voice gateway. The sizing for IP Queue Manager and IP IVR are the same. The IP IVR is under the control of the ICM software via the Service Control Interface (SCI). Cisco CallManager provides the call processing and switching to set up a G.711 Real-Time Transport Protocol (RTP) stream from the voice gateway to the IP IVR. The chapter on Sizing Call Center Resources. This variety of supported servers allows the ICM software to scale and to be sized to meet the needs of the deployment requirements. Features provided by the ICM software include agent state management. dual. When an agent becomes available. IVR control.

No available agent found. and Cisco CallManager does as instructed. 7. all of the agents are assumed to be "not ready" when the call arrives. In this scenario. At the same time the call is being transferred. so IP IVR label returned from routing script. Call is answered by agent. IP IVR transfers the VoIP voice path to selected agent phone. Figure 1-1 Basic IPCC Call Flow IP IVRs 7 Public network 1 6 10 5 10 M M ICM 9 7 3 5 5 8 9 4 7 V 2 CallManager cluster 10 8 Agent available 9 Screen pop 11 Call answered IP phones and agent desktops IP IP IP IP voice TDM voice Call control and CTI data 76583 The call flow in Figure 1-1 is as follows: 1. 5. While the call is connected to the IP IVR. 8. Cisco IP Contact Center Enterprise Edition SRND 1-4 OL-7279-04 . 10. ICM instructs Cisco CallManager to transfer call to IP IVR. 9. 2.Chapter 1 Cisco Intelligent Contact Management (ICM) Software Architecture Overview Basic IPCC Call and Message Flow Figure 1-1 shows the flow of a basic IPCC call. 3. so the call is routed by the ICM to the IP IVR. When an agent becomes available. music. call queuing treatment (announcements. MGCP or H. the ICM directs the IP IVR to transfer the call to that agent's phone. ICM sends call data to selected agent screen and instructs the IP IVR to transfer the call to the agent phone. 11. and so on) is provided. Agent becomes ready (completed previous call or just went ready). ICM runs routing script. Call delivered from PSTN to voice gateway. JTAPI Route Request sent to ICM. IP IVR notifies ICM that call has arrived. ICM instructs IP IVR to play queue announcements.323 Route Request sent to Cisco CallManager. 4. 6. the ICM sends the caller data such as Automatic Number Identification (ANI) and Directory Number (DN) to the agent desktop software.

you need a Cisco CallManager PIM. and the IP IVR PIMs. For each IP IVR. or quad CPU). In this configuration. there appears to be only one Router. Often. the CTI OS Server. Another internal PG process is the Open Peripheral Controller (OPC). Other factors that impact the hardware sizing are the number of agents. whereas a non-redundant process is said to be running in "simplex" mode. When processes are running in a duplex configuration. you need one CTI Server and one CTI OS Server to communicate with the desktops associated with the phones for that Cisco CallManager cluster. The CTI OS Server is the module that interfaces to the IPCC Agent Desktop application. is referred to as a Peripheral Gateway (PG). the server is referred to as a Rogger. logically. The only software modules that do not support multiple instances are the Router and Logger. they are not load balanced. the number of VRU Script nodes in the ICM routing script. For each Cisco CallManager PIM. The Cisco CallManager PIM is the module that interfaces to a Cisco CallManager cluster via the JTAPI protocol. When a module is deployed in a redundant fashion. the number of IP IVR ports. For each Cisco CallManager cluster in your IPCC environment. Each ICM software module can be deployed in a redundant fashion. Internal to the PG is a process called the PG Agent. The A and B sides are both executing the same set of messages and. Router A and Router B are redundant instances of the Router module (process) running on two different servers. the CTI Server. the Cisco CallManager PIM. For example. which enables the other processes to communicate with each other and is also involved in synchronizing PGs in redundant PG deployments. we refer to the two sides as side A and side B. This enterprise view enables IPCC to provide a single logical ACD controlling contacts and agents that can be distributed among many sites. which communicates from the PG to the Central Controller. you need one IP IVR PIM. The Logger is the database module that stores contact center configuration and reporting data. and which statistics agents need at their desktops. Figure 1-2 shows the communications among the various PG software processes. The Central Controller is the hub of the hub-and-spoke architecture for IPCC. The core ICM software modules are: • • • • • • • Router Logger Cisco CallManager Peripheral Interface Manager (PIM) IP IVR PIM CTI Server CTI OS Server Administrative Workstation (AW) The Router is the module that makes all routing decisions on how to route a call or customer contact. Most of the ICM software modules support multiple logical instances for scalability. This redundant mode is referred to as a "duplex" configuration. producing the same result. The Router and Logger combined are often referred to as the Central Controller. the number of skills per agent. the CTI OS Server. The IP IVR PIM is the module that interfaces to the IP IVR/ISN via the Service Control Interface (SCI) protocol. dual. The amount of software that can run on one server is primarily based upon busy hour call attempts (BHCA) and the size of the server being used (single. By having only one central controller. the CTI Server.Chapter 1 Architecture Overview Cisco Intelligent Contact Management (ICM) Software ICM Software Modules The Cisco ICM software is a collection of modules that can run on multiple servers. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 1-5 . The server that runs the Cisco CallManager PIM. therefore. the IPCC system has only one "enterprise view" of all the agents and contacts in queue. When the Router and Logger modules run on the same server. and multiple IP IVR PIMs will run on the same server.

When multiple Cisco CallManager clusters are deployed. The agent desktop has a media-terminated "softphone" option that allows you to eliminate the need for a hardware IP Phone. make call. and Concepts This section describes the major components and concepts employed in an IPCC solution. and so forth) and call control (answer. the ICM software makes them all appear to be part of one logical enterprise-wide contact center with one enterprise-wide queue. multiple PGs are usually deployed. and so forth). Each Cisco CallManager cluster requires a co-located PG.Chapter 1 IPCC Components. release. ready. hold. Do not confuse the agent desktop softphone option with other softphone applications such as the Cisco IP SoftPhone. wrap up. multi-site (multi-cluster) environments. Cisco IP Contact Center Enterprise Edition SRND 1-6 132072 OL-7279-04 . (See Figure 1-3. not ready. transfer. which will encode/decode the VoIP packets and send/receive those packets to/from the LAN. a headset is connected to the PC. Terminology. retrieve. and Concepts Architecture Overview Figure 1-2 Communications Among Peripheral Gateway Software Processes ICM central controller PG server PG 1 IPCC Agent desktops IP phones PG Agent IP CTI OS server CTI server CCM PIM OPC JTAPI IP IVR 1 JTAPI SCI CallManager Cluster M M M IP IP IP IVR 1 PIM JTAPI IP IVR 2 PSTN V IP voice TDM Voice CTI/Call control data IVR 2 PIM SCI In larger. IPCC Components. Terminology. All call control must be done via the agent desktop application. IPCC Agent Desktop The IPCC agent desktop application is the agent interface that enables the agent to perform agent state control (login. conference. logout.) When using the agent desktop softphone option.

Some AWs communicate directly with the ICM Central Controller. and they are called distributor AWs. a supervisor desktop is available with each of these options. Each AW is independent of other AWs. at least one distributor and any number of client AWs can be deployed. add dialed numbers. At any additional site. Embedded CRM desktops such as the Cisco Siebel Desktop.com/univercd/cc/td/doc/product/icm/ipccente/index. client AWs should always be local to their AW distributor. page 7-1. and Concepts Figure 1-3 Cisco Agent Desktop There are three kinds of agent and supervisor desktop options available: • • Cisco Agent Desktop. and a number of other embedded CRM desktops are available from Cisco partners. Terminology. available at http://www. a customer database application). add call types. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 1-7 . The Cisco Siebel Desktop is offered by Cisco. Client AWs communicate with a distributor AW to view and modify the ICM Central Controller database and to receive real-time reporting data.htm The AW is the only software module that must run on a separate server from all of the other IPCC software modules. assign call types to ICM routing scripts. Cisco Toolkit Desktop. The two primary configuration tools on the AW are the Configuration Manager and the Script Editor. and redundancy is provided by deploying multiple AWs.Chapter 1 Architecture Overview IPCC Components. however. Administrative Workstation The Administrative Workstation (AW) provides a collection of administrative tools for managing the ICM software configuration. • In addition to an agent desktop. assign dialed numbers to call types. the script identifies which agent should handle a particular contact).cisco. assign agents to skill groups. The Cisco Toolkit Desktop is implemented for custom desktops or desktops integrated with other applications (for example. refer to the IP Contact Center Administration Guide. add skill groups. and so forth. The chapter on Agent Desktop and Supervisor Desktop. an out-of-the-box agent desktop (shown in Figure 1-3). which is a software development toolkit built on the CTI Object Server (CTI OS). ICM routing scripts specify how to route and queue a contact (that is. For details on the use of these tools. covers details on desktop selection and design considerations. The Cisco Siebel Desktop is an IPCC agent desktop that is fully embedded within the Siebel desktop application. Additional AWs (distributors or clients) are also allowed for redundancy (primary and secondary distributors) or for additional access by the AW clients in a site. An ICM installation supports an unlimited number of AWs and can be deployed co-located with or remote from the ICM Central Controller. Distributor AWs relieve the Central Controller (the real-time call processing engine) from the task of constantly distributing real-time contact center data to the client AWs. An ICM deployment must have at least one distributor AW. The Configuration Manager tool is used to configure the ICM database to add agents. The Script Editor tool is used to build ICM routing scripts.

but the IP IVR Cisco IP Contact Center Enterprise Edition SRND 1-8 OL-7279-04 . Terminology. which will send a route request to the ICM to determine how the call should be routed. suppose a deployment has a voice gateway homed to node 1 in a cluster. A single JTAPI user ID is used for all communications between the entire Cisco CallManager cluster and the ICM. JTAPI Communications In order for JTAPI communications to occur between Cisco CallManager and external applications such as the IPCC and IP IVR. However. and Concepts Architecture Overview AWs can be installed with two software options: • • Historical Data Server (HDS) WebView Server The Historical Data Server (HDS) option provides a replicated copy of the historical reporting data. For lab or prototype systems. The reason for requiring the AW to run on a separate server for production systems is to ensure that complex reporting queries do not interrupt the real-time call processing of the Router and Logger processes. and node 2 executes the CTI Manager process that communicates to the ICM. Each IP IVR also communicates with only one CTI Manager (or node) within the cluster. This option enables reporting to be done from any computer with a browser. When the Cisco CallManager PIM is redundant. three JTAPI user IDs are required: one JTAPI user ID for the ICM application and two JTAPI user IDs for the two IP IVRs. only one side is active and in communication with the Cisco CallManager cluster. Upon startup of the Cisco CallManager PIM or upon startup of the IP IVR. node 1 sends an intra-cluster message to node 2. For more details on the design and configuration of the AWs. then HDS is no longer required because a complete copy of the Logger database is already present on the server. The Cisco CallManager PIM and the two IP IVRs from the previous example could each communicate with different CTI Managers (nodes) or they could all communicate with the same CTI Manager (node). In an IPCC deployment with one Cisco CallManager cluster and two IP IVRs. which is the layer of software that communicates via JTAPI to applications such as the ICM and IP IVR. Side A of the Cisco CallManager PIM communicates with the CTI Manager on one Cisco CallManager node. the JTAPI user ID and password are used to log in to Cisco CallManager. If the AW is installed on the same server as the Logger. and side B of the Cisco CallManager PIM communicates with the CTI Manager on another Cisco CallManager node. The HDS must be installed with a distributor AW. The WebView Server option provides browser-based reporting. a JTAPI user ID and password must be configured within Cisco CallManager.Chapter 1 IPCC Components. The Cisco CallManager software includes a module called the CTI Manager. The WebView Server must be installed on a distributor AW with HDS. Every node within a cluster can execute an instance of the CTI Manager process. When a new call arrives at this voice gateway and needs to be routed by the ICM. A separate JTAPI user ID is also required for each IP IVR server. the AW (with the WebView Server option) can be installed on the same server as the Router and Logger. each communication uses a different user ID. This login process by the application (Cisco CallManager PIM or IP IVR) establishes the JTAPI communications between the Cisco CallManager cluster and the application. For example. The CTI Manager process communicates CTI messages to/from other nodes within the cluster. The IP IVR does not have a redundant side. but the Cisco CallManager PIM on the PG communicates with only one CTI Manager (and thus one node) in the Cisco CallManager cluster.com. The net effect of adding the WebView Server is to turn the distributor AW into a web server. refer to the ICM product documentation available online at Cisco. The user ID is how the CTI Manager keeps track of the different applications.

the IP phones are associated with the ICM JTAPI user ID. For example. they also must be associated in Cisco CallManager with a JTAPI user ID. In order for the routing control communication to occur. Cisco CallManager does not allow the ICM to monitor or control that IP phone. When the agent clicks the answer button. Unlike the ICM. when a call needs to be made to a DN that is associated with a CTI Route Point that is associated with an IP IVR JTAPI user. Because the IP IVR also communicates with Cisco CallManager using the same JTAPI protocol. there needs to be a CTI Port device defined in Cisco CallManager. Terminology. Cisco CallManager does not select the IP IVR port to which it will send the call. In order for the IP phones (devices) to be monitored and controlled. Directory (Dialed) Numbers (DNs) are then associated with the CTI Route Point. In an IPCC environment. The IP IVR does not have real physical ports like a traditional IVR. At that point. the Cisco CallManager PIM requests Cisco CallManager to allow the PIM to begin monitoring and controlling that device (IP phone). Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 1-9 . Cisco CallManager attempts delivery of the call to the agent phone by instructing the phone to begin ringing. when Cisco CallManager receives the routing response from the ICM.Chapter 1 Architecture Overview IPCC Components. A DN is associated to a CTI Route Point that is associated with the ICM JTAPI user ID. the IP IVR provides both the application itself and the devices to be monitored and controlled. the IP IVR will respond to the Cisco CallManager routing control request with the Cisco CallManager device identifier of the CTI Port that is going to handle that call. A typical IPCC call includes all three types of JTAPI communication within a few seconds. Cisco CallManager notifies the ICM that the device (IP phone) has started ringing. Until the login has occurred. For more information on failover. • Device and call control Device control messages provide a way for Cisco CallManager to receive instructions from IPCC on how to control a device (IP phone) or a call. refer to the chapter on Design Considerations for High Availability. and Concepts does have the ability to fail over to another CTI Manager (node) within the cluster if its primary CTI Manager is out of service. page 3-1. • Device and call monitoring Device monitoring messages provide a way for Cisco CallManager to notify IPCC about state changes of a device (IP phone) or a call. Cisco CallManager requires the configuration of a CTI Route Point. and this association enables Cisco CallManager to know which application provides routing control for that CTI Route Point. Unlike a traditional PBX or telephony switch. The devices that the ICM monitors and controls are the physical IP phones. If the device has not been associated with the ICM JTAPI user ID. A CTI Route Point is associated with a specific JTAPI user ID. and that notification enables the agent’s answer button on the desktop application. these same three types of communication also occur with the IP IVR. The JTAPI communications between the Cisco CallManager and IPCC include three distinct types of messaging: • Routing control Routing control messages provide a way for Cisco CallManager to request routing instructions from IPCC. then the agent login request will fail. When a new call arrives. When an agent logs in from the desktop. Cisco CallManager requests routing instructions from the ICM. and this enables Cisco CallManager to generate a route request to the ICM when a new call to that DN arrives. the ICM instructs Cisco CallManager to make the device (IP phone) go off-hook and answer the call. Cisco CallManager asks the IP IVR (via JTAPI routing control) which CTI Port (device) should handle the call. For each CTI Port on the IP IVR. Assuming the IP IVR has an available CTI Port. Its ports are logical ports (independent software tasks or threads running on the IP IVR application server) called CTI Ports. Instead.

no monitoring or control of those additional extensions is possible. but those extensions will not be known to the ICM software and. which then notifies the IP IVR via JTAPI. These scenarios are examples of device and call monitoring performed by the IP IVR. When the IP IVR workflow wants the call transferred or released. it again instructs the Cisco CallManager what it would like done with that call.cisco.com/univercd/cc/td/doc/product/icm/ Other applications such as the Cisco Media Blender. These scenarios are examples of device and call control performed by the IP IVR. this routing practice also allows the ICM to load-balance calls across the multiple IP IVRs. an IP IVR workflow is started within the IP IVR. When a caller releases the call while interacting with the IP IVR. Additional extensions may be configured on the IP phone. Only one extension on the IP phone may be configured as an ICM device target. Routing clients generate route requests to the ICM Central Controller. and the Cisco E-Mail Manager can also function as routing clients to allow the ICM to become a multi-channel contact routing engine. a JTAPI message is sent to Cisco CallManager to answer the call on behalf of that CTI Port (device). which then notifies the IP IVR via JTAPI. A detailed list of PSTN NICs and details on ICM pre-routing can be found in the standard ICM product documentation available at http://www. three routing clients are required: the Cisco CallManager PIM and the two IP IVR/ISN PIMs. it notifies Cisco CallManager via H. ICM Routing Clients An ICM routing client is anything that can generate a route request to the ICM Central Controller. Only certain PSTNs have NICs supported by the ICM. Device Targets Each IP phone must be configured in the ICM Central Controller database as a device target. Terminology. and only one side of a PIM is active at any point in time. thus. Doing so will ensure proper IPCC reporting. The ICM supports a software module called a Network Interface Controller (NIC). therefore it is not necessary to configure call forwarding on Cisco IP Contact Center Enterprise Edition SRND 1-10 OL-7279-04 . The public switched telephone network (PSTN) can also function as a routing client. the Cisco Collaboration Server. the voice gateway detects the caller release and notifies Cisco CallManager via H. The Cisco CallManager PIM (representing the entire Cisco CallManager cluster) and each IP IVR/ISN PIM are routing clients.323 or Media Gateway Control Protocol (MGCP). you would have 300 CTI ports. In an IPCC deployment with one Cisco CallManager cluster (with any number of nodes) and two IP IVRs. If you have two 150-port IP IVRs. For deployments with multiple IP IVRs. While Cisco CallManager can be configured to route calls to IP IVRs on its own.Chapter 1 IPCC Components. routing of calls to the IP IVRs in an IPCC environment should be done by the ICM (even if you have only one IP IVR and all calls require an initial IVR treatment). Details of currently available multi-channel routing are available on Cisco. The ICM Central Controller then executes a routing script and returns a routing label to the routing client. Half of the CTI ports (150) would be associated with JTAPI user IP IVR #1. the CTI Port devices on Cisco CallManager must be associated with the appropriate IP IVR JTAPI user ID. In order for the CTI Port device control and monitoring to occur.245 or MGCP. A redundant PIM is viewed as a single logical routing client. and Concepts Architecture Overview When an available CTI Port is allocated to the call. The ICM provides call treatment for Reroute On No Answer (RONA). and the other 150 CTI ports would be associated with JTAPI user IP IVR #2. which enables the ICM to control how the PSTN routes a call. Intelligently routing a call before the call is delivered to any customer premise equipment is referred to as pre-routing. When DTMF tones are detected by the voice gateway. When the IP IVR workflow executes the accept step.com.

suppose we have an environment with two regionally separated Cisco CallManager clusters. Agent Desk Settings Agent Desk Settings provide a profile that specifies parameters such as whether auto-answer is enabled. Changes made to an agent’s desk setting profile while the agent is logged in are not activated until the agent logs out and logs in again.Chapter 1 Architecture Overview IPCC Components. then we would need 1200 labels for the six routing clients and 200 device targets (assuming we wanted to be able to route a call from any routing client to any device target). A bulk configuration tool is also available to simplify the configuration of the labels. Each combination of device target and routing client must have a label. At agent login. each IP phone must be mapped to the ICM JTAPI user ID in order for the agent login to be successful. users might have to dial a 10. Unless call center policy permits warm (agent-to-agent) transfers. what DN to use in the rerouting. The label is a pointer to the destination where the call is to be routed (basically. and only the ICM software should route calls to this IPCC phone extension. and whether reason codes are needed for logging out and going not-ready. and then doubled for Site 2).digit number. For example.com. Labels Labels are the response to a route request from a routing client. As mentioned previously. Site 1 and Site 2. To reach an IP phone user at either site from a PSTN phone. the number to be dialed by the routing client). and Concepts ring-no-answer in the Cisco CallManager configuration for the IP phones. a device target in an IPCC deployment with a two-node Cisco CallManager cluster and two IP IVRs will require three labels. This feature allows the agent to log in at another phone and allows another agent to log in at that same phone. and this association is released when the agent logs out. This is why IPCC uses labels. Details on configuring labels are provided in the IPCC Installation Guide. how long to wait before rerouting a call for Ring No Answer. then we would need only 600 labels (three routing clients to 100 device targets. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 1-11 . Many labels in an IPCC environment correspond to the IPCC phone extensions so that Cisco CallManager and IP IVR can route or transfer calls to the phone of an agent who has just been selected for a call. the Cisco CallManager PIM requests Cisco CallManager to allow it to begin monitoring that IP phone and to provide device and call control for that IP phone. From this example. depending upon where the call is originating and terminating. A single agent desk setting profile can be shared by many agents. you would need 300 labels. users might have to dial a seven-digit number. we can see how a different label would be needed. Often. Terminology. If you have 100 device targets (IP phones). the way a call is routed to a destination depends upon where the call originated and where it is being terminated. At agent login. each with two IP IVRs and 100 device targets per site. If there are two regionally separated Cisco CallManager clusters. Labels are also used to route calls to IP IVR CTI Ports. In order to reach an IP phone user at Site 2 from Site 1. the IPCC extension also should not be published or dialed by anyone directly. available on Cisco. If calls are to be routed to device targets only at the same site as the routing client. For example. An IP phone user at Site 1 will typically just dial a four-digit extension to reach another IP phone user at Site 1. Each agent must be associated with an agent desk setting profile in the ICM configuration. the agent ID and IP phone extension are associated.

The ICM router then determines the label to be returned. Agent Login and State Control Agents log in to IPCC from their IPCC agent desktop application. that DN is mapped to an ICM Call type. Creating and using Enterprise Skill Groups can simplify routing and reporting in some scenarios. Skill Groups Skill groups are configured within the ICM so that agents with similar skills can be grouped together. the agent is presented with a dialog box that prompts for agent ID. When logging in. Once the ICM receives the route request with the DN. one Cisco CallManager cluster). Skill groups are associated with a specific Cisco CallManager PIM. and the IPCC phone extension to be used for this login session. agent desk setting profile. Directory (Dialed) Numbers and Routing Scripts In order for Cisco CallManager to generate a route request to the ICM. the ICM maps the DN to a call type and then maps the call type to this routing script. password. Cisco CallManager must associate the DN with a CTI Route Point that is associated with the ICM JTAPI User. It is at login time that the agent ID. Skill groups from multiple PIMs can be grouped into Enterprise Skill Groups. Agent 111 is currently logged in from device target 1234 (Cisco CallManager phone extension 1234 in this scenario). the ICM router first uses a Select node to look for the Longest Available Agent (LAA) in the BoatSales skill group on the CCM_PG_1 peripheral (or cluster). The association is released upon agent logout.Chapter 1 IPCC Routing Architecture Overview Agents Agents are configured within the ICM and are associated with one specific Cisco CallManager PIM (that is. phone extension (device target). Within the ICM configuration. Cisco IP Contact Center Enterprise Edition SRND 1-12 OL-7279-04 . based upon the device target and routing client combination. you also configure the password for the agent to use at login. and desktop IP address are all dynamically associated. The appropriate label is then returned to the routing client (Cisco CallManager cluster) so that the call can be routed properly to that IP Phone (device target). The ICM router determines that agent 111 is the LAA. In this routing script. The DN must also be configured in the ICM. which is then mapped to an ICM routing script. skills. the Cisco CallManager PIM (or cluster) is the routing client. Upon receipt of the route request. IPCC Routing The example routing script in Figure 1-4 illustrates how IPCC routes calls. Agents can be associated with one or more skill groups. In this routing script. Changes made to an agent’s skill group association while the agent is logged in are not activated until the agent logs out and logs in again.

and as in the previous example. The re-entry point is the successful exit path of the Translation Route to VRU node. then the router exits the Select node and transfers the call to an IP IVR to begin queuing treatment. The ICM then re-enters the routing script that was previously being run for this call. When the call is successfully transferred to the IP IVR. (See Figure 1-5. the routing script was temporarily paused. the IP IVR translation routing application first sends a request instruction message to the ICM via the SCI between the IP IVR and the ICM. While the call was being transferred.Chapter 1 Architecture Overview IPCC Routing Figure 1-4 Routing Script Example Route request (DN. In Cisco CallManager. the label to be returned to the routing client is identified based upon the combination Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 1-13 .) At this point. The translation route label will equal a DN configured in Cisco CallManager. ANI. the IP IVR becomes the routing client for this routing script. Eventually agent 111 becomes available. the routing client has changed from the Cisco CallManager cluster to IPIVR1. The Translation Route to VRU node returns a unique translation route label to the original routing client. After the transfer to the IP IVR is successfully completed. that DN is mapped to a CTI Route Point that is associated with the JTAPI user for the IP IVR to which the call is being transferred. The transfer is completed using the Translation Route to VRU node. Cisco CallManager and IP IVR will execute the JTAPI routing control messaging to select an available CTI Port. CED) CallManager Cluster Agent ID 111 Dev Target 1234 Dev Target 1234 1234 1234 Rtg Client CM Cluster IPIVR 1 IPIVR 2 Label 1234 1234 1234 Route response returned to CallManager Cluster 76581 Translation Routing and Queuing If no agents are available. The ICM identifies the DN as being the same as the translation route label and is then able to re-associate this call with the call that was previously being routed. Next the routing script queues the call to the BoatSales skill group and then instructs the IP IVR to run a specific queue treatment via the Run VRU Script node. the Cisco CallManager cluster.

The routing script for this RONA treatment should set the call priority to “high” so that the next available agent is selected for this caller. The label returned (1234) when agent 111 becomes available causes the IP IVR to transfer the call to agent 111 (at extension 1234). a translation route and a set of labels is required. Again. all call data is preserved. the ICM routing script should select the IP IVR with the greatest number of idle IP IVR ports and then translation-route the call to that specific IP IVR. Figure 1-5 Translation Routing and Queuing Original route request Original routing client CallManager Cluster New routing client IPIVR 1 Agent ID 111 Dev Target 1234 Dev Target 1234 1234 1234 Rtg Client CM Cluster IPIVR 1 IPIVR 2 Label 1234 1234 1234 Route response returned to IPIVR 1 76582 For each combination of Cisco CallManager cluster and IP IVR. Note that the routing client is now the IP IVR. For example.Chapter 1 IPCC Routing Architecture Overview of device target and routing client. If no IP IVR ports are available. Reroute On No Answer (RONA) When a call is routed to an agent but the agent fails to answer the call within a configurable amount of time. then four translation routes and sets of labels are required. if a deployment has one Cisco CallManager cluster and four IP IVRs. then the script should execute a Busy node. Any call data is preserved and popped onto the next agent's desktop. then it is important to resize your IP IVR port capacity. If no agent is available. If a high number of calls are executing Busy nodes. In the agent desk settings. the Cisco CallManager PIM for the agent who did not answer will change that agent’s state to "not ready" (so that the agent does not get more calls) and launch a route request to find another agent. For deployments with multiple IP IVRs. Cisco IP Contact Center Enterprise Edition SRND 1-14 OL-7279-04 . you can set the RONA timer and the DN used to specify a unique call type and routing script for RONA treatment. the call can be sent back to the IP IVR for queuing treatment again.

The Run VRU Script node in an ICM routing script is the component that causes the ICM to instruct the IVR to play a particular queuing treatment. it is important to realize that sometimes the most recent Cisco CallManager software release will not immediately be supported in IPCC deployments until testing is completed later. called Internet Service Node (ISN). so that agents are not interrupted by IP Telephony calls while they are working on IPCC calls. It is important to consider the environment where IPCC is being deployed to determine whether a separate Cisco CallManager cluster is advantageous. In an IPCC environment. it might sometimes be advantageous to separate Cisco CallManager clusters for IP Telephony extensions from the Cisco CallManager clusters for IPCC extensions. Cisco recommends that any IP Telephony extensions be forwarded to voice mail prior to logging into the IPCC. Queuing in an IPCC Environment Call queuing can occur in three distinct scenarios in a contact center: • • • New call waiting for handling by initial agent Transferred call waiting for handling by a second (or subsequent) agent Rerouted call due to ring-no-answer. However. it is important to note that there is no control over. the IPCC extension is not selected by default. Cisco recommends that you use the bottom-most extension on the IP phone as the IPCC extension so that. The chapter on Deployment Models provides considerations for deployments with ISN. In an IPCC environment. page 2-1. Cisco recommends that the agents change to a "not ready" state so that IPCC calls are not routed to them while they are on the phone. no voice mail. Because of these software and environmental limitations. also provides considerations for deployments with traditional IVRs. an IVR is used to provide voice announcements and queuing treatment while waiting for an agent. those IP Telephony extensions from the IPCC Agent Desktop. or visibility of. Combining IP Telephony and IPCC Extensions on the Same IP Phone It is possible to have multiple extensions on an IP phone. Call queuing in an IPCC deployment requires use of an IVR platform that supports the SCI interface to the ICM. and the chapter on Deployment Models. It is also important to note that many contact center environments have very stringent maintenance windows. When running dual-use Cisco CallManager clusters with both IP Telephony and IPCC extensions. The Cisco IP IVR is one such platform. Cisco also offers another IVR platform. Also. The control over the type of queuing treatment for a call is provided by the ICM via the SCI interface. and no call forwarding. it is important to consider how queuing and requeuing are going to be handled. waiting for handling by an initial or subsequent agent When planning your IPCC deployment. at least one of those extensions must be dedicated to IPCC and be configured with only a single line appearance.Chapter 1 Architecture Overview Combining IP Telephony and IPCC in the Same Cisco CallManager Cluster Combining IP Telephony and IPCC in the Same Cisco CallManager Cluster It is possible for a Cisco CallManager cluster to support IP phones with both normal IP Telephony (office) extensions and IPCC (call center) extensions. prior to making any outbound calls on the IP Telephony extension. when the user lifts the handset. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 1-15 . Other extensions on the IP phone may have multiple lines or appearances and voice mail. Traditional IVRs can also be used in IPCC deployments. that can be used as a queuing point for IPCC deployments.

An alphanumeric dialed number string (such as "sales" or "service") is also valid.Chapter 1 Transfers in an IPCC Environment Architecture Overview While the IVR is playing the queuing treatment (announcements) to the caller. Entries in the DNP are entered per peripheral (PIM).com/univercd/cc/td/doc/product/icm/ipccente/index. release. transfer. The ICM Dialed Number Plan (DNP) is currently administered via the Bulk Configuration tool on the ICM Administrative Workstation (AW). For administration details on editing dialed numbers. This is how a specific dialed number is mapped to a routing script in the ICM router.) The transferring agent then clicks OK to complete (single-step) or initiate (consultative) the transfer. A dialog box allows the transferring agent to enter the dialed number of a skill group or agent. When an agent with the appropriate skill becomes available. When a transferring agent wants to transfer a call to another skill group or agent. The transfer request message flows from the transferring agent desktop to the CTI Server and then to the Cisco CallManager PIM. The target agent is the agent receiving the transfer from the transferring agent.cisco. Updates and additions to the DNP are also sent to the PIM dynamically. conference. In order for the ICM to route the transfer and have all call data move with the transfer and be saved for cradle-to-grave reporting. and they take effect immediately and are used for the next call being transferred. Any call data that was delivered to the transferring agent or added by the transferring agent is sent along with the transfer request to the Cisco CallManager PIM. and the transfer scenarios themselves are discussed in the chapter on Deployment Models. call types. (Single-step transfer is the default. This section explains basic transfer concepts. and all DNP entries for a particular PIM are downloaded to the PIM upon PIM startup. Note Cisco recommends that all call control (answer. Transfers in an IPCC Environment Transfers are a commonly used feature in contact centers. available at http://www. fuzzy (wildcard) matching of dialed number strings is allowed. the transferring agent. and call types are mapped to ICM routing scripts. The original caller is the caller that made the original call that was routed to the transferring agent. The transferring agent is the agent requesting the transfer to the target agent. the ICM waits for an available agent of a particular skill (as defined within the routing script for that call). and routing scripts. The DNP is not the same as the Dialed Number table used by the ICM router and managed via the AW Configuration Manager tool. and so on) be done from the agent desktop application. a match for the dialed number must be found in the DNP for the PIM where the agent is currently logged in. refer to the IP Contact Center Administration Guide. The ICM router maps dialed numbers to call types. the ICM reserves that agent and then instructs the IVR to transfer the voice path to that agent's phone. the transferring agent clicks on the transfer button on the IPCC Agent Desktop. therefore it is very important to consider all of the possible transfer scenarios desired for your IPCC installation.htm Cisco IP Contact Center Enterprise Edition SRND 1-16 OL-7279-04 . Within the DNP. page 2-1. Dialed Number Plan The Cisco CallManager PIM then attempts to match the dialed number with an entry in the Dialed Number Plan. Transfers involve three parties: the original caller. The transferring agent also selects whether this transfer is to be a single-step (blind) transfer or a consultative transfer. This terminology is used throughout this document when referring to the different parties. and the target agent.

When this field is set to Yes. Upon receipt of the route request. The desktop then sends the transfer request to the Cisco CallManager PIM. ready. Dial Plan Type Entries in the Dialed Number Plan must be configured with a dial plan type. Because the Cisco CallManager calling search spaces override any desk settings. it is best to allow all dial plan types in the agent desk settings. the Cisco CallManager PIM generates the route request to get a routing label and then instructs the Cisco CallManager to perform a single-step transfer (without any further action from the transferring agent). the dialed number to be used for the route request must be supplied in the Dialed Number column of the Dialed Number Plan Editor.Chapter 1 Architecture Overview Transfers in an IPCC Environment For help with designing a dial plan for your IPCC deployment. The transferring agent will see the call disappear from their desktop and they will transition to the next agent state (wrap-up. the original caller is temporarily Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 1-17 . the transferring agent enters a DN and clicks the Initiate Transfer button. Assuming a match is found in the DNP. Within the routing script. the DNP type is allowed for the transferring agent. the DNP type for that call must be allowed in the agent desk setting profile used by the transferring agent. Route Request Assuming a match is found in the DNP for the transfer. In order for a call or transfer to proceed any further. Cisco recommends that the post-route option be set to Yes for transfers. For dialed numbers to be used in transfer scenarios. page 1-18 Single-Step (Blind) Transfer A blind transfer is used when the transferring agent does not need to speak with the target agent. Post Route Entries in the Dialed Number Plan must also be configured to indicate whether a post-route is required. Note Changes to the agent desk settings profile do not take effect until the agent logs out and logs in again. After specifying a blind transfer in the transfer dialog box on the agent desktop. and post-route is selected. depending on the agent desk settings for the transferring agent. depending upon the type of transfer being performed. and the post-route option is set to Yes. At this point there are numerous scenarios that can occur. The ICM router will determine which device target (phone extension and desktop) the agent is logged into and will then return the label that points to that device target to the Cisco CallManager PIM. any of the call data collected so far could be used in the intelligent routing of the call. as described in the following sections: • • Single-Step (Blind) Transfer. While the call is being placed to the target agent. the ICM router matches the dialed number to a call type and executes the appropriate routing script to find an appropriate target agent for the call. There are six predefined (via a list box) DNP types that correspond to the types specified in the agent desk settings profile. or not ready). the PIM logic will then generate a route request to the ICM central controller using the dialed number specified in this same DNP entry. page 1-17 Consultative Transfer. the DNP type is valid. consult your Cisco Systems Engineer (SE).

Chapter 1 Transfers in an IPCC Environment Architecture Overview placed on hold. the ICM will instruct the IVR to transfer the call. the Cisco CallManager PIM tells Cisco CallManager to initiate a consultative transfer to the number specified in the label. If the target agent does not answer. the call is just connected between the original caller and the target agent. but no such agent is currently available. Upon answering the call. The Device Ringing message causes the Cisco CallManager PIM to pop the target agent's desktop with call data and to enable their Answer button (assuming auto-answer is not enabled). call data not following the call. then the caller will be transferred anyway. The transferring agent can hear the target agent's phone ringing (assuming auto-answer is not enabled for the target agent). then the ICM routing script should be configured to route the call to an IVR for queuing. the transferring agent can click on the Transfer Complete button at any time after it is enabled. At any time after this. When the target agent clicks the Answer button (or auto-answer is invoked). When the target agent's phone begins ringing. The target agent receives a screen pop with all call data. Transfers not using the dialed number plan are not recommended because of agent roaming restrictions. Consultative Transfer Some parts of the message flow for a consultative transfer are similar to the message flow for a blind transfer. but no such agent is currently available. the original caller and the target agent do not hear any ringing. the transferring agent would hear the IP IVR queue announcements. the target agent is speaking with the original caller and the transfer is then complete. If the agent has transferred the call to a number that is not within the ICM Dialed Number Plan. When the target agent becomes ready. and the Answer button on their agent desktop is enabled when the phone begins ringing. The call would still be released from the transferring agent desktop almost immediately. The transferring agent could press the Transfer Complete button at any time to complete Cisco IP Contact Center Enterprise Edition SRND 1-18 OL-7279-04 . a voice path between the transferring agent and target agent is established (assuming the transferring agent has not clicked the Transfer Complete button). Cisco CallManager places the original caller on hold and makes a consultative call to the number specified in the label. The caller generally hears tone on hold while the transfer is being completed. Generally the transferring agent will not click the Transfer Complete button before the target agent answers because the probable reason they used consultative transfer was that they wanted to talk with the target agent before completing the transfer. If auto-answer is enabled. then the ICM routing script should be configured to translation-route the call to an IP IVR for queuing treatment. The caller will not hear any ringback tones because the IP IVR CTI Port will answer immediately. The consult call confirmation message causes the Cisco CallManager PIM to notify the transferring agents desktop that the call is proceeding. When the target agent phone begins ringing. Cisco CallManager generates a Consult Call Confirmation message and a Device Ringing message. However. Any call data collected by the transferring agent would automatically be passed to the IVR. The destination for the transferred call depends upon the number that was dialed and what is configured in the Cisco CallManager dial plan. and the ICM will pop the agent desktop with all call data. the original caller hears the ringing (assuming auto-answer is not enabled). If the agent is transferring the call to a generic DN to find an available agent with a particular skill. and it enables the Transfer Complete button. and reporting limitations. When the Cisco CallManager PIM receives the label from the ICM router indicating where to transfer the call. then RONA (reroute on no answer) call rerouting logic will take over. If the agent is transferring the call to a generic (skill-group) DN to find an available agent with a particular skill. In this scenario. the agent can click the Transfer Complete button to complete the transfer (before or after the target answers their phone).

Consultative transfers and reconnects are all done from the agent desktop and use the single Cisco CallManager extension that is associated with the IPCC. The Transfer (Complete) and Reconnect controls will be disabled. Non-ICM Transfers Transfers to numbers not in the DNP or to numbers configured in the DNP with post-route set to No are allowed but do not result in an ICM-routed call. that it be marked for post-route. The Alternate control will alternate the transferring agent back to talking with the consulted party. and there is no limit to the number of consultation calls an agent can make. An agent can alternate a call as many times as they would like. the transferring agent can later request another transfer. Upon availability of an appropriately skilled agent. and Reconnect call controls will be enabled. The Alternate control will alternate the transferring agent back to talking with the original caller. the transferring agent will hear the failed consultation call and will be able to reconnect with the original caller. The caller would then begin hearing the IP IVR queuing announcements. the transferring agent’s desktop functionality will be exactly the same as before they requested the transfer. page 1-19. The agent can then alternate again to place the original caller back on hold and retrieve the consultation call leg. When the transferring agent has alternated back to the original caller.Chapter 1 Architecture Overview Transfers in an IPCC Environment the transfer. but it is not supported in an IPCC environment. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 1-19 . The Transfer control will complete the transfer. the only call controls (buttons) that are enabled are Release and Alternate. If the agent is transferring the call to a number that is not in the ICM Dialed Number Plan and a number that is not valid on the Cisco CallManager. Call data is lost if the ICM does not route the call. the agent simply clicks the Reconnect button. any call data will be lost because the ICM did not route the call. To do so. This is basically the process an agent should use when they want to make a consultation call but do not plan to complete the transfer. Alternate Alternate is the ability for the agent to place the consultation call leg on hold and then retrieve the original call leg while in the midst of a consultative transfer. the Release. In these scenarios. the transferring agent can reconnect with the caller and release the consult call leg. Reconnect During the consultation leg of a consultative transfer. When the agent has alternated back to the consultation leg. Alternate. and the Reconnect button will drop the consulted party and reconnect the agent with the original caller. The IPCC system does not support allowing the transferring agent to place the original caller on hold and then use a second extension on their hardware phone to make a consultation call. After a call is successfully reconnected. and that it have a DNP type that is allowed for the transferring agent (based on their agent desk settings). This action causes the agent desktop to instruct the Cisco CallManager PIM to instruct Cisco CallManager to release the consultation call leg and to reconnect the agent with the original caller. the PIM simply sends a call transfer request directly to Cisco CallManager and uses the dialed number from the transfer dialog on the agent desktop. Cisco recommends that any dialed number for a transfer should have a match in the DNP. the IP IVR transfers the call to this target agent and pops any call data onto their screen. Transfer. as explained in the section on Reconnect. The hardware phone offers a button to allow this kind of transfer. Therefore. If an agent transfers a call in this way.

then the agent requesting the transfer must enter the agent ID into the transfer dialog box. All call detail records are associated with one another via a common call ID assigned by the ICM. before the transfer is completed. Transferring from an IVR to a Specific Agent Many contact centers often wish to prompt the caller for information such as an order number and then route the call to the agent who is working on that order. The two call records are associated with one another via a common call ID assigned by the ICM. when the transferring agent presses the Transfer Complete button. Each call leg generates a call detail record in the ICM. If your environment has multiple PIMs. This allows complete cradle-to-grave reporting for the call. is considered as talk time for the transferring agent. the consulted target agent may transfer the consultation call to another target agent. Transfer Reporting After a call transfer is completed. and then using the agent-to-agent script editor node to route the call to that particular agent. all PIM 2 agent IDs begin with a 2. you could set up a generic wildcard string that matches all agent IDs so that you need only one entry in the DNP for agent-to-agent routing. and the talk time during that call leg is associated with the agent who received that call. For more details. Cisco IP Contact Center Enterprise Edition SRND 1-20 OL-7279-04 . it can be transferred again. and so on). If multiple PIMs exist. placing the agent ID in any of the peripheral variable fields. The agent-to-agent node requires the PIM to be specified. Combination or Multiple Transfers During a consultative transfer.com. use the agent-to-agent routing node and specify the CED field as the location of the agent ID so that the ICM router will route this call properly. This causes the PIM to place the dialed number (agent ID) into the CED field before it sends the route request to the ICM router. This can be done on IPCC by having the router do a database lookup. The parsing may be done via a series of "if" nodes in the script editor or via a "route select" node. This type of scenario could also be used to prompt a caller for a specific agent ID and then route the caller to that agent ID. then you must use an agent ID number plan to determine which PIM contains this agent. the agent-to-agent script editor node allows alternative routing for the call. By not repeating agent IDs across the enterprise and by setting up a consistent agent ID assignment plan (such as all PIM 1 agent IDs begin with a 1. After a call has been successfully transferred. The agent-to-agent node must be configured to look for the agent ID value in the peripheral variable field where the IVR placed the agent ID. you can parse the CED field in the script editor to determine which PIM contains the agent. In the event that the target agent is not in a ready state. refer to the IPCC Reporting Guide. a call detail record for the original call leg will exist and a new call detail record will be opened for the new call leg. available online at Cisco. Agent IDs should not match any of the extensions on the Cisco CallManager cluster. Agent IDs are associated with a specific PIM and can be reused on other PIMs. The time during the consultation call leg.Chapter 1 Transfers in an IPCC Environment Architecture Overview Agent-to-Agent Transfers If the transfer is to a specific agent. then the same configuration as discussed in the previous section would be required. If you begin all agent IDs with the same number and they all have the same length. The DNP entry matching the dialed number (agent ID) must have DNP type equal to PBX. the original caller will be connected to the second consulted target agent. Then. In the script editor. Agent IDs by themselves are not unique.

refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide. page 1-23 Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 1-21 . Call Admission Control Quality of Service (QoS) is a necessary part of a Voice over IP (VoIP) environment. The sum of all these applications should not exceed 75% of the available WAN bandwidth. The entity that controls and manages this bandwidth pool is called a gatekeeper. The capacity of the WAN depends on the network infrastructure. or Transfer Connect) Many PSTN service providers offer a network-based transfer service. For details. QoS has various mechanisms to give voice traffic priority over data traffic. refer to the Cisco AVVID Network Infrastructure Quality of Service design guide. the bandwidth that was used for that call is returned to the voice bandwidth pool. If the voice bandwidth pool is exhausted. The PSTN is provisioned to detect these tones and perform some specific logic based upon the tones detected.cisco. even if the conferenced party has released. When a voice call is made. PSTN Transfers (Takeback N Transfer.com/go/srnd Call admission control makes sure that the active calls do not exceed the voice bandwidth allocation.cisco. but QoS alone is not enough to guarantee good voice quality. It is the gatekeeper's job to make sure that voice calls stay within the bandwidth allotment. the bandwidth needed for that call is subtracted from the available voice bandwidth pool. For information on how to calculate the required bandwidth for voice traffic. "transfer this call to site 2 and use 7500 as the DNIS value when delivering the call to site 2. the call center should be able to determine its busy hour call completions (BHCC) within the WAN and use the information to determine the bandwidth that is needed for its calls. In a Cisco CallManager environment. This bandwidth should be added to the data traffic and any other voice traffic that is on the network. Call admission control is a methodology for ensuring voice quality by limiting the number of active calls allowed on the network at one time.com/go/srnd For IPCC. What is needed is a way to make sure that the bandwidth allocated on the WAN link is not exceeded. This DTMF string could mean. transfer is no longer a valid operation. a certain amount of bandwidth should be allocated for voice traffic. These services are generally invoked by the customer premises equipment (CPE) outpulsing a series of DTMF tones. This total voice bandwidth must be able to support the voice call itself plus any call control traffic. A typical outpulse sequence might be something like *827500." IPCC has the ability to invoke these types of transfers. When voice is enabled as an application on a data network. there are two types of call admission control: • • Gatekeeper Controlled. page 1-22 Locations Controlled. then the next call request will be rejected due to insufficient bandwidth. When a call disconnects. available at http://www. available at http://www.Chapter 1 Architecture Overview Call Admission Control Transfers of Conferenced Calls After a conference has been set up by an agent.

which stay up if the call then gets transferred to another agent or IVR port at another site within the network. Cisco IP Contact Center Enterprise Edition SRND 1-22 76584 OL-7279-04 . The reason this is important is that calls are sent to agents and IVRs via routing clients (CTI Desktop. The total amount of bandwidth needed would depend on whether incoming traffic from the PSTN is routed through the WAN or if the WAN is used for inter-site transfers and conferences between agents. The ramification of having calls go out to the PSTN is that two ports are consumed because calls would have to come into and go out of the main or branch sites via voice gateway ports. Before sending the call out the gateway or intercluster trunk. which are not able to hang up and redial the call. The gatekeeper should be configured to allow enough bandwidth for call center traffic to go through. Therefore. (See Figure 1-6. or CTI Route Point). The gatekeeper-controlled model is used for distributed call processing deployments. Cisco CallManager will ask the gatekeeper if there is enough bandwidth for the call to go through the WAN to another site. For IPCC.) Figure 1-6 Area of Concern for Distributed Call Processing Models Cisco CallManager cluster Voice mail server M Gatekeeper IP IP V Router/gateway IP WAN Areas where bandwidth must be provisioned V Router/gateway V Router/gateway IP Cisco CallManager cluster M IP Cisco CallManager cluster M IP Voice mail server IP Voice mail server If the gatekeeper rejects the call. then Cisco CallManager can perform digit manipulation on the dialed digits and send this call transparently out the PSTN. it is important to define this alternate route and digit manipulation within the dialing plan if the gatekeeper does not allow the call to go on the WAN. IVR. the caller would receive busy tone and not be routed to its peripheral target (agent or IVR).Chapter 1 Call Admission Control Architecture Overview Gatekeeper Controlled Gatekeeper control means that there is an independent entity acting as a gatekeeper.

Ideally. it is important to calculate the bandwidth allocation for each branch office properly.Chapter 1 Architecture Overview Call Admission Control Locations Controlled For centralized call processing deployments. The number of simultaneous calls to each branch should be calculated. agent phones should be allocated as one "location" within the location configuration of Cisco CallManager to make sure that traffic generated to and from office workers' phones does not interfere with the bandwidth allocated to call center traffic. For IPCC. Inter-site transfer and conference situations as well as normal office traffic should also be taken into account. the call will fail. In this model. if the call fails due to insufficient bandwidth. the locations-controlled model is used. and there is no mechanism for the routing client to disconnect the call and then dial again. Therefore.) Figure 1-7 Area of Concern for Centralized Call Processing Models Cisco CallManager cluster Voice mail server M Router/ gateway Router/ gateway IP WAN IP V V Remote site IP Central site Areas where bandwidth must be provisioned. Cisco CallManager (not the gatekeeper) decides if there is enough bandwidth available on the WAN to send the call. If there is not enough bandwidth. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 76585 IP 1-23 . (See Figure 1-7. the caller receives busy tone because the call is routed by IVR or the CTI Desktop application. Transparent failover to the PSTN is not available with locations-based call admission control.

Chapter 1 Call Admission Control Architecture Overview Cisco IP Contact Center Enterprise Edition SRND 1-24 OL-7279-04 .

and IVR integration Sizing Redundancy This chapter discusses the impact of these factors (except for sizing) on the selection of a design. The primary factors that cause variations within these models are as follows: • • • • • • • • • Locations of IPCC servers Locations of voice gateways Choice of inter-exchange carrier (IXC) or local exchange carrier (LEC) trunks Pre-routing availability IVR queuing platform and location Transfers Traditional ACD. refer to the Cisco Network Infrastructure Quality of Service Design guide. Examples of scenarios where combinations are likely are identified within each section.com/go/srnd Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-1 . but the deployments can generally be categorized into the following major types or models: • • • • Single Site Multi-Site Centralized Call Processing Multi-Site Distributed Call Processing Clustering over the WAN Many variations or combinations of these deployment models are possible. available at http://www. For example. with considerations on hybrid PBX/ACD deployments. this chapter also lists considerations and risks that must be evaluated using a cost/benefit analysis. With each deployment model.cisco.C H A P T E R 2 Deployment Models There are numerous ways that IPCC can be deployed. a multi-site deployment may have some sites that use centralized call processing (probably small sites) and some sites that use distributed call processing (probably larger sites). Sizing and redundancy are discussed in later chapters of this IPCC design guide. PBX. For more information on the network infrastructure required to support an IPCC solution. A combination of these deployment models is also possible. Scenarios that best fit a particular deployment model are also noted. Also in this chapter is a section on integration of traditional ACD and IVR systems into an IPCC deployment.

the ICM Central Controller and Peripheral Gateways (PGs) could be split onto separate servers. many variations are possible. IP Phones.cisco. available at http://www. Figure 2-1 illustrates this type of deployment. refer to the chapter on Sizing IPCC Components and Servers. a Cisco CallManager cluster. and IP IVR or Internet Service Node (ISN)) are located at the same site and have no WAN connectivity between any IPCC software modules. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide. Intelligent Contact Management (ICM).com/go/srnd Single Site A single-site deployment refers to any scenario where all voice gateways. and call processing servers (Cisco CallManager. desktops. For information on when to install the ICM Central Controller and PG on separate servers. Figure 2-1 Single-Site Deployment Signaling/CTI PSTN IP Voice TDM Voice CallManager Cluster M V M M M M ICM IVR/ISN AW/HDS Agent Figure 2-1 shows two IP IVRs. For example. and a direct connection to the PSTN from the voice gateways. an Administrative Workstation (AW) and Historical Data Server (HDS).Chapter 2 Single Site Deployment Models For more information on deployment models for IPCC and IP Telephony. agents. redundant ICM PROGGERS. page 5-1. Cisco IP Contact Center Enterprise Edition SRND 2-2 126019 IP OL-7279-04 . The ICM PROGGER in this scenario is running the following major software processes: • • • • • • Router Logger Cisco CallManager Peripheral Interface Manager (PIM) Two IVR or ISN PIMs CTI Server CTI Object Server (CTI OS) or Cisco Agent Desktop Servers Within this model.

Given that there is no WAN in this deployment model. For information on determining the number and type of servers required. and so on) to be used between the PSTN and voice gateway or the specific signaling (H. page 3-1 Transfers In this deployment model (as well as in the multi-site centralized call processing model).com/go/srnd The main advantage of the single-site deployment model is that there is no WAN connectivity required.Chapter 2 Deployment Models Single Site The ICM could also be deployed in a simplex fashion instead of redundantly. page 5-1. available at http://www. consultative transfers. A single server may be used. More information can be found in the sections on Sizing ISN Components.cisco. allow scaling and redundancy. discusses how to determine the number of gateway ports. page 4-20.729 or any other compressed Real-Time Transport Protocol (RTP) stream. all initial and subsequent queuing is done using ISN. on the other hand. Treatment and Queuing with IP IVR In this deployment model. For example. there is generally no need to use G. looking for any specialist in the specialist skill group). Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-3 . a deployment can have trunks from a local PSTN. Multiple servers. This also implies that both the routing client and the peripheral target are the same peripheral (or PIM). refer to the chapter on Design Considerations for High Availability. see Traditional ACD Integration. Connection to multiple PSTNs and a PBX all from the same single-site deployment is also possible. MF. and conferencing is also not specified in this model. page 2-35. the ICM should be used to load-balance calls across those IP IVRs. so transcoding would not be required. The number of Cisco CallManager nodes and the hardware model used is not specified along with the number of IP IVRs or ISN servers. and a traditional PBX/ACD. If multiple IP IVRs are deployed. the type of voice gateways. page 2-34. both the transferring agent and target agent are on the same PIM. The chapter on Sizing Call Center Resources. page 3-1. or the number of voice gateways and trunks. The amount of digital signal processor (DSP) resources required for placing calls on hold. Cisco campus design guides and IP Telephony design guides are available to assist in the design of these components. and Traditional IVR Integration. refer to the chapter on Sizing IPCC Components and Servers. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide. page 4-1. This deployment model also does not specify the type of signaling (ISDN. The transferring agent generates a transfer to a particular dialed number (for example. R1. Treatment and Queuing with ISN In this deployment model. Another variation in this model is to have the voice gateways connected to the line side of a PBX instead of the PSTN. with all ISN processes co-located on that server.323 or MGCP) to be used between the voice gateway and Cisco CallManager. and Design Considerations for High Availability. For information on sizing of these resources. all initial and subsequent queuing is done on the IP IVR. For information on the benefits and design for IPCC redundancy. Also not specified in this model is the specific data switching infrastructure required for the LAN. a toll-free PSTN. For more information.

As sites become larger or more geographically dispersed. In some of the more complex scenarios to be discussed in later sections. page 2-7 Centralized Voice Gateways If an enterprise has small remote sites or offices in a metropolitan area where it is not efficient to place call processing servers or voice gateways. the Cisco CallManager PIM logic will generate a route request to the ICM router. If a target agent is not available to receive the transferred call. If a target agent (specialist) is available to receive the transferred call. Multi-Site with Centralized Call Processing A multi-site deployment with centralized call processing refers to any scenario where call processing servers (Cisco CallManager. Cisco IP Contact Center Enterprise Edition SRND 2-4 OL-7279-04 . sometimes the routing client and peripheral target are not the same. and that the post-route option is set to yes. ICM. and IP Phones are located remotely across a WAN link or centrally. the Cisco CallManager PIM will then initiate the transfer by sending a JTAPI transfer request to the Cisco CallManager. The ICM router will match the dialed number to a call type and activate the appropriate routing script. use of distributed voice gateways might be a better option. while the peripheral target is the specific IVR PIM to which the call is being transferred.Chapter 2 Multi-Site with Centralized Call Processing Deployment Models Assuming that a match is found in the Dialed Number Plan (DNP) for the transfer request. Figure 2-2 illustrates this model. then the ICM routing script is typically configured to transfer the call to an IVR so that queue treatment can be provided. In this scenario. Also in this scenario. At the same time that the label is returned to the routing client. Figure 2-2 illustrates this type of deployment. the label is typically just the extension of the phone where the target agent is currently logged in. while any combination of voice gateways. the routing client and peripheral target are different. the routing client and peripheral target are the same Cisco CallManager PIM. agents. that the DNP type is allowed for the transferring agent. This is because the transferring agent and the target agent are both associated with the same PIM. and IP IVR or ISN) are located at the same site. There are two variations of this model: • • Centralized Voice Gateways. pre-call data (which includes any call data that has been collected for this call) is delivered to the peripheral target. Upon receiving the route response (label). desktops. the label is a dialed number that will instruct the Cisco CallManager to transfer the call to an IVR. In this scenario. The routing client is the Cisco CallManager PIM. page 2-4 Distributed Voice Gateways. then the ICM router will return the appropriate label to the routing client (the Cisco CallManager PIM). then this model is most appropriate. In this scenario. The routing script looks for an available specialist.

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 126020 IP IP 2-5 . The number of Cisco CallManager and IP IVR or ISN servers is not specified by the deployment model. see Single Site. IP Phones. The ICM software can be installed as redundant or simplex. and agent desktops are needed at remote sites where only a few agents exist. IPCC Queue Points (IP IVR or ISN) are used more efficiently because all Queue Points are aggregated. voice gateways. No VoIP WAN bandwidth is used while calls are queuing (initial or subsequent). PSTN trunks are used more efficiently because the trunks for small remote sites are aggregated. except for local POTS lines for emergency services (911) in the event of a loss of the WAN link. page 2-2. No PSTN trunks are required directly into these small remote sites and offices. For example. multi-site deployments can run the ICM software all on the same server or on multiple servers. all the same variations exist. • • • • As with the single-site deployment model.Chapter 2 Deployment Models Multi-Site with Centralized Call Processing Figure 2-2 Multi-Site Deployment with Centralized Call Processing and Centralized Voice Gateways Signaling/CTI PSTN IP Voice TDM Voice CallManager Cluster M V M M M ICM PG/CTI PG/CTI M AW/HDS IVR/ISN VoIP WAN Agent Agent Advantages • Only a small data switch and router. nor are the LAN/WAN infrastructure. and only limited system and network management skills are required at remote sites. For other variations. or PSTN connectivity.

local trunks are configured to dial out locally and for 911 emergency calls. While calls are queuing. This situation could be mitigated if the business requirements are to dial 1-800 numbers at the central site. transcoding is required because the IP IVR can generate only G. so transcoding might also be required depending upon how the IP Telephony deployment is designed. ISN is used in the same way as IP IVR. An alternative is to offer customers a toll-free number to dial. an appropriately designed QoS WAN is critical. Treatment and Queuing with ISN In this model. However. the transferring agent and target agent are on the same Cisco CallManager cluster and Cisco CallManager PIM. Therefore. this requires the call center to incur toll-free charges that could be avoided if customers had a local PSTN number to dial.cisco. and this must be managed via the Cisco CallManager dial plan. If requeuing is required during a transfer or reroute on ring-no-answer. customers might be required to dial a long-distance number to reach what would normally be a local PSTN phone call if voice gateways with trunks were present at the remote site.Chapter 2 Multi-Site with Centralized Call Processing Deployment Models Best Practices • • VoIP WAN connectivity is required for RTP traffic to agent phones at remote sites. Adequate bandwidth and QoS provisioning are critical for these links. In most cases. the RTP traffic flow during the queue treatment also does not flow over the WAN. Cisco IP Contact Center Enterprise Edition SRND 2-6 OL-7279-04 . This reduces the amount of WAN bandwidth required to the remote sites.com/go/srnd During consultative transfers where the agent (not the caller) is routed to an IP IVR port for queuing treatment. Cisco CallManager locations-based call admission control failure will result in a routed call being disconnected. Also. all call queuing is done on the IP IVR at a single central site. no RTP traffic flows over the WAN. and have those calls all routed to the centralized voice gateway location. The only differences are that QoS must be enabled and that appropriate LAN/WAN routing must be established. refer to the Cisco Network Infrastructure Quality of Service Design guide. the same call and message flows will occur as in the single-site model. it is important to provision adequate bandwidth to the remote sites. CTI data to and from the IPCC Agent Desktop flows over the WAN. • • • • • Treatment and Queuing with IP IVR As in the single-site deployment.711 media streams. Because there are no voice gateways at the remote sites. Transfers In this scenario. RTP traffic to agent phones at remote sites may require compression to reduce VoIP WAN bandwidth usage. available at http://www. It may be desirable for calls within a site to be uncompressed. Therefore. Skinny Client Control Protocol (SCCP) call control traffic from IP Phones to the Cisco CallManager cluster flows over the WAN. whether the transferring agent is on the same LAN as the target or on a different LAN. For details on provisioning your WAN with QoS. The lack of local voice gateways with local PSTN trunks can also impact access to 911 emergency services.

Figure 2-3 Multi-Site Deployment with Centralized Call Processing and Distributed Voice Gateways with IP IVR PSTN CallManager Cluster M V M M M ICM PG/CTI PG/CTI M AW/HDS Signaling/CTI IVR/ISN IP Voice TDM Voice VoIP WAN Agent Agent In this deployment model. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 126021 IP IP 2-7 . Customer service levels for calls arriving into that site might suffer due to longer queue times and handle times. even though an agent at another site is available. Longer handle times can occur because. but this is not required. even though a more qualified agent exists at another site. each requiring local PSTN trunks for incoming calls. This distributed voice gateway model may be appropriate for a company with many small sites. shown with IP IVR for queuing and treatment. the IPCC configuration may continue to queue for an agent at the local site only. the call may be routed to a local agent to reduce WAN bandwidth usage. By restricting calls to the site where it arrived: • • • • VoIP WAN bandwidth is reduced for calls going to agents. Longer queue times can occur because. This model provides local PSTN connectivity for local calling and access to local emergency services. Figure 2-3 illustrates this model.Chapter 2 Deployment Models Multi-Site with Centralized Call Processing Distributed Voice Gateways A variation of the centralized call processing model can include multiple voice gateway locations. it might be desirable to restrict calls arriving at a site to be handled by an agent within that site.

and Site 2 has only a few calls in queue or maybe even a few agents currently available. A list of PSTN carriers that offer ICM pre-routing services can be found in the ICM product documentation available at http://www. and system configurations are managed from a centralized location. and PGs (for both Cisco CallManager and IVR/ISN) are co-located. Cisco CallManager. This type of multi-site load balancing provided by the ICM is dynamic and automatically adjusts as call volumes change at all sites. Inbound calls from the local PSTN could be both direct inward dial (DID) and contact center calls. It is important to understand the requirements for all inbound and outbound calling to determine the most efficient location for voice gateways. For example. Advantages • • • Only limited systems management skills are needed for the remote sites because most servers. It is important to determine the maximum number of calls that will flow between sites or locations. and so forth. In that scenario. Just as in the two previous deployment models. including sites with local PSTN trunks in addition to toll-free PSTN trunks. The centralized voice gateways can be connected to one PSTN carrier providing toll-free services. In this model. the ICM pre-routing software can load-balance the toll-free contact center calls around the local contact center calls. voice gateways. where they are calling from. and how they are calling. much variation exists in the number and type of ICM.Chapter 2 Multi-Site with Centralized Call Processing Deployment Models It is important for deployment teams to carefully assess the trade-offs between operational costs and customer satisfaction levels to establish the right balance on a customer-by-customer basis. while the distributed voice gateways can be connected to another PSTN carrier providing local phone services. more RTP traffic will flow across the WAN. suppose you have a two-site deployment where Site 1 currently has all agents busy and many calls in queue from locally originated calls. The ICM pre-routing option can be used to load-balance calls across sites. An IPCC deployment may actually use a combination of centralized and distributed voice gateways. you could have the ICM instruct the toll-free provider to route most or all of the toll-free calls to Site 2. and IP IVR or ISN servers. Cisco CallManager locations-based call admission Cisco IP Contact Center Enterprise Edition SRND 2-8 OL-7279-04 . it may be desirable to route a specific high-profile customer to an agent at another site to reduce their queue time and allow the call to be handled by a more experienced representative. For example. Cisco CallManager. while another customer may be restricted to an agent within the site where the call arrived. Best Practices • The IP IVR or ISN.com/univercd/cc/td/doc/product/icm/ In multi-site environments where the voice gateways have both local PSTN trunks and separate toll-free trunks delivering contact center calls. Identify who is calling. why they are calling. PSTN connectivity. the ICM's pre-routing capability can also be used to load-balance calls dynamically across the multiple sites. In multi-site deployments with distributed voice gateways. the only IPCC communications that can be separated across a WAN are the following: – ICM Central Controller to ICM PG – ICM PG to IPCC Agent Desktops – Cisco CallManager to voice gateways – Cisco CallManager to IP Phones • If calls are not going to be restricted to the site where calls arrive. No WAN RTP traffic is required for calls arriving at each remote site that are handled by agents at that remote site. LAN/WAN infrastructure. or if calls will be made between sites. equipment.cisco.

as with the centralized call processing model. sites could be deployed with or without local voice gateways. The label then indicates whether a transfer is intra-site or inter-site. refer to the ICM product documentation available at http://www. PGs.com/univercd/cc/td/doc/product/icm/ Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-9 . If the ICM Central Controller is deployed with redundancy. side A and B can be deployed side-by-side or geographically separated (remote redundancy). Multi-Site with Distributed Call Processing Enterprises with multiple medium to large sites separated by large distances tend to prefer a distributed call processing model. Therefore. However. WAN bandwidth must still be provisioned for transfers and conferences that involve agents at other locations. Some deployments may also contain a combination of distributed voice gateways (possibly for locally dialed calls) and centralized voice gateways (possibly for toll-free calls) as well as centralized or distributed treatment and queue points. available at http://www. and CTI Server.com/go/srnd Treatment and Queuing with IP IVR WAN bandwidth must be provisioned to support all calls that will be treated and queued at the central site.323 or MGCP signaling traffic between the voice gateways and the centralized Cisco CallManager servers will flow over the WAN. each site has its own Cisco CallManager cluster.cisco. Centralized IP IVRs provide efficiency of IP IVR ports when compared with smaller deployments of IP IVRs at each remote site. For details on remote redundancy. and signaling delays must be within tolerances listed in the Cisco IP Telephony Solution Reference Network Design (SRND) guide. Each site can be configured within the ICM as a separate peripheral. In this model. it is important to provision adequate bandwidth to the remote sites. ISN queues and treats calls on the remote gateways. Treatment and Queuing with ISN Using ISN for treatment and queuing allows you to reduce the amount of voice bearer traffic traveling across the WAN. there will still be only one logical ICM Central Controller. treatment and queue points. and appropriately designed QoS for the WAN is critical. Proper QoS implementation on the WAN is critical. eliminating the need to terminate the voice bearer traffic at the central site. • H. Transfers Intra-site or inter-site transfers using the VoIP WAN to send the RTP stream from one site to another will occur basically the same way as a single-site transfer or a transfer in a deployment with centralized voice gateways.cisco. An alternative to using the VoIP WAN for routing calls between sites is to use a carrier-based PSTN transfer service.Chapter 2 Deployment Models Multi-Site with Distributed Call Processing control failure will result in a routed call being disconnected (rerouting within Cisco CallManager is not currently supported). using Takeback N Transfer (TNT). Regardless of how many sites are being deployed. These services allow the IPCC voice gateways to outpulse DTMF tones to instruct the PSTN to reroute (transfer) the call to another voice gateway location.

redundancy. All or most VoIP traffic can be contained within the LAN of each site. An analysis of benefits from customer service levels versus WAN costs is required to determine whether limiting calls within a site is recommended. and IP IVR servers can vary. Central processing and gateways may be added for self-service. voice gateways. Just as in the centralized call processing model with distributed voice gateways. the use of a pre-routing PSTN Network Interface Controller (NIC) is also an option. and there is no software limit (you can have up to 80 PGs) to the number of sites that can be combined by the ICM Central Controller to produce a single enterprise-wide contact center. • • Cisco IP Contact Center Enterprise Edition SRND 2-10 126022 IP IP OL-7279-04 . voice gateways with PSTN trunks terminate into each site. and so forth are also variable within this deployment model. if desired. Figure 2-4 Multi-Site Deployment with Distributed Call Processing and Distributed Voice Gateways with IP IVR AW/HDS ICM Signaling/CTI IP Voice TDM Voice PG/CTI PG/CTI IVR IVR PG/CTI PG/CTI CallManager Cluster 1 M M M M M CallManager Cluster 2 M V VoIP WAN V M M M M PSTN Agent Agent As with the previous models. LAN/WAN infrastructure. a small portion of calls arriving at a particular site can be queued for agent resources at other sites to improve customer service levels. ICM pre-routing can be used to load-balance calls to the best site to reduce WAN usage for VoIP traffic. Cisco CallManager servers. Use of a PSTN transfer service (for example. In this model. PSTN trunks.Chapter 2 Multi-Site with Distributed Call Processing Deployment Models Distributed Voice Gateways with Treatment and Queuing Using IP IVR This deployment model is a good choice if the company has multiple medium to large sites. The QoS WAN shown in Figure 2-4 would be required for voice calls to be transferred across sites. it may be desirable to limit the routing of calls to agents within the site where the call arrived (to reduce WAN bandwidth). If desired. Takeback N Transfer) could eliminate that need. Figure 2-4 illustrates this model. many variations are possible. and support for smaller sites. In addition. toll-free calls. The number and type of ICM Servers. Advantages • Each independent site can scale to support up to 2000 agents per Cisco CallManager cluster.

and IP IVR must be co-located. the Cisco CallManager CTI route points could send the calls to IP IVR ports to provide basic announcement treatment or to invoke a PSTN transfer to another site. • • • • Treatment and Queuing Initial call queuing is done on an IP IVR co-located with the voice gateways. For example. The RTP flow at this point would be directly from the voice gateway at Site 1 to the agent's IP Phone at Site 1. The ICM Central Controller provides the capability to create a single enterprise-wide queue. then all contact center routing for calls at that site is also lost. the call should be queued to an IP IVR at Site 2 to avoid generating another inter-cluster call. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-11 . so no transcoding is required. it is important to implement a fault-tolerant WAN. the two Cisco CallManager clusters would still logically see two calls in progress between the two clusters. For example. When a call is transferred and subsequent queuing is required. Each site can be sized according to the requirements for that site The ICM Central Controller provides centralized management for configuration of routing for all calls within the enterprise. the queuing should be done on an IP IVR at the site where the call is currently being processed. Even when a fault-tolerant WAN is implemented. The communication link from the ICM Central Controller to the PG must be sized properly and provisioned for bandwidth and QoS. refer to the chapter on Bandwidth Provisioning and QoS Considerations. It is best to ensure that adequate WAN bandwidth exists between sites for the maximum amount of calling that can occur. Best Practices • • The PG. (For details. two separate call signaling control paths will remain intact between the two clusters (producing a logical hair-pinning and reducing the number of inter-cluster trunks by two). but that agent needs to transfer the call to another agent whose location is unknown. Therefore. if a call comes into Site 1 and gets routed to an agent at Site 2. it is important to identify contingency plans for call treatment and routing when communication is lost between the ICM Central Controller and PG. If the communication link between the PG and the ICM Central Controller is lost. However. While two inter-cluster call legs for the same call will not cause unnecessary RTP streams. Cisco CallManager cluster.Chapter 2 Deployment Models Multi-Site with Distributed Call Processing • • • • • Failure at any one site has no impact on operations at another site. Another alternative is for the Cisco CallManager cluster to route the call to another Cisco CallManager cluster that may have a PG with an active connection to the ICM Central Controller. A second inter-cluster call would be made only if an agent at Site 1 was selected for the transfer.) Gatekeeper-based call admission control could be used to reroute calls between sites over the PSTN when WAN bandwidth is not available. Latency between ICM Central Controllers and remote PGs cannot exceed 200 ms one way (400 ms round-trip). The ICM Central Controller provides consolidated reporting for all sites. page 8-1. in the event of a lost ICM Central Controller connection.

In this model. Cisco CallManager servers. In addition. The number and type of ICM Servers. Another alternative is to have the Cisco CallManager cluster at Site 1 make an outbound call back to the PSTN. redundancy. Figure 2-5 illustrates this model. and support for smaller sites. the use of a pre-routing PSTN Network Interface Controller (NIC) is also an option. Just as in the centralized call processing model with distributed voice gateways. and so forth are also variable within this deployment model. voice gateways. sufficient inter-cluster trunks must be configured. voice gateways with PSTN trunks terminate into each site. it may be desirable to limit the routing of calls to agents within the site where the call arrived (to reduce WAN bandwidth). except that ISN is used instead of IP IVR for call treatment and queuing. If the VoIP WAN is used. PSTN trunks. Distributed Voice Gateways with Treatment and Queuing Using ISN This deployment model is the same as the previous model. Central processing and gateways may be added for self-service. and ISN servers can vary. Transfers between Cisco CallManager clusters use either the VoIP WAN or a PSTN service. toll-free calls. LAN/WAN infrastructure. further reducing the WAN bandwidth needs.Chapter 2 Multi-Site with Distributed Call Processing Deployment Models Transfers Transfers within a site function just like a single-site transfer. Cisco IP Contact Center Enterprise Edition SRND 2-12 126023 IP IP OL-7279-04 . Call treatment and queuing may also be achieved at the site where the call arrived. An alternative to using the VoIP WAN for routing calls between sites is to use a PSTN transfer service. Figure 2-5 Multi-Site Deployment with Distributed Call Processing and Distributed Voice Gateways with ISN AW/HDS ICM ISN PG/CTI PG/CTI PG PG Signaling/CTI IP Voice TDM Voice PG/CTI PG/CTI CallManager Cluster 1 M M M M M CallManager Cluster 2 M V VoIP WAN V M M M M PSTN Agent Agent As with the previous models. but the call would use two voice gateway ports at Site 1 for the remainder of the call. The PSTN would then route the call to Site 2. many variations are possible. These services allow the IPCC voice gateways to outpulse DTMF tones to instruct the PSTN to reroute (transfer) the call to another voice gateway location.

ICM pre-routing can be used to load-balance calls to the best site to reduce WAN usage for VoIP traffic. The ISN PG and ISN servers must be co-located. regardless of ISN server location. Usage of a PSTN transfer service (for example. eliminating the need to terminate the voice bearer traffic at the central site. two separate call signaling control paths will remain intact between the two clusters (producing a logical hairpinning and reducing the number of intercluster trunks by two). Each site can be sized according to the requirements for that site. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-13 . • • • • • • • • Best Practices • • The Cisco CallManager PG and Cisco CallManager cluster must be co-located. With IP IVR.com/partner/WWChannels/technologies/resources/IPCC_resources.Chapter 2 Deployment Models Multi-Site with Distributed Call Processing Advantages • ISN Servers can be located either centrally or remotely. WAN bandwidth must still be provisioned for transfers and conferences that involve agents at other locations. Takeback N Transfer) could eliminate that need. ISN servers may be located at the central site or distributed to remote sites. executing on the local gateway. The ICM Central Controller provides centralized management for configuration of routing for all calls within the enterprise. if desired. it is important to identify contingency plans for call treatment and routing when communication is lost between the ICM Central Controller and PG. Failure at any one site has no impact on operations at another site. then all contact center routing for calls at that site is lost. All or most VoIP traffic can be contained within the LAN of each site. Unlike IP IVR. This tool is available online at http://www.cisco. Each independent site can scale to support up to 2000 agents per Cisco CallManager cluster. Call treatment and queuing will still be distributed. with ISN the call legs are torn down and reconnected. The communication link from the ICM Central Controller to PG must be properly sized and provisioned for bandwidth and QoS. avoiding signaling hairpins. ISN is shown centrally located in Figure 2-5. The QoS WAN would be required for voice calls to be transferred across sites. Cisco provides a partner tool called the VRU Peripheral Gateway to ICM Central Controller Bandwidth Calculator to assist in calculating the VRU PG-to-ICM bandwidth requirement. a small portion of calls arriving at a particular site can be queued for agent resources at other sites to improve customer service levels.html • If the communication link between the PG and the ICM Central Controller is lost. If desired. and there is no software limit to the number of sites that can be combined by the ICM Central Controller to produce a single enterprise-wide contact center. Latency between ICM Central Controllers and remote PGs cannot exceed 200 ms one way (400 ms round-trip) • Treatment and Queuing ISN queues and treats calls on the remote gateways. Therefore. The ICM Central Controller provides the capability to create a single enterprise-wide queue. The ICM Central Controller provides consolidated reporting for all sites. Even when a fault-tolerant WAN is implemented. it is important that a fault-tolerant WAN is implemented.

Cisco IP Contact Center Enterprise Edition SRND 2-14 126024 IP IP OL-7279-04 . These services allow the IPCC voice gateways to outpulse DTMF tones to instruct the PSTN to reroute (transfer) the call to another voice gateway location. Another alternative is to have the Cisco CallManager cluster at Site 1 make an outbound call back to the PSTN. Distributed ICM Option with Distributed Call Processing Model Figure 2-6 illustrates this deployment model.Chapter 2 Multi-Site with Distributed Call Processing Deployment Models Transfers Transfers within a site function just like a single-site transfer. If the VoIP WAN is used. The PSTN would then route the call to Site 2. Figure 2-6 Distributed ICM Option Shown with IP-IVR Dedicated Private Link Signaling/CTI IP Voice TDM Voice AW/HDS ICM A ICM B AW/HDS PG/CTI PG/CTI CallManager Cluster 1 M M M M M IVR IVR PG/CTI PG/CTI CallManager Cluster 2 M V VoIP WAN V M M M M PSTN Agent Agent Advantages The primary advantage of the distributed ICM option is the redundancy gained from splitting the ICM Central Controller between two redundant sites. Transfers between Cisco CallManager clusters use either the VoIP WAN or a PSTN service. but the call would use two voice gateway ports at Site 1 for the remainder of the call. sufficient intercluster trunks must be configured. An alternative to using the VoIP WAN for routing calls between sites is to use a PSTN transfer service.

see the section on Bandwidth and QoS Requirements for IPCC Clustering Over the WAN. the private traffic usually traverses an Ethernet crossover cable or LAN connected directly between the side A and side B ICM Central Controller components. but this is not necessary when using a ring technology. Currently a maximum latency of 20 ms one way (40 ms round-trip) is allowed. Central administration for both ICM and Cisco CallManager Reduction of servers for distributed deployment Best Practices • The highly available (HA) WAN between the central sites must be fully redundant with no single point of failure. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide. The private link cannot traverse the same path as public traffic. Bandwidth between central sites for ICM public and private traffic. refer to the WAN infrastructure and QoS design guides available at http://www. Advantages • • • • No single point of failure. available at http://www. The redundant centralized model is explored in the next section on Clustering over the WAN • • • • Clustering Over the WAN Clustering over the WAN for IPCC allows full agent redundancy in the case of a central-site outage. the private communication between the A and B ICM components must travel across a dedicated link such as a T1. Latency across the private dedicated link cannot exceed 100 ms one way (200 ms round-trip). In a non-distributed ICM model.cisco. The WAN between central sites must be highly available (HA) with separate ICM (PG and Central Controller) private links. page 2-22. The private link must have path diversity and must reside on a link that is completely path-independent from ICM public traffic. For more information. Latency requirements across the highly available (HA) WAN must meet the current Cisco IP Telephony requirements for clustering over the WAN. Implementation of clustering over the WAN for IPCC does have several strict requirements that differ from other models. In the distributed ICM model. including loss of an entire central site Remote agents require no reconfiguration to remain fully operational in case of site or link outage.Chapter 2 Deployment Models Clustering Over the WAN Best Practices • ICM Central Controllers (Routers and Loggers) must have a dedicated link to carry the private communication between the two redundant sites.com/go/srnd • • Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-15 . agents and agent devices dynamically switch to the redundant site.cisco. and all other voice-related media and signaling must be properly provisioned with QoS enabled. For full specifications.) In case of partial failure of the highly available WAN. Latency between ICM Central Controllers and remote PGs cannot exceed 200 ms one way (400 ms round-trip). Cisco CallManager intra-cluster communications (ICC). the redundant link must be capable of handling the full central-site load with all QoS parameters. The transmission distance will be lessened by network conditions that cause additional latency. A highly available (HA) WAN using point-to-point technology is best implemented across two separate carriers. This equates to a transmission distance of approximately 1860 miles (3000 km) under ideal conditions.com/go/srnd. (For information regarding site-to-site redundancy options. When outages occur.

Cisco recommends 5 nodes. especially if there are IP Phones (either contact center or non-contact center) local to the central sites. if using CTI OS • • Separate dedicated link(s) for ICM private communications are required between ICM Central Controllers Side A and Side B and between PGs Side A and Side B to ensure path diversity. with a WAN technology such as Frame Relay using multiple permanent virtual circuits (PVCs). Without path diversity. one for Central Controller private and one for Cisco CallManager PG private. These paths may reside on the same physical link from the agent site. or central media resources that would require local failover capabilities. Dedicated private link(s) may be two separate dedicated links. or one converged dedicated link containing Central Controller and PG private.Chapter 2 Clustering Over the WAN Deployment Models • IPCC latency requirements can be met by conforming to IP Telephony requirements. and other traffic if one path fails. media. Separate paths must exist from agent sites to each central site. Local gateways also will need local redundant connections to Cisco CallManager. central gateways. Both paths must be capable of handling the full load of signaling. Bandwidth requirements across the highly available (HA) WAN include bandwidth and QoS provisioning for (see Bandwidth and QoS Requirements for IPCC Clustering Over the WAN. page 2-22): – Cisco CallManager intra-cluster communications (ICC) – Communications between Central Controllers – Communications between Central Controller and PG – Communications between CTI Object Server (CTI OS) and CTI Server. • • • • Cisco IP Contact Center Enterprise Edition SRND 2-16 OL-7279-04 . If a dual failure occurs even for a moment. the possibility of a dual (public communication and private communication) failure exists. Path diversity is required due to the architecture of ICM. The minimum cluster size using IP IVR as the treatment and queuing platform is 5 nodes (publisher plus 4 subscribers). for more information. ICM instability and data loss may occur. the bandwidth requirements for Cisco CallManager intra-cluster communications differ between IPCC and IP Telephony. However. However. See Site-to-Site ICM Private Communications Options. page 2-22. including the corruption of one logger database. For more information. This minimum is required to allow IP IVR at each site to have redundant connections locally to the cluster without traversing the WAN. JTAPI connectivity between Cisco CallManager and IP IVR is not supported across the WAN. page 2-20. The minimum cluster size using ISN as the treatment and queuing platform is 3 nodes (publisher plus 2 subscribers). see the section on Bandwidth and QoS Requirements for IPCC Clustering Over the WAN.

Calls are treated and queued locally. Figure 2-7 Centralized Voice Gateways with Centralized Call Treatment and Queuing Using IP IVR Site 1 PG 2A PG 2B Site 2 ICM A IVR 1 1 M ICM B IVR 2 2 M 3 M Highly Available WAN 4 M 5 M PG 1A V CTIOS 1A PG 1B WAN ICC CTIOS 1B V PSTN ICM Public ICM Private IP PSTN Remote Agent Site Advantages • • Component location and administration are centralized. page 2-22. For more information. IP IVR is centrally located and used for treatment and queuing on each side.cisco. Pre-routing is not recommended. available at http://www. See Bandwidth and QoS Requirements for IPCC Clustering Over the WAN. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide.Chapter 2 Deployment Models Clustering Over the WAN Centralized Voice Gateways with Centralized Call Treatment and Queuing Using IP IVR In this model. Gateways and IVRs must be scaled to handle the full load in both sites if one site fails. Figure 2-7 illustrates this model. Best Practices • WAN connections to agent sites must be provisioned with bandwidth for voice as well as control and CTI. the voice gateways are located in the central sites.com/go/srnd • • • Central site outages would include loss of half of the ingress gateways. Pre-routing may be used to balance the load. but it will not be able to prevent calls from being routed to a failed central site. assuming a balanced deployment. Carrier call routing must be able to route calls to the alternate site in the case of a site or gateway loss. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 126025 2-17 . for more information. Local voice gateway may be needed at remote sites for local out-calling and 911. eliminating the need for queuing across a WAN connection.

There is less load on Cisco CallManager because ISN is the primary routing point. Figure 2-8 Centralized Voice Gateways with Centralized Call Treatment and Queuing Using ISN Site 1 PG 2A PG 2B Site 2 ICM A ISN 1 1 M ICM B ISN 2 Highly Available WAN 2 M 3 M 4 M 5 M Gatekeeper 1 PG 1A V CTIOS 1A Gatekeeper 2 PG 1B WAN ICC CTIOS 1B V PSTN ICM Public ICM Private IP PSTN Remote Agent Site Advantages • • • Component location and administration are centralized. eliminating the need for queuing across a WAN connection.Chapter 2 Clustering Over the WAN Deployment Models Centralized Voice Gateways with Centralized Call Treatment and Queuing Using ISN In this model. • Cisco IP Contact Center Enterprise Edition SRND 2-18 126026 OL-7279-04 . See Bandwidth and QoS Requirements for IPCC Clustering Over the WAN. page 5-1. for more information. Calls are treated and queued locally. See Sizing IPCC Components and Servers. for more information. This allows higher scalability per cluster compared to IP IVR implementations. the voice gateways are Voice XML (VXML) gateways located in the central sites. Best Practices • WAN connections to agent sites must be provisioned with bandwidth for voice as well as control and CTI. ISN is centrally located and used for treatment and queuing. A local voice gateway might be needed at remote sites for local out-calling and 911. Figure 2-8 illustrates this model. page 2-22.

Figure 2-9 illustrates this model. the voice gateways are VXML gateways distributed to agent locations. page 5-1. This allows higher scalability per cluster compared to IP IVR implementations. for more information. There is less load on Cisco CallManager because ISN is the primary routing point. eliminating the need for queuing across a WAN connection. Local calls incoming and outgoing. Figure 2-9 Distributed Voice Gateways with Distributed Call Treatment and Queuing Using ISN Site 1 PG 2A PG 2B Site 2 ICM A ISN 1 1 M ICM B ISN 2 2 M 3 M Highly Available WAN 4 M 5 M Gatekeeper 1 PG 1A CTIOS 1A Gatekeeper 2 PG 1B CTIOS 1B WAN ICC PSTN V IP ICM Public ICM Private Remote Agent Site Advantages • No or minimal voice RTP traffic across WAN links if ingress calls and gateways are provisioned to support primarily their local agents. ISN is centrally located and used for treatment and queuing on the remote gateways. including 911.Chapter 2 Deployment Models Clustering Over the WAN Distributed Voice Gateways with Distributed Call Treatment and Queuing Using ISN In this model. can share the local VXML gateway. Calls are treated and queued at the agent site. See Sizing IPCC Components and Servers. Transfers and conferences to other sites would traverse the WAN. • • • Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 126027 2-19 .

Link sizing and configuration must be examined before any major change to call load. ICM Central Controller Private and Cisco CallManager PG Private Across Dual Links Dual links. Unanticipated changes to the call flow or configuration (including misconfiguration) are less likely to cause issues across separate private links. do not have to be redundant and must not be redundant against each other. therefore links are simpler to configure and maintain. thus reducing the QoS and sizing changes needed to ensure proper functionality. shown in Figure 2-10. The QoS configuration is limited to two classifications across each link. Resizing or alterations of the deployment model and call flow may affect only one link. Figure 2-10 ICM Central Controller Private and Cisco CallManager PG Private Across Dual Links Site 1 ICM A Site 2 ICM B Advantages • • • • Failure of one link does not cause both the ICM Central Controller and PG to enter simplex mode. call flow. Locating the media server at the agent site reduces bandwidth requirements but adds to the decentralized model. The links. There are two options for achieving this path separation: dual and single links. separate ICM Central Controller Private traffic from VRU/CM PG Private traffic. however. Best Practices • • The links must be across separate dedicated circuits. Site-to-Site ICM Private Communications Options ICM private communications must travel on a separate path from the public communications between ICM components. The media server for ISN may be centrally located or located at the agent site. Media may also be run from gateway flash.Chapter 2 Clustering Over the WAN Deployment Models Best Practices • • Distributed gateways require minimal additional remote maintenance and administration over centralized gateways. or deployment configuration Cisco IP Contact Center Enterprise Edition SRND 2-20 126028 PG A PG B OL-7279-04 . thus reducing the possibility of an outage due to a double failure.

Link must be a dedicated circuit fully isolated from. page 2-15. but more complex Best Practices • • The link does not have to be redundant. Single-link implementations are more common and less costly than dual-link implementations. Figure 2-11 ICM Central Controller Private and Cisco CallManager PG Private Across Single Link Site 1 ICM A Site 2 ICM B Advantages • • Less costly than separate-link model Fewer links to maintain. at the beginning of the section on Clustering Over the WAN. Link sizing and configuration must be examined before any major change to call load. See Best Practices. the highly available (HA) WAN. for more information on path diversity. at the beginning of the section on Clustering Over the WAN. This is especially important in the single link model. If a redundant link is used. page 2-15. For details. Separate QoS classifications and reserved bandwidth are required for Central Controller high-priority and PG high-priority communications. or deployment configuration. ICM Central Controller Private and Cisco CallManager PG Private Across Single Link A single link. shown in Figure 2-11. page 2-15. • • 126029 PG A PG B Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-21 .Chapter 2 Deployment Models Clustering Over the WAN • The link must be a dedicated circuit and not be tunneled across the highly available (HA) WAN. See Best Practices. carries both ICM Central Controller Private traffic and VRU/CM PG Private traffic. page 2-15. however. and not tunneled across. page 8-1. for more information on path diversity. call flow. see Bandwidth Provisioning and QoS Considerations. latency on failover must not exceed 500 ms.

page 2-23 Cisco CallManager Intra-Cluster Communications (ICC). the tool mentioned in the two previous sections produces a fairly accurate measurement of bandwidth needed for this communication.com/go/srnd Signaling communication must be guaranteed for the following connections: • • • • • • ICM Central Controller to Cisco CallManager PG. that using the tool for the link between the ICM Central Controller and IP IVR will produce accurate measurements. However. Cisco CallManager." IP IVR or ISN PG to IP IVR or ISN At this time. To achieve accurate measurements.html At this time. page 2-22 IP IVR or ISN PG to IP IVR or ISN. Testing has shown. Cisco IP Contact Center Enterprise Edition SRND 2-22 OL-7279-04 . no tool exists that specifically addresses communication between the IP IVR or ISN PG and the IP IVR or ISN. Bandwidth consumed between the ICM Central Controller and IP IVR or ISN PG is very similar to the bandwidth consumed between the IP IVR or ISN PG and the IP IVR or ISN. Minimum total bandwidth required across the highly available WAN for all IPCC signaling is 2 Mbps.com/partner/WWChannels/technologies/resources/IPCC_resources. and CTI traffic. Highly Available WAN Bandwidth must be guaranteed across the highly available (HA) WAN for all ICM public. CTI. bandwidth must be guaranteed for any calls going across the highly available WAN. page 2-23 ICM Central Controller to Cisco CallManager PG Cisco provides a partner tool called the ACD/CallManager Peripheral Gateway to ICM Central Controller Bandwidth Calculator to assist in calculating the Cisco CallManager PG-to-ICM bandwidth requirement.com/partner/WWChannels/technologies/resources/IPCC_resources.cisco.cisco. ICM Public. page 2-22 PG to PG Test Other Side. The following sections detail bandwidth requirements for ICM Private. and Cisco CallManager intra-cluster communications (ICC).Chapter 2 Clustering Over the WAN Deployment Models Bandwidth and QoS Requirements for IPCC Clustering Over the WAN Bandwidth must be provisioned to properly size links and set reservations within those links. Additionally. you have to make a substitution in one field: the field "Average number of RUN VRU script nodes" should be treated as "Number of ICM script nodes that interact with ISN.cisco. page 2-23 CTI Server to CTI OS. however. no tool exists that specifically addresses communication between the ICM Central Controller and the ISN PG. Additional information regarding QoS design and provisioning can be found in the QoS design guides available at http://www.html ICM Central Controller to IP IVR or ISN PG Cisco also provides a partner tool to compute bandwidth needed between ICM Central Controller and the IP IVR PG. This tool is available to Cisco partners and Cisco employees at the following link: http://www. page 2-22 ICM Central Controller to IP IVR or ISN PG. This tool is available online at http://www.

000 kbps (2 Mbps) per 10.000 BHCA. total bandwidth required would be double what the tool reports: once for ICM Central Controller to IP IVR or ISN PG and once for IP IVR or ISN PG to IP IVR ISN.5 Mbps (T1). For this model. you can use the following formula to calculate the required bandwidth: Link Size BHCA ∗ 200 = bps ICM Private WAN Table 2-1 is a worksheet to assist with computing the link and queue sizes.html If the IP IVR or ISN PGs are split across the WAN.Chapter 2 Deployment Models Clustering Over the WAN The tool is available to Cisco partners and Cisco employees at http://www. This requirement assumes proper design and deployment based on the recommendations in this IPCC design guide.000 BHCA. possibly exceeding the defined requirements. More specifically.com/partner/WWChannels/technologies/resources/IPCC_resources. the following simple formula can be used to compute worst-case bandwidth requirements: • With no Extended Call Context (ECC) or Call Variables: BHCA ∗ 20 = bps • With ECC and/or Call Variables BHCA ∗ (20 + ((Number of Variables ∗ Average Variable Length) / 40) = bps Example: With 10. The bandwidth that must be reserved is approximately 2. PG to PG Test Other Side PG-to-PG public communication consists of minimal "Test other Side" messages and consumes approximately 10 kbps of bandwidth per PG pair. Note Minimum link size in all cases is 1. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-23 .000 ∗ 40 = 400. Definitions and examples follow the table. Inefficient design (such as "ingress calls to Site 1 are treated in Site 2") will cause additional intra-cluster communications. A bandwidth queue should be used to guarantee availability for this worst case. CTI Server to CTI OS The worst case for bandwidth utilization across the WAN link between the CTI OS and CTI Server occurs when the CTI OS is remote from the CTI Server.cisco.000 BHCA and 20 ECC variables of average length 40: 10.000 ∗ (20 + ((20 ∗ 40) / 40) = 10. This amount is significantly higher with IPCC due to the number of call redirects and additional CTI/JTAPI communications encompassed in the intra-cluster communications.000 bps = 400 kbps Cisco CallManager Intra-Cluster Communications (ICC) The Cisco IP Telephony Solution Reference Network Design (SRND) guide states that 900 kbps must be reserved for every 10.

including conferences and transfers. 10. For example. For example. 10.000 effective BHCA. with 10% conferences or transfers.000 BHCA ingress calls. with all of them receiving treatment and 40% being queued. use the first row for Router/Logger requirements and the bottom three (out of four) rows added together for PG Private requirements. If separate links are used. would be 14.9 ∗ 0.9 ∗ 0. whichever technology is used in the implementation. • IP IVR PG This value is the total BHCA for call treatment and queuing. Effective BHCA (effective load) on all similar components that are split across the WAN is defined as follows: • Router + Logger This value is the total BHCA on the call center. Total PG High-Priority Queue Size If one dedicated link is used between sites for private communication. would be 14. 10.000 BHCA ingress with 10% conferences or transfers would be 11.000 effective BHCA.Chapter 2 Clustering Over the WAN Deployment Models Table 2-1 Worksheet for Calculating Private Bandwidth Component Router + Logger Multiplication Effective BHCA Factor ∗ 30 Recommended Link Multiplication Factor ∗ 0.9 ∗ 60 ∗ 120 ∗ ((Number of Variables ∗ Average Variable Length) / 40) Total Link Size ∗ 0. 10. • IP IVR or ISN Variables This value represents the number of Call and ECC variables and the variable lengths associated with all calls routed through the IP IVR or ISN. This assumes that each call comes into a route point and is eventually sent to an agent. with all of them receiving treatment and 40% being queued. Cisco IP Contact Center Enterprise Edition SRND 2-24 OL-7279-04 .000 Effective BHCA. add all link sizes together and use the Total Link Size at the bottom of Table 2-1.8 Recommended Queue Total Router+Logger High-Priority Queue Size Cisco CallManager PG IP IVR PG ISN PG IP IVR or ISN Variables ∗ 100 ∗ 0.000 BHCA ingress calls coming into a route point and being transferred to agents.000 effective BHCA.000 BHCA ingress calls. would be 11. 100% treatment is assumed in the calculation.9 Add these three numbers together and total in the shaded box below to get the PG High-Priority Queue size. one for Router/Logger Private and one for PG Private. • ISN PG This value is the total BHCA for call treatment and queuing coming through an ISN. For example. For example. • Cisco CallManager PG This value includes all calls that come through ICM Route Points controlled by Cisco CallManager and/or that are ultimately transferred to agents.

888. There are four IP IVRs used to treat and queue the calls.550.220.Chapter 2 Deployment Models Clustering Over the WAN Example of a Private Bandwidth Calculation Table 2-2 shows an example calculation for a combined dedicated private link with the following characteristics: • • • • • • Table 2-2 BHCA coming into the contact center is 10.000 ∗ 30 Recommended Link 330. with high-priority bandwidth queue of 297.000 1.5 Mb.550. as defined earlier).000 Multiplication Factor ∗ 0.000 bps If this example were implemented with two separate links. There is one Cisco CallManager PG pair for a total of 900 agents. the results are as follows: • • • Total Link = 2.000 For the combined dedicated link in this example.000 Variables ∗ Average Variable Length) / 40) Total Link Size Add these three numbers together and total in the shaded box below to get the PG High-Priority Queue size.000.000 bps Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-25 .9 756.000 ∗ 0.9 ∗ 0. Router/Logger private and PG private. 100% of calls are treated by IP IVR and 40% are queued.000 Total Router+Logger High-Priority Queue Size Cisco CallManager PG IP IVR PG ISN PG IP IVR or ISN Variables 11.000 14.888.000 ∗ 60 ∗ 120 840.000 bps.000 bps PG high-priority bandwidth queue of 1.000 bps PG link of 2.000 ∗ 100 1.9 ∗ 0.100.000 0 14. All calls are sent to agents unless abandoned. Calls have ten 40-byte Call Variables and ten 40-byte ECC variables.000 bps (actual minimum link is 1. 10% of calls to agents are transfers or conferences.888. the link sizes and queues would be as follows: • • Router/Logger link of 330.8 Recommended Queue 297. Total PG High-Priority Queue Size 2.000 0 252.9 880.000 ∗ ((Number of 280.000 0 ∗ 0.000 bps Router/Logger high-priority bandwidth queue of 297. Example Calculation for a Combined Dedicated Private Link Component Router + Logger Multiplication Effective BHCA Factor 11. with one PG pair supporting them. with high-priority bandwidth queue of 1.

page 2-15. major connectivity issues. When using distributed VXML gateways and ISN. and this scenario is covered in subsequent sections. the gateways must fail-over from one site to another if their primary site is lost. For illustrations of the deployment models described in this section. Failover times can range from 1 to 60 seconds for agents. refer to the figures shown previously for Clustering Over the WAN. and calls coming in to the remote gateways during those 30 seconds will be lost. among other things. power issues. Cisco IP Contact Center Enterprise Edition SRND 2-26 OL-7279-04 . If the HA WAN is dual-path and fully redundant. This failover takes approximately 30 seconds. This will cause both components to switch to simplex mode as described above. and agent desktop server used. and failure of the highly available WAN is considered outside the bounds of what would normally happen. This section discusses what happens in this unlikely scenario. The stability of the highly available (HA) WAN is extremely critical in this deployment model. as if the site were switched off. This situation will not cause any call loss or failure. This can result from natural disasters. When using a combined private link. the non-active PG will go out-of-service. a failure of this type would be highly unusual. one ICM Router will go out-of-service and the other ICM Router will then be running in simplex mode until the link is reinstated.Chapter 2 Clustering Over the WAN Deployment Models Failure Analysis of IPCC Clustering Over the WAN This section describes the behavior of clustering over the WAN for IPCC during certain failure situations. Variations are due to agent count. ICM Central Controller and PG private connections will be lost if the link is lost. it is not considered a site loss but rather a partial connectivity loss. all phones and agent desktops will immediately switch to the second central site and begin processing calls. and human error. If a central site retains some but not all connectivity. Connectivity to Central Site from Remote Agent Site If connectivity to one of the central sites is lost from a remote agent site. This situation will not cause any call loss or failure. Failover typically takes between 1 and 60 seconds. This situation will not cause any call loss or failure. When an entire central site has completely lost IPCC clustering over the WAN. a highly available (HA) WAN should not fail under normal circumstances. phone registration location. remote agents will fail-over properly to the redundant site. Highly Available WAN Failure By definition. If the private connection between PG side A and PG side B should fail. as it should be. causing the active PG to run in simplex mode until the link is reinstated. Private Connection Between Site 1 and Site 2 If the private connection between ICM Central Controller sides A and B should fail. Entire Central Site Loss Loss of the entire central site is defined as the loss of all communications with a central site.

The Cisco Voice and Video Enabled IPSec VPN (V3PN) ADSL or Cable connection uses a Cisco 830 Series router as an edge router to the broadband network. Firewall. the Cisco CallManager cluster becomes split. This causes ICM to immediately log out all agents with phones that are no longer visible. and Firewall (and other security functions). This model supports dynamic IP addressing via Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol over Ethernet (PPPoE). The primary result from this occurrence is that ICM loses contact with half of the agent phones. IPCC home agents and home family users can securely share broadband Cable and DSL connections. or customer relationship management (CRM) desktops. Quality of Service (QoS) to the edge.Chapter 2 Deployment Models Remote Agent Over Broadband If the HA WAN is lost for any reason. with authentication of IPCC corporate users providing access to the VPN tunnel. Advantages • • • • • Remote agent deployment results in money saved for a contact center enterprise. and they can access those features in exactly the same way This model provides high-quality voice using IP phones. and a building-block approach to high scalability that can support thousands of home agents. A remote agent can be deployed with standard IPCC agent desktop applications such as Cisco CTI OS. The Broadband Agent Desktop "Always on" connection is a secure extension of the corporate LAN in the home office. thereby increasing return on investment (ROI). This section outlines the IPCC Remote Agent solution that can be deployed using a desktop broadband asymmetric digital subscriber line (ADSL) or Cable connection as the remote network. The home agent solution utilizes the low-cost Cisco 831 Series router. Remote Agent Over Broadband An IPCC enterprise might want to deploy their network with support for remote at-home agents using a Cisco IP Phone. is encrypted with the Triple Data Encryption Standard (3DES). ICM is in communication with only half of the cluster and cannot communicate with or see any phones registered on the other half. This model works with ADSL or Cable broadband networks. At-home agents have access to the same IPCC applications and most IPCC features in their home office as when they are working at the IPCC Enterprise contact center. Network Address Translation (NAT). including data and voice. high availability. with simultaneous data to the agent desktop via existing broadband service. thus reducing the number of devices to be managed. The Cisco 831 Series router provides VPN tunnel origination. All traffic. IOS Intrusion Detection System (IDS). • • • • • • • • Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-27 . The Remote Agent router can be centrally managed by the enterprise using a highly scalable and flexible management product such as CiscoWorks. Encryption. The Cisco 830 Series router provides the remote agent with V3PN. and QoS on the broadband network link to the IPCC campus. These agents cannot log back in until the highly available WAN is restored or their phones are forced to switch cluster sides. The remote agent solution is based on Cisco IOS VPN Routers for resiliency. Remote agent V3PN aggregation on the campus is provided via LAN to LAN VPN routers. Cisco Agent Desktop.

com/go/v3pn http://www. then a transcoder must be set up to enable outside callers to receive MoH.cisco.cisco. Remote agent round-trip delay to the IPCC campus is not to exceed 180 ms for ADSL or 60 ms for Cable. Home agent broadband bandwidth requires a minimum of 256 kbps upload speed and 1.4 Mbps download speed for ADSL. The remote agent’s PC requires Windows XP Pro for the operating system. otherwise the agent will not be able to connect to a CTI OS server.729 codec. however. the home agent can encounter voice quality problems such as clipping. If you are deploying Cable. This is the recommended solution even for pure IP Telephony deployments. There is no loss of conference voice quality using a DSP conference bridge. The Remote Agent over Broadband solution is supported only with centralized IPCC and Cisco CallManager clusters. Implement fault and performance management tools such as NetFlow. Cisco recommends that you configure the conference bridge on a DSP hardware device. If the Music on Hold server is not set up to stream using a G. XP Remote Desktop Control must be installed. Only one remote agent per household is supported. and IP phone. The Cisco 7960 IP Phone requires a power supply. Before actual deployment.cisco. conference bridge problems. • • • • • • • • • • • • • • Cisco IP Contact Center Enterprise Edition SRND 2-28 OL-7279-04 .729 with minimum bandwidth limits. The remote agent's workstation and IP phone must be set up to use Dynamic Host Configuration Protocol (DHCP).com/go/srnd • Configure remote agent IP phones to use G. DNS entries can be dynamically updated or entered as static updates. Longer delay times can result in voice jitter. When the link is back up.711 is 512 kbps upload speed. This task will require remote agent training. Best Practices • Follow all applicable V3PN and Business Ready Teleworker design guidelines outlined in the documentation available at: http://www. and 1 Mbps download for Cable. then take into account peak usage times.711 codec. The minimum bandwidth to support G. Cisco 831 Series router. Home agents can have the same extension type as campus agents. The Cisco 831 Series router does not supply power to the IP Phone. Only unicast Music on Hold (MoH) streams are supported. make sure that the bandwidth is correct. Higher quality voice can be achieved with the G. and delayed agent desktop screen pops. you might have to reset your ADSL or Cable modem.Chapter 2 Remote Agent Over Broadband Deployment Models • • This model can be deployed as part of an existing Cisco CallManager installation. There might be times when the ADSL or Cable link goes down. If link speeds fall below the specified bandwidth. Wireless access points are supported. and Internetwork Performance Monitor (IPM). In addition. There must be a Domain Name System (DNS) entry for the remote agent desktop. their use is determined by the enterprise security polices for remote agents. Service Assurance Agent (SAA).com/go/teleworker http://www.

and voice recording with regard to home agent IP phones. there are supervisor limitations to silent monitoring. Only IP phones that are compatible with Cisco IPCC are supported.cisco. Supervisors are capable of sending and receiving only text messages.htm – Compatibility Matrix at http://www.Broadbandreports. barge in. From this website. barge-in. Desktop-based monitoring is applicable only with IPCC Enterprise edition. CTI OS home and campus supervisors can send and receive text messages. For compatibility information. • Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-29 . but not record home agents. you can execute a test that will benchmark the home agent's line speed (both upload and download) from a test server.” and also log out home agents. Otherwise.cisco.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/apps_3_5/english/admn_ap p/rn35_2.pdf • You can find a test for the broadband line speed at http://www.com/univercd/cc/td/doc/product/icm/ccbubom/index. make an agent “ready. CTI OS Supervisor will not be able to voice-monitor the agent phone.pdf – Release Notes for IPCC Express at http://www. intercept. Connect the agent desktop to the RJ45 port on the back of the IP phone. CTI OS Supervisor home and campus supervisors can silently monitor.com. Cisco Agent Desktop (Enterprise and Express) home and campus supervisors cannot voice-monitor home agents. and they can see which home agents are online and can log them out. refer to the following documentation: – Bill of Materials at • • • • http://www. and intercept.Chapter 2 Deployment Models Remote Agent Over Broadband • For Cisco Supervisor Desktop.com.com/application/pdf/en/us/guest/products/ps1844/c1609/ccmigration_09186 a008031a0a7. The email alias for V3PN questions is: ask-ese-vpn@cisco. Desktop-based monitoring is not supported for IPCC Express with Cisco Agent Desktop.

service providers are not providing QoS. the remote agent’s IP phone and workstation are connected via the VPN tunnel to the main IPCC campus. (See Figure 2-12.) Figure 2-12 Remote Agent with IP Phone Deployed via the Business Ready Teleworker Solution Cisco IP phone IP IPCC Corporate Network Broadband Internet VPN Head-End router 126030 CTI data Broadband modem Encrypted VPN tunnel Cisco 831 Series remote router Advantages • • • • High-speed broadband enables cost-effective office applications Site-to-site "always on" VPN connection Advanced security functions allow extension of the corporate LAN to the home office Supports full range of converged desktop applications.Chapter 2 Remote Agent Over Broadband Deployment Models Remote Agent with IP Phone Deployed via the Business Ready Teleworker Solution In this model. Minimum broadband speed supported is 256 kbps upload and 1.4 Mbps download for ADSL. IP phone must be configured to use G. The Cisco 7200 VXR and Catalyst 6500 IPSec VPN Services Module (VPNSM) offer the best LAN-to-LAN performance for agents. QoS is enabled only at the Cisco 831 Router edge. Enable security features on the Cisco 831 Series router. Agent workstation must have 500 MHz. Redirect on no answer (RONA) should be used when a remote agent is logged in and ready but is unavailable to pick up a call. Currently. 512 MB RAM or greater.711 on minimum broadband speeds. The remote agent's home phone must be used for 911 calls. Customer calls routed to the remote agent are handled in the same manner as campus agents. including CTI data and high-quality voice Best Practices • • • • • • • • • Minimum broadband speed supported is 256 kbps upload and 1.0 Mbps download for cable. Cisco IP Contact Center Enterprise Edition SRND 2-30 OL-7279-04 .

the Campaign Manager (for configuration and customer records). Cisco CallManager (Skinny Client Control Protocol connection for placing and transferring calls). and the Media Routing PG (to reserve agents). Maximum of 300 agents (any mixture of inbound and outbound agents) on a PG when the CTI OS on the PG server is configured for no more than 200 agents. Figure 2-13 illustrates the model for the IPCC Outbound Option with more than 200 agents. The Cisco Outbound Option enables the multi-functional contact center to take advantage of the ICM enterprise management. • • A Media Routing PIM is required for each Dialer to reserve agents for outbound use. Sizing Information • • Maximum of 200 agents (any mixture of inbound and outbound agents) on a fully coresident configuration (Outbound Option Dialer. The Dialer is a pure software solution that does not require telephony cards. – The Import process is responsible for importing customer records and Do Not Call records into the system. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-31 . allowing contact center managers in need of outbound campaign solutions to take advantage of the enterprise view that Cisco ICM Enterprise and Cisco IPCC Enterprise maintain over agent resources. Description and Characteristics • • The IP Dialer uses virtual IP phones to place outbound calls through a voice gateway via the Cisco CallManager. IPCC PG.Chapter 2 Deployment Models IPCC Outbound (Blended Agent) Option IPCC Outbound (Blended Agent) Option The ability for agents to handle both inbound and outbound contacts offers a way to optimize contact center resources. CTI Server. – The Dialer processes. and CTI OS on a single server). The Outbound Option solution consists of three main processes: – The Campaign Manager process resides on the Side-A Logger and is responsible for sending configuration and customer records to all the Dialers in the enterprise. Multiple Dialer processes may be connected to the Campaign Manager server at multiple sites. Outbound Option dialers maintain connections to the CTI Server (for agent CTI control).

This option incorporates flexible outbound mode control by using the ICM script editor to control type of outbound mode and percentage of agents within a skill to use for outbound activity.0 and later provide the Enhanced Call Progress Analysis feature.Chapter 2 IPCC Outbound (Blended Agent) Option Deployment Models Figure 2-13 IPCC Outbound Option with More Than 200 Agents ICM Peripheral Gateway 5A Media Routing Blended Agent PIM (1) ICM Peripheral Gateway 5B Media Routing Blended Agent PIM (1) PSTN Voice Network ICM Peripheral Gateway 2A CallManager PIM (1) CTI Server ICM Peripheral Gateway 2B CallManager PIM (1) CTI Server Private LAN Cross-over Cable ICM CTIOS Server 2A ICM CTIOS Server 2B Private LAN Cross-over Cable Cisco router/ Voice Gateway Ethernet Converged Visible LAN V IP IP M M Cisco 7960 Cisco 7940 ICM Dialer 1 M M IP Data WAN CCMA-PUB/ TFTP M CCMBSUB IPCC Agent PC ICM Dialer 2 IPCC Agent PC 126032 CCMCBACKUP SUB CRS1 24 Ports CRS2 24 Ports Advantages The Cisco Outbound Option Dialer solution allows an agent to participate in outbound campaigns as well as inbound calls by utilizing a pure software IP-based dialer. including answering machine detection. the main benefits of the IPCC Outbound Option are: • • • • • • • IPCC Outbound Option has enterprise-wide dialing capability. Transfer to IVR mode (agent-less campaigns) and Direct Preview mode are available in IPCC Release 6.0 and later. Cisco IP Contact Center Enterprise Edition SRND 2-32 OL-7279-04 . This option provides centralized management and configuration via the ICM Admin workstation. In summary. This option provides integrated webview reporting with outbound specific reporting templates. The Campaign Manager server is located at the central site. IPCC Release 6. This option provides true call-by-call blending of inbound and outbound calls. with IP Dialers placed at multiple call center sites.

Chapter 2

Deployment Models IPCC Outbound (Blended Agent) Option

Best Practices

Follow these guidelines and best practices when implementing the IPCC Outbound Option:
• •

A media routing PG is required, and a media routing PIM is required for each Dialer. An IP Dialer may be installed on an IPCC PG server for a total blended agent count of 200 (either inbound, outbound, or blended). Multiple Dialers located at a single peripheral do provide some fault tolerance but are not a true hot-standby model. IP Dialers support only the G.711 audio codec for customer calls. Although outbound agents may be placed within a region that uses the G.729 codec, the codec switchover can add up to 1.5 seconds to the transfer time between customer and agent and is therefore not recommended. IP Dialers should be located in close proximity to the Cisco CallManager cluster where the Dialers are registered. Using the Cisco Media Termination phones with the outbound option might introduce an additional 0.5 second delay in transferring customer calls to the agent. The following gateways have been tested with IPCC Outbound Option Dialers:
– Cisco AS5300, AS5350, and AS5400 Series – Cisco 6608

• • •

• •

All Outbound option dialers at a particular peripheral should have the same number of configured ports. Outbound Option dialers perform a large number of call transfers, which increases the performance load on the Cisco CallManager server. Ensure proper Cisco CallManager server sizing when installing Outbound Option dialers. Also, proper Dialer call throttling should be enabled to prevent overloading the Cisco CallManager server. For proper throttling values for your particular Cisco CallManager server, refer to the Outbound Option Setup and Configuration Guide, available at http://www.cisco.com/univercd/cc/td/doc/product/icm/icmentpr/icm60doc/icm6out/

For complete information on installing and configuring the Outbound software, see:
• •

Cisco ICM/IP Contact Center Enterprise Edition Outbound Option Setup and Configuration Guide Cisco ICM/IP Contact Center Enterprise Edition Outbound Option User Guide

Both of these documents are available online at http://www.cisco.com/univercd/cc/td/doc/product/icm/icmentpr/icm60doc/icm6out/

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

2-33

Chapter 2 Traditional ACD Integration

Deployment Models

Traditional ACD Integration
For enterprises that want to integrate traditional ACDs with their IPCC deployment, several options exist. For enterprises that want to load-balance calls between a traditional ACD site and an IPCC site, a pre-routing Network Interface Controller (NIC) could be added. (See Figure 2-14.) This requires that the ICM have a NIC that supports the PSTN service provider. In this scenario, the PSTN will query the ICM Central Controller (via the NIC) to determine which site is best, and the ICM response back to the PSTN will instruct the PSTN where (which site) to deliver the call. Any call data provided by the PSTN to the ICM will be passed to the agent desktop (traditional ACD or IPCC). In order to transfer calls between the two sites (ACD site and IPCC site), a PSTN transfer service could be used. Use of a PSTN transfer service avoids any double trunking of calls at either site. An alternative to using a PSTN transfer service is to deploy TDM voice circuits between the traditional ACD and IPCC voice gateways. In that environment, any transfer of a call back to the original site will result in double trunking between the two sites. Each additional transfer between sites will result in an additional TDM voice circuit being utilized.
Figure 2-14 Integrating a Traditional ACD with an IPCC Site

NIC PSTN PG/CTI server

ICM Central Controller

ACD

IP IVR

PG/CTI server

V
M

CallManager

IP IP voice TDM voice CTI/Call control data

IP

IP

IP phones and IPCC agent desktops

An alternative to pre-routing calls from the PSTN is to have the PSTN deliver calls to just one site or to split the calls across the two sites according to some set of static rules provisioned in the PSTN. When the call arrives at either site, either the traditional ACD or the Cisco CallManager will generate a route request to the ICM to determine which site is best for this call. If the call needs to be delivered to an agent at the opposite site from where the call was originally routed, then TDM circuits between sites will be required. Determination of where calls should be routed, and if and when they should be transferred between sites, will depend upon the enterprise business environment, objectives, and cost components.

Cisco IP Contact Center Enterprise Edition SRND

2-34

76612

OL-7279-04

Chapter 2

Deployment Models Traditional IVR Integration

Traditional IVR Integration
There are numerous ways that traditional IVRs can be integrated into an IPCC deployment. Determination of which way is best will depend upon many factors that are discussed in the following sections. The primary consideration, though, is determining how to eliminate or reduce IVR double trunking when transferring the call from the IVR.

Using PBX Transfer
Many call centers have existing traditional IVR applications that they are not prepared to rewrite. In order to preserve these IVR applications, but yet integrate them into an IPCC environment, the IVR must have an interface to the ICM. (See Figure 2-15.) There are two versions of the IVR interface to the ICM. One is simply a post-routing interface, which just allows the IVR to send a post-route request with call data to the ICM. The ICM will return a route response instructing the IVR to transfer the call elsewhere. In this scenario, the traditional IVR will invoke a PBX transfer to release its port and transfer the call into the IPCC environment. Any call data passed from the IVR will be passed by the ICM to the agent desktop or IP IVR. The other IVR interface to the ICM is the serial port communications interface (SCI). The SCI allows the IVR to receive queuing instructions from the ICM. In the PBX model, the SCI is not required. Even if the IVR has the SCI interface, Cisco still recommends that you deploy IP IVR for all call queuing because this prevents any additional utilization of the traditional IVR ports. In addition, use of the IP IVR for queuing provides a way to requeue calls on subsequent transfers or RONA treatment.
Figure 2-15 Traditional IVR Integration Using PBX Transfer

PBX PSTN

IVR

PG

ICM Central Controller

IP IVR

PG/CTI server

V
M

CallManager

IP IP voice TDM voice CTI/Call control data

IP

IP

IP phones and IPCC agent desktops

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

76613

2-35

Chapter 2 Traditional IVR Integration

Deployment Models

Using PSTN Transfer
This model is very similar to the previous model, except that the IVR invokes a PSTN transfer (instead of a PBX transfer) so that the traditional IVR port can be released. (See Figure 2-16.) Again, the IP IVR would be used for all queuing so that any additional occupancy of the traditional IVR ports is not required and also so that any double trunking in the IVR is avoided. Any call data collected by the traditional IVR application will be passed by the ICM to the agent desktop or IP IVR.
Figure 2-16 Traditional IVR Integration Using PSTN Transfer

IVR PSTN

PG

ICM Central Controller

IP IVR

PG/CTI server

V
M

CallManager

IP IP voice TDM voice CTI/Call control data

IP

IP

IP phones and IPCC agent desktops

Cisco IP Contact Center Enterprise Edition SRND

2-36

76614

OL-7279-04

in order to queue the call on the IP IVR. a second traditional IVR port would be used.) Unlike the previous model. By performing the initial queuing on the traditional IVR. where most callers are completely self-served in the traditional IVR and only a very small percentage of callers ever need to be transferred to an agent. if the traditional IVR has an SCI interface. then the IVR will just generate a post-route request to the ICM to determine where the call should be transferred.Chapter 2 Deployment Models Traditional IVR Integration Using IVR Double Trunking If your traditional IVR application has a very high success rate. (See Figure 2-17. then it might be acceptable to double-trunk the calls in the traditional IVR for that small percentage of calls. If the traditional IVR does not have an SCI interface. any subsequent queuing as a result of transfers or RONA treatment must be done on the IP IVR to avoid any double trunking. However. The reason this is beneficial is that. All queuing in that scenario would have to be done on the IP IVR. then the initial call queuing could be done on the traditional IVR. only one traditional IVR port is used during the initial queuing of the call. Figure 2-17 Traditional IVR Integration Using IVR Double Trunking IVR PSTN PG ICM Central Controller IP IVR PG/CTI server V M CallManager IP IP voice TDM voice CTI/Call control data IP IP IP phones and IPCC agent desktops Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 76615 2-37 .

trunk. if a small percentage of traditional IVR applications still exist for very specific scenarios. then the IVR could be connected to a second voice gateway. then a second IVR port. Figure 2-18 Traditional IVR Integration Using Cisco CallManager Transfer and IVR Double Trunking IVR PSTN PG ICM Central Controller IP IVR PG/CTI server V M CallManager IP IP voice TDM voice CTI/Call control data IP IP IP phones and IPCC agent desktops Cisco IP Contact Center Enterprise Edition SRND 2-38 76616 OL-7279-04 . Care should be taken to ensure that transfer scenarios do not allow multiple loops to be created because voice quality could suffer.Chapter 2 Traditional IVR Integration Deployment Models Using Cisco CallManager Transfer and IVR Double Trunking Over time. However. it might become desirable to migrate the traditional IVR applications to the IP IVR. Cisco CallManager could route specific DNs to the traditional IVR or let the ICM or IP IVR determine when to transfer calls to the traditional IVR. and voice gateway port would be used for the duration of the call.) Calls arriving at the voice gateway from the PSTN would be routed by Cisco CallManager. If calls in the traditional IVR need to be transferred to an IPCC agent. (See Figure 2-18.

but not all failures can be made transparent. The type and number of resources impacted will depend on how stringent your requirements are and which design characteristics you choose for the various IPCC components. page 3-17 Cisco Collaboration Server Option. page 3-5 Cisco CallManager and CTI Manager Design Considerations. system administration. page 3-13 Multi-Channel Design Considerations (Cisco Email Manager Option and Cisco Collaboration Server Option). page 3-38 Cisco Agent Desktop Considerations. This chapter contains the following sections: • • • • • • • • • • • • • • Designing for High Availability.C H A P T E R 3 Design Considerations for High Availability This chapter covers several possible IPCC failover scenarios and explains design considerations for providing high availability of system functions and features in each of those scenarios. page 3-15 Cisco Email Manager Option. and it is important to design each deployment in such a way that a failure will impact the fewest resources in the call center. Cisco IPCC is a sophisticated solution designed for mission-critical call centers. page 3-31 CTI OS Considerations. including the network infrastructure. page 3-20 Understanding Failure Recovery. The success of any IPCC deployment requires a team with experience in data and voice internetworking. page 3-39 Other Considerations. page 3-1 Data Network Design Considerations. A good IPCC design will be tolerant of most failures (defined later in this section). and IPCC application configuration. page 3-7 IP IVR (CRS) Design Considerations. page 3-18 Cisco IPCC Outbound Option Design Considerations. page 3-19 Peripheral Gateway Design Considerations. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-1 . page 3-11 Internet Service Node (ISN) Design Considerations. page 3-39 Designing for High Availability Cisco IPCC is a distributed solution that uses numerous hardware and software components.

Figure 3-1 shows a high-level design for a fault-tolerant IPCC single-site deployment. available at http://www. with the exception of the intermediate distribution frame (IDF) switch for the IPCC agents and their phones.Chapter 3 Designing for High Availability Design Considerations for High Availability Before implementing IPCC.com/go/srnd For assistance in planning and designing your IPCC solution. use careful preparation and design planning to avoid costly upgrades or maintenance later in the deployment cycle. different building floors or different cities). CTI data. because it is better to distribute the agents among different IDF switches for load balancing and for geographic separation (for example. In summary. with future scalability in mind for all IPCC sites. but only with the main distribution frame (MDF) switches. all calls should be routed to other available agents in a separate Cisco IP Contact Center Enterprise Edition SRND 3-2 OL-7279-04 126155 WedView Reporting Client . consult your Cisco or certified Partner Systems Engineer (SE). Figure 3-1 IPCC Single-Site Design for High Availability T1 lines Public network T1 lines IDF switch 1 IDF switch 2 Voice gateway 1 Voice gateway 2 Gatekeepers V V Firewall TDM access MDF switch 1 MDF switch 2 Agent 1 PC IPCC agents IP IP Cisco CallManager cluster Agent 2 PC Publisher Sub 1 M M M Sub 2 IP IVR 1 IP IVR group IP IVR 2 Corporate LAN AW A CTI OS A CTI OS B CM PG A CM PG B VRU PG A VRU PG B AW B CTI server A CTI server B ICM A ICM B ICM central controllers Call control.cisco. Always design for the worst possible failure scenario. IP messaging TDM voice lines Ethernet lines In Figure 3-1. each component in the IPCC site is duplicated for redundancy and connected to all of its primary and backup servers. The IDF switches do not interconnect with each other. plan ahead and follow all the design guidelines and recommendations presented in this guide and in the Cisco IP Telephony Solution Reference Network Design (SRND) guide. If an IDF switch fails.

each call should be handled in one of the following ways: • • • • Routed and answered by an available IPCC agent Sent to an available IP IVR (CRS) or ISN port Answered by the Cisco CallManager AutoAttendant Prompted by an IP IVR (CRS) or ISN announcement that the call center is currently experiencing technical difficulties. any IPCC site can lose half of its systems and still be operational.cisco. With this type of design. as illustrated in Figure 3-2.Chapter 3 Design Considerations for High Availability Designing for High Availability IDF switch or to an IP IVR (CRS) queue.com/go/srnd If designed correctly for high availability and load balancing. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-3 . no matter what happens in the IPCC site. and to call back later The components in Figure 3-1 can be rearranged to form two connected IPCC sites. Follow the design recommendations for a single-site deployment as documented in the Cisco IP Telephony Solution Reference Network Design (SRND) guide. available at http://www.

all you have to do is to duplicate the first side and cross-connect all the corresponding parts. starting with the physical layer first) that divides the design into segments that can be deployed in separate stages. These sections use a bottom-up model (from a network model perspective. To implement IPCC high availability. CTI data. Side A and Side B are basically mirror images of each other. IP messaging TDM voice lines Ethernet lines WedView Reporting Client WedView Reporting Client Figure 3-2 emphasizes the redundancy of the single site design in Figure 3-1. The following sections use Figure 3-1 as the model design to discuss issues and features that you should consider when designing IPCC for high availability. IP-IVR/ISN. with each Cisco Cisco IP Contact Center Enterprise Edition SRND 3-4 126156 OL-7279-04 . one of the main IPCC features to enhance high availability is its simple mechanism for converting a site from non-redundant to redundant. This chapter assumes that the IPCC failover feature is a critical requirement for all deployments. In fact. and therefore it presents only deployments that use a redundant (duplex) Cisco CallManager configuration. and ICM configurations for all IPCC deployments that require high availability. Cisco recommends using only duplex (redundant) Cisco CallManager.Chapter 3 Designing for High Availability Design Considerations for High Availability Figure 3-2 IPCC Single-Site Redundancy IPCC site side A T1 lines Public network T1 lines IDF switch 1 TDM access Agent 1 PC IP IP IVR 1 MDF switch 1 Publisher Subscriber 1 M M Voice gateway 1 V V IPCC site side B Voice gateway 2 IDF switch 2 MDF switch 2 Subscriber 2 M IP IVR 2 IP Agent 2 PC CM PG A VRU PG A CTI OS A CTI server A AW A ICM A ICM B CM PG B VRU PG B CTI OS B CTI server B AW B Call control.

This chapter focuses on how the voice gateways should be configured for high availability with the Cisco CallManager cluster(s). Each gateway should use the other Cisco CallManager as a backup in case its primary Cisco CallManager fails. deployments should follow the best practice of having no devices. Refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide (available at http://www. In addition. The bottom of the network infrastructure in the design supports the IPCC environment for data and voice traffic. then everything in the call center is prone to failure because all the servers and network devices depend on the network for communication. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide. including the PSTN. the data and voice networks must be a primary part of your solution design and the first stage for all IPCC implementations. The network. For more information on voice gateways and voice networks in general.cisco. Data Network Design Considerations The IPCC design shown in Figure 3-3 starts from a time division multiplexing (TDM) call access point and ends where the call reaches an IPCC agent. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-5 .cisco. the choice of voice gateways for a deployment is critical because some protocols offer more call resiliency than others. is the foundation for the IPCC solution. where possible. or CTI Manager services running on the Cisco CallManager publisher. CTI data. In a configuration with two voice gateways and one Cisco CallManager cluster. IP messaging TDM voice lines Ethernet lines Sub 1 M M M Sub 2 Corporate LAN 76602 Using multiple voice gateways avoids the problem of a single gateway failure causing blockage of all calls. Additionally. Therefore.Chapter 3 Design Considerations for High Availability Data Network Design Considerations CallManager cluster having at least one publisher and one subscriber.com/go/srnd Figure 3-3 High Availability in a Network with Two Voice Gateways and One Cisco CallManager Cluster T1 lines Public network T1 lines Voice gateway 1 Voice gateway 2 Gatekeepers V IDF switch 1 TDM access IDF switch 2 MDF switch 1 V MDF switch 2 Cisco CallManager cluster Publisher Firewall Call control. available at http://www.com/go/srnd) for details on setting up Cisco CallManager redundancy groups for backup. each gateway should register with a different primary Cisco CallManager to spread the workload across the Cisco CallManagers in the cluster. call processing. If the network is poorly design to handle failures.

If two voice gateways are deployed in this case. use the busyout-monitor interface voice-port configuration command.323 gateway. first decide how many simultaneous voice gateway failures are acceptable for the site. Thus. plan for the possible failure of a voice gateway and calculate the maximum number of trunks that may be in use on the remaining voice gateways registered with each CallManager server. The operational cost savings of fewer T1 lines may be greater than the one-time capital cost of additional voice gateways. then you must ensure that PSTN re-routing or overflow routing to the other trunk groups is configured for all dialed numbers. so you should compare the annual operating cost of the trunks (paid to the PSTN provider) against the one-time fixed cost of the voice gateways. If a voice gateway with a digital interface (T1 or E1) fails. assume the call center has a maximum BHCA that results in the need for four T1 lines. If five voice gateways are deployed. you can reduce the number of T1 lines required by adding more voice gateways. With standalone voice gateways. using more voice gateways will increase the cost of that component of the solution. then one T1 per voice gateway (total of five) would be enough to achieve the same level of availability. To remove the busyout monitor state on the voice port. and you can Cisco IP Contact Center Enterprise Edition SRND 3-6 OL-7279-04 . Every installation has different availability requirements and cost metrics. but using multiple voice gateways is often more cost-effective. Therefore. it is possible that the voice gateway itself is operational but that its communication paths to the Cisco CallManager servers are severed (for example. Loss of carrier level signaling causes the PSTN to busy out all trunks on that digital circuit. Parties at both ends of the line receive silence and. be sure enough trunks are available to handle the maximum busy hour call attempts (BHCA) when one or more voice gateways fail. Because the voice gateways register with a primary Cisco CallManager. From the PSTN perspective. thus preventing the PSTN from routing new calls to the failed voice gateway. In addition to the recurring operational costs of the T1 lines. the voice gateway automatically busies out all its trunks. During the design phase. then each voice gateway should be provisioned with four T1 lines (total of eight). you can determine the number of trunks required. an increase in the amount of traffic on a given voice gateway will result in more traffic being handled by its primary Cisco CallManager. Calls in progress do not survive because the Real-Time Transport Protocol (RTP) stream connection no longer exists. If three voice gateways are deployed. This prevents new calls from being routed to this voice gateway from the PSTN. it is a worthwhile design practice to perform this cost comparison. When the failed voice gateway comes back on-line and the circuits are back in operation. However. use the no form of this command. The more you distribute the trunks over multiple voice gateways. after a configurable timeout. If this occurs in the case of a H. the fewer trunks you will need. then the PSTN automatically stops sending calls to that voice gateway because the carrier level signaling on the digital circuit has dropped. when sizing the Cisco CallManager servers. You can set the Transmission Control Protocol (TCP) timeout parameter in the voice gateway. a failed Ethernet connection). Therefore. and the company has a requirement for no call blockage in the event of a single component (voice gateway) failure. if the trunks going to the multiple voice gateways are configured as a single large trunk group. For example. you should also factor in the one-time installation cost of the T1 lines to ensure that your design accounts for the most cost-effective solution. To place a voice port into a busyout monitor state. After you have determined the number of trunks needed. If all of the trunks are not grouped into a single trunk group within the PSTN. the PSTN service provider has to configure them in such a way that calls can be terminated onto trunks connected to all of the voice gateways (or at least more than one voice gateway). and the distribution of trunks across those voice gateways.Chapter 3 Data Network Design Considerations Design Considerations for High Availability When calculating the number of trunks from the PSTN. then two T1 lines per voice gateway (total of six) would be enough to achieve the same level of availability. then all calls will automatically be routed to the surviving voice gateways when one voice gateway fails. Based upon this requirement. the number of voice gateways used. When the voice gateway interface to the switch fails. calls are cleared. the PSTN automatically starts delivering calls to that voice gateway again. you can use the busyout-monitor interface command to monitor the Ethernet interfaces on a voice gateway.

which is explained later in this section). and CTI route points. there can be multiple CTI Manager services running on different Cisco CallManager servers in the cluster that are aware of each other (via the Cisco CallManager service. a service that 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.1.Chapter 3 Design Considerations for High Availability Cisco CallManager and CTI Manager Design Considerations also set a default timeout in Cisco CallManager. while the CTI Manager service acts as a router for all the CTI application requests for the system devices. The main function of the CTI Manager is to accept messages from external CTI applications and send them to the appropriate resource in the Cisco CallManager cluster. (Refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide for further details about the architecture of the CTI Manager. It basically acts as a switch for all the IP telephony resources and devices in the system. The JTAPI client library in Cisco CallManager Release 3. In addition. However. the trunks are automatically idled and the PSTN should begin routing calls to this voice gateway again (assuming the PSTN has not permanently busied out those trunks). The CTI Manager uses the Cisco JTAPI link to communicate with the applications. Some other services running on a Cisco CallManager server include TFTP. CTI ports.) The CTI Manager and Cisco CallManager are two separate services running on a Cisco CallManager server. Cisco CallManager and CTI Manager Design Considerations Cisco CallManager Release 3. It acts like a JTAPI messaging router. Cisco Messaging Interface.) The main function of the Cisco CallManager service is to register and monitor all the IP telephony devices. The calls are cleared by whichever timeout expires first. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-7 . Figure 3-4 illustrates some of the functions of Cisco CallManager and the CTI Manager. as in releases prior to 3. Some of the devices that can be controlled by JTAPI that register with the Cisco CallManager service include the IP phones. and Real-time Information Server (RIS) data collector services. (This is also explained later in detail.1 and above connects to the CTI Manager instead of connecting directly to the Cisco CallManager service. the CTI Manager does not directly communicate with the other CTI Managers in its cluster. The CTI Manager uses the same Signal Distribution Layer (SDL) signaling mechanism that the Cisco CallManager services in the cluster use to communicate with each other. When the voice gateway interface to the switch recovers.3(x) and later uses CTI Manager.

Figure 3-5 shows the flow of a device request to another Cisco CallManager in the cluster. If the device is not resident on its local Cisco CallManager subscriber. CTI Managers route only the external CTI application requests to the appropriate devices serviced by the local Cisco CallManager service on this subscriber. then the Cisco CallManager service forwards the application request to the appropriate Cisco CallManager in the cluster. 101 Cisco IP Contact Center Enterprise Edition SRND 3-8 76604 OL-7279-04 . SDL signaling is used only by the Cisco CallManager service to talk to the other Cisco CallManager services to make sure everything is in sync within the Cisco CallManager cluster. Figure 3-5 CTI Manager Device Request to a Remote Cisco CallManager Publisher (CTI Manager and CallManager) Subscriber ICM PG Request: IPCC agent ext. 100 IP phone ext.323 Skinny client control protocol (SCCP) IP IP IP IP IP IP 76603 The servers in a Cisco CallManager cluster communicate with each other using the Signal Distribution Layer (SDL) service. The CTI Managers in the cluster are completely independent and do not establish a direct connection with each other. 101 (CTI Manager and Cisco CallManager) Subscriber (CTI Manager and Cisco CallManager) Forward request Device not on local Cisco CallManager IP Device found IP IP phone ext.Chapter 3 Cisco CallManager and CTI Manager Design Considerations Design Considerations for High Availability Figure 3-4 Functions of Cisco CallManager and the CTI Manager Publisher (CTI Manager and CallManager) ICM PG SDL JTAPI Subscriber (CTI Manager and Cisco CallManager) IVR SDL Subscriber (CTI Manager and Cisco CallManager) JTAPI Softphone SCCP V MGCP H.

any CTI application can connect to any CTI Manager to perform its requests. If the first CTI Manager fails. (See Figure 3-6. while IP IVR (CRS) uses User 2. In addition. The Cisco CallManager PG logs into the CTI Manager using the JTAPI account User 1. the server CPU and memory usage will increase because the CTI application registers and monitors events on all the devices associated with the JTAPI user. it is best to load-balance devices (phones. and so forth) and CTI applications evenly across all the nodes in the Cisco CallManager cluster. the Cisco CallManager PG. sides A and B. keep in mind that every time a JTAPI connection is established with a CTI Manager (JTAPI user logs into a CTI Manager). the Voice Response Unit (VRU) Peripheral Gateway (PG) allows the administrator to input two CTI Managers. Therefore. The other side of the Cisco CallManager and VRU PG stays in hot-standby mode. To avoid overloading the available resources. make sure to allocate the CTI application devices so that they are local to the CTI Manager where the application is connected. primary and secondary. and the IP IVR (CRS).Chapter 3 Design Considerations for High Availability Cisco CallManager and CTI Manager Design Considerations It is important to load-balance devices and CTI applications evenly across all the nodes in the Cisco CallManager cluster. The CTI applications can use the same JTAPI user multiple times to log into separate CTI Managers. because the CTI Managers are independent. only one Cisco CallManager PG side allows the JTAPI user to register and monitor the user devices to conserve system resources in the Cisco CallManager cluster. in its JTAPI subsystem. given that the CTI Managers are independent from each other. and each server has one JTAPI connection to load-balance the CTI applications. one CTI Manager cannot pass the CTI application to another CTI Manager upon failure. The Cisco CallManager PG handles failover for the CTI Manager by using its two sides. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 76605 IP IP IP IP 3-9 . and it adds an extra layer of failover and redundancy at the CTI application level by allowing multiple connections to separate CTI Managers while using the same JTAPI user to maintain control.) Figure 3-6 CTI Application Device Registration Publisher (CTI Manager and CallManager) Subscriber ICM PG JTAPI user 1 logs in (CTI Manager and Cisco CallManager) Subscriber (CTI Manager and Cisco CallManager) IP IVR JTAPI user 2 logs in User 2 CTI ports Agent 1 Agent 2 Agent 3 Agent 4 Figure 3-6 shows two external CTI applications using the CTI Manager. However. Each subscriber has two phones to load-balance the calls. CTI Route Points. the external CTI application must implement the failover mechanism to connect to another CTI Manager in the cluster. However. However. waiting to be activated immediately upon failure of the active side. The external CTI applications use a JTAPI user account on the CTI Manager to establish a connection and assume control of the Cisco CallManager devices registered to this JTAPI user. ports. CTI Ports. which both log into the same JTAPI user upon initialization of the two CTI Managers. This feature allows you to load-balance the CTI application connections across the cluster. For example. gateways.

with all the call survivability capabilities considered for treating these calls.Chapter 3 Cisco CallManager and CTI Manager Design Considerations Design Considerations for High Availability Cisco CallManager and CTI Manager design should be the second design stage. thereby adding extra load to the remaining servers in the cluster. and deployment should occur in this same order. (See Figure 3-7. and CTI route points) evenly across all Cisco CallManagers.com/go/srnd Configuring ICM for CTI Manager Redundancy To enable Cisco CallManager support for CTI Manager failover in a duplex Cisco CallManager model.) Cisco IP Contact Center Enterprise Edition SRND 3-10 OL-7279-04 . CTI ports. Also be sure that all servers can handle the load for the worst-case scenarios. where they are the only remaining server in their cluster. Distribute Cisco CallManager devices (phones. make sure that a PSTN phone can call an IP phone and that this same IP phone can dial out to a PSTN phone. Before moving to the next design stage.) Assign the remaining CTI Manager to be the JTAPI service of the Cisco CallManager PG side B. Assign one of the CTI Managers to be the JTAPI service of the Cisco CallManager PG side A.) Designate two CTI Managers to be used for each side of the duplex Peripheral Gateway (PG). Also keep in mind that the Cisco CallManager cluster is the heart of the IPCC system.cisco. and any server failure in a cluster will take down two services (CTI and Cisco CallManager). The reason is that the IP telephony infrastructure must be in place to dial and receive calls using its devices before you can deploy any telephony applications. For more information on how to load-balance the Cisco CallManager clusters. and add subscribers to the group. (See Figure 3-7. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide. right after the network design stage. device registration. or CTI Manager use. (Publishers and TFTP servers should not be used for call processing. available at http://www. perform the following steps: Step 1 Step 2 Step 3 Step 4 Create a Cisco CallManager redundancy group.

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-11 126812 . if one of the Cisco CallManagers fails. the IP IVR associated with that particular Cisco CallManager will fail-over to the second Cisco CallManager. Figure 3-8 shows two IP IVR (CRS) servers configured for redundancy within one Cisco CallManager cluster. The IP IVR group should be configured so that each server is connected to a different CTI Manager service on different Cisco CallManager subscribers in the cluster for load balancing and high availability. Cisco CallManager PIM 1 PG side B. Then. Using the redundancy feature of the JTAPI subsystem in the IP IVR server.Chapter 3 Design Considerations for High Availability IP IVR (CRS) Design Considerations Figure 3-7 Assigning CTI Managers for PG Sides A and B PG side A. This feature enables IPCC designs to add IP IVR redundancy at the CTI Manager level in addition to using the ICM script to check for the availability of IP IVR before sending a call to it. you can implement redundancy by adding the IP addresses or host names of two Cisco CallManagers from the cluster. Load balancing is highly recommended to ensure that all IP IVRs are used in the most efficient way. Cisco CallManager PIM 1 IP IVR (CRS) Design Considerations The JTAPI subsystem in IP IVR (CRS) can establish connections with two CTI Managers.

see IP IVR (CRS) High Availability Using ICM. page 3-13. For more information on this method. The IP IVR subsystems are connections to external applications such as the CTI Manager and ICM. page 3-13. IP messaging TDM voice lines Ethernet lines OL-7279-04 . and Cisco recommends it only for special cases where a few critical CTI route points and CTI ports absolutely must have high availability down to the call processing level in Cisco CallManager.Chapter 3 IP IVR (CRS) Design Considerations Design Considerations for High Availability Figure 3-8 High Availability with Two IP IVR Servers and One Cisco CallManager Cluster T1 lines Public network T1 lines Voice gateway 1 Voice gateway 2 Gatekeepers V IDF switch 1 TDM access IDF MDF switch 2 switch 1 V MDF switch 2 Firewall Cisco CallManager cluster Publisher Sub 1 M M M Sub 2 Corporate LAN IP IVR 1 IP IVR 2 IP IVR group You can increase IP IVR (CRS) availability by using one of the following optional methods: • Call-forward-busy and call-forward-on-error features in Cisco CallManager. Cisco IP Contact Center Enterprise Edition SRND 3-12 76606 Call control. see IP IVR (CRS) High Availability Using Cisco CallManager. • Note Do not confuse the IP IVR (CRS) subsystems with services. ICM script features to check the availability of an IP IVR prior to sending a call to it. This method is more complicated. IP IVR uses only one service. For more information on this method. CTI data. the Cisco Application Engine service.

Internet Service Node (ISN) Design Considerations The Internet Service Node (ISN) may be deployed with IPCC as an alternative to IP IVR for call treatment and queueing.323 for call control and is used "in front of" Cisco CallManager or other PBX systems as part of a hybrid IPCC or migration solution. This feature can be used to forward calls to another CTI port when an IP IVR CTI port is busy due to an IP IVR application problem. ISN is different from IP IVR in that it does not rely on Cisco CallManager for JTAPI call control. Forward No Answer — forwards calls to another port or route point when Cisco CallManager detects that a port has not picked up a call within the timeout period set in Cisco CallManager. and it is easily scalable to virtually any number of IP IVRs.Chapter 3 Design Considerations for High Availability Internet Service Node (ISN) Design Considerations IP IVR (CRS) High Availability Using Cisco CallManager You can implement IP IVR (CRS) port high availability by using any of the following call forward features in Cisco CallManager: • Forward Busy — forwards calls to another port or route point when Cisco CallManager detects that the port is busy. avoid creating a loop in the event that all the IP IVR servers are unavailable. IP IVR (CRS) High Availability Using ICM You can implement IP IVR (CRS) high availability through ICM scripts. do not establish a path back to the first CTI port that initiated the call forwarding. Basically. (See Figure 3-9. This feature can be used to forward calls to another CTI port when an IP IVR CTI port is not answering due to an IP IVR application problem. ISN uses H. you can program an ICM script to check if the IP IVR is active by using an IF node or by configuring a Translation Route to the Voice Response Unit (VRU) node (by using the consider if field). or the IP IVR PG fails. This feature can be used to forward calls to another CTI port when an IP IVR CTI port is busy due to a Cisco CallManager application error. such as running out of available CTI ports. You can prevent calls from queuing to an inactive IP IVR by using the ICM scripts to check the IP IVR Peripheral Status before sending the calls to it. Note All calls at the IP IVR are dropped if the IP IVR server. This method can be modified to load-balance ports across multiple IP IVRs.) Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-13 . Forward on Failure — forwards calls to another port or route point when Cisco CallManager detects a port failure caused by an application error. • • Note When using the call forwarding features to implement high availability of IP IVR ports. IVR-to-CallManager JTAPI link. For example.

IP messaging TDM voice lines Ethernet lines OL-7279-04 . CTI data. • ISN Voice Browser The ISN Voice Browser is used in conjunction with the VXML Voice Browser on the voice gateway to provide call control signalling when calls are switched between the ingress gateway and another endpoint gateway or IPCC agent. The gateway can also use the Media Resource Control Protocol (MRCP) interface to add Automatic Speech Recognition (ASR) and Text-To-Speech (TTS) functions on the gateway as well under ISN control. the gatekeeper can associate the dialed number with a particular set of voice browsers that can handle the call. Instructions from the ICM Peripheral Gateway are translated by the Application Server to VXML code and sent to the voice browsers for processing. when new calls come into the system. these voice gateways also provide additional functionality using the IOS built-in Voice Extensible Markup Language (VXML) Voice Browser to provide caller treatment and call queueing on the voice gateway without having to move the call to a physical IP IVR. Cisco IP Contact Center Enterprise Edition SRND 3-14 126813 ISN PG ISN PG Side A Side B ISN PG Pair Call control. With ISN. The voice browsers register with the application servers as well as gatekeepers so that.Chapter 3 Internet Service Node (ISN) Design Considerations Design Considerations for High Availability Figure 3-9 High Availability with Two ISN Servers T1 lines Public network T1 lines Voice gateway 1 Voice gateway 2 Gatekeepers V IDF switch 1 TDM access IDF MDF switch 2 switch 1 V MDF switch 2 Firewall Combination ISN Voice Browser and ISN Application Server ISN2 ISN1 Corporate LAN ISN uses the following system components: • Cisco Voice Gateway The Cisco Voice Gateway is typically used to terminate TDM PSTN trunks and calls to transform them into IP-based calls on an IP network. • ISN Application Server The ISN Application Server controls the voice browsers (both VXML Voice Browsers on gateways and ISN Voice Browsers) and interfaces to the ICM Peripheral Gateway to obtain instructions and pass data to the ICM routing script.

thus allowing multiple Media Servers to be pooled behind a single URL for access by all the voice browsers in the network. Typically. with email and web contacts being routed by the IPCC to agents in a blended or "universal queue" mode. The Media Routing Peripheral Gateway. like any peripheral gateway. • H. The following optional components are integrated into the IPCC architecture (see Figure 3-10): • Media Routing Peripheral Gateway To route multi-channel contacts.cisco.323 Gatekeepers Gatekeepers are used with ISN to register the voice browsers and associate them with specific dialed numbers. For more information on these options. The Media Servers act as web servers and serve up the . Availability of the ISN can be increased by: • • • • Adding additional redundant ISN systems under control of the ICM Peripheral gateways. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-15 . • Admin Workstation ConAPI Interface The integration of the Cisco multi-channel options allows for the ICM and optional systems to share configuration information about agents and their related skill groups. can be deployed in a redundant or duplex manner with two servers interconnected for high availability. The Configuration Application Programming Interface (ConAPI) runs on an Admin Workstation and can be configured with a backup service running on another Admin Workstation. the Media Routing Peripheral Gateway is co-located at the Central Controller and has an IP-socket connection to the multi-channel systems. a single ISN with multiple voice browsers) Adding gatekeeper redundancy with HSRP Adding Cisco Content Server to load-balance .htm Multi-Channel Design Considerations (Cisco Email Manager Option and Cisco Collaboration Server Option) The IPCC Enterprise solution can be extended to support multi-channel customer contacts. review the ISN product documentation at: http://www. the gateway will query the gatekeeper to find out where to send the call based upon the dialed number.wav files stored on media servers. When calls come into the network.wav files to the voice browsers as part of their VXML processing. The gatekeeper also is aware of the state of the voice browsers and will load-balance calls across them and avoid sending calls to out-of-service voice browsers or ones that have no available sessions.Chapter 3 Design Considerations for High Availability Multi-Channel Design Considerations (Cisco Email Manager Option and Cisco Collaboration Server Option) • ISN Media Server The ISN caller treatment is provided either by using ASR/TTS functions via MRCP or with predefined . thus allowing the ICM to balance the calls across the platforms Adding additional ISN components to an ISN system (for example. Media Servers can be clustered using the Cisco Content Services Switch (CSS) products. the Cisco e-Mail Manager and Cisco Collaboration Server Media Blender communicate with the Media Routing Peripheral Gateway.com/univercd/cc/td/doc/product/icm/isn/isn21/index.wav file requests across multiple ISN Media Servers Note Calls in ISN are not dropped if the Application Server or ISN PG fails because they can be redirected to another ISN Voice Browser on another ISN controlled gateway as part of the fault-tolerant design using TCL scripts in the voice gateway that are provided with the ISN images.

Deploy ConAPI as a redundant pair of Admin Workstations that are not used for configuration and scripting so that they will be less likely to be shut off or rebooted. • Cisco IP Contact Center Enterprise Edition SRND 3-16 OL-7279-04 . Figure 3-10 Multi-Channel System Router Logger AW ConAPI ConAPI Database Database TES Workstation CTI Desktop Phone TES Agents ARM ARM IP MR-PG OPC PIM2 PIM3 MR-PIM MR-PIM MR MR CTI Server IPCC Agent-PG OPC IPCC/EA PIM CTI Server PC Phone CEM CEM Database CCS M 126033 Cisco CallManager Customers/Callers ConAPI ConAPI Recommendations for high availability: • • Deploy the Media Routing Peripheral Gateways in duplex pairs. which can be deployed as a redundant or duplex pair on the Agent Peripheral Gateway. The connection is a TCP/IP socket that connects to the agent's associated CTI Server. Also consider using the HDS servers at the central sites to host this function. These connections provide agent information to the email and web environments as well as accepting and processing task requests from them.Chapter 3 Multi-Channel Design Considerations (Cisco Email Manager Option and Cisco Collaboration Server Option) Design Considerations for High Availability • Agent Reporting and Management (ARM) and Task Event Services (TES) Connections ARM and TES services provide call (ARM) and non-voice (TES) state and event notification from the IPCC CTI Server to the multi-channel systems. Deploy the IPCC Agent Peripheral Gateways and CTI Servers in duplex pairs.

Chapter 3 Design Considerations for High Availability Cisco Email Manager Option Cisco Email Manager Option The Cisco Email Manager is integrated with the IPCC Enterprise Edition to provide full email support in the multi-channel contact center with IPCC. It can be co-resident on the Cisco Email Manager server for smaller deployments or on a dedicated server for larger systems. The major components of Cisco Email Manager are: • • Cisco Email Manager Server — The core routing and control server. Cisco Email Manager UI Server — This server allows the agent user interface (UI) components to be off-loaded from the main Cisco Email Manager server to scale for larger deployments or to support multiple remote agent sites. • Figure 3-11 Single Cisco Email Manager Server Agent Browsers Administrative Browsers SpellServer UIServer RServer CEM Server Machine TServer Inbasket CEM DB Database Server Machine CCL DB 126034 Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-17 . It can be deployed using a single server (see Figure 3-11) for a small deployments or with multiple servers to meet larger system design requirements. Each remote site could have a local UI Server to reduce the data traffic from the agent browser clients to the Cisco Email Manager server (see Figure 3-12). it is not redundant. Cisco Email Manager Database Server — The server that maintains the online database of all emails and configuration and routing rules in the system.

The major components of the Cisco Collaboration Server are (see Figure 3-13): • Cisco Collaboration Server — Collaboration servers are deployed outside the corporate firewall in a demilitarized zone (DMZ) with the corporate web servers they support.Chapter 3 Cisco Collaboration Server Option Design Considerations for High Availability Figure 3-12 Multiple UI Servers Agent Browsers Agent Browsers Administrative Browsers UIServer UIServer Machine UIServer UIServer Machine SpellServer RServer TServer Inbasket CEM Server Machine CEM DB CCL DB 126035 Database Server Machine Cisco Collaboration Server Option The Cisco Collaboration Server is integrated with the IPCC Enterprise Edition to provide web chat and co-browsing support in the multi-channel contact center with IPCC. Cisco Collaboration Server Database Server — This is the server that maintains the online database of all chat and browsing sessions as well as configuration and routing rules in the system. and each Media Blender will have a Media Routing peripheral interface manager (PIM) component on the Media Routing Peripheral Gateway. Multiple Cisco Collaboration Servers can point to the same database server to reduce the total number of servers required for the solution. Cisco Collaboration Server Media Blender — This server polls the collaboration servers to check for new requests. Each IPCC Agent Peripheral Gateway will have its own Media Blender. • • • Cisco IP Contact Center Enterprise Edition SRND 3-18 OL-7279-04 . Cisco Collaboration Dynamic Content Adaptor (DCA) — This server is deployed in the DMZ with the collaboration server. however. because the Cisco Collaboration Server is outside the firewall. and it manages the Media Routing and CTI/Task interfaces to connect the agent and caller. You can deploy multiple collaboration servers for larger systems. most enterprises deploy it on a separate server inside the firewall to protect the historical data in the database. and it allows the system to share content that is generated dynamically by programs on the web site (as opposed to static HTTP pages). It can be co-resident on the Cisco Collaboration Server.

and each Dialer has its own peripheral interface manager (PIM) on the Media Routing Peripheral Gateway. • Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-19 . 126036 Cisco IPCC Outbound Option Design Considerations The Outbound Option provides the ability for IPCC Enterprise to place calls on behalf of agents to customers based upon a predefined campaign. the Dialer emulates a set of IP phones for Cisco CallManager to make the outbound calls. It also interfaces with the Media Routing Peripheral Gateway. MSC). This software is loaded on the Logger platform and is not redundant. In IPCC. and it detects the caller and manages the interaction tasks with the CTI OS server to transfer the call to an agent. Outbound Option Dialer — A software module that performs the dialing tasks on behalf of the Campaign Manager. The major components of the Outbound Option are (see Figure 3-14): • Outbound Option Campaign Manager — A software module that manages the dialing lists and rules associated with the calls to be placed. it can be loaded and active on only one server of the duplex pair of Loggers in the IPCC system.Chapter 3 Design Considerations for High Availability Cisco IPCC Outbound Option Design Considerations Figure 3-13 Cisco Collaboration Server Internet Caller requests for a Call Back or for Web Collaboration with Chat (SSC. or Web Collaboration with a Phone Call (BC) DMZ DCA CallManager ARM CTI Agent PG CTI SVR Media Routing (MR) PG Workstation CTI Desktop Phone IP DCA Connection ARM MRI ICM Queue BAPI Agents CCS CMB MRI MR PIM ICM Distributor AW F I R E W A L L F I R E W A L L ICM Administration Connection (aka Conapi Connection) CMS_jserver HTTP Agent Connection Note: Arrow indicates the direction in which the connection is initiated.

Although they do not function as a redundant or duplex pair the way a Peripheral Gateway does. all of which are under control of the central Campaign Manager software. If the phone. Any calls that were already connected to agents would remain connected and would experience no impact from the failure. a failure of one of the dialers can be handled automatically and calls will continue to be handled by the surviving dialer.) Deploy multiple Dialers and make use of them in the Campaign Manager to allow for automatic fault recovery to a second Dialer in the event of a failure.Chapter 3 Peripheral Gateway Design Considerations Design Considerations for High Availability Figure 3-14 IPCC Outbound Option Logger SQL Server 7/2000 Import EMT ODBC Campaign manager EMT MR PG IPCC PG IPCC PIM IPCC PIM CTI/CTIOS TCP/IP Dialer IP/TI/ Analog/EI TCP/IP TCP/IP Components with dashed lines are only used by IPCC Agent Desktop The system can support multiple dialers across the enterprise. route point. Deploy Dialers on their own servers as standalone devices to eliminate a single point of failure. the Dialer should be on its own server. or you could possibly use multiple Dialers under control of the central Campaign Manager. the Dialer could be co-resident on the IPCC Peripheral Gateway. with a single Peripheral Interface Manager (PIM) controlling agent phones anywhere on the cluster. as would any other phone or device in the Cisco CallManager cluster. the dialer would go down if the PG server failed. (If they were co-resident on a PG. Recommendations for high availability: • • • • Deploy the Media Routing Peripheral Gateways in duplex pairs. Include Dialer "phones" (virtual phones in Cisco CallManager) in redundancy groups in Cisco CallManager to allow them to fail-over to a different subscriber. For smaller implementations. The Peripheral Gateway PIM process registers with CTI Manager on one of the Cisco CallManager servers in the cluster. and the CTI Manager accepts all JTAPI requests from the PG for the cluster. with a pair of dialers under control of the Campaign Manager. Peripheral Gateway Design Considerations The ICM CallManager Peripheral Gateway (PG) uses the Cisco CallManager CTI Manager process to communicate with the Cisco CallManager cluster. For larger systems. or other device being controlled Cisco IP Contact Center Enterprise Edition SRND 3-20 126037 Administrative Workstation CO IP Gateway M ACD/ CallManager OL-7279-04 .

Duplex Cisco CallManager PG implementations are highly recommended because the PG will have only one connection to the Cisco CallManager cluster using a single CTI Manager. the ICM Call Router and Logger/Database Server processes are interconnected through a private. If the servers are geographically distributed. There is no need for a PG to connect to multiple Cisco CallManager servers in a cluster. Adding a redundant or duplex PG allows the ICM to have a second pathway or connection to the Cisco CallManager cluster using a second CTI Manager process on a different Cisco CallManager server in the cluster. In both cases. If that CTI Manager were to fail. IP messaging TDM voice lines Ethernet lines 3-21 .) Figure 3-15 ICM High Availability with One Cisco CallManager Cluster T1 lines Public network T1 lines Voice gateway 1 Voice gateway 2 Gatekeepers V MDF switch 1 TDM access IDF switch 1 IDF switch 2 V MDF switch 2 Firewall Cisco CallManager cluster Publisher Sub 1 M M M Sub 2 IP IVR 1 IP IVR group IP IVR 2 Corporate LAN CM PG A CM PG B ICM A ICM B ICM central controllers Redundant ICM servers can be located at the same physical site or geographically distributed. you can provide the private LAN by inserting a second NIC card in each server (sides A and B) and connecting them with a crossover cable. The minimum requirement for ICM high-availability support for CTI Manager and IP IVR (CRS) is a duplex (redundant) Cisco CallManager PG environment with one Cisco CallManager cluster containing at least two servers. you can provide the private LAN by inserting a second NIC card Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 76607 Call control. If the servers are located at the same site. Therefore. (See Figure 3-15. the CTI Manager forwards that request via Cisco CallManager SDL links to the other Cisco CallManager servers in the cluster. the PG would no long be able to communicate with the Cisco CallManager cluster. the minimum configuration for a Cisco CallManager cluster in this case is one publisher and one subscriber. CTI data.Chapter 3 Design Considerations for High Availability Peripheral Gateway Design Considerations by the PG is not registered to that specific Cisco CallManager server in the cluster. dedicated LAN.

Cisco CallManager PG side A logs into the primary CTI Manager. with only the active PG side PIM communicating with the Cisco CallManager cluster. In duplex PG operation. Also. The registration and initialization services of the Cisco CallManager devices take a significant amount of time. the ICM will have no visibility to the Cisco CallManager cluster. and it is specific for the version of Cisco CallManager.Chapter 3 Peripheral Gateway Design Considerations Design Considerations for High Availability in each server (sides A and B) and connecting them with a dedicated T1 line that meets the specific network requirements for this connection as documented in the Cisco ICM Software Installation Guide. Cisco CallManager Failure Scenarios A duplex ICM model contains no single points of failure. The ICM PG PIM is also a node-managed process and is monitored for unexpected failures and automatically restarted. and having the CTI Manager primed significantly decreases the time for failover. both JTAPI services from both Cisco CallManager PG sides log into the CTI Manager upon initialization. existing calls on that component will be dropped. The standby side logs into the secondary CTI Manager only to initialize the interface and prime it for a failover. and it ensures that only the PG side that has the best connection to the Call Router will attempt to go active.cisco. In either of these cases. if a component of the IPCC solution does not itself support redundancy and failover. The JTAPI Gateway is started by the PG automatically and runs as a node-managed process. but it depends only upon the ability of the PG to connect to the Call Router. It is not deterministic based upon the Side A or Side B designation of the PG device. there are scenarios where a combination of multiple failures can prevent IPCC from accepting new incoming calls. The following ICM failure scenarios have the most impact on high availability. available at http://www. and Cisco CallManager Peripheral Interface Managers (PIMs) cannot activate if the either of the following failure scenarios occurs (see Figure 3-16): • • PIM side A and the secondary CTI Manager that services the PIM on side B both fail. only the active side of the Cisco CallManager PG registers monitors for phones and CTI route points. The duplex ICM PG pair works in hot standby mode.com/univercd/cc/td/doc/product/icm/icmentpr/icm50doc/coreicm5/plngupin/instl gd. the PG side that is able to connect to the ICM Call Router Server and request configuration information first will be the side that goes active. requesting specific objects to monitor and handling route requests from the Cisco CallManager cluster. PIM side B and the primary CTI Manager that services the PIM on side A both fail. two software processes are run to manage the connectivity to the Cisco CallManager cluster: the JTAPI Gateway and the CallManager PIM. Cisco IP Contact Center Enterprise Edition SRND 3-22 OL-7279-04 . This process manages the higher-level interface between the ICM and the Cisco CallManager cluster. However. The JTAPI Gateway handles the low-level JTAPI socket connection protocol and messaging between the PIM and the Cisco CallManager CTI Manager. which means that the PG will monitor this process and automatically restart it if it should fail for any reason. In a duplex ICM PG environment. However. while PG side B logs into the secondary CTI Manager.pdf Within the ICM PG.

call processing continues. page 3-25 Scenario 4 . Cisco CallManagers A and B are each running a separate instance of CTI Manager. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 126158 3-23 . CTI Manager. B is the backup).Cisco CallManager and CTI Manager Fail. The following conditions apply to this scenario: • • • • • • • • All phones and gateways are registered with Cisco CallManager A. all phones and gateways re-home to it. The agent will have to log in again manually using the agent desktop. the IP phone re-homes to the backup Cisco CallManager B. When all of the software services on CallManager Subscriber A fail (call processing. PG side A detects a failure and induces a failover to PG side B. page 3-26 Scenario 1 . page 3-24 Scenario 3 .Only Cisco CallManager Fails. and so on). and Cisco CallManager A is the primary CTI Manager in this case. All phones and gateways are configured to re-home to Cisco CallManager B (that is. page 3-23 Scenario 2 . PG side B becomes active and registers all dialed numbers and phones.Only CTI Manager Fails. all phones and gateways re-home to Cisco CallManager B.Chapter 3 Design Considerations for High Availability Peripheral Gateway Design Considerations Figure 3-16 Cisco CallManager PGs Cannot Cross-Connect to Backup CTI Managers ICM PG A ICM PG B Subscriber 1 (CTI Manager and Cisco CallManager) Subscriber 2 Publisher (CTI Manager and CallManager) (CTI Manager and Cisco CallManager) ICM Failover Scenarios This section describes how redundancy works in the following failure scenarios: • • • • Scenario 1 .Cisco CallManager and CTI Manager Fail Figure 3-17 shows a complete system failure or loss of network connectivity on Cisco CallManager A. After an agent disconnects from all calls. When Cisco CallManager A recovers. The CTI Manager and Cisco CallManager services are both active on the same server.Cisco CallManager PG Side A Fails.

any calls in progress at an IPCC agent will remain active. When the call is completed. All CTI messaging will be handled using the CTI Manager on Cisco CallManager B. All CTI Manager and Cisco CallManager services continue running normally. PG side B registers all dialed numbers and phones. Figure 3-17 Scenario 1 . When PG side A fails. All phones and gateways are configured to re-home to Cisco CallManager B (that is. Cisco CallManagers A and B are each running a separate instance of CTI Manager. During this failure. B is the backup). call processing continues. Cisco IP Contact Center Enterprise Edition SRND 3-24 79925 ICM synchronzation messages CallManager intra-cluster messages JTAPI messages H323 or MGCP messages SCCP messages OL-7279-04 .Cisco CallManager and CTI Manager Fail CallManager PG A CallManager PG B CallManager A M M CallManager B IP Scenario 2 . When PG side A recovers. that agent's desktop functionality is restored to the same state prior to failover. the PG will not fail back to the A side of the duplex pair. the phone will re-home to the backup Cisco CallManager automatically. The following conditions apply to this scenario: • • • • • • • All phones and gateways are registered with Cisco CallManager A. After the failure is recovered.Cisco CallManager PG Side A Fails Figure 3-18 shows a failure on PG side A and a failover to PG side B. which will communicate to Cisco CallManager A to obtain phone state and call information. PG side B remains active and uses the CTI Manager on Cisco CallManager B. PG side B becomes active. using the CTI Manager on Cisco CallManager B. After an agent disconnects from all calls.Chapter 3 Peripheral Gateway Design Considerations Design Considerations for High Availability • • • PG side B remains active.

not the Cisco CallManager service. When Cisco CallManager A fails. The CTI Manager services are running on Cisco CallManagers C and D. it re-homes to Cisco CallManager B after it disconnects from the call. with a CTI Manager connection on Cisco CallManager subscriber C. It does not fail-over because the JTAPI/CTI Manager connection has not failed. the PG will disable the agent desktops to prevent the agents from attempting to use the system while their phones are not actively registered with a Cisco CallManager subscriber. The following conditions apply to this scenario: • • • • • All phones and gateways are registered with Cisco CallManager A.Cisco CallManager PG Side A Fails CallManager PG A CallManager PG B CallManager A M M CallManager B IP Scenario 3 . During the time that the agent phones are not registered. However.Only Cisco CallManager Fails Figure 3-19 shows a failure on Cisco CallManager A. phones and gateways re-home to Cisco CallManager B. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 79926 ICM synchronzation messages CallManager intra-cluster messages JTAPI messages H323 or MGCP messages SCCP messages 3-25 . Cisco CallManagers C and D are each running a separate instance of CTI Manager. If a phone is in a call. All phones and gateways are configured to re-home to Cisco CallManager B (that is. all phones and gateways are registered with Cisco CallManager A. All phones re-home individually to the standby Cisco CallManager B if they are not in a call. However. Cisco CallManager is not affected because the PG communicates with the CTI Manager service.Chapter 3 Design Considerations for High Availability Peripheral Gateway Design Considerations Figure 3-18 Scenario 2 . During this failure. PG side A remains connected and active. and Cisco CallManager C is acting as the primary CTI Manager. it will see the phones and devices being unregistered from Cisco CallManager subscriber A (where they were registered) and will then be notified of these devices being re-registered on Cisco CallManager subscriber B automatically. B is the backup).

and the agent will have to log in again manually using the agent desktop. After the agent disconnects the active call. Call processing also continues for those devices on subscriber A when they are re-registered with their backup subscriber. transfer. that agent's phone will re-register with the backup subscriber. all phones and gateways are registered with Cisco CallManager A. Call processing continues normally after the phones and devices have returned to their original subscriber. or other telephony events during the failover. Because the JTAPI service on PG side B Cisco IP Contact Center Enterprise Edition SRND 3-26 79927 OL-7279-04 . Agents on an active call will stay in their connected state until they complete the call. However. the agent desktop will be disabled to prevent any conference.Only CTI Manager Fails Figure 3-20 shows a CTI Manager service failure on Cisco CallManager C. however. The CTI Manager services are running on Cisco CallManagers C and D.Chapter 3 Peripheral Gateway Design Considerations Design Considerations for High Availability • Call processing continues for any devices not registered to Cisco CallManager subscriber A. When Cisco CallManager A recovers. • • • Figure 3-19 Scenario 3 .Only Cisco CallManager Fails CallManager PG A CallManager PG B CallManager C M M CallManager D CallManager A M M CallManager B IP ICM synchronzation messages CallManager intra-cluster messages JTAPI messages H323 or MGCP messages SCCP messages Scenario 4 . phones and gateways re-home to it. both the CTI Manager and the PG fail-over to their secondary sides. and Cisco CallManager C is the primary CTI Manager. This re-homing can be set up on Cisco CallManager to gracefully return groups of phones and devices over time or to require manual intervention during a maintenance window to minimize the impact to the call center. During this failure.

PG side A detects a failure of the CTI Manager on that server and induces a failover to PG side B. When Cisco CallManager C recovers.Chapter 3 Design Considerations for High Availability Peripheral Gateway Design Considerations is already logged into the secondary (now primary) CTI Manager. that agent's desktop functionality is restored to the same state prior to failover. After an agent disconnects from all calls. B is the backup). When Cisco CallManager C fails. Cisco CallManagers C and D are each running a separate instance of CTI Manager. The following conditions apply to this scenario: • • • • • • • All phones and gateways are registered with Cisco CallManager A. All phones and gateways are configured to re-home to Cisco CallManager B (that is. PG side B continues to be active and uses the CTI Manager on Cisco CallManager D. and call processing continues. Figure 3-20 Only CTI Manager Fails CallManager PG A CallManager PG B CallManager C M M CallManager D CallManager A M M CallManager B IP ICM synchronzation messages CallManager intra-cluster messages JTAPI messages H323 or MGCP messages SCCP messages Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 79928 3-27 . the device registration and initialization time is significantly shorter than if the JTAPI service on PG side B had to log into the CTI Manager. PG side B registers all dialed numbers and phones with Cisco CallManager D.

then PG2A. or calls in queue. The system can continue to function normally. the Call Routers will be in simplex mode until the private network link is restored. there must be a dedicated. The Peripheral Gateway side of the duplex pair that was actively connected to the Cisco CallManager cluster will continue to function as the active side of the pair. and the network must be monitored and maintained. which allows for high availability of Cisco CallManager resources across multiple locations and data center locations. and so forth. There is no impact to the agents. page 3-23) are still valid in this model. starting with PG1A. and the additional failure scenarios for this model include: • • • • Scenario 1 . The Peripheral Gateways verify which side of the duplex pair has the active connection to the Cisco CallManager cluster. calls in progress. and IPCC adds its own specific requirements and new failover considerations to the model. The component failure scenarios noted previously (see ICM Failover Scenarios. • Cisco IP Contact Center Enterprise Edition SRND 3-28 OL-7279-04 . but no code changes were made to the core IPCC solution components to support this model. The TOS message requests the Peripheral Gateway to check if it can "see" the Call Router on the other side to determine if the failure is a network failure or a failure of the redundant pair. with no failover or loss of service. • • • If the private network fails between the Cisco CallManager Peripheral Gateways. isolated private network connection between the geographically distributed Central Controller (Call Router/Logger) and the split Peripheral Gateway pair to maintain state and synchronization between the sides of the system. The Call Routers verify which side sees more active connections of the Peripheral Gateways.Remote Agent Location WAN Fails. the following conditions apply: • The Call Routers will detect the failure by missing five consecutive UDP heartbeats. Missing five consecutive heartbeats will signal the ICM that the link or the remote partner system might have failed. however. All the Peripheral Gateways will realign their active data feed to the active Call Router over the visible network. and UDP heartbeats are generated to verify the health of this link.Chapter 3 Peripheral Gateway Design Considerations Design Considerations for High Availability IPCC Scenarios for Clustering over the WAN IPCC Enterprise can also be overlaid with the Cisco CallManager design model for clustering over the WAN. page 3-28 Scenario 2 . The ICM uses the heartbeats to detect a failure on the private link.Visible Network Fails. page 3-31 Scenario 1 . Specific testing has been performed to identify the design requirements and failover scenarios. If the private network fails between the ICM Central Controllers. The other side will be inactive until the private network connection is restored. That side will continue to function as the active Call Router in simplex mode.ICM Central Controller or Peripheral Gateway Private Network Fails In clustering over the WAN with IPCC. and the redundant Call Router will be disabled. The success of this design model relies on specific network configuration and setup.ICM Central Controller or Peripheral Gateway Private Network Fails. There are a number of specific design requirements for Cisco CallManager to support this deployment model. page 3-29 Scenario 3 . the following conditions apply: • The Peripheral Gateway sides will detect the failure by missing five consecutive UDP heartbeats.Visible and Private Networks Both Fail (Dual Failure). Both Call Routers send a "test other side" (TOS) message to the Peripheral Gateways. page 3-30 Scenario 4 . in simplex mode. then PG1B.

and the local Call Router will then use the private network to pass data to the Call Router on the other side to continue call processing. and it must be highly resilient as well.Visible Network Fails The visible network in this design model is the network path between the data center locations where the main system components (Cisco CallManager subscribers. the failures would follow the same path. IP-IVR/ISN components. calls in progress. This network is used to carry all the voice traffic (RTP stream and call control signalling). Likewise. The ICM Call Routers will detect the failure because the normal flow of TCP keep-alives from the remote Peripheral Gateways will stop. This does not cause a failover of the Peripheral Gateway or the Call Router. as well as all typical data network traffic between the sites. However. the remote Cisco CallManager subscriber at side B cannot send the phone registration event to the remote Peripheral Gateway.Chapter 3 Design Considerations for High Availability Peripheral Gateway Design Considerations • There is no impact to the agents. however. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-29 . If the two private network connections were combined into one link. the phone events would be passed from side B to side A over the visible network via the CTI Manager Service to present these events to the side A Peripheral Gateway. the system would be running in simplex on both the Call Router and the Peripheral Gateway. Agents might be affected by this failure under the following circumstances: – If the agent desktop (Cisco Agent Desktop or CTI OS) is registered to the Peripheral Gateway • • on side A of the system but the physical phone is registered to side B of the Cisco CallManager cluster Under normal circumstances. any calls that were set up over this WAN link will fail with the link. but the phone is reset and it re-registers to a side B of the Cisco CallManager subscriber If the IP Phone re-homes or is manually reset and forced to register to side B of a Cisco CallManager subscriber. the Peripheral Gateways will detect this failure by the loss of TCP keep-alives from the remote Call Routers. If a second failure were to occur at that point. Scenario 2 . or calls in queue. Because the visible network is down. the Call Routers will be in simplex mode until the private network link is restored. – If the agent desktop (Cisco Agent Desktop or CTI OS) and IP Phone are both registered to side A of the Peripheral Gateway and Cisco CallManager. and the agent will be logged out of IPCC automatically because the system can no longer direct calls to the agent’s phone. The Peripheral Gateway will no longer be able to see this phone. the following conditions apply: • The Cisco CallManager subscribers will detect the failure and continue to function locally. the system could lose some or all of the call routing and ACD functionality. The system can continue to function normally. This link is critical to the IPCC design because it is part of the fault-tolerant design of the system. ICM CTI (call control signalling) traffic. the Cisco CallManager subscriber on side A that is providing the CTI Manager Service to the local Peripheral Gateway will unregister the phone and remove it from service. and the phone will remain operational on the isolated side B. IPCC will log out this agent because it can no longer control the phone for the agent. If the visible network fails between the data center locations. however. with no impact to local call processing and call control. In order to meet the requirements of Cisco CallManager clustering over the WAN. The visible network failure will not force the IP Phone to re-home to side A of the cluster. and so forth) are located. this link must be highly available with very low latency and sufficient bandwidth. Peripheral Gateways. The Peripheral Gateways will automatically realign their data communications to the local Call Router.

) Any new calls that come into the disabled side will not be routed by the IPCC. and the Peripheral Gateway will not remain active if it is not able to connect to an active Call Router. The Call Routers and Peripheral Gateways will detect the private network failure after missing five consecutive UDP heartbeats. with no impact to local call processing and call control. it will also consider the state of the Call Router. However. These heartbeats are generated every 100 ms. so it can take up to two seconds before this failure is detected. depending upon the /LOAD parameter defined for the Cisco CallManager Peripheral Gateway in ICM Config Manager). but they can be redirected or handled using standard Cisco CallManager "redirect on failure" for their CTI Route Points. However. However. and the failure will be detected within about 500 ms on this link. The Call Routers will send a message to the Peripheral Gateways to realign their data feeds to the active call router only. taking them out of service in the ICM Call Routing Scripts (using the "peripheral on-line" status checks) and forcing any of the calls in progress on these devices to be disconnected.Chapter 3 Peripheral Gateway Design Considerations Design Considerations for High Availability – If the agent desktop (CTI OS or Cisco Agent Desktop) is registered to the CTI OS Server at the side-B site but the active Peripheral Gateway side is at the side-A site Under normal operation. any calls that were set up over this WAN link will fail with the link. The remote IP-IVR or ISN Peripheral Gateways will be off-line. the CTI OS desktop (and Cisco Agent Desktop Server) will load-balance their connections to the CTI OS Server pair. When the visible network fails. During this transition. the CTI OS Server detects the loss of connection with the remote Peripheral Gateway CTI Server (CG) and disconnects the active agent desktop clients to force them to re-home to the redundant CTI OS Server at the remote site. The Call Router will be able to see only the local Peripheral Gateways. with backup and resiliency built into the design. These keep-alives are sent every 400 ms. half the agent connections would be on a CTI OS server that has to cross the visible network to connect to the active Peripheral Gateway CTI Server (CG). • • • • • • Cisco IP Contact Center Enterprise Edition SRND 3-30 OL-7279-04 . (The agent may be logged out or put into not-read state. Scenario 3 . The surviving Call Router and Peripheral Gateways will detect the failure of the visible network by the loss of TCP keep-alives on the visible network. This failure should be considered catastrophic and should be avoided by careful WAN design. The CTI OS agent desktop is aware of the redundant CTI OS server and will automatically use this server. the agent desktop will be disabled and will return to operational state as soon as it is connected to the redundant CTI OS server. the following conditions apply: • The Cisco CallManager subscribers will detect the failure and continue to function locally. and that side will stay active in simplex mode while the remote Call Router will be in standby mode. which are those used to control local IP-IVR or ISN ports and the local half of the CallManager Peripheral Gateway pair. the system will be reduced to very limited functionality. if both of these networks fail at the same time. The Call Routers will determine the side with the most active Peripheral Gateway connections. the private and visible networks can fail with limited impact to the IPCC agents and calls. The Call Routers will attempt to contact their Peripheral Gateways with the "test other side" message to determine if the failure was a network issue or if the remote Call Router had failed and was no longer able to send heartbeats. If both the visible and private networks fail at the same time. (ISN can redirect the calls upon failure. The Peripheral Gateways will determine which side has the active Cisco CallManager connection. At any given time.Visible and Private Networks Both Fail (Dual Failure) Individually.

the Call Router and Cisco CallManager Peripheral Gateway will run in simplex mode. transfer. If side A of the WAN at the remote agent location fails. Understanding Failure Recovery This section analyzes the failover recovery of each individual part (products and subcomponents inside each product) of the IPCC solution. Scenario 4 . Each agent location requires WAN connectivity to both of the data center locations where the Cisco CallManager and ICM components are located. Only agents that were active on the surviving side of the Peripheral Gateway with phones registered locally to that site will not be impacted. any calls in progress are terminated and the agents are logged out so that future calls are not routed to them. Cisco CallManager reporting shows the call as terminated when the Cisco CallManager failure occurred because.Chapter 3 Design Considerations for High Availability Understanding Failure Recovery • Agents will be impacted as noted above if their IP Phones are registered to the side of the Cisco CallManager cluster opposite the location of their active Peripheral Gateway and CTI OS Server connection. The IP-IVR/ISN functionality will also be limited to the surviving side as well.) If both sides of the WAN at the remote agent location fail. and so on) are not possible. but further call control functions (hold. These connections should be isolated and provide for redundancy as well as making use of basic SRST functionality in the event of a complete network failure so that the remote site would still have basic dial tone service to make emergency (911) calls. retrieve. all the devices registered to it are reported out of service by the CTI Manager service. The agent desktop will detect the loss of connectivity to the CTI OS Server (or Cisco Agent Desktop Server) and automatically log the agent out of the system.Remote Agent Location WAN Fails The IPCC design model for clustering over the WAN assumes the IPCC agents are remotely located at multiple sites connected by a WAN. and the system will accept new calls from only the surviving side for IPCC call treatment. When an active Cisco CallManager service fails. then the calls in progress survive. conference. Cisco CallManager Service In larger deployments. The IP phone of an agent on a call at the time of failure will not register with the backup Cisco CallManager until after the agent completes the current call. IP phones of agents not on calls at the time of failure will quickly register with the backup Cisco CallManager. the following conditions apply: • • The local voice gateway will detect the failure of the communications path to the Cisco CallManager cluster and will go into SRST mode to provide local dial-tone functionality. they will not be able to function as IPCC agents. from a Cisco CallManager reporting perspective. the following conditions apply: • • Any IP phones that are homed to the side-A Cisco CallManager subscribers will automatically re-home to the side-B subscribers (provide the redundancy group is configured). While the IP phones are in SRST mode. (Agent desktop will be disabled during the realignment process. At this point. Agent desktops that are connected to the CTI OS or Cisco Agent Desktop server at that site will automatically realign to the redundant CTI OS server at the remote site. it is possible that the Cisco CallManager where agent phones are registered will not be running the CTI Manager service that communicates with the Cisco CallManager. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-31 . If MGCP gateways are used.

This does not impact the Internet Service Node (ISN) because it does not depend upon the Cisco CallManager JTAPI service. Upon recovery of the primary Cisco CallManager. In addition.Chapter 3 Understanding Failure Recovery Design Considerations for High Availability When the active Cisco CallManager fails. In summary. The agents can recognize this event because the agent state display on their desktop will show logged out. all voice calls at this IP IVR are dropped. the JTAPI detects an OUT_OF_SERVICE event and induces a failover to the standby PG. ICM The ICM is a collection of services and processes within these services. This initialization service takes place at a rate of about 5 devices per second. the PG does not need to fail-over. it registers monitors for the phones with logged-in agents and configured dialed numbers and CTI route points. and its failure does not affect the Cisco CallManager PGs. it logs into this CTI Manager again and re-registers all the CTI ports associated with the IP IVR JTAPI user. all redundant ICM services discussed in this chapter must be located at the same site and connected through a private LAN. if a secondary is specified. the IP IVR (CRS) JTAPI subsystem shuts down and restarts by trying to connect to the secondary CTI Manager. the PG does not go off-line because the Cisco CallManager server running CTI Manager remains operational. From a Cisco CallManager perspective. the agent desktops show the agents as being logged out. To continue receiving calls. You can provide the private LAN by installing a second network interface card (NIC) in each server (sides A and B) and connecting them with a crossover cable. the Cisco CallManager service is separate from the CTI Manager service. The agent desktops show them as being logged out. the agent phones re-register with their original service because all the Cisco CallManager devices are forced to register with their home Cisco CallManager. the server resumes its Voice Response Unit (VRU) functions and handles new calls. As stated previously. After all the Cisco CallManager devices are successfully registered with the IP IVR JTAPI user. Since the standby PG is logged into the standby CTI Manager already. the agents must wait for their phones to re-register with a backup Cisco CallManager to have their desktop functionality restored by the CTI server to the state prior to the Cisco CallManager service failure. their IP phones display a message stating that the phone has gone off-line. depending on the administrator's preference. Cisco IP Contact Center Enterprise Edition SRND 3-32 OL-7279-04 . including another ICM service. and all the IP phone soft keys are grayed out until the phones fail-over to the backup Cisco CallManager. you can eliminate all external network equipment failures.) All agents lose their desktop functionality until the failure recovery is complete. Therefore. (This warning can be turned on or off. Cisco CallManager PG and CTI Manager Service When the active CTI Manager or PG fails. IP IVR (CRS) When a CTI Manager fails. If there is an available secondary CTI Manager. Note Agents should not push any buttons during desktop failover because these keystrokes can be buffered and sent to the CTI server when it completes its failover and restores the agent states. The failover and recovery process for each of these services is unique and requires carefully examination to understand the impact to other parts of the IPCC solution. Any existing calls handled by the agent should remain alive without any impact to the caller. and a message displays stating that their routing client or peripheral (Cisco CallManager) has gone off-line. and the login button will be the only button available. which talks to the Cisco CallManager PG via JTAPI. The Cisco CallManager service is responsible for registering the IP phones. By doing this.

Chapter 3 Design Considerations for High Availability Understanding Failure Recovery Once the CTI Manager or PG completes its failover.) Figure 3-21 Redundant ICM VRU PGs with Two IP IVR Servers T1 lines Public network T1 lines Voice gateway 1 Voice gateway 2 Gatekeepers V MDF switch 1 TDM access IDF switch 1 IDF switch 2 V MDF switch 2 Firewall Cisco CallManager cluster Publisher Sub 1 M M M Sub 2 IP IVR 1 IP IVR group IP IVR 2 Corporate LAN CM PG A CM PG B VRU PG A VRU PG B ICM central controllers Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 76609 Call control. and matched with call context information saved on the PG. (See Figure 3-21. or conference calls if they were on a call at the time of the failure. all agents without active calls are reset to the default Not Ready state. However. not ready. IP messaging TDM voice lines Ethernet lines ICM A ICM B 3-33 . the Service Control Interface (SCI) link of the failed VRU PG automatically connects to the backup VRU PG so that all new calls can be handled properly. Therefore. ICM Voice Response Unit PG When a Voice Response Unit (VRU) PG fails. the Longest Available Agent (LAA) algorithm resets the timers for all the agents to zero. All the call data that had been collected and stored via a call data update message is retained on the agent desktops. However. At this point. CTI data. transfer. a VRU PG failure would block use of that IP IVR even though the IP IVR is working properly. Upon recovery of the failed VRU PG. having redundant VRU PGs adds significant value because it allows an IP IVR to continue to function as an active IP IVR. all the calls currently in queue on that IP IVR (CRS) are dropped. and so forth). if available. ready. the currently running VRU PG continues to operate as the active VRU PG. Without VRU PG redundancy. recovered. In addition. the agents can return to their previous call state (talking. the agents should also be able to release. Calls queued in the Internet Service Node (ISN) are not dropped and will be redirected to a secondary ISN or number in the dial plan.

the surviving server will detect the failure after missing five consecutive heartbeats on the private LAN. It performs the call routing in the system. Upon detection of the failure. the Call Router that previously had the most active PG connections would remain active in simplex mode. and events in the system. depending upon the size of the implementation. When the Logger server is restored. the Logger data is also synchronized.Chapter 3 Understanding Failure Recovery Design Considerations for High Availability ICM Call Router and Logger The ICM Central Controllers or ICM Servers are shown in these diagrams as a single set of redundant servers. Call Router hardware failure — It is possible for the Call Router on the other side to have a physical hardware failure and be completely out of service. In the event that the two Logger databases are out of synchronization. In this case. The Call Router software runs in synchronized execution. The Logger also provides a replication of its historical data to the customer Historical Database Server (HDS) Admin Workstations over the visible network. call types. If the Logger was off-line for less than 12 hours. executing the user-created ICM Routing Scripts and populating the real-time reporting feeds for the Administrative Workstation. and so forth) and scripting (call flow scripts) as well as the historical data from call processing. the surviving Call Router will contact the Peripheral Gateways in the system to verify the type of failure that occurred. The loss of heartbeats on the private network could be caused by either of the following conditions: • Private network outage — It is possible for the private LAN switch or WAN to be down but for both of the ICM Call Routers to still be fully operational. only the surviving Call Router would be communicating with the Peripheral Gateways using the Test Other Side message. and the Call Router on the other side would go idle until the private network is restored. the Call Routers will both send a Test Other Side message to the PGs to determine if the Call Router on the other side is still operational and which side should be active. They keep this information updated by passing the state events between the servers on the private LAN connection. However. Based upon the messages from the PGs. calls. In the event that the one of the ICM Call Routers should fail. the Logger will contact the redundant Logger to determine how long it had been off-line. they can be resynchronized manually by using the ICMDBA application over the private LAN. the Peripheral Gateways will still see both of the ICM Call Routers even though they cannot see each other over the private network. In this case. The redundant Logger would continue to accept data from its local Call Router. In this case. they could be deployed with multiple servers to host the following key software processes: • ICM Call Router The ICM Call Router is the "brain" of the system that maintains a constant memory image of the state of all the agents. The Loggers receive data from their local Call Router process to store in the system database. so it will take up to 500 ms to detect this failure. If one of the ICM Logger and Database Servers were to fail. Because the Call Routers are synchronized. with both of the redundant servers running the same memory image of the current state across the system. and the surviving Call Router would take over the active processing role in simplex mode. The Peripheral Gateways would report that they can no longer see the Call Router on the other side. The Call Routers generate these heart beats every 100 ms. • During the Call Router failover processing. any Route Requests sent to the Call Router from a Carrier Network Interface Controller (NIC) or Peripheral Gateway will be queued until the surviving Call Router is in active simplex mode. • ICM Logger and Database Server The ICM Logger and Database Server maintains the system database for the configuration (agent IDs. skill groups. there would be no immediate impact except that the local Call Router would no longer be able to store data from call processing. it will automatically request all the transactions it missed from the Cisco IP Contact Center Enterprise Edition SRND 3-34 OL-7279-04 . Any calls in progress in the IVR or at an agent will not be impacted.

any outbound calling will stop until the Logger can be restored to operational status. the system will not automatically resynchronize the databases. (See Figure 3-22. Manual resynchronization allows the system administrator to decide when to perform this data transfer on the private network. you can deploy multiple Administrative Workstation servers to provide redundancy for the IPCC.) Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-35 . WebView and Internet Script Editor. as the other ICM system components do. the Campaign Manager software is loaded on only one of the Logger platforms (must be Logger A). These servers do not support redundant or duplex operation. The Loggers maintain a recovery key that tracks the date and time of each entry recorded in the database. However. If the Logger was off-line for more than 12 hours. perhaps scheduling it during a maintenance window when there would be little call processing activity in the system. If that platform is out of service. Admin Workstation Real-Time Distributor (RTD) The Administrative Workstation (AW) Real-Time Distributor (RTD) provides the user interface to the system for making configuration and scripting changes. It also hosts the web-based reporting tool. and these keys will be used to restore data to the failed Logger over the private network. There is no impact to call processing during a Logger failure. however. In this case. resynchronization has to be done manually using the ICMDBA application. the HDS data that is replicated from that Logger would stop until the Logger can be restored. Additionally. if the Outbound Option is used. The Logger replication process that sends data from the Logger database to the HDS Admin Workstations will automatically replicate each new row written to the Logger database when the synchronization takes place as well.Chapter 3 Design Considerations for High Availability Understanding Failure Recovery redundant Logger while it was off-line.

Real-Time Distributors at the same site can be set up as part of an Admin Site that includes a designated primary real-time distributor and one or more secondary real-time distributors.Chapter 3 Understanding Failure Recovery Design Considerations for High Availability Figure 3-22 Redundant ICM Distributors and AW Servers T1 lines Public network T1 lines Voice gateway 1 Voice gateway 2 Gatekeepers V MDF switch 1 TDM access IDF switch 1 IDF switch 2 V MDF switch 2 Firewall Cisco CallManager cluster Publisher Sub 1 M M M Sub 2 IP IVR 1 IP IVR group IP IVR 2 Corporate LAN CM PG A CM PG B VRU PG A VRU PG B IPCC_Site1 AW A AW B ICM central controllers WedView Reporting Client Administrative Workstation Real-Time Distributors are clients of the ICM Call Router real-time feed that provides real-time information about the entire IPCC across the enterprise. IP messaging TDM voice lines Ethernet lines ICM A ICM B OL-7279-04 . this is important because it can reduce the required bandwidth to support remote Admin Workstations across a WAN connection. Another option is to add Client Admin Workstations which do not have their own local SQL databases and are homed to a Real-Time Distributor for their SQL database and real-time feed. The Admin Site reduces the number of real-time feed clients the ICM Call Router has to service at a particular site. When using an Admin Site. CTI data. For remote sites. If the primary real-time distributor is down or does not accept the registration from the secondary real-time distributors. they will register with the Cisco IP Contact Center Enterprise Edition SRND 3-36 126159 Call control. and the other real-time distributors within that Admin Site register with the primary real-time distributor for the real-time feed. the primary real-time distributor is the one that will register with the ICM Call Router for the real-time feed.

however. If the CTI Server is down on both sides of the duplex agent Peripheral Gateway pair. none of the agents for that Agent Peripheral Gateway will be able to log into these applications.) It does not. CTI OS Server is a client of the CTI Server and is designed to monitor both CTI Servers in a duplex environment and maintain the agent state during failover processing. This will create more overhead for the ICM Call Router to maintain multiple real-time feed clients. The buttons will be restored as soon as the redundant CTI Server is restored. It also processes third-party call control messages (such as "make call" or "answer call") from the CTI clients and sends these messages via the PIM interface of the PG to Cisco CallManager to process the event on behalf of the agent desktop. Upon failure of the CTI Server. The CTI Server is also critical to the operation of the Multi-Channel Options (Cisco Email Manager and Cisco Content Server) as well as the Outbound Option. if the Admin Workstation is being used to host the ConAPI interface for the Multi-Channel Options (Cisco Email Manager and Cisco Content Server). Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-37 .Chapter 3 Design Considerations for High Availability Understanding Failure Recovery ICM Call Router for the real-time feed. and the agent does not have to log on again to the desktop application. however. CTI OS agents will see their desktop buttons gray-out during the failover to prevent them from attempting to perform tasks while the CTI Server is down. Client AWs that cannot register with the primary or secondary real-time distributors will not be able to perform any Admin Workstation tasks until the distributors are restored. or Cisco Content Server systems will not be passed over the ConAPI interface until it is restored. CTI Server The CTI Server monitors the PIM data traffic for specific CTI messages (such as "call ringing" or "off hook" events) and makes them available to CTI clients such as the CTI OS Server or Cisco Agent Desktop Enterprise Server. the redundant CTI server becomes active and begins processing call events. it will prevent a failure of the primary real-time distributor from taking down the secondary distributors at the site. Cisco Email Manager. CTI Server is redundant on duplex CTI Servers or can be co-resident on the PG servers. each real-time distributor could be deployed in its own Admin Site regardless of the physical site of the device. any configuration changes made to the ICM. (See Figure 3-23. Additionally. Alternatively. maintain agent state in the event of a failure.

IP messaging TDM voice lines Ethernet lines ICM B 126160 ICM central controllers WedView Reporting Client CTI OS Considerations CTI OS acts as client to CTI Server and provides agent and supervisor desktop functionality for IPCC. The CTI Object Server (CTI OS) consists of two services. CTI data.Chapter 3 CTI OS Considerations Design Considerations for High Availability Figure 3-23 Redundant CTI Servers with No Cisco Agent Desktop Server Installed T1 lines Public network T1 lines Voice gateway 1 Voice gateway 2 Gatekeepers V MDF switch 1 TDM access IDF switch 1 IDF switch 2 V MDF switch 2 Firewall Cisco CallManager cluster Publisher Sub 1 M M M Sub 2 IP IVR 1 IP IVR group IP IVR 2 Corporate LAN CTI server A CTI server B CM PG A CM PG B VRU PG A AW A VRU PG B AW B ICM A Call control. It manages agent state and functionality during a failover of CTI Server. The CTI OS Agent Desktop load-balances the agents between the redundant servers automatically. and it can be deployed as redundant CTI OS Servers. If either of these two fails. Cisco IP Contact Center Enterprise Edition SRND 3-38 OL-7279-04 . Therefore. it is important to keep both of these services active at all times. the CTI OS service and the CTI driver. and agents sitting next to each other may in fact be registered to two different CTI OS Servers. then the active CTI OS fails-over to its peer server.

When agents log out. RASCAL. ICM failover does not force the agents to log out. all their reporting statistics stop. The Peripheral Gateways provide buffering (in memory and on disk) of the five-minute and half-hour data collected by the system to handle network connectivity failures or slow network response as well as automatic retransmission of data when the network service is restored. some data could be lost during its failover. The next time the agents log in.com/univercd/cc/td/doc/product/icm/icmentpr/icm50doc/icm5rept/index.Chapter 3 Design Considerations for High Availability Cisco Agent Desktop Considerations Cisco Agent Desktop Considerations Cisco Agent Desktop is a client of CTI OS. CTI OS maintains the agent state and information during the failover to prevent agents from being logged out by the system because of the failover. physical failure of both Peripheral Gateways in a redundant pair can result in loss of the half-hour or five-minute data that has not been transmitted to the Central Controller. however. Typically. available at http://www. Therefore. but their agent desktop functionality is restored back to its pre-failover state. The Call Routers process the data and send it to their local Logger and Database Servers for historical data storage. that data is then replicated to the HDS server from the Logger as it is written to the Logger database. Cisco Agent Desktop software is aware of the redundant Cisco Agent Desktop Servers and will automatically fail-over in the event of a Cisco Agent Desktop Server process or hardware failure. it does reset their agent statistics when the ICM failover is complete. For further information. Chat. or other products that depend on IPCC to function properly might not be able to handle an IPCC failover. This section examines what happens to other critical areas in the IPCC solution during and after failover. Although IPCC may stay up and running. Other Considerations An IPCC failover can affect other parts of the solution.cisco. at the end of each five-minute and half-hour interval. each Peripheral Gateway will gather the data it has kept locally and send it to the Call Routers. and so forth) can also be deployed redundantly to allow for failover of the core Cisco Agent Desktop components. five-minute and half-hour intervals to build its reporting database. their real-time statistics start from zero. If the deployment has the Historical Data Server (HDS) option.htm Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-39 . The Cisco Agent Desktop Servers (Enterprise Server. refer to the Cisco IP Contact Center Reporting Guide. However. Cisco recommends the use of redundant Peripheral Gateways to reduce the chance of losing both physical hardware devices and their associated data during an outage window. If the Cisco CallManager Peripheral Gateway or CTI Server (CG) fail-over. which provides for automatic failover and redundancy for the Cisco Agent Desktop Server. Reporting The IPCC reporting feature uses real-time.

Chapter 3 Other Considerations Design Considerations for High Availability Cisco IP Contact Center Enterprise Edition SRND 3-40 OL-7279-04 .

defines the specific terms used for the input and output of the Cisco call center sizing tool. page 4-6. Examples are provided for an IPCC deployment to illustrate how resources can be impacted under various call scenarios such as call treatment in the IP IVR and agent wrap-up time. For additional call center industry terminology. if sizing is desired for such smaller intervals. refer to the definitions at http://www. and the number of voice gateway ports required to carry the traffic volume coming from the PSTN or other TDM source such as PBXs and TDM IVRs. Improper use of these terms in the tools used to size call center resources can lead to inaccurate sizing results. Common practice is to design for the average Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-1 . the section on the Cisco IPC Resource Calculator.C H A P T E R 4 Sizing Call Center Resources Central to designing an IP Contact Center (or any call center) is the proper sizing of its resources. queuing. There are weekly busy hours and seasonal busy hours. and to be consistent in the use of. This chapter discusses the tools and methodologies needed to determine the required number of call center agents (based on customer requirements such as call volume and service level desired). for more details on various call center terms and concepts discussed in this document.html (There are also other resources available on the internet for defining call center terms. the number of IP IVR ports required for various call scenarios (such as call treatment.com/glossary. refer to the IPCC product documentation available online at http://www. There is one busiest hour in the year. The terms listed in this section are the most common terms used in the industry for sizing call center resources.cisco.thecallcenterschool. and months. The busy hour or interval varies over days. Also. The busy interval occurs when the most traffic is offered during this period of the day. Call Center Basic Traffic Terminology It is important to be familiar with. such as 30 minutes or 15 minutes.) In addition to the terms listed in this section. These tools and methodologies are intended as building blocks for sizing call center resources and for any telephony applications in general. The methodologies and tools presented in this chapter are based on traffic engineering principles using the Erlang-B and Erlang-C models applied to the various resource in an IPCC deployment.com Busy Hour or Busy Interval A busy interval could be one hour or less. IPC Resource Calculator. weeks. common call center terminology. and self-service applications).

recording notes from the call. Use the following formula to calculate the Erlang value: Traffic in Erlangs = (Number of calls in the busy hour ∗ AHT in sec) / 3600 sec The term is named after the Danish telephone engineer A. it is not practical to add or remove trunks or ports daily. or 1 hour) of calls on the same circuit. The Erlang is based on having 3600 seconds (60 minutes.Chapter 4 Call Center Basic Traffic Terminology Sizing Call Center Resources busy hour (the average of the 10 busiest hours in one year). additional trunks could be added during the peak season and disconnected afterwards. however. Calls normally originate from the PSTN. when staffing is required to accommodate a marketing campaign or a seasonal busy hour such as an annual holiday peak. although calls to a call center can also be generated internally.) If a contact center receives 30 calls in the busy hour and each call lasts for six minutes. Talk Time Talk time is amount of time an agent spends talking to a caller. agents. such as PSTN trunks and gateway ports. Servers Servers are resources that handle traffic loads or calls. Busy Hour/Interval Call Attempts (BHCA) The BHCA is the total number of calls during the peak traffic hour (or interval) that are attempted or received in the call center. we will assume that all calls offered to the voice gateway are received and serviced by the call center resources (agents and IP IVR ports). and queuing time. If the contact center receives 100 calls averaging 36 seconds each in the busy hour. This average is not always applied. K. this equates to 180 minutes of traffic in the busy hour." such as call treatment time. AHT is the sum of agent talk time and agent wrap-up time. Wrap-Up Time (After-Call Work Time) After the call is terminated (caller finishes talking to an agent and hangs up). but staffing requirements for the rest of the day are calculated separately for each period (usually every hour) for proper scheduling of agents to answer calls versus scheduling agents for offline activities such as training or coaching. (One circuit is busy for one hour regardless of the number of calls or how long the average call lasts. such as by a help-desk application. the originator of queuing theory used in traffic engineering. or 1 Erlang (3600 sec/3600 sec). In some retail environments. For the sake of simplicity. or 3 Erlangs (180 min/60 min). then total traffic received is 3600 seconds. In a call center. It is a commonly used term that refers to the sum of several types of "handle time. or any other activity performed until an agent becomes available to answer another call. Cisco IP Contact Center Enterprise Edition SRND 4-2 OL-7279-04 . The IPCC term for this concept is “after-call work time. voicemail ports. or port. There are many types of servers in a call center. Erlang. Erlang Erlang is a measurement of traffic load during the busy hour. so these resources are sized for the peak periods.” Average Handle Time (AHT) AHT is the mean (or average) call duration during a specified time period. and IVR ports. staffing for the maximum number of agent is determined using peak periods. For trunks or IVR ports (in most cases). including the time an agent places a caller on hold and the time spent during consultative conferences. trunk. In its most common definition. talk time. the wrap-up time is the time it takes an agent to "wrap up" the call by performing such tasks as updating a database.

refer to the IPCC glossary available online at http://www. Some calculators perform this calculation transparently using the BHCA and AHT for ease of use and convenience.Chapter 4 Sizing Call Center Resources Call Center Basic Traffic Terminology Busy Hour Traffic (BHT) in Erlangs BHT is the traffic load during the busy hour and is represented as the product of the BHCA and the AHT normalized to one hour: BHT = (BHCA ∗ AHT seconds) / 3600.com Queuing When all agents are busy with other callers or are unavailable (after call wrap-up mode). if the call center receives 600 calls in the busy hour. An IVR can also be used to handle all calls initially (call treatment. A 1% blockage is a typical value to use for PSTN trunks. For example. grade of service is the percentage of calls that are blocked or that receive busy tone (no trunks available) out of the total BHCA. In that case. a grade of service of 0. such as 80% of all calls answered within 30 seconds in the busy hour. In the case of a voice gateway. the average time calls will spend in queue. then the busy hour traffic load is (600 * 2/60) = 20 Erlangs. All resources might be occupied when a user places a call. and trunks. or BHT = (BHCA ∗ AHT minutes) / 60 For example. prompt and collect – such as DTMF input or account numbers – or any other information gathering) and for self-service applications where the caller is serviced without needing to talk to an agent (such as obtaining a bank account balance. Your contact center’s service level goal drives the number of agents needed. The nature of the blocked call will determine the model used for sizing the particular resources. Grade of Service (Percent Blockage) This measurement is the probability that a resource or server is busy during the busy hour. and so forth). and the number of PSTN trunks and IP IVR ports needed. and it refers to the percentage of the offered call volume (received from the voice gateway and other sources) that will be answered within x seconds. averaging 2 minutes each. For an additional definition of service level within IPCC products. This blockage typically applies to resources such as voice gateway ports. IVR ports. The percentage of calls queued and the average time spent in the queue are determined by the service level desired and by agent staffing. Each of these scenarios requires a different number of IP IVR ports to handle the different applications because each will have a different average handle time and Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-3 . airline arrival/departure times. or if they hear a tone (such as a busy tone) or announcement.cisco. Cisco's IPCC solution uses an IP IVR to place callers in queue and play announcements. the call is lost or blocked. Callers are considered blocked if they are rerouted to another route or trunk group. subsequent callers must be placed in a queue until an agent becomes available. the percentage of calls that will be queued. Blocked Calls A blocked call is a call that is not serviced immediately.01 means that 1% of calls in the busy hour would be blocked. PBX lines. A support-oriented call center might have a different service level goal. BHT is typically used in Erlang-B models to calculate resources such as PSTN trunks or self-service IVR ports. delayed and put in a queue. but different applications might require different grades of service. Service Level This term is a standard in the contact center industry. A typical value for a sales call center is 90% of all calls answered in less than 10 seconds (some calls will be delayed in a queue). where x is a variable.

there are mainly two traffic models that are commonly used in sizing call center resources. It is helpful first to understand the anatomy of an inbound call center call as it relates to the various resources used and the holding time for each resource. delayed) Call arrival patterns (random.) Call Center Resources and the Call Timeline The focus of this chapter is on sizing the following main resources in a call center: • • • Agents Gateway ports (PSTN trunks) IP IVR ports. This delay could be a few seconds on average. Choosing the right model depends on three main factors: • • • Traffic source characteristics (finite or infinite) How lost calls are handled (cleared. Erlang Calculators as Design Tools Many traffic models are available for sizing telephony systems and resources. The number of trunks or gateway ports needed for each of these applications will also differ accordingly. for examples on how to calculate the number of trunks and gateway ports needed.Chapter 4 Call Center Resources and the Call Timeline Sizing Call Center Resources possibly a different call load. held. Figure 4-1 Inbound Call Timeline Ring IVR Answers Agent Answers Agent Talk Time Agent Hangs-up Agent Ready Network Treatment/Queue Delay Wrap-up Time Time Trunk is Occupied Time IVR is Occupied Time Agent is Occupied 126044 Ring delay time (network ring) should be included if calls are not answered immediately. For purposes of this document. and Trunks. (See the section on Sizing Call Center Agents. Erlang calculators are designed to help answer the following questions: • • • How many PSTN trunks do I need? How many agents do I need? How many IVR ports do I need? Cisco IP Contact Center Enterprise Edition SRND 4-4 OL-7279-04 . peaked). Figure 4-1 shows the main resources used and the occupancy (hold/handle time) for each of these resources. smooth. page 4-11. There are many other resources on the internet that give detailed explanations of the various models (search using "traffic engineering"). Erlang-B and Erlang-C. and it should be added to the trunk average handle time. IVR Ports.

If all agents are busy. Cisco does not endorse any particular vendor product. It assumes the following: • • Call arrival is random. but not all. gateway ports. the next two sections present a brief description of the generic Erlang models and the input/output of such tools (available on the internet) to help the reader who does not have access to the Cisco IPC Resource Calculator or who chooses to use other non-Cisco Erlang tools. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-5 . are the same regardless of the tool itself. The first version discussed here is designed to size call center resources. called Cisco IPC Resource Calculator. Erlang-C The Erlang-C model is used to size agents in call centers that queue calls before presenting them to agents. and the methodology used. and the average queue time for these calls. or percent blockage. Basic examples are included later in this chapter to show how to use the Cisco IPC Resource Calculator. Erlang-B The Erlang-B model is used to size PSTN trunks. but they all use the two basic traffic models. This model assumes: • • Call arrival is random. If all trunks/ports are occupied. Erlang-B and Erlang-C. the percentage of calls delayed or queued when no agents are available. The input parameters required for this model are: • • • The number of calls in the busy hour (BHCA) to be answered by agents The average talk time and wrap-up time The delay or service level desired. it is up to the customer to choose which tool suits their needs. Cisco has chosen to develop its own telephony sizing tool.Chapter 4 Sizing Call Center Resources Erlang Calculators as Design Tools Before you can answer these basic questions. new calls will be queued and not blocked. expressed as the percentage of calls answered within a specified number of seconds The output of the Erlang-C model lists the number of agents required. and they list which model to use for sizing the specific call center resource (agents. of the input fields are known or available. Additional examples are also included to show how to use the tool when some. and IP IVR ports). you must have the following minimum set of information that is used as input to these calculators: • • • • The busy hour call attempts (BHCA) Average handle time (AHT) for each of the resources Service level (percentage of calls that are answered within x seconds) Grade of service. desired for PSTN trunks and IP IVR ports The remaining sections of this chapter help explain the differences between the Erlang-B and Erlang-C traffic models in simple terms. new calls are lost or blocked (receive busy tone) and not queued. There are various web sites that provide call center sizing tools free of charge (some offer feature-rich versions for purchase). gateway ports. The input required for any of the tools. Before discussing the Cisco IPC Resource Calculator. or IP IVR ports.

and the latest versions are available at http://tools.cisco. Cisco IP Contact Center Enterprise Edition SRND 4-6 OL-7279-04 .Chapter 4 Cisco IPC Resource Calculator Sizing Call Center Resources The input and output for the Erlang B model consists of the following three factors. Cisco is continually enhancing the IPC Resource Calculators. You need to know any two of these factors. • Busy Hour Traffic (BHT). and the model will calculate the third. Grade of Service.com/partner/ipccal/index. BHT is the product of the number of calls in the busy hour (BHCA) and the average handle time (AHT). Other Erlang traffic calculators available on the Web can also be used for sizing various contact center resources. or the number of IP IVR or gateway ports • • Cisco IPC Resource Calculator Figure 4-2 is a snapshot of the current Cisco IP Communications (IPC) Resource Calculator.htm The Cisco IPC Resource Calculators are accessible to Cisco internal employees and Cisco partners. These tools are based on industry Erlang traffic models. followed by a definition of each of the input and output fields. or the number of hours of call traffic (in Erlangs) during the busiest hour of operation. how to use them. and how to interpret them. or the percentage of calls that are blocked because not enough ports are available Ports (lines).

if desired. It helps to distinguish the different scenarios run (exported and saved) for a project or a customer proposal. Calls Per Interval (BHCA) The number of calls attempted during the busiest interval. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-7 . It can also be used to calculate staffing requirements for any interval of the day (non-busy hour staffing). This choice of interval length allows the flexibility to calculate staffing requirements more accurately for the busiest periods within one hour. You can choose the interval to be 60 minutes (busy hour). 30 minutes (half-hour interval). you must provide the following input data: Project Identification This field is a description to identify the project or customer name and the specific scenario for this calculation. or busy hour call attempts (BHCA).Chapter 4 Sizing Call Center Resources Cisco IPC Resource Calculator Figure 4-2 Cisco IPC Resource Calculator IPC Resource Calculator Input Fields (What You Must Provide) When using the Cisco IPC Resource Calculator. or 15 minutes.

IPC Resource Calculator Output Fields (What You Want to Calculate) The IPC Resource Calculator calculates the following output values based on your input data: Recommended Agents The number of seated agents (calculated using Erlang-C) required to staff the call center during the busy hour or busy interval. If the number of agents is too far from the recommended number. the calculator will show an error message. This value includes time talking and time placed on hold by the agent. Check to Manually Enter Agents The user may manually enter the number of agents. If seated agents enter into another mode (other than the wrap-up mode) where they are unavailable to answer calls.Chapter 4 Cisco IPC Resource Calculator Sizing Call Center Resources Service Level Goal (SLG) The percentage of calls to be answered within a specified number of seconds (for example. or IVR menuing) to route the call to an agent. (This queuing time is calculated in the output section of the calculator. then this additional time should be included (averaged for all calls) in the after-call work time. 90% within 30 seconds). after checking this box. This entry assumes that agents are available to answer calls when they are not in wrap-up mode. Cisco IP Contact Center Enterprise Edition SRND 4-8 OL-7279-04 . 1% blockage means that 99% of all calls attempted from the PSTN during the interval will have a trunk port available on the gateway to reach the IVR or an agent. Blockage % (PSTN Trunks) This field is also known as Grade of Service. Average After-Call Work Time The average agent wrap-up time in seconds after the caller hangs up. It does not include time spent in the IVR for call treatment or time in queue. Average Call Talk Time The average number of seconds a caller will be on-line after an agent answers the call. or the percentage of calls that will receive busy tone (no trunks available on the gateway) during the busy hour or interval. Wait Before Abandon (Tolerance) This field is the amount of time in seconds that a contact center manager expects callers to wait in queue (tolerance) for an agent to become available before they abandon the queue (hang up). The error will appear any time the number of calls queued reaches 0% or 100%.) The call treatment time should not include calls arriving at the IVR for self-service with no intention to route them to agents. For example. Self-service IVR applications should be sized separately using an Erlang-B calculator. until the call is terminated. This time includes greetings and announcements as well as time to collect and enter digits (known as prompt and collect. Average Call Treatment Time (IVR) The average time in seconds a call spends in the IVR before an attempt is made to send the call to an agent. This value has no effect on any of the output fields except the abandon rate (number of calls abandoned). It does not include queuing time if no agents are available.

Average Queue Time (AQT) The average amount of time in seconds that calls will spend in queue waiting for an agent to become available during the interval. This value is the sum of the average talk time. less than 30 seconds). if the SLG is 90% of calls answered within 30 seconds. These calls do not have to wait in queue for an agent. the average IVR delay (call treatment).Chapter 4 Sizing Call Center Resources Cisco IPC Resource Calculator Calls Completed (BHCC) This field is the busy hour call completions (BHCC). It is the number of calls attempted minus the number of calls blocked. Queued Calls The percentage of all calls queued in the IVR during the busy hour or interval. then there are 10% of calls queued beyond 30 seconds. and the average speed of answer. Calls Answered Beyond SLG The percentage of calls answered beyond the set target time entered in the Service Level Goal (SLG) field. After-call work time is not included in this calculation. Calls Answered Within Target SLG The percentage of calls that are answered within the set target time entered in the Service Level Goal (SLG) field. and the remaining 15% of calls are queued and answered within 30 seconds (the SLG). It includes a portion of calls queued if no agents are available within the SLG (for example. Average Call Duration The total time in seconds that a call remained in the system. For example. but only the portion queued beyond the SLG target (for example. then 75% of the calls would be answered immediately. Average Speed of Answer (ASA) The average speed of answer for all calls during the interval. This value includes a portion of all calls queued. Agents Utilization The percentage of agent time engaged in handling call traffic versus idle time. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-9 . if the SLG is 90% of calls answered within 30 seconds and queued calls are 25%. more than 30 seconds). This value does not include any call treatment in the IVR prior to attempting to send the call to an agent. This value is the calculated percentage of calls answered immediately if agents are available. or the number of expected calls completed during the busy hour. the calls answered beyond SLG would be 10%. This value includes calls queued and then answered within the Service Level Goal as well as calls queued beyond the SLG. For example. including queued calls and calls answered immediately. As in the preceding example. if 25% of the calls are queued (including those beyond the target of 30 seconds). Calls Answered Immediately The percentage of calls answered immediately by an agent after they receive treatment (if implemented) in the IVR. It does not include all queued calls because some calls will be queued beyond the SLG target.

IVR Ports Required for Queuing The number of IVR ports required to hold calls in queue while the caller waits for an agent to become available. then additional trunks would be required. Cisco IP Contact Center Enterprise Edition SRND 4-10 OL-7279-04 . and agent talk time. If this output is zero. However. Pooling the ports for treatment and queuing results in fewer ports for the same amount of traffic than if the traffic is split between two separate IVR port pools or groups. This format makes comparing results of multiple scenarios easy to analyze. queuing in the IVR (if no agents are available). If several smaller trunk groups are used instead. Cisco recommends that you configure the number of ports required for queuing in a separate group. This value is based on an Erlang-B calculation using the number of queued calls and the average queue time for those calls. calculated by dividing the offered load (Erlangs) by the number of trunks Voice Trunks Required The number of PSTN gateway trunks required during the busy interval. based on the number of calls answered by the voice gateway and the average hold time of a trunk during the busy interval. click on the Submit button to compute the output values. This value is based on an Erlang-B calculation using the number of calls answered and the average call treatment time (average IVR delay). it means that all queued calls were answered by an agent in less than the specified abandon time (longest queued call time is less than the abandon time).Chapter 4 Cisco IPC Resource Calculator Sizing Call Center Resources Calls Exceeding Abandon Tolerance The percentage (and number) of calls that will abandon their attempt during the interval. This CSV file could be imported into a Microsoft Excel spreadsheet and formatted for insertion into bid proposals or for presentation to clients or customers. PSTN Trunk Utilization This value is the occupancy rate of the PSTN trunks. IVR Ports Required for Call Treatment The number of IVR ports required for calls being treated in the IVR. Total IVR Ports Requirement This value is the total number of IVR ports required if the system is configured with separate port groups for queuing and treatment. This calculated number assumes all trunks are grouped in one large group to handle the specified busy hour (or interval) calls. This value includes average time of call treatment in the IVR. Submit After entering data in all required input fields. therefore smaller groups are less efficient. with the ability to overflow to other groups if available. Export Click on the Export button to save the calculator input and output in a comma-separated values (CSV) format to a location of your choice on your hard drive. Multiple scenarios could be saved by changing one or more of the input fields and combining all outputs in one Excel spreadsheet by adding appropriate titles to columns reflecting changes in the input. based on expected Tolerance time specified in the input.

if available. No call treatment (prompt and collect) is implemented initially. calls are queued until an agent becomes available. No after-call work time (agent wrap-up time = 0 seconds). Average call talk time (agent talk time) = 150 seconds (2 minutes and 30 seconds). and PSTN trunks) in this basic example. along with the impact on required resources. The first example is a basic call flow. Desired grade of service (percent blockage) for the PSTN trunks on the voice gateway = 1%. Desired service level goal (SLG) of 90% of calls answered within 30 seconds. subsequent examples build upon it by adding different scenarios. Calls are routed directly to an agent.000. pressing the Submit button at the bottom of the calculator results in the output shown in Figure 4-3. This basic example uses the following input data: • • • • • • • Total BHCA (60-minute interval) into the call center from the PSTN to the voice gateway = 2. and Trunks The call center examples in this section illustrate how to use the IPC Resource Calculator in various scenarios. All calls will be routed to available agents or will be queued until an agent becomes available. Basic Call Center Example This example forms the basis for all subsequent examples in this chapter. such as call treatment and agent wrap-up time. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-11 . Wait time before abandoned (tolerance) = 150 seconds (2 minutes and 30 seconds). IVR Ports. where all incoming calls to the call center are presented to the voice gateway from the PSTN. otherwise. IVT ports. After a brief explanation of the output results highlighting the three resources (agents. to demonstrate how the various resources are impacted by different call scenarios. IVR Ports. and Trunks Sizing Call Center Agents. After entering the above data in the input fields.Chapter 4 Sizing Call Center Resources Sizing Call Center Agents.

This result also means that 7% of the calls will be answered beyond the 30 second SLG. This is because we have requested a provisioning of 1% blockage from our PSTN provider. the calculated service level is 93% of calls answered within 30 seconds. there will be 31. IVR Ports Required for Queuing In this basic example. The average queue time for queued calls is 20 seconds. or 627 calls) and the average queue time (20 seconds). with 90 agents. The calculator shows the percent and number of calls queued (31. which results in 20 calls (1%) being blocked and receiving busy tone out of the total 2000 calls.7% of calls queued. Had there been one less agent (89 instead of 90). as shown in the output in Figure 4-3.7%. some will queue less than 30 seconds and others longer. Notice that. which exceeds the desired 90% requested in the input section. and Trunks Sizing Call Center Resources Figure 4-3 Basic Example Notice that the output shows 1980 calls completed by the voice gateway. then 68. the IP IVR is being used as a queue manager to queue calls when no agents are available. out of the total of 2000 calls attempted from the PSTN. and calls will be queued to this resource (agents). In addition.3% of the calls will be answered immediately without delay in a queue. If 31. Agents The result of 90 seated agents is determined by using the Erlang-C function imbedded in the IPC Resource Calculator. Cisco IP Contact Center Enterprise Edition SRND 4-12 OL-7279-04 .Chapter 4 Sizing Call Center Agents.7% of the calls will queue. IVR Ports. then the 90% SLG would not have been met.

Using a 15-second call treatment and keeping all other inputs the same. The Erlang-B function is used here because a call would receive a busy signal (be lost) if no trunks or IVR ports were available to answer or service the call. Total trunks required to carry this total traffic load above is 103 trunks. This calculation does not include trunks that might be needed for call scenarios that require all calls to be treated first in the IVR before they are presented to available agents. and service level) has not changed. talk time. More IP IVR ports are also required to carry this extra load. all incoming calls to the call center are presented to the voice gateway from the PSTN. Figure 4-4 shows the number of PSTN trunks (112) and IP IVR ports (16) required in addition to the existing 10 ports for queuing. IVR Ports. PSTN Trunks (Voice Gateway Ports) The following traffic loads impact the required number of trunks: • • The load presented by the incoming traffic (1980 answered calls). in addition to the ports required for queued calls. If no agents are available. That scenario is discussed in the next example. with an average agent talk time for all calls of 150 seconds. Call treatment (prompt and collect) does not impact the number of required agents because the traffic load presented to the agents (number of calls. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-13 . with an average queue time of 20 seconds when no agent is available to answer the call immediately. for the period of the call treatment holding time. The impact of presenting all calls to the IP IVR is that the PSTN trunks are held longer.7% queued). calls are queued until an agent becomes available. Call Treatment Example This example builds upon the basic example in the preceding section. The following traffic load impacts the required number of IP IVR ports for queuing derived from the output of the calculator: • The traffic load presented by the calls that queue (627 queued) with an average queue time of 20 seconds when no agents are available to answer the call immediately. The traffic load presented by the calls that queue (31. This load shows that 10 IVR ports are required for queuing. and Trunks These two outputs from the Erlang-C calculation are then used as inputs for the imbedded Erlang-B function in the calculator to compute the number of IVR ports required for queuing and the corresponding PSTN trunks required. then calls are immediately routed to the IP IVR for call treatment (such as an initial greeting or to gather account information) before they are presented to an agent. Again. if available.Chapter 4 Sizing Call Center Resources Sizing Call Center Agents.

Chapter 4 Sizing Call Center Agents. IVR Ports. Assuming the SLG and traffic load also remain the same. so trunk and IP IVR resources are not impacted and should remain the same. and Trunks Sizing Call Center Resources Figure 4-4 Call Treatment in IVR After-Call Work Time (Wrap-up Time) Example Using the previous example. Cisco IP Contact Center Enterprise Edition SRND 4-14 OL-7279-04 . We can then use the IPC Resource Calculator to determine the number of agents required to handle the same traffic load (see Figure 4-5). we now add the assumption that agents will spend an average of 45 seconds of work time (wrap-up time) after each call. additional agents would be required only to service the call load and to compensate for the time agents are in the wrap-up mode. After-call work time (wrap-up time) begins after the caller hangs up.

and no additional agents are required. Examples include accessing bank account balances and transactions. a standalone Erlang-B calculation is necessary to compute the additional PSTN trunks and IVR ports required. as described in previous examples and illustrated in the following example. In this case. At the end of the transaction. except that there is one additional trunk (113 instead of 112). Call Center Sizing With Self-Service IVR Applications Self-service applications route calls to an IVR (Cisco IP IVR or Cisco Internet Service Node (ISN)) and present them with a menu of choices to access information from various databases. For such self-service applications. The calls are serviced in the IVR and not answered by agents. the caller hangs up and does not need to speak to an agent. only PSTN trunks (voice gateway ports) and IVR ports are required. This slight increase is not due to the wrap-up time. These trunks and IVR ports can then be added to the rest of the requirements needed in a call center for calls presented to agents. and so forth. but rather is a side effect of the slight change in the SLG (92% instead of 93%) due to rounding calculations for the required 116 agents due to wrap-up time.Chapter 4 Sizing Call Center Resources Call Center Sizing With Self-Service IVR Applications Figure 4-5 After-Call Work Time Note that trunks and IVT ports remained virtually the same. airline flight arrival and departure information. menu services such as driving directions. as shown in the following example. These self-service applications have a different call load and IVR average handle time than the call load presented to the agents. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-15 .

Chapter 4 Call Center Sizing With Self-Service IVR Applications Sizing Call Center Resources Call Center Example with IVR Self-Service Application In this example. the three traffic loads (call types) coming into this call center consist of the following: • IVR self-service calls: 18.000 ∗ 20% = 3600 calls. number dialed.000 ∗ 60% = 10. SGL = 90% of the calls to be answered within 30 seconds. we will use the Cisco IP IVR Stand-Alone Calculator (shown in Figure 4-6). Average talk time = 6 minutes (360 seconds). The average call treatment is about 3 minutes and 9 seconds (171 seconds). • High-priority calls (transferred to agents directly. and a portion of the calls (20%) are self-serviced in the IVR without ever being transferred to an agent. and the average talk time is 5 minutes (300 seconds). Average IVR call treatment = 60 seconds. no IVR call treatment. These calls last an average of about 60 seconds before they complete their transaction and hang up. Assume PSTN blockage = 1%.000 ∗ 20% = 3600 calls. Average talk time = 5 minutes (300 seconds). For self-service applications only. we assume that the call center receives 18. SGL = 95% of the calls to be answered within 10 seconds. For high-priority and normal calls. Average IVR call treatment = 60 seconds. where no agents are required or involved. a call might have to wait in queue in the IVR if no agents are available to answer the call immediately. In summary. Another portion (20%) are identified as "high priority" callers (based on calling number. which uses Erlang-B to compute the necessary trunks and IP IVR ports. Average time in IVR for call treatment = 171 seconds. no delay in IVR): 18. Routed immediately to agents if available. • Normal calls: 18.800 calls. Cisco IP Contact Center Enterprise Edition SRND 4-16 OL-7279-04 . prompt and collect) before they are transferred to an agent. We can compute the required resources for each of the three types of calls as follows: IVR Self-Service Calls • • 18. or other automatic identifier) and are immediately routed to a specialized group of agents without any call treatment in the IVR but with a high service level goal of 95% of the calls to be answered within 10 seconds. • • Busy hour traffic (BHT) = (3600 calls ∗ 60 sec/3600) = 60 Erlangs.000 calls in the busy hour. The remaining portion (60%) is normal calls that are presented with a menu in the IVR (call treatment.000 ∗ 20% = 3600 calls. and they have an SLG of 90% answered within 30 seconds.

No call treatment ports are required here. titled Self Service. in the calculator produces the following results. Routed immediately to agents if available. The remaining columns could be used if you had multiple trunk and IVR groups that were not pooled together (multiple self-service applications) or if the IVR employed had the capability to queue calls at the edge (remote branch with local PSTN incoming gateway). 6 IVR ports are needed for queuing. 386 trunks are required. Figure 4-6 IVR Self-Service Calls Note There are many Erlang-B calculators available for free on the Web.000 ∗ 20% = 3600 calls. no IVR call treatment. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-17 .Chapter 4 Sizing Call Center Resources Call Center Sizing With Self-Service IVR Applications Inserting these values into the first column. as illustrated in Figure 4-6: • • 75 IVR ports for self-service 75 trunks These PSTN trunks and IVR ports are in addition to any that might be needed for priority calls (20%) and normal calls (60%) that require PSTN trunks and IVR ports for queuing and call treatment before transferring to an agent. Inserting these parameters into the IPC Resource Calculator produces the following results (as illustrated in Figure 4-7): • • • • 384 agents are required. as is the case with Cisco ISN. no IVR Call Treatment) • • • • 18. (Search on Erlang-B.) High-Priority Calls (Transferred to Agents Directly. Average talk time = 6 minutes (360 seconds). SGL = 95% of the calls to be answered within 10 seconds.

Chapter 4 Call Center Sizing With Self-Service IVR Applications Sizing Call Center Resources Figure 4-7 High-Priority Calls Normal Calls • • • • 18. Inserting these parameters into the IPC Resource Calculator produces the following results (as illustrated in Figure 4-8): • • • • 907 agents are required. Average time in IVR for call treatment = 171 seconds. 563 IVR ports are needed for call treatment. 44 IVR ports are needed for queuing. SGL = 90% of the calls to be answered within 30 seconds. Average talk time = 5 minutes (300 seconds). 1469 trunks are required. Cisco IP Contact Center Enterprise Edition SRND 4-18 OL-7279-04 .000 ∗ 60% = 10.800 calls.

we can add the results to determine the total required resources of each type (agents. then you must enter the number of call treatment and queuing ports into the Configuration and Ordering Tool for proper sizing of server resources.com/en/US/partner/products/sw/custcosw/ps1844/prod_how_to_order.Chapter 4 Sizing Call Center Resources Call Center Sizing With Self-Service IVR Applications Figure 4-8 Normal Calls Now that we have sized all the resources required for the three types of calls in this call center example. You can access the Configuration and Ordering Tool at http://www. and IVR ports): • • • • • • • • Agents for high-priority calls (calls answered by agents. no IVR) = 384 Agents for normal calls (calls transferred to agents after IVR treatment) = 907 Total agents = 384 + 907 = 1291 IVR ports for self-service = 75 IVR ports for queuing = 6 + 40 = 46 IVR ports for call treatment = 540 Total IVR ports = 75 + 46 + 540 = 661 Total PSTN trunks = 75 + 386 + 1469 = 1930 If IP IVR is used. refer to the section on Sizing ISN Components.cisco. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-19 . for additional details on sizing ISN servers.html If Cisco ISN is the IVR type used. page 4-20. PSTN trunks.

page 4-24 ISN Server Sizing According to the Cisco Internet Service Node Technical Reference (available at http://www. Note This section uses the same example as in the preceding Call Center Example with IVR Self-Service Application. Assume a portion of the calls. if the ISN uses the IP Transfer method to route a call to an agent. then ISN no longer has any control over that call. if an Outpulse or IN Transfer is used to route a call to an agent. but it reiterates the parameters of that example for clarity and simplicity. These calls last an average of about 60 seconds before they complete their transaction and hang up. 60%. will be identified as high-priority callers (based on calling number. Also assume that another portion of the incoming calls. The traffic loads (call types) coming into this call center are as follows: • IVR self-service calls: 18. however. Average IVR call treatment = 60 seconds. is normal calls that will be presented with IVR treatment by the ISN before they are transferred to an agent with an SLG of 90% answered within 30 seconds. unless those calls are unable to find an agent and are subsequently treated by the ISN. 20%. number dialed. or other automatic identifier) and will be routed immediately to a specialized group of agents with a high service level goal (SLG) of 95% of the callers to be answered within 10 seconds without any intended ISN involvement (no call treatment).com).000 ∗ 20% = 3600 calls. or it can be a call that the ISN has transferred to an agent and that is still being monitored/controlled by the ISN. an ISN Combo Box (an ISN Application server and an ISN Voice Browser hosted on the same server) deployed in the common comprehensive ISN deployment model can support 300 effective calls.000 calls. so that call does not count as an effective call. In the latter case. are self-serviced in the IVR without ever being transferred to an agent.cisco. page 4-20 Sizing ISN Licenses. for example. On the other hand. 20%. Note. calls that are transferred to agents directly without ISN (Voice Browser) control or involvement do not count as effective calls either. then the ISN is still monitoring that call and it counts as an effective call. In addition. page 4-23 Cisco IOS Gateway Sizing. that a small percentage of these calls will not be able to reach an agent immediately and will have to be diverted for queuing by the ISN. ISN Server Sizing Example Consider an example where a call center receives BHCAs of 18. The average call treatment is 3 minutes and 9 seconds (171 seconds) and the average talk time is 5 minutes (300 seconds). page 4-24 Prompt Media Server Sizing. page 4-16. Cisco IP Contact Center Enterprise Edition SRND 4-20 OL-7279-04 . page 4-24 ICM Peripheral Gateway (PG) Sizing. The remaining portion.Chapter 4 Sizing ISN Components Sizing Call Center Resources Sizing ISN Components Internet Service Node (ISN) sizing involves the following components: • • • • • ISN Server Sizing. An effective call can be a call that is undergoing call treatment or queuing in the IVR on the Cisco IOS gateway (under VXML control of the ISN).

with no ISN involvement or call treatment (using the Cisco IPC Resource Calculator): – 384 agents are required – 386 trunks (no VXML required) – 7 ports for queuing if calls cannot reach an agent immediately – No IVR ports are required • Normal calls (using the Cisco IPC Resource Calculator): – 907 agents are required – 1469 trunks – 44 ports for queuing – 563 ports for IVR (prompt and collect) Totaling the Results Now that we have calculated all the resources required for the three types of calls. After computing the required IVR ports and agents for each of these call types using the tools and methodology described in chapter on Sizing Call Center Resources. • Normal calls: 18. In our example. the totals are: • • Ports required for IVR = (75 + 563) = 638 Ports required for queuing = (7 + 44) = 51 Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-21 . the agents are all IPCC agents. Average talk time = 5 minutes (300 seconds). we obtain the following results: • IVR self-service calls (using the Cisco IP IVR standalone Erlang-B calculator): – 75 ports for IVR (prompt and collect) – 75 trunks • High-priority calls transferred to agents directly. we can total the results to determine the number of effective calls needed to size the ISN properly. when the ISN routes calls to the agents. SLG = 90% of the callers to be answered within 30 seconds. call must be queued by ISN. no IVR call treatment. Average talk time = 6 minutes (360 seconds).000 ∗ 20% = 3600 calls. SLG = 95% of the callers to be answered within 10 seconds. a call might have to wait in queue in the IVR (ISN) if no agents are available to answer the call. For this example. which means that the ISN continues to monitor those calls.000 ∗ 60% = 10800 calls. Average IVR time for call treatment = 171 seconds. Calls routed immediately to agents if available. the ISN uses the IP Transfer routing method. In the latter two call types. Therefore.Chapter 4 Sizing Call Center Resources Sizing ISN Components • High-priority calls (transferred to agents directly): 18. Remember that an effective call is a call undergoing IVR call treatment or queuing treatment by the ISN. or it is a call that the ISN has transferred to an agent but that the ISN still needs to monitor. page 4-1. high-priority and normal calls. If agent is not available.

the total simultaneous number of effective calls for ISN sizing purposes is: 689 (IVR and queuing) + 921 (transferred) = 1610 effective calls Each ISN Combo Box supports 300 effective calls. (For simplicity. the Cisco IOS gatekeeper and Cisco CallManager are not shown. The number of calls transferred to IPCC agents by the ISN (which still require monitoring by the ISN) includes the simultaneous calls handled by the 907 agents needed for normal calls (because the ISN treated every normal call before sending it to an agent) plus a slight extra amount for the high-priority calls that are transferred to agents after being queued by ISN (because they could not initially reach agents).) Figure 4-9 ISN Server Sizing Example 921 calls transferred to agents by ISN Other calls routed to agents without ISN involvement IP ISN PSTN VXML/H. so for our example we will need: 1610/300 = 6 ISN Combo Boxes An additional ISN Combo Box is normally recommended for redundancy. which in this case is: (7 ∗ 2) = 14 extra calls The number of transferred calls to agents monitored by ISN in this example is. where the IVR queuing treatment is physically performed on Cisco IOS gateways (using the ISN Comprehensive deployment model). the combined IVR and queuing load on the ISN is 689 simultaneous calls.Chapter 4 Sizing ISN Components Sizing Call Center Resources • • • PSTN trunks (with VXML) = 75 + 1469 = 1544 PSTN trunks (no VXML) = 386 PSTN trunks (total) = 75 + 1469 + 386 = 1930 Thus. therefore: 907 + 14 = 921 simultaneous calls Thus.323 V 689 calls getting IVR/queuing on an IOS gateway under ISN ISN sees an “effective” load of 689 + 921 = 1610 calls GED125 PG ICM Cisco IP Contact Center Enterprise Edition SRND 4-22 132075 OL-7279-04 . The extra amount needed for the these high-priority calls is a fairly complex calculation that can be approximated in most cases by simply doubling the number of ISN queue ports required for the high-priority calls. giving us a final total of: 7 ISN Combo Boxes Figure 4-9 illustrates the preceding ISN sizing example.

ISN Voice Browser session licenses are required for the number of effective calls. but it is not a bad estimate. for more information on estimating the number of agents needed. However. This simplified method can be used if you already know the number of agents and the number of IVR/queuing sessions required. then the licenses and servers would be overestimated and overpriced. assume that we know 689 sessions are required for IVR/queuing and that there are 1291 agents. The simplified method also assumes a worst-case scenario. In our example. we simply add the number of IVR/queuing sessions to the number of agents to reach a conservative estimate of 1980 effective calls. 1610 ISN Voice Browser session licenses are required. With this method. In a worst-case scenario. ISN Session Licenses In addition to the ISN software licenses. (See Agent Staffing Considerations. Alternative Simplified Method for ISN Capacity Sizing This section presents a fast. This number of effective calls requires 7 ISN Combo Boxes plus an extra for redundancy. Therefore. the following session licenses are also required: • ISN Application Server An ISN Application Server session license is required for the maximum number of simultaneous calls requiring IVR/queuing treatment by the ISN. giving us 8 ISN Combo Boxes. In other words. For the example in Figure 4-9.) Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-23 . This estimate is higher than the number derived from the more rigorous sizing calculations. 8 ISN Application Server software licenses and 8 ISN Voice Browser software licenses are also required. • ISN Voice Browser An ISN Voice Browser session license is required for the maximum number of simultaneous IVR/queuing calls plus the number of calls transferred to agents that are still being monitored by the ISN. One reason the number of agents might be overestimated is that sometimes this count includes all hired agents rather than the actual number of seated agents required for the busy hour. our example deployment in Figure 4-9 would require 7 ISN Application Server software licenses and 7 ISN Voice Browser software licenses. page 4-25. Therefore. if the estimates for the number of agents and IVR ports are very high compared to what are actually need (calculated method). but the number of ISN Voice Browser session licenses would now be (689 + 1291) = 1980. we would estimate that 689 ISN Application Server session licenses are required (for the 689 IVR/queuing sessions). as defined earlier. and it has the advantage of being conservative. In our example. page 4-23 ISN Software Licenses An ISN Application Server software license and an ISN Voice Browser software license are required for each ISN Combo Box. page 4-23 ISN Session Licenses.Chapter 4 Sizing Call Center Resources Sizing ISN Components Sizing ISN Licenses ISN deployments require the following types of licenses: • • ISN Software Licenses. 689 ISN Application Server session licenses are required. conservative alternative to the fairly rigorous ISN sizing calculations used in the preceding sections. wherein every call sent to an agent is being monitored by the ISN.

The VXML and PSTN functions can reside on the same Cisco IOS gateway or on separate gateways. Therefore. then you might be able to reduce the required number of prompt media servers. which would require 689/400 = 2 prompt media servers (plus a recommended third prompt media server for failover purposes). If you can cache some of the prompts in gateway memory. Thus.711 bandwidth (approximately 80 kbps). but it is nonetheless reasonably accurate and conservative. each call receiving prompt play from the Cisco IOS gateway requires 80 kbps of media from the prompt media server. For example. we need to play prompts (media) for 689 self-service and IVR/queued calls. refer to the chapter on Sizing IPCC Components and Servers. Cisco IP Contact Center Enterprise Edition SRND 4-24 OL-7279-04 . In most cases.wav files. 1980 gateway ingress ports are required.wav files have to be pushed to the Cisco IOS gateway using G. assume the prompt media server has a media serving capacity of 32 Mbps. It can also act as a VXML browser to perform prompt/collect and queuing treatment under ISN control. however. the Cisco IOS gateway does more than simply terminate PSTN ports. This sizing method is not rigorous. ICM Peripheral Gateway (PG) Sizing Each ISN Application Server requires an instance of the ICM VRU PIM. our example deployment would require 7 ICM VRU PIM instances. For details on VRU PG and PIM capacities. That server can support: 32 Mbps / 80 kbps = 400 simultaneous prompts per media server For the example in Figure 4-9. The other piece of required information is the media serving capacity of the web server that will act as the prompt media server. Contact your Cisco Systems Engineer (SE) for guidance on sizing Cisco IOS gateways for VXML performance. they are included with the ISN Application Server software licenses. based on our estimate of 7 ISN Combo Boxes. page 5-1 Prompt Media Server Sizing The prerecorded prompts played out by Cisco IOS gateways (under VXML control of the ISN) can be stored in gateway flash memory. To determine the maximum number of prompts that serve can support. Use the following method to estimate how many prompt media servers are required: Assume that the prerecorded prompt . For the example in Figure 4-9. divide the media serving capacity of the media server by 80 kbps per prompt. There is no explicit charge for the PIM licenses. With the ISN comprehensive deployment model.Chapter 4 Sizing ISN Components Sizing Call Center Resources Cisco IOS Gateway Sizing You can estimate the number of PSTN ingress ports required on the Cisco IOS gateway by adding all the IVR/queuing ports plus the number of agents. the prompt files are stored on a separate web server called the prompt media server. provided there is enough gateway memory to hold the prompt .

When sizing IVR ports and PSTN trunks. unplanned absence. however. You can use the Erlang-B calculator to size the number of trunks required. meetings. divide the number of agents required from Erlang-C by the productive agent percentage (or 1 minus the shrinkage percentage). it is better to over-provision than to under-provision. Agent Shrinkage Percentage This factor will vary and should be calculated for each call center. and outsourced call centers might have to meet specific service level agreements. and to input the expected call load during the busiest 15 minutes to compute required agents and resources. non-adherence to schedules. additional trunks would be required to carry the same load using one large trunk group. a good approximation would be to use a shorter busy interval. The cost of trimming excess capacity (disconnecting PSTN lines) is much cheaper than lost revenue. Many businesses compute the average of the 10 busiest hours of the year (excluding seasonal busy hours) as the busy-hour staffing.75 yields a staffing requirement of 134 agents. Retail business call centers will add temporary staff based on seasonal demands such as holiday seasons. a load of 2000 calls in 60 minutes (busy interval) requires 90 agents and 103 trunks. Run multiple interval calculations to understand daily staff requirements. Agents Required This number is based on Erlang-C results for a specific call load (BHCA) and service level. Sizing of required trunks must be done for each type of trunk group. following the same methodology as in the Call Treatment Example. page 4-13. bad service. page 4-11. or legal risks. We would get exactly the same results if we used an interval of 15 minutes with 500 calls (¼ of the call • • • Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-25 . The Erlang traffic models are not designed for such short peaks (bunched-up calls). make the following adjustments to factor in all the activities and situations that make agents unproductive or unavailable: Agent Shrinkage Agent shrinkage is a result of any time for which agents are being paid but are not available to handle calls. Customer Relationship Management (CRM) and historical reporting data help to fine-tune your provisioning computations to maintain or improve service levels. training. Call Center Design Considerations Consider the following design factors when sizing call center resources: • Compute resources required for the various busy intervals (busy hours). Consider marketing campaigns that have commercials asking people to call now. such as seasonal busy hours and average daily busy hour. it ranges from 20% to 35%. For example. such as 15 minutes instead of 60 minutes. Using our Basic Call Center Example. then 100/. Every business has a different call load throughout the day or the week. Agents Staffed To calculate this factor. if 100 agents are required from Erlang-C and the shrinkage is 25%. which can cause call loads to peak during a short period of time. If the call center receives different incoming call loads on multiple trunk groups. Some governmental agencies are required to meet minimum service levels. In most call centers. including activities such as breaks. off-phone work. and agents must be staffed accordingly (using different shifts or staffing levels). and general unproductive time.Chapter 4 Sizing Call Center Resources Agent Staffing Considerations Agent Staffing Considerations In calculating agent requirements.

and high).benchmarkportal. medium. You can use such industry statistics in the absence of any specific data about your call center (no existing CDR records.8 3.3 2. historical reports. support. make assumptions for the missing input. the day. as explained in Agent Staffing Considerations. business environment. 20011 • • Table 4-1 Inbound Call Center Statistics 80% calls answered in? (seconds) Average speed of answer (seconds) Average talk time (minutes) Average after-call work time (minutes) Average calls abandoned Average time in queue (seconds) Average number of calls closed on first contact Average TSR occupancy Average time before abandoning (seconds) Average adherence to schedule Cost per call Inbound calls per 8-hour shift Percentage attendance Average 36. • Consider agent absenteeism. available from web sites such as http://www. then 106 agents and 123 trunks would be required instead to answer all 600 calls within the same service level goal. and so forth). Principal Investigator. eBusiness Best Practices for All Industries. However. such as those shown in Table 4-1.3 21. Jon Anton.com. number of trunks.12 73.7 34. Special Executive Summary. Some trade industries publish call center metrics and statistics.9% $7.2 3.1% 66.7% 28. the number of IVR ports. and the associated traffic load (BHCA). thus requiring additional trunks and IP IVR queuing ports because more calls will be waiting in queue longer and fewer calls will be answered immediately. Allow for growth. and so forth).0 86.3% $9. In a sales call center. Cisco IP Contact Center Enterprise Edition SRND 4-26 OL-7279-04 . unforeseen events. internal help desk. Use the output of the IPC Resource Calculator as input for other Cisco configuration and ordering tools that may require as input.90 69. especially if the marketing campaign commercials are staggered throughout the hour.6 5. if 600 of the calls arrive during a 15-minute interval and the balance of the calls (1400) arrive during the rest of the hour. Increase trunk and IVR capacity to accommodate the impact of these events (real life) compared to Erlang model assumptions. the potential to capture additional sales and revenue could justify the cost of the additional agents. and load fluctuations.6 6.7% 1. number of agents.1 6.8% 84.Chapter 4 Call Center Design Considerations Sizing Call Center Resources load).3% 31. which can cause service levels to go down.9 94.3 70. Dr.1 86. and choose the best output result based on risk tolerance and impact to the business (sales. (Assumptions might not match reality.5% 75.2 86. Center for Customer-Driven Quality. and the various time zones.) If the required input is not available.2 87. run three scenarios (low. Purdue University. among other factors. Adjust agent staffing based on the agent shrinkage factor (adherence to schedules and staffing factors.5% 45.8% Best Practices 18. industry. page 4-25).

The design considerations. in other cases. IP Telephony components are a critical factor in capacity planning.com/go/srnd Additionally. available at http://www.C H A P T E R 5 Sizing IPCC Components and Servers Proper sizing of your Cisco IP Contact Center (IPCC) Enterprise solution is important for optimum system performance and scalability. including multiple Cisco CallManagers and clusters. must be considered and included in the planning of any deployment. and capacities presented in this chapter are derived primarily from testing and. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 5-1 . and scalability apply to each element within the solution as well as to the overall solution. Finally. must be utilized to support significant call loads. Sizing considerations include the number of agents the solution can support. page 5-9 Core IPCC Components When sizing IPCC deployments. and questions about capacity.cisco. while able to scale extremely well. discussed in this section. Sizing Considerations for IPCC This section discusses the following IPCC sizing considerations: • • • Core IPCC Components. and to the Cisco IP Telephony Solution Reference Network Design (SRND) guide. page 5-1 Minimum Hardware Configurations for IPCC Core Components. and other variables that affect the number. the maximum busy hour call attempts (BHCA). refer to Sizing Cisco CallManager Servers For IPCC. best practices. For additional information on Cisco CallManager capacity and sizing of IP Telephony components. IPCC Enterprise is based on a highly distributed architecture. the remaining ICM components. These factors. are affected by specific configuration element sizing variables that also have an impact on the system resources. This information is intended to enable you to size and provision IPCC solutions appropriately. performance. because of varying agent and skill group capacities. and configuration of servers required to support the deployment. Regardless of the deployment model chosen. proper sizing of the CTI OS and Cisco Agent Desktop servers should be considered together with the IP Telephony components. This chapter presents best design practices focusing on scalability and capacity for IPCC Enterprise deployments. extrapolated test data. page 6-1. page 5-8 Additional Sizing Factors. type. Good design.

Chapter 5 Sizing Considerations for IPCC Sizing IPCC Components and Servers The information presented in Figure 5-1. refer to the Cisco Intelligent Contact Management Software Bill of Materials (BOM) documentation available at http://www. Therefore. If extra performance is required beyond the limits described in the table below.com/univercd/cc/td/doc/product/icm/ccbubom/index.cisco. As always. you can and should refer to Table 5-1 for sizing information about simplexed as well as duplexed deployments. For server specifications. The following notes apply to all figures and tables in this chapter: • • The number of agents indicates the number of logged-in agents. and it serves only as a guide.htm. Note The Cisco IP Contact Center solution does not provide a quad-processor Media Convergence Server (MCS) at this time. it might be possible to use an off-the-shelf quad-processor server in lieu of the MCS 7845. Major ICM software processes were run on individual servers to measure their specific CPU and memory usage and other internal system resources. along with the sizing variables information in this chapter. Figure 5-2. This information is meant as a guide for determining when ICM software processes can be co-resident within a single server and when certain processes need their own dedicated server. Reasonable extrapolations were used to derive capacities for co-resident software processes and multiple CPU servers. Server types: – APG = Agent Peripheral Gateway – CAD = Cisco Agent Desktop – HDS = Historical Data Server – PRG = Progger – RGR = Rogger Cisco IP Contact Center Enterprise Edition SRND 5-2 OL-7279-04 . Note Sizing considerations are based upon capacity and scalability test data. Table 5-1 assumes that the deployment scenario includes two fully redundant servers that are deployed as a duplexed pair. The data is based on testing in particular scenarios. and Table 5-1 does not apply equally to all implementations of IPCC. you should be conservative when sizing and should plan for growth. While a non-redundant deployment might theoretically deliver higher capacity. no independent testing has been done to validate this theory.

0 GHz or higher) and 5 skill groups per agent.Chapter 5 Sizing IPCC Components and Servers Sizing Considerations for IPCC Figure 5-1 Minimum Servers Required for Typical IPCC Deployment with CTI Desktop Max Agent Count 250 PGR 500 RGR 1. Voice Response Unit (VRU) and Cisco CallManager components are not shown. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 5-3 . refer to Table 5-1. and CTI OS. For more than 2.000 agents.000 RGR 2. CTI Server. The Agent Peripheral Gateway (APG) consists of a Generic PG (Cisco CallManager PIM and VRU PIM). For more information about APG deployment and configuration options.000 Router Routing Database Reporting HDS HDS HDS Logger HDS APG Peripheral Gateways Agent Services APG APG APG APG APG APG 132068 The following notes apply to Figure 5-1: • • • • • Sizing is based upon the Cisco MCS 7845 (3. see Figure 5-3 and Figure 5-4.

0 GHz or higher) and 5 skill groups per agent.400 Router Routing Database Reporting HDS HDS HDS Logger HDS APG* CAD APG* CAD APG* CAD APG* CAD Peripheral Gateways Agent Services APG* CAD APG* CAD APG* CAD APG* CAD APG* CAD APG* CAD APG* CAD APG* CAD APG* 132069 CAD The following notes apply to Figure 5-2: • • • • Sizing is based upon the Cisco MCS 7845 (3. and CTI OS.Chapter 5 Sizing Considerations for IPCC Sizing IPCC Components and Servers Figure 5-2 Minimum Servers Required for Typical IPCC Deployment with Cisco Agent Desktop Max Agent Count 100 PGR CAD 300 RGR 1. For more than 2. Voice Response Unit (VRU) and Cisco CallManager components are not shown. refer to Table 5-1.200 RGR 2. Cisco IP Contact Center Enterprise Edition SRND 5-4 OL-7279-04 . The Agent Peripheral Gateway (APG) consists of a Generic PG (Cisco CallManager PIM and VRU PIM).400 agents. CTI Server.

000 AW/HDS cannot be co-resident with a Progger.0-CC1 1 MCS-7845H-3. maximum of 4 with duplexed Loggers. Maximum of 2 AW/HDS supported with a single Logger. Maximum of 100 agents on MCS-7845 if using a co-resident Cisco Agent Desktop server. Maximum of 50 simultaneous queued calls. Rogger.0-CC1 MCS-7835H-3.0-CC1 2 Server (HDS) Third-party quad server WebView Reporting Server MCS-7835I-3. and Logger Server Model1 MCS-7835I-3.500 5. Difference between MCS-7845 and MCS-7835 is the number of agents supported by AW/HDS. Router.000 6. Logger. Logger database is limited to 14 days.Chapter 5 Sizing IPCC Components and Servers Sizing Considerations for IPCC Table 5-1 Sizing Information for IPCC Components and Servers Component Progger: Peripheral Gateway.000 6. MCS-7835 not supported MCS-7835 not supported Logger MCS-7845H-3. Outbound Dialer is not supported on the MCS-7835 in the Progger configuration.0-CC1 2 250 Maximum of 125 simultaneous queued calls. Maximum of 50 agents on MCS-7845 if using a co-resident Dialer. WebView server can be co-resident with HDS for up to 50 simultaneous users.0-CC1 Number of CPUs Maximum Agents 100 Notes Cannot be co-resident with Administrative Workstation (AW) or Historical Data Server (HDS). Maximum of 25 agents on MCS-7845 if using a co-resident Cisco Agent Desktop server and Dialer.0-CC1 1 MCS-7845H-3. Router.000 6000 5.0-CC1 Administrative Workstation (AW) MCS-7835H-3.0-CC1 2 MCS-7845H-3.0-CC1 2 Third-party quad server 4 MCS-7835I-3.0-CC1 MCS-7835H-3.000 50 simultaneous WebView clients Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 5-5 .0-CC1 1 and Historical Data MCS-7845H-3. A total of 4 WebView servers may be deployed to reach 200 simultaneous WebView clients.0-CC1 2 4 500 5. or PG. Rogger: Router and Logger Router MCS-7835I-3.0-CC1 1 MCS-7845H-3.0-CC1 2 Third-party quad server 4 500 1. MCS-7835H-3.

MCS-7835H-3. See subsequent rows of this table for capacity numbers. Additional VRU PGs can be deployed to accommodate a greater number of VRU ports. Not to exceed 2 PIMs per 300 ports on a Generic PG.0-CC1 2 500 Up to 300 Cisco Agent Desktop agents are supported on a MCS-7845 server Agent PG.0-CC1 1 MCS-7845H-3. For more information on the various Agent PG deployment options.0-CC1 2 Moving the dialer off of the Agent PG has no effect (Inbound agents) + (2.0-CC1 MCS-7835H-3.0-CC1 1 MCS-7845H-3. Voice Response Unit (VRU) PG MCS-7835I-3.5 on the total number of Outbound agents supported. VRU ports should not exceed half of the maximum supported agents listed in the Maximum Agents column.0-CC1 2 100 200 Each transfer to a VRU port is equivalent to an agent. agents) < 250 (Inbound agents) + (2.0-CC1 Number of CPUs Maximum Agents 250 Notes Refer to Figure 5-3 and Figure 5-4 for more details about Agent PG configuration options. see Peripheral Gateway and Server Options. Agent PG with Outbound Voice (includes Dialer and Media Routing PG) MCS-7835H-3. total sessions With MCS-7845: • • • Single-session chat: 250 agents and 250 callers Blended collaboration: 250 agents and 250 callers Multi-session chat: 125 agents and 375 callers Cisco IP Contact Center Enterprise Edition SRND 5-6 OL-7279-04 . Maximum of 8 PIMs per MCS-7845 and 4 PIMs per MCS-7835. page 5-10. MCS-7845H-3. Up to 500 Media Routing (MR) PG co-residency requires the total sessions MCS-7845. Average of 5 Run VRU Script Nodes per call.0-CC1 1 MCS-7845H-3.0-CC1 2 Up to 500 MCS-7835 is not supported.0-CC1 1 MCS-7845H-3.Chapter 5 Sizing Considerations for IPCC Sizing IPCC Components and Servers Table 5-1 Sizing Information for IPCC Components and Servers (continued) Component Agent PG (Inbound only) Server Model1 MCS-7835I-3.5 ∗ Outbound agents) < 500 Dialer only Agent PG with Media Blender (Collaboration includes Media Routing PG) Media Blender MCS-7835H-3. ∗ Outbound Each transfer to a VRU port is equivalent to an agent.0-CC1 2 600 ports 1200 ports Use the number of ports instead of agent count.0-CC1 1 MCS-7845H-3.0-CC1 2 MCS-7835H-3. Up to 150 Cisco Agent Desktop agents are supported on an MCS-7835 server Agent PG.

Overall limitation (MCS-7845): 100 concurrent DCA sessions. database server (Primary and LAMDA) on sixth. 1000 (max) MCS-7835 is not supported. Cisco Email Manager UI Server (third) on fourth. (In this scenario.0-CC1 1 MCS-7845H-3.) Up to 1000 agents: 7 servers – Cisco Email Manager AppServer on first (quad processor recommended). Cisco Email Manager UI Server (first) and WebView server on second. and CIR databases) on second. refer to the Cisco Intelligent Contact Management Software Bill of Materials (BOM) documentation available at http://www. Up to 250 agents: 2 servers – Cisco Email Manager AppServer. Cisco Email Manager UI Server (second) on third. Less than 10 agents: all Cisco Email Manager components and databases co-exist on single server (MCS-7845). database server (CIR) on seventh. an MCS-7835 may be used for the second UI Server box. UI Server. LAMBDA.0-CC1 2 100 MCS-7835 is not supported. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 5-7 . database server on fourth.Chapter 5 Sizing IPCC Components and Servers Sizing Considerations for IPCC Table 5-1 Sizing Information for IPCC Components and Servers (continued) Component Web Collaboration Server Server Model1 Number of CPUs Maximum Agents 500 total sessions or 250 one-to-one Notes MCS-7835 is not supported.0-CC1 2 Single-session chat: 250 agents and 250 callers Blended collaboration: 250 agents and 250 callers Multi-session chat: 125 agents and 375 callers Dynamic Content Adapter (DCA) for Web Option MCS-7845H-3. and WebView on first. database server (Primary. Cisco Email Manager UI Server (forth.cisco.) For sizing information. (In this scenario. With MCS-7845: • • • MCS-7845H-3. Cisco Email Manager UI Server (first) and WebView server on second. an MCS-7835 may be used for the n+1 UI Server boxes. Up to 500 agents: 4 servers – Cisco Email Manager AppServer on first. required if more than 750 agents) on fifth.com/en/US/partner/products/sw/c ustcosw/ps1001/products_usage_guidelines_list.ht ml. Cisco Email Manager UI Server (second) on third. DCA co-residency is not supported.0-CC1 2 See note. Email Manager Server MCS-7835H-3.

It is possible to use different server model configurations for the Rogger and the PGs.com/univercd/cc/td/doc/product/ic m/ccbubom/index. per IVR call.htm. available at http://www.Chapter 5 Sizing Considerations for IPCC Sizing IPCC Components and Servers Table 5-1 Sizing Information for IPCC Components and Servers (continued) Component Internet Service Node (ISN) Application Server and Voice Browser IP IVR Server Server Model1 Number of CPUs Maximum Agents Notes For the server specifications for the Internet Service Node (ISN). • • • • Cisco IP Contact Center Enterprise Edition SRND 5-8 OL-7279-04 . If a deployment has more than five groups per agent. If a deployment has a more complex ICM/IVR script than this. nor does lower BHCA equate to a greater number of agents supported. Agent capacities are based upon a maximum of 30 BHCA per agent and 90 calls per IVR port.html 1. The capacity numbers are also based on 5 skill group per agent.0-CC1 and MCS-7835H-3. The capacity numbers are based on an average of 5 Run Voice Response Unit (VRU) scripts. but they can still be used in an IPCC configuration.0-CC1 and the MCS-7835H1-3. The MCS-7835I-3.0-CC1 server as a replacement for the MCS-7835I-3.0-CC1. refer to the Cisco Internet Service Node (ISN) Software Bill of Materials available at http://www. it will also decrease the maximum BHCA and agent capacity and should be handled on a case-by-case basis. You must adhere to the capacity limits for the number of agents on each system component. running consecutively in the ICM script. Adjustments either way are not supported: fewer agents does not necessarily equate to higher BHCA. it will also decrease the maximum BHCA and agent capacity. The capacity maximums assume a normal amount of CTI traffic for each given configuration. refer to the Cisco IPCC Express and IP IVR Configuration and Ordering Tool. For the IP IVR server specifications. Cisco currently sells the MCS-7835I1-3.0-CC1 servers are no longer available from Cisco.0-CC1 as a replacement for the MCS-7835H-3. especially for the Progger. Extraordinary CTI traffic (from very large IVRs. for example) will decrease the BHCA and agent maximums. Minimum Hardware Configurations for IPCC Core Components The sizing information in Table 5-1 must be applied to each deployment to gauge server sizing requirements accurately. as long as you observe the BHCA and agent maximums for each separate component and adhere to the recommendations in the Cisco Intelligent Contact Management Software Bill of Materials (BOM) documentation. The following considerations and guidelines apply to the information in Table 5-1: • • Formal and critical call center deployments are encouraged to use dual CPU server configurations.cisco.cisco.com/en/US/partner/products/sw/c ustcosw/ps1846/prod_how_to_order.

Table 5-2 summarizes the sizing variables and their effects. or whether the agents will handle calls immediately and the IVR will queue only unanswered calls when all agents are busy. IVR Script Complexity As IVR script complexity increases with features such as database queries.Chapter 5 Sizing IPCC Components and Servers Sizing Considerations for IPCC Additional Sizing Factors Many variables in the IPCC configuration and deployment options can affect the hardware requirements and capacities. For impact of agents on the performance of Cisco CallManager components. for more information. page 4-6. see Sizing Cisco CallManager Servers For IPCC. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 5-9 . As BHCA increases. and Router. Progger. In addition. most notably on Cisco CallManager. For sizing purposes. Queuing The IP IVR places calls in a queue and plays announcements until an agent answers the call. Required VRU ports can be determined using the Cisco IPC Resource Calculator. the processor and memory overhead on the ICM Router and VRU PG will increase significantly.) ICM Script Complexity As the complexity and/or number of ICM scripts increase. There is no good rule of thumb or benchmark to characterize the IP IVR performance when used for complex scripting. the Cisco CallManager PG. or transaction-based usage. and that you periodically remove unused skill groups so that they do not affect system performance. Cisco recommends that you test complex IVR configurations in a lab or pilot deployment to determine the response time of database queries under various BHCA and how they affect the processor and memory for the IVR server. the load placed upon the IVR server and the Router also increases. when possible. Reporting Real-time reporting can have a significant effect on Logger. Progger. The delay time between replaying Run VRU scripts also has an impact. and the ICM Router and Logger. and Rogger. IP IVR. This section describes the major sizing variables and how they affect the capacity of the various IPCC components. The capacity numbers for agents assume up to 30 calls per hour per agent. Agents The number of agents is another important metric that will impact performance of most IPCC server components including Cisco CallManager clusters. You can also manage the effects on the CTI OS server by increasing the value for the frequency of statistical updates. page 6-1 Skill Groups The number of skill groups per agent has significant effects on the CTI OS Server. complex database queries. it is important to know whether the IVR will handle all calls initially (call treatment) and direct the callers to agents after a short queuing period. Cisco recommends that you limit the number of skill groups per agent to 5 or fewer. (See Cisco IPC Resource Calculator. and the Cisco CallManager PG. and Rogger processing due to database access. A separate server is required for an Administrative Workstation (AW) and/or Historical Data Server (HDS) to off-load reporting overhead from the Logger. there is an increase in the load on all IPCC components. PG. Busy Hour Call Attempts (BHCA) The number of calls attempted during a busy hour is an important metric. The answer to this question determines very different IVR sizing requirements and affects the performance of the ICM Router/Logger and Voice Response Unit (VRU) PG.

Chapter 5 Peripheral Gateway and Server Options Sizing IPCC Components and Servers IP IVR Self-Service Applications In deployments where the IP IVR is also used for self-service applications. Table 5-2 lists PG and PIM sizing recommendations Figure 5-3 Agent PG Configuration Options with CTI OS Agent PG (All-in-one) CCM PG (CCM PIM) VRM PG (VRU PIM) CTI SVR CTI OS Agent PG (with Generic) Generic PG (CCM PIM and VRU PIM) CTI SVR CTI OS Agent PG (with CCM) CCM PG (CCM PIM) Agent PG (with Outbound) Generic PG (CCM PIM and VRU PIM) CTI SVR CTI OS MR PG Dialer Agent PG (with Blender) Generic PG (CCM PIM and VRU PIM) CTI SVR CTI OS MR PG 132070 CTI SVR CTI OS Blender Cisco IP Contact Center Enterprise Edition SRND 5-10 OL-7279-04 . the self-service applications are in addition to the IPCC load and must be factored into the sizing requirements as stated in Table 5-1. Contact centers are often mission-critical. The Peripheral Interface Manager (PIM) is the software process that runs on the PG and performs the message translation and control. Every peripheral device that is part of the IPCC solution must be connected to a PG and PIM. the IP IVR. Third-Party Database and Cisco Resource Manager Connectivity Carefully examine connectivity of any IPCC solution component to an external device and/or software to determine the overall effect on the solution. The capacity impact will vary based on ECC configuration and should be handled on a case-by-case basis. or other third-party automatic call distributors (ACDs) or voice response units (VRUs) into common internally formatted messages that are then sent to and understood by the ICM. it also translates ICM messages so that they can be sent to and understood by the peripheral devices. Therefore. Peripheral Gateway and Server Options An ICM Peripheral Gateway (PG) translates messages coming from the Cisco CallManager servers. Router. Figure 5-3 and Figure 5-4 illustrate various configuration options for the Agent PG with CTI OS and Cisco Agent Desktop. and customer-facing operations. Logger. Extended Call Context (ECC) The ECC usage impacts PG. Cisco recommends that you engage a Cisco partner (or Cisco Advanced Services) with the appropriate experience and certifications to help you design your IPCC solution. Cisco IPCC solutions are very flexible and customizable. but they can also be complex. In the reverse. There are many ways that ECC can be configured and used. and network bandwidth. revenue-generating.

cisco. BHCA. and ACD Actual number of IVR PIMs is determined by the size of the IPCC deployment (agents.0 80 Up to 2 PG types are permitted per server. 1 No Can PGs be remote from ICM? Can PGs be remote from Cisco CallManager or IP IVR? PIM types Maximum number of PIMs per PG Maximum number of PIM types per PG (CTI server may be added) Maximum number of IVRs controlled by one Cisco CallManager Maximum number of CTI servers per PG Can PG be co-resident with Cisco CallManager on Media Convergence Server (MCS)? CTI OS The CTI OS is most commonly configured as a co-resident component on the Agent PG (see Figure 5-3 and Figure 5-4). IVR. provided that any given server is limited to the maximum agent and VRU port limitations outlined in Table 5-1. Yes No Cisco CallManager.Chapter 5 Sizing IPCC Components and Servers CTI OS Figure 5-4 Agent PG Configuration Options with Cisco Agent Desktop Agent PG (All-in-one) CCM PG (CCM PIM) VRM PG (VRU PIM) CTI SVR CTI OS Agent PG (with Generic) Generic PG (CCM PIM and VRU PIM) CTI SVR CTI OS Agent PG (with CCM) CCM PG (CCM PIM) Agent PG (with Outbound) Generic PG (CCM PIM and VRU PIM) CTI SVR CTI OS MR PG Dialer Agent PG (with Blender) Generic PG (CCM PIM and VRU PIM) CTI SVR CTI OS MR PG 132071 CTI SVR CTI OS Blender CAD SVR CAD SVR CAD SVR CAD SVR CAD SVR Table 5-2 PG and PIM Sizing Recommendations Sizing Variable Maximum number of PGs per ICM Maximum PG types per server platform Recommendation. available at http://www. supporting up to 500 agents. Media Routing (MR). IVR ports. and so forth). Table 5-3 lists additional sizing factors for CTI OS. Under most circumstances. 5 PIMs per PG (Agent PG) and 8 PIMs per PG (standalone PG) is a reasonable limit. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 5-11 . 2 + CTI Server Refer to the Cisco IP Telephony Solution Reference Network Design (SRND). Based on ICM Software Release 5.com/go/srnd.

The CTI OS capacity decreases when CTI OS configuration values differ from those listed in Table 5-3. page 5-13 Cisco Agent Desktop Recording and Playback Service. page 5-13 Cisco Agent Desktop VoIP Monitor Service. see Agent Desktop and Supervisor Desktop.Chapter 5 Cisco Agent Desktop Component Sizing Sizing IPCC Components and Servers Table 5-3 CTI OS Sizing Factors Sizing Factor Maximum number of supervisors Maximum number of teams Maximum BHCA per agent MSC-7845 50 50 30 MSC-7835 250 25 25 30 50 5 50 5 None Comments 10% of supported agents1 10% of supported agents1 Supervisors do not receive new calls. page 5-13 Cisco IP Contact Center Enterprise Edition SRND 5-12 OL-7279-04 . whether or not Switched Port Analyzer (SPAN) monitoring and recording is used. The numbers in Table 5-3 are based on the following assumptions: • • Hyper-threaded is enabled for the MCS server. 20% of supported agents1 2% of supported agents1 20% of supported agents1 Maximum number of agents plus supervisors 500 Maximum number of agents plus supervisors 100 per team Maximum number of supervisors per team Maximum number of agents per supervisor Skill groups per agent Extended Call Context (ECC) 10 100 5 None 1. additional Agent PG instances are off-loaded (500 agents each) to additional servers. platform resource usage increase significantly due to the increase in work load required to query and update agents and skill groups. For example. Cisco Agent Desktop Component Sizing For details on the components and architecture of the Cisco Agent Desktop. and the number of simultaneous recordings. Server capacities for the Cisco Agent Desktop CTI Option vary based on the total number of agents. The traffic profile is: – 85% of calls answered by agents – 10% of calls transferred – 5% of calls conferenced For more than 500 CTI agents. the CTI OS capacity decreases as the number of skill groups per agent increases. These percentages apply to the CTI OS Server agent capacity and not to the entire Contact Center capacity. In this case. This section presents sizing guidelines for the following installable Cisco Agent Desktop Server components: • • • Cisco Agent Desktop Base Services. page 7-1.

A set of Cisco Agent Desktop Base Services plus the additional application servers correspond to a logical call center (LCC). Table 5-4 Maximum Number of Agents Supported by a Logical Call Center (LCC) Enterprise Size Small Medium Maximum LCC capacity with multiple PG and CTI Servers Desktop Agents Only 100 300 1000 IP Phone Agents Only 50 150 250 500 Mixed 33 of each 100 of each 333 of each 333 of each Large (multiple PG and CTI Servers) 500 Cisco Agent Desktop VoIP Monitor Service The VoIP Monitor Service enables the silent monitoring and recording features. Table 5-4 lists the maximum number of agents that a single LCC can support for various sizes of enterprises. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 5-13 . Enterprise Service. They include Chat Service. the VoIP Monitor Service may be co-located on the Agent PG for up to 100 agents. Directory Services. When Remote Switched Port Analyzer (RSPAN) monitoring and recording are required for more than 400 agents. Cisco Agent Desktop Recording and Playback Service The Recording and Playback Service stores the recorded conversations and makes them available to the Supervisor Log Viewer application. The capacity of the Recording and Playback Service is not dependent on the codec that is used. Licensing and Resource Manager Service. IP Phone Agent Service. In addition. the VoIP Monitor Service must be deployed on a dedicated server (an MCS-7835 server or equivalent). LDAP Monitor Service. These additional applications include the VoIP Monitor Service and the Recording and Playback Service. there are application servers that may be placed on the same or separate computers as the Base Servers.Chapter 5 Sizing IPCC Components and Servers Cisco Agent Desktop Component Sizing Cisco Agent Desktop Base Services The Cisco Agent Desktop Base Services consist of a set of application servers that run as Microsoft Windows 2000 services. Table 5-5 summarizes the raw Recording and Playback Service capacity. Each dedicated VoIP Monitor Service can support up to 400 agents. Recording and Statistics Service. When using Switched Port Analyzer (SPAN) monitoring. the VoIP Monitor Service has no impact on design guidance for Agent PG scalability. A co-resident Recording and Playback Service can support up to 32 simultaneous recordings. and Sync Service. A dedicated Recording and Playback Service (which is available in the Premium offering) can support up to 80 simultaneous recordings. For Desktop Monitoring.

and Agent PG). designers should pay careful attention to the sizing variables that will impact sizing capacities such as skill groups per Agent. While it is often difficult to determine these variables in the pre-sales phase. While new versions will scale far higher. Progger. Correct sizing and design can ensure stable deployments for large systems up to 6. and these considerations should be applied to the final design and hardware selection. cost savings can be achieved with careful planning and co-resident ICM components (for example. significant call queuing.000 agents and 180. Careful planning and discovery in the pre-sales process should uncover critical sizing variables. the Cisco Agent Desktop Monitor Server is still limited in the number of simultaneous sessions that can be monitored by a single server when monitoring and recording are required. Additionally. For smaller deployments. especially when deploying co-resident PGs and Proggers. Cisco IP Contact Center Enterprise Edition SRND 5-14 OL-7279-04 . and other factors contribute to the total capacity of any individual component. Configurations with multiple skill groups per agent. Rogger.000 BHCA.Chapter 5 Summary Sizing IPCC Components and Servers Table 5-5 Capacity of Recording and Playback Service Recording and Playback Service Type Co-resident Dedicated Maximum Simultaneous Recordings 32 80 Summary Proper sizing of IPCC components requires analysis beyond the number of agents and busy hour call attempts. it is critical to consider them during the initial design.

and you should become familiar with them before continuing with this chapter. Cisco recommends that you study the details about the operations of Cisco CallManager clusters presented in the Call Processing chapter of the Cisco IP Telephony Solution Reference Network Design (SRND) guide. facilitate redundancy. This chapter documents general best practices and scalability considerations for sizing the Cisco CallManager servers used with your IPCC Enterprise deployments. you should perform the following steps.com/go/srnd The information in this chapter builds upon the concepts presented in the Cisco IP Telephony SRND. However. scalability refers to Cisco CallManager server and/or cluster capacity when used in the IPCC Enterprise environment. the foundational concepts are not duplicated here. outbound. Within the context of this document. which will have an impact on the Cisco CallManager cluster scalability: • • Determine customer call center application requirements (IP IVR. multi-channel. Before reading this chapter. CTI ports. provisioning. and so forth): – Number of required IPCC Enterprise agents – Number of required IP IVR CTI ports or ISN ports (or sessions) – Number of CTI route points (ICM route points and IVR route points) – Number of PSTN trunks – Estimated busy hour call attempts (BHCA) for all agents and devices mentioned above (Inbound or outbound?) Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 6-1 . available at http://www. and so forth).C H A P T E R 6 Sizing Cisco CallManager Servers For IPCC This chapter discusses the concepts. Cisco CallManager clusters provide a mechanism for distributing call processing across a converged IP network infrastructure to support IP telephony. ISN. and provide feature transparency and scalability.cisco. Determine the types of call center resources and devices used in IPCC Enterprise (route points. Call Processing With IPCC Enterprise Before applying the guidelines presented in this chapter. Some duplication is necessary to clearly concepts relating to IPCC as an application supported by the Cisco CallManager call processing architecture. and configuration of Cisco CallManager clusters when used in an IPCC Enterprise environment. This chapter covers only the IPCC Enterprise operation of clusters within both single and multiple campus environments and proposes reference designs for implementation.

such as: – Simple call flow (IVR self-service or direct agent transfer without any IVR call treatment) Simple call flows are those that do not involve multiple call handling (for example. Do not use a publisher as a failover or backup call processing server unless you have fewer than 50 agent phones and the installation is not mission critical or is not a production environment. Similarly. The publisher server should be of equal or higher capability than the subscriber servers. JTAPI Users. clustering over the WAN. centralized. agents.Chapter 6 IPCC Clustering Guidelines Sizing Cisco CallManager Servers For IPCC – Percent of conferenced and/or transferred calls • • • Determine the required deployment model (single site. Determine the placement of solution components in the network (gateways. incoming calls from a gateway directly to a phone. ISN. or remote branches within centralized or distributed deployments). or consultation or conference from an agent to a skill group) Complex call flows are those that involve multiple call redirects and call handling of the original call (for example. distributed. This assumes BHCA is uniform across all agents (average BHCA processed is about the same on all nodes). music on hold. distribute all gateway ports and IP IVR CTI ports equally among the cluster nodes. CTI route point. such as ICM route points and agent devices. then transferred or redirected to another target such as an agent). route points. Note A cluster may contain a mix of server platforms. The Cisco MCS-7825H-3000 is the minimum server required.) • Devices (including phones. • • • • • Cisco IP Contact Center Enterprise Edition SRND 6-2 OL-7279-04 . and CTI Manager) should never reside or be registered on the publisher. in the same server if possible. gateway ports. agent-to-agent transfer and conference. Any deployment with more than 50 agent phones requires a minimum of two subscriber servers and a combined TFTP and publisher. Any deviations will require review by Cisco Bid Assurance on a case-by-case basis. If you require more than one ICM JTAPI user (CTI Manager) and more than one primary subscriber. call redirection to a route point. CTI ports. internal calls. then group and configure all devices monitored by the same ICM JTAPI User (third-party application provider). and so forth). then distribute all agents equally among the cluster nodes. – Complex call flow (IVR call treatment or database lookup prior to agent transfer. incoming calls to central route points redirected to CTI route points and then to IP IVR for call treatment. IPCC Clustering Guidelines The following guidelines apply to all Cisco CallManager clusters with IPCC Enterprise. and so forth). Any administrative work on Cisco CallManager will impact call processing and CTI Manager activities if there are any devices registered with the publisher. but all servers in the cluster must run the same Cisco CallManager software release and service pack. CTI ports. These multiple call processing segments of the original call consume more CPU resources compared to simple call handling. Determine the different types of call flows and call disposition. (See Table 6-2. IVR self-service. If you require more than one primary subscriber to support your configuration.

1 and 3.2.com/univercd/cc/td/doc/product/voice/c_callmg/ccmcomp. or a maximum of 3200 per cluster if they are equally balanced among the four primary servers. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide at http://www.htm • Within a cluster. music on hold.cisco. Each H.323 device can support up to 500 H. available at http://www. and other CTI devices. the 1:1 redundancy scheme is strongly recommended. thus allowing the CPU to process a higher transaction load.323 calls with Cisco CallManager Release 3.1 or 3.) • • • Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 6-3 .Chapter 6 Sizing Cisco CallManager Servers For IPCC IPCC Enterprise with Cisco CallManager Releases 3. and so forth) would be on one or more Cisco CallManager servers. (This does not mean that you can double the agent capacity simply by installing the BBWC because the capacity might be limited by other server resources such as processor speed and memory. Servers that do not have the capability to add the battery-backed write cache (BBWC) enabler kit typically are rated at half the capacity of the equivalent server with the BBWC installed. (See Call Processing Redundancy with IPCC. ensure that the installed MCS-7800 Series server is able to handle the maximum rated agent capacity.2 The following guidelines apply to Cisco CallManager releases 3. place all servers from the Cisco CallManager cluster within the same LAN or MAN. You can configure a maximum of 800 Computer Telephony Integration (CTI) connections or associations per server. database publisher.2 • If you have a mixed cluster with IPCC and general office IP phones. Other servers may be used for more dedicated functions such as Trivial File Transfer Protocol (TFTP). refer to the Cisco CallManager Compatibility Matrix. The default trace setting for Cisco CallManager Release 3.cisco.com/go/srnd IPCC Enterprise with Cisco CallManager Releases 3. IP IVR CTI ports. you must follow the specific guidelines for clustering over the IP WAN as described in both the section on Clustering Over the WAN. This maximum would include IPCC agent phones.2. and the section on Clustering Over the IP WAN in the Cisco IP Telephony Solution Reference Network Design (SRND) guide. CTI ports. When upgrading to Cisco CallManager Release 3. page 6-9.2 is different than the setting for later releases (Cisco CallManager Release 3. CTI route points. for details) Under normal circumstances. In this case. available at http://www.1 and 3. and so forth.cisco. For specific Cisco CallManager and IPCC supported releases. For example.com/go/srnd • • For additional Cisco CallManager clustering guidelines. group and configure each type on a separate server if possible (unless you need only one subscriber server).3 or later.1 or 1000 calls with Cisco CallManager Release 3. page 2-15 in this guide.1 and 3. Cisco does not recommend placing all members of a cluster on the same VLAN or switch. If the cluster spans an IP WAN. as long as cluster capacity allows. and all general office IP phones and their associated devices (such as gateway ports) would be on other Cisco CallManager servers. all IPCC agents and their associated devices and resources (gateway ports. you may enable a maximum of 6 call processing servers (4 primary and 2 backup servers) with the Cisco CallManager Service. BBWC helps reduce disk I/O contention.3 and later) and typically has a lesser impact on disk I/O.

Chapter 6 IPCC Enterprise with Cisco CallManager Releases 3. including backup servers.000 per cluster. Again this maximum would include IPCC agent phones.3 and later: • Within a cluster. as determined by the Cisco CallManager Capacity Tool. and a maximum of 2500 controlled devices per CTI application if they are equally balanced among all servers. the primary server would support a maximum of 500 agents and 15. The BHCA would be spread equally among the eight call processing servers with 1:1 redundancy.) Cisco IP Contact Center Enterprise Edition SRND 6-4 OL-7279-04 . publisher. Other (additional) servers may be used for more dedicated functions such as TFTP. These simple schemes have been replaced by a capacity tool to allow for more accurate planning of the system. The required resources can include memory. such as an IPCC agent phone. or a maximum of 3200 per cluster. This configuration will have the least impact on disk I/O resources. (See Call Processing Redundancy with IPCC. This trace file should be redirected to the secondary F drive array.3 and Later Sizing Cisco CallManager Servers For IPCC • The default trace file location for the Cisco CallManager and signal distribution layer (SDL) is on the primary drive. and a maximum of 2000 controlled devices per CTI application if they are equally balanced among all servers (Cisco MCS-7835 server required). A device that handles only 6 calls per hour.000 BHCA. gateways. page 6-5. Each Cisco CallManager cluster (four primary and four backup subscriber servers) can support up to 2. In a failover scenario. page 6-9.3 and Later The following guidelines apply to Cisco CallManager Release 3. and the CTI default trace file location should be directed to the C drive array. music on hold. such as a standard IP phone.) Each of the eight Cisco CallManager servers (MCS-7845H High Performance Servers with BBWC installed) would support a maximum of 250 agents or 7. In prior Cisco CallManager software releases. processor. and other third-party application CTI devices configured in Cisco CallManager.000 IPCC agents and no more than 60.) • • • Cisco CallManager Platform Capacity Planning with IPCC Many types of devices can register with a Cisco CallManager. which are normally in the form of calls. and I/O. You can configure a maximum of 800 CTI connections or associations per standard server that does not have battery-backed write cache (BBWC) installed (as defined in Table 6-2). or a maximum 10. IP IVR CTI ports. (See Cisco CallManager Capacity Tool. or an IP IVR port. CTI (TAPI/JTAPI) devices. IP IVR ports. consumes fewer resources than a device handling 30 calls per hour. including IP phones. page 6-5. Each device then consumes additional server resources during transactions. and dial plan weights. Each of these devices requires resources from the server platform with which it is registered. CTI route points.500 BHCA. you may enable a maximum of 8 servers with the Cisco CallManager Service. BHCA multipliers. and DSP resources such as transcoding and conferencing. Cisco has utilized various schemes to calculate the capacity of a system using device weights. depending on your specific configuration (simple versus complex call flows). for redundancy schemes. You can configure a maximum of 2500 CTI connections or associations per MCS-7845H with battery-backed write cache (BBWC) or equivalent high-performance server (see Table 6-2). voicemail ports. These capacities can vary. a gateway port. IPCC Enterprise with Cisco CallManager Releases 3. and so forth.000 BHCA. (See Cisco CallManager Capacity Tool.

8 0. coresident software. T1 PRI. coresident software.15 0. Cisco CallManager Capacity Tool The Cisco CallManager Capacity Tool (CCMCT) requires various pieces of information to provide a calculation of the minimum size and type of servers required for a system.3 0.83 of an hour. if all IPCC phones make an average of 25 calls per hour and the average call lasts 2 minutes. maximum of 20 streams) Transcoder MTP resource (hardware. redirect) CTI port – Type #2 (transfer.8 0. conference) CTI route point Third-party controlled line Intercluster trunk gateways Intercluster trunks H323 client (phone) H323 gateways H323 gateway DS0s (T1 CAS. E1 PRI.83.8 0.15 0.) Table 6-1 shows an example of the input for the Capacity Tool. or standalone software) Conference resource (hardware.8 0. (25 calls of 2 minutes each equals 50 minutes per hour on the phone. gateways. the Capacity Tool also requires the average bust hour call rate and the average busy hour traffic utilization. The information includes the type and quantity of devices.Chapter 6 Sizing Cisco CallManager Servers For IPCC Cisco CallManager Capacity Tool Note If your system does not meet the guidelines in this document. and media resources.3 0.8 Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 6-5 . then the BHCA is 25 and the utilization is 0. contact your Cisco Systems Engineer (SE) for proper sizing of the Cisco CallManager cluster. Analog) 20 MoH (Music on Hold) stream (coresident.8 0.8 IP phone Unity connection port CTI port – Type #1 (simple call. which is 50/60 = 0. Table 6-1 Sample Input for Cisco CallManager Capacity Tool Device or Port IP Telephony Input Average Busy Hour Call Rate (BHCA) 4 20 8 8 100 8 20 4 20 Average Busy Hour Traffic Utilization 0. T1 PRI. E1 PRI. For each device type. or standalone software) Dial plan Directory numbers or lines 20 20 6 0. such as IP phones. Analog) MGCP gateways MGCP gateway DS0s (T1 CAS.3 0. or if you consider the system to be complex (IP Telephony and IPCC mixed with other applications). For example.

Chapter 6 Cisco CallManager Capacity Tool

Sizing Cisco CallManager Servers For IPCC

Table 6-1

Sample Input for Cisco CallManager Capacity Tool (continued)

Device or Port Route patterns Translation patterns
IPCC Input

Average Busy Hour Call Rate (BHCA)

Average Busy Hour Traffic Utilization

IPCC agents ISN (prompt and collect or queueing) ISN (self-service) CTI ports or IP IVR (prompt and collect or queueing) CTI ports or IP IVR (self-service) CTI route points H323 gateways H323 gateway DS0s (T1 CAS, T1 PRI, E1 PRI, Analog) MGCP gateways

30

0.8

30 30

0.8 0.8

20

0.8 0.8

MGCP gateway DS0s (T1 CAS, T1 PRI, E1 PRI, Analog) 20 % Agent-to-agent transfer % Agent conference
IPCC Outbound

10% 10% 30 30 60 20 20 20 0.8 0.8 0.8 0.8 0.8 0.8

IPCC outbound predictive/preview agents IPCC outbound direct preview agents IPCC outbound dialer ports IPCC outbound IVR ports H.323 gateways H.323 gateway DS0s (T1 CAS, T1 PRI, E1 PRI, analog) MGCP gateways MGCP gateway DS0s (T1 CAS, T1 PRI, E1 PRI, analog)

In addition to the device information, the Cisco CallManager Capacity Tool also requires information regarding the dial plan, such as route patterns and translation patterns. The IPCC input includes entries for agents (inbound and outbound), Internet Service Node (ISN) or IP IVR ports for gateway ports, and percent of total calls that are transferred and/or conferenced. When all the details have been entered, the Cisco CallManager Capacity Tool calculates how many servers of the desired server type are required, as well as the number of clusters if the required capacity exceeds a single cluster. At this time, the Cisco CallManager Capacity Tool is available to all Cisco employees and partners at http://www.cisco.com/partner/WWChannels/technologies/resources/CallManager/

Cisco IP Contact Center Enterprise Edition SRND

6-6

OL-7279-04

Chapter 6

Sizing Cisco CallManager Servers For IPCC Supported Cisco CallManager Server Platforms for IPCC Enterprise

Supported Cisco CallManager Server Platforms for IPCC Enterprise
Table 6-2 lists the general types of servers you can use with IPCC Enterprise in a Cisco CallManager cluster, along with their main characteristics.
Table 6-2 Types of Cisco CallManager Servers that Support IPCC

Server Type Standard server: MCS-7825H

Characteristics
• • •

IPCC Enterprise Recommendation1 Up to a maximum of 100 agents (Not recommended for mission-critical call centers above 50 agents) Up to a maximum of 250 agents (Maximum of 125 agents without BBWC installed)

Single processor Single power supply (not hot-swap) Non-RAID hard disk (not hot-swap) Single processor Redundant power supplies (hot-swap) Redundant SCSI RAID hard disk array (hot-swap) Dual processors Redundant power supplies (hot-swap) Redundant SCSI RAID hard disk arrays

High-availability standard server: MCS-7835H with BBWC

• • •

High-performance server: MCS-7845H with BBWC

• • •

Recommended for all mission-critical contact centers up to a maximum of 500 agents (Maximum of 250 agents without BBWC installed)

1. Agent capacities are based on a maximum of 30 BHCA per agent in the busy hour.

The maximum number of IPCC Enterprise agents that a single Cisco CallManager server can support depends on the server platform, as indicated in Table 6-3.
Table 6-3 Maximum Number of IPCC Enterprise Agents per Cisco CallManager (Release 3.3 or Later) Server Platform

Cisco CallManager MCS Server Platform and Equivalent Server Characteristics1
• • •

Maximum IPCC High-Availability Agents per Server 2 Platform 3 Yes

High-Performance Server Yes
4

Cisco MCS-7845H-3000 (Dual Prestonia Xeon 3.06 GHz 500 or higher) 4 GB RAM HP DL380-G3 3.06 GHz 2-CPU 3 Cisco MCS-7845H-2400 (Dual Prestonia Xeon 2400 MHz) 4 GB RAM (With the addition of battery-backed write cache, BBWC, installed separately) HP DL380-G3 2400 MHz 2-CPU Cisco MCS-7845H-2400 (Dual Prestonia Xeon 2400 MHz) 4 GB RAM (Without BBWC) HP DL380-G3 2400 MHz 2-CPU Cisco MCS-7835H-3000 (Prestonia Xeon 3.06 GHz) 2 GB RAM (With the addition of battery-backed write cache, BBWC, installed separately) HP DL380-G3 3.06 GHz 1-CPU 250 250 500

Yes

Yes

5

• • • •

Yes

Yes

Yes

No 5

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

6-7

Chapter 6 Supported Cisco CallManager Server Platforms for IPCC Enterprise

Sizing Cisco CallManager Servers For IPCC

Table 6-3

Maximum Number of IPCC Enterprise Agents per Cisco CallManager (Release 3.3 or Later) Server Platform

Cisco CallManager MCS Server Platform and Equivalent Server Characteristics1
• • • •

Maximum IPCC High-Availability Agents per Server 2 Platform 3 125 Yes

High-Performance Server No

Cisco MCS-7835H-3000 (Prestonia Xeon 3.06 GHz) 2 GB RAM (Without BBWC) HP DL380-G3 3.06 GHz 1-CPU Cisco MCS-7825H-3000 (Pentium 4, 3.06 GHz) 2 GB RAM HP DL320-G2 3.06 GHz 6

100

No

No

1. For the latest information on server memory requirements, refer to Product Bulletin No. 2864, Physical Memory Recommendations for Cisco CallManager Version 4.0 and Later, available at http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_bulletin0900aecd80284099.html. 2. Agent capacities are based on a maximum of 30 BHCA per agent in the busy hour and failover scenario. 3. A high-availability server supports redundancy for both the power supplies and the hard disks. 4. This server has the battery-backed write cache kit (BBWC) installed. 5. This server does not have the battery-backed write cache kit (BBWC) installed. Without this kit, the capacity would be half the stated limit. The kit must be ordered and installed separately to achieve the maximum stated agent capacity. 6. The maximum number of IPCC agents supported on a single non-high-availability platform (such as the MCS-7825H) is 50 agents in a mission-critical call center. With a redundant configuration, this limit does not apply.

The following notes also apply to Table 6-3:
• • • •

Agent capacities are based on Cisco CallManager Release 3.3 and later, in failover mode. The maximum number of IPCC agents is 500 with Cisco CallManager Release 3.3 or later, or 250 IPCC agents with Cisco CallManager Release 3.2 or earlier. A single non-high-availability platform supports a maximum of 50 IPCC agents. With a redundant server configuration, this limit does not apply. The Cisco MCS-7845I-3000 is not a supported MCS platform for Cisco CallManager. However, the IBM server equivalent (IBM x345, 3.06 GHz dual CPU) is supported for IPCC deployments as a software only-platform with OS 2000.2.6. The Cisco MCS-7815I-2000 server is a supported Cisco CallManager platform for Cisco IP Telephony deployments only. It is not supported with IPCC Enterprise deployments, but lab or demo setups can use this server. Newer MCS-7835H and MCS-7845H server platforms have the same capacities as shown in Table 6-3.

For the latest information on supported platforms and specific hardware configurations, refer to the online documentation at http://www.cisco.com/en/US/products/hw/voiceapp/ps378/prod_brochure_list.html The capacities outlined in this section provide a design guideline for ensuring an expected level of performance for normal operating configurations. Higher levels of performance can be achieved by disabling or reducing other functions that are not directly related to processing calls. Increasing some of these functions can also have an impact on the call processing capabilities of the system. Some of these functions include tracing, call detail recording, highly complex dial plans and call flows, and other services that are coresident on the server. Highly complex dial plans can include multiple line appearances, many partitions, calling search spaces, route patterns, translations, route groups, hunt groups, pickup groups, route lists, extensive use of Call Forward, coresident services, and other

Cisco IP Contact Center Enterprise Edition SRND

6-8

OL-7279-04

Chapter 6

Sizing Cisco CallManager Servers For IPCC Call Processing Redundancy with IPCC

coresident 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. A Cisco CallManager cluster with a very large dial plan containing many gateways, route patterns, translation patterns, and partitions can take an extended amount of time to initialize when the Cisco CallManager Service is first started. If the system does not initialize within the default time, there are service parameters that can be increased to allow additional time for the configuration to initialize. For details on the service parameters, refer to the online help for Service Parameters in Cisco CallManager Administration.

Call Processing Redundancy with IPCC
With all versions of Cisco CallManager and IPCC, you can choose from the following redundancy configurations:
• •

2:1 — For every two primary subscribers, there is one shared backup subscriber. 1:1 — For every primary subscriber, there is a backup subscriber.

The 1:1 redundancy scheme allows upgrades with only the failover periods impacting the cluster. Cisco CallManager Release 3.3 and later supports up to eight subscribers (servers with the Cisco CallManager service enabled), so you may have as many as four primary and four backup subscribers in a cluster. The 1:1 redundancy scheme enables you to upgrade the cluster using the following method.
Step 1 Step 2 Step 3

Upgrade the publisher server. Upgrade dedicated TFTP and music on hold (MoH) servers. Upgrade all backup subscribers. This step will impact some users if 50/50 load balancing is implemented. During this step, the Cisco CallManager service is stopped in the backup subscriber, and the devices move to the primary subscriber. Fail-over the primary subscribers to their backups, and stop the Cisco CallManager service on the primaries. All users are on primaries and are moved to backup subscribers when the Cisco CallManager service is stopped. CTI Manager is also stopped, causing the Peripheral Gateway (PG) to switch sides and inducing a brief outage for agents on that particular node. Upgrade the primaries, and then re-enable the Cisco CallManager service.

Step 4

Step 5

With this upgrade method, there is no period (except for the failover period) when devices are registered to subscriber servers that are running different versions of the Cisco CallManager software. This factor can be important because the Intra-Cluster Communication Signaling (ICCS) protocol that communicates between subscribers can detect a different software version and shut down communications to that subscriber. This action could potentially partition a cluster for call processing, but SQL and LDAP replication would not be affected. The 2:1 redundancy scheme allows for fewer servers in a cluster, but it can potentially result in an outage during upgrades. This is not a recommended scheme for IPCC, although it is supported if it is a customer requirement and possible outage of call processing is not of concern to the customer.

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

6-9

and so on) running on them. Cluster Configurations for Redundancy Figure 6-1 through Figure 6-5 illustrate typical cluster configurations to provide IPCC call processing redundancy with Cisco CallManager. until the server is upgraded. Remember to upgrade one server at a time. Upgrade servers. During the upgrade of the second primary subscriber. Cisco strongly recommends that you have no more than the maximum of 500 IPCC agents registered to the backup server during the upgrade. Make sure that the Cisco CallManager service does not run on these servers. Similarly. that have only Cisco CallManager-related services (music on hold. Figure 6-1 Basic Redundancy Schemes 2:1 REDUNDANCY SCHEME 1:1 REDUNDANCY SCHEME Backup M M M Backup Backup M M M M Cost-efficient redundancy Degraded service during upgrades Not Recommended High availability during upgrades Simplified configuration 126039 Cisco IP Contact Center Enterprise Edition SRND 6-10 OL-7279-04 . Step 4 Note Cisco does not recommend that you oversubscribe the backup server(s) during the upgrade. Upgrade each backup server. Cisco strongly recommends that you perform the upgrade during off-peak hours when low call volume occurs. there will be some outage for users and agents subscribed on that server.Chapter 6 Cluster Configurations for Redundancy Sizing Cisco CallManager Servers For IPCC The 2:1 redundancy scheme enables you to upgrade the cluster using the following method. there will be some outage for users and agents subscribed on that server. one server at a time. Upgrade the Cisco TFTP server if it exists separately from the publisher database server. upgrade the servers in the following order: Step 1 Step 2 Step 3 Upgrade the publisher database server. until the server is upgraded. Step 5 Upgrade each primary server that has the Cisco CallManager service running on it. when you upgrade the fourth primary subscriber. Cisco IP Media Streaming Application. If the Cisco CallManager service does not run on the publisher database server. Make sure that you upgrade only one server at a time. one server at a time.

Chapter 6 Sizing Cisco CallManager Servers For IPCC Cluster Configurations for Redundancy Figure 6-2 1:1 Redundancy Configuration Options 1 MAX 50 AGENTS Publisher and Backup Subscriber Primary M M 2 Publisher and TFTP Server(s) MAX 500 AGENTS Primary Backup M M 3 Publisher and TFTP Server(s) MAX 1000 AGENTS Backup Backup M M Primary Primary M M 4 Publisher and TFTP Server(s) MAX 1500 AGENTS Backup Backup Backup M M 5 Publisher and TFTP Server(s) MAX 2000 AGENTS Backup Backup Backup Backup M M Primary Primary Primary Primary Primary Primary Primary 126040 M M M M M M M M M M Figure 6-3 2:1 Redundancy Configuration Options 1 MAX 50 AGENTS Publisher and Backup Subscriber Primary M M 2 Publisher and TFTP Server(s) MAX 500 AGENTS Primary Backup M 3 Publisher and TFTP Server(s) MAX 1000 AGENTS M Primary Primary Backup M M M 4 Publisher and TFTP Server(s) MAX 1500 AGENTS M 5 Publisher and TFTP Server(s) MAX 2000 AGENTS M Primary Primary Backup M Primary Primary Primary Primary 126041 Backup M M M Backup M M Primary Backup M M M Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 6-11 .

BBWC must be ordered separately.4 Advanced server does not come with BBWC installed. with 50/50 Load Balancing (High-Performance Server with BBWC Installed) 500 IPCC AGENTS Publisher and TFTP Server(s) 1 to 250: Primary 251 to 500: Backup 251 to 500: Primary 1 to 250: Backup 1000 IPCC AGENTS Publisher and TFTP Server(s) 251 to 500 751 to 1000 1 to 250 501 to 750 2000 IPCC AGENTS Publisher and TP Server(s) 251 to 500 751 to 1000 1250 to 1500 1750 to 2000 M M M M M M 1 to 250 501 to 750 1001 to 1250 126042 M M M M M M M M 1501 to 1750 Note MCS-7845H-2.Chapter 6 Cluster Configurations for Redundancy Sizing Cisco CallManager Servers For IPCC Figure 6-4 1:1 IPCC Enterprise Redundancy with Cisco CallManager Release 3.3 or Later.3 or Later on MCS-7845H-3000 High-Performance Server with 50/50 Load Balancing 250 IPCC AGENTS AND 3750 PHONES Publisher and TFTP Server(s) IPCC Agents 250 Agents: Primary 3750 Phones: Backup Phones 3750 Phones: Primary 250 Agents: Backup M 500 IPCC AGENTS AND 7500 PHONES Publisher and TFTP Server(s) IPCC Agents 251 to 500 M M 1000 IPCC AGENTS AND 15000 PHONES Publisher and TP Server(s) IPCC Agents 1 to 250 251 to 500 751 to 1000 3750 to 7500 11251 to 15000 M M 1 to 250 501 to 750 1 to 3750 126043 Phones M M M 3751 to 7500 M M 1 to 3750 Phones M M M M 7501 to 11250 Cisco IP Contact Center Enterprise Edition SRND 6-12 OL-7279-04 . Figure 6-5 1:1 Redundancy for Mixed Office and IPCC Phones with Cisco CallManager Release 3.

To allow for failure of the primary or the backup. calculate the capacity of a cluster without load balancing and then distribute the load across the primary and backup subscribers based on devices and call volume.cisco. you can reduce by 50% the impact of any server becoming unavailable. In this way. In a 1:1 redundancy pair.Chapter 6 Sizing Cisco CallManager Servers For IPCC Load Balancing With IPCC Load Balancing With IPCC An additional benefit of using the 1:1 redundancy scheme is that it enables you to balance the devices over the primary and backup server pairs. To provide for failover conditions when only one server is active.). you can move up to half of the device load from the primary to the secondary subscriber by using the Cisco CallManager redundancy groups and device pool settings. Special Cisco CallManager configurations and services such as: – MOH – Tracing levels Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 6-13 . refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide. available at http://www. which lowers CPU usage. As the call rate increases.com/go/srnd Impact of IPCC Application on Cisco CallManager Performance and Scalability Cisco CallManager system performance is influenced by many factors such as: • • Software release versions The type and quantity of devices registered. IP phones. and so on. the total load on the primary and secondary subscribers should not exceed that of a single subscriber. For example. configuring each subscriber with 250 agents. With load balancing. you can split the load between the two subscribers. Normally (as in the 2:1 redundancy scheme) a backup server has no devices registered unless its primary is unavailable. To plan for 50/50 load balancing. more CPU resources are consumed on the Cisco CallManager server. CTI limits. Average call duration — Longer average call duration means a lower busy-hour call completion rate. MCS-7845H-3000 servers have a total server limit of 500 IPCC agents. for the redundant pair do not exceed the limits allowed for a single server. (See the configuration for 500 agents in Figure 6-2. For additional information on general call processing topics such as secondary TFTP servers and gatekeeper considerations. make sure that all capacity limits are observed so that IPCC agent phones. such as: – CTI ports – Gateway ports – Agent phones – Route points – CTI Manager • • • The load (BHCA) processed by these devices.

page 6-1. This difference is due to the way ISN routes the calls (as described in the preceding paragraph) and to the fact that the H. page 4-20. This difference is due to the fact that ISN does not require calls to be routed to Cisco CallManager before call treatment.323 gateway protocol uses more CPU resources than MGCP does. Cisco CallManager release. • Tests conducted with a complex call flow (call treatment then transfer to agents) using IP IVR with H323 gateways show an increase in CPU usage compared to the same call flow using ISN (H. but this is not a recommended configuration and is not supported by Cisco Technical Assistance Center.) – IVR self-service – Call treatment – Routing to agents – Transfers and conferences CPU consumption varies by type of call flow. for more information). complex call flows using IP IVR with Media Gateway Control Protocol (MGCP) gateways show an increase in CPU usage compared to the same call flow using ISN (H.323 gateway). This balancing of resources will prevent overloading one server to benefit the others. ISN configurations.) CPU consumption due to Default traces will vary based on load. (Changing the tracing level from Default to No tracing can decrease CPU consumption significantly at high loads. Please consult with your Cisco Systems Engineer for proper sizing of your system requirements. but CPU consumption for complex call flows is much higher. the CPU consumption is moderate. Cisco CallManager is involved only when calls are transferred to agents (simple call handling). depending on the trace level enabled. Similarly. Cisco IP Contact Center Enterprise Edition SRND 6-14 OL-7279-04 . call flow complexity.Chapter 6 Impact of IPCC Application on Cisco CallManager Performance and Scalability Sizing Cisco CallManager Servers For IPCC • Server platform type: – Standard – High-performance • Application call flow complexity (See the definitions of simple and complex call flows in the section on Call Processing With IPCC Enterprise. simple call flow configurations. The trade-off is that ISN gateways have increased performance demands. instead. • • • • • Memory consumption and disk I/O resources (battery-backed write cache) Phone authentication and encryption It is important to balance all resources equally as much as possible if you are using more than one primary Cisco CallManager server. and so forth.000 agents per Cisco CallManager cluster. applications installed. and a lower call arrival rate (BHCA) might be able to support more than 2.323 gateway). (See Sizing ISN Components. For simple call flows. Trace level enabled Cisco CallManager CPU resource consumption varies. Changing the trace level from Default to Full on Cisco CallManager can increase CPU consumption significantly under high loads.

transfer. depending upon agent configuration in the ICM). and wrap-up) and call control (answer. and the IPCC phone extension to be used for this login session. ready. If the CTI OS Server runs on its own platform. the agent is presented with a dialog box that prompts for agent ID. The CTI OS Server can run on the same Peripheral Gateway (PG) server as the Cisco CallManager PG process (typical scenario) or on a separate server. The hardware and third-party software requirements for a CG and PG are the same. release. and agent desktop IP address are all dynamically associated. an IPCC agent desktop is not statically associated with any specific agent or IP Phone extension. From the agent desktop. retrieve. and both are associated with a specific Cisco CallManager cluster.C H A P T E R 7 Agent Desktop and Supervisor Desktop An agent desktop is a required component of an IPCC deployment. hold. make call. IP Phone extension (device target). All communication from the agent desktop passes through the CTI OS Server (see Figure 7-1). This mechanism enables an agent to hot-desk from one agent desktop to another. logout. the agent performs agent state control (login. then that server is sometimes called a CTI gateway (CG) as opposed to a Peripheral Gateway (PG). It is at login time that the agent ID. page 5-1. Agents and IP Phone extensions (device targets) must be configured within the ICM configuration. It also provides for laptop roaming so that an agent can take their laptop to any IP Phone and log in from that IP Phone (assuming the IP Phone has been configured in the ICM and in Cisco CallManager to be used in an IPCC deployment). Agents can also log in to other IP Phones using the extension mobility feature. Server sizing is discussed in the chapter on Sizing IPCC Components and Servers. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 7-1 . not ready. and conference). password (optional. Within the Cisco Intelligent Contact Management (ICM) configuration. The association is released upon agent logout. When logging in from an agent desktop.

Chapter 7 Types of IPCC Agent Desktops Agent Desktop and Supervisor Desktop Figure 7-1 Agent Desktop Communication with CTI OS Server ICM central controller PG server PG 1 IPCC Agent desktops IP phones PG Agent IP CTI OS server CTI server CCM PIM OPC JTAPI IP IVR 1 JTAPI SCI CallManager Cluster M M M IP IP IP IVR 1 PIM JTAPI IP IVR 2 PSTN V IP voice TDM Voice CTI/Call control data IVR 2 PIM SCI For each Cisco CallManager PG (and Cisco CallManager cluster). All agent state change requests flow from the agent desktop through CTI OS to the CTI Server to the Cisco CallManager PG to the ICM Central Controller. The CTI OS Server interfaces with the CTI OS desktop and toolkit as well as Cisco Agent Desktop (Release 6. then typically to either the ICM Central Controller or the Cisco CallManager. there is one CTI OS Server. make call. CTI Object Server (CTI OS) — A toolkit for agent desktops that require customization or integration with other applications on the desktop or with customer databases such as a Customer Relationship Management (CRM) application. The Cisco CallManager then performs the requested call or device control. It is the role of the Cisco CallManager PG to keep the IPCC agent desktop and the IP Phone in sync with one another. There may be one or more CTI OS Servers connecting to the CTI Server. Call control (answer. All communications from the CTI OS Server are passed to the CTI Server. Cisco IP Contact Center Enterprise Edition SRND 7-2 132072 OL-7279-04 . release.0 and later). hold. Types of IPCC Agent Desktops There are three types of IPCC agent and supervisor desktops available: • • Cisco Agent Desktop — A packaged agent desktop solution. retrieve. and so on) flows from the agent desktop through the CTI OS Server to the CTI Server to the Cisco CallManager PG and then to the Cisco CallManager. The CTI OS Server and the Cisco CallManager PG communicate with each other via the Open Peripheral Controller (OPC) process. then via OPC to the Cisco CallManager PG process. The ICM Central Controller monitors the agent state so that it knows when it can and cannot route calls to that agent and can report on that agent's activities.

and CTI OS cannot co-exist with Cisco CallManager PG. Source code for these executables is provided. as described in the previous section. SPAN port silent monitoring — A server-based and switch-based silent monitor solution that works with IPPA as well as Cisco Agent Desktop agents. statements about Cisco Agent Desktop apply to both Cisco Agent Desktop and Cisco Supervisor Desktop.) IP Phone Agents (IPPA) — This is an XML application that allows agents on Cisco 7940 and 7960 IP Phones to log in and perform basic ACD functions from their phones. intercept. and silent monitoring. Source code is also provided with a number of sample applications. These integrations are based on the CTI OS toolkit and are not discussed individually in this document. In addition to an agent desktop. except where specifically noted. operational agent and supervisor desktop executable. The Cisco Supervisor Desktop integrates with Cisco Agent Desktop and allows supervisory functions such as barge-in. It has a system administration interface that allows configuration of the desktop and workflow automation. The following sections cover these two desktop options separately. Cisco Agent Desktop and Cisco Supervisor Desktop Throughout this section. Cisco Agent Desktop includes a set of base server applications as well as a VoIP Monitor server application. but it requires a PC to be running at the agent's location. nor can a CTI OS supervisor monitor a Cisco Agent Desktop agent. Cisco Agent Desktop is a packaged agent and supervisor desktop application. a supervisor desktop is available with the Cisco Agent Desktop and CTI OS options. specifying call. and specifying what telephony data will appear on the desktop. The Cisco Agent Desktop and Supervisor Desktop Product Suite is a client-server application providing packaged CTI functionality for Cisco ICM and CTI. the configuration of agents and supervisors must be kept separate. Some customizations can be as simple as using keystroke macros for screen pops. While CTI OS is a toolkit. Cisco Supervisor Desktop cannot be used to monitor a CTI OS agent desktop. The workflow automation interfaces with applications written for Microsoft Windows browsers and terminal emulators. The CTI OS Toolkit does provide the most flexibility. and data processing functions for buttons. voice. Cisco Agent Desktop. which are included with the toolkit to allow for easy customization. as well as offering advanced tools for integrating the desktop to a database. popping data into third-party applications on answer and sending email on dropped events). Both rely upon communication with the CTI Server.Chapter 7 Agent Desktop and Supervisor Desktop Types of IPCC Agent Desktops • Prepackaged CRM integrations — These integrations are available through Cisco CRM Technology Partners. Prepackaged CRM integrations are provided by the major CRM manufacturers. It allows a custom agent or supervisor desktop to be developed. one major distinction between the two desktop solutions is that Cisco Agent Desktop offers all of the following features: • • • Ad-hoc recording (CTI OS users must rely on a third-party recording solution. it does provide a pre-built. Aside from the differences between configured versus customized applications. Supervisor Desktop. CRM. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 7-3 . or other applications. The workflow automation enables data processing actions to be scheduled based on telephony events (for example. CTI OS does offer endpoint monitoring. These packages are based upon either CTI or CTI OS tools. Desktop configuration includes: defining what buttons are visible. which is not the case with IPPA.

Prior to Release 6. HTTP Post/Get action enables interaction between Agent Desktop (Premium version only) and web-based applications. configuration data is now stored in Directory Services Desktops are automatically updated when new versions are detected at startup System redundancy Cisco Desktop Administrator includes the following new features: • Configuration settings are set up and maintained through the Cisco Agent Desktop Configuration Setup utility. These configuration settings are no longer set up during the installation process. The Cisco Agent Desktop servers may be co-resident on the Peripheral Gateway (PG). the Cisco Agent Desktop servers might require a dedicated server. Cisco Agent Desktop received its CTI input from the CTI server. page 5-1. which can be accessed through the Desktop Administrator (or as a standalone program). Similarly.Chapter 7 Types of IPCC Agent Desktops Agent Desktop and Supervisor Desktop One of the base Cisco Agent Desktop services. Figure 7-2 Cisco Agent Desktop PSTN IP phone IP Agent PC -Cisco Agent Desktop Cisco voice gateway V Cisco Catalyst -SPAN port for Silent Monitor (optional) Administrator PC -Administrative Workstation Agent PC -Cisco Agent Desktop Supervisor PC -Cisco Supervisor Desktop -Media termination (optional) -Cisco Agent Desktop Ethernet LAN M ICM IP IVR Cisco Agent Desktop Release 6.0(1) includes the following new features: • • • • CTI OS-based implementation No longer dependent on shares. is a monitor-only CTI application that provides value-added services to the agent desktop. Figure 7-2 illustrates the system components. refer to the chapter on Sizing IPCC Components and Servers. for redundancy) -Cisco Desktop Base Server -Cisco Desktop VoIP Monitor Server -Cisco Desktop Recording Server . Cisco Agent Desktop receives its CTI input from the CTI OS Server. the Enterprise server. with Release 6. • Cisco IP Contact Center Enterprise Edition SRND 7-4 OL-7279-04 132175 Cisco CallManager PG and CTI OS -Cisco Desktop Base Server -Cisco Desktop VoIP Monitor Server -Cisco Desktop Recording Server PG and CTI OS (optional.0.0 and later (except for IPCC Express). For more information on server requirements. As the number of agents increases. the other Cisco Agent Desktop services provide value-added features such as recording and chatting.

Provides access to agent logs. refer to the Cisco Agent Desktop User’s Guide.htm Cisco Agent Desktop The Cisco Agent Desktop software provides the core component of the Cisco Agent Desktop application: the softphone. screen reader-compatible tool tips for all controls. Messages can be tagged as high priority for immediate notice. call and agent event logging. workflow automation. and conference calls.htm Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 7-5 . agents can chat with supervisors and other team members. available at http://www. Report Preferences allow you to choose which columns are displayed in reports. and an integrated browser in one window. answer.cisco. chat windows or supervisor interventions).cisco. Improved status bar provides more information about system status.com/univercd/cc/td/doc/product/icm/icmentpr/icm46doc/ipccdoc/cadall/cad60d/i ndex. Cisco Outbound Option now includes the Direct Preview Dialing mode. For more information on the Cisco Agent Desktop. With Cisco Agent Desktop. refer to the Cisco Agent Desktop and Supervisor Desktop product documentation. enterprise data. If your version of Cisco Agent Desktop includes media termination. available at http://www. and audible tones that sound when a non-agent-initiated dialog appears (for example. Cisco Supervisor Desktop includes the following new features: • • • • • Agent call data now includes the skill group. The media termination softphone allows the agent to make. Accessibility improved with the addition of improved icons. and agent real-time statistics. they can use the Cisco Agent Desktop softphone by itself. login. Improved status bar provides more information about the user and system status. screen reader-compatible shortcut key. Chat Selection window displays agent phone hook states.com/univercd/cc/td/doc/product/icm/icmentpr/icm46doc/ipccdoc/cadall/cad60d/i ndex. Individual agent statistics combined into a Team Agent Statistics report. agents do not need a physical IP phone. Chat capability has been enhanced in the following ways: • • • Agents are no longer limited to chatting with conference call participants. with the ability to record more calls simultaneously (32 calls in Enhanced version or 80 in Premium version) Multiple dedicated Recording & Playback servers For more information. call activity.Chapter 7 Agent Desktop and Supervisor Desktop Types of IPCC Agent Desktops Cisco Agent Desktop includes the following new features: • • • • Improved Agent Desktop interface now includes call control. transfer. Recording capability has been enhanced in the following ways: • • Recording is scalable. you have the option of using either a Cisco IP Phone (7940 or 7960) or media termination (softphone).

and enter reason codes and wrap up data. including Customer Relationship Management (CRM) systems. For more information on the Cisco IP Phone Agent. Cisco Supervisor Desktop requires an instance of Cisco Agent Desktop running co-resident on the supervisor's PC. It is Cisco's latest version of the CTI implementation. Configuration and behavior information is managed at the server. refer to the IP Phone Agent User’s Guide. During the Supervisor Desktop installation process. This instance of Agent Desktop is the same as the instance of Agent Desktop on the agent PCs.0. Thin-client and browser-based applications that do not require Cisco software on the desktop can be developed and deployed with CTI OS. IPPA uses the XML display capability of the Cisco 7940 and 7960 IP Phones to provide a basic text interface to the agents.0. The Supervisor Desktop installation includes installation of both the Supervisor Desktop software and the instance of Agent Desktop software. With Release 6. An expandable navigation tree control. scalable. Up until Cisco Agent Desktop Release 6. you are prompted to choose the option of using either a hardware IP Phone (either the Cisco 7940 or 7960) or media termination (softphone). available at http://www.cisco. and workflow solutions. is used to navigate to and manage the team's resources. and retrieval of skill group statistics. fault tolerant server-based solution for deploying CTI applications. intercept. IPPA is now supported as the agent’s sole device.Chapter 7 Types of IPCC Agent Desktops Agent Desktop and Supervisor Desktop IP Phone Agent (IPPA) The Cisco IP Phone provides the ability to use the IP Phone as the agent's device. For more information on the Supervisor Desktop. refer to the IPCC Supervisor Desktop User’s Guide. change state. updates. allowing them to log in and out. and maintenance.cisco. The IPPA also provides the agent with caller data and queue data displays. IPPA could be used only as a backup to the desktop application. available at http://www. data mining. CTI OS incorporates the following major components: • • • • CTI OS Toolkit Client Interface Library CTI OS Agent Phone CTI OS Supervisor Phone Cisco IP Contact Center Enterprise Edition SRND 7-6 OL-7279-04 .htm Cisco Supervisor Desktop Cisco Supervisor Desktop provides a graphical view of the agent team being managed by the supervisor. simplifying customization.htm CTI Object Server (CTI OS) Toolkit Cisco CTI Object Server (CTI OS) is a high-performance.com/univercd/cc/td/doc/product/icm/icmentpr/icm46doc/ipccdoc/cadall/cad60d/i ndex. similar to Windows Explorer.com/univercd/cc/td/doc/product/icm/icmentpr/icm46doc/ipccdoc/cadall/cad60d/i ndex. The instance of Agent Desktop allows the supervisor to take calls and enables barge-in. Servers can be accessed and managed remotely. CTI OS serves as a single point of integration for third-party applications.

h tm Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 7-7 . Server sizing for CTI OS is covered in the chapter on Sizing IPCC Components and Servers. the CTI OS server process is the first process you should split off from the PG/CTI Server. CTI OS Server provides a mechanism to maintain agent and call state information so that the agent desktop can be stateless. refer to the Release Notes for CTI OS Release 6.Chapter 7 Agent Desktop and Supervisor Desktop Types of IPCC Agent Desktops Architecturally.0. CTI OS is typically installed in duplex mode. As an IPCC site gets larger. available at http://www. At the supervisor desktop. CTI OS can also run in simplex mode with all clients connecting to one server. these voice packets are decoded and played on the supervisor's system sound card. and additional CTI OS servers can be added to exceed this limitation. This architecture provides the necessary support to develop a browser-based agent desktop if desired. with two CTI OS servers running in parallel for redundancy. page 5-1.cisco. Silent monitoring means that voice packets sent to and received by the agent's IP hard phone are captured from the network and sent to the supervisor desktop. The CTI OS desktop application will randomly connect to either server and automatically fail over to the other server if the connection to the original CTI OS server fails.com/univercd/cc/td/doc/product/icm/icmentpr/icm60doc/icm6cti/ctios60/index. A supervisor can choose to silently monitor an agent on his/her team. CTI OS typically runs on the same server as the CTI Server and Cisco CallManager PG processes. For more information. A single CTI OS server can support a maximum of 500 simultaneous agent logins. CTI OS Server is positioned between the CTI OS agent desktop and the CTI Server.1. Endpoint Silent Monitoring was introduced in CTI OS Release 5. but Cisco does not recommend this configuration. Multiple CTI OS server processes can connect to a CTI Server. The CTI OS system consists of three major components (see Figure 7-3): • • • CTI OS Server CTI OS Agent Desktop CTI OS Supervisor Desktop (only on Cisco IPCC for now) CTI OS Basic Architecture Figure 7-3 PG/CTI platform Cisco CallManager PIM CTIOS server CTI server CTI server driver CTIOS server node TCP/IP JTAPI Agent workstation Desktop computer M Cisco CallManager Voice IP Telephone CTIOS agent/supervisor desktop Active-X controls COM (CtiosClient) C++ CIL 76375 CTI OS Server connects to CTI Server via TCP/IP.

Data Collaboration Server (DCS). and Siebel 7.cisco. web) displayed on the supervisor's desktop Siebel Support — IPCC Enterprise Adapter certified for use with Siebel 7.com/univercd/cc/td/doc/product/icm/icmentpr/icm60doc/icm6cti/ctios60/index.com/en/US/products/sw/custcosw/ps14/prod_technical_reference_list.com/en/US/products/sw/custcosw/ps427/prod_technical_reference_list.pdf • Integrating Cisco Agent Desktop into a Citrix Thin-Client Environment This document helps guide a Citrix administrator through the installation of Cisco Agent Desktop Release 6.pdf • Cisco Agent Desktop Service Information This document provides release-specific information such as product limitations.05 and 7.cisco. error messages. configuration files.com/application/pdf/en/us/guest/products/ps14/c1667/ccmigration_09186a0 080225251.html • Voice-Over IP Monitoring Best Practices Deployment Guide for CAD 6.cisco.1.com/application/pdf/en/us/guest/products/ps427/c1225/ccmigration_09186a 008038a48d.cisco. registry entries. http://www. CTI OS Server. http://www.0/6.cisco. refer to the Cisco CTI Object Server product documentation.h tm Additional Information about Cisco Agent Desktop and Supervisor Desktop The following additional information related to Cisco Agent Desktop and Cisco Supervisor Desktop is available at the listed URLs: • CTI Compatibility Matrix Provides tables outlining ICM Peripheral Gateway (PG) and Object Server (OS) support for versions of Cisco Agent Desktop.com/application/pdf/en/us/partner/products/ps427/c1244/cdccont_0900aecd 800e9db4. service connection types and port numbers.cisco.1 This document provides information about the abilities and requirements of voice over IP (VoIP) monitoring for Cisco Agent Desktop (CAD) Releases 6.Chapter 7 Additional Information about Cisco Agent Desktop and Supervisor Desktop Agent Desktop and Supervisor Desktop CTI OS also provides the following features: • • • CTI OS JavaCIL API — SDK for Java-based desktops for agents and supervisors CTI OS Supervisor support for Agent Availability Status for IPCC across multi-media domains — Agent availability in multi-media channels (email. This information is intended to help you deploy VoIP monitoring effectively.0 applications in a Citrix thin-client environment. http://www.0 and 6. event/error logs. available at http://www.html • Cisco ICM Software CTI Server Message Reference Guide (Protocol Version 9) This document describes the CTI Server message interface between Cisco ICM software and application programs. http://www. Siebel 6. CTI OS Client. http://www.53 For more information. and troubleshooting.pdf Cisco IP Contact Center Enterprise Edition SRND 7-8 OL-7279-04 .

pdf Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 7-9 .cisco.Chapter 7 Agent Desktop and Supervisor Desktop Additional Information about Cisco Agent Desktop and Supervisor Desktop • Cisco ICM Software CTI OS Developer's Guide This document provides a brief overview of the Cisco CTI Object Server (CTI OS).com/application/pdf/en/us/guest/products/ps14/c1667/ccmigration_09186a0 080228190. and describes the syntax and usage for CTI OS methods and events. introduces programmers to developing CTI-enabled applications with CTI OS. http://www.

Chapter 7 Additional Information about Cisco Agent Desktop and Supervisor Desktop Agent Desktop and Supervisor Desktop Cisco IP Contact Center Enterprise Edition SRND 7-10 OL-7279-04 .

including recommendations on how to apply proper Quality of Service (QoS) to WAN traffic flows. Enterprises deploying networks that share multiple traffic classes.0. This chapter presents recommendations for configuring QoS for the traffic flows over the WAN. QoS deployment on the public network enables remote Peripheral Gateways (PGs) to share a converged network and. prefer to maintain their existing infrastructure rather than revert to an incremental.C H A P T E R 8 Bandwidth Provisioning and QoS Considerations This chapter presents an overview of the IPCC Enterprise network architecture. point-to-point leased-line network connections for both its private (duplexed controller. redundant IP routers. application layer Quality of Service (QoS) packet marking on the IPCC public path is supported from within the IPCC application. side-to-side) as well as public (Peripheral Gateway to Central Controller) WAN network structure. Scalability becomes an issue with IntServ because state information of thousands of reservations has to be maintained at every router along the path. bandwidth. IPCC does not support IntServ. flow categorization. As a coarse-grained. see Architecture Overview. The IntServ model relies on the Resource Reservation Protocol (RSVP) to signal and reserve the desired QoS for each flow in the network. categorizes traffic into different classes. Beginning with IPCC Enterprise Release 5. dedicated network. Adequate bandwidth provisioning is a critical component in the success of IPCC deployments. and provisioning requirements of the IPCC network. guarantees the stringent ICM/IPCC traffic latency. Provisioning guidelines are presented for network traffic flows between remote components over the WAN. of course. Bandwidth guidelines and examples are provided in this chapter to help with provisioning the required bandwidth. The public network that connects the remote PGs to the Central Controller is the main focus. IPCC applications are not aware of RSVP and. The QoS considerations in this chapter are based on DiffServ. two QoS models have been used: Integrated Services (IntServ) and Differentiated Services (DiffServ). Historically. in contrast. at the same time. thus simplifying WAN deployment in a converged network environment when that network is enabled for QoS. IP-based prioritization and segmentation. including network segments. keep-alive (heartbeat) traffic. and end-to-end QoS solution. therefore. For a more detailed description of the IPCC architecture and various component internetworking. DiffServ is more widely used and accepted. deployment characteristics of the network. and specific forwarding treatments are then applied to the traffic class at each network node. Essential network architecture concepts are introduced. Cisco IP Contact Center (IPCC) has traditionally been deployed using private. and such support is a key aspect of Cisco Powered Networks. and appropriate priority queuing. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 8-1 . and traffic-related prioritization requirements inherent in the real-time requirements of the product. Convergent networks offer both cost and operational efficiency. page 1-1. Optimal network performance characteristics (and route diversity for the fault tolerant failover mechanisms) are provided to the IPCC application only through dedicated private facilities. DiffServ. and bandwidth and latency requirements. scalable.

web activity. email. or redirect calls. or TAPI/JTAPI). This chapter focuses primarily on the types of data flows and bandwidth used between a remote Peripheral Gateway (PG) and the ICM Central Controller (CC). maintain. Guidelines and examples are presented to help estimate required bandwidth and. and other non-IPCC mission critical traffic will vary according to the specific integration and deployment model used. In an IP Telephony environment. skill groups. and CTI database application traffic sent to the agent desktops. These design requirements are necessary to ensure both the fault-tolerant message synchronization of specific duplexed Cisco Intelligent Contact Management (ICM) nodes (Central Controller and Peripheral Gateway) as well as the delivery of time-sensitive system status data (agent states. SCCP. For information on proper network design for data traffic. according to the endpoints involved in the call. and IP phones. Call control functions include those used to set up. WAN and LAN traffic can be grouped into the following categories: • Voice and video traffic Voice calls (voice carrier stream) consist of Real-Time Transport Protocol (RTP) packets that contain the actual voice samples between various endpoints such as PSTN gateway ports. tear down.cisco. The flows discussed encapsulate the latter two of the above three traffic groups. and this type of traffic is not addressed in this chapter. • Call control traffic Call control consists of packets belonging to one of several protocols (H. voice and video provisioning is not addressed here. on the network path between sides A and B of a PG or of the Central Controller. and on the CTI flows between the desktop application and CTI OS and/or Cisco Agent Desktop servers. available at http://www. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide.Chapter 8 IPCC Network Architecture Overview Bandwidth Provisioning and QoS Considerations IPCC Network Architecture Overview IPCC is a distributed. low latency. such as screen pops and other priority data.com/go/srnd Cisco IP Contact Center Enterprise Edition SRND 8-2 OL-7279-04 . trunk information. resilient. IP IVR Q-points (ports). and a prioritization scheme favoring specific UDP and TCP application traffic. provision QoS for these network segments. and fault-tolerant network application that relies heavily on a network infrastructure with sufficient performance to meet the real-time data transfer requirements of the product. IPCC priority data includes data associated with non-real-time system states.cisco. where applicable.com/go/srnd Data traffic consisting of various HTTP. refer to the Network Infrastructure and Quality of Service (QoS) documentation available at http://www. A properly designed IPCC network is characterized by proper bandwidth. For bandwidth estimates for the voice RTP stream generated by the calls to IPCC agents and the associated call control traffic generated by the various protocols. call statistics. • Data traffic Data traffic can include normal traffic such as email. control traffic includes routing and service control messages required to route voice calls to peripheral targets (such as agents. and so forth) across the system.323. Because media (voice and video) streams are maintained primarily between Cisco CallManager and its endpoints. Expeditious delivery of PG data to the Central Controller is necessary for accurate call center state updates and fully accurate real-time reporting data. MGCP. For IPCC. or services) and other media termination resources (such as IP IVR ports) as well as the real-time updates of peripheral resource status. such as events involved in reporting and configuration updates.

IP routers in the private network typically use priority queuing (based on the ICM private high/non-high IP addresses and. most communication between them is also over the private network. may be deployed in ICM systems that also interface directly with the carrier network (PSTN) and that deploy the Hosted ICM/IPCC architecture. Figure 8-1 Example of Public and Private Network Segments for an IPCC Enterprise System CallRouter A CallRouter B V V PG 1A PG 1B Public Network PG 2A PG 2B 126999 CC/PG Private Network The following notes apply to Figure 8-1: • The private network carries ICM traffic between duplexed sides of the CallRouter or a PG pair. A third network.Chapter 8 Bandwidth Provisioning and QoS Considerations IPCC Network Architecture Overview Network Segments The fault-tolerant architecture employed by IPCC requires two independent communication networks. The signaling access network is not addressed in this chapter. The public network carries traffic between the Central Controller and call centers (PGs and AWs). When a router process and its logger process are deployed on separate nodes. The private network (or dedicated path) carries traffic necessary to maintain and restore synchronization between the systems and to allow clients of the Message Delivery Subsystem (MDS) to communicate. Figure 8-1 illustrates the fundamental network segments for an IPCC Enterprise system with two PGs (with sides A and B co-located) and two geographically separated CallRouter servers. and it must meet aggressive latency requirements. The private link must provide sufficient bandwidth to handle simultaneous synchronizer and state transfer traffic. Note The terms public network and visible network are used interchangeably throughout this document. and it also conveys the state transfer necessary to re-synchronize duplexed sides when recovering from an isolated state. • • Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 8-3 . port numbers) to ensure that high-priority ICM traffic does not experience excessive queuing delay. The public network is also used as an alternate network by the fault-tolerance software to distinguish between node failures and network failures. the private link is critical to the overall responsiveness of the Cisco ICM. This traffic consists primarily of synchronized data and control messages. for UDP heartbeats. used to determine which side of the Central Controller should retain control in the event that the two sides become isolated from one another. the signaling access network. When deployed over a WAN. The public network can also serve as a Central Controller alternate path. The public network carries traffic between each side of the synchronized system and foreign systems. The public network is never used to carry synchronization control traffic. and it must have enough bandwidth left over for the case when additional data will be transferred as part of a recovery operation.

and to the remote Central Controller side over public WAN links. If either end misses 5 heartbeats in a row (that is. a common point of failure) for the multiple PG-to-CallRouter sessions (see Figure 8-1). a TCP Reset message is typically generated from the closing side. This arrangement requires that the public WAN network must provide connectivity between side A and side B. Independent WAN links ensure that any single point of failure is truly isolated between public and private networks. Both ends of a connection send heartbeats at periodic intervals (typically every 100 or 400 milliseconds) to the opposite end. There are several parameters associated with heartbeats. the default heartbeat interval between a central site and a peripheral gateway was 400 ms.0 Central Controller talks to a PG that is prior to Release 5. and so forth. thus. To achieve the required fault tolerance. detects inactivity and in that case causes the server/client side to terminate. The two values of most interest are: • • The amount of time between heartbeats The number of missed heartbeats (currently hard-coded as 5) that the system uses to determine whether a circuit has apparently failed The default value for the heartbeat interval is 100 milliseconds between the central sites. (An exception is that. Be sure to avoid routes that result in common path selection (and. keep-alive packets) across a connection after the connection has been idle for a certain period. you should leave these parameters set to their system default values. and each end looks for analogous heartbeats from the other. Loss of heartbeats can be caused by various reasons.0. if a heartbeat is not received within a period that is 5 times the period between heartbeats). meaning that one site can detect the failure of the circuit or the other site within 500 ms. The IP routers in the public network use IP-based priority queuing or QoS to ensure that ICM traffic classes are processed within acceptable tolerances for both latency and jitter. Each WAN link to a call center must have adequate bandwidth to support the PGs and AWs at the call center. meaning that the circuit failure threshold was 2 seconds in this case. Bridges may optionally be deployed to isolate PGs from the AW LAN segment to enhance protection against LAN outages. then the side detecting this condition assumes that something is wrong and the application closes the socket connection. It operates by sending probe packets (namely. At this point. Detection can be made from either end of the connection. network segments or paths.) Note that the UDP heartbeat remains unchanged in the private network connecting duplexed sites. based on the direction of heartbeat loss. and the connection is considered Cisco IP Contact Center Enterprise Edition SRND 8-4 OL-7279-04 . the process sending the heartbeats failed. provided in the TCP stack. and so forth). the communication automatically reverts to the UDP mechanism. while others can be specified by setting values in the Microsoft Windows 2000 registry. the UDP packets are not properly prioritized.0 and 6. the private WAN link must be fully independent from the public WAN links (separate IP routers. when an ICM Release 5.0. Call centers (PGs and AWs) local to one side of the Central Controller connect to the local Central Controller side via the public Ethernet.0 or 6. public network WAN segments traversing a routed network must be deployed so that PG-to-CallRouter route diversity is maintained throughout the network. such as: the network failed. Some of these values are specified when a connection is established. In general. In ICM Releases 5. as a part of the ICM QoS implementation. • • UDP Heartbeat and TCP Keep-Alive The primary purpose of the UDP heartbeat design is to detect if a circuit has failed. the machine on which the sending process resides is shut down. Prior to ICM Release 5. the UDP heartbeat is replaced by a TCP keep-alive message in the public network connecting a Central Controller to a Peripheral Gateway. The TCP keep-alive feature.0. Additionally.Chapter 8 IPCC Network Architecture Overview Bandwidth Provisioning and QoS Considerations • Remote call centers connect to each Central Controller side via the public network.

scheduling. and policing) to packets based on QoS markings as opposed to IP addresses. in some cases. As a result. ICM applications use three priorities – high. In a converged network. due to extreme latency conditions. meaning that a failure can be detected after 2 seconds. as was the case with the UDP heartbeat prior to Release 5. The approach with IP-based prioritization is to configure IP routers with priority queuing in a way that gives preference to TCP packets with a high-priority IP address and to UDP heartbeats over the other traffic. the network effectively recognized only two priorities identified by source and destination IP address (high-priority traffic was sent to a separate IP destination address) and.Chapter 8 Bandwidth Provisioning and QoS Considerations IPCC Network Architecture Overview down if a keep-alive response from the other side is not heard. as configured at PG setup. prior to QoS. algorithms used by routers to handle network congestion conditions have different effects on TCP and UDP. The dynamic port allocation for heartbeat communications makes it necessary to open a large range of port numbers. However.0 provides marking capability of both Layer-3 DSCP and Layer-2 802. and low. For ICM public connections. delays and congestion experienced by UDP heartbeat traffic can have. The reasons of moving to TCP keep-alive are as follows: • The use of UDP heartbeats creates deployment complexities in a firewall environment. Microsoft Windows 2000 allows you to specify keep-alive parameters on per-connection basis.) A network that is not prioritized correctly almost always leads to call time-outs and problems from loss of heartbeat as the application load increases or (worse) as shared traffic is placed on the network. Traffic marking implies that configuring dual IP addresses on the public Network Interface Controller (NIC) is no longer necessary if the public network is aware of QoS markings. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 8-5 . in the case of UDP heartbeats. • IP-Based Prioritization and QoS Simply stated. traffic prioritization is needed because it is possible for large amounts of low-priority traffic to get in front of high-priority traffic. In a slow network flow. by specific UDP port range in the network. the amount of time a single large (for example. thereby delaying delivery of high-priority packets to the receiving end. thereby allowing a high-priority packet to get on the wire sooner. medium. ICM Release 6. a smaller Maximum Transmission Unit (MTU) size is used by the application for low-priority traffic. thus defeating the original purpose of the firewall device. This delay would cause the apparent loss of one or more heartbeats.0. little correspondence to the TCP connections. (MTU size for a circuit is calculated from within the application as a function of the circuit bandwidth. 1500-byte) packet consumes on the network (and delays subsequent packets) can exceed 100 ms. the keep-alive timeout is set to 5∗400 ms. A QoS-enabled network applies prioritized processing (queuing.1p (using the Microsoft Windows Packet Scheduler) for public network traffic. To avoid this situation. A secondary effect often seen is application buffer pool exhaustion on the sending side.

When a PG starts. Heartbeat traffic — UDP messages with the private high-priority IP address and in the port range of 39500 to 39999. calls. but it must complete its journey to the central site within the half hour (to get ready for the next half hour of data). This document does not address bandwidth sizing for AW traffic. The historical data is low-priority. and so forth it has to monitor. at the respective call center sites. The medium-priority traffic is sent in TCP with the public high-priority IP address. This configuration download can be a significant network bandwidth transient. and they share the physical WAN/LAN circuits that the PGs use.Chapter 8 IPCC Network Architecture Overview Bandwidth Provisioning and QoS Considerations Traffic Flow This section briefly describes the traffic flows for the public and private networks. In summary.0. Private Network Traffic Flow Traffic destined for the critical Message Delivery Service (MDS) client (Router or OPC) is copied to the other side over the private link. Heartbeats are transmitted at 400-ms intervals bidirectionally between the PG and the Central Controller. configuration traffic from the CC. Heartbeat traffic — UDP messages with the public high-priority IP address and in the port range of 39500 to 39999. trunks. The private traffic can be summarized as follows: • High-priority traffic — Includes routing. • Cisco IP Contact Center Enterprise Edition SRND 8-6 OL-7279-04 . Public Network Traffic Flow The active PG continuously updates the Central Controller call routers with state information related to agents. and other traffic from MDS client processes such as the PIM CTI Server. • • Administrative Workstations (AWs) are typically deployed at ACD sites. When this is the case. MDS control traffic. Medium-priority traffic — Includes real-time traffic and configuration requests from the PG to the Central Controller. its configuration data is supplied from the central site so that it can know which agents. Heartbeats are transmitted at 100-ms intervals bidirectionally between the duplexed sides. The low-priority traffic is sent in TCP with the public high-priority IP address. It is sent in TCP with the public high-priority IP address. It is sent in TCP with the private high-priority IP address. The UDP heartbeat traffic does not exist unless the Central Controller talks to a PG that is prior to Release 5. queues. traffic flows from PG to Central Controller can be classified into the following distinct flows: • • High-priority traffic — Includes routing and Device Management Protocol (DMP) control traffic. network activity for the AW must be factored into the network bandwidth calculations. and so forth. and so forth. The PGs also send up historical data each half hour on the half hour. Logger. This type of PG-to-Central Controller traffic is real-time traffic. Low-priority traffic — Includes historical data traffic. and call close notifications.

The Cisco ICM support team has custom tools (for example.0. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 8-7 .000 bytes per call is a rule of thumb. this traffic includes shared non-route control peripheral and reporting traffic. should generally be configured to have 320 kbps of bandwidth. As with bandwidth. respectively. we would expect to need 10. but generally it is roughly 10 to 30 percent. Each post-route request generates between 200 and 300 additional bytes of data on the high-priority path. each taking 10 calls per second. This class of traffic is sent in TCP sessions designated as medium-priority and low-priority. This queuing strategy is fully dependent upon traffic profiles and bandwidth availability.0. The side-to-side private network of duplexed CallRouter and PG nodes has a maximum one-way latency of 100 ms (50 ms preferred). As an example. Without proper prioritization in place. specific latency requirements must be guaranteed in order for the ICM to function as designed. The majority of this data is sent on the low-priority path.0 in steady-state operation is 1. A rule of thumb that works well for ICM software releases prior to 5. and they are stated here for reference purpose only. Client/Server) that can be used to demonstrate proper prioritization and to perform some level of bandwidth utilization modeling for deployment certification. • Bandwidth and Latency Requirements The amount of traffic sent between the Central Controllers (call routers) and Peripheral Gateways is largely a function of the call load at that site.Chapter 8 Bandwidth Provisioning and QoS Considerations Bandwidth and Latency Requirements • Medium-priority and low-priority traffic — For the Central Controller. Translation routes incur per-call data flowing in the opposite direction (CallRouter to PG). the rule of thumb and example described here apply to ICM releases prior to 5. and other synchronized processes.0 and 6. Meeting or exceeding these latency requirements is particularly important in an environment using ICM post-routing and/or translation routes. for more details.) Again. It is sent in TCP with a private non-high-priority IP address. The 1. WAN connections will fail. including call router state transfer (independent session). a site that has 4 peripherals. and they can project bandwidth requirements far more accurately. startup configuration load) and specific configuration sizes also affect the amount of traffic. Depending upon the final network design. State transfer traffic — State synchronization messages for the Router. and prioritization requirements of the product are met. an IP queuing strategy will be required in a shared network environment to achieve ICM traffic prioritization concurrent with other non-ICM traffic flows. page 8-10.000 bytes (8 kb) of data is typically sent from a PG to the Central Controller for each call that arrives at a peripheral. this traffic includes shared data sourced from routing clients as well as (non-route control) call router messages. OPC. although transient boundary conditions (for example. success in a shared network cannot be guaranteed unless the stringent bandwidth. See Bandwidth Sizing. latency. A site that has an ACD as well as a VRU has two peripherals. Therefore. As discussed earlier. with the private non-high priority IP address. For the OPC (PG). ICM bandwidth and latency design is fully dependant upon an underlying IP prioritization scheme. Two bandwidth calculators are supplied for ICM releases 5.000 bytes (80 kb) of data per second to be communicated to the Central Controller. the degree to which post-routing is performed). and the size of this data is fully dependent upon the amount of call context presented to the desktop. (ICM meters data transmission statistics at both the CallRouter and PG sides of each path. The ratio of low to high path bandwidth varies with the characteristics of the deployment (most significantly. As discussed previously. and the bandwidth requirement calculations should take both peripherals into account. but the actual behavior should be monitored once the system is operational to ensure that enough bandwidth exists. The PG-to-CallRouter path has a maximum one-way latency of 200 ms in order to perform as designed. if a peripheral is handling 10 calls per second.

Chapter 8 Network Provisioning

Bandwidth Provisioning and QoS Considerations

Network Provisioning
This section covers:
• • • •

Quality of Service, page 8-8 Bandwidth Sizing, page 8-10 Bandwidth Requirements for CTI OS Agent Desktop, page 8-11 Bandwidth Requirements for Cisco Agent Desktop Release 6.0, page 8-13

Quality of Service
This section covers:
• • • •

QoS Planning, page 8-8 Public Network Marking Requirements, page 8-8 Configuring QoS on IP Devices, page 8-9 Performance Monitoring, page 8-10

QoS Planning
In planning QoS, a question often arises about whether to mark traffic in the application or at the network edge. Marking traffic in the application saves the access lists for classifying traffic in IP routers and switches, and it might be the only option if traffic flows cannot be differentiated by IP address, port and/or other TCP/IP header fields. As mentioned earlier, ICM currently supports DSCP markings on the public network connection between the Central Controller and the PG. Additionally, when deployed with Microsoft Windows Packet Scheduler, ICM offers shaping and 802.1p. The shaping functionality mitigates the bursty nature of ICM transmissions by smoothing transmission peaks over a given time period, thereby smoothing network usage. The 802.1p capability, a LAN QoS handling mechanism, allows high-priority packets to enter the network ahead of low-priority packets in a congested Layer-2 network segment. Traffic can be marked or remarked on edge routers and switches if it is not marked at its source or if the QoS trust is disabled in an attempt to prevent non-priority users in the network from falsely setting the DSCP or 802.1p values of their packets to inflated levels so that they receive priority service. For classification criteria definitions on edge routers and switches, see Table 8-1.

Public Network Marking Requirements
The ICM QoS markings are set in compliance with Cisco IP Telephony recommendations but can be overwritten if necessary. Table 8-1 shows the default markings of public network traffic, latency requirement, IP address, and port associated with each priority flow. For details about Cisco IP Telephony packet classifications, refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide, available at http://www.cisco.com/go/srnd

Cisco IP Contact Center Enterprise Edition SRND

8-8

OL-7279-04

Chapter 8

Bandwidth Provisioning and QoS Considerations Network Provisioning

Note

Cisco has begun to change the marking of voice control protocols from DSCP 26 (PHB AF31) to DSCP 24 (PHB CS3). However, many products still mark signaling traffic as DSCP 26 (PHB AF31). Therefore, in the interim, Cisco recommends that you reserve both AF31 and CS3 for call signaling.
Table 8-1 Public Network Traffic Markings (Default) and Latency Requirements

Priority High

IP address & port

Latency Requirement

DSCP / 802.1p Using Packet Scheduler AF31 / 3

DSCP / 802.1p Bypassing Packet Scheduler AF31 / 3

High-priority public IP address 200 ms and high-priority connection port

Medium High-priority public IP address 1,000 ms and medium-priority connection port Low Non-high-priority public IP address and low-priority connection port 5 seconds

AF31 / 3

AF21 / 2

AF11 / 1

AF11 / 1

Configuring QoS on IP Devices
This section presents some representative QoS configuration examples. For details about Cisco campus network design, switch selection, and QoS configuration commands, refer to the Cisco Enterprise Campus documentation available at http://www.cisco.com/en/US/netsol/ns340/ns394/ns431/networking_solutions_packages_list.html

Note

The terms public network and visible network are used interchangeably throughout this document.
Configuring 802.1q Trunks on IP Switches

If 802.1p is an intended feature and the 802.1p tagging is enabled on the visible network NIC card, the switch port into which the ICM server plugs must be configured as an 802.1q trunk, as illustrated in the following configuration example:
switchport mode trunk switchport trunk encapsulation dot1q switchport trunk native vlan [data/native VLAN #] switchport voice vlan [voice VLAN #] switchport priority-extend trust spanning-tree portfast

Configuring QoS trust

Assuming ICM DSCP markings are trusted, the following commands enable trust on an IP switch port:
mls qos interface mod/port mls qos trust dscp

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

8-9

Chapter 8 Network Provisioning

Bandwidth Provisioning and QoS Considerations

Configuring QoS Class to Classify Traffic

If the ICM traffic comes with two marking levels, AF31 for high and AF11 for non-high, the following class maps can be used to identify the two levels:
class-map match class-map match match-all ICM_Visible_High ip dscp af31 match-all ICM_Visible_NonHigh ip dscp af11

Configuring QoS Policy to Act on Classified Traffic

The following policy map puts ICM high priority traffic into the priority queue with the minimum and maximum bandwidth guarantee of 500 kbps. The non-high-priority traffic is allocated with a minimum bandwidth of 250 kbps.
policy-map Queuing_T1 class ICM_Visible_High priority 500 class ICM_Visible_NonHigh bandwidth 250

Apply QoS Policy to Interface

The following commands apply the QoS policy to an interface in the outbound direction:
interface mod/port service-policy output Queuing_T1

Performance Monitoring
Once the QoS-enabled processes are up and running, the Microsoft Windows Performance Monitor (PerfMon) can be used to track the performance counters associated with the underlying links. For details on using PerfMon for this purpose, refer to the Cisco ICM Enterprise Edition Administration Guide, available at http://www.cisco.com/univercd/cc/td/doc/product/icm/icmentpr/icm60doc/coreicm6/config60/inde x.htm

Bandwidth Sizing
This section briefly describes bandwidth sizing for the public (visible) and private networks.

IPCC Private Network Bandwidth
Because IPCC typically dedicates a network segment to the private path flows (both Central Controller and PG), a specific bandwidth calculation for that segment is usually not required, except when clustering IPCC over the WAN. Cisco therefore does not provide a bandwidth calculator for this purpose. A rule of thumb is to provide a minimum of a T1 link for the Central Controller private path and a minimum of a T1 link for the PG private path.

Cisco IP Contact Center Enterprise Edition SRND

8-10

OL-7279-04

Chapter 8

Bandwidth Provisioning and QoS Considerations Network Provisioning

IPCC Public Network Bandwidth
Special tools are available to help calculate the bandwidth needed for the following public network links:
ICM Central Controller to Cisco CallManager PG

A tool is accessible to Cisco partners and Cisco employees for computing the bandwidth needed between the ICM Central Controller and Cisco CallManager. This tool is called the ACD/CallManager Peripheral Gateway to ICM Central Controller Bandwidth Calculator, and it is available (with proper login authentication) through the Cisco Steps to Success Portal at http://tools.cisco.com/s2slv2/viewProcessFlow.do?method=browseStepsPage&modulename=brow se&stepKeyId=55|EXT-AS-107287|EXT-AS-107288|EXT-AS-107301&isPreview=null&prevTec hID=null&techName=IP%20Communications
ICM Central Controller to IP IVR or ISN PG

A tool is accessible to Cisco partners and Cisco employees for computing the bandwidth needed between the ICM Central Controller and the IP IVR PG. This tool is called the VRU Peripheral Gateway to ICM Central Controller Bandwidth Calculator, and it is available (with proper login authentication) through the Cisco Steps to Success Portal at http://tools.cisco.com/s2slv2/viewProcessFlow.do?method=browseStepsPage&modulename=brow se&stepKeyId=55|EXT-AS-107287|EXT-AS-107288|EXT-AS-107301&isPreview=null&prevTec hID=null&techName=IP%20Communications At this time, no tool exists that specifically addresses communications between the ICM Central Controller and the ISN PG. Testing has shown, however, that the tool for calculating bandwidth needed between the ICM Central Controller and the IP IVR PG will also produce accurate measurements for ISN if you perform the flooring substitution in one field: For the field labeled Average number of RUN VRU script nodes, substitute the number of ICM script nodes that interact with ISN.

Bandwidth Requirements for CTI OS Agent Desktop
This section addresses the traffic and bandwidth requirements between CTI OS Agent Desktop and the CTI OS server. These requirements are important in provisioning the network bandwidth and QoS required between the agents and the CTI OS server, especially when the agents are remote over a WAN link. Even if the agents are local over Layer 2, it is important to account for the bursty traffic that occurs periodically because this traffic presents a challenge to bandwidth and QoS allocation schemes and can impact other mission-critical traffic traversing the network.

CTI OS Client/Server Traffic Flows and Bandwidth Requirements
CTI OS (Releases 4.6.2, 5.x, and 6.x) sends agent skill group statistics automatically every 10 seconds to all agents. This traffic presents a challenge to bandwidth and QoS allocation schemes in the case of centralized call processing with remote IPCC agents over a WAN link. The statistics are carried in the same TCP connection as agent screen pops and control data. Additionally, transmission is synchronized across all agents logged into the same CTI OS server. This transmission results in an order-of-magnitude traffic spike every 10 seconds, affecting the same traffic queue as the agent control traffic.

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

8-11

If we assume 10 agents at the remote site and one supervisor. use any combination of the following options: Configure Fewer Statistics CTI OS allows the system administrator to specify.cisco. This calculator does not take into account the RTP and multimedia messages. This traffic flow should be prioritized and marked as AF21 or AF11. while the effect of system call control traffic is a relatively small component of the overall network load. not just remote ones) handles 3600 BHCA (which equates to 1 call per second). Any other traffic traversing the link should be added to the bandwidth calculations as well and should be marked with proper classification. CTI OS provides a bandwidth calculator that examines bandwidth requirements for communications between the CTI OS Server and the CTI OS Desktop. in the registry. the supervisor could use a different connection profile with statistics turned on. then the bandwidth calculation must to be done separately for each CTI OS Server and added together to derive the total bandwidth of the whole site. The CTI OS Bandwidth Calculator is available at http://www. if the call center (all agents. For more information on agent statistics. Configuring fewer statistics will decrease the traffic sent to the agents. Agent Bandwidth. the statistics items that are sent to all CTI OS clients. This option could eliminate the need for a separate CTI OS Server in remote locations. and Supervisor Bandwidth requirements.htm Best Practices and Options for CTI OS Server and CTI OS Agent Desktop To mitigate the bandwidth demands. For example. if more limited statistics traffic is acceptable for the remote site. A remote supervisor or selected agents might still be able to log statistics by using a different connection profile with statistics enabled. the volume of traffic sent to the supervisor would be considerably less. and a supervisor observing five skill groups would get five packets. then the WAN link bandwidth required to any remote branch.com/univercd/cc/td/doc/product/icm/bandcalc/index. The choice of statistics affects the size of each statistics packet and. Turn Off Statistics on a Per-Agent Basis You can turn off statistics on a per-agent basis by using different connection profiles. The statistics cannot be specified on a per-agent basis at this time. In this case. In the case where remote agents have their skill group statistics turned off but the supervisor would like to see the agent skill group statistics. refer to the CTI OS System Manager's Guide. This bandwidth (between the CTI OS server at the central site and the CTI OS server at the remote site) can be calculated as follows: (3000 bytes) ∗ (Calls per second) = 24 kbps ∗ (Calls per second) For example. available at http://www. For each skill group and agent (or supervisor).com/univercd/cc/td/doc/product/icm/icmentpr/icm60doc/icm6cti/ctios60/ Install Another CTI OS Server at the Remote Branch The bandwidth required between the CTI OS server at the central site and the CTI OS server at the remote site in this scenario is a fraction of the bandwidth that would be required if each remote agent had to access the one central CTI OS server every time. all with the same Cisco IP Contact Center Enterprise Edition SRND 8-12 OL-7279-04 . therefore. these client connections would have no statistics traffic at all between the CTI OS Server and the Agent or Supervisor Desktop. if remote agents use a connection profile with statistics turned off.Chapter 8 Network Provisioning Bandwidth Provisioning and QoS Considerations The network bandwidth requirements increase linearly as a function of agent skill group membership. the packet size for a skill-group statistics message is fixed.cisco. would be only 24 kbps. the network traffic. So an agent in two skill groups would get two packets. it calculates the bandwidth based on the control flow between the CTI OS Server and CTI OS Client only. regardless of the number of remote agents. It calculates Total Bandwidth. If one site has multiple CTI OS Servers and each server has dedicated agents. The 10-second skill group statistics are the most significant sizing criterion for network capacity.

regardless of what the agent is doing. they could do so without impacting the traffic to the remote location if the supervisor uses a different connection profile. page 8-13 Agent State Change. All call scenarios and data presented in this section were tested using the Cisco Agent Desktop software phone (softphone). the supervisor sees all the statistics for the skill groups to which any agent in his agent team belongs). page 8-15 Heartbeats and Skill Statistics Table 8-2 shows the bandwidth usage between Cisco Agent Desktop and the CTI OS and Cisco Agent Desktop servers for heartbeats and skill statistics. By default. Again.cisco.0 This section describes the bandwidth requirements for the Cisco Agent Desktop and Supervisor Desktop applications and the network on which they run. turn them all off. available at http://www. then this approach would reduce skill-group statistics traffic by 90% if only the supervisor has statistics turned on to observe the two skill groups but agents have statistics turned off. assuming only supervisors need to see the statistics. at the main location. Doing so would remove the connections between the CTI OS Server and the Agent or Supervisor Desktop and would eliminate all statistics traffic. It includes bandwidth for call control and any CTI events returned from the CTI service. Skill group statistics were also configured in CTI OS as described in the Cisco Agent Desktop Installation Guide. In the case where there are multiple remote locations. This type of data is passed to and from logged-in agents at set intervals. if agents want to have their skill-group statistics turned on.com Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 8-13 . The refresh interval for these skill group statistics was the default setting of 10 seconds. it would be sufficient to have only one connection profile for all remote supervisors. in this case no additional CTI OS servers would be required. Call Control Bandwidth Usage This section lists bandwidth usage data for the following types of call control communications between Cisco Agent Desktop and the CTI OS Server: • • • Heartbeats and Skill Statistics. page 8-14 Typical Call Scenario.Chapter 8 Bandwidth Provisioning and QoS Considerations Network Provisioning two skill groups configured (in IPCC. Turn Off All Skill Group Statistics in CTI OS If skill group statistics are not required. Also. The reported bandwidth usage represents the total number of bytes sent for the specific scenario. This refresh interval can be configured in CTI OS. all communication between Cisco Desktop applications and the CTI OS server occurs through server port 42028. Bandwidth Requirements for Cisco Agent Desktop Release 6.

653 Bps ∗ 8 bits per byte = 93.1 Bps + (Number of skills ∗ 5.4 Bps) Example If there are 25 remote agents with 10 skills per agent.4 Bps) Bandwidth from Cisco Agent Desktop to CTI OS: 1.220 average bits per second = 93.653 Bps 11.22 kilobits per second (kbps) Agent State Change Table 8-3 lists the total bytes of data sent when an agent changes state from Ready to Not Ready and enters a reason code. the total number of bytes sent from the CTI OS server to Cisco Agent Desktop is: 25 ∗ 6883 = 172. each of whom changes agent state one time.1 Bps + (Number of skills ∗ 46.Chapter 8 Network Provisioning Bandwidth Provisioning and QoS Considerations Table 8-2 Bandwidth Usage for Heartbeats and Skill Statistics (Bytes Per Second) To Cisco Agent Desktop Server CTI OS Cisco Agent Desktop Base Cisco Agent Desktop VoIP Monitor Total 1 Skill 5 Skills From Cisco Agent Desktop 1 Skill 5 Skills 49 2 0 51 234 2 0 0 236 7 2 0 0 9 28 2 0 0 30 Cisco Agent Desktop Recording 0 Bandwidth from CTI OS to Cisco Agent Desktop: 2. Table 8-3 Bytes of Data Used for Agent State Change To Cisco Agent Desktop Server CTI OS Cisco Agent Desktop Base Cisco Agent Desktop VoIP Monitor Total 1 Skill 5 Skills From Cisco Agent Desktop 1 Skill 5 Skills 2043 268 0 2311 6883 268 0 0 7151 523 638 0 0 1161 739 638 0 0 1377 Cisco Agent Desktop Recording 0 Example If there are 25 remote agents with 5 skills per agent.1 Bps + (10 skills ∗ 46. the number of bytes per second (Bps) sent from the CTI OS server to those desktops across the WAN can be calculated as follows: 25 agents ∗ (2.4 Bps) = 11.075 bytes Cisco IP Contact Center Enterprise Edition SRND 8-14 OL-7279-04 .

602. Hang up the call using the softphone controls. For this call scenario. This scenario includes presenting Expanded Call Context (ECC) variables to the agent.cisco. and does not depend on the length of the call (a 1-minute call and a 10-minute call typically use the same amount of bandwidth. held.500 bytes per hour) / (3600 seconds per hour) = 5. and playback. Put the agent in a work ready state. and use the larger of the To/From bandwidth numbers. recording. The amount of bandwidth used is per call. Each ECC variable is 20 bytes in length. excluding voice traffic). but on calls attempted or completed. Select wrap-up data. Cisco Agent Desktop is used to perform the following functions: • • • • • Transition an agent from the work ready state. and then cache it. who each answer 20 calls in the busy hour. For details on traffic marking. 37. The example does not take into account the additional traffic generated if calls are transferred. at startup.Chapter 8 Bandwidth Provisioning and QoS Considerations Network Provisioning Typical Call Scenario Table 8-4 lists the total bytes of data required for a typical call scenario. (18. Answer an incoming ACD call using the softphone controls. assuming a worst-case scenario. Also assume a full-duplex network.com/go/srnd Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 8-15 . Be sure to mark RTP packets for monitoring. Table 8-4 Bytes of Data Used for a Typical Call Scenario To Cisco Agent Desktop 1 Skill 5 Skills 5 ECCs 1 ECC 5 ECCs From Cisco Agent Desktop 1 Skill 1 ECC 5 ECCs 5 Skills 1 ECC 5 ECCs Service CTI OS Cisco Agent Desktop Base Cisco Agent Desktop Recording Cisco Agent Desktop VoIP Monitor Total 1 ECC 19683 4274 0 0 23957 Example 20199 5882 0 0 26081 30804 4674 0 0 35478 31263 5942 0 0 37205 2371 6716 0 0 9087 2371 6832 0 0 9203 2749 6726 0 0 9475 2749 6894 0 0 9643 Assume there are 25 remote agents with 5 skills and 5 ECC variables.602. in addition to other required RTP and signaling marking. which is 37. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide.205 bytes in this case.500 bytes per hour. available at http://www.167 bytes per second (Bps) Note Access to LDAP is not included in the calculation because both Cisco Agent Desktop and Cisco Supervisor Desktop read their profiles only once. or conferenced.205 bytes per call ∗ 25 agents ∗ 20 calls per hour = 18. The numbers in this example are not based on calls in progress.

Both the main office and the remote office have Cisco Agent Desktop agents and supervisors. there are usually no more than 3 to 5 simultaneous monitoring/recording requests at any one time. In that case. Instead of using a centralized VoIP Monitor service. desktop monitoring was introduced as a new feature.Chapter 8 Network Provisioning Bandwidth Provisioning and QoS Considerations Silent Monitoring Bandwidth Usage Starting with Cisco Agent Desktop Release 4. Figure 8-2 Contact Center Diagram Remote Office Router Ethernet Supervisor B V WAN Router Agent B V Main Office Ethernet IP Phone Services: CallManager ICM IPIVR IP IP Phone IP Switch Cisco IP Contact Center Enterprise Edition SRND 8-16 127000 Supervisor A Agent A OL-7279-04 . This service is responsible for all silent monitoring and recording requests for the agent logged in on that desktop. each monitor request requires the bandwidth of an additional call for the desktop. each Cisco Agent Desktop installation includes a miniature VoIP service called the Desktop Monitor service. In this diagram. Silent Monitoring IP Traffic Flow Figure 8-2 shows a main office and a remote office. In practice. It is possible to have multiple silent monitoring requests for the same agent extension from different Cisco Agent Desktop supervisors. For the purposes of this discussion. The maximum number of simultaneous monitoring and recording requests is 21 (one monitoring request from each of the 20 allowed supervisors per team. plus one recording request).6. The bandwidth requirements for the Desktop Monitor service are identical to those of the VoIP Monitor service from the standpoint of monitor requests. 5 simultaneous monitoring/recording sessions are used to calculate the average bandwidth requirements for a single Cisco Agent Desktop installation to support desktop monitoring. Unlike the VoIP Monitor service. but the number of requests sent to the Desktop Monitor service is much lower. the maximum number of recording requests that can be sent to the Desktop Monitor is one. all agents and supervisors belong to the same logical contact center (LCC) and are on the same team. The main office contains the various Cisco Desktop services and the switch shared with the remote office.

2 kbps of the available bandwidth.711 packets carrying 20 ms of speech data require 64 kbps of network bandwidth. If supervisor A monitors agent A. the bandwidth requirements are between the agent's desktop and the supervisor's desktop. you must use the size of the RTP packet plus the additional overhead of the networking protocols used to transport the RTP data through the network. G.) Therefore.2 kbps. Table 8-5 Bandwidth Requirements for Two Streams of Data CODEC G.2 kbps of bandwidth per data stream as it travels over the network. UDP. Each of these protocols adds its own header information to the G. If supervisor A monitors agent B at the remote office. agents and supervisors use media termination softphones. the bandwidth requirement also applies to the WAN link. (Monitor services refers to both the VoIP Monitor service and the Desktop Monitor service. If supervisor A monitors agent B in the remote office. this bandwidth is required between the VoIP Monitor service and the supervisor's computer. the G. IP.711 data.711 codec). both going from the service to the requestor. Monitor services send out two streams for each monitored call. As a result. In Figure 8-2. all of the maximum bandwidth is needed.4 kbps with the G.Chapter 8 Bandwidth Provisioning and QoS Considerations Network Provisioning In the main office. there is 100 Mbps of upload bandwidth and 100 Mbps of download bandwidth. (See Table 8-5. both streams require 87.) These packets are encapsulated by four layers of networking protocols (RTP. In this scenario. Maximum instantaneous bandwidth. This means that. an IP phone call consumes the bandwidth equivalent of a single stream of data. when a voice signal is present. this bandwidth is required on the main office LAN.) When calculating bandwidth. if supervisor A monitors agent A. once packed into an Ethernet frame.729 G. one from A to B and one from B to A. for each monitor session. a G.711 G. In the remote office. and Ethernet). requires 87. you must consider this metric because. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 8-17 .4 174. An IP phone call consists of two streams. If a VoIP Monitor service is used to monitor an agent's extension.4 61 62.711 codec. the bandwidth requirement is for two streams (174.729 with silence suppression Average kbps Per Monitoring Supervisor 174. For full-duplex connections. the bandwidth speed applies to both incoming and outgoing traffic.8 Maximum kbps Per Monitoring Supervisor1 174. (For instance. agents and supervisors use IP phones.4 62. this bandwidth is required on the main office LAN. When silence suppression is used on a physical channel that has fixed capacity.711 IP phone call with no silence suppression requires 87. If desktop monitoring is used.4 1. The bandwidth requirement also applies to the WAN link.711 with silence suppression G. Bandwidth Requirements for Monitor Services to Cisco Supervisor Desktop The amount of traffic between the monitor services and the monitoring supervisor is equal to the bandwidth of one IP phone call (two RTP streams of data).4 62. For an IP phone call using the G. another VoIP Monitor service is needed in the remote office (not shown in Figure 8-2).4 21. for a 100-Mbps connection.711 data.

However. A connection's true speed can differ from the maximum stated due to various other factors. It does not include the bandwidth requirements for other Cisco Agent Desktop modules as outlined in other sections of this document. If the bandwidth requirements approach the total bandwidth available and other applications must share access to the network. • Cisco IP Contact Center Enterprise Edition SRND 8-18 OL-7279-04 . This service sends RTP streams to supervisors for recording playback.0 introduced a new Recording Service. The data represents the codecs without silence suppression. latency does not affect the quality of recorded speech. the bandwidth requirement is the bandwidth between the monitor service and the requestor: • • • • VoIP Monitor service to supervisor Agent desktop to supervisor VoIP service to Recording and Statistics service Agent desktop to Recording and Statistics service Table 8-6 and Table 8-7 display the percentage of total bandwidth available that is required for simultaneous monitoring sessions handled by a single Desktop Monitor service. the additional load of the IP phone call is added to the bandwidth requirement because the IP phone call comes to the same agent where the Desktop Monitor service is located. Bandwidth Requirements for Recording Service to Cisco Supervisor Desktop Cisco Agent Desktop Release 6. the bandwidth requirement on the service's network connection is two streams of voice data. The bandwidth used for the RTP streams is identical to silent monitoring. Download speed affects only the incoming stream for the IP phone call.Chapter 8 Network Provisioning Bandwidth Provisioning and QoS Considerations Bandwidth Requirements for Monitor Service to Recording and Statistics Service The Recording and Statistics service is used to record agent conversations. If a Desktop Monitor service is used. In either case. latency (packet delay) of the voice packets can affect the quality of the monitored speech. With silence suppression. The data shown does not address the quality of the speech of the monitored call. See Table 8-5 for details. The following notes also apply to the bandwidth requirements for the Desktop Monitor service shown in Table 8-6 and Table 8-7: • • • • The bandwidth values are calculated based on the best speed of the indicated connections. Bandwidth Requirements for Desktop Monitor If a VoIP Monitor service is used to monitor or record a call. See Table 8-5 for the bandwidth requirements between the Recording and Statistics service and the monitor service. the amount of bandwidth used may be lower. The data represents only the bandwidth required for monitoring and recording. The bandwidth requirements are based on upload speed.

8 1.7 1.3 5.6 0.1 30.1 95.7 5.1 0.1 0.3 50.4 0.544 Mbps 5.1 NS NS NS NS NS NS NS NS NS 64 kbps 48.6 4.9 68.6 11.9 92.9 85.1 39.8 9.1 38.0 0.1 4. Percentage of Available Bandwidth Required 100 Mbps 0.3 0.5 61.8 10 Mbps 0.1 43.Chapter 8 Bandwidth Provisioning and QoS Considerations Network Provisioning Table 8-6 Percentage of Available Upload Bandwidth Required for Simultaneous Monitoring Sessions with G.9 14.8 3.3 1.1 NS NS NS NS NS NS NS NS NS NS 128 kbps 68.4 73. Percentage of Available Upload Bandwidth Required 100 Mbps 0.1 NS NS NS NS NS NS NS NS NS NS 64 kbps NS NS NS NS NS NS NS NS NS NS NS 1 56 kbps NS NS NS NS NS NS NS NS NS NS NS NS = not supported.0 6.1 1.6 24.1 42.2 95.1 26.6 0.6 1.2 0.9 6.9 2.4 34.3 0.0 10.6 18.3 13.7 72.6 63.0 1.1 18.2 2.6 NS 256 kbps 12.9 1.4 NS NS NS NS NS NS NS 256 kbps 34.9 53. Table 8-7 Percentage of Available Upload Bandwidth Required for Simultaneous Monitoring Sessions with G. The bandwidth of the connection is not large enough to support the number of simultaneous monitoring sessions.4 6.8 NS NS NS NS NS NS NS NS NS NS 1 56 kbps 55.4 73.711 Codec and No Silence Suppression Number of Simultaneous Monitoring Sessions Call only 1 2 3 4 5 6 7 8 9 10 1.3 0.5 0.1 22.7 NS NS NS NS NS NS NS NS NS NS NS = not supported. The bandwidth of the connection is not large enough to support the number of simultaneous monitoring sessions.8 16.6 40.4 4.0 14.6 16.3 1.1 14.5 0.4 NS NS 640 kbps 13.729 Codec and No Silence Suppression Number of Simultaneous Monitoring Sessions Call only 1 2 3 4 5 6 7 8 9 10 1.7 10 Mbps 0.3 0.4 0.544 Mbps 2. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 8-19 .9 84.6 60.2 0.1 82.1 34.8 28.6 2.5 1.3 NS NS NS NS NS NS NS 128 kbps 24.2 36.1 7.2 640 kbps 4.

544 Mbps 11. the amount of bandwidth used may be lower. The bandwidth of the connection is not large enough to support the number of simultaneous monitoring sessions.6 52. With silence suppression.4 5.0 69.2 0. The bandwidth requirements are based on upload speed.711 Codec and No Silence Suppression • • • Table 8-8 Number of Simultaneous Monitoring Sessions 1 5 10 15 20 25 30 35 40 45 50 1. The data represents the codecs without silence suppression. A connection's true speed can differ from the maximum stated due to various other factors.1 NS1 NS NS NS NS NS NS NS NS NS = not supported. The values in Table 8-8 and Table 8-9 are calculated based on the best speed of the indicated connections.5 87. Download speed affects only the incoming stream for the IP phone call.2 34.8 78. the number of monitoring sessions is higher than for the Desktop Monitor service. latency (packet delay) of the voice packets can affect the quality of the monitored speech.7 10 Mbps 1.7 2.1 7. Percentage of Available Upload Bandwidth Required 100 Mbps 0. If the bandwidth requirements approach the total bandwidth available and other applications must share access to the network. The data shown does not address the quality of the speech of the monitored call.7 8.0 7. Some of the slower connection speeds are not shown in Table 8-8 and Table 8-9 because they are not supported for a VoIP Monitor service.6 3.9 1.8 8.2 6. It does not include the bandwidth requirements for other Cisco Agent Desktop modules as outlined in other sections of this document.4 26. Percentage of Available Upload Bandwidth Required for Simultaneous Monitoring Sessions with G.7 17.5 4. However.2 1.2 56. The data represents only the bandwidth required for monitoring and recording. Cisco IP Contact Center Enterprise Edition SRND 8-20 OL-7279-04 .9 43. latency does not affect the quality of recorded speech. as listed in Table 8-8 and Table 8-9: • • • • Because the VoIP Monitor service is designed to handle a larger load.3 61.Chapter 8 Network Provisioning Bandwidth Provisioning and QoS Considerations Bandwidth Requirements for VoIP Monitor Service The following notes apply to the bandwidth requirements for the VoIP Monitor service.

there is 2 kilobytes (kB) of bandwidth per call sent between Cisco Supervisor Desktop and the Chat service.1 6.2 9. Percentage of Available Upload Bandwidth Required 100 Mbps 0.1 40.9 2.1 10 Mbps 0.6 0.2 1.0 28. for more details.729 Codec and No Silence Suppression Number of Simultaneous Monitoring Sessions 1 5 10 15 20 25 30 35 40 45 50 1. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 8-21 .000 bytes per hour (4330. Table 8-10 Cisco Supervisor Desktop Bandwidth for a Typical Agent Call Service CTI OS Cisco Agent Desktop Base Cisco Agent Desktop VoIP Monitor Total To Cisco Supervisor Desktop 0 1650 0 1650 From Cisco Supervisor Desktop 0 550 0 0 550 Cisco Agent Desktop Recording 0 The same typical call scenario was used to capture bandwidth measurements for both Cisco Agent Desktop and Cisco Supervisor Desktop.2 2. If there are 10 agents on the supervisor's team and each agent takes 20 calls an hour.5 2.Chapter 8 Bandwidth Provisioning and QoS Considerations Network Provisioning Table 8-9 Percentage of Available Upload Bandwidth Required for Simultaneous Monitoring Sessions with G.000 bytes) / (3600 seconds per hour) = 92 kBps 92 kBps ∗ 8 bits per byte = 733 kbps.1 31.2 80.6 3.6 1.8 25. For each agent on the supervisor's team.0 20.544 Mbps 4. as shown in Table 8-10.7 21.9 1.6 18.3 0.3 NS1 NS NS NS NS NS NS = not supported. Bandwidth Requirements for Cisco Supervisor Desktop to Cisco Desktop Base Services In addition to the bandwidth requirements discussed in the preceding sections.4 12. there is traffic from Cisco Supervisor Desktop to the Cisco Agent Desktop Base Services. the traffic is: 10 agents ∗ 20 calls per hour = 200 calls per hour 200 calls ∗ 1650 bytes per call = 330. page 8-15.5 15.8 3.1 0.2 60. See Typical Call Scenario.2 1. The bandwidth of the connection is not large enough to support the number of simultaneous monitoring sessions.

Table 8-11 lists the bandwidth usage per report request. Table 8-12 Bandwidth Usage for Team Agent Statistics Report (Average Bytes per Report) Team Agent Statistics Report Service CTI OS Cisco Agent Desktop Base Cisco Agent Desktop VoIP Monitor Total To Cisco Supervisor Desktop 0 250 per agent 0 250 per agent From Cisco Supervisor Desktop 0 200 0 0 200 Cisco Agent Desktop Recording 0 Cisco IP Contact Center Enterprise Edition SRND 8-22 OL-7279-04 . Table 8-12 lists the bandwidth usage per report request. The supervisor can refresh the report manually.Chapter 8 Network Provisioning Bandwidth Provisioning and QoS Considerations There is additional traffic sent if the supervisor is viewing reports or if a silent monitor session is started or stopped. Agent Detail Report This report is refreshed automatically every 30 seconds. Table 8-11 Bandwidth Usage for Agent Detail Report (Average Bytes per Report) Agent Detail Report Service CTI OS Cisco Agent Desktop Base Cisco Agent Desktop VoIP Monitor Total To Cisco Supervisor Desktop 0 220 0 220 From Cisco Supervisor Desktop 0 200 0 0 200 Cisco Agent Desktop Recording 0 Bandwidth for a supervisor viewing the Agent Detail Report is: 220 bytes per request ∗ 2 requests per minute = 440 bytes per minute (440 bytes per minute) / (60 seconds per minute) = 7 bytes per second (Bps) Team Agent Statistics Report This function is a one-time transfer occurring when the supervisor opens the report (no automatic refresh).

Chapter 8

Bandwidth Provisioning and QoS Considerations Network Provisioning

Team Skill Statistics Report

This report is refreshed automatically every 30 seconds. Table 8-13 lists the bandwidth usage per report request.
Table 8-13 Bandwidth Usage for Team Skill Statistics Report (Average Bytes per Report)

Team Skill Statistics Report Service CTI OS Cisco Agent Desktop Base Cisco Agent Desktop VoIP Monitor
Total

To Cisco Supervisor Desktop 0 250 per skill 0 250 per skill

From Cisco Supervisor Desktop 0 200 0 0 200

Cisco Agent Desktop Recording 0

Bandwidth for a supervisor viewing the Team Skill Statistics Report with 10 skills in the team is: 250 bytes per skill ∗ 10 skills ∗ 2 requests per minute = 5000 bytes per minute (5000 bytes per minute) / (60 seconds per minute) = 83 bytes per second (Bps)
Start and Stop Silent Monitoring Requests

Requests to start or stop silent monitor sessions result in a one-time bandwidth usage per request, as listed in Table 8-14.
Table 8-14 Bandwidth Usage to Start or Stop Silent Monitoring (Average Bytes per Request)

Start Monitoring Service CTI OS Cisco Agent Desktop Base Cisco Agent Desktop Recording Cisco Agent Desktop VoIP Monitor
Total

Stop Monitoring From Cisco Supervisor To Cisco Supervisor Desktop Desktop 0 450 0 500 950 0 0 0 150 150 From Cisco Supervisor Desktop 0 0 0 325 325

To Cisco Supervisor Desktop 0 775 0 275 1050

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

8-23

Chapter 8 Network Provisioning

Bandwidth Provisioning and QoS Considerations

Service Placement Recommendations
Table 8-15 summarizes recommendations for service placements that help minimize bandwidth to the desktop. These recommendations apply to deployments with centralized call processing and remote agents.
Table 8-15 Service Placement Recommendations

Service Cisco Agent Desktop Base Services VoIP Monitor Service

Location Central

Reason Traffic to/from centralized IPCC components outweighs the traffic to/from desktops. Span of agent traffic to service. This is a requirement, not a recommendation, for silent monitoring and recording.

Remote, near agents

Recording Service

Close to agents and No CTI. Lots of traffic to/from desktops supervisor if in one location; and from the VoIP Monitor Service(s). central if not With the agents Close to the VoIP Monitor service.

Cisco Desktop Supervisor

For multiple remote locations, each remote location must have a VoIP Monitor service. Multiple VoIP Monitor services are supported in a single logical contact center. The Recording and Statistics service can be moved to the central location if the WAN connections are able to handle the traffic. If not, each site should have its own logical contact center and installation of the Cisco Desktop software.

Quality of Service (QoS) Considerations
When considering which traffic flows are mission-critical and need to be put in a priority queue, rank them in the following order of importance:
1. 2. 3. 4.

Customer experience Agent experience Supervisor experience Administrator experience

With this ranking for the service-to-service flows, traffic between the Enterprise Service and the CTI service (call events) is the most critical. Based on the service placement recommendations in Table 8-15, both services should reside in the central location. However, QoS considerations must still be applied. This traffic should be classified as AF31, similar to voice call control and signaling traffic. The traffic from Cisco Agent Desktop to and from the CTI service (call events, call control) should also be prioritized and classified as AF31. For IP Phone Agent, communications between the IP Phone Agent service and the CTI service are also important because they affect how quickly agents can change their agent state. This traffic should also be classified as AF31.

Note

Cisco has begun to change the marking of voice control protocols from DSCP 26 (PHB AF31) to DSCP 24 (PHB CS3). However, many products still mark signaling traffic as DSCP 26 (PHB AF31). Therefore, in the interim, Cisco recommends that you reserve both AF31 and CS3 for call signaling.

Cisco IP Contact Center Enterprise Edition SRND

8-24

OL-7279-04

Chapter 8

Bandwidth Provisioning and QoS Considerations Network Provisioning

The traffic from Cisco Agent Desktop to and from the Chat service (agent information, call status) is less critical and should be classified as AF21 or AF11.

Cisco Desktop Component Port Usage
For details on network usage, refer to the Cisco Contact Center Product Port Utilization Guide, available at http://www.cisco.com/univercd/cc/td/doc/product/icm/port_uti/index.htm The Desktop application tags only the RTP packets that are sent from the Desktop Monitor software, VoIP Monitor Service, or Recording Service for silent monitoring, recording, and recording playback.

Integrating Cisco Agent Desktop Release 6.0 into a Citrix Thin-Client Environment
For guidance on installing Cisco Agent Desktop Release 6.0 applications in a Citrix thin-client environment, refer to the documentation for Integrating CAD 6.0 into a Citrix Thin-Client Environment, available at http://www.cisco.com/application/pdf/en/us/partner/products/ps427/c1244/cdccont_0900aecd800e 9db4.pdf

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

8-25

Chapter 8 Network Provisioning

Bandwidth Provisioning and QoS Considerations

Cisco IP Contact Center Enterprise Edition SRND

8-26

OL-7279-04

Updates and additions are posted periodically.com/go/srnd. so frequent site visits are recommended. page 9-1 Security Best Practices. page 9-5 Firewalls and IPSec. They must be located in data centers to which Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 9-1 . and SSL Services An adequately secure IPCC configuration requires a multi-layered approach to protecting systems from targeted attacks and the propagation of viruses. and systems management within your contact center. • • • • IP Telephony SRND for Cisco CallManager 3. Cisco has developed a set of documents with detailed design and implementation guidance for various Cisco networking solutions in order to assist enterprise customers in building an efficient. It includes the following sections: • • • • • • • Introduction to Security.3 IP Telephony SRND for Cisco CallManager 4. and Integrated Data (AVVID).cisco. Load Balancing. reliable. These Solution Reference Network Design (SRND) guides. and scalable network. Video. page 9-4 Cisco Security Agent. provide proven best practices to build out a network infrastructure based on the Cisco Architecture for Voice. Among them are the following relevant documents relating to Security and IP Telephony that should be used in order to successfully deploy an IPCC network.C H A P T E R 9 Securing IPCC This chapter describes the importance of securing the IPCC solution and points to the various security resources available. page 9-3 Antivirus. and system availability. page 9-6 Security Features in Cisco CallManager Release 4. page 9-8 Introduction to Security Achieving IPCC system security requires an effective security policy that accurately defines access. you can use many state-of-the-art Cisco technologies and products to protect your data center resources from internal and external threats and to ensure data privacy. secure.0 Data Center Networking: Securing Server Farms SRND Data Center Networking: Integrating Security. connection requirements. integrity. Once you have a good security policy. A first approach is to ensure that the servers hosting the Cisco contact center applications are physically secure.0. which can be found at http://www. page 9-2 Patch Management.

This document. It further assumes that the reader is fully familiar with the applications that compose the ICM and IPCC solutions. While desktop-based applications such as the CTI OS. as well as with the installation and administration of those systems. or Cisco Supervisor Desktop tend to be deployed in open corporate VLANs. The servers may be hardened according to the guidelines provided in the security best-practices guides applicable to your release of the application. CTI OS. the Security Best Practices for Cisco Intelligent Contact Management Software. and Cisco Agent Desktop servers) The security best practices for these servers are consolidated in a document that describes security hardening configuration guidelines for the Microsoft Windows 2000 Server environment. The next level of protection is to ensure the servers are running antivirus applications with the latest virus definition files and are kept up-to-date with Microsoft and other third-party security patches. proper care should be taken to ensure the network links are secure. The security best practices for the following servers vary slightly from the other applications in the IPCC solution: • • • • • ICM Routers ICM Loggers ICM Peripheral Gateways ICM Administrative Workstations (Historical Data Server and WebView) CTI-based servers (CTI. It is the additional intent of these best practices to provide a consolidated view of securing the various third-party applications and operating system upon which the Cisco IP Contact Center applications depend.cisco. Another level of security is the network segmentation of the servers.com/en/US/partner/products/sw/custcosw/ps1001/prod_technical_reference_list. In cases where the servers are geographically distributed. is available at http://www. Cisco IP Contact Center Enterprise Edition SRND 9-2 OL-7279-04 . Security Best Practices Default (Standard) Windows 2000 Server Operating System Installation The IPCC solution consists of a number of server applications which are managed differently. html The recommendations contained in the Security Best Practices guide are based in part on hardening guidelines published by Microsoft. None of the IPCC servers are meant to be deployed as internet-facing systems or bastion hosts (with the only exception of the Web Collaboration option. Cisco Agent Desktop. the Security Best Practices guide strives to present the underlying rationale for the deviation. such as those found in the Windows 2000 Security Hardening Guide. if deployed). The Security Best Practices guide assumes that the reader is an experienced network administrator familiar with securing Windows 2000 Server. Where exceptions or specific recommendations are made. as well as other third-party vendors' hardening recommendations.Chapter 9 Security Best Practices Securing IPCC only authorized personnel have access. The purpose of the Security Best Practices guide is to further interpret and customize those guidelines as they specifically apply to the contact center server products. servers making up the IPCC solution should be placed in the data center behind a secure network.

Cisco recommends that Contact Center customers separately assess all security patches released by Microsoft and install those deemed appropriate for their environments. The hardening specifications for this operating system can be found in the Cisco IP Telephony Solution Reference Network Design (SRND) guide.cisco. where necessary. Internet Service Node (ISN). typically within 24 hours. A field notice update is released when those tests are completed. available at http://www. whereby customers control which and when patches can be deployed to those servers.html Upon the release of a Critical or Important security update from Microsoft.com/cgi-bin/Support/FieldNoticeTool/field-notice Customers should follow Microsoft's guidelines regarding when and how they should apply these updates.cisco.cisco. Cisco continues to test its products to further determine if there are any potential conflicts after the initial field notice. The servers can be configured for Automatic Windows Updates.com/application/pdf/en/us/guest/products/ps556/c1167/ccmigration_09186a0080 157c73. validating higher severity security patches that may be relevant to the Contact Center software products. For the security updates categorized as Impacting.cisco.pdf Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 9-3 . but Cisco recommends that they point to local Software Update Services (SUS) or Windows Update Services (WUS) servers. Cisco assesses the impact on the ICM-based applications and releases a field notice with this assessment. Cisco will continue to provide a service of separately assessing and.Chapter 9 Securing IPCC Patch Management Cisco-Provided Windows 2000 Server Installation (CIPT OS) The IP IVR. Customers can set up a profile to be alerted of field notices announcing security updates by going to the following link: http://www. Cisco-Provided Windows 2000 Server Installation (CIPT OS) Security Patches The Cisco CallManager Security Patch Process is available at http://www.com/go/srnd Patch Management Default (Standard) Windows 2000 Server Operating System Installation Security Patches The security updates qualification process for Contact Center products is documented at http://www. Automated Patch Management ICM-based servers support integration with Microsoft's Software Update Services (SUS).com/en/US/partner/products/sw/custcosw/ps1001/prod_bulletins_list. and Cisco CallManager servers all support a hardened operating system called the Cisco IP Telephony Operating System.

Newer versions improve scanning speed over previous versions.cisco.htm This document also provides Cisco recommendations for applying software updates (Cisco CallManager. Avoid scanning of any files accessed from remote drives (such as network mappings or UNC connections). With a multi-tiered antivirus strategy. scanning across the network and adding to the network load should not be required. IP IVR. Antivirus Applications Supported A number of third-party antivirus applications are supported for the IPCC system. All applicable patches are consolidated and posted once per month as incremental Service Releases A notification tool (email service) for providing automatic notification of new fixes. The following list highlights some general best practices: • • Upgrade to the latest supported version of the third-party antivirus application. For a list of applications and versions supported on your particular release of the IPCC software.cisco. Where possible. especially when an application such as the Cisco Security Agent is installed on the IPCC systems.) Configuration Guidelines Antivirus applications have numerous configuration options that allow very granular control of what and how data should be scanned on a server. the greater the potential performance overhead. Refer to the security best-practices guide and your particular antivirus product documentation for more detailed configuration information on an ICM environment. page 9-5. Note Deploy only the supported applications for your environment.cisco.com within 24 hours as Hotfixes. thus keeping all scanning local. refer to the ICM platform hardware specifications and related software compatibility data listed in the Cisco Intelligent Contact Management (ICM) Bill of Materials and the Cisco CallManager product documentation (available at http://www. (See Cisco Security Agent. Cisco IP Contact Center Enterprise Edition SRND 9-4 OL-7279-04 . and security files is available at http://www. SQL Server. configuration is a balance of scanning versus the performance of the server.cisco. resulting in lower overhead on servers.com/cgi-bin/Software/Newsbuilder/Builder/VOICE.Chapter 9 Antivirus Securing IPCC A document providing information for tracking Cisco-supported operating system files. The role of the system administrator is to determine what the optimal configuration requirements will be for installing an antivirus application within a particular environment. and patches for Cisco CallManager and associated products is available at http://www. and ISN only). The more you choose to scan. otherwise a software conflict might arise.com/univercd/cc/td/doc/product/voice/c_callmg/osbios.com). OS updates.cgi Automated Patch Management The Cisco IP Telephony Operating System configuration and patch process does not currently allow for an automated patch management process. With any antivirus product. The Security Patch and Hotfix Policy for Cisco CallManager specifies that any applicable patch deemed Severity 1 or Critical must be tested and posted to http://www. each of these remote machines should have its own antivirus software installed.

Chapter 9 Securing IPCC Cisco Security Agent • Due to the higher scanning overhead of heuristics scanning over traditional antivirus scanning. Cisco Security Agent should not be considered a substitute for antivirus applications. this configuration does have the overhead of scanning those files that cannot support malicious code (for example. also known as endpoints. Real-time or on-access scanning can be enabled. thereby eliminating known and unknown ("day zero") security risks and helping to reduce operational costs. in all scanning modes.com/en/US/partner/products/sw/voicesw/ps556/products_implementation_design_guides _list. distributed firewall capabilities. malicious mobile code protection.html http://cisco. but only on incoming files (when writing to disk). Support for Standalone Agents and Managed Agents The Cisco Security Agent can be deployed in two modes.com/en/US/partner/products/sw/custcosw/ps1001/prod_technical_reference _list. It identifies and prevents malicious behavior. as provided in the Security Best Practices for Cisco Intelligent Contact Management Software available at http://www. operating system integrity assurance. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 9-5 . To determine when application purge activity is scheduled. While on-demand and real-time scanning of all files gives optimum protection. • Standalone mode — A standalone agent can be obtained directly from the Cisco Software Center for each voice application and can be implemented without communication capability to a central Cisco Security Agent Management Center (MC). Also. refer to the Security Best Practices guides listed in the previous item. Cisco recommends excluding files or directories of files. Implementing on-access scanning on file reads will yield a higher impact on system resources than necessary in a high-performance application environment.html Cisco Security Agent Cisco Security Agent provides threat protection for servers. Cisco Security Agent analyzes behavior rather than relying on signature matching. but both remain critical components to a multi-layered approach to host security. This is the default setting for most antivirus applications. all within a single product. that are known to present no risk to the system.com/en/US/partner/products/sw/voicesw/ps556/products_user_guide_list. and audit log consolidation. Deploying Cisco Security Agent agents on IPCC components involves obtaining a number of application-compatible agents and implementing them according to the desired mode.html • • • Schedule regular disk scans only during low usage times and at times when application activity is lowest. Unlike antivirus applications. use this advanced scanning option only at key points of data entry from untrusted networks (such as email and Internet gateways). The Cisco Security Agent aggregates and extends multiple endpoint security functions by providing host intrusion prevention.cisco. ASCII text files). Guidelines for configuring antivirus applications for Cisco CallManager are available at the following locations: • • http://cisco. follow the recommendations for which specific ICM files to exclude in an ICM or IPCC implementation.

ICM and IPCC Enterprise deployments now add support for IPSec between Central Controller sites and remote Peripheral Gateway (PG) sites as well as between call control servers and agent desktops. and maintaining communications to the agents.cisco. available at http://www.com/kobayashi/sw-center/sw-voice.html. IPCC Enterprise. and Internet Service Node (ISN) Agents.cisco. This secure Cisco IP Contact Center Enterprise Edition SRND 9-6 OL-7279-04 . For an inventory of all the ports used across the contact center suite of applications for the most widely deployed versions of Cisco products.pdf Firewalls and IPSec Firewalls Deploying the application in an environment where firewalls are in place requires the network administrator to be knowledgeable of which TCP/UDP IP ports are used. Its role-based. Features include: • Cisco ICM. part of the CiscoWorks VPN/Security Management Solution (VMS) bundle.cisco.com/en/US/products/sw/secursw/ps2120/prod_release_notes_list. web browser "manage from anywhere" access makes it easy for administrators to control thousands of agents per MC. available at http://www. IPSec and NAT Support for IP Security (IPSec) in Tunnel Mode Due to increased security concerns in the deployment of data and voice networks alike. refer to the Release Notes for the Cisco Secure PIX Firewall. providing software updates. available at http://www.shtml • Other agents.cisco. refer to Installing Cisco Security Agent for Cisco Intelligent Contact Management Software.shtml Third-Party Applications Dependencies Cisco Security Agent can reside on the same server with only those supported applications listed in the Cisco Intelligent Contact Management (ICM) Bill of Materials or the installation guides for the Cisco Security Agent you are installing. For more details on the installation of Cisco ICM agents.com/kobayashi/sw-center/cw2000/voip-planner.Chapter 9 Firewalls and IPSec Securing IPCC • Managed mode — An XML export file specific to the agent and compatible with each voice application in the deployed solution. The advanced CiscoWorks Management Center for Cisco Security Agents incorporates all management functions for agents in core management software that provides a centralized means of defining and distributing policies.cisco.com/univercd/cc/td/doc/product/icm/port_uti/ Note Outbound Option Dialers and Cisco CallManager servers must not be segmented through a PIX firewall. refer to the Cisco Contact Center Product Port Utilization Guides available at http://www. can be downloaded from the same location and imported into an existing CiscoWorks Management Center for Cisco Security Agents.com/univercd/cc/td/doc/product/icm/icmentpr/icm60doc/coreicm6/config60/icm e60ci. available at http://www. For details.

0(0) officially adds support for deployment of Agent Desktops and IP Phones (IPCC) across NAT.com/go/ipsec Support for Network Address Translation (NAT) IPCC Release 6. Cisco IOS™ Network Address Translation (NAT) is a mechanism for conserving registered IP addresses in large networks and simplifying IP address management tasks. In tunnel mode. NAT Traversal is auto-detected and auto-negotiated.html Note The IPSec NAT Transparency feature introduces support for IP Security (IPSec) traffic to travel through Network Address Translation (NAT) or Port Address Translation (PAT) points in the network by addressing many known incompatibilities between NAT and IPSec. are the IOS Routers connecting a central site to a remote site. There are no configuration steps for a router running Cisco IOS Software Release 12. Incoming traffic is translated back for delivery within the inside network. which means that only the Cisco IP Routers (IPSec peers) between the two sites were part of the secure channel establishment. There are also some latency implications. Cisco has also tested locating remote Peripheral Gateway (PG) servers on a NAT network remote from the Central Controller servers (Routers and Loggers).cisco. The testing undertaken in this release was limited to configuration of Cisco IOS™ IPSec in Tunnel Mode. The qualification of NAT support for Agent Desktops and PG servers was limited to a network infrastructure implementing Cisco IP Routers with NAT functionality. NAT Traversal is a feature that is auto-detected by VPN devices.com/en/US/partner/products/sw/iosswrel/ps1834/products_feature_guide09186a00800 8052e. Cisco IOS NAT translates IP addresses within private "internal" networks to "legal" IP addresses for transport over public "external" networks (such as the Internet). so it is important to size the network infrastructure (network hardware and physical links) accordingly.com/go/nat More details on how to deploy IP Phones across NAT for IPCC deployments are available at http://cisco. There are also considerations that must be taken into account for QoS networks.2(13)T and above. If both VPN devices are NAT-T capable. More detailed information on Cisco IOS IPSec functionality is available at http://www. traffic flow confidentiality is ensured between IPSec peers which. in this case. As its name implies. All data traffic is encrypted across the WAN link but unencrypted on the local area networks. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 9-7 .cisco.Chapter 9 Securing IPCC Firewalls and IPSec network implementation implies a distributed model with the WAN connection secured via IPSec tunnels. The qualified specifications for the IPSec configuration are as follow: • • HMAC-SHA1 Authentication (ESP-SHA-HMAC) 3DES Encryption (ESP-3DES) Cisco recommends that you use hardware encryption to avoid a significant increase in IP Router CPU overhead and throughput impact. The common recommendation is to classify and apply QoS features based on packet header information before traffic is tunnel encapsulated and/or encrypted. More detailed resources on how to configure NAT are available at http://www.

• PC Voice VLAN Access – Indicates whether the phone will allow a device attached to the PC port to access the Voice VLAN. Media Encryption Media encryption is currently supported only on the Cisco 7970 IP Phones. – Default: Enabled. it is important to note that IPCC does not support device authentication for the Cisco 7940 and 7960 IP Phones. Set this setting to Enabled if an application is being run on the PC that requires monitoring of the phone’s traffic. which are not supported in an IPCC environment. – This is a required field. features such as silent monitoring and recording will not be available for any agents who are equipped with this model of IP Phone. Disabling Voice VLAN Access will prevent the attached PC from sending and receiving data on the Voice VLAN.0 Securing IPCC Security Features in Cisco CallManager Release 4. The port labeled “10/100 PC” on the back of the phone connects a PC or workstation to the phone so that they can share a single network connection. Cisco IP Contact Center Enterprise Edition SRND 9-8 OL-7279-04 . Due to the performance impact on Cisco CallManager.Chapter 9 Security Features in Cisco CallManager Release 4. Phone Settings The Cisco IP Phone device configuration in Cisco CallManager provides the ability to disable the phone's PC port as well as restricting access of a PC to the voice VLAN. at this time Cisco recommends that you do not enable this feature unless you have conducted thorough performance testing based on the target environment. Changing these default settings to disable PC access will also disable the monitoring feature of the IPCC solution. – This is a required field. It will also prevent the PC from receiving data sent and received by the phone. This could include monitoring and recording applications and use of network monitoring software for analysis purposes. The settings are defined as follows: • PC Port – Indicates whether the PC port on the phone is enabled or disabled. If Cisco 7970 IP Phones are deployed as part of your IPCC solution with Cisco's permission. – Default: Enabled.0.0 Device Authentication When designing an IPCC solution based on Cisco CallManager Release 4.

and Integrated Data Administrative Workstation B BBWC BHCA BHCC BHT BOM bps Bps Battery-backed write cache Busy hour call attempts Busy hour call completions Busy hour traffic Bill of materials Bits per second Bytes per second Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 GL-1 .GLOSSARY Numerics 3DES Triple Data Encryption Standard A ACD ADSL AHT ANI APG AQT ARM ASA ASR AVVID AW Automatic call distribution Asymmetric digital subscriber line Average handle time Automatic Number Identification Agent Peripheral Gateway Average queue time Agent Reporting and Management Average speed of answer Automatic speech recognition Cisco Architecture for Voice. Video.

Glossary C CAD CC CG CIPT OS CIR ConAPI CPE CPI CRM CRS CSS CSV CTI CTI OS Cisco Agent Desktop Central Controller CTI gateway Cisco IP Telephony Operating System Cisco Independent Reporting) Configuration Application Programming Interface Customer premises equipment Cisco Product Identification tool Customer Relationship Management Cisco Customer Response Solution Cisco Content Server Switches Comma-separated values Computer telephony integration CTI Object Server D DCA DCS DES DHCP DID DiffServ DMP DMZ DN DNP DNS Dynamic Content Adapter Data Collaboration Server Data Encryption Standard Dynamic Host Configuration Protocol Direct inward dial Differentiated Services Device Management Protocol Demilitarized zone Directory number Dialed Number Plan Domain Name System Cisco IP Contact Center Enterprise Edition SRND GL-2 OL-7279-04 .

Glossary DSCP DSL DSP Differentiated Services Code Point Digital subscriber line Digital signal processor E ECC Extended Call Context H HA WAN HDS Highly available WAN Historical Data Server I ICC ICCS ICM IDF IDS IntServ IP IPC IPCC IPM IPPA ISN IVR IXC Intra-cluster communications Intra-Cluster Communication Signaling Cisco Intelligent Contact Management Intermediate distribution frame Intrusion Detection System Integrated Services Internet Protocol Cisco IP Communications Cisco IP Contact Center Internetwork Performance Monitor IP Phone Agent Internet Service Node Interactive voice response Inter-exchange carrier Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 GL-3 .

Glossary J JTAPI Java Telephony Application Programming Interface K kb kB kbps kBps Kilobits Kilobytes Kilobits per second Kilobytes per second L LAMBDA LAN LCC LDAP LEC LLA LSPAN Load Adaptive Message-Base Data Archive Local area network Logical contact center Lightweight Directory Access Protocol Local exchange carrier Longest Available Agent Local Switched Port Analyzer M MAC Mbps MC MCS MDF MDS MGCP MoH Media Access Control Megabits per second Management center Cisco Media Convergence Server Main distribution frame Message Delivery Subsystem Media Gateway Control Protocol Music on hold Cisco IP Contact Center Enterprise Edition SRND GL-4 OL-7279-04 .

Glossary MR MRCP MTU Media Routing Media Resource Control Protocol Maximum Transmission Unit N NAT NDIS NIC Network Address Translation Network Driver Interface Specification Network Interface Controller O OPC OS Open Peripheral Controller Object Server P PAT PerfMon PG PHB PIM PLAR PPPoE Progger PSPAN PSTN PVC Port Address Translation Microsoft Windows Performance Monitor Peripheral Gateway Per-hop behavior Peripheral Interface Manager Private Line Automatic Ringdown Point-to-Point Protocol over Ethernet Peripheral Gateway. and Logger Port Switched Port Analyzer Public switched telephone network Permanent virtual circuit Q QoS Quality of Service Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 GL-5 . Router.

S3. and S4 SAA SCCP SCI SCSI SDL SE SLG SPAN SRND SUS Severity levels for service requests Service Assurance Agent Skinny Client Control Protocol Service Control Interface Small Computer System Interface Signal distribution layer Cisco Systems Engineer Service level goal Switched Port Analyzer Solution Reference Network Design Microsoft Software Update Services T TAC TAPI TCP Cisco Technical Assistance Center Telephony Application Programming Interface Transmission Control Protocol Cisco IP Contact Center Enterprise Edition SRND GL-6 OL-7279-04 . S2.Glossary R RAID RIS Rogger ROI RONA RSPAN RSVP RTD RTP Redundant array of inexpensive disks Real-time Information Server Router and Logger Return on investment Reroute On No Answer Remote Switched Port Analyzer Resource Reservation Protocol Real-Time Distributor Real-Time Transport Protocol S S1.

Glossary TDM TES TFTP TNT TOS TTS Time-division multiplexing Task Event Services Trivial File Transfer Protocol Takeback N Transfer Test other side Text-to-speech U UDP UI URL User Datagram Protocol User interface Uniform Resource Locator V V3PN VLAN VMS VoIP VPN VPNSM VRU VSPAN VXML Cisco Voice and Video Enabled Virtual Private Network Virtual local area network CiscoWorks VPN/Security Management Solution Voice over IP Virtual private network Virtual Private Network Services Module Voice Response Unit Virtual LAN Switched Port Analyzer Voice XML (Extensible Markup Language) W WAN WUS Wide area network Microsoft Windows Update Services Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 GL-7 .

Glossary X XML Extensible Markup Language Cisco IP Contact Center Enterprise Edition SRND GL-8 OL-7279-04 .

4-14 1-20 agent-to-agent transfers alternate between calls answered calls APG AQT 5-13 3-39 5-3.1q 8-9 agents average call time general login 1-12 1-12 4-8 4-2 A abandoned calls abbreviations acronyms active time ACD integration GL-1 4-2 xi. 4-12 4-25 staffing requirements state change talk time utilization 4-2 1-20 8-14 additional information Administrative Workstation (AW) admission control after-call work time Agent Desktop bandwidth requirements Base Services CTI OS Toolkit described details 7-3 5-13 7-3 8-13 1-21 4-2. 5-10. 5-11 Agent Reporting and Management (ARM) call talk time Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 IN-1 . 7-1 antivirus applications 5-6. obtaining xiii 2-34 3-1 automatic call distribution (ACD) average after-call work time call duration 3-16 4-9 4-8 4-8 availability of functions and features 8-22 VoIP Monitor Service Agent Detail Report Agent PG (APG) 5-6. 8-2 required servers assistance. xiv 1-7. 5-4 4-9 1-19 Cisco Agent Desktop 7-6 1-6.INDEX Numerics 802. 5-10. 5-11 4-9 9-4 Recording and Playback Service redundancy settings sizing types 1-11 5-12 7-2 5-13 architecture overview ARM ASA 3-16 4-9 1-1. 5-5 3-15 4-10 GL-1 2-34 manually entering the number of number of settings shrinkage sizing 5-9 4-8 recommended number 1-11 4-25 4-5. 4-8 Admin Workstation ConAPI Interface transfers between 4-9 wrap-up time AHT 4-2 4-2.

2-18. 2-17 blended agent option blind transfer broadband 1-17 queuing on IP IVR queuing on ISN routing timeline 2-30 1-12 2-3. 2-19 blockage of calls 2-27 4-3. 5-9 4-9 4-3 2-31 high-priority 4-21 4-17. 1-15. 2-6. 2-6. 4-21 per interval 4-7 1-13. reporting Business Ready Teleworker transferring 1-16 Cisco IP Contact Center Enterprise Edition SRND IN-2 OL-7279-04 . 2-12. 5-9 4-9 call completions (BHCC) traffic (BHT) busy interval speed of answer (ASA) B balancing server loads bandwidth call scenario for call control 8-15 8-13 8-13 2-22 8-11 6-13 C calculators for call center resources for Erlang values 4-4 1-21 4-1 4-6 for Cisco Agent Desktop for CTI OS Agent Desktop for Desktop Monitor for private network for silent monitoring for VoIP Monitor provisioning sizing 8-10 8-1 8-18 call admission control call center terminology call control 8-13 for clustering over the WAN CallManager (see Cisco CallManager) call processing centralized 8-11 2-4 2-9. 4-8 self-service xiii 4-4 4-20. 4-7. 5-5 4-8 4-2 4-9 4-9 busy hour call attempts (BHCA) defined 4-1 4-3 4-1 4-2. 4-7. 2-10. 2-9. 4-21 bugs. 2-14 6-9 6-1 for monitoring services 8-10 8-17 for public (visible) network 8-16 8-21 distributed redundancy with IPCC calls abandoned alternate answered 5-13 for Supervisor Desktop 8-20 latency requirements 8-7 4-10 1-19 4-9 4-3. 4-9 2-3. 4-8 4-9 4-9 Base Services for Cisco Agent Desktop best practices CTI OS bandwidth security BHCA BHCC BHT 9-2 4-25 8-12 blockage completed duration flow normal queuing 1-4 sizing call center resources 4-2. 2-9.Index call treatment time handle time (AHT) queue time (AQT) AW 1-7.

6-5 server capacity sizing servers with IP IVR customer support 6-7 xiii 6-1 supported server platforms 3-13 D xiii Cisco Product Identification Tool Cisco Resource Manager Cisco Security Agent 9-5 5-10 databases DCA xiii 5-7 5-10 3-5 data network Cisco Supervisor Desktop (see Supervisor Desktop) Cisco Technical Assistance Center (TAC) Citrix thin-client environment classifying traffic clients for routing described clusters guidelines redundancy 6-2 6-10 3-15. 3-32 Object Server (see CTI OS) Server CTI OS Agent Desktop architecture failover Toolkit 3-38 5-11 7-6 8-11 1-5. 3-18 2-15 2-26. 4-13 4-8 4-14 combination transfers Combo Box 4-20 1-20 1-15 treatment time wrap-up time capacity combining IPCC and IP Telephony components of IPCC 6-4. 2-19. 2-17. 3-31 3-7 6-5 3-7. 2-12. 4-10. 2-18.com 6-5 6-5 computer telephony integration (see CTI) conferences. 3-10. 6-5 1-6. 5-1 of server platforms planning tool CCMCT CIPT OS Cisco. 6-4 server sizing 7-6 6-4. 8-18 2-4 2-9 clustering over the WAN failover scenarios Desktop Monitor Collaboration Server Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 IN-3 . 1-11 8-25 demilitarized zone (DMZ) deployment models clustering over the WAN described 2-1 3-18 2-15 multi-site with centralized call processing multi-site with distributed call processing single site design tools devices authentication targets 1-10 9-8 2-2 4-4 8-17. 3-37 high availability 3-31 3-7 redundancy 9-8 6-3. 3-28 8-10 1-10.Index treatment 2-10. transfers of Configuration Manager 1-21 1-7 centralized call processing 9-3 xii 2-4 consultative transfer CSS CTI Manager 1-2 1-18 1-2 Content Server Switches (CSS) Cisco Agent Desktop (see Agent Desktop) Cisco CallManager Capacity Tool (CCMCT) described failover recovery releases security 1-1 3-22.

8-16 1-4 documentation feedback obtaining ordering related dual links xii xii. 8-11. 2-12. 2-17. 2-22. 2-14 directory number (DN) distributed ICM DMZ DN DNP 3-18 1-12 1-16 2-14 scenarios firewalls 9-6 2-26.323 3-15 5-8 hardware configurations 4-4. 4-5 HA WAN HDS 5-10 2-15. 5-5 8-4. 8-13 3-1 2-15. 3-22.Index dialed number (DN) Dialer 5-6 1-16 1-12 1-16 CTI OS ICM 3-38 3-1 Dialed Number Plan (DNP) dial plans design considerations 3-23 3-31 recovery 1-12 2-9. xiv xii xi. xiv 2-37. 2-26 heartbeat Extended Call Context (ECC) high availability high-priority calls extensions for IPCC and IP Telephony on same phone 1-15 highly available (HA) WAN 4-17. 3-28 5-9 history of revisions xi 1-15 hybrid IP Telephony and IPCC system clustering over the WAN Cisco IP Contact Center Enterprise Edition SRND IN-4 OL-7279-04 . 5-7 grade of service Email Manager encryption Erlang calculations defined export 4-2 4-10 9-8 H H. 3-15 double trunking 2-20 duration of a call sizing voice glossary 4-24 3-14 GL-1 4-3 Dynamic Content Adapter (DCA) E ECC 5-10 3-15. 2-26 3-39. 2-10. 2-22. 3-17. 2-19 4-13 1-22. 2-18 2-7. 3-23. 5-5 F factors to consider for sizing failover Cisco CallManager 3-22 2-26. 2-38 G gatekeepers gateways centralized distributed port sizing 4-9 5-7 2-4. 3-28 xii distributed call processing feedback on this document flow of calls and messages flow of traffic 8-6. 4-21 Historical Data Server (HDS) 3-39.

2-18. 2-19 4-20 4-23 4-15 server capacities simplified sizing method sizing call center resources sizing components sizing servers Voice Browser IVR 1-4 5-8 5-8 3-14. 2-19 Internet Service Node (see ISN) intra-cluster communications (ICC) IN transfer IPCC agent desktop architecture call flows clusters 6-2 1-15 1-4 7-2 1-1 1-2 described licenses design considerations 4-23 3-15 3-13 Media Server queuing of calls 2-12. SCI 1-3 3-14. 2-17 minimum hardware configurations Outbound Option 2-35 Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 IN-5 . 4-23 2-12. 9-3 9-6 9-6 7-6 software modules infrastructure of the network installation of Windows 2000 integration with ACD with IVR 2-34 2-35 IP Security (IPSec) IP switching IP Telephony 1-2 combined with IPCC extensions ISN Application Server call treatment Combo Box 2-15. 2-18. 4-23 4-20 1-6.Index I ICC ICM Central Controller components described distributed 1-5 1-3 2-14 3-32 3-23 3-13 2-20 1-5 2-15. 8-2 9-2. 2-23 overview security 1-1 9-1 7-2 4-6 supervisor desktop IP IVR described 1-3 IP Communications (IPC) Resource Calculator failover recovery high availability ports 4-12 3-11 3-32 3-11 failover recovery failover scenarios IP IVR redundancy redundancy 3-10 redundancy with ICM IPPA 7-6 with Cisco CallManager 3-13 3-13 private communications routing clients 1-10 1-5 IP Phone Agent (IPPA) IPSec 3-5. 5-1 5-5 combined with IP Telephony components component sizing current release extensions 1-15 xi message flows call treatment integration ports 4-10 3-19 2-10. 2-23 4-20 1-2 1-15 1-15 Intelligent Contact Management (see ICM) Interactive Voice Response (see IVR) interfaces.

3-39. 8-10 8-8 provisioning segments 4-3 8-3 latency requirements 5-13 8-3. 8-6. 8-11 level of service licenses 4-23 8-3. 8-24 5-6 9-8 3-15.Index queuing of calls scripts 5-9 2-10. 3-19 1-2 1-1 overview of IPCC architecture Media Routing (MR) Peripheral Gateway (PG) Cisco IP Contact Center Enterprise Edition SRND IN-6 OL-7279-04 . 8-6. 8-2 L labels LCC 1-11 8-7 private public visible 8-3. 5-6 2-31. 8-8. 5-5 5-13 no answer normal calls non-ICM transfers 4-21 logical call center (LCC) 1-12 O M manually entering the number of agents marking traffic Media Blender media encryption 8-8. 8-11 9-7 8-5 Network Address Translation (NAT) 6-13 8-24 1-23 load balancing Network Interface Controller (NIC) NIC 8-5 1-14 1-19 location of services Logger login locations for call admission control 1-5. 5-6 4-8 OPC 1-5 1-5 Open Peripheral Controller (OPC) outbound option outpulse transfer 2-31. 4-21 4-15 minimum hardware configurations models for deployments monitoring performance monitor services MR PG 3-15. 2-17 media server message flows 5-10 4-24 1-4 5-8 see also IP IVR self-service applications self-service calls sizing servers 5-8 1-20 4-20. 3-34. 3-15 1-20 8-17 2-1 8-10 sizing call center resounces transfers to agents multi-channel multiple transfers J JTAPI 1-8 multi-site deployment centralized call processing distributed call processing 2-4 2-9 K keep-alive message 8-4 N NAT 9-7 network infrastructure 3-5. 8-6. 8-8.

2-18. 5-11 9-8 3-20 3-32 3-33 Q QoS configuration examples planning policy 8-8 8-10 8-1 8-8. 8-24 8-5 8-9 2-22 for clustering over the WAN phone settings recommendations traffic marking trust 8-9 failover scenarios 5-11 traffic prioritization Quality of Service (see QoS) queuing of calls described on IP IVR 4-10 4-3. 2-6. 8-8. reporting product identification Progger 5-5 Recording and Playback Service for Cisco Agent Desktop 5-13 Recording and Statistics service Recording Service 8-18 8-18 xiii Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 IN-7 . 2-19 4-9 percentage of calls queued 1-15 for queuing 4-12 4-13 8-25 1-17 with translation routing 1-13 R Real-Time Distributor (RTD) 8-5 2-20 3-35 1-10 prioritization of traffic private communications private network private WAN 2-23 xiii real-time reporting reconnect 1-19 5-9 4-8 recommended number of agents 8-3. 8-6. 5-9 2-3. 2-12. 2-9. 2-6. 4-8 provisioning (see sizing) PSTN transfers public network 1-21. 2-17 6-4. 2-9. 2-10. 6-5 placement of services platform capacity ports for call treatment for IVR IP IVR sizing usage post route pre-routing 4-10 4-10 on ISN scenarios 2-3. 8-6. 8-10 problems. 8-11 performance monitoring Peripheral Gateway (see PG) Peripheral Interface Manager (see PIM) PG design considerations for Cisco CallManager for Voice Response Unit server options sizing PIM described sizing PIX 9-6 8-24 1-5 3-22 5-10 4-24.Index P patch management PBX transfers 2-35 9-8 9-3 prompt media server protocols SCCP TCP UDP 8-10 2-6 8-4 8-4 4-24 PC port on IP phone percent blockage 4-3. 2-36 8-3.

Index recovery from failover redundancy cluster configurations CTI Manager 3-10 3-31 SCI 1-3 1-7 Script Editor 6-10 scripts security 1-12 9-1 9-5 8-3 design considerations for call processing related documentation releases of software remote agents reporting reports bandwidth usage Logger transfers 3-39 1-20 8-21 5-9 2-27 xi 6-9 3-1 Security Agent self-service calls serial numbers 5-13 segments of a network xi 4-20. 5-1. 6-10 request for technical service reroute on no answer (RONA) resource calculator resource sizing revision history Rogger RONA Router routing calls clients request scripts RSPAN RTD 1-12 1-10. 5-5 1-17 4-1 xi 4-6 required for Cisco Agent Desktop required for CTI Desktop sizing 4-20. 1-11 1-17 1-12 1-13 5-5 1-10. 3-34. 4-21 4-15 self-service IVR applications xiii Remote Switched Port Analyzer (RSPAN) servers capacity planning defined 4-2 4-24 6-4. 5-9 8-16 4-25 xiv Run VRU scripts simplified sizing method for ISN capacity single link 2-21 2-2 4-23 S scalability SCCP 2-6 Cisco IP Contact Center Enterprise Edition SRND single-site deployment model single-step transfer 6-13 1-17 site-to-site communications 2-20 IN-8 OL-7279-04 . 1-14 6-13 5-10 Peripheral Gateway (PG) 6-9. 1-14 1-5. 6-5 for prompt media 3-39 Historical Data Server load balancing redundancy xiii 1-10. 6-1 6-7 1-3 5-3 5-4 supported platforms service grade service level 4-3 4-3 Service Control Interface (SCI) service level goal (SLG) service placement service request session licenses settings for agent desktop on IP phones 9-8 1-11 xiii 4-23 8-24 4-8 route request translation 5-13 3-35 severity level of service request shrinkage of agent staffing silent monitoring 5-8.

5-5 IPCC components and servers IP IVR ports 4-12 4-20 TAC xiii 1-21 Takeback N Transfer (TNT) talk time 4-24. 4-13 4-15 Task Event Services (TES) 3-16 Team Agent Statistics Report Team Skill Statistics Report 4-23 8-22 8-23 self-service IVR applications wrap-up time example skill groups skill statistics SLG 4-8 1-6 4-23 xi. 6-4 1-12. 5-11 5-11 4-2 1-10 ISN components Peripheral Gateway (PG) ports 4-13 4-24 target devices TCP TDM 8-4 1-3 Peripheral Interface Manager (PIM) prompt media server PSTN trunks 4-5. 4-12 8-10 4-11 4-25 4-1 4-13 5-12 6-1 Cisco Supervisor Desktop CTI OS Toolkit described details types support 7-3 7-2 xiii 7-1 7-6 7-3 bandwidth basic example best practices call center resources call treatment example Cisco Agent Desktop factors to consider gateway ports gateways 4-24 4-13 supported server platforms switching 1-2 6-7 5-13 Switched Port Analyzer (SPAN) Cisco CallManager servers 5-9 T 5-1.Index sizing agents 4-5. 6-3. 8-16 4-3 in a bust hour Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 IN-9 . 5-9 8-13 4-14 simplified method for ISN capacity technical assistance terminology TES 3-16 2-23 4-1 xiii xiii Technical Assistance Center (TAC) Skinny Client Control Protocol (SCCP) softphone 2-6 Test other side thin-client environment timeline for calls time on a call xi 4-2 4-4 8-25 1-3 time-division multiplexing (TDM) software licenses software versions SPAN SRND 5-13 xi Solution Reference Network Design (SRND) TNT 1-21 4-8 4-10 tolerance 4-25 8-14 tolerance time for abandoned calls toolkit for CTI OS traffic 8-21 7-6 staffing considerations state change for agents state control 1-12 tools for designing an IPCC solution classification flow 8-10 4-4 statistics reports Supervisor Desktop bandwidth requirements 8-21 8-6. 8-11.

2-26 4-8 highly available 2-23 tunneling Web Collaboration Server WebView Reporting Server wrap-up time 4-2. 8-20 5-13 VoIP Monitor Service for Cisco Agent Desktop 1-13 Translation Route to VRU translation routing treatment of calls treatment time trunks double trunking required number sizing trust 8-9 9-6 1-16 4-5. 5-9 using Cisco CallManager 2-35 1-21. 4-14 5-7 5-5 9-2. 2-9 non-ICM reconnect reporting single step using PBX using PSTN 1-19 1-19 1-20 single-site deployments 1-17 Voice Response Unit (VRU) voice VLAN 9-8 4-24 1-13. 8-24 8-5 U UDP 8-4 8-4 prioritization 8-2 transfer connect agent-to-agent alternate blind 1-19 1-17 1-21 User Datagram Protocol (UDP) 1-20 V V3PN 2-27 xi. 6-4 conferenced calls consultative described multiple IVR to agent 1-20 1-18 1-16 1-20 1-21 versions of software visible network VLAN 9-8 8-3. 2-17. 2-36 2-38 Voice XML (VXML) VoIP Monitor 8-17. 5-8 2-27 multi-site deployments with centralized call processing 2-6. 9-3 types of dial plans Windows 2000 Server installation Cisco IP Contact Center Enterprise Edition SRND IN-10 OL-7279-04 . 4-13 W wait before abandon WAN clustering private 2-15 2-15. 2-22. 5-8. 4-13 2-37. 2-17. 5-6. 2-19 3-14 4-23. 2-12. 2-10. 2-18 2-7. 8-8. 6-3.Index marking types of transfers 8-8. 2-19. 2-38 4-10 4-8 1-13 VRU VXML 8-4 1-13. 2-18. 8-6. 3-33. 5-8. 5-9 4-24 Transmission Control Protocol (TCP) 2-10. 5-6. 3-33. 8-11 Voice and Video Enabled IPSec VPN (V3PN) Voice Browser voice gateways centralized distributed functions ports 2-3 4-13 2-4. 2-12.