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

Revision History xi

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

Obtaining Additional Publications and Information xiv

CHA PTER 1 Architecture Overview 1-1

Cisco CallManager 1-1

Cisco Internet Service Node (ISN) 1-2

Cisco IP Interactive Voice Response (IP IVR) 1-3

Cisco Intelligent Contact Management (ICM) Software 1-3
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 1-12
Agent Login and State Control 1-12
IPCC Routing 1-12
Translation Routing and Queuing 1-13
Reroute On No Answer (RONA) 1-14

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

Contents

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

Queuing in an IPCC Environment 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) 1-21

Call Admission Control 1-21
Gatekeeper Controlled 1-22
Locations Controlled 1-23

CHA PTER 2 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 2-30 IPCC Outbound (Blended Agent) Option 2-31 Traditional ACD Integration 2-34 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 2-38 CHA PTER 3 Design Considerations for High Availability 3-1 Designing for High Availability 3-1 Data Network Design Considerations 3-5 Cisco CallManager and CTI Manager Design Considerations 3-7 Configuring ICM for CTI Manager Redundancy 3-10 Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 v .

Cisco CallManager and CTI Manager Fail 3-23 Scenario 2 . Contents IP IVR (CRS) Design Considerations 3-11 IP IVR (CRS) High Availability Using Cisco CallManager 3-13 IP IVR (CRS) High Availability Using ICM 3-13 Internet Service Node (ISN) Design Considerations 3-13 Multi-Channel Design Considerations (Cisco Email Manager Option and Cisco Collaboration Server Option) 3-15 Cisco Email Manager Option 3-17 Cisco Collaboration Server Option 3-18 Cisco IPCC Outbound Option Design Considerations 3-19 Peripheral Gateway Design Considerations 3-20 Cisco CallManager Failure Scenarios 3-22 ICM Failover Scenarios 3-23 Scenario 1 .ICM Central Controller or Peripheral Gateway Private Network Fails 3-28 Scenario 2 .Only CTI Manager Fails 3-26 IPCC Scenarios for Clustering over the WAN 3-28 Scenario 1 .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 3-38 Cisco Agent Desktop Considerations 3-39 Other Considerations 3-39 CHA PTER 4 Sizing Call Center Resources 4-1 Call Center Basic Traffic Terminology 4-1 Call Center Resources and the Call Timeline 4-4 Cisco IP Contact Center Enterprise Edition SRND vi OL-7279-04 .Cisco CallManager PG Side A Fails 3-24 Scenario 3 .Visible Network Fails 3-29 Scenario 3 .Visible and Private Networks Both Fail (Dual Failure) 3-30 Scenario 4 .Only Cisco CallManager Fails 3-25 Scenario 4 .

Contents Erlang Calculators as Design Tools 4-4 Erlang-C 4-5 Erlang-B 4-5 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) 4-8 Sizing Call Center Agents. 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 4-23 Cisco IOS Gateway Sizing 4-24 ICM Peripheral Gateway (PG) Sizing 4-24 Prompt Media Server Sizing 4-24 Agent Staffing Considerations 4-25 Call Center Design Considerations 4-25 CHA PTER 5 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 5-8 Additional Sizing Factors 5-9 Peripheral Gateway and Server Options 5-10 CTI OS 5-11 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 5-13 Summary 5-14 Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 vii . IVR Ports.

3 and Later 6-4 Cisco CallManager Platform Capacity Planning with IPCC 6-4 Cisco CallManager Capacity Tool 6-5 Supported Cisco CallManager Server Platforms for IPCC Enterprise 6-7 Call Processing Redundancy with IPCC 6-9 Cluster Configurations for Redundancy 6-10 Load Balancing With IPCC 6-13 Impact of IPCC Application on Cisco CallManager Performance and Scalability 6-13 CHA PTER 7 Agent Desktop and Supervisor Desktop 7-1 Types of IPCC Agent Desktops 7-2 Cisco Agent Desktop and Cisco Supervisor Desktop 7-3 Cisco Agent Desktop 7-5 IP Phone Agent (IPPA) 7-6 Cisco Supervisor Desktop 7-6 CTI Object Server (CTI OS) Toolkit 7-6 Additional Information about Cisco Agent Desktop and Supervisor Desktop 7-8 CHA PTER 8 Bandwidth Provisioning and QoS Considerations 8-1 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 Network Provisioning 8-8 Quality of Service 8-8 QoS Planning 8-8 Public Network Marking Requirements 8-8 Configuring QoS on IP Devices 8-9 Performance Monitoring 8-10 Cisco IP Contact Center Enterprise Edition SRND viii OL-7279-04 .2 6-3 IPCC Enterprise with Cisco CallManager Releases 3. Contents CHA PTER 6 Sizing Cisco CallManager Servers For IPCC 6-1 Call Processing With IPCC Enterprise 6-1 IPCC Clustering Guidelines 6-2 IPCC Enterprise with Cisco CallManager Releases 3.1 and 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 into a Citrix Thin-Client Environment 8-25 CHA PTER 9 Securing IPCC 9-1 Introduction to Security 9-1 Security Best Practices 9-2 Default (Standard) Windows 2000 Server Operating System Installation 9-2 Cisco-Provided Windows 2000 Server Installation (CIPT OS) 9-3 Patch Management 9-3 Default (Standard) Windows 2000 Server Operating System Installation 9-3 Cisco-Provided Windows 2000 Server Installation (CIPT OS) 9-3 Antivirus 9-4 Cisco Security Agent 9-5 Firewalls and IPSec 9-6 Firewalls 9-6 IPSec and NAT 9-6 Security Features in Cisco CallManager Release 4.0 9-8 GL O S S A R Y INDEX Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 ix .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.

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

0.com/go/srnd Visit this Cisco. This document builds upon ideas and concepts presented in the Cisco IP Telephony Solution Reference Network Design (SRND). December. Revision Date Comments May. You can obtain the latest version of this document online at http://www. 2005 Fixed several broken links in the online document.cisco. 2006 Corrected a few errors in the text and updated some of the referenced URL.0 and 6. the information in this document applies specifically to Cisco IP Contact Center Enterprise Edition Releases 5.cisco. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 xi . Revision History Unless stated otherwise. 2005 Initial version of this document for Cisco IPCC Enterprise Edition Releases 5. refer to the documentation at the preceding URL. June. To review IP Telephony terms and concepts. The following table lists the revision history for this document.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. which are available online at http://www.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. March.0 and 6. and Integrated Data (AVVID). 2005 Corrected various typographical errors in the document.0. Video. This document may be updated at any time without notice. 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.

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

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

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

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

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

provides the foundation for a Voice over IP (VoIP) solution. and IP phones. and Computer Telephony Integration (CTI) solution. For more information on a particular product. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide.com Cisco CallManager Cisco CallManager. 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.com/go/srnd Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 1-1 . 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. the following Cisco hardware products are required for a complete IPCC deployment: • Cisco IP Phones • Cisco voice gateways • Cisco LAN/WAN infrastructure Once deployed. voice gateways. The following sections discuss each of the software products in more detail and describe the data communications between each of these components. IPCC provides an integrated Automatic Call Distribution (ACD). when combined with the appropriate LAN/WAN infrastructure. refer to the specific product documentation available online at http://www. For details on Cisco CallManager call processing capabilities and clustering options.cisco. available at http://www.cisco. The Cisco CallManager software running on a server is referred to as a Cisco CallManager server. Multiple Cisco CallManager servers can be grouped into a cluster to provide for scalability and fault tolerance. IVR.

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. • 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. After defining the deployment scenario. With the Cisco ISN system. fault tolerant. a Cisco CallManager cluster of servers is capable of supporting thousands of agents. 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. menu. The Cisco ISN can also access customer databases and applications via the Cisco ICM software. Cisco IP Contact Center Enterprise Edition SRND 1-2 OL-7279-04 . 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 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. The Cisco ISN can support multiple grammars for prerecorded announcements. voice is terminated on Cisco IOS® gateways that interact with the ISN application server (Microsoft Windows Server) using VXML (speech) and H. However. how many IP IVR/ISN servers are needed. how many servers and what types of servers are required for the ICM software. how many voice gateways are needed for each site and for the entire enterprise. When ISN treatment is finished. This method eliminates consumption of ports on the gateway for the rest of the call. and so forth. With this transfer method. In a fault-tolerant design. The ISN can optionally provide automatic speech recognition and text-to-speech capability. • IN Transfer Cisco ICM software temporarily routes PSTN-originated calls to ISN via a Cisco IOS Voice Gateway. The ISN architecture is distributed. Advanced load balancing can be provided by Cisco Content Server Switches (CSS). The ICM script can also invoke external VXML applications via ISN. The ISN software is tightly integrated with the Cisco ICM software for application control. and highly scalable. Typically when designing an IPCC solution. Chapter 1 Architecture Overview Cisco Internet Service Node (ISN) A single Cisco CallManager server is capable of supporting hundreds of agents. Cisco Internet Service Node (ISN) The Cisco Internet Service Node (ISN) provides prompting. you first define the deployment scenario. queuing. This method eliminates consumption of ports on the gateway for the rest of the call. but it might not be available with all carriers. play data. but it might not be available with all carriers.323 (call control). including arrival point(s) for voice traffic and the location(s) of the contact center agents. and collect information. The Cisco ISN also provides a queuing platform for the IPCC solution. and call control services using standard web-based technologies. collecting. An additional PSTN port is also required on an egress gateway if the call is transferred to a PSTN-based destination. a PSTN port is used on the ingress gateway for the life of the call. 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. Telephone calls can remain queued on Cisco ISN until they are routed to a contact center agent (or external system). The ICM scripting environment controls the execution of "building block" functions such as play media.

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

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

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

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

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

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

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

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

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

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

the routing client has changed from the Cisco CallManager cluster to IPIVR1. Cisco CallManager and IP IVR will execute the JTAPI routing control messaging to select an available CTI Port. While the call was being transferred. The transfer is completed using the Translation Route to VRU node. Eventually agent 111 becomes available. 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. In Cisco CallManager. When the call is successfully transferred to the IP IVR. the IP IVR becomes the routing client for this routing script. The Translation Route to VRU node returns a unique translation route label to the original routing client. 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 . After the transfer to the IP IVR is successfully completed. 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.) At this point. The re-entry point is the successful exit path of the Translation Route to VRU node. 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. ANI. the routing script was temporarily paused. and as in the previous example. Chapter 1 Architecture Overview IPCC Routing Figure 1-4 Routing Script Example Route request (DN. The translation route label will equal a DN configured in Cisco CallManager. (See Figure 1-5. the Cisco CallManager cluster. CED) CallManager Cluster Agent ID Dev Target 111 1234 Dev Target Rtg Client Label 1234 CM Cluster 1234 1234 IPIVR 1 1234 1234 IPIVR 2 1234 Route response returned to CallManager Cluster 76581 Translation Routing and Queuing If no agents are available. 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 IP IVR translation routing application first sends a request instruction message to the ICM via the SCI between the IP IVR and the ICM.

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. 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. Again. a translation route and a set of labels is required. Cisco IP Contact Center Enterprise Edition SRND 1-14 OL-7279-04 . If no IP IVR ports are available. 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. if a deployment has one Cisco CallManager cluster and four IP IVRs. all call data is preserved. then it is important to resize your IP IVR port capacity. you can set the RONA timer and the DN used to specify a unique call type and routing script for RONA treatment. then the script should execute a Busy node. If no agent is available. the call can be sent back to the IP IVR for queuing treatment again. If a high number of calls are executing Busy nodes. In the agent desk settings. For example. 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. The label returned (1234) when agent 111 becomes available causes the IP IVR to transfer the call to agent 111 (at extension 1234). Figure 1-5 Translation Routing and Queuing Original Original route request routing client CallManager Cluster New routing client IPIVR 1 Agent ID Dev Target 111 1234 Dev Target Rtg Client Label 1234 CM Cluster 1234 1234 IPIVR 1 1234 1234 IPIVR 2 1234 Route response returned to IPIVR 1 76582 For each combination of Cisco CallManager cluster and IP IVR. Chapter 1 Architecture Overview IPCC Routing of device target and routing client. then four translation routes and sets of labels are required. Any call data is preserved and popped onto the next agent's desktop. Note that the routing client is now the IP IVR. For deployments with multiple IP IVRs.

and the chapter on Deployment Models. it might sometimes be advantageous to separate Cisco CallManager clusters for IP Telephony extensions from the Cisco CallManager clusters for IPCC extensions. 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. Traditional IVRs can also be used in IPCC deployments. it is important to consider how queuing and requeuing are going to be handled. or visibility of. Also. The chapter on Deployment Models provides considerations for deployments with ISN. also provides considerations for deployments with traditional IVRs. In an IPCC environment. so that agents are not interrupted by IP Telephony calls while they are working on IPCC calls. 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. Combining IP Telephony and IPCC Extensions on the Same IP Phone It is possible to have multiple extensions on an IP phone. 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. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 1-15 . called Internet Service Node (ISN). and no call forwarding. those IP Telephony extensions from the IPCC Agent Desktop. prior to making any outbound calls on the IP Telephony extension. The Cisco IP IVR is one such platform. page 2-1. Call queuing in an IPCC deployment requires use of an IVR platform that supports the SCI interface to the ICM. Because of these software and environmental limitations. when the user lifts the handset. 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. The control over the type of queuing treatment for a call is provided by the ICM via the SCI interface. Other extensions on the IP phone may have multiple lines or appearances and voice mail. 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. that can be used as a queuing point for IPCC deployments. waiting for handling by an initial or subsequent agent When planning your IPCC deployment. Cisco recommends that any IP Telephony extensions be forwarded to voice mail prior to logging into the IPCC. no voice mail. an IVR is used to provide voice announcements and queuing treatment while waiting for an agent. it is important to note that there is no control over. However. It is also important to note that many contact center environments have very stringent maintenance windows. 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. 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. Cisco also offers another IVR platform. When running dual-use Cisco CallManager clusters with both IP Telephony and IPCC extensions.

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

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

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

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

If you begin all agent IDs with the same number and they all have the same length. then the agent requesting the transfer must enter the agent ID into the transfer dialog box. The parsing may be done via a series of "if" nodes in the script editor or via a "route select" node. In the script editor. and the talk time during that call leg is associated with the agent who received that call. After a call has been successfully transferred. Transfer Reporting After a call transfer is completed. the consulted target agent may transfer the consultation call to another target agent. and so on). Agent IDs by themselves are not unique. 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. Cisco IP Contact Center Enterprise Edition SRND 1-20 OL-7279-04 . 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. This can be done on IPCC by having the router do a database lookup. The agent-to-agent node requires the PIM to be specified. 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. 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. Then. For more details. all PIM 2 agent IDs begin with a 2. The two call records are associated with one another via a common call ID assigned by the ICM. available online at Cisco. then you must use an agent ID number plan to determine which PIM contains this agent. you can parse the CED field in the script editor to determine which PIM contains the agent. refer to the IPCC Reporting Guide. This allows complete cradle-to-grave reporting for the call. If your environment has multiple PIMs. the agent-to-agent script editor node allows alternative routing for the call. and then using the agent-to-agent script editor node to route the call to that particular agent. The DNP entry matching the dialed number (agent ID) must have DNP type equal to PBX. then the same configuration as discussed in the previous section would be required. Agent IDs should not match any of the extensions on the Cisco CallManager cluster. Each call leg generates a call detail record in the ICM. it can be transferred again.com. In the event that the target agent is not in a ready state. Agent IDs are associated with a specific PIM and can be reused on other PIMs. placing the agent ID in any of the peripheral variable fields. If multiple PIMs exist. when the transferring agent presses the Transfer Complete button. 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. Combination or Multiple Transfers During a consultative transfer. is considered as talk time for the transferring agent. 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. 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. All call detail records are associated with one another via a common call ID assigned by the ICM. Chapter 1 Architecture Overview Transfers in an IPCC Environment Agent-to-Agent Transfers If the transfer is to a specific agent. 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. the original caller will be connected to the second consulted target agent. The time during the consultation call leg. before the transfer is completed.

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

Before sending the call out the gateway or intercluster trunk. The gatekeeper should be configured to allow enough bandwidth for call center traffic to go through. the caller would receive busy tone and not be routed to its peripheral target (agent or IVR). then Cisco CallManager can perform digit manipulation on the dialed digits and send this call transparently out the PSTN.) Figure 1-6 Area of Concern for Distributed Call Processing Models Cisco CallManager cluster Voice mail M server Gatekeeper IP IP Router/gateway V Areas where bandwidth IP WAN must be provisioned Router/gateway Router/gateway V V IP Cisco CallManager IP Cisco CallManager cluster cluster IP M IP M Voice mail Voice mail 76584 server server If the gatekeeper rejects the call. or CTI Route Point). Therefore. Chapter 1 Architecture Overview Call Admission Control Gatekeeper Controlled Gatekeeper control means that there is an independent entity acting as a gatekeeper. For IPCC. 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. IVR. 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. (See Figure 1-6. The reason this is important is that calls are sent to agents and IVRs via routing clients (CTI Desktop. The gatekeeper-controlled model is used for distributed call processing deployments. 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. Cisco CallManager will ask the gatekeeper if there is enough bandwidth for the call to go through the WAN to another site. which are not able to hang up and redial the call. Cisco IP Contact Center Enterprise Edition SRND 1-22 OL-7279-04 . which stay up if the call then gets transferred to another agent or IVR port at another site within the network.

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

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

Also in this chapter is a section on integration of traditional ACD and IVR systems into an IPCC deployment. 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.cisco. Sizing and redundancy are discussed in later chapters of this IPCC design guide. with considerations on hybrid PBX/ACD deployments. 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. For example. C H A P T E R 2 Deployment Models There are numerous ways that IPCC can be deployed. PBX. available at http://www. 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). Scenarios that best fit a particular deployment model are also noted. refer to the Cisco Network Infrastructure Quality of Service Design guide.com/go/srnd Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-1 . and IVR integration • Sizing • Redundancy This chapter discusses the impact of these factors (except for sizing) on the selection of a design. A combination of these deployment models is also possible. Examples of scenarios where combinations are likely are identified within each section. this chapter also lists considerations and risks that must be evaluated using a cost/benefit analysis. With each deployment model. For more information on the network infrastructure required to support an IPCC solution.

available at http://www. IP Phones. the ICM Central Controller and Peripheral Gateways (PGs) could be split onto separate servers. For information on when to install the ICM Central Controller and PG on separate servers. 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. Figure 2-1 Single-Site Deployment Signaling/CTI PSTN IP Voice TDM Voice CallManager Cluster M V M M ICM M M IVR/ISN AW/HDS IP 126019 Agent Figure 2-1 shows two IP IVRs. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide. Intelligent Contact Management (ICM). Chapter 2 Deployment Models Single Site For more information on deployment models for IPCC and IP Telephony. and a direct connection to the PSTN from the voice gateways. desktops. agents. page 5-1.com/go/srnd Single Site A single-site deployment refers to any scenario where all voice gateways. many variations are possible. 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.cisco. Cisco IP Contact Center Enterprise Edition SRND 2-2 OL-7279-04 . and call processing servers (Cisco CallManager. redundant ICM PROGGERS. Figure 2-1 illustrates this type of deployment. For example. refer to the chapter on Sizing IPCC Components and Servers. an Administrative Workstation (AW) and Historical Data Server (HDS).

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

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

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

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

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

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

there will still be only one logical ICM Central Controller. as with the centralized call processing model. available at http://www. refer to the ICM product documentation available at http://www. 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. sites could be deployed with or without local voice gateways. and signaling delays must be within tolerances listed in the Cisco IP Telephony Solution Reference Network Design (SRND) guide. eliminating the need to terminate the voice bearer traffic at the central site.cisco. For details on remote redundancy. it is important to provision adequate bandwidth to the remote sites.323 or MGCP signaling traffic between the voice gateways and the centralized Cisco CallManager servers will flow over the WAN. Regardless of how many sites are being deployed. side A and B can be deployed side-by-side or geographically separated (remote redundancy). and appropriately designed QoS for the WAN is critical.cisco. An alternative to using the VoIP WAN for routing calls between sites is to use a carrier-based PSTN transfer service. In this model. 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. • H. 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). 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.com/univercd/cc/td/doc/product/icm/ Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-9 . ISN queues and treats calls on the remote gateways.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. and CTI Server. If the ICM Central Controller is deployed with redundancy. Centralized IP IVRs provide efficiency of IP IVR ports when compared with smaller deployments of IP IVRs at each remote site. Proper QoS implementation on the WAN is critical. The label then indicates whether a transfer is intra-site or inter-site. PGs. treatment and queue points. each site has its own Cisco CallManager cluster. 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. However. using Takeback N Transfer (TNT). Therefore. WAN bandwidth must still be provisioned for transfers and conferences that involve agents at other locations. Each site can be configured within the ICM as a separate peripheral. 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.

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

• The communication link from the ICM Central Controller to the PG must be sized properly and provisioned for bandwidth and QoS.) • Gatekeeper-based call admission control could be used to reroute calls between sites over the PSTN when WAN bandwidth is not available. 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). 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. • The ICM Central Controller provides consolidated reporting for all sites. in the event of a lost ICM Central Controller connection. Chapter 2 Deployment Models Multi-Site with Distributed Call Processing • Failure at any one site has no impact on operations at another site. Best Practices • The PG. so no transcoding is required. page 8-1. A second inter-cluster call would be made only if an agent at Site 1 was selected for the transfer. • While two inter-cluster call legs for the same call will not cause unnecessary RTP streams. but that agent needs to transfer the call to another agent whose location is unknown. For example. if a call comes into Site 1 and gets routed to an agent at Site 2. Cisco CallManager cluster. When a call is transferred and subsequent queuing is required. (For details. • If the communication link between the PG and the ICM Central Controller is lost. the call should be queued to an IP IVR at Site 2 to avoid generating another inter-cluster call. refer to the chapter on Bandwidth Provisioning and QoS Considerations. 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. For example. However. Even when a fault-tolerant WAN is implemented. 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. It is best to ensure that adequate WAN bandwidth exists between sites for the maximum amount of calling that can occur. the queuing should be done on an IP IVR at the site where the call is currently being processed. • Latency between ICM Central Controllers and remote PGs cannot exceed 200 ms one way (400 ms round-trip). it is important to identify contingency plans for call treatment and routing when communication is lost between the ICM Central Controller and PG. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-11 . 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. • 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. Treatment and Queuing Initial call queuing is done on an IP IVR co-located with the voice gateways. and IP IVR must be co-located. then all contact center routing for calls at that site is also lost. Therefore.

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

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

Cisco IP Contact Center Enterprise Edition SRND 2-14 OL-7279-04 . 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. sufficient intercluster trunks must be configured. Another alternative is to have the Cisco CallManager cluster at Site 1 make an outbound call back to the PSTN. 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. Figure 2-6 Distributed ICM Option Shown with IP-IVR Dedicated Signaling/CTI Private Link IP Voice TDM Voice ICM ICM AW/HDS AW/HDS A B PG/CTI PG/CTI PG/CTI IVR IVR PG/CTI CallManager Cluster 1 CallManager Cluster 2 M M VoIP WAN M M V V M M M M M M IP IP 126024 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. Chapter 2 Deployment Models Multi-Site with Distributed Call Processing Transfers Transfers within a site function just like a single-site transfer. An alternative to using the VoIP WAN for routing calls between sites is to use a PSTN transfer service. Transfers between Cisco CallManager clusters use either the VoIP WAN or a PSTN service. Distributed ICM Option with Distributed Call Processing Model Figure 2-6 illustrates this deployment model. If the VoIP WAN is used.

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

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

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

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

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

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

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

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

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. possibly exceeding the defined requirements. 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. A bandwidth queue should be used to guarantee availability for this worst case. Definitions and examples follow the table. Note Minimum link size in all cases is 1.5 Mbps (T1). Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-23 . Chapter 2 Deployment Models Clustering Over the WAN The tool is available to Cisco partners and Cisco employees at http://www.000 ∗ 40 = 400.000 kbps (2 Mbps) per 10. Inefficient design (such as "ingress calls to Site 1 are treated in Site 2") will cause additional 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. More specifically.html If the IP IVR or ISN PGs are split across the WAN. For this model.000 ∗ (20 + ((20 ∗ 40) / 40) = 10.cisco.000 BHCA.com/partner/WWChannels/technologies/resources/IPCC_resources.000 BHCA.000 BHCA and 20 ECC variables of average length 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. 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. 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. This requirement assumes proper design and deployment based on the recommendations in this IPCC design guide. 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.

10. • ISN PG This value is the total BHCA for call treatment and queuing coming through an ISN. 10. For example. • 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.9 the PG Variables Variables ∗ Average High-Priority Variable Length) / Queue size. • IP IVR PG This value is the total BHCA for call treatment and queuing. For example. This assumes that each call comes into a route point and is eventually sent to an agent.000 Effective BHCA. one for Router/Logger Private and one for PG Private. 100% treatment is assumed in the calculation.9 Add these three CallManager numbers PG together and IP IVR PG ∗ 60 ∗ 0.000 BHCA ingress calls coming into a route point and being transferred to agents.9 total in the shaded box ISN PG ∗ 120 ∗ 0. Cisco IP Contact Center Enterprise Edition SRND 2-24 OL-7279-04 . with 10% conferences or transfers. would be 14. 10. If separate links are used. whichever technology is used in the implementation.000 effective BHCA. 10. • 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. with all of them receiving treatment and 40% being queued. For example. Chapter 2 Deployment Models Clustering Over the WAN Table 2-1 Worksheet for Calculating Private Bandwidth Multiplication Recommended Multiplication Recommended Component Effective BHCA Factor Link Factor Queue Router + ∗ 30 ∗ 0.000 effective BHCA. use the first row for Router/Logger requirements and the bottom three (out of four) rows added together for PG Private requirements. would be 11.000 effective BHCA.000 BHCA ingress with 10% conferences or transfers would be 11. with all of them receiving treatment and 40% being queued. add all link sizes together and use the Total Link Size at the bottom of Table 2-1. including conferences and transfers. For example.000 BHCA ingress calls.000 BHCA ingress calls.9 below to get IP IVR or ISN ∗ ((Number of ∗ 0. 40) Total Link Size Total PG High-Priority Queue Size If one dedicated link is used between sites for private communication. would be 14. 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.8 Total Logger Router+Logger High-Priority Queue Size Cisco ∗ 100 ∗ 0.

000 Total PG High-Priority Queue Size For the combined dedicated link in this example.000 Add these three CallManager numbers PG together and IP IVR PG 14. • There is one Cisco CallManager PG pair for a total of 900 agents.000 the PG Variables Variables ∗ Average High-Priority Variable Length) / Queue size. with high-priority bandwidth queue of 297. • All calls are sent to agents unless abandoned.888.000 ∗ 0.000 ∗ 0.000.000 bps Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-25 . 10% of calls to agents are transfers or conferences.100.550.9 756.8 297.000 ∗ 60 840. Table 2-2 Example Calculation for a Combined Dedicated Private Link Multiplication Recommended Multiplication Recommended Component Effective BHCA Factor Link Factor Queue Router + 11.9 252. with one PG pair supporting them.000 ∗ 100 1.888.000 ∗ ((Number of 280.5 Mb.000 1.888.000 bps • PG link of 2.000 bps. • There are four IP IVRs used to treat and queue the calls.000 bps If this example were implemented with two separate links. 40) Total Link Size 2.000 ∗ 0.000 ∗ 0.000 ∗ 30 330.220.000 total in the shaded box ISN PG 0 ∗ 120 0 ∗ 0. as defined earlier).000 bps (actual minimum link is 1.9 880. • 100% of calls are treated by IP IVR and 40% are queued. 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: • BHCA coming into the contact center is 10.000 bps • PG high-priority bandwidth queue of 1.000 Total Logger Router+Logger High-Priority Queue Size Cisco 11. • Calls have ten 40-byte Call Variables and ten 40-byte ECC variables.9 0 below to get IP IVR or ISN 14. the link sizes and queues would be as follows: • Router/Logger link of 330. with high-priority bandwidth queue of 1.550.000 bps • Router/Logger high-priority bandwidth queue of 297. the results are as follows: • Total Link = 2. Router/Logger private and PG private.

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

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

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

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

service providers are not providing QoS. Chapter 2 Deployment Models Remote Agent Over Broadband Remote Agent with IP Phone Deployed via the Business Ready Teleworker Solution In this model. 512 MB RAM or greater. • The Cisco 7200 VXR and Catalyst 6500 IPSec VPN Services Module (VPNSM) offer the best LAN-to-LAN performance for agents. (See Figure 2-12. including CTI data and high-quality voice Best Practices • Minimum broadband speed supported is 256 kbps upload and 1.711 on minimum broadband speeds. Currently. • Enable security features on the Cisco 831 Series router. • Minimum broadband speed supported is 256 kbps upload and 1. • QoS is enabled only at the Cisco 831 Router edge. • 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.4 Mbps download for ADSL.0 Mbps download for cable. • Agent workstation must have 500 MHz. Cisco IP Contact Center Enterprise Edition SRND 2-30 OL-7279-04 .) Figure 2-12 Remote Agent with IP Phone Deployed via the Business Ready Teleworker Solution IPCC Cisco IP Corporate phone Network VPN IP Broadband Head-End modem Broadband Internet router CTI Encrypted VPN tunnel data 126030 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. Customer calls routed to the remote agent are handled in the same manner as campus agents. • IP phone must be configured to use G. • The remote agent's home phone must be used for 911 calls. the remote agent’s IP phone and workstation are connected via the VPN tunnel to the main IPCC campus.

Cisco CallManager (Skinny Client Control Protocol connection for placing and transferring calls). • 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. 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. and CTI OS on a single server). – The Import process is responsible for importing customer records and Do Not Call records into the system. The Dialer is a pure software solution that does not require telephony cards. • A Media Routing PIM is required for each Dialer to reserve agents for outbound use. and the Media Routing PG (to reserve agents). Sizing Information • Maximum of 200 agents (any mixture of inbound and outbound agents) on a fully coresident configuration (Outbound Option Dialer. – The Dialer processes. the Campaign Manager (for configuration and customer records). Description and Characteristics • The IP Dialer uses virtual IP phones to place outbound calls through a voice gateway via the Cisco CallManager. Figure 2-13 illustrates the model for the IPCC Outbound Option with more than 200 agents. IPCC PG. 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). • 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. CTI Server.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. The Cisco Outbound Option enables the multi-functional contact center to take advantage of the ICM enterprise management. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 2-31 .

with IP Dialers placed at multiple call center sites. including answering machine detection.0 and later provide the Enhanced Call Progress Analysis feature. ICM IPCC IP Data TFTP SUB Dialer 1 Agent WAN PC M M M IPCC 126032 CCMC. CRS1 CRS2 Agent ICM BACKUP 24 Ports 24 Ports PC Dialer 2 SUB 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. Cisco IP Contact Center Enterprise Edition SRND 2-32 OL-7279-04 . • This option provides true call-by-call blending of inbound and outbound calls.0 and later. • This option provides integrated webview reporting with outbound specific reporting templates. • This option provides centralized management and configuration via the ICM Admin workstation. the main benefits of the IPCC Outbound Option are: • IPCC Outbound Option has enterprise-wide dialing capability. In summary. • Transfer to IVR mode (agent-less campaigns) and Direct Preview mode are available in IPCC Release 6. The Campaign Manager server is located at the central site. • 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. Chapter 2 Deployment Models IPCC Outbound (Blended Agent) Option Figure 2-13 IPCC Outbound Option with More Than 200 Agents ICM Peripheral ICM Peripheral Gateway 5A Gateway 5B Media Routing Media Routing Blended Agent PIM (1) Blended Agent PIM (1) Private LAN Cross-over Cable ICM Peripheral ICM Peripheral Gateway 2A Gateway 2B PSTN CallManager PIM (1) CallManager PIM (1) ICM CTIOS ICM CTIOS Voice Network CTI Server CTI Server Server 2A Server 2B Private LAN Cross-over Cable Ethernet Converged Visible LAN Cisco router/ Voice Gateway V IP IP M M Cisco 7960 Cisco 7940 CCMA-PUB/ CCMB. • IPCC Release 6.

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 Deployment Models
Traditional ACD Integration

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

ICM Central
NIC Controller

PSTN

PG/CTI
ACD server

PG/CTI
IP IVR server

V

M
CallManager

IP IP IP
IP voice
TDM voice
CTI/Call
76612

control data

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 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

ICM Central
IVR PG Controller
PBX

PSTN

PG/CTI
IP IVR server

V

M
CallManager

IP IP IP
IP voice
TDM voice
CTI/Call
76613

control data

IP phones and IPCC agent desktops

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

Chapter 2 Deployment Models
Traditional IVR Integration

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

ICM Central
IVR PG Controller

PSTN

PG/CTI
IP IVR server

V

M
CallManager

IP IP IP
IP voice
TDM voice
CTI/Call

76614
control data

IP phones and IPCC agent desktops

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

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

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

page 3-13 • Multi-Channel Design Considerations (Cisco Email Manager Option and Cisco Collaboration Server Option). page 3-39 • Other Considerations. system administration. page 3-31 • CTI OS Considerations. This chapter contains the following sections: • Designing for High Availability. page 3-19 • Peripheral Gateway Design Considerations. page 3-11 • Internet Service Node (ISN) Design Considerations. 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. The success of any IPCC deployment requires a team with experience in data and voice internetworking. page 3-7 • IP IVR (CRS) Design Considerations. page 3-39 Designing for High Availability Cisco IPCC is a distributed solution that uses numerous hardware and software components. but not all failures can be made transparent. page 3-38 • Cisco Agent Desktop Considerations. A good IPCC design will be tolerant of most failures (defined later in this section). page 3-15 • Cisco Email Manager Option. 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-17 • Cisco Collaboration Server Option. page 3-1 • Data Network Design Considerations. page 3-5 • Cisco CallManager and CTI Manager Design Considerations. page 3-18 • Cisco IPCC Outbound Option Design Considerations. page 3-20 • Understanding Failure Recovery. including the network infrastructure. and IPCC application configuration. Cisco IPCC is a sophisticated solution designed for mission-critical call centers. 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 IP Contact Center Enterprise Edition SRND OL-7279-04 3-1 .

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

as illustrated in Figure 3-2. any IPCC site can lose half of its systems and still be operational.com/go/srnd If designed correctly for high availability and load balancing.Chapter 3 Design Considerations for High Availability Designing for High Availability IDF switch or to an IP IVR (CRS) queue. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-3 . 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. no matter what happens in the IPCC site. available at http://www.cisco. 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. With this type of design.

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

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

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

(Refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide for further details about the architecture of the CTI Manager.1. The JTAPI client library in Cisco CallManager Release 3. The calls are cleared by whichever timeout expires first.) The main function of the Cisco CallManager service is to register and monitor all the IP telephony devices. 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. the CTI Manager does not directly communicate with the other CTI Managers in its cluster. while the CTI Manager service acts as a router for all the CTI application requests for the system devices. 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.3(x) and later uses CTI Manager. In addition. It acts like a JTAPI messaging router. 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. Figure 3-4 illustrates some of the functions of Cisco CallManager and the CTI Manager. It basically acts as a switch for all the IP telephony resources and devices in the system.) The CTI Manager and Cisco CallManager are two separate services running on a Cisco CallManager server. When the voice gateway interface to the switch recovers. and CTI route points.Chapter 3 Design Considerations for High Availability Cisco CallManager and CTI Manager Design Considerations also set a default timeout in Cisco CallManager. and Real-time Information Server (RIS) data collector services. 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. which is explained later in this section). CTI ports. as in releases prior to 3.1 and above connects to the CTI Manager instead of connecting directly to the Cisco CallManager service. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-7 . (This is also explained later in detail. The CTI Manager uses the Cisco JTAPI link to communicate with the applications. Cisco CallManager and CTI Manager Design Considerations Cisco CallManager Release 3. Cisco Messaging Interface. Some of the devices that can be controlled by JTAPI that register with the Cisco CallManager service include the IP phones. However. Some other services running on a Cisco CallManager server include TFTP. 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).

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

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

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

Load balancing is highly recommended to ensure that all IP IVRs are used in the most efficient way. you can implement redundancy by adding the IP addresses or host names of two Cisco CallManagers from the cluster. Chapter 3 Design Considerations for High Availability IP IVR (CRS) Design Considerations Figure 3-7 Assigning CTI Managers for PG Sides A and B 126812 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. Then. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-11 . Figure 3-8 shows two IP IVR (CRS) servers configured for redundancy within one Cisco CallManager cluster. Cisco CallManager PIM 1 PG side B. if one of the Cisco CallManagers fails. Cisco CallManager PIM 1 IP IVR (CRS) Design Considerations The JTAPI subsystem in IP IVR (CRS) can establish connections with two CTI Managers. 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. the IP IVR associated with that particular Cisco CallManager will fail-over to the second Cisco CallManager. Using the redundancy feature of the JTAPI subsystem in the IP IVR server.

• ICM script features to check the availability of an IP IVR prior to sending a call to it. Cisco IP Contact Center Enterprise Edition SRND 3-12 OL-7279-04 . see IP IVR (CRS) High Availability Using ICM. page 3-13. Note Do not confuse the IP IVR (CRS) subsystems with services. This method is more complicated. CTI data. IP messaging IP IVR 1 IP IVR 2 TDM voice lines Ethernet lines 76606 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. 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. For more information on this method. page 3-13. IP IVR uses only one service. the Cisco Application Engine service. The IP IVR subsystems are connections to external applications such as the CTI Manager and ICM. see IP IVR (CRS) High Availability Using Cisco CallManager. For more information on this method. Chapter 3 Design Considerations for High Availability IP IVR (CRS) Design Considerations Figure 3-8 High Availability with Two IP IVR Servers and One Cisco CallManager Cluster T1 lines Public Voice Voice network T1 lines gateway 1 gateway 2 Gatekeepers V V IDF IDF MDF switch 1 switch 2 switch 1 MDF switch 2 TDM access Firewall Cisco CallManager cluster Publisher Corporate LAN Sub 1 M Sub 2 M M Call control.

avoid creating a loop in the event that all the IP IVR servers are unavailable. do not establish a path back to the first CTI port that initiated the call forwarding. 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. and it is easily scalable to virtually any number of IP IVRs. ISN uses H. (See Figure 3-9.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. 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. ISN is different from IP IVR in that it does not rely on Cisco CallManager for JTAPI call control. Note When using the call forwarding features to implement high availability of IP IVR ports. • 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. such as running out of available CTI ports. 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. or the IP IVR PG fails. 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).) Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-13 . 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. 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. Note All calls at the IP IVR are dropped if the IP IVR server. 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. This method can be modified to load-balance ports across multiple IP IVRs. Basically. IP IVR (CRS) High Availability Using ICM You can implement IP IVR (CRS) high availability through ICM scripts. IVR-to-CallManager JTAPI link. For example. • Forward on Failure — forwards calls to another port or route point when Cisco CallManager detects a port failure caused by an application error.

when new calls come into the system. With ISN. 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. • 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. Chapter 3 Design Considerations for High Availability Internet Service Node (ISN) Design Considerations Figure 3-9 High Availability with Two ISN Servers T1 lines Public Voice Voice network T1 lines gateway 1 gateway 2 Gatekeepers V V IDF IDF MDF switch 1 switch 2 switch 1 MDF switch 2 TDM access Firewall Combination ISN Voice Browser and ISN Application Server Corporate ISN1 ISN2 LAN Call control. CTI data. the gatekeeper can associate the dialed number with a particular set of voice browsers that can handle the call. Cisco IP Contact Center Enterprise Edition SRND 3-14 OL-7279-04 . IP messaging ISN PG ISN PG TDM voice lines Side A Side B Ethernet lines 126813 ISN PG Pair 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 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. 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. Instructions from the ICM Peripheral Gateway are translated by the Application Server to VXML code and sent to the voice browsers for processing. The voice browsers register with the application servers as well as gatekeepers so that.

For more information on these options. a single ISN with multiple voice browsers) • Adding gatekeeper redundancy with HSRP • Adding Cisco Content Server to load-balance . • 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. Availability of the ISN can be increased by: • Adding additional redundant ISN systems under control of the ICM Peripheral gateways. thus allowing multiple Media Servers to be pooled behind a single URL for access by all the voice browsers in the network. The Configuration Application Programming Interface (ConAPI) runs on an Admin Workstation and can be configured with a backup service running on another Admin Workstation. • H. the Cisco e-Mail Manager and Cisco Collaboration Server Media Blender communicate with the Media Routing Peripheral Gateway.323 Gatekeepers Gatekeepers are used with ISN to register the voice browsers and associate them with specific dialed numbers. The following optional components are integrated into the IPCC architecture (see Figure 3-10): • Media Routing Peripheral Gateway To route multi-channel contacts.wav files stored on media servers. The Media Servers act as web servers and serve up the .cisco. Typically. thus allowing the ICM to balance the calls across the platforms • Adding additional ISN components to an ISN system (for example. 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. the gateway will query the gatekeeper to find out where to send the call based upon the dialed number. with email and web contacts being routed by the IPCC to agents in a blended or "universal queue" mode. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-15 . The Media Routing Peripheral Gateway. like any peripheral gateway. When calls come into the network. can be deployed in a redundant or duplex manner with two servers interconnected for high availability.wav files to the voice browsers as part of their VXML processing. Media Servers can be clustered using the Cisco Content Services Switch (CSS) products. review the ISN product documentation at: http://www. the Media Routing Peripheral Gateway is co-located at the Central Controller and has an IP-socket connection to the multi-channel systems.com/univercd/cc/td/doc/product/icm/isn/isn21/index.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.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 .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 . These connections provide agent information to the email and web environments as well as accepting and processing task requests from them. Figure 3-10 Multi-Channel System ConAPI Logger AW ConAPI Router Database Database TES Workstation CTI Desktop Phone MR-PG IPCC Agent-PG TES OPC CTI Server OPC CTI Server IP PIM3 PIM2 IPCC/EA Agents MR-PIM MR-PIM PIM MR MR ARM ARM PC Phone M CEM CEM CCS Database Cisco CallManager 126033 Customers/Callers ConAPI ConAPI Recommendations for high availability: • Deploy the Media Routing Peripheral Gateways in duplex pairs. The connection is a TCP/IP socket that connects to the agent's associated CTI Server. Chapter 3 Design Considerations for High Availability Multi-Channel Design Considerations (Cisco Email Manager Option and Cisco Collaboration Server Option) • 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. which can be deployed as a redundant or duplex pair on the Agent Peripheral Gateway. Also consider using the HDS servers at the central sites to host this function.

• 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 Administrative Agent Browsers Browsers SpellServer UIServer RServer CEM Server Machine TServer Inbasket CEM DB CCL DB Database Server 126034 Machine Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-17 . it is not redundant. It can be co-resident on the Cisco Email Manager server for smaller deployments or on a dedicated server for larger systems. • Cisco Email Manager Database Server — The server that maintains the online database of all emails and configuration and routing rules in the system. 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). The major components of Cisco Email Manager are: • Cisco Email Manager Server — The core routing and control server. 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.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.

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. It can be co-resident on the Cisco Collaboration Server. • Cisco Collaboration Dynamic Content Adaptor (DCA) — This server is deployed in the DMZ with the collaboration server. 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. • Cisco Collaboration Server Media Blender — This server polls the collaboration servers to check for new requests. Cisco IP Contact Center Enterprise Edition SRND 3-18 OL-7279-04 . Multiple Cisco Collaboration Servers can point to the same database server to reduce the total number of servers required for the solution. Each IPCC Agent Peripheral Gateway will have its own Media Blender. and it allows the system to share content that is generated dynamically by programs on the web site (as opposed to static HTTP pages). most enterprises deploy it on a separate server inside the firewall to protect the historical data in the database. You can deploy multiple collaboration servers for larger systems. Chapter 3 Design Considerations for High Availability Cisco Collaboration Server Option Figure 3-12 Multiple UI Servers Agent Browsers Administrative Agent Browsers Browsers UIServer SpellServer RServer UIServer Machine UIServer TServer Inbasket UIServer Machine CEM Server Machine CEM DB CCL DB Database Server 126035 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. and each Media Blender will have a Media Routing peripheral interface manager (PIM) component on the Media Routing Peripheral Gateway. however. • 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 it detects the caller and manages the interaction tasks with the CTI OS server to transfer the call to an agent. It also interfaces with the Media Routing Peripheral Gateway. L 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. Chapter 3 Design Considerations for High Availability Cisco IPCC Outbound Option Design Considerations Figure 3-13 Cisco Collaboration Server Internet DMZ DCA Caller CallManager Workstation CTI Agent PG requests for Desktop Phone ARM a Call Back CTI or for Web CTI SVR DCA Connection IP Collaboration with Chat Media Routing Agents (SSC. 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. CCS ARM (MR) PG or Web MRI MRI Collaboration CMB MR PIM with a Phone ICM BAPI Call (BC) Queue ICM Distributor AW ICM Administration F CMS_jserver I F Connection (aka R I Conapi Connection) E R E HTTP Agent Connection W A W 126036 L A Note: Arrow indicates the direction in L L which the connection is initiated. • Outbound Option Dialer — A software module that performs the dialing tasks on behalf of the Campaign Manager. MSC). and each Dialer has its own peripheral interface manager (PIM) on the Media Routing Peripheral Gateway. In IPCC. This software is loaded on the Logger platform and is not redundant. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-19 .

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

dedicated LAN. 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. 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.) Figure 3-15 ICM High Availability with One Cisco CallManager Cluster T1 lines Public Voice Voice network T1 lines gateway 1 gateway 2 Gatekeepers V V MDF MDF switch 1 switch 2 Firewall TDM IDF IDF access switch 1 switch 2 Cisco CallManager cluster Corporate Publisher LAN Sub 1 M Sub 2 IP IVR 1 IP IVR M group M IP IVR 2 CM CM PG A PG B Call control. There is no need for a PG to connect to multiple Cisco CallManager servers in a cluster. If the servers are located at the same site. CTI data. 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. If that CTI Manager were to fail. (See Figure 3-15. you can provide the private LAN by inserting a second NIC card Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-21 . Therefore. 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. the CTI Manager forwards that request via Cisco CallManager SDL links to the other Cisco CallManager servers in the cluster. ICM A ICM B IP messaging TDM voice lines 76607 Ethernet lines ICM central controllers Redundant ICM servers can be located at the same physical site or geographically distributed. the ICM Call Router and Logger/Database Server processes are interconnected through a private. the minimum configuration for a Cisco CallManager cluster in this case is one publisher and one subscriber. 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 PG would no long be able to communicate with the Cisco CallManager cluster. If the servers are geographically distributed.

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

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

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

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

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

• PG side B registers all dialed numbers and phones with Cisco CallManager D.Chapter 3 Design Considerations for High Availability Peripheral Gateway Design Considerations is already logged into the secondary (now primary) CTI Manager. Figure 3-20 Only CTI Manager Fails CallManager CallManager PG A PG B CallManager C CallManager D M M CallManager A M M CallManager B IP ICM synchronzation messages CallManager intra-cluster messages JTAPI messages H323 or MGCP messages 79928 SCCP messages Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-27 . PG side B continues to be active and uses the CTI Manager on Cisco CallManager D. • After an agent disconnects from all calls. • When Cisco CallManager C fails. that agent's desktop functionality is restored to the same state prior to failover. • All phones and gateways are configured to re-home to Cisco CallManager B (that is. PG side A detects a failure of the CTI Manager on that server and induces a failover to PG side B. • 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. B is the backup). • When Cisco CallManager C recovers. and call processing continues. 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.

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

however. In order to meet the requirements of Cisco CallManager clustering over the WAN. This link is critical to the IPCC design because it is part of the fault-tolerant design of the system. any calls that were set up over this WAN link will fail with the link. • 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. and so forth) are located. Scenario 2 . Because the visible network is down. This does not cause a failover of the Peripheral Gateway or the Call Router. This network is used to carry all the voice traffic (RTP stream and call control signalling). The Peripheral Gateways will automatically realign their data communications to the local Call Router. the Call Routers will be in simplex mode until the private network link is restored. If the visible network fails between the data center locations. Likewise. 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. or calls in queue. the following conditions apply: • The Cisco CallManager subscribers will detect the failure and continue to function locally. The system can continue to function normally. The Peripheral Gateway will no longer be able to see this phone. the remote Cisco CallManager subscriber at side B cannot send the phone registration event to the remote Peripheral Gateway. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-29 . However. 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. as well as all typical data network traffic between the sites. calls in progress. the system would be running in simplex on both the Call Router and the Peripheral Gateway. the system could lose some or all of the call routing and ACD functionality. IP-IVR/ISN components. and the phone will remain operational on the isolated side B. 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. this link must be highly available with very low latency and sufficient bandwidth. Peripheral Gateways. The visible network failure will not force the IP Phone to re-home to side A of the cluster. • The ICM Call Routers will detect the failure because the normal flow of TCP keep-alives from the remote Peripheral Gateways will stop. and it must be highly resilient as well. Chapter 3 Design Considerations for High Availability Peripheral Gateway Design Considerations • There is no impact to the agents. however. and the agent will be logged out of IPCC automatically because the system can no longer direct calls to the agent’s phone. If a second failure were to occur at that point. the Peripheral Gateways will detect this failure by the loss of TCP keep-alives from the remote Call Routers. ICM CTI (call control signalling) traffic. 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. with no impact to local call processing and call control. – 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. IPCC will log out this agent because it can no longer control the phone for the agent.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.

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

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 CallManager reporting shows the call as terminated when the Cisco CallManager failure occurred because. any calls in progress are terminated and the agents are logged out so that future calls are not routed to them. Scenario 4 . If side A of the WAN at the remote agent location fails. At this point. 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. 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. 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. While the IP phones are in SRST mode. all the devices registered to it are reported out of service by the CTI Manager service. they will not be able to function as IPCC agents. the Call Router and Cisco CallManager Peripheral Gateway will run in simplex mode. from a Cisco CallManager reporting perspective. • 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. Understanding Failure Recovery This section analyzes the failover recovery of each individual part (products and subcomponents inside each product) of the IPCC solution. and the system will accept new calls from only the surviving side for IPCC call treatment. The IP-IVR/ISN functionality will also be limited to the surviving side as well. and so on) are not possible. but further call control functions (hold. Only agents that were active on the surviving side of the Peripheral Gateway with phones registered locally to that site will not be impacted. 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). IP phones of agents not on calls at the time of failure will quickly register with the backup Cisco CallManager. If MGCP gateways are used. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-31 . • 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.) If both sides of the WAN at the remote agent location fail. Each agent location requires WAN connectivity to both of the data center locations where the Cisco CallManager and ICM components are located. (Agent desktop will be disabled during the realignment process. then the calls in progress survive. 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.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. retrieve. transfer. When an active Cisco CallManager service fails. conference. Cisco CallManager Service In larger deployments.

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

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

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

the system will not automatically resynchronize the databases. Manual resynchronization allows the system administrator to decide when to perform this data transfer on the private network. and these keys will be used to restore data to the failed Logger over the private network. These servers do not support redundant or duplex operation. 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. 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. The Loggers maintain a recovery key that tracks the date and time of each entry recorded in the database. if the Outbound Option is used. 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. the HDS data that is replicated from that Logger would stop until the Logger can be restored. If that platform is out of service. WebView and Internet Script Editor. There is no impact to call processing during a Logger failure. It also hosts the web-based reporting tool. Chapter 3 Design Considerations for High Availability Understanding Failure Recovery redundant Logger while it was off-line. resynchronization has to be done manually using the ICMDBA application. as the other ICM system components do. Additionally. However. you can deploy multiple Administrative Workstation servers to provide redundancy for the IPCC. In this case.) Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-35 . any outbound calling will stop until the Logger can be restored to operational status. the Campaign Manager software is loaded on only one of the Logger platforms (must be Logger A). (See Figure 3-22.

and the other real-time distributors within that Admin Site register with the primary real-time distributor for the real-time feed. 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. CTI data. 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. they will register with the Cisco IP Contact Center Enterprise Edition SRND 3-36 OL-7279-04 . IP messaging ICM B TDM voice lines Ethernet lines 126159 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. If the primary real-time distributor is down or does not accept the registration from the secondary real-time distributors. this is important because it can reduce the required bandwidth to support remote Admin Workstations across a WAN connection. For remote sites. When using an Admin Site. Chapter 3 Design Considerations for High Availability Understanding Failure Recovery Figure 3-22 Redundant ICM Distributors and AW Servers T1 lines Public Voice Voice network T1 lines gateway 1 gateway 2 Gatekeepers V V MDF MDF switch 1 switch 2 Firewall TDM IDF IDF access switch 1 switch 2 Cisco CallManager cluster Corporate Publisher LAN Sub 1 M Sub 2 IP IVR 1 IP IVR M group M IP IVR 2 CM VRU VRU CM PG A PG B PG A PG B IPCC_Site1 AW AW A B ICM A Call control. The Admin Site reduces the number of real-time feed clients the ICM Call Router has to service at a particular site. the primary real-time distributor is the one that will register with the ICM Call Router for the real-time feed.

Alternatively. Upon failure of the CTI Server. any configuration changes made to the ICM. 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. the redundant CTI server becomes active and begins processing call events. however. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-37 . The buttons will be restored as soon as the redundant CTI Server is restored. This will create more overhead for the ICM Call Router to maintain multiple real-time feed clients. and the agent does not have to log on again to the desktop application. (See Figure 3-23. it will prevent a failure of the primary real-time distributor from taking down the secondary distributors at the site.) It does not. none of the agents for that Agent Peripheral Gateway will be able to log into these applications. Additionally. maintain agent state in the event of a failure. each real-time distributor could be deployed in its own Admin Site regardless of the physical site of the device. 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. 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. 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. 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. however. 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 Email Manager. or Cisco Content Server systems will not be passed over the ConAPI interface until it is restored. Chapter 3 Design Considerations for High Availability Understanding Failure Recovery ICM Call Router for the real-time feed. 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. CTI Server is redundant on duplex CTI Servers or can be co-resident on the PG servers. If the CTI Server is down on both sides of the duplex agent Peripheral Gateway pair.

and it can be deployed as redundant CTI OS Servers. IP messaging TDM voice lines 126160 Ethernet lines 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. then the active CTI OS fails-over to its peer server. it is important to keep both of these services active at all times. CTI data. The CTI Object Server (CTI OS) consists of two services. 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. Cisco IP Contact Center Enterprise Edition SRND 3-38 OL-7279-04 . If either of these two fails. and agents sitting next to each other may in fact be registered to two different CTI OS Servers. the CTI OS service and the CTI driver. Chapter 3 Design Considerations for High Availability CTI OS Considerations Figure 3-23 Redundant CTI Servers with No Cisco Agent Desktop Server Installed T1 lines Public Voice Voice network T1 lines gateway 1 gateway 2 Gatekeepers V V MDF MDF switch 1 switch 2 Firewall TDM IDF IDF access switch 1 switch 2 Cisco CallManager cluster Corporate Publisher LAN Sub 1 M Sub 2 IP IVR 1 IP IVR M group M IP IVR 2 CTI CTI CM CM server server PG A PG B VRU VRU A B PG A PG B AW A AW B ICM A ICM B Call control. Therefore.

some data could be lost during its failover.com/univercd/cc/td/doc/product/icm/icmentpr/icm50doc/icm5rept/index. Therefore. This section examines what happens to other critical areas in the IPCC solution during and after failover. Other Considerations An IPCC failover can affect other parts of the solution.htm Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 3-39 . When agents log out.cisco. at the end of each five-minute and half-hour interval. refer to the Cisco IP Contact Center Reporting Guide. which provides for automatic failover and redundancy for the Cisco Agent Desktop Server. 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. ICM failover does not force the agents to log out. Reporting The IPCC reporting feature uses real-time. each Peripheral Gateway will gather the data it has kept locally and send it to the Call Routers. but their agent desktop functionality is restored back to its pre-failover state. Typically. For further information. The next time the agents log in. RASCAL. available at http://www. five-minute and half-hour intervals to build its reporting database.Chapter 3 Design Considerations for High Availability Cisco Agent Desktop Considerations Cisco Agent Desktop Considerations Cisco Agent Desktop is a client of CTI OS. their real-time statistics start from zero. Although IPCC may stay up and running. If the deployment has the Historical Data Server (HDS) option. The Cisco Agent Desktop Servers (Enterprise Server. 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. 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. 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. and so forth) can also be deployed redundantly to allow for failover of the core Cisco Agent Desktop components. all their reporting statistics stop. Chat. 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. that data is then replicated to the HDS server from the Logger as it is written to the Logger database. it does reset their agent statistics when the ICM failover is complete. however. The Call Routers process the data and send it to their local Logger and Database Servers for historical data storage. or other products that depend on IPCC to function properly might not be able to handle an IPCC failover. However. If the Cisco CallManager Peripheral Gateway or CTI Server (CG) fail-over.

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

) In addition to the terms listed in this section. 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.com/glossary. There is one busiest hour in the year. the number of IP IVR ports required for various call scenarios (such as call treatment. 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. Common practice is to design for the average Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-1 . refer to the definitions at http://www. and to be consistent in the use of.html (There are also other resources available on the internet for defining call center terms. The busy interval occurs when the most traffic is offered during this period of the day. 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). Improper use of these terms in the tools used to size call center resources can lead to inaccurate sizing results. 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. IPC Resource Calculator. The busy hour or interval varies over days. There are weekly busy hours and seasonal busy hours.com Busy Hour or Busy Interval A busy interval could be one hour or less.thecallcenterschool. Call Center Basic Traffic Terminology It is important to be familiar with. defines the specific terms used for the input and output of the Cisco call center sizing tool. the section on the Cisco IPC Resource Calculator. such as 30 minutes or 15 minutes. queuing. 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. Also. These tools and methodologies are intended as building blocks for sizing call center resources and for any telephony applications in general. and self-service applications). common call center terminology. For additional call center industry terminology. and months. if sizing is desired for such smaller intervals. page 4-6.cisco. for more details on various call center terms and concepts discussed in this document. The terms listed in this section are the most common terms used in the industry for sizing call center resources. weeks. refer to the IPCC product documentation available online at http://www.

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

Cisco's IPCC solution uses an IP IVR to place callers in queue and play announcements. A 1% blockage is a typical value to use for PSTN trunks. the call is lost or blocked. averaging 2 minutes each. the average time calls will spend in queue. IVR ports. where x is a variable. or if they hear a tone (such as a busy tone) or announcement. and the number of PSTN trunks and IP IVR ports needed. 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 . For an additional definition of service level within IPCC products. The percentage of calls queued and the average time spent in the queue are determined by the service level desired and by agent staffing. but different applications might require different grades of service. PBX lines. the percentage of calls that will be queued. 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. This blockage typically applies to resources such as voice gateway ports. then the busy hour traffic load is (600 * 2/60) = 20 Erlangs. a grade of service of 0. In the case of a voice gateway. such as 80% of all calls answered within 30 seconds in the busy hour. and so forth). 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. 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. if the call center receives 600 calls in the busy hour.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. All resources might be occupied when a user places a call. Service Level This term is a standard in the contact center industry.com Queuing When all agents are busy with other callers or are unavailable (after call wrap-up mode). airline arrival/departure times. Blocked Calls A blocked call is a call that is not serviced immediately. refer to the IPCC glossary available online at http://www. For example.cisco. A support-oriented call center might have a different service level goal.01 means that 1% of calls in the busy hour would be blocked. BHT is typically used in Erlang-B models to calculate resources such as PSTN trunks or self-service IVR ports. Grade of Service (Percent Blockage) This measurement is the probability that a resource or server is busy during the busy hour. or BHT = (BHCA ∗ AHT minutes) / 60 For example. delayed and put in a queue. 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). Your contact center’s service level goal drives the number of agents needed. An IVR can also be used to handle all calls initially (call treatment. grade of service is the percentage of calls that are blocked or that receive busy tone (no trunks available) out of the total BHCA. and trunks. Some calculators perform this calculation transparently using the BHCA and AHT for ease of use and convenience. In that case. The nature of the blocked call will determine the model used for sizing the particular resources.

For purposes of this document. there are mainly two traffic models that are commonly used in sizing call center resources. Figure 4-1 shows the main resources used and the occupancy (hold/handle time) for each of these resources. page 4-11. and Trunks. smooth. The number of trunks or gateway ports needed for each of these applications will also differ accordingly. 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 . held. and it should be added to the trunk average handle time. IVR Ports. 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. Figure 4-1 Inbound Call Timeline IVR Agent Agent Agent Ring Answers Answers Hangs-up Ready Network Treatment/Queue Delay Agent Talk Time Wrap-up Time Time Trunk is Occupied Time IVR is Occupied 126044 Time Agent is Occupied Ring delay time (network ring) should be included if calls are not answered immediately. This delay could be a few seconds on average.) 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. Erlang-B and Erlang-C. for examples on how to calculate the number of trunks and gateway ports needed. Erlang Calculators as Design Tools Many traffic models are available for sizing telephony systems and resources. delayed) • Call arrival patterns (random. There are many other resources on the internet that give detailed explanations of the various models (search using "traffic engineering"). Choosing the right model depends on three main factors: • Traffic source characteristics (finite or infinite) • How lost calls are handled (cleared. (See the section on Sizing Call Center Agents. Chapter 4 Sizing Call Center Resources Call Center Resources and the Call Timeline possibly a different call load. peaked).

and the average queue time for these calls. Cisco has chosen to develop its own telephony sizing tool. Cisco does not endorse any particular vendor product. The first version discussed here is designed to size call center resources. or IP IVR ports. new calls will be queued and not blocked. new calls are lost or blocked (receive busy tone) and not queued. Basic examples are included later in this chapter to show how to use the Cisco IPC Resource Calculator. 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 the methodology used. Before discussing the Cisco IPC Resource Calculator. Erlang-B and Erlang-C. but not all. There are various web sites that provide call center sizing tools free of charge (some offer feature-rich versions for purchase). The input required for any of the tools. 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. Chapter 4 Sizing Call Center Resources Erlang Calculators as Design Tools Before you can answer these basic questions. are the same regardless of the tool itself. 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. and they list which model to use for sizing the specific call center resource (agents. This model assumes: • Call arrival is random. • If all agents are busy. It assumes the following: • Call arrival is random. 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. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-5 . • If all trunks/ports are occupied. of the input fields are known or available. called Cisco IPC Resource Calculator. the percentage of calls delayed or queued when no agents are available. 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. or percent blockage. Additional examples are also included to show how to use the tool when some. and IP IVR ports). Erlang-C The Erlang-C model is used to size agents in call centers that queue calls before presenting them to agents. it is up to the customer to choose which tool suits their needs. gateway ports. Erlang-B The Erlang-B model is used to size PSTN trunks. but they all use the two basic traffic models.

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

or busy hour call attempts (BHCA). It helps to distinguish the different scenarios run (exported and saved) for a project or a customer proposal. 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. It can also be used to calculate staffing requirements for any interval of the day (non-busy hour staffing). or 15 minutes. if desired. This choice of interval length allows the flexibility to calculate staffing requirements more accurately for the busiest periods within one hour. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-7 . You can choose the interval to be 60 minutes (busy hour). Calls Per Interval (BHCA) The number of calls attempted during the busiest interval. 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.

Average After-Call Work Time The average agent wrap-up time in seconds after the caller hangs up. Chapter 4 Sizing Call Center Resources Cisco IPC Resource Calculator Service Level Goal (SLG) The percentage of calls to be answered within a specified number of seconds (for example. Average Call Talk Time The average number of seconds a caller will be on-line after an agent answers the call. Blockage % (PSTN Trunks) This field is also known as Grade of Service. or IVR menuing) to route the call to an agent. 90% within 30 seconds). It does not include time spent in the IVR for call treatment or time in queue. 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. The error will appear any time the number of calls queued reaches 0% or 100%. after checking this box. Check to Manually Enter Agents The user may manually enter the number of agents. This value has no effect on any of the output fields except the abandon rate (number of calls abandoned). 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. This time includes greetings and announcements as well as time to collect and enter digits (known as prompt and collect. This value includes time talking and time placed on hold by the agent. then this additional time should be included (averaged for all calls) in the after-call work time. (This queuing time is calculated in the output section of the calculator. Self-service IVR applications should be sized separately using an Erlang-B calculator. the calculator will show an error message. 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 entry assumes that agents are available to answer calls when they are not in wrap-up mode. It does not include queuing time if no agents are available. If seated agents enter into another mode (other than the wrap-up mode) where they are unavailable to answer calls. or the percentage of calls that will receive busy tone (no trunks available on the gateway) during the busy hour or interval. For example. If the number of agents is too far from the recommended number. Cisco IP Contact Center Enterprise Edition SRND 4-8 OL-7279-04 .) The call treatment time should not include calls arriving at the IVR for self-service with no intention to route them to agents. 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). until the call is terminated.

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

Submit After entering data in all required input fields. therefore smaller groups are less efficient. queuing in the IVR (if no agents are available). 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). based on the number of calls answered by the voice gateway and the average hold time of a trunk during the busy interval. Chapter 4 Sizing Call Center Resources Cisco IPC Resource Calculator Calls Exceeding Abandon Tolerance The percentage (and number) of calls that will abandon their attempt during the interval. This calculated number assumes all trunks are grouped in one large group to handle the specified busy hour (or interval) calls. This format makes comparing results of multiple scenarios easy to analyze. If this output is zero. 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. 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 value includes average time of call treatment in the IVR. If several smaller trunk groups are used instead. Cisco IP Contact Center Enterprise Edition SRND 4-10 OL-7279-04 . with the ability to overflow to other groups if available. 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 value is based on an Erlang-B calculation using the number of queued calls and the average queue time for those calls. 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. click on the Submit button to compute the output values. Cisco recommends that you configure the number of ports required for queuing in a separate group. 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. 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. This value is based on an Erlang-B calculation using the number of calls answered and the average call treatment time (average IVR delay). PSTN Trunk Utilization This value is the occupancy rate of the PSTN trunks. then additional trunks would be required. and agent talk time. IVR Ports Required for Call Treatment The number of IVR ports required for calls being treated in the IVR. 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. However. based on expected Tolerance time specified in the input.

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

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

Using a 15-second call treatment and keeping all other inputs the same. calls are queued until an agent becomes available. 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.7% queued). and service level) has not changed. If no agents are available. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-13 . talk time. all incoming calls to the call center are presented to the voice gateway from the PSTN. • The traffic load presented by the calls that queue (31. This load shows that 10 IVR ports are required for queuing. with an average agent talk time for all calls of 150 seconds. if available. Again. More IP IVR ports are also required to carry this extra load. Call treatment (prompt and collect) does not impact the number of required agents because the traffic load presented to the agents (number of calls. Call Treatment Example This example builds upon the basic example in the preceding section. 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. 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. 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. with an average queue time of 20 seconds when no agent is available to answer the call immediately. 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. That scenario is discussed in the next example. 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. 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. Total trunks required to carry this total traffic load above is 103 trunks. The impact of presenting all calls to the IP IVR is that the PSTN trunks are held longer. IVR Ports. for the period of the call treatment holding time. Chapter 4 Sizing Call Center Resources Sizing Call Center Agents.

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

and so forth. Examples include accessing bank account balances and transactions. 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. At the end of the transaction. and no additional agents are required. 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. the caller hangs up and does not need to speak to an agent. The calls are serviced in the IVR and not answered by agents. 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. a standalone Erlang-B calculation is necessary to compute the additional PSTN trunks and IVR ports required. only PSTN trunks (voice gateway ports) and IVR ports are required. For such self-service applications. airline flight arrival and departure information. as shown in the following example. menu services such as driving directions. 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 . 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. as described in previous examples and illustrated in the following example. This slight increase is not due to the wrap-up time. In this case.

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

• Average talk time = 6 minutes (360 seconds).) High-Priority Calls (Transferred to Agents Directly. • SGL = 95% of the calls to be answered within 10 seconds. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 4-17 . 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. • No call treatment ports are required here. • 6 IVR ports are needed for queuing. as is the case with Cisco ISN. • Routed immediately to agents if available.Chapter 4 Sizing Call Center Resources Call Center Sizing With Self-Service IVR Applications Inserting these values into the first column. 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).000 ∗ 20% = 3600 calls. Figure 4-6 IVR Self-Service Calls Note There are many Erlang-B calculators available for free on the Web. no IVR call treatment. no IVR Call Treatment) • 18. • 386 trunks are required. (Search on Erlang-B. titled Self Service. in the calculator produces the following results.

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

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. and IVR ports): • Agents for high-priority calls (calls answered by agents. page 4-20. PSTN trunks. You can access the Configuration and Ordering Tool at http://www. refer to the section on Sizing ISN Components.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. 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. then you must enter the number of call treatment and queuing ports into the Configuration and Ordering Tool for proper sizing of server resources.cisco. we can add the results to determine the total required resources of each type (agents.

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.cisco. On the other hand.com). 60%. are self-serviced in the IVR without ever being transferred to an agent. 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). then ISN no longer has any control over that call. if the ISN uses the IP Transfer method to route a call to an agent. so that call does not count as an effective call. page 4-23 • Cisco IOS Gateway Sizing. The remaining portion. then the ISN is still monitoring that call and it counts as an effective call. These calls last an average of about 60 seconds before they complete their transaction and hang up. Chapter 4 Sizing Call Center Resources Sizing ISN Components 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). page 4-24 • Prompt Media Server Sizing. 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. however. unless those calls are unable to find an agent and are subsequently treated by the ISN. Note This section uses the same example as in the preceding Call Center Example with IVR Self-Service Application. number dialed. page 4-16. 20%. 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.000 ∗ 20% = 3600 calls. In the latter case. page 4-20 • Sizing ISN Licenses. but it reiterates the parameters of that example for clarity and simplicity. 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).000 calls. Also assume that another portion of the incoming 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. page 4-24 ISN Server Sizing According to the Cisco Internet Service Node Technical Reference (available at http://www. Average IVR call treatment = 60 seconds. Note. The traffic loads (call types) coming into this call center are as follows: • IVR self-service calls: 18. Cisco IP Contact Center Enterprise Edition SRND 4-20 OL-7279-04 . 20%. Assume a portion of the calls. for example. if an Outpulse or IN Transfer is used to route a call to an agent. will be identified as high-priority callers (based on calling number. In addition. calls that are transferred to agents directly without ISN (Voice Browser) control or involvement do not count as effective calls either. page 4-24 • ICM Peripheral Gateway (PG) Sizing.

no IVR call treatment. • Normal calls: 18. or it is a call that the ISN has transferred to an agent but that the ISN still needs to monitor. SLG = 90% of the callers to be answered within 30 seconds. 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 . For this example. the agents are all IPCC agents. 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. Therefore. In our example. If agent is not available. Average talk time = 5 minutes (300 seconds). SLG = 95% of the callers to be answered within 10 seconds. which means that the ISN continues to monitor those calls. Average IVR time for call treatment = 171 seconds.Chapter 4 Sizing Call Center Resources Sizing ISN Components • High-priority calls (transferred to agents directly): 18. high-priority and normal calls. Remember that an effective call is a call undergoing IVR call treatment or queuing treatment by the ISN. call must be queued by ISN. 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. when the ISN routes calls to the agents. Average talk time = 6 minutes (360 seconds). page 4-1. In the latter two call types. Calls routed immediately to agents if available. we can total the results to determine the number of effective calls needed to size the ISN properly.000 ∗ 20% = 3600 calls. a call might have to wait in queue in the IVR (ISN) if no agents are available to answer the call. the ISN uses the IP Transfer routing method. 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.000 ∗ 60% = 10800 calls.

where the IVR queuing treatment is physically performed on Cisco IOS gateways (using the ISN Comprehensive deployment model). 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.323 GED125 PSTN V PG 689 calls getting ISN sees an ICM “effective” load 132075 IVR/queuing on an IOS gateway of 689 + 921 = under ISN 1610 calls Cisco IP Contact Center Enterprise Edition SRND 4-22 OL-7279-04 . the Cisco IOS gatekeeper and Cisco CallManager are not shown.) Figure 4-9 ISN Server Sizing Example 921 calls transferred to agents by ISN Other calls routed to agents without ISN involvement IP ISN VXML/H. therefore: 907 + 14 = 921 simultaneous calls Thus. (For simplicity. the combined IVR and queuing load on the ISN is 689 simultaneous calls. giving us a final total of: 7 ISN Combo Boxes Figure 4-9 illustrates the preceding ISN sizing example. so for our example we will need: 1610/300 = 6 ISN Combo Boxes An additional ISN Combo Box is normally recommended for redundancy. Chapter 4 Sizing Call Center Resources Sizing ISN Components • PSTN trunks (with VXML) = 75 + 1469 = 1544 • PSTN trunks (no VXML) = 386 • PSTN trunks (total) = 75 + 1469 + 386 = 1930 Thus. which in this case is: (7 ∗ 2) = 14 extra calls The number of transferred calls to agents monitored by ISN in this example is. 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. 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).

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

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

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

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

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

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

• For more than 2.000 agents. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 5-3 . see Figure 5-3 and Figure 5-4.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 500 1.000 2. and CTI OS. refer to Table 5-1. • Voice Response Unit (VRU) and Cisco CallManager components are not shown. CTI Server.000 PGR RGR RGR Router Routing Database HDS HDS HDS Logger Reporting HDS APG APG APG Peripheral APG APG Gateways Agent Services APG APG 132068 The following notes apply to Figure 5-1: • Sizing is based upon the Cisco MCS 7845 (3. • 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.

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

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

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

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

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

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

In the reverse. 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. it also translates ICM messages so that they can be sent to and understood by the peripheral devices. Chapter 5 Sizing IPCC Components and Servers Peripheral Gateway and Server Options IP IVR Self-Service Applications In deployments where the IP IVR is also used for self-service applications. Therefore. and customer-facing operations. the IP IVR. Peripheral Gateway and Server Options An ICM Peripheral Gateway (PG) translates messages coming from the Cisco CallManager servers. revenue-generating. There are many ways that ECC can be configured and used. Table 5-2 lists PG and PIM sizing recommendations Figure 5-3 Agent PG Configuration Options with CTI OS Agent PG Agent PG Agent PG Agent PG Agent PG (All-in-one) (with Generic) (with CCM) (with Outbound) (with Blender) CCM PG (CCM PIM) Generic PG CCM PG (CCM PIM) Generic PG Generic PG (CCM PIM and VRU PIM) (CCM PIM and VRU PIM) (CCM PIM and VRU PIM) VRM PG (VRU PIM) CTI SVR CTI SVR CTI SVR CTI SVR CTI SVR CTI OS CTI OS CTI OS CTI OS CTI OS MR PG MR PG Dialer Blender 132070 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. 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. Figure 5-3 and Figure 5-4 illustrate various configuration options for the Agent PG with CTI OS and Cisco Agent Desktop. Contact centers are often mission-critical. but they can also be complex. Router. Extended Call Context (ECC) The ECC usage impacts PG. The capacity impact will vary based on ECC configuration and should be handled on a case-by-case basis. The Peripheral Interface Manager (PIM) is the software process that runs on the PG and performs the message translation and control. Logger. and network bandwidth. 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. Every peripheral device that is part of the IPCC solution must be connected to a PG and PIM. Cisco IPCC solutions are very flexible and customizable.

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

Server capacities for the Cisco Agent Desktop CTI Option vary based on the total number of agents. and the number of simultaneous recordings. These percentages apply to the CTI OS Server agent capacity and not to the entire Contact Center capacity. see Agent Desktop and Supervisor Desktop. Cisco Agent Desktop Component Sizing For details on the components and architecture of the Cisco Agent Desktop. platform resource usage increase significantly due to the increase in work load required to query and update agents and skill groups. Chapter 5 Sizing IPCC Components and Servers Cisco Agent Desktop Component Sizing Table 5-3 CTI OS Sizing Factors Sizing Factor MSC-7845 MSC-7835 Comments Maximum number of agents plus supervisors 500 250 Maximum number of supervisors 50 25 10% of supported agents1 Maximum number of teams 50 25 10% of supported agents1 Maximum BHCA per agent 30 30 Supervisors do not receive new calls. In this case. This section presents sizing guidelines for the following installable Cisco Agent Desktop Server components: • Cisco Agent Desktop Base Services. For example. page 5-13 • Cisco Agent Desktop VoIP Monitor Service. 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. the CTI OS capacity decreases as the number of skill groups per agent increases. Maximum number of agents plus supervisors 100 50 20% of supported agents1 per team Maximum number of supervisors per team 10 5 2% of supported agents1 Maximum number of agents per supervisor 100 50 20% of supported agents1 Skill groups per agent 5 5 Extended Call Context (ECC) None None 1. The numbers in Table 5-3 are based on the following assumptions: • Hyper-threaded is enabled for the MCS server. whether or not Switched Port Analyzer (SPAN) monitoring and recording is used. • The traffic profile is: – 85% of calls answered by agents – 10% of calls transferred – 5% of calls conferenced For more than 500 CTI agents. page 5-13 Cisco IP Contact Center Enterprise Edition SRND 5-12 OL-7279-04 . page 7-1. additional Agent PG instances are off-loaded (500 agents each) to additional 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. When Remote Switched Port Analyzer (RSPAN) monitoring and recording are required for more than 400 agents. Recording and Statistics Service. there are application servers that may be placed on the same or separate computers as the Base Servers. 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 VoIP Monitor Service may be co-located on the Agent PG for up to 100 agents. Table 5-4 Maximum Number of Agents Supported by a Logical Call Center (LCC) Desktop Agents IP Phone Agents Enterprise Size Only Only Mixed Small 100 50 33 of each Medium 300 150 100 of each Large (multiple PG and CTI Servers) 500 250 333 of each Maximum LCC capacity with 1000 500 333 of each multiple PG and CTI Servers Cisco Agent Desktop VoIP Monitor Service The VoIP Monitor Service enables the silent monitoring and recording features. The capacity of the Recording and Playback Service is not dependent on the codec that is used. Each dedicated VoIP Monitor Service can support up to 400 agents. They include Chat Service. and Sync Service. Licensing and Resource Manager Service. IP Phone Agent Service. When using Switched Port Analyzer (SPAN) monitoring. Table 5-4 lists the maximum number of agents that a single LCC can support for various sizes of enterprises. A co-resident Recording and Playback Service can support up to 32 simultaneous recordings. Directory Services. the VoIP Monitor Service must be deployed on a dedicated server (an MCS-7835 server or equivalent). For Desktop Monitoring. Table 5-5 summarizes the raw Recording and Playback Service capacity. the VoIP Monitor Service has no impact on design guidance for Agent PG scalability. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 5-13 . LDAP Monitor Service. A set of Cisco Agent Desktop Base Services plus the additional application servers correspond to a logical call center (LCC). Enterprise Service. These additional applications include the VoIP Monitor Service and the Recording and Playback Service. A dedicated Recording and Playback Service (which is available in the Premium offering) can support up to 80 simultaneous recordings. In addition.

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

facilitate redundancy. multi-channel. scalability refers to Cisco CallManager server and/or cluster capacity when used in the IPCC Enterprise environment. Cisco CallManager clusters provide a mechanism for distributing call processing across a converged IP network infrastructure to support IP telephony. ISN. Within the context of this document. However. and so forth). and you should become familiar with them before continuing with this chapter. provisioning. Some duplication is necessary to clearly concepts relating to IPCC as an application supported by the Cisco CallManager call processing architecture.cisco. and configuration of Cisco CallManager clusters when used in an IPCC Enterprise environment. which will have an impact on the Cisco CallManager cluster scalability: • Determine customer call center application requirements (IP IVR.com/go/srnd The information in this chapter builds upon the concepts presented in the Cisco IP Telephony SRND. you should perform the following steps. available at http://www. the foundational concepts are not duplicated here. This chapter covers only the IPCC Enterprise operation of clusters within both single and multiple campus environments and proposes reference designs for implementation. 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 . outbound. C H A P T E R 6 Sizing Cisco CallManager Servers For IPCC This chapter discusses the concepts. Before reading this chapter. and provide feature transparency and scalability. CTI ports. This chapter documents general best practices and scalability considerations for sizing the Cisco CallManager servers used with your IPCC Enterprise deployments. Call Processing With IPCC Enterprise Before applying the guidelines presented in this chapter. • Determine the types of call center resources and devices used in IPCC Enterprise (route points. 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.

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

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

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

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

Chapter 6 Sizing Cisco CallManager Servers For IPCC
Cisco CallManager Capacity Tool

Table 6-1 Sample Input for Cisco CallManager Capacity Tool (continued)

Average Busy Hour Average Busy Hour
Device or Port Call Rate (BHCA) Traffic Utilization
Route patterns
Translation patterns
IPCC Input
IPCC agents 30 0.8
ISN (prompt and collect or queueing)
ISN (self-service)
CTI ports or IP IVR (prompt and collect or queueing) 30 0.8
CTI ports or IP IVR (self-service) 30 0.8
CTI route points
H323 gateways
H323 gateway DS0s (T1 CAS, T1 PRI, E1 PRI, Analog) 20 0.8
MGCP gateways
MGCP gateway DS0s (T1 CAS, T1 PRI, E1 PRI, Analog) 20 0.8
% Agent-to-agent transfer 10%
% Agent conference 10%
IPCC Outbound
IPCC outbound predictive/preview agents 30 0.8
IPCC outbound direct preview agents 30 0.8
IPCC outbound dialer ports 60 0.8
IPCC outbound IVR ports 20 0.8
H.323 gateways
H.323 gateway DS0s (T1 CAS, T1 PRI, E1 PRI, analog) 20 0.8
MGCP gateways
MGCP gateway DS0s (T1 CAS, T1 PRI, E1 PRI, analog) 20 0.8

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 Characteristics IPCC Enterprise Recommendation1
Standard server: • Single processor Up to a maximum of 100 agents
MCS-7825H (Not recommended for mission-critical
• Single power supply (not hot-swap)
call centers above 50 agents)
• Non-RAID hard disk (not hot-swap)
High-availability standard server: • Single processor Up to a maximum of 250 agents
MCS-7835H with BBWC (Maximum of 125 agents without
• Redundant power supplies (hot-swap)
BBWC installed)
• Redundant SCSI RAID hard disk array
(hot-swap)
High-performance server: • Dual processors Recommended for all mission-critical
MCS-7845H with BBWC contact centers up to a maximum of
• Redundant power supplies (hot-swap)
500 agents
• Redundant SCSI RAID hard disk arrays (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 Maximum IPCC High-Availability High-Performance
Server Characteristics1 Agents per Server 2 Platform 3 Server
4
• Cisco MCS-7845H-3000 (Dual Prestonia Xeon 3.06 GHz 500 Yes Yes
or higher) 4 GB RAM
• HP DL380-G3 3.06 GHz 2-CPU 3
5
• Cisco MCS-7845H-2400 (Dual Prestonia Xeon 500 Yes Yes
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 250 Yes Yes
2400 MHz) 4 GB RAM (Without BBWC)
• HP DL380-G3 2400 MHz 2-CPU
• Cisco MCS-7835H-3000 (Prestonia Xeon 3.06 GHz) 250 Yes No 5
2 GB RAM (With the addition of battery-backed write
cache, BBWC, installed separately)
• HP DL380-G3 3.06 GHz 1-CPU

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

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

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 Maximum IPCC High-Availability High-Performance
Server Characteristics1 Agents per Server 2 Platform 3 Server
• Cisco MCS-7835H-3000 (Prestonia Xeon 3.06 GHz) 125 Yes No
2 GB RAM (Without BBWC)
• HP DL380-G3 3.06 GHz 1-CPU
• Cisco MCS-7825H-3000 (Pentium 4, 3.06 GHz) 100 No No
2 GB RAM
• HP DL320-G2 3.06 GHz 6
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 Upgrade the publisher server.
Step 2 Upgrade dedicated TFTP and music on hold (MoH) servers.
Step 3 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.
Step 4 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.
Step 5 Upgrade the primaries, and then re-enable the Cisco CallManager service.

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

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

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

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

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. To provide for failover conditions when only one server is active. • Special Cisco CallManager configurations and services such as: – MOH – Tracing levels Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 6-13 . To allow for failure of the primary or the backup.).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. As the call rate increases. With load balancing. In this way. make sure that all capacity limits are observed so that IPCC agent phones. MCS-7845H-3000 servers have a total server limit of 500 IPCC agents. To plan for 50/50 load balancing. and so on. (See the configuration for 500 agents in Figure 6-2. such as: – CTI ports – Gateway ports – Agent phones – Route points – CTI Manager • The load (BHCA) processed by these devices. Normally (as in the 2:1 redundancy scheme) a backup server has no devices registered unless its primary is unavailable.cisco. For additional information on general call processing topics such as secondary TFTP servers and gatekeeper considerations. • Average call duration — Longer average call duration means a lower busy-hour call completion rate. configuring each subscriber with 250 agents. IP phones. CTI limits. which lowers CPU usage. In a 1:1 redundancy pair. available at http://www. 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.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. you can split the load between the two subscribers. for the redundant pair do not exceed the limits allowed for a single server. For example. the total load on the primary and secondary subscribers should not exceed that of a single subscriber. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide. more CPU resources are consumed on the Cisco CallManager server. you can reduce by 50% the impact of any server becoming unavailable.

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. • 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.) CPU consumption due to Default traces will vary based on load. Please consult with your Cisco Systems Engineer for proper sizing of your system requirements. • Similarly.) – IVR self-service – Call treatment – Routing to agents – Transfers and conferences CPU consumption varies by type of call flow. Cisco CallManager is involved only when calls are transferred to agents (simple call handling). simple call flow configurations. 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. instead. but this is not a recommended configuration and is not supported by Cisco Technical Assistance Center. and so forth. • Trace level enabled Cisco CallManager CPU resource consumption varies. Cisco IP Contact Center Enterprise Edition SRND 6-14 OL-7279-04 . for more information). the CPU consumption is moderate. This difference is due to the fact that ISN does not require calls to be routed to Cisco CallManager before call treatment. This balancing of resources will prevent overloading one server to benefit the others. page 6-1. Changing the trace level from Default to Full on Cisco CallManager can increase CPU consumption significantly under high loads.323 gateway). depending on the trace level enabled. The trade-off is that ISN gateways have increased performance demands. applications installed. Cisco CallManager release. • ISN configurations. Chapter 6 Sizing Cisco CallManager Servers For IPCC Impact of IPCC Application on Cisco CallManager Performance and Scalability • 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. and a lower call arrival rate (BHCA) might be able to support more than 2. (See Sizing ISN Components. • 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. but CPU consumption for complex call flows is much higher. For simple call flows. (Changing the tracing level from Default to No tracing can decrease CPU consumption significantly at high loads. call flow complexity.323 gateway).000 agents per Cisco CallManager cluster.323 gateway protocol uses more CPU resources than MGCP does.

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

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. then typically to either the ICM Central Controller or the Cisco CallManager. The Cisco CallManager then performs the requested call or device control. • 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. Chapter 7 Agent Desktop and Supervisor Desktop Types of IPCC Agent Desktops Figure 7-1 Agent Desktop Communication with CTI OS Server ICM central controller IPCC Agent desktops PG server PG 1 IP phones PG Agent IP CTI OS server IP IP CallManager Cluster IP CTI server M JTAPI CCM PIM M IP IVR 1 JTAPI M OPC SCI JTAPI IVR 1 PIM IP IVR 2 PSTN V SCI IVR 2 PIM IP voice TDM Voice 132072 CTI/Call control data For each Cisco CallManager PG (and Cisco CallManager cluster). 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. Types of IPCC Agent Desktops There are three types of IPCC agent and supervisor desktops available: • Cisco Agent Desktop — A packaged agent desktop solution. The CTI OS Server interfaces with the CTI OS desktop and toolkit as well as Cisco Agent Desktop (Release 6. release. Call control (answer. All communications from the CTI OS Server are passed to the CTI Server. there is one CTI OS Server. 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. There may be one or more CTI OS Servers connecting to the CTI Server. Cisco IP Contact Center Enterprise Edition SRND 7-2 OL-7279-04 . hold. It is the role of the Cisco CallManager PG to keep the IPCC agent desktop and the IP Phone in sync with one another.0 and later). make call. retrieve.

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

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

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

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

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

http://www.0 applications in a Citrix thin-client environment. Chapter 7 Agent Desktop and Supervisor Desktop Additional Information about Cisco 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. web) displayed on the supervisor's desktop • Siebel Support — IPCC Enterprise Adapter certified for use with Siebel 7.com/application/pdf/en/us/guest/products/ps14/c1667/ccmigration_09186a0 080225251. CTI OS Server.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.0 and 6.1 This document provides information about the abilities and requirements of voice over IP (VoIP) monitoring for Cisco Agent Desktop (CAD) Releases 6. service connection types and port numbers. error messages.cisco. and troubleshooting. available at http://www. event/error logs.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.cisco.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.0/6.pdf Cisco IP Contact Center Enterprise Edition SRND 7-8 OL-7279-04 .53 For more information.html • Voice-Over IP Monitoring Best Practices Deployment Guide for CAD 6. and Siebel 7.com/univercd/cc/td/doc/product/icm/icmentpr/icm60doc/icm6cti/ctios60/index.cisco. CTI OS Client.com/application/pdf/en/us/guest/products/ps427/c1225/ccmigration_09186a 008038a48d. Siebel 6.com/en/US/products/sw/custcosw/ps427/prod_technical_reference_list. http://www. http://www. http://www.com/application/pdf/en/us/partner/products/ps427/c1244/cdccont_0900aecd 800e9db4. This information is intended to help you deploy VoIP monitoring effectively.cisco.1.cisco.05 and 7. registry entries. Data Collaboration Server (DCS). configuration files.com/en/US/products/sw/custcosw/ps14/prod_technical_reference_list. refer to the Cisco CTI Object Server product documentation. http://www.cisco.pdf • Cisco Agent Desktop Service Information This document provides release-specific information such as product limitations.

http://www.com/application/pdf/en/us/guest/products/ps14/c1667/ccmigration_09186a0 080228190. introduces programmers to developing CTI-enabled applications with CTI OS. and describes the syntax and usage for CTI OS methods and events.pdf Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 7-9 .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).cisco.

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

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

or services) and other media termination resources (such as IP IVR ports) as well as the real-time updates of peripheral resource status. and IP phones. available at http://www.323. and a prioritization scheme favoring specific UDP and TCP application traffic. MGCP. such as screen pops and other priority data. according to the endpoints involved in the call. and on the CTI flows between the desktop application and CTI OS and/or Cisco Agent Desktop servers. In an IP Telephony environment. or TAPI/JTAPI). or redirect calls. voice and video provisioning is not addressed here. such as events involved in reporting and configuration updates. email.cisco. 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). web activity. For information on proper network design for data traffic. • Call control traffic Call control consists of packets belonging to one of several protocols (H. The flows discussed encapsulate the latter two of the above three traffic groups. 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. on the network path between sides A and B of a PG or of the Central Controller. where applicable. and CTI database application traffic sent to the agent desktops. maintain. and this type of traffic is not addressed in this chapter. IPCC priority data includes data associated with non-real-time system states. low latency. IP IVR Q-points (ports). provision QoS for these network segments. and other non-IPCC mission critical traffic will vary according to the specific integration and deployment model used. SCCP. Expeditious delivery of PG data to the Central Controller is necessary for accurate call center state updates and fully accurate real-time reporting data. For IPCC. control traffic includes routing and service control messages required to route voice calls to peripheral targets (such as agents. trunk information. 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. 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. tear down.cisco. skill groups. A properly designed IPCC network is characterized by proper bandwidth. and so forth) across the system. refer to the Network Infrastructure and Quality of Service (QoS) documentation available at http://www. Chapter 8 Bandwidth Provisioning and QoS Considerations IPCC Network Architecture Overview IPCC Network Architecture Overview IPCC is a distributed.com/go/srnd Cisco IP Contact Center Enterprise Edition SRND 8-2 OL-7279-04 . call statistics. resilient. • Data traffic Data traffic can include normal traffic such as email. Because media (voice and video) streams are maintained primarily between Cisco CallManager and its endpoints.com/go/srnd Data traffic consisting of various HTTP. Guidelines and examples are presented to help estimate required bandwidth and. Call control functions include those used to set up. 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. refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide.

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. the signaling access network. Note The terms public network and visible network are used interchangeably throughout this document. This traffic consists primarily of synchronized data and control messages. The private link must provide sufficient bandwidth to handle simultaneous synchronizer and state transfer traffic. 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 public network can also serve as a Central Controller alternate path. and it must meet aggressive latency requirements. The public network carries traffic between each side of the synchronized system and foreign systems. 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 PG 2A PG 2B 126999 Public Network 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. the private link is critical to the overall responsiveness of the Cisco ICM. for UDP heartbeats. and it must have enough bandwidth left over for the case when additional data will be transferred as part of a recovery operation. most communication between them is also over the private network. 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. • When deployed over a WAN. The public network is never used to carry synchronization control traffic. may be deployed in ICM systems that also interface directly with the carrier network (PSTN) and that deploy the Hosted ICM/IPCC architecture. When a router process and its logger process are deployed on separate nodes. IP routers in the private network typically use priority queuing (based on the ICM private high/non-high IP addresses and. and it also conveys the state transfer necessary to re-synchronize duplexed sides when recovering from an isolated state. A third network. The public network is also used as an alternate network by the fault-tolerance software to distinguish between node failures and network failures. The signaling access network is not addressed in this chapter. 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. • The public network carries traffic between the Central Controller and call centers (PGs and AWs). used to determine which side of the Central Controller should retain control in the event that the two sides become isolated from one another.

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

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. little correspondence to the TCP connections. For ICM public connections. A QoS-enabled network applies prioritized processing (queuing. • In a converged network. as was the case with the UDP heartbeat prior to Release 5. and policing) to packets based on QoS markings as opposed to IP addresses. In a slow network flow. However. thereby delaying delivery of high-priority packets to the receiving end. ICM Release 6. in the case of UDP heartbeats. Microsoft Windows 2000 allows you to specify keep-alive parameters on per-connection basis. 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. algorithms used by routers to handle network congestion conditions have different effects on TCP and UDP. and low.0.) 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. thereby allowing a high-priority packet to get on the wire sooner. A secondary effect often seen is application buffer pool exhaustion on the sending side. 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 a result. traffic prioritization is needed because it is possible for large amounts of low-priority traffic to get in front of high-priority traffic. IP-Based Prioritization and QoS Simply stated. due to extreme latency conditions. the keep-alive timeout is set to 5∗400 ms. This delay would cause the apparent loss of one or more heartbeats. ICM applications use three priorities – high. delays and congestion experienced by UDP heartbeat traffic can have. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 8-5 . The reasons of moving to TCP keep-alive are as follows: • The use of UDP heartbeats creates deployment complexities in a firewall environment. a smaller Maximum Transmission Unit (MTU) size is used by the application for low-priority traffic. meaning that a failure can be detected after 2 seconds. To avoid this situation. in some cases. the amount of time a single large (for example. (MTU size for a circuit is calculated from within the application as a function of the circuit bandwidth. by specific UDP port range in the network.1p (using the Microsoft Windows Packet Scheduler) for public network traffic. scheduling.0 provides marking capability of both Layer-3 DSCP and Layer-2 802. 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. prior to QoS. The dynamic port allocation for heartbeat communications makes it necessary to open a large range of port numbers. thus defeating the original purpose of the firewall device. medium. as configured at PG setup. 1500-byte) packet consumes on the network (and delays subsequent packets) can exceed 100 ms.

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

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

Chapter 8 Bandwidth Provisioning and QoS Considerations
Network Provisioning

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

DSCP / 802.1p
Latency DSCP / 802.1p Using Bypassing Packet
Priority IP address & port Requirement Packet Scheduler Scheduler
High High-priority public IP address 200 ms AF31 / 3 AF31 / 3
and high-priority connection
port
Medium High-priority public IP address 1,000 ms AF31 / 3 AF21 / 2
and medium-priority
connection port
Low Non-high-priority public IP 5 seconds AF11 / 1 AF11 / 1
address and low-priority
connection port

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 Bandwidth Provisioning and QoS Considerations
Network Provisioning

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-all ICM_Visible_High
match ip dscp af31
class-map match-all ICM_Visible_NonHigh
match 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

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

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

1 Bps + (10 skills ∗ 46.220 average bits per second = 93.4 Bps) = 11.4 Bps) Example If there are 25 remote agents with 10 skills per agent. Table 8-3 Bytes of Data Used for Agent State Change To Cisco Agent Desktop From Cisco Agent Desktop Server 1 Skill 5 Skills 1 Skill 5 Skills CTI OS 2043 6883 523 739 Cisco Agent Desktop Base 268 268 638 638 Cisco Agent Desktop Recording 0 0 0 0 Cisco Agent Desktop VoIP 0 0 0 0 Monitor Total 2311 7151 1161 1377 Example If there are 25 remote agents with 5 skills per agent. the total number of bytes sent from the CTI OS server to Cisco Agent Desktop is: 25 ∗ 6883 = 172.1 Bps + (Number of skills ∗ 5.4 Bps) Bandwidth from Cisco Agent Desktop to CTI OS: 1. Chapter 8 Bandwidth Provisioning and QoS Considerations Network Provisioning Table 8-2 Bandwidth Usage for Heartbeats and Skill Statistics (Bytes Per Second) To Cisco Agent Desktop From Cisco Agent Desktop Server 1 Skill 5 Skills 1 Skill 5 Skills CTI OS 49 234 7 28 Cisco Agent Desktop Base 2 2 2 2 Cisco Agent Desktop Recording 0 0 0 0 Cisco Agent Desktop VoIP 0 0 0 0 Monitor Total 51 236 9 30 Bandwidth from CTI OS to Cisco Agent Desktop: 2.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.653 Bps ∗ 8 bits per byte = 93. 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. each of whom changes agent state one time.075 bytes Cisco IP Contact Center Enterprise Edition SRND 8-14 OL-7279-04 .1 Bps + (Number of skills ∗ 46.

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

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

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

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

5 14.0 24.1 68.1 NS NS 2 0.7 30.4 22.4 4.9 6.9 NS NS NS NS 9 0.6 5.3 3.4 28.0 9.3 34.1 26.0 4.1 NS NS NS NS 8 0.6 6.1 84. NS = not supported.1 82.8 55.7 1 1 0.6 NS NS NS NS 6 0.4 60.6 NS NS NS NS NS NS 10 1.2 1.9 NS NS NS 3 0.9 38.1 68.1 63.4 NS NS NS NS 4 0.1 43. NS = not supported. The bandwidth of the connection is not large enough to support the number of simultaneous monitoring sessions.1 92.1 73.3 13.9 NS NS NS NS NS 7 1.1 53.5 NS NS NS NS NS 5 1.7 6.2 NS NS NS NS NS 1.3 2.5 4.2 2.6 42.544 Mbps 640 kbps 256 kbps 128 kbps 64 kbps 56 kbps Call only 0.6 34.3 72.8 40.6 16.1 NS NS NS NS 3 0.1 0.6 36.1 39. The bandwidth of the connection is not large enough to support the number of simultaneous monitoring sessions.2 14.6 NS NS NS NS 10 0.8 95.1 85.6 10.7 NS NS NS NS NS 6 1.1 34.4 NS NS NS NS 7 0.711 Codec and No Silence Suppression Number of Simultaneous Percentage of Available Upload Bandwidth Required Monitoring Sessions 100 Mbps 10 Mbps 1.2 NS NS NS NS NS 8 1.3 NS NS NS NS NS NS 1.8 18.9 NS NS NS NS 5 0.4 NS NS NS NS NS 9 1.4 48.8 7.8 50.7 16.0 14. Table 8-7 Percentage of Available Upload Bandwidth Required for Simultaneous Monitoring Sessions with G.6 61.1 0.3 95.8 18.6 73.544 Mbps 640 kbps 256 kbps 128 kbps 64 kbps 56 kbps 1 Call only 0.1 NS NS 1 0.3 2.0 0.3 NS NS NS 4 0.1 11.9 5.729 Codec and No Silence Suppression Number of Simultaneous Percentage of Available Bandwidth Required Monitoring Sessions 100 Mbps 10 Mbps 1. Chapter 8 Bandwidth Provisioning and QoS Considerations Network Provisioning Table 8-6 Percentage of Available Upload Bandwidth Required for Simultaneous Monitoring Sessions with G. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 8-19 .4 4.2 24.9 12.3 2.5 5.9 NS NS NS NS 2 0.6 13.

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

9 18.000 bytes) / (3600 seconds per hour) = 92 kBps 92 kBps ∗ 8 bits per byte = 733 kbps. there is traffic from Cisco Supervisor Desktop to the Cisco Agent Desktop Base Services. Bandwidth Requirements for Cisco Supervisor Desktop to Cisco Desktop Base Services In addition to the bandwidth requirements discussed in the preceding sections.6 15. Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 8-21 .2 15 0.0 NS 45 2.729 Codec and No Silence Suppression Number of Simultaneous Percentage of Available Upload Bandwidth Required Monitoring Sessions 100 Mbps 10 Mbps 1.2 NS 1. the traffic is: 10 agents ∗ 20 calls per hour = 200 calls per hour 200 calls ∗ 1650 bytes per call = 330.8 28.4 60.3 3.2 12. See Typical Call Scenario. for more details.1 NS 50 3. 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 per hour (4330.5 80.9 9.6 NS1 30 1. page 8-15. as shown in Table 8-10.0 5 0.5 25. Table 8-10 Cisco Supervisor Desktop Bandwidth for a Typical Agent Call Service To Cisco Supervisor Desktop From Cisco Supervisor Desktop CTI OS 0 0 Cisco Agent Desktop Base 1650 550 Cisco Agent Desktop Recording 0 0 Cisco Agent Desktop VoIP 0 0 Monitor Total 1650 550 The same typical call scenario was used to capture bandwidth measurements for both Cisco Agent Desktop and Cisco Supervisor Desktop.1 0.544 Mbps 1 0. If there are 10 agents on the supervisor's team and each agent takes 20 calls an hour.8 NS 40 2.7 NS 35 2. NS = not supported. there is 2 kilobytes (kB) of bandwidth per call sent between Cisco Supervisor Desktop and the Chat service.2 20 1.1 31.2 21.6 4. For each agent on the supervisor's team. The bandwidth of the connection is not large enough to support the number of simultaneous monitoring sessions.6 6.3 25 1.1 20.2 40.1 10 0.

Agent Detail Report This report is refreshed automatically every 30 seconds. Table 8-11 lists the bandwidth usage per report request. Table 8-12 lists the bandwidth usage per report request. Chapter 8 Bandwidth Provisioning and QoS Considerations Network Provisioning There is additional traffic sent if the supervisor is viewing reports or if a silent monitor session is started or stopped. The supervisor can refresh the report manually. Table 8-11 Bandwidth Usage for Agent Detail Report (Average Bytes per Report) Agent Detail Report Service To Cisco Supervisor Desktop From Cisco Supervisor Desktop CTI OS 0 0 Cisco Agent Desktop Base 220 200 Cisco Agent Desktop Recording 0 0 Cisco Agent Desktop VoIP 0 0 Monitor Total 220 200 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). Table 8-12 Bandwidth Usage for Team Agent Statistics Report (Average Bytes per Report) Team Agent Statistics Report Service To Cisco Supervisor Desktop From Cisco Supervisor Desktop CTI OS 0 0 Cisco Agent Desktop Base 250 per agent 200 Cisco Agent Desktop Recording 0 0 Cisco Agent Desktop VoIP 0 0 Monitor Total 250 per agent 200 Cisco IP Contact Center Enterprise Edition SRND 8-22 OL-7279-04 .

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 To Cisco Supervisor Desktop From Cisco Supervisor Desktop
CTI OS 0 0
Cisco Agent Desktop Base 250 per skill 200
Cisco Agent Desktop Recording 0 0
Cisco Agent Desktop VoIP 0 0
Monitor
Total 250 per skill 200

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 Stop Monitoring
To Cisco Supervisor From Cisco Supervisor To Cisco Supervisor From Cisco Supervisor
Service Desktop Desktop Desktop Desktop
CTI OS 0 0 0 0
Cisco Agent Desktop Base 775 450 0 0
Cisco Agent Desktop 0 0 0 0
Recording
Cisco Agent Desktop VoIP 275 500 150 325
Monitor
Total 1050 950 150 325

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

Chapter 8 Bandwidth Provisioning and QoS Considerations
Network Provisioning

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 Location Reason
Cisco Agent Desktop Base Central Traffic to/from centralized IPCC
Services components outweighs the traffic
to/from desktops.
VoIP Monitor Service Remote, near agents Span of agent traffic to service. This is
a requirement, not a recommendation,
for silent monitoring and recording.
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
Cisco Desktop Supervisor With the agents Close to the VoIP Monitor service.

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. Customer experience
2. Agent experience
3. Supervisor experience
4. 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 Bandwidth Provisioning and QoS Considerations
Network Provisioning

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

page 9-8 Introduction to Security Achieving IPCC system security requires an effective security policy that accurately defines access. page 9-3 • Antivirus. 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.0.3 • IP Telephony SRND for Cisco CallManager 4. and Integrated Data (AVVID). which can be found at http://www. connection requirements. They must be located in data centers to which Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 9-1 . so frequent site visits are recommended. 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. Load Balancing. page 9-1 • Security Best Practices. • IP Telephony SRND for Cisco CallManager 3. It includes the following sections: • Introduction to Security. A first approach is to ensure that the servers hosting the Cisco contact center applications are physically secure. 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-2 • Patch Management. Updates and additions are posted periodically.com/go/srnd. and scalable network. secure. Video. page 9-6 • Security Features in Cisco CallManager Release 4. and systems management within your contact center. and SSL Services An adequately secure IPCC configuration requires a multi-layered approach to protecting systems from targeted attacks and the propagation of viruses. page 9-4 • Cisco Security Agent. provide proven best practices to build out a network infrastructure based on the Cisco Architecture for Voice. page 9-5 • Firewalls and IPSec. integrity. reliable. These Solution Reference Network Design (SRND) guides. and system availability. Once you have a good security policy. 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.cisco.0 • Data Center Networking: Securing Server Farms SRND • Data Center Networking: Integrating Security.

The Security Best Practices guide assumes that the reader is an experienced network administrator familiar with securing Windows 2000 Server. proper care should be taken to ensure the network links are secure. html The recommendations contained in the Security Best Practices guide are based in part on hardening guidelines published by Microsoft. as well as with the installation and administration of those systems. 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. It further assumes that the reader is fully familiar with the applications that compose the ICM and IPCC solutions. the Security Best Practices for Cisco Intelligent Contact Management Software. such as those found in the Windows 2000 Security Hardening Guide. 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. 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. 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. Cisco IP Contact Center Enterprise Edition SRND 9-2 OL-7279-04 . if deployed). is available at http://www. Another level of security is the network segmentation of the servers.cisco. In cases where the servers are geographically distributed. The servers may be hardened according to the guidelines provided in the security best-practices guides applicable to your release of the application.com/en/US/partner/products/sw/custcosw/ps1001/prod_technical_reference_list. While desktop-based applications such as the CTI OS. 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. as well as other third-party vendors' hardening recommendations. Cisco Agent Desktop. 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 Security Best Practices guide strives to present the underlying rationale for the deviation. Where exceptions or specific recommendations are made. servers making up the IPCC solution should be placed in the data center behind a secure network. 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. CTI OS. or Cisco Supervisor Desktop tend to be deployed in open corporate VLANs. This document. Chapter 9 Securing IPCC Security Best Practices only authorized personnel have access.

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

(See Cisco Security Agent. the greater the potential performance overhead. IP IVR.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). and patches for Cisco CallManager and associated products is available at http://www.) Configuration Guidelines Antivirus applications have numerous configuration options that allow very granular control of what and how data should be scanned on a server.com within 24 hours as Hotfixes.cisco.com).cisco. Cisco IP Contact Center Enterprise Edition SRND 9-4 OL-7279-04 . Antivirus Applications Supported A number of third-party antivirus applications are supported for the IPCC system. page 9-5.com/univercd/cc/td/doc/product/voice/c_callmg/osbios. Note Deploy only the supported applications for your environment. 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. OS updates. and ISN only). thus keeping all scanning local. The following list highlights some general best practices: • Upgrade to the latest supported version of the third-party antivirus application. Newer versions improve scanning speed over previous versions.cisco. resulting in lower overhead on servers. Refer to the security best-practices guide and your particular antivirus product documentation for more detailed configuration information on an ICM environment. each of these remote machines should have its own antivirus software installed.cgi Automated Patch Management The Cisco IP Telephony Operating System configuration and patch process does not currently allow for an automated patch management process. 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. 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. Chapter 9 Securing IPCC Antivirus A document providing information for tracking Cisco-supported operating system files. For a list of applications and versions supported on your particular release of the IPCC software. scanning across the network and adding to the network load should not be required.cisco. especially when an application such as the Cisco Security Agent is installed on the IPCC systems. configuration is a balance of scanning versus the performance of the server. With any antivirus product. and security files is available at http://www. otherwise a software conflict might arise.com/cgi-bin/Software/Newsbuilder/Builder/VOICE. Where possible. 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. SQL Server. The more you choose to scan. With a multi-tiered antivirus strategy.

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

web browser "manage from anywhere" access makes it easy for administrators to control thousands of agents per MC. This secure Cisco IP Contact Center Enterprise Edition SRND 9-6 OL-7279-04 .cisco. providing software updates.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. Chapter 9 Securing IPCC Firewalls and IPSec • Managed mode — An XML export file specific to the agent and compatible with each voice application in the deployed solution. can be downloaded from the same location and imported into an existing CiscoWorks Management Center for Cisco Security Agents. For more details on the installation of Cisco ICM agents. For an inventory of all the ports used across the contact center suite of applications for the most widely deployed versions of Cisco products. For details. Features include: • Cisco ICM. available at http://www.com/kobayashi/sw-center/sw-voice.html. Its role-based. and Internet Service Node (ISN) Agents. and maintaining communications to the agents. 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. 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. IPCC Enterprise.cisco. available at http://www.com/univercd/cc/td/doc/product/icm/icmentpr/icm60doc/coreicm6/config60/icm e60ci.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. refer to the Release Notes for the Cisco Secure PIX Firewall.shtml • Other agents. part of the CiscoWorks VPN/Security Management Solution (VMS) bundle.cisco.com/en/US/products/sw/secursw/ps2120/prod_release_notes_list. 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. available at http://www. available at http://www.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. refer to the Cisco Contact Center Product Port Utilization Guides available at http://www.com/kobayashi/sw-center/cw2000/voip-planner.cisco. refer to Installing Cisco Security Agent for Cisco Intelligent Contact Management Software.

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04 9-7 . NAT Traversal is a feature that is auto-detected by VPN devices. There are also considerations that must be taken into account for QoS networks. The common recommendation is to classify and apply QoS features based on packet header information before traffic is tunnel encapsulated and/or encrypted. 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 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 testing undertaken in this release was limited to configuration of Cisco IOS™ IPSec in Tunnel Mode. Cisco IOS™ Network Address Translation (NAT) is a mechanism for conserving registered IP addresses in large networks and simplifying IP address management tasks. If both VPN devices are NAT-T capable. which means that only the Cisco IP Routers (IPSec peers) between the two sites were part of the secure channel establishment. The qualification of NAT support for Agent Desktops and PG servers was limited to a network infrastructure implementing Cisco IP Routers with NAT functionality.2(13)T and above. As its name implies. so it is important to size the network infrastructure (network hardware and physical links) accordingly. Cisco IOS NAT translates IP addresses within private "internal" networks to "legal" IP addresses for transport over public "external" networks (such as the Internet).com/en/US/partner/products/sw/iosswrel/ps1834/products_feature_guide09186a00800 8052e. Incoming traffic is translated back for delivery within the inside network. There are also some latency implications.0(0) officially adds support for deployment of Agent Desktops and IP Phones (IPCC) across NAT.cisco.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. More detailed resources on how to configure NAT are available at http://www. More detailed information on Cisco IOS IPSec functionality is available at http://www.Chapter 9 Securing IPCC Firewalls and IPSec network implementation implies a distributed model with the WAN connection secured via IPSec tunnels. traffic flow confidentiality is ensured between IPSec peers which. 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.com/go/nat More details on how to deploy IP Phones across NAT for IPCC deployments are available at http://cisco. in this case.com/go/ipsec Support for Network Address Translation (NAT) IPCC Release 6. NAT Traversal is auto-detected and auto-negotiated. All data traffic is encrypted across the WAN link but unencrypted on the local area networks. In tunnel mode.

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

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

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

Glossary DSCP Differentiated Services Code Point DSL Digital subscriber line DSP Digital signal processor E ECC Extended Call Context H HA WAN Highly available WAN HDS Historical Data Server I ICC Intra-cluster communications ICCS Intra-Cluster Communication Signaling ICM Cisco Intelligent Contact Management IDF Intermediate distribution frame IDS Intrusion Detection System IntServ Integrated Services IP Internet Protocol IPC Cisco IP Communications IPCC Cisco IP Contact Center IPM Internetwork Performance Monitor IPPA IP Phone Agent ISN Internet Service Node IVR Interactive voice response IXC 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 Kilobits kB Kilobytes kbps Kilobits per second kBps Kilobytes per second L LAMBDA Load Adaptive Message-Base Data Archive LAN Local area network LCC Logical contact center LDAP Lightweight Directory Access Protocol LEC Local exchange carrier LLA Longest Available Agent LSPAN Local Switched Port Analyzer M MAC Media Access Control Mbps Megabits per second MC Management center MCS Cisco Media Convergence Server MDF Main distribution frame MDS Message Delivery Subsystem MGCP Media Gateway Control Protocol MoH Music on hold Cisco IP Contact Center Enterprise Edition SRND GL-4 OL-7279-04 .

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

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

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

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

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

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

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

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

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

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