Cisco UCCE SRND 9.0
Cisco UCCE SRND 9.0
Cisco UCCE SRND 9.0
Americas 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 527-0883
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.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network
topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional
and coincidental.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: http://
www.cisco.com/go/trademarks. Third-party trademarks mentioned 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. (1110R)
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
iii
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
iv
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
v
Contents
Centralized Voice Gateways with Centralized Call Treatment and Queuing Using Unified
IP IVR 66
Clustering Over the WAN with Unified CCE System PG 67
Centralized Voice Gateways with Centralized Call Treatment and Queuing Using Unified
CVP 67
Considerations for Clustering Over the WAN 68
Distributed Voice Gateways with Distributed Call Treatment and Queuing Using Unified
CVP 70
Site-to-Site Unified CCE Private Communications Options 71
Unified CCE Central Controller Private and Unified CM PG Private Across Dual Links 71
Unified CCE Central Controller Private and Unified CM PG Private Across Single
Link 72
Failure Analysis of Unified CCE Clustering Over the WAN 72
Entire Central Site Loss 73
Private Connection Between Site 1 and Site 2 73
Connectivity to Central Site from Mobile Agent Site 73
High-Availability WAN Failure 74
Mobile Agent Over Broadband 74
Mobile Agent with Unified IP Phones Deployed by using the Cisco Virtual Office
Solution 77
Traditional ACD Integration 78
Hybrid Deployment with PSTN Pre-routing 78
Hybrid Deployment with Fixed PSTN Delivery 79
Hybrid Deployment with Unified CVP 79
Parent/Child Deployment 80
Traditional IVR Integration 80
Using PBX Transfer 80
Using PSTN Transfer 82
Using IVR Double Trunking 82
Using Unified CM Transfer and IVR Double Trunking 83
Unified CCE/CCH: Integration with the Genesys Cisco T-Server 85
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
vi
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
vii
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
viii
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
ix
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
x
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
xi
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
xii
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
xiii
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
xiv
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
xv
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
xvi
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
xvii
Contents
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
xviii
Preface
• Change History, page xix
Change History
Date Content Changes
9/28/2012 Initial release
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
xix
Preface
Change History
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
xx
CHAPTER 1
Architecture Overview
Cisco Unified Contact Center Enterprise (Unified CCE) is a solution that delivers intelligent call routing,
network-to-desktop Computer Telephony Integration (CTI), and multichannel contact management to contact
center agents over an IP network. It combines software IP automatic call distribution (ACD) functionality
with Cisco Unified Communications in a unified solution that enables companies to rapidly deploy an
advanced, distributed contact center infrastructure.
The reader of this document is expected to be familiar with the Unified CCE solution architecture and
functionality as described in the Installation and Configuration Guide for Cisco Unified CCE at http://
www.cisco.com/en/US/products/sw/custcosw/ps1844/prod_installation_guides_list.html. Make sure that
you become familiar with the concepts described in that manual for topics such as routes, labels, and dialed
numbers.
This design guide describes the deployment models and their implications including scalability, fault tolerance,
and interaction between the solution components.
The Unified CCE product integrates with Cisco Unified Communications Manager (Unified Communications
Manager), Cisco Unified IP IVR, Cisco Unified Customer Voice Portal (Unified CVP), Cisco VoIP Gateways,
and Cisco Unified IP Phones. Together these products provide Cisco Unified Communications and contact
center solutions to achieve intelligent call routing, multichannel automatic call distribution (ACD) functionality,
voice response unit (VRU), network call queuing, and consolidated enterprise-wide reporting. Unified CCE
can optionally integrate with Cisco Unified Intelligent Contact Manager to support networking with legacy
ACD systems while providing a smooth migration path to a converged communications platform.
The Unified CCE solution is designed for implementation in both single and multisite contact centers. It
uses your existing Cisco IP network to lower administrative expenses and extend the boundaries of the
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
1
Architecture Overview
contact center enterprise to include branch offices, home agents, and knowledge workers. This figure illustrates
a typical Unified CCE setup.
The Unified CCE solution consists primarily of four Cisco software products:
• Unified Communications infrastructure: Cisco Unified Communications Manager
• Queuing and self-service: Cisco Unified IP Interactive Voice Response (Unified IP IVR) or Cisco
Unified Customer Voice Portal (Unified CVP)
• Contact center routing and agent management: Unified CCE. The major components are CallRouter,
Logger, Peripheral Gateway, and the Administration & Data Server/Administration Client.
• Agent desktop software: Cisco Agent Desktop, Cisco Toolkit Agent Desktop (CTI OS), Cisco Finesse,
or integrations with third-party customer relationship management (CRM) software through Cisco
Unified CRM Connector.
The following sections discuss each of the software products in more detail and describe the data
communications between each of those products. For more information about a particular product, see the
specific product documentation available online at cisco.com.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
2
Architecture Overview
Solution Components
Solution Components
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
3
Architecture Overview
Agent Phones
Agent Phones
Before Release 8.0, Unified CCE supported monitoring of only a single line for all agent devices (Single Line
Agent Mode).
Unified CCE Release 8.0 added support for monitoring multiple agent lines when Multi Line Agent Mode is
enabled for the Peripheral. This feature provides the following capabilities:
• Monitoring and reporting of calls on all lines on the phone. For more details on reporting in a multiline
environment, see the Release Notes for Cisco Unified ICM/Contact Center Enterprise & Hosted, Release
8.0(1).
• Other than placing a call, all other call control on the non-ACD extensions is supported from multiline
capable desktops, except for call initiation. Calls initiated from the hard phone can be controlled after
initial call setup.
• Allows Unified CCE to support Join Across Line (JAL) and Direct Transfer Across Line (DTAL) features
on the phone. These phone features are supported in all Cisco supported phone families.
• Requires a busy trigger of 1 (no call waiting), although calls can be forwarded to other extensions on
the phone when busy.
• Requires a maximum of two call appearances.
• Supports a maximum of four lines per phone, one ACD line and up to three non-ACD lines.
• Shared lines are not supported on ACD and non-ACD lines.
• Call Park is not supported on ACD and non-ACD lines.
• Unified CCE may not be backward compatible with third-party CTI applications when Multi Line Agent
Mode is enabled. Multiline support must be validated with the third-party vendor.
For a list of supported agent phones, see the Cisco Unified Contact Center Enterprise (Unified CCE) Software
Compatibility Guide.
The following three families of phones are in the Cisco portfolio:
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
4
Architecture Overview
Agent Phones
Cisco Finesse Release 9.1(1) or later supports Unified IP Phones 8900 Series and 9900 Series with the following
caveats:
• The phones must be configured with only a single line (these phones are not supported if multiple lines
are configured).
• Maximum Number of Calls must be set to 2.
• Busy Trigger must be set to 1.
For a list of agent phones and required firmware to support the Agent Greeting feature, see the Cisco Unified
Contact Center Enterprise (Unified CCE) Software Compatibility Guide.
In Unified CCE Version 8.5(1), Agent Greeting is not supported for mobile agent, or for parent/child
deployments. Release 8.5(2) adds mobile agent and parent/child support for Agent Greeting.
Note Agent Greeting for Parent/Child is only supported for a specific Parent/Child configuration, where calls
are queued at a CCX (IP-IVR) on the child system PG, and requires a dedicated CVP at the child on a
dedicated VRU PG to provide the agent greetings. Agent Greeting in Parent/Child configurations must
be approved by the Cisco Assessment to Quality (A2Q) process and requires Cisco Design Mentoring
Service to assure that the deployment model is designed and sized correctly to support the Agent Greeting
feature.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
5
Architecture Overview
Precision Routing
Precision Routing
Precision Routing is a feature available with Cisco Unified Contact Center Enterprise (Unified CCE), Release
9.0. Precision Routing enhances and can replace traditional routing. Traditional routing looks at all of the
skills to which an agent belongs and defines the hierarchy of skills to map business needs. However, traditional
routing is restricted by its single dimensional nature. Precision Routing provides multidimensional routing
with simple configuration, scripting, and reporting. Agents are represented through multiple attributes with
proficiencies so that the capabilities of each agent are accurately exposed, bringing more value to the business.
You can use a combination of attributes to create multidimensional precision queues. Using Unified CCE
scripting, you can dynamically map the precision queues to direct a call to the agent that best matches the
precise needs of the caller.
Note Precision Routing is supported only on Unified CCE Communications Manager PG.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
6
Architecture Overview
Cisco Unified IP IVR
menu, and collect information. The Unified CCE script can also invoke external VoiceXML applications to
be executed by the Unified CVP VoiceXML Server, an Eclipse and J2EE-based scripting and web server
environment. VoiceXML Server is well suited for sophisticated and high-volume IVR applications and it can
interact with custom or third-party J2EE-based services. These applications can return results and control to
the Unified CCE script when complete. Advanced load balancing across all Unified CVP solution components
can be achieved by Cisco Content Services Switch (CSS) and Cisco IOS Gatekeepers or Cisco Unified Presence
SIP Proxy Servers.
Unified CVP can support multiple grammars for prerecorded announcements in several languages. Unified
CVP can optionally provide automatic speech recognition and text-to-speech capability. Unified CVP can
also access customer databases and applications through the Cisco Unified CCE software.
Unified CVP also provides a queuing platform for the Unified CCE solution. Voice and video calls can remain
queued on Unified CVP until they are routed to a contact center agent (or external system). The system can
play back music or videos while the caller is on hold; and when Unified CCE routes the call to an agent, the
agent is able to send videos to a caller from the agent desktop application. For more information, see the latest
version of the Cisco Unified Communications Solution Reference Network Design (SRND) Guide at http://
www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html.
Unified CVP also supports Agent Greeting recording and playback when integrated with Unified CCE. A
preinstalled CVP VXML application is provided to allow agents to record and manage their greetings. Unified
CCE instructs the CVP to play back the agent’s specific greeting to the caller and agent when the agent answers
the call.
Unified CVP also supports the Whisper Announcement feature to play a pre-recorded announcement to the
agent when the agent answers the call.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
7
Architecture Overview
Unified Presence Server
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
8
Architecture Overview
Unified CCE Software Components
The core Unified CCE software components are listed here and described in greater detail later in this chapter.
CTI Object Server (CTI OS) CTI interface for Agent Desktops.
Unified CM Peripheral Interface Manager Part of a PG that interfaces to a Unified CM cluster by using
(PIM) the JTAPI protocol.
CTI Server Part of the PG that interfaces to CTI OS and provides an open
CTI interface, which is useful for some server-to-server
communications.
Network Interface Controller (NIC) Interfaces to the public switched telephone network (PSTN),
which enables Unified CCE to control how the PSTN routes
a call.
Administration & Data Server Configuration interface and real-time and historical data storage
(for example, for reporting). There are several different
deployment models described later in this chapter.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
9
Architecture Overview
Redundancy and Fault Tolerance
The combination of CallRouter and Logger is called the Central Controller. When the CallRouter and Logger
modules run on the same server, the server is referred to as a Rogger. When the CallRouter, Logger, and
Peripheral Gateway modules run on the same server, the server is referred to as a Progger. In lab environments,
the system Administration & Data Server can also be loaded onto the Progger to create a server known as a
Sprawler configuration; however, this configuration is approved only for lab use and is not supported in
customer production environments.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
10
Architecture Overview
Peripheral Gateway (PG) and PIMs
All Unified CCE systems are deployed as a single instance (using the same instance name and number in
setup) across all the Unified CCE components.
Note The CTI OS components on Side A and Side B are simultaneously active to load-balance desktop
communication.
For each Unified IP IVR or CVP Call Server, there is one VRU PIM. VRU PIMs may be part of the Agent
PG.
Often, the Unified CM PIM, the CTI Server, the CTI OS, and multiple VRU PIMs may run on the same server.
Internal to the PG is a process called the PG Agent which communicates to the Central Controller. Another
internal PG process is the Open Peripheral Controller (OPC), which enables the other processes to communicate
with each other and is also involved in synchronizing PGs in redundant PG deployments. The following figure
shows the communications among the various PG software processes.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
11
Architecture Overview
Network Interface Controller
In larger, multisite (multi-cluster) environments, multiple Agent PGs are usually deployed. When multiple
Unified CM clusters are deployed, Unified CCE tracks all the agents and calls centrally. Unified CCE is able
to route the calls to the most appropriate agent independent of the site or cluster that they are using, thus
making them all appear to be part of one logical enterprise-wide contact center with one enterprise-wide
queue.
• Cisco Agent Desktop: Cisco Agent Desktop provides an out-of-the-box, feature-rich, desktop solution
for Unified CCE. The desktop application can be deployed in various ways:
◦Windows application
◦Browser-based application
◦Cisco Unified IP Phone Agent, where there is no desktop application at all but just an XML
application on the IP phone
• Cisco CTI OS Desktop Toolkit:The CTI OS Desktop Toolkit provides a software toolkit for building
custom desktops, desktop integrations into third-party applications, or server-to-server integrations to
third-party applications.
• CRM Connectors: Cisco offers pre-built, certified CRM Connectors for CRM packages including SAP,
Siebel (using CTI OS driver), and Salesforce.com. These integrated solutions enable call control from
the CRM user interface (Answer, Drop, Hold, Un-Hold, Blind or Warm Transfers, and Conferences),
outbound and consultative calls from the CRM desktop, and delivery and manipulation of Call Context
Data (CTI screen pop).
Agents who use a third-party CRM user interface that is connected through a CRM Connector can be supervised
using a CTI OS Desktop Toolkit-based supervisor desktop.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
12
Architecture Overview
Administration and Data Server and Administration Client
For more information about desktop selection and design considerations, see Unified Contact Center Enterprise
Desktop.
Note See the Deployment Models chapter for more details on deployment options and
requirements.
• An Administration Client (formerly known as a client AW) serves the administration role but is deployed
as a client to an Administration Server for scalability. The Administration Client may view and modify
the configuration and receive real-time reporting data from the AW, but it does not store the data itself
and does not have a database.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
13
Architecture Overview
Administration Server and Administration Client
Each Administration & Data Server must be installed on a separate server for production systems to ensure
no interruptions to the real-time call processing of the CallRouter and Logger processes. For lab or prototype
systems, the Administration & Data Server can be installed on the same server as the CallRouter and Logger.
The AW acts as the authentication server for Cisco Finesse. In a Finesse deployment, the AW is mandatory
and must run in high-availability mode (both a primary and backup AW).
For information about data storage in virtualized deployments, see the Virtualization for Unified CCE page
on the DocWiki.
For information about these and other configuration tools, see the Administration Guide for Cisco Unified
ICM/Contact Center Enterprise & Hosted.
The Administration Server is deployed as part of the Administration and Real-time Data Server, known as
AW. AWs are deployed in pairs for fault tolerance. During normal operation, the primary AW communicates
directly with the Central Controller for configuration data (see Figure 4) and the secondary AW connects to
the primary AW for the data. If the primary AW fails, the secondary AW connects to the Central Controller.
Both types of AW store the configuration and real-time data in the AW Database, or AWDB. Each AW can
be deployed in the same location as, or remote from, the Central Controller. A secondary AW need not be
co-located with the primary AW.
Multiple Administration Clients can be deployed and connected to either primary or secondary AWs. An
Administration Client must be geographically local to its AW.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
14
Architecture Overview
Administration Server and Administration Client
Configuration Only Administration Servers are the same as AWs, but without the real-time data. As such,
Administration Clients cannot connect to them and they cannot display real-time data in Script Editor. They
can be deployed in a multi-instance configuration for Hosted CCE. (See Figure 4.)
Figure 4: Communication Between Unified CCE Central Controller and Administration & Data Server
Figure 5: Communication Between Unified CCE Central Controller and Multiple Administration & Data Servers
AWs, Configuration-Only Administration Servers, and Administration Clients may operate only as a single
instance on a given server. In a hosted environment, multiple instances may be installed and configured and
the Select Administration Instance tool may be used to switch between the instances.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
15
Architecture Overview
Unified CCE Reporting
Note Reporting concepts and data descriptions are described in the Reporting Guide for Cisco Unified ICM/
Contact Center Enterprise & Hosted. (This description is independent of the reporting user interface being
used.)
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
16
Architecture Overview
JTAPI Communications
• Unified Configuration; that is, tenant provisioning of both the applicable IP contact center elements and
the Cisco Unified Communications Manager components through a single task-based web interface
• Partitioned System supporting multiple business units with complete autonomy
• Hierarchical Administration supporting multiple business-level users where each user is defined with
specific roles and responsibilities
• Audit Trail Reports that detail configuration changes and usage by all users of the management portal
See the chapter on Cisco Unified Contact Center Management Portal for more information about Cisco Unified
Contact Center Management Portal.
JTAPI Communications
In order for JTAPI communications to occur between Unified CM and external applications such as Unified
CCE and Unified IP IVR, a JTAPI user ID and password must be configured within Unified CM. Upon startup
of the Unified CM PIM or on startup of the Unified IP IVR, the JTAPI user ID and password are used to sign
in to Unified CM. This sign-in process by the application (Unified CM PIM or Unified IP IVR) establishes
the JTAPI communications between the Unified CM cluster and the application. A separate JTAPI user ID
is required for each Unified IP IVR server. In a Unified CCE deployment with one Unified CM cluster and
two Unified IP IVRs, three JTAPI user IDs are required: one JTAPI user ID for Unified CCE and two JTAPI
user IDs for the two Unified IP IVRs. The best practice is one PG User for each PG Pair.
The Unified CM software includes a module called the CTI Manager, which is the layer of software that
communicates through JTAPI to applications such as Unified CCE and Unified IP IVR. Every node within
a cluster can execute an instance of the CTI Manager process, but the Unified CM PIM on the PG communicates
with only one CTI Manager (and thus one node) in the Unified CM cluster. The CTI Manager process
communicates CTI messages to and from other nodes within the cluster.
For example, suppose a deployment has a Voice Gateway homed to node 1 in a cluster, and node 2 executes
the CTI Manager process that communicates to Unified CCE. When a new call arrives at this Voice Gateway
and needs to be routed by Unified CCE, node 1 sends an intra-cluster message to node 2, which sends a route
request to Unified CCE to determine how the call is routed.
Each Unified IP IVR also communicates with only one CTI Manager (or node) within the cluster. The Unified
CM PIM and the two Unified IP IVRs from the previous example can communicate with different CTI
Managers (nodes) or they can all communicate with the same CTI Manager (node). However, each
communication uses a different user ID. The user ID is how the CTI Manager tracks the different applications.
When the Unified CM PIM is redundant, only one side is active and in communication with the Unified CM
cluster. Side A of the Unified CM PIM communicates with the CTI Manager on one Unified CM node and
Side B of the Unified CM PIM communicates with the CTI Manager on another Unified CM node. The Unified
IP IVR does not have a redundant side, but the Unified IP IVR does have the ability to fail-over to another
CTI Manager (node) within the cluster if its primary CTI Manager is out of service. (For more information
about fail-over, see Design Considerations for High Availability.)
The JTAPI communications between the Unified CM and Unified CCE include three distinct types of
messaging:
• Routing control
Routing control messages provide a way for Unified CM to request routing instructions from Unified
CCE.
• Device and call monitoring
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
17
Architecture Overview
JTAPI Communications
Device monitoring messages provide a way for Unified CM to notify Unified CCE about state changes
of a device (phone) or a call.
• Device and call control
Device control messages provide a way for Unified CM to receive instructions from Unified CCE on
how to control a device (phone) or a call.
A typical Unified CCE call includes all three types of JTAPI communications within a few seconds. When a
new call arrives, Unified CM requests routing instructions from Unified CCE. For example, when Unified
CM receives the routing response from Unified CCE, Unified CM attempts delivery of the call to the agent
phone by instructing the phone to begin ringing. At that point, Unified CM notifies Unified CCE that the
device (phone) has started ringing and that notification enables the agent’s answer button on the desktop
application. When the agent clicks the answer button, Unified CCE instructs Unified CM to make the device
(phone) go off-hook and answer the call.
In order for the routing control communication to occur, Unified CM requires the configuration of a CTI
Route Point. A CTI Route Point is associated with a specific JTAPI user ID, and this association enables
Unified CM to know which application provides routing control for that CTI Route Point. Directory (Dialed)
Numbers (DNs) are then associated with the CTI Route Point. A DN is associated to a CTI Route Point that
is associated with Unified CCE JTAPI user ID. This enables Unified CM to generate a route request to Unified
CCE when a new call to that DN arrives.
In order for the phones to be monitored and controlled, they also must be associated in Unified CM with a
JTAPI user ID. Starting with Unified CM 8.0, when using Extension Mobility or Extension Mobility Cross
Cluster, it is possible to associate an Extension Mobility device profile instead. In a Unified CCE environment,
the IP phones or the corresponding Extension Mobility device profiles are associated with Unified CCE JTAPI
user IDs. When an agent logs in from the desktop, the Unified CM PIM requests Unified CM to allow the
PIM to begin monitoring and controlling that phone. Until the login has occurred, Unified CM does not allow
Unified CCE to monitor or control that phone. If the device or the corresponding Extension Mobility device
profile has not been associated with a Unified CCE JTAPI user ID, then the agent login request fails.
Support for Extension Mobility Cross Cluster (EMCC) is provided in Release 8.0. The Unified CCE PIM
phone registers to the local Unified CM after Extension Mobility login and it looks like an agent situated
across a WAN. The Unified CCE peripheral is managing the agent devices based on the Extension Mobility
profile rather than on a phone device in the Application User on Unified CM. For more details, see the Cisco
Unified Communications System Solution Reference Network Design (SRND) Guide at http://www.cisco.com/
en/US/docs/voice_ip_comm/uc_system/design/guides/UCgoList.html.
Because EMCC is now supported, you can associate Extension Mobility devices by two methods; either by
device or by user profile. The best practice is to associate the Extension Mobility profile to the CCE Application
User on UC Manager.
Because the Unified IP IVR also communicates with Unified CM using the same JTAPI protocol, these same
three types of communications also occur with the Unified IP IVR. Unlike Unified CCE, the Unified IP IVR
provides both the application itself and the devices to be monitored and controlled.
The devices that Unified CCE monitors and controls are the physical phones. The Unified IP IVR does not
have physical ports like a traditional IVR. Its ports are logical ports (independent software tasks or threads
running on the Unified IP IVR application server) called CTI Ports. For each CTI Port on the Unified IP IVR,
there needs to be a CTI Port device defined in Unified CM.
Unlike a traditional PBX or telephony switch, Unified CM does not select the Unified IP IVR port to which
it sends the call. Instead, when a call needs to be made to a DN that is associated with a CTI Route Point that
is associated with a Unified IP IVR JTAPI user, Unified CM asks the Unified IP IVR (through JTAPI routing
control) which CTI Port (device) handles the call. Assuming the Unified IP IVR has an available CTI Port,
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
18
Architecture Overview
Multichannel Subsystems: EIM and WIM
the Unified IP IVR responds to the Unified CM routing control request with the Unified CM device identifier
of the CTI Port that is going to handle that call.
The following scenarios are examples of device and call control performed by the Unified IP IVR.
When an available CTI Port is allocated to the call, a Unified IP IVR workflow is started within the Unified
IP IVR. When the Unified IP IVR workflow executes the accept step, a JTAPI message is sent to Unified CM
to answer the call on behalf of that CTI Port (device). When the Unified IP IVR workflow wants the call
transferred or released, it again instructs Unified CM on what to do with that call.
When a caller releases the call while interacting with the Unified IP IVR, the Voice Gateway detects the caller
release and notifies Unified CM by using H.323 or Media Gateway Control Protocol (MGCP), which then
notifies the Unified IP IVR by using JTAPI. When DTMF tones are detected by the Voice Gateway, it notifies
Unified CM via H.245 or MGCP, which then notifies the Unified IP IVR through JTAPI.
In order for the CTI Port device control and monitoring to occur, the CTI Port devices on Unified CM must
be associated with the appropriate Unified IP IVR JTAPI user ID. If you have two 150-port Unified IP IVRs,
you have 300 CTI ports. Half of the CTI ports are associated with JTAPI user Unified IP IVR 1, and the other
half of the CTI ports are associated with JTAPI user Unified IP IVR 2.
While Unified CM can be configured to route calls to Unified IP IVRs on its own, routing of calls to the
Unified IP IVRs in a Unified CCE environment is done by Unified CCE (even if you have only one Unified
IP IVR and all calls require an initial IVR treatment). Doing so ensures proper Unified CCE reporting. For
deployments with multiple Unified IP IVRs, this routing practice also allows Unified CCE to load-balance
calls across the multiple Unified IP IVRs.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
19
Architecture Overview
Serviceability
Serviceability
Diagnostic Tools
Unified CCE has a built-in web-based (REST-like) interface for diagnostics called the Diagnostic Framework,
which is resident on every Unified CCE server. The Analysis Manager functionality integrated with the Unified
Communications Manager Real-Time Monitoring Tool (RTMT) is provided as the client-side tool to collect
diagnostic information from this diagnostic framework. In addition to the Analysis Manager, a command line
interface—Unified System CLI tool—is available that allows a client to access the diagnostic framework on
any Unified Communications server. (A user need not use Remote Desktop first to gain access to use the
CLI.)
Using the Analysis Manager, the administrator connects to one or more Unified Communications devices to
set trace levels, collect trace and log files, and gather platform and application configuration data as well as
version and license information. The Analysis Manager is the one tool that allows administrators to collect
diagnostic information from all Cisco Unified Communications applications and devices.
The Analysis Manager offers local user and domain security for authentication and secure HTTP to protect
data exchanged by it and the diagnostic framework.
For more information about the Unified CCE Diagnostic Framework (that runs on every Unified CCE server),
see the Serviceability Best Practices Guide for Cisco Unified ICM/Contact Center Enterprise at http://
www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/
products-configuration-examples-list.html.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
20
Architecture Overview
Combining IP Telephony and Unified CCE in the Same Unified Communications Manager Cluster
For details on the health monitoring and management capabilities of Unified CCE, review the Serviceability
Best Practices Guide for Cisco Unified ICM/Contact Center Enterprise at http://www.cisco.com/c/en/us/
support/customer-collaboration/unified-contact-center-enterprise/products-configuration-examples-list.html.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
21
Architecture Overview
Agent Phones in Countries with Toll-Bypass Regulations
It is possible to have a deployment where the agent extension is the same as the agent’s DID or personal line.
When call waiting is configured on the agent phone, agent-to-agent calls can interrupt a customer call. To
prevent this from happening, agent-to-agent routing can be used and the agent-to-agent routing script can be
set up to queue or reject the call if the agent is busy. This is a good option if there is a need to see all agent
activity and to avoid all interruptions for the agent. The configuration involves using CTI Route Points in
Unified Communications Manager instead of the agent DID to send the calls to Unified CCE for agent-to-agent
routing. For ease of configuration and to reduce the number of CTI route points, the Unified Communications
Manager wildcard feature can be used, although Unified CCE requires distinct routing DNs (one for each
agent).
Note You cannot use the DN for a CTI Route Point on a different CTI Route Point in another partition. Ensure
that DNs are unique across all CTI Route Points on all partitions.
To comply with such regulations, agents had one line to access customer calls and a different phone for VoIP
access to teammates or experts located outside the contact center.
The Logical Partitioning feature in Cisco Unified Communications Manager provides the same capability to
control calls and features based on specific allowed or forbidden configurations. A common telephony system
in a contact center provides access to both the PSTN and VoIP networks. Therefore, the system requires
configurations to provide controlled access and to avoid toll bypass.
You can enable and configure the Logical Partitioning feature to prevent toll-bypass calls. With the feature,
agents in a Unified CCE system can use the same phone for receiving customer calls and for making or
receiving VoIP calls with other employees. Although this feature eliminates the need for agents to have a
second phone, contact center managers can choose to have a dedicated line or phone for customer calls and
can allocate a different line or phone for other calls.
When planning your Unified CCE deployment, it is important to consider how to handle queuing and requeuing.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
22
Architecture Overview
Transfers and Conferences in a Unified CCE Environment
Call queuing in a Unified CCE deployment requires use of an VRU platform that supports the SCI interface
to Unified CCE. Unified IP IVR is one such platform. Cisco offers another VRU platform, Unified CVP,
which you can use as a queuing point for Unified CCE deployments. For more information, see Deployments.
In a Unified CCE environment, a VRU provides voice announcements and queuing treatment while waiting
for an agent. Unified CCE provides the control over the type of queuing treatment for a call through the SCI
interface. The Run VRU Script node in a Unified CCE routing script is the component that causes Unified
CCE to instruct the VRU to play a particular queuing treatment.
While the VRU plays the queuing treatment to the caller, Unified CCE waits for an available agent with the
skill defined in the routing script. When an agent with the defined skill becomes available, Unified CCE
reserves that agent. Unified CCE instructs the VRU to transfer the voice path to that agent phone.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
23
Architecture Overview
Transfers and Conferences in a Unified CCE Environment
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
24
CHAPTER 2
Deployment Models
There are numerous ways that Unified Contact Center Enterprise (Unified CCE) can be deployed, but the
deployments can generally be categorized into the following major types or models:
• Single Site
• Multisite Centralized Call Processing
• Multisite Distributed Call Processing
• Clustering over the WAN
Many variations or combinations of these deployment models are possible. The primary factors that cause
variations within these models are as follows:
• Location of Unified CCE servers
• Location 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, PBX, and IVR integration
• Sizing
• Redundancy
This topic discusses the impact of these factors (except for sizing) on the selection of a design. With each
deployment model, this topic also lists considerations and risks that must be evaluated using a cost benefit
analysis. Scenarios that best fit a particular deployment model are also noted.
In this topic, section titles are prefaced by the type of factor discussed in the section. The factors are classified
into the following categories:
• IPT—Cisco Unified Communications deployment factors (how Cisco Unified Communications Manager
and the Voice Gateways are deployed)
• Unified CCE—Unified CCE deployment factors (such as what PG is used)
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
25
Deployment Models
What’s New in This Chapter
• IVR—IVR and queuing deployment factors (if Unified CVP or Unified IP IVR is used)
A combination of these deployment models is also possible. For example, a multisite deployment may have
some sites that use centralized call processing (probably small sites) and some sites that use distributed call
processing (probably larger sites). Examples of scenarios where combinations are likely are identified within
each section.
Also in this chapter is a section on integration of traditional ACD and IVR systems into a Unified CCE
deployment with considerations on hybrid PBX/ACD deployments. Sizing and redundancy are discussed in
later chapters of this Unified CCE design guide. For more information about the network infrastructure
required to support a Unified CCE solution, see the latest version of the Cisco Network Infrastructure Quality
of Service Design Guide at http://www.cisco.com/en/US/netsol/ns742/networking_solutions_program_
category_home.html .
For more information about deployment models for Unified CCE and Cisco Unified Communications, see
the latest version of the Cisco Unified Communications Solution Reference Network Design (SRND) Guide
at http://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html.
The new and changed information in this chapter is extensive; read the entire chapter.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
26
Deployment Models
Agent Peripheral Types
Note Precision Routing does not support the Unified CCE System Peripheral.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
27
Deployment Models
Unified CCE Administration and Data Server
Roles
The Administration & Data Servers are classified into the following roles based on the system configuration
and the call load that it can handle:
Administration Server (Configuration and Real-Time Reporting)
This role is similar to the former Distributor AW model which provides the capability for configuration
changes as well as real-time reporting. The real-time reporting is supported using Cisco Unified
Intelligent Center (Reporting client). No historical reporting is supported.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
28
Deployment Models
Unified CCE Administration and Data Server
Figure 7: Configuration-Only AW
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
29
Deployment Models
Unified CCE Administration and Data Server
Administration Server, Historical Data Server, and Detail Data Server (AW-HDS-DDS)
This Administration & Data Server deployment role is similar to the existing Distributor AW with HDS
model which provides the capability for configuration changes as well as both real-time and historical
reporting. The real-time and historical reporting is supported using Cisco Unified Intelligence Center
(Unified Intelligence Center Reporting client). Call detail and call variable data are supported for custom
reporting data extraction to feed historical data.
Figure 8: Administration Server, Historical Data Server, and Detail Data Server (AW-HDS-DDS)
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
30
Deployment Models
Unified CCE Administration and Data Server
Note Cisco Unified Intelligence Center is not part of the out-of-the-box solution.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
31
Deployment Models
Deployment Options
Figure 10: Historical Data Server And Detail Data Server (HDS-DDS)
Deployment Options
The following deployment options are based on the varying capacity in terms of number of agents, call load,
number of reporting users, and other operating conditions mentioned in the Sizing Unified CCE Components
and Servers chapter.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
32
Deployment Models
Parent/Child
The number of Administration & Data Server roles is limited to three AW-HDSs and 1 HDS-DDS or
AW-HDS-DDS per Logger side.
Cisco Unified Intelligence Center (Reporting client) is supported but not part of the out-of-the-box solution.
Parent/Child
The Unified CCE Gateway PG allows Unified CCE or Unified CCX to appear as a traditional ACD connected
to the Unified ICM system. The Unified CCE Gateway PG does this by providing a PG to the Unified ICM
system that communicates to the CTI interface of Unified CCE System PG or Unified CCX.
When the Unified CCE Gateway PG is used in a deployment, its relationship to Unified ICM is termed a
parent and Unified CCE is called the child:
Parent
The Unified ICM system that serves as the network or enterprise routing point. The child looks like an
ACD to the parent, which uses the appropriate Unified CCE Gateway PG (Enterprise or Express) to
communicate to the CTI interface on the child Unified CCE. The parent can perform all functions that
a Unified ICM can usually perform, including pre- and post-routing and end-to-end call tracking using
translation routes.
Child
The Unified CCE System PG or Unified CCX system that is set up to function as an ACD. The child
can receive calls that are translation-routed from the parent, but it is not aware of any other peripherals
attached to the parent. The child can also post-route calls from the Unified CCE to the parent where
the call can be handled like any other Unified ICM call. For example, the call can be translation-routed
to any TDM or IP ACD controlled by the Unified ICM or queued in the Unified ICM network queue
point with Unified CVP.
In the parent/child model, the child Unified CCE is configured to function completely on its own and does
not need the connection to the parent to route calls to agents. This independence provides complete local
survivability for mission-critical contact centers if the network between the child and parent goes down or if
there is a problem with the parent or the Unified CCE Gateway PG connection.
Configuration objects entered into the child system can automatically be sent to the parent Unified ICM and
inserted into the Unified ICM configuration, thus eliminating the need to configure objects twice (once in the
local ACD and again to match the configuration in the Unified ICM itself for routing and reporting). This
functionality can also be turned off for situations where the customer does not want automatic configuration
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
33
Deployment Models
Parent/Child
updates, such as with an outsourcer using the Unified CCE child system where not all of the agents, skill
groups, and call types on that child system apply to the customer’s Unified ICM system.
The Unified CCE Gateway PG can connect to a Unified CCE child that is using the Unified CCE System PG
or to Unified CCX. If the Unified CCE child has multiple Unified CCE System PGs and peripherals, a separate
Unified CCE Gateway PG peripheral must be installed and configured for each one in the Unified ICM parent
system. When deployed on a separate server, a Unified CCE Gateway PG can manage multiple child Unified
CCE peripherals or multiple child Unified CCX systems (up to five child systems).
Note The Unified CCE Gateway PG does not support Unified CCE System PG and Unified CCX integration
on the same CCE Gateway PG instance.
In the Unified CCE child, you can deploy IP IVR or Unified CVP for call treatment and queuing. If you deploy
Unified CVP, you must configure an additional VRU PG. This model does not follow the single peripheral
model used when IP IVR is deployed. For this reason, information about calls queued at the child (and queue
time of a call) is not available on the parent, so any computation involving queue time (such as minimum
expected delay (MED) and average answer wait time) are inaccurate.
Special Note on Whisper Announcement and Agent Greeting for Parent/Child Systems
Beginning with Unified CCE Release 8.5(2), the Whisper Announcement and Agent Greeting feature are
supported on a child Unified CCE.
Agent Greeting for Parent/Child is only supported for a very specific Parent/Child configuration, where calls
are queued at a CCX (IP-IVR) on the child system PG, and requires a dedicated CVP at the child on a dedicated
VRU PG to provide the agent greetings. Agent Greeting in Parent/Child configurations must be approved by
the Cisco Assessment to Quality (A2Q) process and requires Cisco's Design Mentoring Service to assure that
the deployment model is designed and sized correctly to support the Agent Greeting feature.
To deploy the child Unified CCE, you must complete the following:
• Use IP-IVR on the child for call treatment, queuing, and Whisper Announcement.
• Use CVP on the child only for Agent Greeting. Do not use CVP for call queuing. You must use a separate
VRU PG for the CVP.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
34
Deployment Models
SIP Support
Note Network blind transfer is still possible using any client (for example, Unified CVP or a NIC) on the parent
system when a post route is initiated to the parent system from the child.
SIP Support
Unified IP IVR is notified of caller entered digits (DTMF input) by way of JTAPI messages from Unified
CM. Unified IP IVR and Unified CM do not support mechanisms to detect in-band DTMF digits. In
deployments with SIP Voice Gateways or SIP phones that support only in-band DTMF (or are configured to
use in-band DTMF In accordance with RFC 2833), Unified CM must invoke an MTP resource to convert the
in-band DTMF signaling to out-of band signaling so that the Unified IP IVR can be notified of caller entered
digits. Therefore, in environments that include SIP phones or gateways, it is necessary to provision sufficient
MTP resources. Keep this in mind if the phones need to interact with Unified IP IVR. Likewise, CTI ports
do not support in-band DTMF (RFC 2833). The Mobile Agent feature relies on CTI ports, so MTP resources
are required when in-band DTMF (RFC 2833) is negotiated.
SIP trunking is supported using CVP deployments with Cisco IOS gateways (IOS GW) and Unified Border
Elements (CUBE). For more information about deployment models for Unified CCE and Cisco Unified
Communications, see the latest version of the Cisco Unified Communications Solution Reference Network
Design (SRND) Guide at http://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_
series_home.html.
Q.SIG Support
Cisco Unified CCE does not support using Q.SIG trunks with the Unified CM deployment.
IPv6 Support
Unified CCE 8.0 supports interoperability with an IPv6-enabled Unified CM cluster. All the Unified CCE
components run with IPv4 enabled including IP-IVR, Unified CVP, the CTI OS Agent Desktops, and Agent
Phones. The Unified CCE Agent PG integration with the Unified CM CTI Manager uses IPv4.
Caller phones or Voice Gateways can run IPv4 or IPv6. If the caller's environment is IPv6 only, then Media
Termination Point (MTP) resources are required for call treatment using IP-IVR and Unified CVP VXML
Gateways.
Agent phones must run IPv4; IPv6 is not supported for agent phones. If the caller’s phone is IPv6, then an
MTP must also be inserted between the resources.
Mobile Agent and Outbound Option endpoints (CTI ports and Dialer ports) must be configured as IPv4
devices.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
35
Deployment Models
Cisco Unified Mobile Agent
Cisco Finesse must be deployed as a virtual machine in a VMware virtual environment. Finesse can be deployed
according to coresidency policies outlined in the Unified Communications Virtualization DocWiki (http://
docwiki.cisco.com/wiki/Unified_Communications_Virtualization).
Finesse can be deployed with CTI-OS with the following limitations:
• The maximum number of CTI all events connections supported by the CTI Server (7) is not exceeded.
• The total number of combined Finesse and CTI OS agents does not exceed the capacity of the common
PG.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
36
Deployment Models
Virtualization Support
Virtualization Support
For detailed information about Unified Communications applications running in virtual machines on UCS
hardware, please see the Unified Communications Virtualization DocWiki page at: http://docwiki.cisco.com/
wiki/Unified_Communications_Virtualization.
Limitations
Precision Routing is currently available for voice agents only, and does not support multimedia. Precision
Routing is available only for the unified CCE PG, and does not support the Unified System PG.
Precision Routing is not supported in a parent/child deployment.
Precision Routing is not supported for Cisco Outbound Option. However, agents who participate in an outbound
campaign (through an outbound skill group) can also be logged into a Precision Queue to handling inbound
calls.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
37
Deployment Models
Agent Greeting Support
One Network VRU Is Used for Call Treatment, Call Queuing, and Playing Agent Greeting
In this deployment model, one network VRU is configured in the Unified CCE and this VRU is used for
playing prompts, call queuing, and playing or recording agent greeting. The SendToVRU node can be used
in the routing script for the agent greeting call leg.
For small deployments where one CVP server is used for call queuing and treatment, a SIP trunk can be
configured in UCM to directly send the call to the CVP to play the agent greeting.
For those deployments where more than one CVP servers are needed for call queuing and treatment, each
CVP server is associated with a VRU PIM and all those VRU PIMs are associated with the same network
VRU.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
38
Deployment Models
Agent Greeting Support
A proxy server can be configured between the UCM and CVP servers to balance the load among those CVP
servers for the agent greeting call leg. See the following figure.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
39
Deployment Models
IPT: Single Site
• The latency between the Unified CCE Central Controllers and remote PGs (both Agent PG and VRU
PG) cannot exceed 50 ms one way (100-ms round trip).
• When multiple CVP servers are deployed for the call load, it is possible that the call is queued at one
CVP and Agent Greeting is played by a different CVP at another site. For better performance, it is ideal
to have the Agent Greeting played by the VXML Voice Gateway which is closest to the agent phone.
This figure shows a Unified IP IVR, a Unified CM cluster, redundant Unified CCE servers, two Administration
& Data Servers, and a direct connection to the PSTN from the Voice Gateways.
The Unified CCE server in this scenario is running the following major software processes:
• Call Router
• Logger and Database Server
• Unified CCE System PG with Unified CM Peripheral Interface Manager (PIM) and Unified IP IVR
PIM
• CTI Server
• CTI Object Server (CTI OS)
• Optionally, Cisco Agent Desktop (CAD) servers can be co-located on the Unified CCE servers as well.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
40
Deployment Models
Unified CCE: Unified CCE System PG
Optionally, the Central Controller and Unified CCE System PG can be split onto separate servers. For
information about when to install the Central Controller and PG on separate servers, see Sizing Unified CCE
Components and Servers.
Traditional Unified CCE must be deployed in a redundant fashion. Simplex deployments are supported only
for lab or non-production deployments. For information about Unified CCE redundancy, see Design
Considerations for High Availability.
The number of Unified CM nodes and the hardware model used is not specified along with the number of
Unified IP IVRs. For information about determining the number and type of servers required, see Sizing
Unified CCE Components and Servers.
Also not specified in this model is the specific data switching infrastructure required for the LAN, the type
of Voice Gateways, or the number of Voice Gateways and trunks. Cisco campus design guides and Cisco
Unified Communications design guides are available to assist in the design of these components. Sizing
Contact Center Resources discusses how to determine the number of gateway ports.
Another variation of this model is to have the Voice Gateways connected to the line side of a PBX instead of
the PSTN. Connection to multiple PSTNs and a PBX all from the same single-site deployment is also possible.
For example, a deployment can have trunks from a local PSTN, a toll-free PSTN, and a traditional PBX/ACD.
For more information, see Traditional ACD Integration and Traditional IVR Integration.
This deployment model also does not specify the type of signaling (ISDN, MF, R1, and so on) to be used
between the PSTN and Voice Gateway, or the specific signaling (H.323, SIP or MGCP) to be used between
the Voice Gateway and Unified CM.
The amount of digital signal processor (DSP) resources required for placing calls on hold, consultative transfers,
and conferencing is also not specified in this model. For information about sizing of these resources, see the
latest version of the Unified Communications System Solution Reference Network Design (SRND) at http://
www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/UCgoList.html.
The main advantage of the single-site deployment model is that there is no WAN connectivity required. Given
that there is no WAN in this deployment model, there is generally no need to use g.729 or any other compressed
Real-Time Transport Protocol (RTP) stream (so transcoding is not required).
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
41
Deployment Models
IVR: Treatment and Queuing with Unified IP IVR
shows a single-site deployment using Unified CVP instead of IP-IVR in a Unified CCE system. In this model,
no longer do all calls reside under a single peripheral; Unified CVP is its own peripheral.
When using this configuration, the VRU PGs are deployed in a duplex PG configuration with one to ten
Unified CVP Call Servers (depending on the number of agents and call volume required).
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
42
Deployment Models
Unified CCE: Enterprise Unified CCE PG
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
43
Deployment Models
IPT: Multisite with Centralized Call Processing
both associated with the same peripheral. In some of the more complex scenarios to be discussed in later
sections, the routing client and peripheral target are not the same.
If a target agent is not available to receive the transferred call, the Call Routing script is typically configured
to transfer the call to an IVR so that queue treatment can be provided. In this scenario, the logic in the Unified
CCE System PG differs from the logic in the Unified CCE PG if the IP-IVR variant is used.
In both cases, the label is a dialed number that instructs Unified CM to transfer the call to an IVR. The
translation-route or correlationID is not needed when using the Unified CCE System peripheral but is needed
when deploying Unified CVP.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
44
Deployment Models
IPT: Centralized Voice Gateways
The following figure illustrates this model using a Unified CCE deployment. The figure shows the deployment
using IP-IVR, but it can also use Unified CVP instead of IP-IVR.
Figure 15: Multisite Deployment with Centralized Call Processing and Centralized Voice Gateways
Advantages
• Only a small data switch and router, IP phones, and agent desktops are needed at remote sites where
only a few agents exist. Only limited system and network management skills are required at remote
sites.
• No PSTN trunks are required directly into these small remote sites and offices, except for local POTS
lines for emergency services (911) in the event of a loss of the WAN link.
• PSTN trunks are used more efficiently because the trunks for small remote sites are aggregated.
• Unified CCE Queue Points (Unified IP IVR or Unified CVP) are used more efficiently because all Queue
Points are aggregated.
• No VoIP WAN bandwidth is used while calls are queuing (initially or subsequently). Calls are extended
over the WAN only when there is an agent available for the caller.
As with the single-site deployment model, all the same options exist when using Unified CCE configurations.
For example, multisite deployments can run the Unified CCE software all on the same server or on multiple
servers. The Unified CCE software can be deployed either with the Unified CCE System PG or the Unified
CCE PG. The number of Unified CM and Unified IP IVR or Unified CVP servers is not specified by the
deployment model, nor are the LAN/WAN infrastructure, Voice Gateways, or PSTN connectivity. For other
variations, see IPT: Single Site.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
45
Deployment Models
IVR: Treatment and Queuing with Unified IP IVR
Best Practices
• VoIP WAN connectivity is required for RTP traffic to agent phones at remote sites.
• RTP traffic to agent phones at remote sites might require compression to reduce VoIP WAN bandwidth
usage. It may be desirable for calls within a site to be uncompressed, so transcoding might also be
required depending on how the Cisco Unified Communications deployment is designed.
• Skinny Client Control Protocol (SCCP) or SIP call control traffic from IP phones to the Unified CM
cluster flows over the WAN.
• CTI data to and from the Unified CCE Agent Desktop flows over the WAN. Adequate bandwidth and
QoS provisioning are critical for these links.
• Because there are no Voice Gateways at the remote sites, customers might be required to dial a
long-distance number to reach what is normally a local PSTN phone call if Voice Gateways with trunks
were present at the remote site. This situation is mitigated if the business requirements are to dial toll-
free numbers at the central site. An alternative is to offer customers a toll-free number to dial and have
those calls all routed to the centralized Voice Gateway location. However, this requires the call center
to incur toll-free charges that can be avoided if customers had a local PSTN number to dial.
• The lack of local Voice Gateways with local PSTN trunks can also impact access to 911 emergency
services; this must be managed through the Unified CM dial plan. In most cases, local trunks are
configured to dial out locally and for 911 emergency calls.
• Unified CM location-based call admission control failure results in a routed call being disconnected.
Therefore, it is important to provision adequate bandwidth to the remote sites. Also, an appropriately
designed QoS WAN is critical.
Note For calls controlled by Unified CVP, call admission control failures can be recovered
with the proper Unified CCE Scripting configuration with the Unified CCE Router
Re-query feature enabled.
• Automated Alternate Routing (AAR) provides a mechanism to reroute calls through the PSTN or other
network by using an alternate number when Unified CM blocks a call due to insufficient location
bandwidth. For deployments with Unified CVP ingress call control, do not enable AAR. This allows
Unified CVP Router Re-query to take control of the call in the event of a failure or timeout. For
deployments using IP-IVR, enable AAR to route the call through the PSTN or other network component
using an alternative number.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
46
Deployment Models
Unified CCE: Transfers
Figure 16: Multisite Deployment with Centralized Call Processing and Distributed Voice Gateways
In this deployment model, shown with Unified IP IVR for queuing and treatment, it might be desirable to
restrict calls arriving at a site to be handled by an agent within that site, but this is not required. By restricting
calls to the site where it arrived, the following conditions apply:
• VoIP WAN bandwidth is reduced for calls going to agents from the ingress Voice Gateway.
• Calls still cross the VoIP WAN during the time they are in a queue or are receiving treatment from the
centralized Unified IP IVRs.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
47
Deployment Models
IPT: Distributed Voice Gateways
• Customer service levels for calls arriving into that site might suffer due to longer queue times and
handling times.
• Longer queue times can occur because even though an agent at another site is available, the Unified
CCE configuration may continue to queue for an agent at the local site.
• Longer handling times can occur because even though a more qualified agent exists at another site, the
call may be routed to a local agent to reduce WAN bandwidth usage.
To restrict a call to the site at which it arrived in this deployment model, you must create separate skill groups
for agents at each location. To route a call to any agent in a given skill group regardless of location, you can
use an enterprise skill group to combine the location-specific skill groups.
When using Precision Routing, to target agents which are local to a particular site you can use a location based
attribute within a Precision Queue (as opposed to using location specific skill groups).
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. For example, 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, while another customer may be restricted
to an agent within the site where the call arrived.
A Unified CCE deployment may actually use a combination of centralized and distributed Voice Gateways.
The centralized Voice Gateways can be connected to one PSTN carrier providing toll-free services, while the
distributed Voice Gateways can be connected to another PSTN carrier providing local phone services.
Inbound calls from the local PSTN can be both direct inward dial (DID) and contact center calls. It is important
to understand the requirements for all inbound and outbound calling to determine the most efficient location
for Voice Gateways. Important details include identifying who is calling, why they are calling, where they
are calling from, and how they are calling.
Traditional Pre-routing
In a traditional deployment with Unified ICM (parent and child or hybrid) with multisite deployments and
distributed Voice Gateways, the Unified ICM pre-routing capability can also be used to load-balance calls
dynamically across the multiple sites. For a list of PSTN carriers that offer Unified ICM pre-routing services,
see the Pre-installation Planning Guide for Cisco ICM Enterprise & Hosted Editions.
In multisite environments in which Voice Gateways have both local PSTN trunks and separate toll-free trunks
that deliver contact center calls, the Unified ICM pre-routing software can load-balance the toll-free contact
center calls around the local contact center calls. For example, suppose you have a two-site deployment where
Site 1 currently has all agents busy and there are many locally-originating calls in the queue. Site 2 has only
a few calls in the queue or maybe even a few agents are currently available. In this scenario, configure the
Unified ICM to instruct the toll-free provider to route most or all of the toll-free calls to Site 2. This type of
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
48
Deployment Models
IPT: Distributed Voice Gateways
multisite load balancing provided by Unified ICM is dynamic and automatically adjusts as call volumes change
at all sites.
Just as in the two previous deployment models, much variation exists in the number and types of Unified
ICM/CCE, Unified CM, and Unified IP IVR or Unified CVP servers, LAN/WAN infrastructure, Voice
Gateways, PSTN connectivity, and so forth.
Best Practices
• The Unified IP IVR or Unified CVP, Unified CM and PGs (for both Unified CM and IVR or Unified
CVP) are co-located. In this model, the only Unified CCE communications that can be separated across
a WAN are the following:
◦Unified Central Controller to PG
◦PG to Unified CCE Agent Desktops
◦Unified CM to Voice Gateways
◦Unified CM to phones
◦Unified CVP Call Control Server to remote Voice Gateway (call control)
• If calls are not going to be restricted to the site where calls arrive, or if calls are made between sites,
more RTP traffic flows across the WAN. It is important to determine the maximum number of calls that
flow between sites or locations. Unified CM locations-based call admission control failure results in a
routed call being disconnected (rerouting within Unified CM is not currently supported). Therefore, it
is important to provision adequate bandwidth to the remote sites, and appropriately designed QoS for
the WAN is critical. Calls that are treated by IP IVR at the central site must also be considered.
Note For calls controlled by Unified CVP, call admission control failures can be recovered
with the proper Unified CCE Scripting configuration with the Unified CCE Router
Re-query feature enabled.
• H.323, SIP, or MGCP signaling traffic between the Voice Gateways and the centralized Unified CM
servers flows over the WAN. Proper QoS implementation on the WAN is critical and signaling delays
must be within tolerances listed in the latest version of the Cisco Unified Communications System Solution
Reference Network Design (SRND) Guide at http://www.cisco.com/en/US/docs/voice_ip_comm/
uc_system/design/guides/UCgoList.html.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
49
Deployment Models
Unified CCE: Unified CCE System PG
Unified CCE & IVR: Treatment and Queuing with Unified IP IVR
WAN bandwidth must be provisioned to support all calls that are treated and queued at the central site.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
50
Deployment Models
Unified CCE: Transfers
Unified CCE: Distributed Voice Gateways with Treatment and Queuing Using
Unified IP IVR
This deployment model is a good choice if the company has multiple medium to large sites. In this model,
Voice Gateways with PSTN trunks terminate into each site. Just as in the centralized call processing model
with distributed Voice Gateways, it might be desirable to limit the routing of calls to agents within the site
where the call arrived (to reduce WAN bandwidth). An analysis of benefits from customer service levels
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
51
Deployment Models
Unified CCE: Distributed Voice Gateways with Treatment and Queuing Using Unified IP IVR
versus WAN costs is required to determine whether limiting calls within a site is appropriate. The following
figure illustrates this model using a traditional Unified CCE deployment with the Unified CCE System PG.
Figure 17: Multisite Deployment with Distributed Call Processing and Distributed Voice Gateways with Unified IP IVR
As with the previous models, many options are possible. The number and type of Unified CCE Servers,
Unified CM servers, and Unified IP IVR servers can vary. The LAN and WAN infrastructure, Voice Gateways,
PSTN trunks, redundancy, and so forth are also variable within this deployment model. Central processing
and gateways may be added for self-service, toll-free calls and support for smaller sites. In addition, the use
of a pre-routing PSTN Network Interface Controller (NIC) is also an option.
Advantages
• Scalability — Each independent site can scale up to the maximum number of supported agents per
Unified CM cluster and there is no software limit to the number of sites that can be combined by the
Unified CCE Central Controller to produce a single enterprise-wide contact center (provided that the
total concurrent agent count is less than the maximum supported agent count in a Unified CCE System).
For scalability and sizing information, see the chapter on Sizing Contact Center Resources.
• All or most VoIP traffic can be contained within the LAN of each site, if desired. The VoIP WAN shown
in Figure 18 is required for voice calls to be transferred across sites. Use of a PSTN transfer service (for
example, Take Back and Transfer or Transfer Connect) can eliminate that need. If desired, a small portion
of calls arriving at a particular site can be queued for agent resources at other sites to improve customer
service levels.
• Unified ICM/CCE pre-routing can be used to load-balance calls (based on agent or Unified IP IVR port
availability) to the best site to reduce WAN usage for VoIP traffic.
• Failure at any one site has no impact on operations at another site.
• Each site can be sized according to the requirements for that site.
• The Unified CCE Central Controller provides centralized management for configuration of routing for
all calls within the enterprise.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
52
Deployment Models
Treatment and Queuing
• The Unified CCE Central Controller provides the capability to create a single enterprise-wide queue.
• The Unified CCE Central Controller provides consolidated reporting for all sites.
Best Practices
• The PG, Unified CM cluster, and Unified IP IVR must be co-located at the contact center site.
• The communication link from the Unified CCE Central Controller to the PG must be sized properly and
provisioned for bandwidth and QoS. (For details, see the chapter Bandwidth Provisioning and QoS
Considerations.)
• Gatekeeper-based or RSVP Agent-based call admission control can be used to reroute calls between
sites over the PSTN when WAN bandwidth is not available. It is best to ensure that adequate WAN
bandwidth exists between sites for the maximum amount of calling that can occur.
• If the communication link between the PG and the Unified CCE Central Controller is lost, then all contact
center routing for calls at that site is also lost. Therefore, it is important to implement a fault-tolerant
WAN. Even when a fault-tolerant WAN is implemented, it is important to identify contingency plans
for call treatment and routing when communication is lost between the Unified CCE Central Controller
and PG. For example, in the event of a lost Unified CCE Central Controller connection, the Unified CM
CTI route points send the calls to Unified IP IVR ports to provide basic announcement treatment or to
invoke a PSTN transfer to another site. Another alternative is for the Unified CM cluster to route the
call to another Unified CM cluster that has a PG with an active connection to the Unified CCE Central
Controller. For more information about these options, see the Design Considerations for High Availability
chapter.
• While two inter-cluster call legs for the same call do not cause unnecessary RTP streams, two separate
call signaling control paths remain intact between the two clusters (producing logical hair-pinning and
reducing the number of inter-cluster trunks by two). Consider the percentage of inter-site transfers when
sizing inter-cluster trunks capacities.
• Latency between Unified CCE Central Controllers and remote PGs cannot exceed 200 ms one way (400
ms round-trip).
Transfers
Transfers within a site function just like a single-site transfer. Transfers between Unified CM clusters use
either the VoIP WAN or a PSTN service.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
53
Deployment Models
Unified CCE: Unified CCE System PG
If the VoIP WAN is used, sufficient inter-cluster trunks must be configured. An alternative to using the VoIP
WAN for routing calls between sites is to use a PSTN transfer service. These services allow the Unified CCE
Voice Gateways to out-pulse DTMF tones to instruct the PSTN to reroute (transfer) the call to another Voice
Gateway location. Another alternative is to have the Unified CM cluster at Site 1 make an outbound call back
to the PSTN. The PSTN then routes the call to Site 2, but the call uses two Voice Gateway ports at Site 1 for
the remainder of the call.
Alternative: Parent/Child
The Unified ICM Enterprise (parent) and Unified CCE (child) model is an appropriate alternative deployment
to provide local, distributed call processing with a local Unified CM and Unified CCE at each site (child),
controlled under a centralized Unified ICM Enterprise parent for enterprise-wide routing, reporting, and call
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
54
Deployment Models
Alternative: Parent/Child
control. This model has the advantage of being more tolerant of WAN outages and each site is survivable.
The following figure shows this same model deployed using the parent/child model.
Figure 18: Multisite Deployment with Distributed Call Processing and Parent/Child
In this design, there is a parent Unified ICM Enterprise system deployed with Unified CVP and its own
Administration & Data server. At each distributed site, there is a complete Unified CCE deployment consisting
of Central Controller on one or more servers. There is also a local Administration & Data Server for Unified
CCE to perform configuration, scripting, and reporting tasks for that specific site. There is a Unified CCE
Gateway PG that connects Unified CCE to the Unified ICM parent and it is part of the Peripheral Gateways
deployed on the parent Unified ICM.
An optional deployment for the Unified CCE Gateway PG is to co-locate it with the Unified CCE System
PG, while adhering to the following guidelines:
• If the Unified CCE Gateway PG and Unified CCE System PG Instance Numbers are the same, then the
PG number for the Unified CCE Gateway PG and Unified CCE System PG must be different.
• If the Unified CCE Gateway PG and Unified CCE System PG Instance Numbers are different, then the
PG number for the Unified CCE Gateway PG and the Unified CCE System PG may be the same.
• No additional PGs (such as a VRU PG or MR PG) can be added to this Server.
• For scalability limits of the co-resident Unified CCE Gateway PG and Unified CCE System PG.
In this design, the local Unified CCE deployments act as their own local IP ACDs with no visibility to any
of the other sites in the system. Users at Site 1 cannot see any of the calls or reports from Site 2 in this model.
Only the Unified ICM Enterprise parent system has visibility to all activity at all sites connected to the Unified
ICM Enterprise system.
The Unified CVP at the Unified ICM parent site is used to control the calls coming into the distributed sites
providing local call queuing and treatment in the VoiceXML Browser in the Voice Gateway. When configuring
the Unified ICM parent CVP to use Unified CVP Router Re-query to take control of the call if a failure or
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
55
Deployment Models
Alternative: Parent/Child
answer timeout, the child Unified CCE cannot terminate the ingress call to a child Unified CVP or a child
Unified IP IVR. The local Unified IP IVR servers are used only for a local backup if the connection from
these Voice Gateways is lost to the parent Unified CVP Server. The local Unified IP IVR also provides local
queue treatment for calls that are not answered by the local agents (RONA) rather than returning the call to
the Unified CVP to be re-queued.
The child Unified CCE deployments can also transfer calls across the system between the sites using Unified
ICM post-routing by the Unified CCE Gateway PG. The Unified CCE Gateway PG allows the child Unified
CCE to ask the Unified ICM to transfer a call to the best agent at another site or to queue it centrally for the
next available agent.
Unlike traditional Unified CCE models with distributed Unified CM Peripheral Gateways, the parent/child
model provides for complete local redundancy at the contact center site. The local Unified CCE takes over
call processing for inbound calls from the Unified CVP gateways and provide local call queuing and treatment
in the local Unified IP IVR. This design works well for call center sites that require complete redundancy or
100% up-time and that cannot be down because of a WAN failure.
This design is a good approach for customers who have Unified ICM already installed with their TDM ACD
platforms and who want either to add new sites with Unified CCE or to convert an existing site to Unified
CCE. It allows the Unified ICM to continue performing enterprise-wide routing and reporting across all the
sites while inserting new Unified CCE technology on a site-by-site basis.
Note Unified CVP can be at both the parent and child. This deployment is similar to Unified CVP at the parent
and Unified IP VR at the child from a call flow perspective. One key difference is that information about
queued calls at the child Unified CVP are not available at the parent (through the Unified CCE Gateway
PG), as is the case if Unified IP IVR is used. This difference means that minimum expected delay (MED)
over services cannot be used.
Advantages
• Unified CVP provides a virtual network queue across all the distributed sites controlled by the parent
Unified ICM. The parent Unified ICM has visibility into all the distributed sites and sends the call to
the next available agent from the virtual queue.
• Each distributed site can scale up to the maximum number of supported agents on a single Unified CCE
deployment. Multiple Unified CCE Central Controllers can be connected to a single Unified CM cluster
to scale up to the maximum number of supported agents per cluster. The Unified CCE systems are
connected to the parent Unified ICM using the Unified CCE Gateway PG on the parent Unified ICM,
which can scale up to the maximum number of supported agents per parent Unified ICM Enterprise
system.
• All or most VoIP traffic can be contained within the LAN of each site, if desired. The QoS WAN shown
in Figure 19 is required for voice calls to be transferred across sites. Use of a PSTN transfer service (for
example, Take Back and Transfer or Transfer Connect) eliminates that need. If desired, a small portion
of calls arriving at a particular site can be queued for agent resources at other sites to improve customer
service levels.
• Unified ICM pre-routing can be used to load-balance calls based on agent or Unified CVP session
availability and to route calls to the best site to reduce WAN usage for VoIP traffic.
• Failure at any one site has no impact on operations at another site.
• Each site can be sized according to the requirements for that site
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
56
Deployment Models
IVR: Distributed Voice Gateways with Treatment and Queuing Using Unified CVP
• The parent Unified ICM Central Controller provides centralized management for configuration of routing
for all calls within the enterprise.
• The parent Unified ICM Central Controller provides the capability to create a single enterprise-wide
queue.
• The parent Unified ICM Central Controller provides consolidated reporting for all sites.
Disadvantages
Server count — The number of servers that are required to manage the parent/child model is higher due to
the increased number of software components (extra Unified CCE Gateway PGs required if co-locating with
Unified CCE System PG is not an option, extra Central Controller for each child, and so forth).
Design Considerations
• Co-locate the Unified CCE Gateway PG, Unified Communications Manager cluster, Unified IP IVR,
and Unified CCE (if possible) at the contact center site.
• The communication link from the parent Unified ICM Central Controller to the Unified CCE Gateway
PG must be sized properly and provisioned for bandwidth and QoS.
• Gatekeeper-based or RSVP agent-based call admission control is used to reroute calls between sites
over the PSTN when WAN bandwidth is not available. It is best to ensure that adequate WAN bandwidth
exists between sites for the maximum amount of calling that can occur.
• If the communication link between the Unified CCE Gateway PG and the parent Unified ICM Central
Controller is lost, then all contact center routing for calls at that site is put under control of the local
Unified CCE. Unified CVP-controlled ingress Voice Gateways have survivability TCL scripts to redirect
inbound calls to local Unified Communications Manager CTI route points and the local Unified IP IVR
are used to handle local queuing and treatment during the WAN outage. This feature of the parent/child
model provides complete local survivability for the call center.
• While two inter-cluster call legs for the same call do not cause unnecessary RTP streams, two separate
call signaling control paths remain intact between the two clusters (producing logical hair-pinning and
reducing the number of inter-cluster trunks by two). Consider the percentage of inter-site transfers when
sizing inter-cluster trunks capacities.
• Latency between parent Unified ICM Central Controllers and remote Unified CCE Gateway PGs must
not exceed 200 ms one way (400-ms round-trip).
IVR: Distributed Voice Gateways with Treatment and Queuing Using Unified
CVP
This deployment model is the same as the previous model, except that Unified CVP is used instead of Unified
IP IVR for call treatment and queuing. In this model, Voice Gateways with PSTN trunks terminate into each
site. Just as in the centralized call processing model with distributed Voice Gateways, it might be desirable
to limit the routing of calls to agents within the site where the call arrived (to reduce WAN bandwidth). Call
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
57
Deployment Models
IVR: Distributed Voice Gateways with Treatment and Queuing Using Unified CVP
treatment and queuing can also be achieved at the site where the call arrived, further reducing the WAN
bandwidth needs. Figure 20 illustrates this model using a traditional Unified CCE deployment.
Figure 19: Multisite Deployment with Distributed Call Processing and Distributed Voice Gateways with Unified CVP
As with the previous models, many options are possible. The number and type of Unified CCE Servers,
Unified CM servers, and Unified CVP servers can vary. The LAN and WAN infrastructure, Voice Gateways,
PSTN trunks, redundancy, and so forth are also variable within this deployment model. Central processing
and gateways may be added for self-service, toll-free calls and support for smaller sites. The use of a pre-routing
PSTN Network Interface Controller (NIC) is also an option.
Advantages
• Unified CVP Servers can be located either centrally or remotely. Call treatment and queuing is still
distributed, executing on the local gateway, regardless of Unified CVP server location. Unified CVP is
shown centrally located in Figure 20.
• For information about the number of agents supported per PG and across the entire system, see Sizing
Unified CCE Components and Servers, on page 281.
• All or most VoIP traffic can be contained within the LAN of each site, if desired. The QoS WAN are
required for voice calls to be transferred across sites. Use of a PSTN transfer service (for example,
Takeback N Transfer) eliminates that need. If desired, a small portion of calls arriving at a particular
site can be queued for agent resources at other sites to improve customer service levels.
• Unified CCE pre-routing can be used to load-balance calls and route them to the best site to reduce WAN
usage for VoIP traffic.
• Failure at any one site has no impact on operations at another site.
• Each site can be sized according to the requirements for that site.
• The Unified CCE Central Controller provides centralized management for configuration of routing for
all calls within the enterprise.
• The Unified CCE Central Controller provides the capability to create a single enterprise-wide queue.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
58
Deployment Models
IVR: Treatment and Queuing
• The Unified CCE Central Controller provides consolidated reporting for all sites.
Best Practices
• The Unified CM PG and Unified CM cluster must be co-located. The Unified CVP PG and Unified
CVP servers must be co-located.
• The communication link from the Unified CCE Central Controller to PG must be properly sized and
provisioned for bandwidth and QoS. A tool is accessible to Cisco partners and Cisco employees for
computing the bandwidth needed between the Unified CCE Central Controller and the VRU Peripheral
Gateway. This tool is called the VRU Peripheral Gateway to Unified CCE Central Controller Bandwidth
Calculator, and it is also available through the Steps to Success Portal.
• If the communication link between the PG and the Unified CCE Central Controller is lost, then all contact
center routing for calls at that site is lost. Therefore, it is important to implement a fault-tolerant WAN.
Even when a fault-tolerant WAN is implemented, it is important to identify contingency plans for call
treatment and routing when communication is lost between the Unified CCE Central Controller and PG.
• Latency between Unified CCE Central Controllers and remote PGs must not exceed 200 ms one way
(400 ms round-trip)
Transfers
Transfers within a site function just like a single-site transfer. Transfers between Unified CM clusters use
either the VoIP WAN or a PSTN service.
If the VoIP WAN is used, sufficient inter-cluster trunks must be configured. An alternative to using the VoIP
WAN for routing calls between sites is to use a PSTN transfer service. These services allow the Unified CCE
Voice Gateways to out-pulse DTMF tones to instruct the PSTN to reroute (transfer) the call to another Voice
Gateway location. Another alternative is to have the Unified CM cluster at Site 1 make an outbound call back
to the PSTN. The PSTN then routes the call to Site 2, but the call uses two Voice Gateway ports at Site 1 for
the remainder of the call.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
59
Deployment Models
Unified CCE: Unified CCE PG
Unified CCE: Distributed Unified CCE Option with Distributed Call Processing
Model
Figure 21 illustrates this deployment model.
Figure 20: Distributed Unified CCE Option Shown with Unified IP IVR
Advantages
The primary advantage of the distributed Unified CCE option is the redundancy gained from splitting the
Unified CCE Central Controller between two redundant sites.
Best Practices
• Unified CCE Central Controllers (Routers and Loggers) require a separate network path or link to carry
the private communications between the two redundant sites. In a non-distributed Unified CCE model,
the private traffic usually traverses an Ethernet crossover cable or LAN connected directly between the
Side A and Side B Unified CCE Central Controller components. In the distributed Unified CCE model,
the private communications between the A and B Unified CCE components travel across a dedicated
link with at least as much bandwidth as a T1 line.
• Latency across the private separate link must not exceed 100 ms one way (200 ms round-trip), but 50
ms (100 ms round-trip) is preferred.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
60
Deployment Models
IPT: Clustering Over the WAN
• Latency between Unified CCE Central Controllers and remote PGs must not exceed 200 ms one way
(400 ms round-trip).
• The private link cannot traverse the same path as public traffic. The private link must have path diversity
and must reside on a link that is completely path-independent from Unified CCE public traffic. This link
is used as part of the system fault tolerant design. For more information, see Design Considerations for
High Availability.
• The redundant centralized model is explored in the next section on IPT Clustering over the WAN.
Advantages
• No single point of failure, including loss of an entire central site.
• Cisco Unified Mobile Agents (Remote Agent) require no reconfiguration to remain fully operational in
case of site or link outage. When outages occur, agents and agent devices dynamically switch to the
redundant site.
• Central administration for both Unified CCE and Unified CM.
• Reduction of servers for distributed deployment.
Best Practices
• Deploy a minimum of three WAN links for systems that employ the clustered over the WAN model.
Deploy at least two links for the high-availability network that carries the Unified CCE public traffic
(see Figure 22). Use a separate WAN link for the Unified CCE private traffic (see Figure 23). If QoS
and bandwidth are configured correctly (see the guidelines in the Bandwidth Provisioning and QoS
Considerations chapter), these WAN links can be converged with other corporate traffic as long as the
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
61
Deployment Models
IPT: Clustering Over the WAN
private and public traffic are not carried over the same link. Carry the Unified CM ICCS traffic over the
high-availability network used by the Unified CCE public communications.
Figure 21: High-Availability WAN Network for the Unified CCE Public Traffic
Figure 22: Separate WAN Link for Unified CCE Private Traffic
• It is possible to deploy Unified CCE clustering over the WAN with two links, if the following rules are
applied:
◦During normal operations, the Unified CCE public and private traffic must be carried over separate
links; they must not be carried over the same link.
◦Carry the Unified CM traffic over the Unified CCE public link in normal conditions (see Figure
24).
◦Two routers are required on each side of the WAN for redundancy; connect these to different WAN
links.
• In case of network failure, configure the WAN link that carries the Unified CCE public traffic to fail-over
to the other link that carries the Unified CCE private traffic (see Figure 25). Temporarily allow the
Unified CM ICCS traffic to fail-over to the private link. This prevents situations where a CTI Manager
that connects to the active Agent PG loses its WAN connection to the Unified CM node to which the
agent phones are registered. Restore the link as fast as possible so that the public and private Unified
CCE traffic are carried over separate links. If the redundant link that carries the Unified CCE private
traffic also fails, Unified CCE instability and data loss can occur, including the corruption of one Logger
database. Manual intervention may be required. This is why it is very important to actively monitor any
network failure at all times.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
62
Deployment Models
IPT: Clustering Over the WAN
The links must also be sized correctly to accommodate this fail-over situation where the private link
carries the entire WAN traffic, including the public and ICCS traffic. QoS and bandwidth must be
configured according to the guidelines in the Bandwidth Provisioning and QoS Considerations chapter.
Figure 24: Network Architecture After Failure of the Unified CCE Public Network
• It is also possible to allow the private link to fail-over to the public link. However, if the total fail-over
latency takes more than 500 ms (five times the TCP keep alive interval of 100 ms), the Unified CCE
system considers the private link to be down. If the public link is also down, Unified CCE instability
and data loss can occur, including the corruption of one Logger database. Manual intervention is required.
The total fail-over latency typically includes the round-trip transmission latency, the routing protocol
convergence delay, the HSRP convergence delay (if applicable), queuing and packetization delays, and
any other delay that is applicable. If the total fail-over latency is higher than 500 ms, or if you suspect
possible recurrent network flapping, deploy three WAN links and keeping the private traffic separate
from the public traffic at all times. Also, the links must be sized correctly to accommodate this fail-over
situation where the public link carries the entire WAN traffic, including the private and ICCS traffic.
Restore the link as fast as possible so that the public and private Unified CCE traffic are carried over
separate links.
• If QoS and bandwidth are configured correctly (see the guidelines in the Bandwidth Provisioning and
QoS Considerations chapter for more details), these WAN links can be converged with other corporate
traffic.
• With a SONET fiber ring, which is highly resilient and has built-in redundancy, the public and private
traffic can be carried over the same SONET ring under normal operations or following a network fail-over.
A separate link for the private traffic is not required in this case. Also, two routers are required on each
side of the WAN for redundancy. Under normal operations, use one router for the Unified CCE public
traffic and use the other router for the Unified CCE private traffic. The other rules described in this
section also apply.
Figure 25: Network Architecture Based on a SONET Ring Under Normal Operations
• The high-availability (HA) WAN between the central sites must be fully redundant with no single point
of failure. (For information regarding site-to-site redundancy options, see the WAN infrastructure and
QoS design guides.) In case of partial failure of the high-availability WAN, the redundant link must be
capable of handling the full central-site load with all QoS parameters. For more information, see
Bandwidth Requirements for Unified CCE Clustering Over the WAN.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
63
Deployment Models
IPT: Clustering Over the WAN
• A high-availability (HA) WAN using point-to-point technology is best implemented across two separate
carriers, but this is not necessary when using a ring technology.
• Latency requirements across the high-availability (HA) WAN must meet the current Cisco Unified
Communications requirements for clustering over the WAN. Currently, a maximum latency of 40 ms
one way (80 ms round-trip) is allowed with Unified CM Release 6.1 or later releases. With prior versions
of Unified CM, the maximum latency is 20 ms one way. For full specifications, see the Unified
Communications System Solution Reference Network Design (SRND) Guide at http://www.cisco.com/
en/US/docs/voice_ip_comm/uc_system/design/guides/UCgoList.html.
• Unified CCE latency requirements can be met by conforming to Cisco Unified Communications
requirements. However, the bandwidth requirements for Unified CM intra-cluster communications differ
between Unified CCE and Cisco Unified Communications. For more information, see the section on
Bandwidth Requirements for Unified CCE Clustering Over the WAN.
• Bandwidth requirements across the high-availability (HA) WAN include bandwidth and QoS provisioning
for:
◦Unified CM intra-cluster communication signaling (ICCS)
◦Communications between Unified CCE Central Controllers
◦Communications between Unified CCE Central Controller and PG
◦Communications between CTI Object Server (CTI OS) and CTI Server, if using CTI OS
◦See Bandwidth Requirements for Unified CCE Clustering Over the WAN.
• Deploy separate dedicated links for Unified CCE private communications between Unified CCE Central
Controllers Side A and Side B and between PGs Side A and Side B to ensure path diversity. Path diversity
is required due to the architecture of Unified CCE. Without path diversity, the possibility of a dual
(public communication and private communication) failure exists. If a dual failure occurs even for a
moment, Unified CCE instability and data loss can occur, including the corruption of one Logger database.
The separate links for Unified CCE private communications can be converged with other corporate
traffic if QoS and bandwidth are configured correctly, but they cannot be converged with the Unified
CCE public traffic.
• The separate private links may be either two links (one for Central Controller private traffic and one for
Unified CM PG private traffic) or one converged link containing both Central Controller and PG private
traffic. See Site-to-Site Unified CCE Private Communications Options for more information.
• Separate paths must exist from agent sites to each central site. Both paths must be capable of handling
the full load of signaling, media and other traffic if one path fails. These paths may reside on the same
physical link from the agent site with a WAN technology such as Frame Relay using multiple permanent
virtual circuits (PVCs).
• The minimum cluster size using Unified IP IVR as the treatment and queuing platform is five nodes
(publisher plus four subscribers). This minimum is required to allow Unified IP IVR at each site to have
redundant connections locally to the cluster without traversing the WAN. JTAPI connectivity between
Unified CM and Unified IP IVR is not supported across the WAN in this model. Local gateways also
need local redundant connections to Unified CM.
• The minimum cluster size using Unified CVP as the treatment and queuing platform is three nodes
(publisher plus two subscribers). However, a deployment with five nodes is preferable, especially if
there are phones (either contact center or non-contact center) local to the central sites, central gateways,
or central media resources, which requires local fail-over capabilities.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
64
Deployment Models
IPT: Clustering Over the WAN
• In a deployment with clustering over the WAN, the VRU PG can connect to a local IP IVR or Unified
CVP or to a redundant IP IVR or Unified CVP across the WAN. For information about bandwidth
requirements, see the Bandwidth Provisioning and QoS Considerations chapter.
• In a deployment with clustering over the WAN, the Unified CM PG must be on the same LAN segment
with the CTI Manager to which it is connected.
• Cisco Finesse supports a WAN connection between the Cisco Finesse Server and the CTI Server. CTI
reconnect time is determined by a number of factors, including the number of configured agents, the
number of concurrent agents who are taking calls, the number of skill groups, and bandwidth. To
determine the bandwidth requirements for your specific deployment, review the Finesse Bandwidth
Calculator.
Any of the network connections shown as arrows in the following diagram can be over a LAN or WAN.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
65
Deployment Models
Centralized Voice Gateways with Centralized Call Treatment and Queuing Using Unified IP IVR
Figure 27: Centralized Voice Gateways with Centralized Call Treatment and Queuing Using Unified IP IVR
Advantages
• Component location and administration are centralized.
• Calls are treated and queued locally, eliminating the need for queuing across a WAN connection.
Best Practices
• WAN connections to agent sites must be provisioned with bandwidth for voice as well as control and
CTI. See Bandwidth Requirements for Unified CCE Clustering Over the WAN for more information.
• A local Voice Gateway might be needed at remote sites for local out-calling and 911. For more
information, see the Cisco Unified Communications Solution Reference Network Design (SRND) Guide
at http://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html.
• Central site outages include loss of half of the ingress gateways, assuming a balanced deployment.
Gateways and IVRs must be scaled to handle the full load in both sites if one site fails.
• Carrier call routing must be able to route calls to the alternate site in the case of a site or gateway loss.
Pre-routing may be used to balance the load, but it cannot prevent calls from being routed to a failed
central site. Pre-routing is best deployed only as a last resort.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
66
Deployment Models
Clustering Over the WAN with Unified CCE System PG
Figure 28: Centralized Voice Gateways with Centralized Call Treatment and Queuing Using Unified CVP
Advantages
• Component location and administration are centralized.
• Calls are treated and queued locally, eliminating the need for queuing across a WAN connection.
• There is less load on Unified CM because Unified CVP is the primary routing point. This allows higher
scalability per cluster compared to Unified IP IVR implementations. See the Sizing Unified CCE
Components and Servers chapter for more information.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
67
Deployment Models
Considerations for Clustering Over the WAN
Best Practices
• WAN connections to agent sites must be provisioned with bandwidth for voice as well as control and
CTI. See Bandwidth Requirements for Unified CCE Clustering Over the WAN for more information.
• A local Voice Gateway might be needed at remote sites for local out-calling and 911.
The following guidelines and considerations apply to deployments with clustering over the WAN:
• The network deployment supports high availability, converged Visible, and Private Networks. The
Unified ICM and Unified CCE Central Controller's Private traffic and Visible (Public) traffic are isolated
and converge on different edge devices.
• WAN considerations for communications between the two Data Centers may include a Multiprotocol
Label Switching (MPLS) backbone with VPN routing and forwarding table VRFs.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
68
Deployment Models
Considerations for Clustering Over the WAN
• Design the network to prevent any single points of failure. The visible network and private networks
need to converge on separate switches and routers before connecting to the WAN.
• Isolation of the private network is not required. Central Controllers and Unified CCE System PGs can
share a common private network path.
• Multiple private network paths can be provisioned. (Central Controllers and Unified CCE System PGs
have separate private networks.)
• Bandwidth must be guaranteed across the WAN for the private network path traffic and visible (public)
network traffic with appropriate traffic prioritization. For more information, see the Bandwidth
Provisioning and QoS Considerations chapter.
• Currently there is no bandwidth calculator for the private network bandwidth between the gateway and
system PG pairs because this has not been certified. For guidance, see the section on Bandwidth
Provisioning.
• A side-to-side private network of a duplexed Central Controller and PGs has a maximum one-way
latency of 100 ms, but 50 ms is preferred.
The underlying network infrastructure for LAN and WAN provisioning must meet all the above requirements.
Key factors are isolation of visible and private paths as well as critical low-latency and bandwidth, especially
on the private path. The isolated private networks for PGs and Central Controllers provide some degree of
independence from each other's private link failures. The more path and route diversity provisioned, the greater
the fault tolerance. For example, if the private network between the parent central controllers goes down, the
child central controllers can still continue to function in duplex mode.
MPLS Considerations
If an MPLS network can guarantee the route diversity, latency, and bandwidth; and if it is configured to
support label switch paths that route through independent topologies and hardware elements to meet the above
requirements, then the application works as designed. It is important to ensure that the route autonomy is not
compromised over time through adaptive change.
For additional information regarding best practices and high-availability deployments, see the section on IPT:
Clustering Over the WAN.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
69
Deployment Models
Distributed Voice Gateways with Distributed Call Treatment and Queuing Using Unified CVP
Figure 30: Distributed Voice Gateways with Distributed Call Treatment and Queuing Using Unified CVP
Advantages
• No or minimal voice RTP traffic across WAN links if ingress calls and gateways are provisioned to
support primarily their local agents. Transfers and conferences to other sites traverse the WAN.
• Calls are treated and queued at the agent site, eliminating the need for queuing across a WAN connection.
• Local calls incoming and outgoing, including 911, can share the local VoiceXML gateway.
• There is less load on Unified CM because Unified CVP is the primary routing point. This allows higher
scalability per cluster compared to Unified IP IVR implementations. See Sizing Unified CCE Components
and Servers for more information.
Best Practices
• Distributed gateways require minimal additional remote maintenance and administration over centralized
gateways.
• The media server for Unified CVP may be centrally located or located at the agent site. Media may also
be run from gateway flash. Locating the media Server At the agent site reduces bandwidth requirements
but adds to the server count and maintenance costs.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
70
Deployment Models
Site-to-Site Unified CCE Private Communications Options
Unified CCE Central Controller Private and Unified CM PG Private Across Dual
Links
Dual links separate Unified CCE Central Controller Private traffic from VRU/CM PG Private traffic.
Figure 31: Unified CCE Central Controller Private and Unified CM PG Private Across Dual Links
Advantages
• Failure of one link does not cause both the Unified CCE Central Controller and PG to enter simplex
mode, thus reducing the possibility of an outage due to a double failure.
• The QoS configuration is limited to two classifications across each link, therefore links are simpler to
configure and maintain.
• Resizing or alterations of the deployment model and call flow might affect only one link, thus reducing
the QoS and sizing changes needed to ensure proper functionality.
• Unanticipated changes to the call flow or configuration (including misconfiguration) are less likely to
cause issues across separate private links.
Best Practices
• Deploy separate links across separate dedicated circuits. The links, however, do not have to be redundant
and must not fail-over to each other.
• Link sizing and configuration must be examined before any major change to call load, call flow, or
deployment configuration.
• Make the link a dedicated circuit; not tunneled across the high-availability (HA) WAN. See Best Practices,
at the beginning of the section about IPT: Clustering Over the WAN for more information about path
diversity.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
71
Deployment Models
Unified CCE Central Controller Private and Unified CM PG Private Across Single Link
Figure 32: Unified CCE Central Controller Private and Unified CM PG Private Across a Single Link
Advantages
• Less costly than separate-link model.
• Fewer links to maintain, but is more complex.
Best Practices
• The link does not have to be redundant. If a redundant link is used, however, latency on fail-over must
not exceed 500 ms.
• Separate QoS classifications and reserved bandwidth are required for Central Controller high-priority
and PG high-priority communications. For details, see the Bandwidth Provisioning and QoS
Considerations chapter.
• Link sizing and configuration must be examined before any major change to call load, call flow, or
deployment configuration. This is especially important in the single-link model.
• Make the link a dedicated circuit fully isolated from, and not tunneled across, the high-availability (HA)
WAN. See Best Practices, at the beginning of the section on IPT: Clustering Over the WAN for more
information about path diversity.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
72
Deployment Models
Failure Analysis of Unified CCE Clustering Over the WAN
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
73
Deployment Models
Mobile Agent Over Broadband
The Cisco 830, 870, and 880 Series routers are examples of acceptable routers. Avoid using the Cisco 850
and 860 Series routers for this application because they have limited QoS feature support.
Advantages
• A mobile agent deployment results in money saved for a contact center enterprise, thereby increasing
return on investment (ROI).
• Mobile agents can be deployed with standard Unified CCE agent desktop applications such as Cisco
CTI OS, Cisco Agent Desktop, or customer relationship management (CRM) desktops.
• The Broadband Agent Desktop Always-on connection is a secure extension of the corporate LAN in
the home office.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
74
Deployment Models
Mobile Agent Over Broadband
• Mobile agents have access to the same Unified CCE applications and most Unified CCE features in their
home office as when they are working at the Unified CCE contact center and they can access those
features in exactly the same way.
• The mobile-agent router provides high-quality voice using IP phones with simultaneous data to the agent
desktop over existing broadband service.
• Unified CCE home agents and home family users can securely share broadband Cable and DSL
connections with authentication of Unified CCE corporate users providing access to the VPN tunnel.
• The mobile-agent routers can be managed centrally by the enterprise using a highly scalable and flexible
management product such as Cisco Unified Operations Manager.
• The mobile-agent-over-broadband solution is based on Cisco IOS VPN Routers for resiliency, high
availability, and a building-block approach to high scalability that can support thousands of home agents.
• All traffic, including data and voice, is encrypted with the Triple Data Encryption Standard (3DES).
• The remote-agent router can be deployed as part of an existing Unified CM installation.
• Mobile agents can have the same extension type as campus agents.
Best Practices
• Follow all applicable V3PN and Cisco Virtual Office design guidelines outlined in the documentation
available at http://cisco.com/go/cvo.
• Configure mobile agent IP phones to use g.729 with minimum bandwidth limits. Higher-quality voice
can be achieved with the g.711 codec. The minimum bandwidth to support g.711 is 512 kbps upload
speed.
• Implement fault and performance management tools such as NetFlow, Service Assurance Agent (SAA),
and Internetwork Performance Monitor (IPM).
• Wireless access points are supported; however, their use is determined by the enterprise security polices
for Mobile agents.
• Only one mobile agent per household is supported.
• Configure the conference bridge on a DSP hardware device. There is no loss of conference voice quality
using a DSP conference bridge. This is the preferred solution even for pure Cisco Unified Communications
deployments.
• The remote-agent-over-broadband solution is supported only with centralized Unified CCE and Unified
CM clusters.
• There might be times when the ADSL or Cable link goes down. When the link is back up, you might
have to reset your ADSL or Cable modem mobile agent router and IP phone. This task requires Mobile
agent training.
• Only unicast Music on Hold (MoH) streams are supported.
• There must be a Domain Name System (DNS) entry for the mobile agent desktop, otherwise the agent
cannot connect to a CTI server. DNS entries can be updated dynamically or entered as static updates.
• The mobile agent workstation and IP phone must be set up to use Dynamic Host Configuration Protocol
(DHCP).
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
75
Deployment Models
Mobile Agent Over Broadband
• The mobile agent workstation requires Windows 7 or Windows XP Pro for the operating system. For
Windows XP, XP Remote Desktop Control must also be installed.
• The Cisco Unified IP Phone requires a power supply if the remote-agent router does not have the Power
over Ethernet option.
• Mobile agent broadband bandwidth requires a minimum of 256 kbps upload speed and 1.4 Mbps download
speed for ADSL and 1 Mbps download for Cable. Before actual deployment, make sure that the bandwidth
is correct. If you are deploying Cable, take into account peak usage times. If link speeds fall below the
specified bandwidth, the home agent can encounter voice quality problems such as clipping.
• Mobile agent round-trip delay to the Unified CCE campus is not to exceed 180 ms for ADSL or 60 ms
for Cable. Longer delay times can result in voice jitter, conference bridge problems, and delayed agent
desktop screen pops.
• If the Music on Hold (MoH) server is not set up to stream using a g.729 codec, then a transcoder must
be set up to enable outside callers to receive MoH.
• CTI OS Supervisor home and campus supervisors can silently monitor, barge in, and intercept (but not
record) home agents. CTI OS home and campus supervisors can send and receive text messages, make
an agent ready, and log out home agents.
• Connect the agent desktop to the RJ45 port on the back of the IP phone. Otherwise, CTI OS Supervisor
cannot voice-monitor the agent phone.
• Only IP phones that are compatible with Cisco Unified CCE are supported. For compatibility information,
see the following documentation:
◦Hardware & System Software Specification (Bill of Materials) for Cisco Unified ICM/Contact
Center Enterprise & Hosted, Release 9.0(x)
◦Cisco Unified Contact Center Enterprise (Unified CCE) Software Compatibility Guide
◦Release Notes for Cisco Unified ICM/Contact Center Enterprise & Hosted, Release 8.0(1)
• You can find a test for the broadband line speed at http://broadbandreports.comBroadbandreports.com.
From this website, you can execute a test that benchmarks the home agent’s line speed (both upload and
download) from a test server.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
76
Deployment Models
Mobile Agent with Unified IP Phones Deployed by using the Cisco Virtual Office Solution
Mobile Agent with Unified IP Phones Deployed by using the Cisco Virtual
Office Solution
In this model, the mobile agent IP phone and workstation are connected by using the VPN tunnel to the main
Unified CCE campus. Customer calls routed to the mobile agent are handled in the same manner as campus
agents, as shown in Figure 33.
Figure 33: Mobile Agent with IP Phones Deployed via the Cisco Virtual Office Solution
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 including CTI data and high-quality voice.
Best Practices
• Minimum broadband speed supported is 256 kbps upload and 1.0 Mbps download for cable.
• Minimum broadband speed supported is 256 kbps upload and 1.4 Mbps download for ADSL.
• Agent workstation must have 500 MHz and 512 MB RAM or greater.
• IP phone must be configured to use g.729 on minimum broadband speeds.
• QoS is enabled only at the remote-agent router edge. Currently, service providers are not providing QoS.
• Enable security features on the remote-agent router.
• The Cisco 7200 VXR and Catalyst 6500 IPSec VPN Services Module (VPNSM) offer the best
LAN-to-LAN performance for agents.
• The mobile agent home phone must be used for 911 calls.
• Use Redirect-on-no-answer (RONA) when a mobile agent is logged in and ready but is unavailable to
pick up a call.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
77
Deployment Models
Traditional ACD Integration
Figure 34: Integrating a Traditional ACD with a Unified CCE Site Using a Hybrid Deployment and Pre-routing via PSTN
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
78
Deployment Models
Hybrid Deployment with Fixed PSTN Delivery
Figure 35: Integrating Unified CVP with a Traditional ACD and a Unified CCE Site Using a Hybrid Deployment and Unified
CVP
In this design, all calls first come to the Voice Gateway controlled by Unified CVP and they are then directed
by the Unified ICM/CCE Call Router. Unified ICM/CCE uses the PG connections to the TDM ACD and
Unified CCE PG to monitor for available agents. Calls are queued in Unified CVP until an agent becomes
available in either environment. When a call needs to be transferred to the TDM ACD, it hairpins in the Voice
Gateway (meaning that it comes into the gateway on a T1 interface from the PSTN carrier network and goes
out on a second physical T1 interface) to appear as a trunk on the TDM ACD. Most TDM ACDs are unable
to accept inbound calls in IP from the Voice Gateway and require this physical T1 interface connection.
Unified CCE agents receive their calls directly over the IP voice network.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
79
Deployment Models
Parent/Child Deployment
Parent/Child Deployment
The parent/child model is illustrated in the following figure.
Figure 36: Parent/Child Model for Integrating a Traditional ACD with a Unified CCE Site
In this model, the Unified ICM Enterprise parent has PGs connected to a Unified CCE (using System PG) at
one site (with a complete installation) and a second site with a TDM ACD that is using a Unified ICM TDM
ACD PG. In this model, Unified ICM still provides virtual enterprise-wide routing, call treatment, and queuing
with the distributed Unified CVP Voice Gateways at the sites. Unified ICM also has full visibility to all the
sites for agents and calls in progress. The difference in this model is that Unified CCE provides local
survivability. If it loses connection to the Unified ICM parent, the calls are still treated locally just as they are
at the TDM ACD site.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
80
Deployment Models
Using PBX Transfer
There are two versions of the IVR interface to Unified CCE. One is simply a post-routing interface (Call
Routing Interface or CRI), which just allows the IVR to send a post-route request with call data to Unified
CCE. Unified CCE returns a route response instructing the IVR to transfer the call elsewhere. In this scenario,
the traditional IVR invokes a PBX transfer to release its port and transfer the call into the Unified CCE
environment. Any call data passed from the IVR is passed by Unified CCE to the agent desktop or Unified
IP IVR.
The other IVR interface to Unified CCE is the Service Control Interface (SCI). The SCI enables the IVR to
receive queuing instructions from Unified CCE. In the PBX model, the SCI is not required.
Even if the IVR has the SCI interface, it is still preferable to deploy Unified CVP or Unified IP IVR for all
call queuing because this prevents any additional use of the traditional IVR ports. In addition, use of the
Unified IP IVR for queuing provides a way to re-queue calls on subsequent transfers or RONA treatment.
In this design, calls come first to the PBX from the PSTN carrier network on a standard T1 trunk interface.
The PBX typically uses a hunt group to transfer the call to the IVR, putting all of the IVR ports into the hunt
group as agents in auto available mode. The PBX looks like the PSTN to Unified CCE because it does not
have a PG connected to the PBX. Unified CCE cannot track the call from the original delivery to the IVR;
and it has reporting only from the time the call arrived at the IVR and the IVR informed Unified CCE of the
call.
When the caller opts out of the IVR application, the IVR sends a Post-Route to Unified CCE using the Call
Routing Interface (CRI). Because this application does not require calls to queue in the IVR, the CRI is the
preferred interface option. Unified CCE looks at the agent states across the system and select the agent to
send the call to (by using agent phone number or device target) or translation-route the call to the Unified IP
IVR for queuing.
When the call is sent to an agent or into queue, it is hair-pinned in the PBX, coming in from the PSTN on a
T1 trunk port and then going out to a Voice Gateway on a second T1 trunk port in the PBX. This connection
is used for the life of the call.
Alternatively, if you want to track the call from its entry at the PBX or if you need to capture the caller ANI
or original dialed number, you can install a PG on the PBX. The PBX can request (through a Post-Route to
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
81
Deployment Models
Using PSTN Transfer
Unified CCE) which IVR port to send the call to behind the PBX. The PBX cannot use a hunt group to deliver
the call from the PBX to the IVR. Unified CCE requires direct DNIS termination to ensure that the translation
route maintains the call data collected in the PBX and makes it available to the IVR.
In this model, the TDM IVR is set up as a farm of IVR platforms that have direct PSTN connections for
inbound calls. The IVR has a PG connection to Unified CCE which tracks all calls in the system. When a
caller opts out of the IVR treatment, the IVR sends a post-route request to Unified CCE which returns a label
that directs the call either to an agent or to the Unified IP IVR for queuing.
The label that is returned to the TDM IVR instructs it to send an in-band transfer command using transfer
tones (*8 with a destination label in the carrier network). The IVR out-pulses these tones to the service provider
with tone generation or plays the tones by using a recorded file.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
82
Deployment Models
Using Unified CM Transfer and IVR Double Trunking
Unlike the previous model, if the traditional IVR has a Service Control Interface (SCI), then the initial call
queuing is done on the traditional IVR. The reason this is beneficial is to queue the call on the Unified IP
IVR, a second traditional IVR port is used to transfer the call to the Unified IP IVR. By performing the initial
queuing on the traditional IVR, only one traditional IVR port is used during the initial queuing of the call.
However, any subsequent queuing as a result of transfers or RONA treatment must be done on the Unified
IP IVR to avoid any double trunking.
If the traditional IVR does not have an SCI interface, then the IVR just generates a post-route request to
Unified CCE to determine where the call is transferred. All queuing in that scenario has to be done on the
Unified IP IVR.
In this model, the TDM IVR is set up as a farm of IVR platforms that have direct PSTN connections for
inbound calls. The IVR has a PG connection to Unified CCE which tracks all calls in the system. When a
caller opts out of the IVR treatment, the IVR sends a post-route request to Unified CCE which returns a label
that either directs the call to an agent or queues the call locally on the TDM IVR using the Service Control
Interface (SCI). The transfer to the agent is done by the TDM IVR selecting a second port to hairpin the call
to the Voice Gateway and to the Unified CCE agent. This takes up two ports for the time the call is at the
agent.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
83
Deployment Models
Using Unified CM Transfer and IVR Double Trunking
Gateway port are used for the duration of the call. Ensure that transfer scenarios do not allow multiple loops
to be created because voice quality suffers.
Figure 40: Traditional IVR Integration Using Unified CM Transfer and IVR Double Trunking
In this model, the TDM IVR is front-ended by either Unified CVP using the Voice Gateway or the Unified
IP IVR and Unified CM with Unified CCE to determine the location to provide call treatment.
With Unified CVP, calls coming into the Voice Gateway immediately start a routing dialog with Unified CCE
using the Service Control Interface (SCI). Based on the initial dialed number or prompting in Unified CVP,
Unified CCE decides if the call needs to be sent to the TDM IVR for a specific self-service application or if
Unified CVP has the application available for the caller. If the call was sent to the TDM IVR, the TDM IVR
sends a route request to Unified CCE when the caller opts out. The reply is not sent back to the TDM IVR
but back to Unified CVP as the original routing client. Unified CVP then takes the call leg away from the
TDM IVR and transfers it to the Unified CCE agent over the VoIP network or holds it in a queue locally in
the Voice Gateway.
With Unified CM, calls coming into the Voice Gateway hit a CTI route point for Unified CM to send a route
request to Unified CCE to determine the appropriate call treatment device for the caller. If the CTI route point
indicated an application that still is on the TDM IVR, Unified CCE instructs Unified CM to transfer the call
to the TDM IVR by hairpinning the call using a second T1 port on the Voice Gateway to connect to the TDM
IVR. Unified CCE can also instruct Unified CM to translation-route the call to the Unified IP IVR for call
processing or prompting and then make a subsequent transfer to the TDM IVR for further processing. When
the caller opts out of the TDM IVR, it sends a post-route request to Unified CCE, and Unified CCE returns
a label to the TDM IVR. This label instructs the TDM IVR to transfer the call using a second T1 port on the
IVR and to pass the call back to the Voice Gateway and over to the Unified CCE agent under the Unified CM
dial plan.
In the model controlled by Unified CM, calls are initially received by the Voice Gateway and are hair-pinned
to the TDM IVR on a second T1 port. When the IVR sends the call back to the Unified CCE agent, it uses a
second TDM IVR port and a third port on the Voice Gateway. All three ports are used on the Voice Gateway
as long as the agent is talking with the caller and both of the TDM IVR ports are used for the duration of this
call.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
84
Deployment Models
Unified CCE/CCH: Integration with the Genesys Cisco T-Server
The deployment models listed in this document are supported for the integrated solution. See the Cisco Unified
Contact Center Enterprise (Unified CCE) Software Compatibility Guide.
Note the following deployment considerations:
• In an integrated Unified CCE/Genesys deployment, Cisco Unified CCE or Genesys Universal Routing
Server (URS) can perform enterprise level routing—but not both
• If Genesys URS is the enterprise routing engine, Unified CCE can only support IP-IVR as the local
queuing platform
• CVP as the queuing platform is only supported with Genesys in CTI/Desktop only mode
• If Unified CCE is the enterprise routing engine, the Genesys T-Server can only be used in a CTI/Desktop
only mode
• Genesys Agent Desktop cannot be used for Unified CCE Mobile Agents (only Cisco CTI OS Desktop
can be used)
• Cisco Outbound Option is not supported by any Unified CCE/Genesys integrated deployment
• Due to Unified CCE and Genesys having very different reporting architecture and terminology, the
reports from Unified CCE and Genesys should not be used for correlation purposes:
◦In case of Unified CCE routing (Genesys is CTI only), there is no impact to Unified CCE reporting
data
◦In case of Genesys routing, Genesys enterprise reporting is used
• For deployments leveraging Genesys routing, Unified CCE must be configured to provide backup routing
for the failure scenario where Unified CCE loses connectivity with the Genesys T-Server
• The Unified CCE configuration data is not synchronized with Genesys (both need to be configured
separately)
Note Current deployments cannot mix Genesys and CTI-OS desktops. CTI OS may be installed for backup
ACD functionality but cannot be operated concurrently.
• All standard Clustering across the WAN (COW) deployments are supported with the added caveat of
when the T-Servers are split across the WAN, or in the case of a single T-Server that can link to
CTI-Server Across the WAN, the Genesys T-Server deployment guidelines should be followed.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
85
Deployment Models
Unified CCE/CCH: Integration with the Genesys Cisco T-Server
• For all diagrams, Genesys Desktops can be exchanged with a CTI-OS desktop.
Figure 41: Unified CCE with Genesys CTI/Desktop Only - No Genesys Routing
Figure 42: Unified CCE Parent/Child with Genesys CTI/Desktop Only - No Genesys Routing
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
86
Deployment Models
Unified CCE/CCH: Integration with the Genesys Cisco T-Server
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
87
Deployment Models
Unified CCE/CCH: Integration with the Genesys Cisco T-Server
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
88
Deployment Models
Unified CCE/CCH: Integration with the Genesys Cisco T-Server
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
89
Deployment Models
Unified CCE/CCH: Integration with the Genesys Cisco T-Server
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
90
CHAPTER 3
Design Considerations for High Availability
Note Many of the design considerations and illustrations throughout this chapter have been revised and updated.
Review the entire chapter before designing a Unified CCE system.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
91
Design Considerations for High Availability
Designing for High Availability
and which design characteristics you choose for the various Unified CCE components (including the network
infrastructure). A good Unified CCE design tolerates most failures (defined later in this section); but not all
failures can be made transparent.
• Cisco Unified CCE is a solution designed for mission-critical contact centers. The successful design of
any Unified CCE deployment requires a team with experience in data and voice internetworking, system
administration, and Unified CCE application design and configuration.
• Simplex deployments are allowed for demo, laboratory, and non-production deployments. However, all
production deployments must be deployed with redundancy for the core Unified CCE components (Call
Routers, Loggers, PGs, and pre-routing gateways).
Before implementing Unified CCE, use careful preparation and design planning to avoid costly upgrades or
maintenance later in the deployment cycle. Always design for the worst possible failure scenario with future
scalability in mind for all Unified CCE sites.
In summary, plan ahead and follow all the design guidelines presented in this guide and in the Cisco Unified
Communications Solution Reference Network Design (SRND) Guide at http://www.cisco.com/en/US/products/
sw/voicesw/ps556/tsd_products_support_series_home.html.
For assistance in planning and designing your Unified CCE solution, consult your Cisco or certified Partner
Systems Engineer (SE).
The figure below shows a high-level design for a fault-tolerant Unified CCE single-site deployment.
In the figure above, each component in the Unified CCE solution is duplicated with a redundant or duplex
component, with the exception of the intermediate distribution frame (IDF) switches for the Unified CCE
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
92
Design Considerations for High Availability
Designing for High Availability
agents and their phones. The IDF switches do not interconnect with each other but only with the main
distribution frame (MDF) switches because it is better to distribute the agents among different IDF switches
for load balancing and geographic separation (such as different building floors or different cities). If an IDF
switch fails, route all calls to other available agents in a separate IDF switch or to a Unified IP IVR queue.
Follow the design guidelines for a single-site deployment as documented in the Cisco Unified Communications
Solution Reference Network Design (SRND) Guide at http://www.cisco.com/en/US/products/sw/voicesw/
ps556/tsd_products_support_series_home.html.
If designed correctly for high-availability and redundancy, a Unified CCE system can lose half of its core
component systems or servers and still be operational. With this type of design, no matter what happens in
the Unified CCE system, calls can still be handled in one of the following ways:
• Routed and answered by an available Unified CCE agent using an IP phone or desktop soft phone
• Sent to an available Unified IP IVR or Unified CVP port or session
• Answered by the Cisco Unified Communications Manager AutoAttendant or Hunt Group
• Prompted by a Unified IP IVR or Unified CVP announcement that the call center is currently experiencing
technical difficulties and to call back later
• Rerouted to another site with available agents or resources to handle the call
The components in the figure above can be rearranged to form two connected Unified CCE sites, as illustrated
in the figure below.
The figure above emphasizes the redundancy of the single site design in Figure 46. Side A and Side B are
basically mirror images of each other. In fact, one of the main Unified CCE features to enhance high-availability
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
93
Design Considerations for High Availability
Data Network Design Considerations
is its capability to add redundant or duplex components that are designed to automatically fail-over and recover
without any manual intervention. Core system components with redundant components are interconnected to
provide failure detection of the redundant system component with the use of TCP keep-alive messages generated
every 100 ms over a separate Private Network path. The fault-tolerant design and failure detection and recovery
method is described later in this chapter.
Other components in the solution use other types of redundancy strategies. For example, Cisco Unified
Communications Manager (Unified CM) uses a cluster design that provides IP phones and devices with
multiple Unified CM subscribers (servers) to register with when the primary server fails. The devices
automatically reconnect to the primary server when it is restored.
The following sections use Figure 46 as the model design to discuss issues and features to consider when
designing Unified CCE for high availability. These sections use a bottom-up model (from a network model
perspective, starting with the physical layer first) that divides the design into segments that can be deployed
in separate stages.
Use only duplex (redundant) Unified CM, Unified IP IVR or Unified CVP, and Unified CCE components for
all Unified CCE deployments. This chapter assumes that the Unified CCE fail-over feature is a critical
requirement for all deployments; therefore it presents only deployments that use a redundant configuration
with each Unified CM cluster having at least one publisher and one subscriber. Additionally, where possible,
deploy Unified CCE so that no devices, call processing, or CTI Manager Services are running on the Unified
CM publisher.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
94
Design Considerations for High Availability
Data Network Design Considerations
For more information about Voice Gateways and voice networks in general, see the Cisco Unified
Communications Solution Reference Network Design (SRND) Guide at http://www.cisco.com/en/US/products/
sw/voicesw/ps556/tsd_products_support_series_home.html.
Figure 48: High-availability in a Network with Two Voice Gateways and One Unified CM Cluster
The use of multiple Voice Gateways avoids the problem of a single gateway failure causing blockage of all
inbound and outgoing calls. In a configuration with two Voice Gateways and one Unified CM cluster, register
each gateway with a different primary Unified CM subscriber to spread the workload across the subscribers
in the cluster. Configure each gateway to use another subscriber as a backup in case its primary fails. For
details on setting up Unified CM for redundant service and redundancy groups related to call processing, see
the Cisco Unified Communications Solution Reference Network Design (SRND) Guide at http://www.cisco.com/
en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html.
With Cisco IOS Voice Gateways using H.323 or SIP, additional call processing is available by using TCL
scripts and additional dial peers if the gateway is unable to reach its Unified CM for call control or call
processing instructions. MGCP gateways do not have this built-in functionality and the trunks that are terminated
in these gateways require backup routing or "roll-over service" from the PSTN carrier or service provider to
reroute the trunk on failure or no-answer to another gateway or location.
As for sizing the gateway's trunk capacity, it is a good idea to account for fail-over of the gateways by building
in enough excess capacity to handle the maximum busy hour call attempts (BHCA) if one or more Voice
Gateways fail. During the design phase, first decide how many simultaneous Voice Gateway failures are
possible and acceptable for the site. Based on this requirement, the number of Voice Gateways used, and the
distribution of trunks across those Voice Gateways; you can determine the total number of trunks required
for normal and disaster modes of operation. The more you distribute the trunks over multiple Voice Gateways,
the fewer trunks you need in a failure mode. However, using more Voice Gateways or carrier PSTN trunks
increases the cost of the solution, so compare the cost with the benefits of being able to service calls in a
gateway failure. The form-factor of the gateway is also a consideration.
As an example, assume a contact center has a maximum BHCA that results in the need for four T1 lines and
the company has a requirement for no call blockage in the event of a single component (Voice Gateway)
failure. If two Voice Gateways are deployed, then provision each Voice Gateway with four T1 lines (a total
of eight). If three Voice Gateways are deployed, then two T1 lines per Voice Gateway (a total of six) are
enough to achieve the same level of redundancy. If five Voice Gateways are deployed, then one T1 per Voice
Gateway (a total of five) are enough to achieve the same level of redundancy. Thus, you can reduce the number
of T1 lines required by adding more Voice Gateways and spreading the risk over multiple physical devices.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
95
Design Considerations for High Availability
Data Network Design Considerations
The operational cost savings of fewer T1 lines might be greater than the one-time capital cost of the additional
Voice Gateways. In addition to the recurring operational costs of the T1 lines, also factor in the carrier charges
(like the typical one-time installation cost) of the T1 lines to ensure that your design accounts for the most
cost-effective solution. Every installation has different availability requirements and cost metrics, but using
multiple Voice Gateways is often more cost-effective. It is a worthwhile design practice to perform this cost
comparison.
After you have determined the number of trunks needed, the PSTN service provider has to configure them so
that calls can be terminated onto trunks connected to all of the Voice Gateways (or at least more than one
Voice Gateway). From the PSTN perspective, if the trunks going to the multiple Voice Gateways are configured
as a single large trunk group, then all calls are automatically routed to the surviving Voice Gateways when
one Voice Gateway fails. If all of the trunks are not grouped into a single trunk group within the PSTN, then
you must ensure that PSTN rerouting or overflow routing to the other trunk groups is configured for all dialed
numbers.
If a Voice Gateway with a digital interface (T1 or E1) fails, then the PSTN automatically stops sending calls
to that Voice Gateway because carrier level signaling on the digital circuit has dropped. The loss of carrier
level signaling on a digital circuit causes the PSTN to busy-out all trunks, thereby preventing the PSTN from
routing new calls to the failed Voice Gateway. When the failed Voice Gateway comes back on-line and the
circuits are back in operation, the PSTN automatically starts delivering calls to that Voice Gateway again.
With Cisco IOS Voice Gateways using H.323 or SIP, it is possible for the Voice Gateway itself to be operational
but for its communication paths to the Unified CM servers to be severed (for example, a failed Ethernet
connection). If this situation occurs, you can use the busyout-monitor interface command to monitor the
Ethernet interfaces on a Voice Gateway. To place a voice port into a busyout monitor state, use the
busyout-monitor interface voice-port configuration command. To remove the busyout-monitor state on the
voice port, use the no form of this command.
As noted previously, these gateways also provide additional processing options if the call control interface is
not available from Unified CM to reroute the calls to another site or dialed number or to play a locally stored
.wav file to the caller and end the call.
With MGCP-controlled Voice Gateways, when the Voice Gateway interface to Unified CM fails, the gateway
look for secondary and tertiary Unified CM subscribers from the redundancy group. The MGCP gateway will
automatically fail-over to the other subscribers in the group and periodically check the health of each, marking
it as available once it comes back on-line. The gateway will then fail-back to the primary subscriber when all
calls are idle or after 24 hours (whichever comes first).
If no subscribers are available, the Voice Gateway automatically busies-out all its trunks. This action prevents
new calls from being routed to this Voice Gateway from the PSTN. When the Voice Gateway interface to
Unified CM homes to the backup subscriber, the trunks are automatically idled and the PSTN begins routing
calls to this Voice Gateway again (assuming the PSTN has not permanently busied-out those trunks). The
design practice is to spread the gateways across the Unified CM call processing servers in the cluster to limit
the risk of losing all the gateway calls in a call center if the primary subscriber that has all the gateways
registered to it fails.
Voice gateways that are used with the Cisco Unified Survivable Remote Site Telephony (SRST) option for
Unified CM follow a similar fail-over process. If the gateway is cut off from the Unified CM that is controlling
it, the gateway will fail-over into SRST mode, which drops all voice calls and resets the gateway into SRST
mode. Phones re-home to the local SRST gateway for call control and calls are processed locally and directed
to local phones.
While running in SRST mode, it is assumed that the agents also have no CTI connection from their desktops.
They are seen as not ready within the Unified CCE routing application and no calls are sent to these agents
by Unified CCE. When the data connection is re-established to the gateway at the site, the Unified CM takes
control of the gateway and phones again, allowing the agents to be reconnected to the Unified CCE.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
96
Design Considerations for High Availability
Unified CM and CTI Manager Design Considerations
The servers in a Unified CM cluster communicate with each other using the Signal Distribution Layer (SDL)
service. SDL signaling is used only by the CallManager service to talk to the other CallManager services to
make sure everything is in sync within the Unified CM cluster. The CTI Managers in the cluster are completely
independent and do not establish a direct connection with each other. CTI Managers route only the external
CTI application requests to the appropriate devices serviced by the local CallManager service on this subscriber.
If the device is not resident on its local Unified CM subscriber, then the CallManager service forwards the
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
97
Design Considerations for High Availability
Unified CM and CTI Manager Design Considerations
application request to the appropriate Unified CM in the cluster. The figure below shows the flow of a device
request to another Unified CM in the cluster.
Although it might be tempting to register all of the Unified CCE devices to a single subscriber in the cluster
and point the Peripheral Gateway (PG) to that server, this configuration puts a high load on that subscriber.
If the PG were to fail in this case, the duplex PG would connect to a different subscriber and all the CTI
Manager messaging would have to be routed across the cluster to the original subscriber. It is important to
distribute devices and CTI applications appropriately across all the call processing nodes in the Unified CM
cluster to balance the CTI traffic and limit possible failover conditions.
The external CTI applications use a CTI-enabled user account in Unified CM. They log into the CTI Manager
service to establish a connection and assume control of the Unified CM devices associated to this specific
CTI-enabled user account, typically referred to as the JTAPI user or PG user. In addition, given that the CTI
Managers are independent from each other, any CTI application can connect to any CTI Manager in the cluster
to perform its requests. However, because the CTI Managers are independent, one CTI Manager cannot pass
the CTI application to another CTI Manager upon failure. If the first CTI Manager fails, the external CTI
application must implement the fail-over mechanism to connect to another CTI Manager in the cluster.
For example, the Agent PG handles fail-over for the CTI Manager by using its duplex servers, Sides A and
B, each of which is pointed to a different subscriber in the cluster, and by using the CTI Manager on those
subscribers. It is important to note these connections from the PG are managed in hot standby mode, which
means that only one side of the PG is active at any given time and is connected to the CTI Manager on the
subscriber.
The PG processes are designed to prevent both sides from trying to be active at the same time to reduce the
impact of the CTI application on Unified CM. Additionally, both of the duplex PG servers (Side A and Side
B) use the same CTI-enabled JTAPI or PG user to log into the CTI Manager applications. However, only one
Unified CM PG Side Allows the JTAPI user to register and monitor the user devices to conserve system
resources in the Unified CM cluster. The other side of the Unified CM PG stays in hot-standby mode, waiting
to connect, log in, register, and be activated upon failure of the active side.
The figure below shows two external CTI applications using the CTI Manager, the Agent PG, and the Unified
IP IVR. The Unified CM PG logs into the CTI Manager using the JTAPI account User 1 while the Unified
IP IVR uses account User 2. Each external application uses its own specific JTAPI user account and have
different devices registered and monitored by that user. For example, the Unified CM PG (User 1) monitors
all four agent phones and the inbound CTI Route Points, while the Unified IP IVR (User 2) monitors its CTI
Ports and the CTI Route Points used for its JTAPI Triggers. Although multiple applications can monitor the
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
98
Design Considerations for High Availability
Configuring the Unified CCE Peripheral Gateway for CTI Manager Redundancy
same devices, avoid this method because it can cause race conditions between the applications trying to take
control of the same physical device.
Unified CM CTI applications also add to the device weights on the subscribers, adding memory objects used
to monitor registered devices. These monitors are registered on the subscriber that has the connection to the
external application. It is a good design practice to distribute these applications to CTI Manager registrations
across multiple subscribers to avoid overloading a single subscriber with all of the monitored object tracking.
Perform the design of Unified CM and CTI Manager as the second design stage, right after the network design
stage. Perform deployment in this same order. The reason for this order is that the Cisco Unified
Communications infrastructure must be in place to dial and receive calls using its devices before you can
deploy any telephony applications.
Before moving to the next design stage, make sure that a PSTN phone can call an IP phone and that this same
IP phone can dial out to a PSTN phone with all the call survivability capabilities considered for treating these
calls. Also keep in mind that the Unified CM cluster design is paramount to the Unified CCE system, and any
server failure in a cluster takes down two services (CTI Manager and Unified CM), thereby adding an extra
load to the remaining servers in the cluster.
Configuring the Unified CCE Peripheral Gateway for CTI Manager Redundancy
To enable Unified Communications Manager support for CTI Manager fail-over in a duplex Unified CCE
Peripheral Gateway model, perform the following steps:
Procedure
Step 1 Create a Unified Communications Manager redundancy group and add subscribers to the group. (Do not use
Publishers and TFTP servers for call processing, device registration, or CTI Manager functions.)
Step 2 Designate two CTI Managers on different subscribers to be used for each side of the duplex Peripheral Gateway
(PG), one for PG Side A and one for PG Side B.
Step 3 Assign one of the CTI Managers to be the JTAPI service of the Unified Communications Manager PG Side
A.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
99
Design Considerations for High Availability
Unified IP IVR Design Considerations
Note that the setup panel on the left is for Side A of the Peripheral Gateway. It points to the CCM1 subscriber
and uses the PGUser CTI-enabled user account on the Unified Communications Manager cluster.
Step 4 Assign the second CTI Manager to be the JTAPI service of the Unified Communications Mananger PG Side
B.
Note that the setup panel on the right is for Side B of the Peripheral Gateway. It points to the CCM2 subscriber
and uses the same PGUser CTI-enabled user account on the Unified Communications Manager cluster. Both
sides of the duplex PG pair must use the same JTAPI user to monitor the same devices from either side of the
PG pair.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
100
Design Considerations for High Availability
Unified IP IVR High-Availability Using Unified CM
or host names of two Unified CMs from the cluster. Then, if one of the Unified CMs fails, the Unified IP IVR
associated with that particular Unified CM will fail-over to the second Unified CM.
Figure 53: High-availability with Two Unified IP IVR Servers and One Unified CM Cluster
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
101
Design Considerations for High Availability
Unified IP IVR High-Availability Using Unified CCE Call Flow Routing Scripts
Unified IP IVR High-Availability Using Unified CCE Call Flow Routing Scripts
You can implement Unified IP IVR high-availability through Unified CCE call flow routing scripts. You can
prevent calls from queuing to an inactive Unified IP IVR by using the Unified CCE scripts to check the Unified
IP IVR Peripheral Status before sending the calls to it. For example, you can program a Unified CCE script
to check if the Unified IP IVR is active by using an IF node or by configuring a Translation Route to the Voice
Response Unit (VRU) node (use the consider if field) to select the Unified IP IVR with the most idle ports
to distribute the calls evenly on a call-by-call basis. This method can be modified to load-balance ports across
multiple Unified IP IVRs and it can address all of the Unified IP IVRs on the cluster in the same Translation
Route or Send to VRU node.
Note All calls at the Unified IP IVR are dropped if the Unified IP IVR server itself fails. It is important to
distribute calls across multiple Unified IP IVR servers to minimize the impact of such a failure. In Unified
IP IVR), there is a default script to handle cases where the Unified IP IVR loses the link to the IVR
Peripheral Gateway so that the calls are not lost.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
102
Design Considerations for High Availability
Cisco Unified Customer Voice Portal (Unified CVP) Design Considerations
call control. Unified CVP uses H.323 or SIP for call control and is used in front of Unified CM or other PBX
systems as part of a hybrid Unified CCE or migration solution.
Figure 54: High-availability with Two Unified CVP Call Control Servers Using H.323
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
103
Design Considerations for High Availability
Cisco Multichannel Options with the CIM: E-mail Interaction Manager and Web Interaction Manager
using the Cisco Content Services Switch (CSS) products allowing multiple media servers to be pooled
behind a single URL for access by all the voice browsers in the network.
• Unified CVP VXML Application Server
Unified CVP provides a VoiceXML service creation environment using an Eclipse toolkit browser which
is hosted in the Unified CVP Call Studio Application. The Unified CVP VXML server hosts the Unified
CVP VoiceXML runtime environment where the dynamic VoiceXML applications are executed and
Java and Web Services calls are processed for external systems and database access.
• H.323 Gatekeepers
Gatekeepers are used with Unified CVP to register the voice browsers and associate them with specific
dialed numbers. When a call comes into the network, the gateway will query the gatekeeper to find out
where to send the call based on the dialed number. The gatekeeper is also aware of the state of the voice
browsers and will load-balance calls across them to avoid sending calls to out-of-service voice browsers
or ones that have no available sessions.
• SIP Proxy Servers
SIP Proxy Servers are used with Unified CVP to select voice browsers and associate them with specific
dialed numbers. When a call comes into the network, the gateway queries the SIP Proxy Server to find
out where to send the call based on the dialed number.
For more information about these options, review the Unified CVP product documentation.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
104
Design Considerations for High Availability
Cisco Interaction Manager Architecture Overview
The architecture is defined by a multi-tiered model, with various components at each of the following levels
of the design.
External Clients
Cisco Interaction Manager is a 100% web-based product that agents and end-customers can access using a
web browser from their desktops.
Agents can access the application using Microsoft Internet Explorer 6.0 or the embedded CAD browser, and
customers can access the chat customer console using specific versions of Microsoft IE, Mozilla, Firefox, or
Netscape. Cisco Interaction Manager is not supported on agent desktops running in a Citrix terminal services
environment.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
105
Design Considerations for High Availability
Unified CCE Integration
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
106
Design Considerations for High Availability
High-Availability Considerations for Cisco Interaction Manager
Cisco Interaction Manager objects in the Cisco Interaction Manager database. Note that Cisco Interaction
Manager does not make use of the Configuration API (ConAPI) interface.
For certain deployments of Unified CCE, the Media Routing (MR) PG of Unified CCE can reside on the
services server.
In parent/child configurations, there is no multichannel routing and integration through the parent Unified
ICM. Media Routing PGs need to connect to the child Unified CCE. A separate Cisco Interaction Manager
or partition is required for each child.
Likewise, in hosted Unified ICM/CCH environments, there is no multichannel routing through the Network
Application Manager (NAM) layer and integration is at the individual Customer ICM (CICM) level only. The
Media Routing (MR) PGs need to connect to the CICM.
Managing Fail-over
Cisco Interaction Manager supports clustered deployments. This ensures high-availability and performance
through transparent replication, load balancing, and fail-over. The following key methods are available for
handling failure conditions within a Cisco Interaction Manager and Unified CCE integrated deployment:
• Implementing multiple Web and Application servers – If the primary server goes down, the load balancer
can help handle the failure through routing requests to alternate servers. The load balancer detects
application server failure and redirects requests to another application server, after which a new user
session is created and users have to log in again to the Cisco Interaction Manager.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
107
Design Considerations for High Availability
Cisco Unified Outbound Option Design Considerations
• Allowing servers to be dynamically added or removed from the online cluster to accommodate external
changes in demand or internal changes in infrastructure.
• Allowing Cisco Interaction Manager services to fail-over with duplexed Unified CCE components (for
example, MR PIM and Agent PIM of the MR PG and Agent PG, respectively) to eliminate downtime
of the application in failure circumstances.
The single points of failure in Cisco Interaction Manager include the following.
• The JMS server going down
• The Services server going down
• The Database server going down
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
108
Design Considerations for High Availability
Cisco Unified Outbound Option Design Considerations
In the Unified Outbound Option solution, each Dialer communicates with its own peripheral interface
manager (PIM) on the Media Routing Peripheral Gateway.
The system can support multiple dialers across the enterprise, all of which are under control of the central
Campaign Manager software.
For the new SIP Dialer introduced in Unified CCE Release 8.0, Dialers operate in a warm standby mode
similar to the PG fault tolerance model. For more details, see Outbound Option Description, on page 207.
For the pre-existing SCCP Dialers, although they do not function as a redundant or duplexed pair the way a
Peripheral Gateway does, with a pair of dialers under control of the Campaign Manager, a failure of one of
the dialers can be handled automatically and calls will continue to be placed and processed by the surviving
dialer. Any calls that were already connected to agents remain connected and agents experience no impact
from the failure.
In all deployments, the Dialers are co-resident on the Unified CCE Peripheral Gateway for Unified CM.
Guidelines for high availability:
• Deploy the Media Routing Peripheral Gateways in duplex pairs.
• Deploy multiple Dialers with one on each side of the Duplex Unified CCE Peripheral Gateway 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. For the SCCP Dialer, there are two options with multiple Dialers: a second Dialer can
be configured with the same number of ports (100% redundancy), or the ports can be split across the
two Dialers since they operate independently and are both active at the same time. In designs with a
small number of Dialer ports, splitting them can impact the performance of the campaign.
• Deploy redundant Voice Gateways for outbound dialing to ensure that the dialers have enough trunks
available to place calls in the event of a Voice Gateway failure. In some instances where outbound is
the primary application, these gateways are dedicated to outbound calling only.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
109
Design Considerations for High Availability
Peripheral Gateway Design Considerations
Improving Fail-over Recovery for Customers with Large Numbers of CTI Route
Points
When a Unified CCE PG fails-over, the PIM connection that was previously controlling the Unified CM
cluster is disconnected from its CTI Manager and the duplex or redundant side of the PG will attempt to
connect its PIM to the cluster using a different CTI Manager and Subscriber. This process requires the new
PIM connection to register for all of the devices (phones, CTI Route Points, CTI Ports, and so forth) that are
controlled by Unified CCE on the cluster. When the PIM makes these registration requests, all of them must
be confirmed by Unified CM before the PIM can go into an active state and process calls.
To help recover more quickly, the Unified CCE PG can have a PIM created that is dedicated to the CTI Route
Points for the customer, thus allowing this PIM to register for these devices at a rate of approximately five
per second and allowing the PIM to activate and respond to calls hitting these CTI Route points faster than if
the PIM had to wait for all of the route points, then all the agent phones, and all the CTI ports.
This dedicated CTI Route Point PIM can become active several minutes sooner and direct new inbound calls
to queuing or treatment resources while waiting for the Agent PIM with the phones and CTI Ports to complete
the registration process and become active.
This does not provide any additional scaling or other benefits for the design; the only purpose is to allow
Unified CM to have the calls on the CTI Route Points serviced faster by this dedicated PIM. Use this only
with customers who have more than 250 Route Points because anything less does not provide a reasonable
improvement in recovery time. Additionally, associate only the CTI Route Points that are serviced by Unified
CCE with this PIM and provide it with its own dedicated CTI-Enabled JTAPI or PG user that is specific to
the CTI Route Point PIM.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
110
Design Considerations for High Availability
Scaling the Unified CCE PG Beyond 2,000 Agents per Server
Note Use the Cisco Unified Communications Sizing Tool (Unified CST) to size the Unified CM cluster properly
for Unified CCE. This tool is only available to Cisco partners and employees with proper login
authentication.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
111
Design Considerations for High Availability
Redundant or Duplex Unified CCE Peripheral Gateway Considerations
To simplify the illustration in Figure 58, the Unified CCE Server or Unified CCE Central Controller is
represented as a single server, but it is actually a set of servers sized according to the Unified CCE agent count
and call volume. The Unified CCE Central Controllers include the following redundant or duplex servers:
• Call Router — The core of the CCE complex that provides intelligent call routing instructions based on
real-time conditions that it maintains in memory across both the A-Side And B-Side Call Router processes.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
112
Design Considerations for High Availability
Unified Communications Manager JTAPI and Peripheral Gateway Failure Detection
• Logger and Database Server — The repository for all configuration and scripting information as well
as historical data collected by the system. The Loggers are paired with Call Routers such that Call Router
Side A will read and write data only to the Logger A and Call Router B will read and write only to the
Logger B. Because both sides of the Call Router processes are synchronized, the data written to both
Loggers is identical.
In specific deployment models, these two components can be installed on the same physical server which is
then referred to as a Rogger, or combined Router and Logger. See the chapter on Sizing Unified CCE
Components and Servers for more details on these specific configurations.
Procedure
Step 1 From the Start Menu of the Peripheral Gateway, Select Programs > Cisco JTAPI > JTAPI Preferences.
Step 2 Set theAdvanced > Server Heartbeat Interval (sec) field to 5 seconds.
Note Do not set this value lower than five seconds because it might impact system performance and trigger
an inappropriate fail-over. This setting determines how often the heartbeats are generated. If it is set
to five seconds, the system will fail-over this connection within ten seconds of a loss of network
connection (because it must detect two consecutive missed heartbeats). The default of 30 seconds
means that it takes up to one minute (60 seconds) to take action on a network connection failure.
Because this JTAPI connection between the Peripheral Gateway and Unified Communications Manager is
only supported locally on the same LAN segment, there is no latency issue for this heartbeat value. However,
if there are any additional network hops, firewalls, or other devices that cause delay between these two
components, then set the heartbeat interval value accordingly to account for this delay.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
113
Design Considerations for High Availability
Unified CCE Redundancy Options
Private connections from the rest of the Visible or Public Network in their own Cisco Catalyst switch if they
are located at the same physical site.
If the Central Controllers are geographically separated (located at two different physical sites), under normal
operations the same Private Network connections must continue to be isolated and connected between the
two physical sites with a separate WAN connection. For normal operations, do not provision this Private
Network connection on the same circuits or network gear as the Visible or Public Network WAN connection
because that creates a single point of failure that could disable both WAN segments at the same time.
The Unified CCE Peripheral Gateway duplex pair of servers is also interconnected through a Private Network
connection that is isolated from the Visible or Public Network segment under normal operations. If the two
sides of the duplex pair (Side A and Side B) are both at the same physical site, the Private Network can be
created by using an Ethernet Cross-Over Cable between the two servers to interconnect their Private Network
NIC cards. If the two servers in the duplex pair are geographically distributed (located at two different physical
sites), the Private Network connections must be connected with a separate WAN connection between the two
physical sites. Do not provision this Private Network connection on the same circuits or network gear as the
Visible or Public Network WAN connection because that creates a single point of failure that could disable
both WAN segments at the same time.
For additional details on the Unified ICM network requirements for this connection, see the installation guides.
For additional details on the Unified CCE network requirements for clustered over the WAN, see the section
on IPT: Clustering Over the WAN.
Within the Agent PG, two software processes manage the connectivity to the Unified CM cluster:
• JTAPI Gateway
The JTAPI Gateway is installed on the PG by downloading it from the Unified CM cluster at the time
of the PG installation. This ensures compatibility with the JTAPI and CTI Manager versions in the
system. Note that when either the PG or Unified CM is upgraded, this JTAPI Gateway component must
be removed and re-installed on the PG.
The JTAPI Gateway is started by the PG automatically and runs as a node-managed process. The PG
monitors this process and automatically restarts it if it fails for any reason. The JTAPI Gateway handles
the low-level JTAPI socket connection protocol and messaging between the PIM and the Unified CM
CTI Manager.
• Agent PG Peripheral Interface Manager (PIM)
The PIM is also a node-managed process and is monitored for unexpected failures and automatically
restarted. This process manages the higher-level interface between the Unified CCE and the JTAPI
Gateway and Unified CM cluster, requesting specific objects to monitor and handling route requests
from the Unified CM cluster.
In a duplex Agent PG environment, both JTAPI services from both Agent PG sides log into the CTI Manager
upon initialization. Unified CM PG Side A logs into the primary CTI Manager; PG Side B logs into the
secondary CTI Manager. Only the active side of the Unified CM PG register monitors for phones and CTI
route points. The duplex Agent PG pair works in hot-standby mode with only the active PG side PIM
communicating with the Unified CM cluster. The standby side logs into the secondary CTI Manager only to
initialize the interface and make it available for a fail-over. The registration and initialization services of the
Unified CM devices take a significant amount of time; therefore having the CTI Manager available significantly
decreases the time for fail-over.
In duplex PG operation, the side that goes active is the PG side that is first able to connect to the Unified CCE
Call Router Server And request configuration information. It is not determined based on the side-A or side-B
designation of the PG device but depends only on the ability of the PG to connect to the Call Router. The Call
Router ensures that only the PG side that has the best connection goes active.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
114
Design Considerations for High Availability
Unified CM Failure Scenarios
The startup process of the PIM requires that all of the CTI route points be registered first, which is done at a
rate of 5 route points per second. For systems with a lot of CTI route points (for example, 1000), this process
can take as long as 3 minutes to complete before the system will allow any of the agents to log in. This time
can be reduced by distributing the devices over multiple PIM interfaces to the Unified CM cluster, as noted
above.
In the event that calls arrive at the CTI Route Points in Unified CM but the PIM is not yet fully operational,
these calls fail unless these route points are configured with a recovery number in their "Call Forward on
Unregistered" or "Call Forward on Failure" setting. These recovery numbers can be the Cisco Unity voicemail
system for the Auto Attendant (or perhaps the company operator position) to ensure that the incoming calls
are being answered.
In either of these cases, Unified CCE will not be able to communicate with the Unified CM cluster.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
115
Design Considerations for High Availability
Scenario 1: Unified CM and CTI Manager Fail
• Scenario 4: The Unified CM CTI Manager Providing JTAPI Services to the Unified CCE PG Fails
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
116
Design Considerations for High Availability
Scenario 2: Agent PG Side A Fails
• As noted above, when the PG fails-over, the Unified CCE Call Router writes a Termination Call Detail
Record (TCD) in the Unified CCE database for any active calls. If the call is still active when the PG
fails-over to the other side, a second TCD record is written for this call as if it were a "new" call in the
system and not connected to the prior call that was recorded in the database.
• When Unified CM subscriber A recovers, all idle phones and gateways re-home to it. Active devices
wait until they are idle before re-homing to the primary subscriber.
• PG Side B remains active using the CTI Manager on Unified CM subscriber B.
• After recovery from the failure, the PG does not fail back to the A side of the duplex pair. All CTI
messaging is handled using the CTI Manager on Unified CM subscriber B which communicates with
Unified CM subscriber A to obtain phone state and call information.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
117
Design Considerations for High Availability
Scenario 3: The Unified CM Active Call Processing Subscriber Fails
• Agents with calls in progress will stay in progress but with no third-party call control (conference,
transfer, and so forth) available from their agent desktop soft phones. Agents that were not on calls may
notice their CTI desktop disable their agent state or third-party call control buttons on the desktop during
the fail-over to the B-Side PG. Once the fail-over is complete, the agent desktop buttons are restored;
however the barge in and conference calls will not be rebuilt properly and calls will disappear from the
desktop when either of the participants drops out of the call. Call Type indication of Transfer, Barge In,
Intercept, Supervisor Assist, and Emergency Assist are not recovered in the agent desktop or in reporting.
• In most cases, after a PG fail-over, agents whose states are Available or Wrap Up are moved to Available.
Alternatively, agents may receive a prompt to log in or to change their state from Not Ready to Available.
• In most cases, after a PG fail-over, agents and supervisors whose states were either Talking or Reserved
before the fail-over will be returned to Talking or Reserved, respectively (if the call is still active). Once
the call ends, the agents' or supervisors' states change to Available.
• When the PG fails-over, the Unified CCE Call Router writes a Termination Call Detail Record (TCD)
in the Unified CCE database for any active calls. If the call is still active when the PG fails-over to the
other side, a second TCD record is written for this call as if it were a "new" call in the system and not
connected to the prior call that was recorded in the database.
• When PG Side A recovers, PG Side B remains active and uses the CTI Manager on Unified CM subscriber
B. The PG does not fail-back to Side A, and call processing continues on the PG Side B.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
118
Design Considerations for High Availability
Scenario 3: The Unified CM Active Call Processing Subscriber Fails
to the Unified CCE PG. The CTI Manager services are running on all the Unified CM subscribers in the
cluster, but only subscribers C and D are configured to communicate with the Unified CCE Peripheral Gateway.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
119
Design Considerations for High Availability
Scenario 4: The Unified CM CTI Manager Providing JTAPI Services to the Unified CCE PG Fails
the agent disconnects the active call, that agent’s phone re-registers with the backup subscriber. The
agent is logged out and will need to log in again.
• As noted above, when the Unified CM subscriber A fails, the calls in progress stay active; however,
Unified CCE loses control and track of those calls because the phone has not re-homed (re-registered)
with the backup subscriber in the cluster. In fact, the phone does not re-home until after the current call
is completed. The Unified CCE Call Router writes a Termination Call Detail Record (TCD) in the
Unified CCE database for calls that were active at the time of the subscriber failure with call statistics
up to the time of the failure and loss of control. Any additional call information (statistics, call wrap-up
data, and so forth) are not written to the Unified CCE database.
• When Unified CM subscriber A recovers, phones and gateways re-home to it. This re-homing can be
set up on Unified CM to gracefully return groups of phones and devices over time or to require manual
intervention during a maintenance window to minimize the impact to the call center. During this re-homing
process, the CTI Manager service notifies the Unified CCE Peripheral Gateway of the phones being
unregistered from the backup Unified CM subscriber B and re-registered with the original Unified CM
subscriber A.
• Call processing continues normally after the phones and devices have returned to their original subscriber.
Figure 63: Scenario 4—Only the Unified CM CTI Manager Service Fails
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
120
Design Considerations for High Availability
Unified CCE Scenarios for Clustering over the WAN
Note The terms public network and visible network are used interchangeably throughout this document.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
121
Design Considerations for High Availability
Scenario 1: Unified CCE Central Controller or Peripheral Gateway Private Network Failure
Additional Considerations
The Call Routers are "paired" with the Loggers and can read and write only to their own Logger for
configuration and historical data over the Private Network locally. In the event that the failure is caused by
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
122
Design Considerations for High Availability
Scenario 2: Visible Network Failure
the loss of a Private NIC card in the Call Router and that Call Router is the enabled side, it cannot write any
historical data to the Logger nor can any configuration changes be made to the Logger database.
The Private NIC in the Call Router is also used in some cases to communicate with carrier-based Pre-Routing
Network or SS7 interfaces. If the Private NIC fails, there is no access to these services.
If there is an even number of PGs specified in the Call Router Setup and only half of the PGs are available,
then only Side A runs. For the B-Side to be operational during a private network failure, it must be able to
communicate with more than half of the PGs in the system.
It is important to maintain the configuration so that "extra" PGs or PGs that are no longer on the network are
removed from the Call Router Setup panels to avoid problems with determination of device majority for PGs
that no longer exist.
If the private network fails between the Unified CM Peripheral Gateways, the following conditions apply:
• The Peripheral Gateway sides detect a failure if they miss five consecutive TCP keep-alive messages
and they follow a process similar to the Call Routers of leveraging the MDS process when handling a
private link failure. As with the Central Controllers, one MDS process is the enabled synchronizer and
its redundant side is the disabled synchronizer. When running redundant PGs, the A side is always the
enabled synchronizer.
• After detecting the failure, the disabled synchronizer (Side B) initiates a test of its peer synchronizer by
using the TOS procedure on the Public or Visible Network connection. If PG Side B receives a TOS
response stating that the A side synchronizer is enabled or active, then the B side immediately goes out
of service, leaving the A side to run in simplex mode until the Private Network connection is restored.
The PIM, OPC, and CTI SVR processes become active on PG Side A, if not already in that state, and
the CTI OS Server process still remains active on both sides as long as the PG Side B server is healthy.
If the B side does not receive a message stating that the A side is enabled, then Side B continues to run
in simplex mode and the PIM, OPC, and CTI SVR processes become active on PG Side B if not already
in that state. This condition occurs only if the PG Side A server is truly down or unreachable due to a
double failure of visible and private network paths.
• There is no impact to the agents, calls in progress, or calls in queue because the agents stay connected
to their already established CTI OS Server process connection. The system can continue to function
normally; however, the PGs are in simplex mode until the private network link is restored.
If the two private network connections are combined into one link, the failures follow the same path; however,
the system runs in simplex mode on both the Call Router, and the Peripheral Gateway. If a second failure
were to occur at that point, the system could lose some or all of the call routing and ACD functionality.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
123
Design Considerations for High Availability
Scenario 2: Visible Network Failure
capable of handling the full central-site load with all QoS parameters. For more information, see the
section on Bandwidth Requirements for Unified CCE Clustering Over the WAN.
• An HA WAN using point-to-point technology is best implemented across two separate carriers, but this
is not necessary when using a ring technology.
If the visible network fails between the data center locations, the following conditions apply:
• The Unified CM subscribers detect the failure and continue to function locally with no impact to local
call processing and call control. However, any calls that were set up over this WAN link fail with the
link.
• The Unified CCE Call Routers detect the failure because the normal flow of TCP keep-alives from the
remote Peripheral Gateways stops. Likewise, the Peripheral Gateways detect this failure by the loss of
TCP keep-alives from the remote Call Routers. The Peripheral Gateways automatically realign their
data communications to the local Call Router and the local Call Router then uses the private network to
pass data to the Call Router on the other side to continue call processing. This does not cause a fail-over
of the Peripheral Gateway or the Call Router.
• Half the agents (or more) 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 Unified CM cluster.
Under normal circumstances, phone events are passed from Side B to Side A over the visible
network by using the CTI Manager Service to present these events to the Side A Peripheral Gateway.
The visible network failure does not force the IP phone to re-home to Side A of the cluster and the
phone remains operational on the isolated Side B. The Peripheral Gateway is no longer able to see
this phone and the agent is logged out of Unified CCE automatically because the system can no
longer direct calls to the agent’s phone.
◦If the agent desktop (Cisco Agent Desktop or CTI OS) and IP phone are both registered to Side A
of the Peripheral Gateway and Unified CM, but the phone is reset and it re-registers to a Side B
of the Unified CM subscriber.
If the IP phone re-homes or is manually reset and forced to register to Side B of a Unified CM
subscriber, the Unified CM subscriber on Side A that is providing the CTI Manager service to the
local Peripheral Gateway unregisters the phone and removes it from service. Because the visible
network is down, the remote Unified CM subscriber at Side B cannot send the phone registration
event to the remote Peripheral Gateway. Unified CCE logs this agent out because it can no longer
control the phone for the agent.
◦If the agent desktop (CTI Toolkit Agent Desktop 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, the CTI Toolkit Agent Desktop load-balances its connections to the CTI
OS Server pair. At any given time, half the agent connections are on a CTI OS server that has to
cross the visible network to connect to the active Peripheral Gateway CTI Server (CG). When the
visible network fails, the CTI OS Server detects the loss of connection with the remote Peripheral
Gateway CTI Server (CG) and disconnects the active agent desktop clients to force them to re-home
to the redundant CTI OS Server At the remote site. The CTI Toolkit Agent Desktop is aware of
the redundant CTI OS Server And automatically uses this server. During this transition, the CTI
Toolkit Agent Desktop is disabled and returns to an operational state as soon as it is connected to
the redundant CTI OS server. (The agent may be logged out or put into not-ready state depending
on the /LOAD parameter defined for the Unified CM Peripheral Gateway in Unified CCE
Configuration Manager.)
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
124
Design Considerations for High Availability
Scenario 3: Visible and Private Networks Both Fail (Dual Failure)
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
125
Design Considerations for High Availability
Scenario 4: Unified CCE Agent Site WAN (Visible Network) Failure
• Agents are impacted as noted above if their IP phones are registered to the side of the Unified CM cluster
opposite the location of their active Peripheral Gateway and CTI OS Server connection. Only agents
that were active on the surviving side of the Peripheral Gateway with phones registered locally to that
site are not impacted.
At this point, the Call Router and Unified CM Peripheral Gateway run in simplex mode and the system accepts
new calls from only the surviving side for Unified CCE call treatment. The Unified IP IVR/Unified CVP
functionality is also limited to the surviving side.
If both sides of the WAN at the Unified CCE Agent Site fail, the following conditions apply:
• The local Voice Gateway detects the failure of the communications path to the Unified CM cluster and
goes into SRST mode to provide local dial-tone functionality. With Unified CVP, these gateways detect
the loss of the Unified CVP Call Server And execute their local survivability TCL script to reroute the
inbound calls. Active calls in Unified CVP locally are no longer be visible to Unified CCE, so a
Termination Call Detail (TCD) record is written to the Unified CCE database at the time of the failure
and tracking of the call stops at that point. The call executes the local survivability TCL script, which
could redirect it using the PSTN to another Unified CCE site that remains active; however, the call then
appears as a "new call" to Unified CCE and has no relationship with the original call information. If the
call is retained locally and redirected by way of SRST to a local phone, Unified CCE does not have
visibility to the call from that point forward.
• The agent desktop detects the loss of connectivity to the CTI OS Server (or Cisco Agent Desktop Server)
and automatically logs the agent out of the system. While the IP phones are in SRST mode, they are not
able to function as Unified CCE agents.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
126
Design Considerations for High Availability
Unified CM Service
Unified CM Service
In larger deployments, it is possible that the Unified CM to which the agent phones are registered is not running
the CTI Manager service that communicates with the Unified CM Peripheral Gateway for Unified CCE. When
an active Unified CM (call processing) service fails, all the devices registered to it are reported "out of service"
by the CTI Manager service locally and to any external client such as the Peripheral Gateway on a different
subscriber CTI Manager service.
Unified CM call detail reporting (CDR) shows the call as terminated when the Unified CM failure occurred,
although the call may have continued for several minutes after the failure because calls in progress stay in
progress. IP phones of agents not on calls at the time of failure quickly register with the backup Unified CM
subscriber. The IP phone of an agent on a call at the time of failure does not register with the backup Unified
CM subscriber until after the agent completes the current call. If MGCP, H.323, or SIP gateways are used,
then the calls in progress survive, but further call control functions (hold, retrieve, transfer, conference, and
so on) are not possible.
Unified CCE also writes a call record to the Termination Call Detail (TCD) table because Unified CM has
reported the call as terminated to the Unified CCE PG. If the call continues after the PG has failed-over, a
second TCD record is written as a "new call" not related to the original call.
When the active Unified CM subscriber fails, the PG receives out-of-service events from Unified CM and
logs out the agents. To continue receiving calls, the agents must wait for their phones to re-register with a
backup Unified CM subscriber, then log back into their Unified CCE desktop application to have its
functionality restored. On recovery of the primary Unified CM subscriber, the agent phones re-register to
their original subscriber to return the cluster to the normal state with phones and devices properly balanced
across multiple active subscribers.
In summary, the Unified CM call processing service is separate from the CTI Manager service which connects
to the Unified CM PG through JTAPI. The Unified CM call processing service is responsible for registering
the IP phones and its failure does not affect the Unified CM PGs. From a Cisco Unified CCE perspective, the
PG does not go off-line because the Unified CM server running CTI Manager remains operational. Therefore,
the PG does not need to fail-over.
Unified IP IVR
When a CTI Manager service fails, the Unified IP IVR JTAPI subsystem shuts down and restarts by trying
to connect to the secondary CTI Manager service on a backup Unified CM subscriber in the cluster. In addition,
all voice calls at this Unified IP IVR are dropped. If there is an available secondary CTI Manager service on
a backup subscriber, the Unified IP IVR logs into this CTI Manager service on that subscriber and re-registers
all the CTI ports associated with the Unified IP IVR JTAPI user. After all the Unified CM devices are
successfully registered with the Unified IP IVR JTAPI user, the server resumes its Voice Response Unit
(VRU) functions and handles new calls. This action does not impact the Unified CVP because it does not
depend on the Unified CM CTI Manager service for call control.
Unified IP IVR Release 3.5 provided for cold standby and Release 4.0 provides hot standby redundancy but
this configuration is not supported for use with Unified CCE. These designs make use of a redundant server
that is not used unless there is a failure of the primary Unified IP IVR server. However, during this fail-over
processing, all calls that are in queue or treatment are dropped on the Unified IP IVR as part of the fail-over.
A more resilient design is to deploy a second (or more) Unified IP IVR servers and have them all active,
allowing Unified CCE to load-balance calls across them automatically. As shown in Figure 64: Redundant
Unified CCE VRU PGs with Two IP IVR Servers , on page 129, if one of the Unified IP IVR servers fails,
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
127
Design Considerations for High Availability
Unified CCE
only the calls on that server fail but the other active servers remain active and are able to accept new calls in
the system.
Unified CCE
Unified CCE is a collection of services and processes running on Unified CCE servers. The fail-over and
recovery process for each of these services is unique and requires careful examination to understand the impact
to other parts of the Unified CCE solution (including another Unified CCE service).
Note Do not push any buttons during desktop fail-over because these keystrokes can be buffered and sent to
the CTI server when it completes its fail-over and restores the agent states.
When an active PG fails over to the idle side, calls still in progress are recovered by querying Unified CM as
part of the activation sequence. There is one Termination Call Detail record providing information about the
call after the PG transition when the call terminates. Peripheral call variables and ECC variables are maintained
on the agent desktop. Call Type indication of Transfer, Barge In, Intercept, Supervisor Assist, and Emergency
Assist are not recovered in the desktop or in reporting after the fail-over. In most cases, after a PG fail-over,
agents whose states are Available or Wrap Up are moved to Available. Alternatively, agents may receive a
prompt to log in or to change their state from Not Ready to Available. Agents can release, transfer, or conference
calls from their agent desktop after activation completes. During conference tear down, a call appearance
from the desktop of an active call but agent state is not affected. Calls that end while the PG is down end after
a dead call time out after two hours.
Note Call and agent state information might not be complete at the end of a fail-over if there are call status and
agent state changes during the fail-over window.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
128
Design Considerations for High Availability
Unified CCE Voice Response Unit PG
Figure 64: Redundant Unified CCE VRU PGs with Two IP IVR Servers
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
129
Design Considerations for High Availability
Unified CCE Call Router and Logger
The Unified CCE Call Router is the brain of the system and it maintains a constant memory image of
the state of all the agents, calls, and events in the system. It performs the call routing in the system;
executing the user-created Unified CCE Routing Scripts and populating the real-time reporting feeds
for the Administration & Data Server. The Call Router software runs in synchronized execution with
both of the redundant servers running the same memory image of the current state across the system.
They keep this information updated by passing the state events between the servers on the private LAN
connection.
• Unified CCE Logger and Database Server
The Unified CCE Logger and Database Server maintain the system database for the configuration (agent
IDs, skill groups, call types, and so forth) and scripting (call flow scripts) as well as the historical data
from call processing. The Loggers receive data from their local Call Router process to store in the system
database. Because the Call Routers are synchronized, the Logger data is also synchronized. In the event
that the two Logger databases are out of synchronization, they can be resynchronized manually by using
the Unified ICMDBA application over the private LAN. The Logger also provides a replication of its
historical data to the customer Administration & Data Server over the visible network.
In the event that one of the Unified CCE Call Routers fails, the surviving server detects the failure after missing
five consecutive TCP keep-alive messages on the private LAN. The Call Routers generate these TCP keep-alive
messages every 100 ms, so it takes up to 500 ms to detect this failure. On detection of the failure, the surviving
Call Router contacts the Peripheral Gateways in the system to verify the type of failure that occurred. The
loss of TCP keep-alive messages on the private network can 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 Unified CCE Call Routers to still be fully operational. In this case, the Peripheral Gateways still see
both of the Unified CCE Call Routers even though they cannot see each other over the private network
to provide synchronization data. If the disabled synchronizer (Call Router B) can communicate with a
majority of the PGs, it then sends a Test Other Side (TOS) message to the PGs sequentially to determine
if the Call Router on the other side (Side A) is enabled. If Call Router B receives a message that Side A
is in fact enabled, then Call Router A runs in simplex until the private network is restored. If all the PGs
reply to the TOS message and indicate that Side A is down, then Side B re-initializes in simplex mode.
• Call Router hardware failure — It is possible for the Call Router on the other side to have a physical
hardware failure and be completely out of service. In this case, the Peripheral Gateways report that they
can no longer see the Call Router on the other Side And the surviving Call Router takes over the active
processing role in simplex mode. This failure is detected by the Call Routers from the loss of heartbeat
keep-alives on the Private Network.
During Call Router fail-over processing, any Route Requests sent to the Call Router from a Carrier Network
Interface Controller (NIC) or Peripheral Gateway are queued until the surviving Call Router is in active
simplex mode. Any calls in progress in the IVR or at an agent are not impacted.
If one of the Unified CCE Logger and Database Servers were to fail, there is no immediate impact except that
the local Call Router is no longer able to store data from call processing. The redundant Logger continues to
accept data from its local Call Router. When the Logger server is restored, the Logger contacts the redundant
Logger to determine how long it had been off-line. If the Logger was off-line for less than 12 hours, it
automatically requests all the transactions it missed from the redundant Logger while it was off-line. The
Loggers maintain a recovery key that tracks the date and time of each entry recorded in the database and these
keys are used to restore data to the failed Logger over the private network.
If the Logger was off-line for more than 12 hours, the system does not automatically resynchronize the
databases. In this case, resynchronization is done manually using the Unified ICMDBA application. Manual
resynchronization allows the system administrator to decide when to perform this data transfer on the private
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
130
Design Considerations for High Availability
Administration and Data Server
network, perhaps scheduling it during a maintenance window when there is little call processing activity in
the system.
The Logger replication process that sends data from the Logger database to the HDS database on the
Administration & Data Servers automatically replicates each new row written to the Logger database when
the synchronization takes place as well.
There is no impact to call processing during a Logger failure; however, the historical data on the Administration
& Data Server that is replicated from that Logger stops until the Logger is restored.
Additionally, if the Unified Outbound Option is used, the Campaign Manager software is loaded on Logger
A only. If that platform is out of service, any outbound calling stops until the Logger is restored to operational
status.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
131
Design Considerations for High Availability
CTI Server
Administration & Data Server Real-Time Distributors are clients of the Unified CCE Call Router real-time
feed that provides real-time information about the entire Unified CCE across the enterprise. 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. Another option is to add Administration Clients
that do not have their own local SQL databases and are homed to a Real-Time Distributor locally for their
SQL database and real-time feed.
The Admin Site reduces the number of real-time feed clients the Unified CCE Call Router has to service at a
particular site. For remote sites, this is important because it can reduce the required bandwidth to support
remote Administration & Data Servers across a WAN connection.
When using an Admin Site, the primary Administration & Data Server is the one that registers with the Unified
CCE Call Router for the real-time feed and the other Administration & Data Servers within that Admin Site
register with the primary Administration & Data Server for the real-time feed. If the primary real-time distributor
is down, the secondary real-time distributors register with the Unified CCE Call Router for the real-time feed.
Administration Clients that cannot register with the primary or secondary Administration & Data Server
cannot perform any tasks until the distributors are restored.
Alternatively, each Administration & Data Server can be deployed in its own Admin Site regardless of the
physical site of the device. This deployment creates more overhead for the Unified CCE Call Router to maintain
multiple real-time feed clients; however, it prevents a failure of the primary Administration & Data Server
from taking down the secondary Administration & Data Server At the site.
Additionally, if the Administration & Data Server is used to host the ConAPI interface for the Cisco Unified
Contact Center Management Portal (Unified CCMP), any configuration changes made to the Unified CCE
or Unified CCMP systems are not passed over the ConAPI interface until it is restored.
CTI Server
The CTI Server monitors the data traffic of the Unified CM PIM on the Agent PG for specific CTI messages
(such as call ringing or off-hook events) and makes those messages available to CTI clients such as the CTI
OS Server or Cisco Agent Desktop Enterprise Server. It also processes third-party call control messages (such
as make call or answer call) from the CTI clients and sends those messages by using the PIM interface of the
PG to Unified CM to process the event on behalf of the agent desktop.
CTI Server is redundant and co-resident on the Agent PG servers. (See Figure 66) It does not, however,
maintain agent state in the event of a failure. On failure of the CTI Server, the redundant CTI Server Becomes
active and begins processing call events. Both CTI OS and Finesse Servers are clients of the CTI Server And
are designed to monitor both CTI Servers in a duplex environment and maintain the agent state during fail-over
processing. CTI OS agents see their desktop buttons dim during the fail-over to prevent them from attempting
to perform tasks while the CTI Server is down. The buttons are restored as soon as the redundant CTI Server
is restored and the agent does not have to log on again to the desktop application. Most call context is
maintained, but ANI and DNIS are lost in this instance where only the CTI Server component is impacted.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
132
Design Considerations for High Availability
CTI OS Considerations
Finesse servers return an OUT_OF_SERVICE status to clients during the fail-over, preventing the clients
from initiating actions. The Finesse Desktop user interface retains its last state until the redundant CTI Server
is restored, at which time the Finesse server updates each client with the current CTI state.
CTI OS Considerations
CTI OS Server is a software component that runs co-resident on the Unified CM Peripheral Gateway. CTI
OS Server software is designed to be fault-tolerant and is typically deployed on redundant physical servers;
however, unlike the PG processes that run in hot-standby mode, both of the CTI OS Server processes run in
active mode all the time. The CTI OS Server processes are managed by Node Manager, which monitors each
process running as part of the CTI OS service and which automatically restarts abnormally terminated processes.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
133
Design Considerations for High Availability
CTI OS Considerations
CTI OS handles fail-over of related components as described in the following scenarios (see figure below).
Note When the active agent peripheral’s CG loses network connectivity to the agent desktops, the system
registers that agents are not connected within one minute and waits one more minute for possible
re-connection before it fails over to the other side.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
134
Design Considerations for High Availability
CTI OS Considerations
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
135
Design Considerations for High Availability
Cisco Finesse Considerations
Scenario 10: Network Failure between CTI OS Client 2 and CTI OS Server B
In this scenario, the following events occur:
• CTI OS Server B drops the connection of CTI OS Client 2.
• CTI OS Client 2 detects the loss of network connection and automatically connects to CTI OS Server
A. During this transition, the buttons of the CTI Toolkit Agent Desktop are disabled and return to the
operational state as soon as the desktop is connected to CTI OS Server A.
Note Note: If there are no clients connected to the active CTI Server, a default switch occurs every
"NoClientConnectionTimeout" seconds. This occurs to isolate any spurious reasons that the CTI clients
cannot connect to the active CTI Server.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
136
Design Considerations for High Availability
Cisco Finesse Considerations
Finesse handles the fail-over of related components as described in the following scenarios (see figure below).
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
137
Design Considerations for High Availability
Cisco Finesse Considerations
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
138
Design Considerations for High Availability
Cisco Agent Desktop Considerations
The following services are active on both sides at all times and are available to the Cisco Agent Desktop client
applications as long as network connectivity is available:
• Cisco LDAP Monitor Service
• Cisco Recording & Playback Service
• Cisco VoIP Monitor Service
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
139
Design Considerations for High Availability
CAD IP Phone Agent
Network failure between active side and idle side Cisco Agent Desktop service
In this scenario, the following events occur:
• The Cisco Agent Desktop services on Side A remain active.
• The Cisco Agent Desktop services on Side B (idle) activate.
• The Cisco Agent Desktop client applications remain connected to Cisco Agent Desktop services on Side
A.
• When network connectivity is restored between Sides A and B, the Cisco Licensing and Resource
Manager Service renders inactive the non-preferred side. Recovery side preference is configurable in
Post Install.
Idle side Cisco Agent Desktop services become active after failure
In this scenario, the following events occur for a logged-in desktop agent:
• The desktop applet changes to a logged out state and the user is notified that the connection has been
lost.
• The desktop applet automatically connects to services on Side B and logs-in the agent.
In this scenario, the following events occur for a logged-in CAD IP Phone agent:
• The phone agent is notified that the connection to the server has been lost.
• The phone agent manually selects Side B from their services list and logs in again.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
140
Design Considerations for High Availability
Unified CCE High Availability with Unified ICM Enterprise
Note Starting release 9.0(3), all customers with new deployments of any version of Cisco Agent Desktop must
use SQL Server as the data store, and not flat files. The rationale behind this change is that deployments
with a fully replicated SQL Server database experience a more complete feature set, better performance,
and stability.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
141
Design Considerations for High Availability
Parent/Child Components
Unified CCE solution to allow sites to remain functional as Unified CCE sites even if they are cut off from
centralized call processing resources.
Parent/Child Components
The following sections describe the components used in Unified ICME (parent) and Unified CCE (child)
deployments.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
142
Design Considerations for High Availability
Unified CCX Call Center (Child) Site
can also support standard pre-routing with inter-exchange carriers (IXCs) such as AT&T, MCI, and others,
allowing Unified ICME to select the best target for the call while it is still in the carrier network.
The Unified ICME parent is not designed to support any directly controlled agents in this model, which means
that it does not support classic Unified CCE with a Unified CM PG installed on this Unified ICME parent.
All agents must be controlled externally to this Unified ICME parent system.
The Unified CVP or IVR PG pair controls the CVP Call Server which translates the IVR PG commands from
Unified ICME into VoiceXML and directs the VoiceXML to the Voice Gateways (VGs) at the remote contact
center sites. This allows calls from the data center location to come into the remote call centers under control
of the Unified CVP at the parent location. The parent then has control over the entire network queue of calls
across all sites and holds the calls in queue on the Voice Gateways at the sites until an agent becomes available.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
143
Design Considerations for High Availability
Unified CCE Gateway PGs at Unified ICME data center
For scalability limits of the co-resident Unified CCE Gateway PG and Unified CCE System PG, refer to Sizing
Unified CCE Components and Servers for additional details.
The Unified CCE Gateway PGs provide real-time event data and agent states to the parent from the Unified
CCE child. The Unified CCE Gateway PGs also capture configuration data (skill groups, services, call types,
and so forth) and send it to the parent Unified ICME configuration database as well.
The IP-IVR at the child site can be replaced with a local Unified CVP instance. Unified CVP is not integrated
as part of the Agent Controller's System PG; there is a separate IVR PG defined specifically for Unified CVP
as part of the installation for Unified CCE with Unified CVP. Because Unified CVP is not part of the System
PG, calls in queue or treatment in Unified CVP are not reported to the parent Unified ICME through the
Unified CCE Gateway PG.
A local Unified CCE child system is used to provide IP-ACD functionality and it can be sized depending on
the type of deployment required:
• Progger configuration with a single server or duplex server that contains the following Unified CCE
components: Call Router and Logger, System PG for Unified CM and IP IVR, CTI Server and CTI OS
Server, and optionally the VRU PG for Unified CVP.
• Rogger configuration with separate Unified CCE Agent Controller (System PG and optional Unified
CVP controller and CTI/CTI OS Server)
The Rogger configuration contains the Unified CCE components: Call Router and Logger as a single
set of duplex Central Controllers, and a separate Agent Controller set of duplex servers that contain the
System PG for Unified CM and IP IVR, CTI Server and CTI OS Server, and the optional VRU PG for
Unified CVP.
For more details about the capacity of these configurations, refer to Sizing Unified CCE Components and
Servers.
In either configuration, a separate Administration & Data Server is required to host the configuration and
scripting tools for the system as well as an optional Historical Database Server role and Web based Unified
Intelligence Center reporting tool.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
144
Design Considerations for High Availability
Parent/Child Call Flows
an Outsourcer/Service Bureau manages child site and connect to the Unified CCE Gateway PGs at the parent
site.
Figure 70: Parent/Child deployment with Unified CCE Gateway PGs at data center
There are several drawbacks with moving the Unified CCE Gateway PGs to the data center. One is specific
to recovering reporting data in the event of a network failure. If the network connection between the parent
site and the Unified CCE System PGs at the child drops, all reporting at the parent site is lost for that period.
Note If the Unified CCE Gateway PG is deployed locally to the Unified CCE System PG and the connection
between the Unified CCE Gateway PG and the parent site drops, the historical data in the parent site is
updated when the network connection is restored.
A second drawback with centralizing the Unified CCE Gateway PGs is that the network bandwidth requirements
for the connections between the Unified CCE Gateway PG and the Unified CCE System PG are significantly
higher. See the "Bandwidth Requirements for Unified CCE Gateway to System PG" section in the Bandwidth
Provisioning and QoS Considerations chapter for additional details.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
145
Design Considerations for High Availability
Typical Inbound PSTN Call Flow
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
146
Design Considerations for High Availability
Parent/Child Fault Tolerance
• For Unified CCE child configurations using local Unified CVP resources for queue and treatment with
Unified CCE 7.5(x):
◦The local VG must have dial peer statements to pass control of the calls to the local Unified CVP
Call Server at the child site. Also, the inbound DNIS or dialed numbers that the local VG will
present to the child Unified CVP must be configured in the child Unified CCE to process these
calls locally at the child site.
◦The local VXML Gateways and Unified CVP Call Servers must be configured with appropriate
.wav files and applications that can be called by the Unified CCE child system locally to provide
basic call treatment such as playing a welcome greeting or other messages.
◦Self-service or Unified CVP Studio VXML applications normally provided by the parent Unified
ICME must be replicated using Unified CVP VXML Server (web application server) at the child
site to generate the dynamic VXML for these applications.
◦The child Unified CCE Routing Script must handle queuing of calls for agents in local skill groups,
instructing the local Unified CVP at the child site to play treatment in-queue while waiting for an
agent.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
147
Design Considerations for High Availability
Unified CCX Child Loses WAN to Unified ICME Parent
◦Any data lookup or external CTI access that is normally provided by the parent Unified CVP or
the parent Unified ICME must be provisioned locally to allow the agents to have full access to
customer data for call routing and screen pops.
◦Any post-routing transfer scripts will fail during this outage, so Unified CCE must be configured
to handle this outage or prevent the post-route scripts from being accessed.
A similar failure occurs if the local Unified CVP ingress VGs controlled by the parent Unified CVP Call
Server cannot see the parent Unified ICME CVP Call Servers. The local Unified CVP gateways are configured
to fail-over to the local Unified CM (or child Unified CVP) to route calls to the Unified CCX agents as
described above. Likewise, if the entire Unified ICME parent were to fail, the local VGs controlled by the
parent Unified CVP at the sites would no longer have call control from the Unified ICME parent, and calls
would forward to the local sites for processing.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
148
Design Considerations for High Availability
Reporting and Configuration Impacts
calls were sent to the local Unified CM while the child Unified CCE or Unified CCX system was down, the
call-forward-on-failure processing would take over the call for the CTI route point. This method would redirect
the call to another site or an answering resource to play a message telling the caller there was an error and to
call again later.
Reporting
The Unified CCE reporting feature uses real-time, five-minute and reporting interval (15 or 30 minute) data
to build its reporting database. Therefore, at the end of each five-minute and reporting interval (15 or 30
minute), each Peripheral Gateway will gather the data it has kept locally and send it to the Call Routers. The
Call Routers process the data and send it to their local Logger for historical data storage. That data is then
replicated to the HDS database from the Logger as it is written to the Logger database.
The Peripheral Gateways provide buffering (in memory and on disk) of the five-minute and reporting interval
(15 or 30 minute) 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. However, 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. Use redundant Peripheral Gateways to reduce the chance
of losing both physical hardware devices and their associated data during an outage window.
When agents log out, all their reporting statistics stop. The next time the agents log in, their real-time statistics
start from zero. Typically, Central Controller fail-over does not force the agents to log out or reset their
statistics; however, if the PG fails-over, their agent statistics are reset because the PIM and OPC processes
that maintain these values in memory are restarted. If the CTI OS or CAD servers do not fail-over or restart,
the agent desktop functionality is restored to its pre-fail-over state.
For further information, see the Reporting Guide for Cisco IPCC Enterprise & Hosted Editions.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
149
Design Considerations for High Availability
Other Considerations for High-Availability
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
150
CHAPTER 4
Unified Contact Center Enterprise Desktop
The Cisco Unified Contact Center Enterprise (CCE) solution delivers a comprehensive set of desktop
applications and services.
Desktop Components
The desktop applications themselves typically run on Agent desktops, Supervisor desktops, Administration
& Data Servers or Administration Client. Services supporting the desktop applications typically run on the
Unified CCE Peripheral Gateway (PG) server. Within the Unified CCE deployment, there may be one or
more PG systems, and for each PG there is one set of active desktop services, which includes the CTI Object
Server (CTI OS) and the Cisco Agent Desktop Base Services for Cisco Agent Desktop (CAD) deployments.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
151
Unified Contact Center Enterprise Desktop
CTI Object Server
The following figure depicts the components within a Unified CCE deployment that support the various
desktop applications.
In the Unified CCE solution, the Peripheral Gateway may be deployed in either a simplex or duplex
configuration. (Simplex mode is not supported for production environments.) Duplex configurations provide
redundant desktop services for fail-over recovery support. These systems are typically identified as the primary,
or A-side, and the backup, or B-side. For production deployments, a duplex configuration is required.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
152
Unified Contact Center Enterprise Desktop
CAD Base Services
Call control flows from the agent desktop application to Cisco Unified Communications Manager (Unified
CM). Unified CM then performs the requested call or device control. The desktop services located on the PG
keep the agent desktop application synchronized with the agent’s IP phone state.
CTI Toolkit desktop configuration and behavior information is also managed at the CTI OS server, simplifying
customization, updates, and maintenance, and supporting remote management.
Note Desktop Security is not currently available in the .NET and Java CILs.
• Quality of Service (QoS) — Supports packet prioritization with the network for desktop call control
messages.
Note QoS is not currently available in the .NET and Java CILs.
The CTI Object Server is typically installed in duplex mode, with two CTI OS servers running in parallel for
redundancy, one on PG side-A and one on PG side-B. The CTI Toolkit Desktop applications randomly connect
to one of the two servers and automatically fails-over to the alternate server if the connection to the original
CTI OS server fails. CTI OS can also run in simplex mode with all clients connecting to a single server, but
Cisco does not recommend this configuration. (Simplex mode is not supported for production environments.)
Agent capacity sizing for the PG is covered in the chapter on Sizing Unified CCE Components and Servers.
Note The CTI OS server interfaces to any desktop application built using the CTI Toolkit Software Development
Kit. A single CTI OS server can support the use of both CAD and CTI Toolkit desktops concurrently.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
153
Unified Contact Center Enterprise Desktop
Agent Desktops
Agent Desktops
An agent desktop application is a required component of a Unified CCE deployment. The contact center agent
uses this application to perform agent state control (login, log out, ready, not ready, and wrap-up) and call
control (answer, release, hold, retrieve, make call, transfer, and conference). In addition to these required
features, the application can provide enhanced features that are useful in a contact center environment.
Cisco offers the following primary types of Unified CCE agent desktop applications:
• Cisco Agent Desktop (CAD) — A packaged agent desktop solution supporting an embedded browser
and scripted workflow automation.
• Cisco Finesse Desktop — A browser-based agent desktop solution that provides a gadget-based
architecture for extending base agent functionality.
• CTI Toolkit Desktop — An agent desktop application built with the CTI Toolkit that supports full
customization and integration with other applications, customer databases, and Customer Relationship
Management (CRM) applications.
• Cisco Unified CRM Connector for Siebel — A CTI driver for the Siebel Communication Server.
• Cisco Unified IP Phone Agent — An agent desktop solution provided through the Cisco Unified IP
Phone display.
• Cisco Agent Desktop Browser Edition (CAD-BE) — A browser-based agent application that supports
many of the features of the CAD windows-based agent application with lower platform requirements.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
154
Unified Contact Center Enterprise Desktop
Agent Mobility
• Partner Agent Desktops — Custom agent desktop applications are available through Cisco Technology
Partners. These applications are based on the CTI Toolkit and are not discussed individually in this
document.
• Prepackaged CRM integrations — CRM integrations are available through Cisco Unified CRM
Technology Partners. They are based on the CTI Toolkit and are not discussed individually in this
document.
Agent Mobility
Within the Unified CCE deployment, the agent desktop application is not statically associated with any specific
agent or IP phone extension. Agents and phone extensions (device targets) are configured within the Unified
CCE configuration and associated with a specific Unified Communications Manager cluster.
When logging in from an agent desktop application, a dialog box prompts for the agent ID or login name,
password, and the phone extension for that session. From that data, the system dynamically associates the
agent ID, phone extension, and agent desktop IP address. The system releases the association when the agent
logs out.
This mechanism enables an agent to work (or hot-desk) at any workstation. Agents can take their laptops to
any Cisco Unified IP Phone and log in from that device (if the phone is properly configured in Unified CCE
and in Unified Communications Manager). Agents can also log in to other phones using the Cisco Extension
Mobility feature. For more information about Extension Mobility, see the Extension Mobility section of the
Cisco Unified Communications Manager Features and Services Guide.
Supervisor Desktops
In addition to the agent desktop application, Cisco offers a supervisor desktop application. The contact center
supervisor uses this application to monitor agent state for members of their team. The supervisor desktop also
enables Silent Monitoring of agents during active calls.
Cisco offers the following types of Unified CCE supervisor desktop applications:
• Cisco Supervisor Desktop (CSD) — A packaged supervisor desktop solution.
• CTI Toolkit Supervisor Desktop — A supervisor desktop application, built with the CTI Toolkit that
supports customization and integration with other applications, customer databases, and Customer
Relationship Management (CRM) applications.
• Cisco Finesse Supervisor Desktop — A fully browser-based supervisor application that extends the base
Finesse Agent Desktop with supervisor capabilities.
• Supervisor Desktop Applications Offered through Cisco partners
• Prepackaged CRM integrations — CRM integrations are available through Cisco Unified CRM
Technology Partners. They are based on the CTI Toolkit and are not discussed individually in this
document.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
155
Unified Contact Center Enterprise Desktop
Desktop Solutions
Desktop Solutions
Depending on the requirements of the contact center, a particular type of desktop might be better suited to the
solution. The following table provides an abbreviated list of the functionality available in the various desktop
applications. It is intended to provide a starting point to determine the desktop that best meets specific solution
requirements. Further information is available for each of the Cisco desktops in the sections below and in
their respective product specifications at Cisco.com.
Desktop Cisco Cisco Agent CTI Toolkit Cisco Unified IP Phone Cisco
Functionality Agent Desktop CRM Agent Finesse
Desktop Browser Connector for Desktop
Edition Siebel
Turn-key desktop Yes Yes Yes Yes Yes Yes
applications
Custom Yes
development using
standard web
components
(HTML, JavaScript)
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
156
Unified Contact Center Enterprise Desktop
Desktop Solutions
Desktop Cisco Cisco Agent CTI Toolkit Cisco Unified IP Phone Cisco
Functionality Agent Desktop CRM Agent Finesse
Desktop Browser Connector for Desktop
Edition Siebel
Integrated Yes Yes Yes
Recording Capacity
Specific capability
or integration not
offered by Cisco
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
157
Unified Contact Center Enterprise Desktop
Cisco Agent Desktop Solution
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
158
Unified Contact Center Enterprise Desktop
CAD Application Features
• Cisco Desktop Work Flow Administrator: Windows-based work flow configuration tool
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
159
Unified Contact Center Enterprise Desktop
Cisco Finesse Agent/Supervisor Desktop
*
For more detailed information about supported monitoring and recording, refer to Configuring and
Troubleshooting VoIP Monitoring at http://www.cisco.com/c/en/us/support/customer-collaboration/
agent-desktop/products-troubleshooting-guides-list.html.
**
Call control actions are performed by using the IP phone call control softkeys.
For more information about CAD agent applications, see the appropriate user guide.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
160
Unified Contact Center Enterprise Desktop
Cisco Agent Desktop
• Authentication with Unified CCE over a direct connection to the Unified CCE AW Database. Finesse
requires that the AW Database is configured to use Windows authentication and that the user configured
for Finesse database access is a domain user.
• An active/active deployment model where both Finesse servers connect to the active CTI Server on the
Agent PG.
• Redundancy through the standard Cisco VOS replication mechanism.
Finesse supervisor features extend the agent desktop with additional gadgets that are accessible to supervisors
configured in Unified CCE. These features include the following:
• Team Performance gadget for viewing agent status
• Queue Statistics gadget for viewing queue (skill group) statistics for the supervisor’s queues
• Silent Monitoring
• Barge In
• Intercept
Cisco Finesse includes an administrative application that allows for the configuration of the following:
• CTI Server and AW Database connections
• Cluster settings for VOS replication
• Reason and Wrap Up codes
• Phone books
• Team resources
• Finesse layout configuration (media properties and gadget layout)
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
161
Unified Contact Center Enterprise Desktop
Cisco Agent Desktop Browser Edition
The figure below illustrates various ways agent desktops can be configured in a contact center.
• Agent A shows an agent who uses a hardware IP phone. The IP phone connects directly to the agent’s
PC through a network cable. This is the configuration required for desktop monitoring. CAD supports
a VPN connection between the agent PC and the contact center network.
• Agent B shows an agent who uses Cisco IP Communicator. This configuration also supports a VPN
connection to the contact center network. This is the most common configuration for mobile agents.
• Agent C shows Agent Desktop used with the Mobile Agent feature. Mobile agents are agents whose
phones are not directly controlled by Unified CM. Agents might use their home phones or cell phones
as their agent device. In this case, the agent provides a CTI port to associate with their remote phone
when logging in. ACD calls for the logged-in agent are sent to the CTI port, which causes the call to
appear at the mobile agent’s phone device. There is a logical relationship (the dashed line) between the
agent and the mobile phone. CAD supports a VPN connection between the agent and the contact center
network in this configuration. Mobile agents can be monitored and recorded using SPAN monitoring.
For more information about Cisco Agent Desktop features and capabilities, see the Cisco Agent Desktop User
Guide at http://www.cisco.com/c/en/us/support/customer-collaboration/agent-desktop/
products-user-guide-list.html.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
162
Unified Contact Center Enterprise Desktop
Cisco Agent Desktop IP Phone Agent
• Desktop Monitoring and Recording is not supported. CAD-BE does Support Server Monitoring and
Recording and Unified CM monitoring.
• The integrated browser is external to the CAD-BE window and is launched when CAD-BE is launched.
• The click to dial from browser feature is not supported.
• Agents cannot modify enterprise data.
• The dial pad does not support dial string formatting, phone books, or recent call list.
• Window behavior (for example, stealth or always on top) cannot be configured by the agent.
•
For more information about CAD-BE features and capabilities, see the Cisco Agent Desktop—Browser Edition
User Guide.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
163
Unified Contact Center Enterprise Desktop
Cisco Desktop Administrator
Supervisors are able to view real-time information about the agents in a team as well as interact with those
agents. The supervisor can:
• View and change an agent’s state
• View contact information specific to the agent
• Silently monitor and/or record the agent’s calls
• Barge-in or intercept an agent’s call
• Chat with the agent using an instant message window
• Push a web page to the agent’s desktop
When Supervisor Desktop is installed, an instance of Agent Desktop is installed as well. Agent Desktop is
needed by the supervisor to take calls, barge in, intercept, and retrieve skill group statistics.
The Supervisor Work Flow module enables configurable actions to be triggered when specific events occur
in the contact center. For example, a supervisor work flow can be set up so that whenever more than ten calls
are in queue for a specified skill group, an audible alert sounds and the skill group name is highlighted in red
on the supervisor’s desktop. Another work flow sends an email to specified email addresses when certain
events occur. The email contains information related to the condition that caused the event, as well as custom
text.
Supervisors can use the Supervisor Record Viewer to review recordings and mark selected recordings for
extended retention. The supervisor can also save recordings for permanent retention in a format that can be
played by any media player.
For more information about Supervisor Desktop features and capabilities, see the CTI OS Supervisor Desktop
User Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted at http://www.cisco.com/c/en/us/
support/customer-collaboration/unified-contact-center-enterprise/products-user-guide-list.html.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
164
Unified Contact Center Enterprise Desktop
Cisco Desktop Monitoring Console
Dial strings, phone books, reason codes, and wrap-up data can be configured on the global and work flow
group level.
Work flows and user interfaces can be configured for specific agent types.
Cisco Desktop Administrator is used to configure the following:
• Enterprise data fields and layouts
• Silent Monitoring and recording
• Personnel and assigning users to work flow groups
• Cisco Unified Presence settings
For more information about Cisco Desktop Administrator features and capabilities, see the CAD documentation
at http://www.cisco.com/c/en/us/support/customer-collaboration/agent-desktop/products-user-guide-list.html.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
165
Unified Contact Center Enterprise Desktop
CTI OS Desktop Toolkit Software Development Kits and User Applications
• Java CIL API—A cross-platform library for developing Java CTI applications
• .NET CIL API—A Windows software development kit for developing custom .NET framework CTI
applications
• COM CIL API—A set of COM Dynamic Link Libraries (COM DLL) for building a Visual Basic 6.0
CTI application
• ActiveX Controls—A set of Windows GUI controls for custom desktop development using Development
environments that support ActiveX technology. For example Visual Basic 6.0
• CTI OS Runtime Callable Wrappers—A set of .NET assemblies that allows the use of COM CIL and
ActiveX controls in native .NET applications
• CTI Toolkit Agent Desktop — A Windows Visual Basic application built on the COM CIL and Active-X
controls, providing agent desktop functionality
• CTI Toolkit Supervisor Desktop—A Windows Visual Basic application built on the COM CIL and
Active-X controls, providing supervisor desktop functionality
• CTI Toolkit Outbound Desktop—A Windows Visual Basic application built on the COM CIL and
Active-X controls, supporting outbound call center campaigns in addition to standard agent desktop
functionality
• CTI Toolkit Combo Desktop—A Windows agent and supervisor application based on the .NET CIL,
which combines support for agent, supervisor, and outbound functionality
• CTI Toolkit All-Agents Monitor—A Windows Admin application based on the C++ CIL, providing
call center agent status monitoring
• CTI Toolkit All-Calls Monitor—A Windows Admin application based on the C++ CIL, providing call
center call status monitoring
Note The CTI Toolkit All-Agents and All-Calls Monitor applications can be used only if the number of skill
groups per agent is less than 20.
Note The CTI OS Desktop Toolkit C++/COM CIL is the only APIs that support Agent Greeting Enable/Disable
and Agent Greeting Recording.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
166
Unified Contact Center Enterprise Desktop
CTI OS Desktop Toolkit Software Development Kits and User Applications
The following figure illustrates the architecture of the CTI OS Desktop Toolkit. For more information regarding
the CTI OS Desktop Toolkit, see the CTI OS Developer's Guide for Cisco ICM/IPCC Enterprise and Hosted
Editions.
ActiveX Controls
The CTI Toolkit includes a set of ActiveX controls to enable rapid application development. The ActiveX
controls are UI components that enable easy drag-and-drop creation of custom CTI applications in a variety
of container applications. Container applications include Microsoft Visual Basic.NET, Microsoft Internet
Explorer, Microsoft Visual C++ 8.0, Borland Delphi, Sybase PowerBuilder, and other applications supporting
the OC96 ActiveX standard.
The ActiveX Controls include:
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
167
Unified Contact Center Enterprise Desktop
CTI OS Desktop Toolkit Software Development Kits and User Applications
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
168
Unified Contact Center Enterprise Desktop
Cisco Unified CRM Connector for Siebel Solution
a team as well as interact with these agents. A supervisor can select an agent to change the agent’s state, view
information specific to that agent, silently monitor the agent’s call, barge in or intercept the agent’s call, or
chat with the agent.
A supervisor may also receive emergency assistance requests from agents on their team through the supervisor
desktop.
In Unified CCE, supervisors may also be configured to act as agents. When this is done, the standard set of
agent phone controls is available on the Supervisor Desktop.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
169
Unified Contact Center Enterprise Desktop
Deployment Considerations
Deployment Considerations
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
170
Unified Contact Center Enterprise Desktop
Silent Monitoring
For implementation details, see Integrating CAD into a Citrix MetaFrame Presentation Server or Microsoft
Terminal Services Environment.
Note CTI-OS supports virtualized desktop infrastructure from Citrix and VMware. CTI-OS also supports Cisco
VXI endpoints. When you deploy VDI or VXI, the performance, bandwidth, and timing requirements for
CTI-OS, as defined in this document, must still be met.
Silent Monitoring
Silent Monitoring enables supervisors to monitor the conversations of agents within their team. Supervisors
are not able to participate actively in the conversation, and the agents and callers are unaware they are being
monitored. Cisco Agent Desktop, CTI Object Server (CTI OS), and Cisco Finesse provide solutions support
for Silent Monitoring. CAD Server-based monitoring supports Agent Desktops, IP Phone Agents, and Mobile
Agents. Desktop Monitoring supports only desktop agents. CTI OS Releases 7.2 and higher support two types
of Silent Monitors: CTI OS based Silent Monitor and Unified CM Silent Monitor. Cisco Finesse supports
Unified CM Silent Monitor only.
CTI OS based Silent Monitoring is accomplished by using one or more VoIP monitoring services located
either on the agent’s desktop (desktop monitoring) or on a separate VoIP monitor server (server-based
monitoring). CTI OS uses server-based Silent Monitoring to support mobile agents and desktop-based Silent
Monitoring to support traditional (non-mobile) Unified CCE agents.
Unified CM accomplishes Silent Monitoring with a call between the supervisor's (monitoring) device and
agent’s (monitored) device. The agent’s phone mixes and sends the agent’s conversation to the supervisor's
phone, where it is played out to the supervisor. Unified CM Silent Monitoring can be initiated by any of the
CTI OS supervisors’ desktops (out-of-the-box, Java, or .NET).
Any Unified CCE agent desktop, including Siebel, can be silently monitored using Unified CM Silent
Monitoring, provided that the following requirements are met:
• The agent that is silently monitored is using a Cisco Unified IP Phone 7941, 7942, 7945, 7961, 7962,
7965, 7970, 7971, or 7975, and Cisco IP Communicator Release 7.0 or higher.
• The contact center is using Cisco Unified CM Release 8.0 or higher. For details, see the Unified CCE
compatibility specifications.
• When a CTI OS based Silent Monitor is used, the Cisco IP Phones, including Cisco IP Communicator,
must be configured to use RTP streams (SRTP streams cannot be silently monitored).
• Unified CM Silent Monitoring does not support mobile agents.
• Unified CM Silent Monitoring supports a maximum of one Silent Monitoring session and one recording
session for the same agent phone.
• Supervisors can use any Cisco IP Phone, including Cisco IP Communicator, to monitor silently.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
171
Unified Contact Center Enterprise Desktop
Unified CM Silent Monitor
Note g.722 is used as the default codec for regions that are configured for g.711 on devices that support g.722.
However, g.722 is not supported with Silent Monitoring and Call Recording based on CAD, CTI OS, or
Unified CM. To disable this default, in Unified CM Administration go to Enterprise Parameters and set
Advertise g.722 Codec to disabled.
Note ASA does not currently support the type of call flow that the Silent Monitoring feature uses.
The following figure illustrates the following message flow, which occurs when the Unified CM Silent Monitor
is initiated by the supervisor’s desktop:
1 The supervisor initiates Silent Monitoring by sending the Agent.SuperviseCall() message to Unified CCE.
2 Unified CCE sends the Call.startMonitor() message to Unified CM.
3 Unified CM instructs the supervisor's phone to call the built-in-bridge in the agent’s phone.
4 The supervisor's phone places the call to the built-in-bridge in the agent’s phone.
5 The agent’s phone forwards a mix of the agent’s voice stream and customer's voice stream.
6 Call events for the silently-monitored call are sent from Unified CM to Unified CCE.
7 CTI OS sends a SilentMonitorStarted event to the supervisor’s desktop.
8 CTI OS sends a SilentMonitorStarted event to the agent’s desktop.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
172
Unified Contact Center Enterprise Desktop
CTI OS Based Silent Monitor
9 CTI OS sends call events for the silently-monitored call to the supervisor’s desktop.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
173
Unified Contact Center Enterprise Desktop
CTI OS Based Silent Monitor
the Citrix Server. Agents and supervisors use a Citrix client to run the desktop. When this is done, the desktop
runs on the Citrix server. The Citrix client merely displays the UI of the desktop. Because it is the agent’s
Citrix client that is deployed behind the IP phone, the CIL no longer has access to the voice path. Similarly,
it is the supervisor's Citrix client that has the sound card. In this case, the CIL is running on the Citrix Server
and does not have access to the sound card.
In Mobile Agent deployments, the CIL is deployed on an agent’s remote PC. When the agent uses an analog
phone, the CIL does not have access to the voice stream.
To support these two deployment models, it was necessary to remove the Silent Monitor components from
the CIL and put them on a separate service. This allows the service to be deployed where it has access to the
agent’s voice stream or the supervisor's sound card.
The following figures show where the Silent Monitoring service should be deployed for each deployment
model. The red line in each diagram illustrates the path of the monitored voice stream.
Figure 77: CTI OS Based Silent Monitoring for Cisco Unified CCE When a Mobile or Local Agent Uses an
IP Phone , on page 174 and Figure 78: CTI OS Based Silent Monitoring for Cisco Unified CCE with Citrix
When a Mobile or Local Agent Uses an IP Phone , on page 175 illustrate deployments where the agent uses
an IP phone. In these deployments, Silent Monitoring is configured the same way regardless of whether the
agent is mobile or not.
Figure 77: CTI OS Based Silent Monitoring for Cisco Unified CCE When a Mobile or Local Agent Uses an IP Phone
The deployment in Figure 77: CTI OS Based Silent Monitoring for Cisco Unified CCE When a Mobile or
Local Agent Uses an IP Phone , on page 174 is very similar to CTI OS Release 7.0 and earlier deployments.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
174
Unified Contact Center Enterprise Desktop
CTI OS Based Silent Monitor
The only difference is that the Silent Monitoring service is running alongside the CIL to provide Silent
Monitoring functionality.
Figure 78: CTI OS Based Silent Monitoring for Cisco Unified CCE with Citrix When a Mobile or Local Agent Uses an IP
Phone
In the deployment model in Figure 78: CTI OS Based Silent Monitoring for Cisco Unified CCE with Citrix
When a Mobile or Local Agent Uses an IP Phone , on page 175, the Silent Monitoring service is deployed on
Citrix clients, where it has access to the agent’s voice stream and the supervisor's sound card. The CIL makes
a connection to the Silent Monitoring service and sends it instructions over a TCP connection to start and stop
Silent Monitoring sessions.
Figure 79: Silent Monitoring for a Mobile Agent Using a PSTN Phone
In the deployment model in Figure 79: Silent Monitoring for a Mobile Agent Using a PSTN Phone , on page
175, one Silent Monitoring service is deployed on a switch's SPAN port to gain access to voice traffic passing
through the agent gateway. Agents to forward their voice streams to the supervisor Silent Monitoring services
use the Silent Monitoring service attached to the SPAN port.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
175
Unified Contact Center Enterprise Desktop
Clusters
Supervisors running locally are deployed the same as Unified CCE supervisors. Supervisors running remotely
are also deployed the same as Unified CCE supervisors, but a Cisco 800 Series Router with hardware-based
VPN is required in order for the supervisor to receive agent voice streams.
Figure 80: Silent Monitoring for a Mobile Agent Using a PSTN Phone with Citrix or Microsoft Terminal Services
In the deployment model in Figure 80: Silent Monitoring for a Mobile Agent Using a PSTN Phone with Citrix
or Microsoft Terminal Services , on page 176, one Silent Monitoring service is deployed on a switch's SPAN
port to gain access to voice traffic passing through the agent gateway. Agents to forward their voice streams
to the supervisor Silent Monitoring services use the Silent Monitoring service attached to the SPAN port.
Mobile agents need to run only their Citrix clients. Agent desktops running on the Citrix server will connect
to the Silent Monitoring server.
Supervisors running locally are deployed the same as Citrix Unified CCE supervisors. Supervisors running
remotely are also deployed the same as Citrix Unified CCE supervisors, but a Cisco 800 Series Router with
hardware-based VPN is required in order for the supervisor to receive agent voice streams.
In the two mobile agent deployments above (Figure 79: Silent Monitoring for a Mobile Agent Using a PSTN
Phone , on page 175 and Figure 80: Silent Monitoring for a Mobile Agent Using a PSTN Phone with Citrix
or Microsoft Terminal Services , on page 176), calls whose voice traffic does not leave the agent gateway
cannot be silently monitored. This includes agent-to-agent calls as well as agent consultations with other
agents. The only calls that can be reliably monitored in this case are calls between agents and customers. This
is because the mobile agent solution requires separate gateways for callers and agents to ensure that voice
traffic is put on the network.
Clusters
If a mobile agent’s login can be handled by one of two gateways, it is possible to cluster two and only two
Silent Monitoring servers together to provide Silent Monitoring functionality regardless of the gateway that
handles the call. A maximum of two Silent Monitoring servers are supported in a cluster (SPAN) based
deployment. When a request to silently monitor the agent is received, the Silent Monitoring server that receives
the request from the agent desktop will forward the request to its peer, and then both Silent Monitoring servers
will attempt to detect the stream. Once the agent’s voice stream is detected, it is forwarded to the supervisor's
Silent Monitoring service by the Silent Monitoring server that detected the stream.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
176
Unified Contact Center Enterprise Desktop
Message Flow
For more information regarding deployment and configuration of the Silent Monitoring service, see the CTI
OS System Manager's Guide for Cisco ICM/IPCC Enterprise & Hosted Editions.
Message Flow
The figure below illustrates the messaging that occurs between the desktops, CIT OS Server, and Silent
Monitoring services when a Silent Monitor session is initiated. Note that messaging between the desktops
and the CTI OS Server has not changed from CTI OS Release 7.0.
Figure 81: Message Flow Between Desktops, CTI OS Server, and Silent Monitoring Service
Connection Profiles
In mobile agent deployments, agent desktops learn where and how to connect to their Silent Monitoring server
using a CTI OS connection profile. When an agent logs in, the agent desktop uses the following algorithm to
determine where the Silent Monitoring service is located:
1 If a Silent Monitoring service is present in the connection profile, attempt to connect to it.
2 If no Silent Monitoring service is present, determine if the desktop is running under Citrix.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
177
Unified Contact Center Enterprise Desktop
CAD Silent Monitoring and Recording
3 If the desktop is running under Citrix, connect to the Silent Monitoring service running at the Citrix client's
IP address.
4 If the desktop is not running under Citrix, connect to the Silent Monitoring service running at localhost.
Supervisor desktops use the following algorithm to find their Silent Monitoring service:
1 If the desktop is running under Citrix, connect to the Silent Monitoring service running at the Citrix client's
IP address.
2 If the desktop is not running under Citrix, connect to the Silent Monitoring service running at localhost.
If the IPCCSilentMonitorEnabled key is set to 0 in the connection profile, no attempt is made to connect to
a Silent Monitoring service.
Note CAD recording is not suitable for use as a compliance recording solution. This functionality is best for
on-demand recording or recording on a filtered list of calls only.
CAD-Based Monitoring
CAD-based monitoring consists of three types of monitoring:
• Desktop Monitoring
• Server Monitoring
• Mobile Agent Monitoring
Desktop Monitoring
Desktop Monitoring uses software running on the agent’s desktop (Cisco Agent Desktop) to sniff the network
traffic going to and from the agent’s phone (hardware phone or software phone) for RTP packets. The monitoring
software then sends the RTP packets to the appropriate software over the network for decoding. Desktop
Monitoring relies on the ability for certain Cisco IP Phones to be daisy-chained with the agent’s PC by using
a network connection and for the phones to send all its network traffic along this connection to the software
running on the PC. In this case, the packet-sniffing software can see the voice traffic flowing to and from the
agent’s phone. It will copy this traffic and send it to the supervisor that is monitoring the agent or to a recording
service for the call to be stored and to be listened to at some later time. Desktop Monitoring is not a true
service, at least from the perspective of the Service Control Manager. It is a Dynamic-Link Library (DLL),
an executable module that is part of Cisco Agent Desktop.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
178
Unified Contact Center Enterprise Desktop
Server Monitoring
Server Monitoring
Server monitoring uses one or more Cisco Desktop VoIP Monitor Services to sniff the network running over
a Cisco Catalyst switch for voice streams. The Cisco Desktop VoIP Monitor Service looks for particular
streams to and from phones being monitored or recorded. It then sends the voice packets to the supervisor
desktop that is performing the monitoring or to a recording service for storage.
The Cisco Desktop VoIP Monitor Service uses the Switched Port Analyzer (SPAN) or Remote SPAN (RSPAN)
monitoring feature of certain Cisco Catalyst switches to sniff the network. The switch uses the monitoring
feature to copy the network traffic from one or more sources to a destination port. Sources can be ports and/or
Virtual LANs (VLANs). RSPAN allows the source ports to reside on remote switches. The Cisco VoIP
Monitor Service connects to the switch by using the destination port. This allows the Cisco VoIP Monitor
Service to see the voice traffic going to and coming from IP phones.
Recording
Recording is fault tolerant. If a recording service fails in a high-availability deployment, the other recording
service will assume all recording responsibilities.
Recording Playback
Playback of recordings is not fault tolerant. Recordings are tied to the recording service that captured the
recording. If a recording service fails, all recordings associated with that service is unavailable until it is
restored.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
179
Unified Contact Center Enterprise Desktop
Load Balancing for CAD-Based Monitoring and Recording
Recording
Recording services are selected in round-robin fashion at runtime by the desktops. However, no attempt is
made to ensure that the load is balanced between the recording services.
For a further description of these components, see the Cisco Remote Silent Monitoring Installation and
Administration Guide, available at cisco.com.
Platform Considerations
The Remote Silent Monitoring solution is highly integrated into the Cisco Unified Contact Center Enterprise
environment. Because of this, the functioning of RSM requires resources from various other components of
the platform as a whole. To properly integrate RSM, then, requires an understanding of its interactions with
the rest of the environment so that capacity can be properly planned, provisioned, and managed.
In particular, RSM interacts mainly with the Unified Communications Manager cluster.
The RSM server has two tie-ins with each Unified Communications Manager cluster in the environment that
it is configured to use:
• Simulated Phones
The RSM PhoneSim component requires that a Cisco Unified IP Phone 7941 device entry be created
on the Unified CM cluster for each of the simulated phones ("simphones") it is configured to manage.
For instance, a RSM system that is configured to handle up to 100 dialed-in supervisors monitoring
agents on a particular Unified Communications Manager cluster must have at least 100 simphones. To
the Unified CM cluster, these simphones appear as Cisco Unified IP Phone 7941 SIP phones; however,
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
180
Unified Contact Center Enterprise Desktop
Cisco Remote Silent Monitoring
in reality they are homed to PhoneSim and controlled by PhoneSim, instead of being an actual physical
phone device.
When compared with the usage profile of a physical phone device, the simphone usually puts a lighter
load on the Unified Communications Manager cluster. This is because it exhibits only a small set of
behaviors, consisting of:
• Registering with the Unified Communications Manager cluster when PhoneSim is started.
• Making a "monitoring call" to an agent’s phone when a dialed-in supervisor requests to monitor
that agent. The agent’s phone then forks off a copy of the conversation that the agent is having to
the simphone.
• JTAPI
When RSM is integrated into the environment, a JTAPI user is created and associated with each agent
phone device that can be monitored, as well as with each simphone device that was created on the cluster.
When an agent is to be monitored, a JTAPI monitor request call is made from the RSM server to the
Unified CM cluster that manages that agent’s phone. Also, while RSM is in use, a JTAPI CallObserver
is kept attached to each simphone device. It is also attached to an agent phone device, but only while
the JTAPI monitor request is being issued to that device.
JTAPI connections may optionally be encrypted. However, this will induce a slight performance penalty
on the server itself when higher agent loads are utilized. For more information about enabling JTAPI
connection security, see the Cisco Remote Silent Monitoring Installation and Administration Guide,
available at cisco.com.
CTI OS Server
RSM makes a persistent "monitor-mode" connection to each CTI OS server that it is configured to use. Through
this connection, certain platform events are streamed in real-time. These platform events include call start,
call end, agent on hold, and so forth.
RSM also makes an additional, short-lived "agent-mode" connection to possibly each CTI OS server when a
supervisor dials in and authenticates. The purpose of this connection is to validate the supervisor's credentials
by performing a corresponding login into CTI OS. Note that this connection is not made if the built-in
authentication mechanisms of the RSM call flow (for example, the checkCredentials API call) are not used.
If the login is successful, that supervisor's team membership is requested by the RSM server. Once returned,
a logout is called and the connection is terminated.
Note that the total supervisor count in Unified CCE must be spread across CTI OS desktop users and RSM.
For example, in a 2,000 agent configuration, up to 200 agents can be supervisors. This means that the total
supervisor count between CTI OS and RSM must not exceed 200.
CTI OS connections can be optionally encrypted through the use of IP Sec configurations. However, this
optional encryption will induce a significant performance penalty on the server itself when higher agent loads
are utilized. For more information about enabling CTI OS connection security, see the Cisco Remote Silent
Monitoring Installation and Administration Guide, available at cisco.com.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
181
Unified Contact Center Enterprise Desktop
Cisco Remote Silent Monitoring
Furthermore, RSM calls often place higher loads on the VRU processor and memory than more traditional
IVR-type calls. These RSM loads are higher because more traditional IVR call flows play shorter, and
oftentimes cached or non-streamed prompts. These prompts are separated by periods of caller input gathering
and silence. With RSM, however, the predominant caller activity is monitoring an agent’s call. To the VRU,
this looks like the playback of a long-streaming audio prompt, which requires a relatively higher level of VRU
processor involvement.
With Unified CVP deployments, supported VXML gateway models are listed in the Hardware and System
Software Specification for Cisco Unified Customer Voice Portal (Unified CVP), otherwise known as Unified
CVP Bill of Materials (BOM), available at cisco.com.
When provisioning a VRU for use by RSM, a good rule of thumb is to count each RSM call as 1.3 non-RSM
calls on a processor/memory-usage basis. So for a VRU that can normally handle 40 concurrent calls, plan
for it to be able to handle only 30 RSM calls, that is (40/1.3) = 30.
Also note that RSM makes extensive use of VXML Voice Browser functionality under both Unified CVP
and IP IVR.
RSM Release 9.1 and later support RTSP prompt streaming, and, therefore, no longer require a dedicated
VXML Gateway for Unified CVP installations. (In other words, you do not need to configure the 'ivr prompt
streamed http' option in VXML Gateway, which conflicts with Unified CVP IOS requirements). Due to this
change, RSM scalability on Unified CVP has been improved to support 80 concurrent sessions on any Unified
CVP-supported VXML Voice Gateway model and IOS version. RTSP streaming support for Unified CVP
eliminates the previous high gateway memory requirement, as well as the Unified CVP monitoring call duration
limit default (a maximum of twenty minutes).
Agent Phones
Use of RSM to monitor an agent requires that that agent’s phone be a third-generation Cisco Unified IP Phones
79x1, 79x2, 79x5, 7970, or newer. This is because these third-generation phones include extra DSP resources
in the form of a Built-in-Bridge (BiB). The BiB allows the phone to fork off a copy of the current conversation
stream to the RSM server.
Cisco Unified Contact Manager provides for a maximum of one active monitoring session per agent because
the agent’s phone can handle only one active monitoring session and one active recording session at any given
time.
So, if a third-party recorder is recording the agent’s conversations, the agent can still be monitored by a
supervisor using supervisor’s desktop or RSM. However, if both a RSM-based supervisor and a
supervisor-desktop-based supervisor both tried to monitor the agent during the same time period, the request
fails with the last one to try because it exceeds the above-mentioned monitoring limit.
Note that RSM will set up only one monitoring session through Unified CM for a single monitored agent,
even if two or more RSM users are requesting to monitor the agent’s call at the same time. In this case, RSM
forks the stream to cover all RSM users. This allows more than two RSM-based supervisors to monitor the
same agent, for instance. However, if there are multiple RSM servers in the environment that monitor the
same agent, they will each make a separate monitoring call to that agent.
If the monitoring call limit has been reached for a specific agent and a dialed-in supervisor then attempts to
monitor this same agent, the supervisor's request is denied through an audio prompt feedback from the system
stating that the agent cannot be monitored.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
182
Unified Contact Center Enterprise Desktop
Cisco Remote Silent Monitoring
these agents distributed across multiple PGs and supports up to six PG clusters configuration on each server.
In all supported RSM configurations, the VLEngine and PhoneSim components are installed on the same
physical server.
For more information, see the “RSM Requirements” section of the Cisco Remote Silent Monitoring Installation
and Administration Guide, available at cisco.com.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
183
Unified Contact Center Enterprise Desktop
Cisco Remote Silent Monitoring
11 The PhoneSim component will then receive a SIP-based instruction from Unified CM for a simulated
phone that it manages, to establish a monitoring call with the agent’s phone.
12 The chosen simulated phone establishes the monitoring call with the agent’s phone based on Unified CM's
above request.
13 After the establishment of a monitoring call from RSM server to agent, the agent phone's Built-in-Bridge
(BiB) forwards the call conversation to PhoneSim in the form of RTP packets.
14 In turn, for IPIVR, PhoneSim strips the RTP headers and streams this data to the VRU node over HTTP
as a response to the request made earlier in step 8. For CVP, PhoneSim streams the audio back to CVP
Gateway using RTSP and RTP protocols.
15 The VRU then plays the data to the supervisor as if it were a streaming audio prompt.
Single Site
The following figure illustrates the basic network connectivity of RSM deployed within a typical single-site
configuration.
As shown in the preceding figure, supervisors may dial in through a VoIP phone as well as through the PSTN.
The VRU that handles the supervisor's call is IP IVR in this case.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
184
Unified Contact Center Enterprise Desktop
Cisco Remote Silent Monitoring
This typical RSM VLAN configuration also illustrates the various protocol interfaces that RSM has into the
rest of the system:
• HTTPs: As stated previously, HTTP is used as the carrier protocol for VRU-based requests into the
RSM system. A request takes standard URL form and may look like one of the following URLs:
http://rsmserver:8080/vlengine/checkUserCredentials?supervisorID=1101&pin=1234&outputFormat=plain
http://rsmserver:8080/vlengine/canMonitorAgentID?supervisorID=1101&agentID=1001&outputFormat=vxml
The first request is for the checkUserCredentials API call, while the second is for the canMonitorAgentID
API call. Parameters to these requests are passed by using the GET method. The return data (as an HTTP
response) is either plain text or encapsulated in VoiceXML, depending on the API call being used and
on the value specified for the outputFormat parameter (if available for that call).
• CTI OS: The RSM server makes several connections to CTI OS. One of these connections is for receiving
platform events. (In the language of CTI OS, it is a monitor-mode connection.) The others are what CTI
OS calls agent mode connections and they are used to authenticate logging-in supervisors if the standard
authentication facilitates are being utilized.
• JTAPI: The request to start monitoring an agent’s phone is made through JTAPI. This requires a JTAPI
application user to be defined on each Unified Communications Manager cluster in the environment,
and to be associated to all agent phones.
• RTP: While a dialed-in supervisor is monitoring an agent, there is a monitoring call in progress from
the BiB (built-in-bridge) of that agent’s phone to the RSM server. While the signaling data for this call
is run through Unified Communications Manager (just like any other call), the RTP traffic will flow
between the agent phone and the RSM server.
Multisite WAN
The following scenarios depict basic supported configurations for the RSM product in a multisite deployment.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
185
Unified Contact Center Enterprise Desktop
Cisco Remote Silent Monitoring
Figure 84: Multisite Deployment with a Single Unified Communications Manager Cluster and Single VRU
In this scenario, the Unified Communications Manager and Unified CCE environment is co-located in Atlanta,
and the Austin location contains the entire end-user population. The VRU is a VXML Gateway/Voice Gateway
in Atlanta, controlled by a Unified CVP Call Server also in Atlanta.
The supervisor in Austin could possibly have two ways of dialing into the RSM system:
• Through the PSTN — Here the supervisor would dial an E.164 number, and the call is hairpinned through
the Voice Gateway. The Unified CVP RSM call flow application would handle the call as normal from
that point.
• As a VoIP extension — In this case, Unified Communications Manager would have a trunk configuration
set up to the VRU. The call would remain VoIP all the way through, and the call would likewise be
handled by the Unified CVP RSM call flow application.
In this scenario, all RSM traffic is confined to the Atlanta site except:
• The RTP traffic of the agent being monitored
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
186
Unified Contact Center Enterprise Desktop
Cisco Remote Silent Monitoring
Figure 85: Multisite Deployment with a Single Unified Communications Manager Cluster and Multiple VRUs
This scenario is similar to the previous one, with the addition of PSTN access at the Austin site. This scenario
also adds personnel to the Atlanta site.
With the addition of a PSTN egress point in Austin, a call from a supervisor at the Austin location to the RSM
system can be backhauled across the WAN (if VoIP end-to-end) or sent across the PSTN if the Atlanta DID
associated with the RSM application was dialed.
In this example, Unified CVP is still used as well as the Unified CVP Call Server. However, there are two
VXML Gateways, one at each site. The environment is configured so that a supervisor dialing RSM from
Austin is routed to the RSM call flow application on the Austin VXML Gateway, while a supervisor dialing
in from Atlanta is routed to the Atlanta VXML Gateway.
Because the Atlanta site houses the Unified CM and Unified CCE environment, all RSM-related JTAPI and
CTI OS traffic is still confined there. However, the addition of a VXML Gateway at Austin leads to HTTP-based
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
187
Unified Contact Center Enterprise Desktop
Cisco Remote Silent Monitoring
traffic being streamed between the sites over the WAN. This traffic consists of relatively small requests from
the gateway to the RSM server for services, and the RSM server's responses. The responses themselves can
be sizeable, especially when it is the data for a monitored conversation.
Also, when an agent in Austin is monitored, the RTP data for that conversation is sent over the WAN back
to the RSM server as well.
Figure 86: Multisite Deployment with Multiple Unified Communications Manager Clusters and a Single VRU
This scenario includes a Unified Communications Manager cluster at both the Atlanta and Austin sites and a
single IP IVR VRU in Atlanta. Cluster 1 handles the phone devices at the Atlanta site, while Cluster 2 handles
the ones at the Austin site. The RSM server is linked to the CTI OS servers of both clusters to track all agents
in the enterprise.
As IP IVR is in use, a supervisor call to the RSM call flow is routed to, and media-terminated on, this IP IVR
system over either the PSTN or IP WAN (as discussed previously). No VXML Gateway is involved in this
configuration, and all RSM-related HTTP interaction is confined to the Atlanta site, between the RSM and
IP IVR systems.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
188
Unified Contact Center Enterprise Desktop
Cisco Remote Silent Monitoring
Because a Unified Communications Manager cluster now exists at the Austin site, several classes of data that
RSM uses to track environment state and initiate agent monitoring requests (CTI OS and JTAPI traffic) are
sent over the IP WAN.
Figure 87: Multisite Deployment with Multiple Unified Communications Manager Clusters and Multiple VRUs
This scenario illustrates a Unified Communications Manager cluster as well as a Unified CVP VXML
Gateway/Voice Gateway at each site. It is a combination of the previous deployment models, and it has the
following characteristics:
• The Unified CVP Call Server controls the VXML Gateways at each site.
• Because there are agent phones at both sites, RTP data can be streamed either within the LAN at Atlanta
(if the requested agent to monitor is in Atlanta) or across the WAN (if the requested agent is in Austin).
• As with the previous multisite, multicluster deployment, the RSM tracks the state of the entire enterprise.
This means that a supervisor could dial in from either site (or anywhere in the world through PSTN)
and listen to an agent in Atlanta or Austin.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
189
Unified Contact Center Enterprise Desktop
Cisco Remote Silent Monitoring
Single Cluster, Single PG/CTIOS with Two UCM PIMs (Agent Expansion Unified CCE Deployment Configuration)
This diagram depicts a setup involving a single UCM cluster and single Agent PG/CTIOS server configured
with two UCM PIMs.
Figure 88: Single UCM Cluster and Single Agent PG/CTIOS Server Configured with Two UCM PIMs
In this scenario, the single PG/CTIOS server is configured with two PIMs and each PIM points to a separate
subscriber pair in the UCM cluster.
This is supported in Unified CCE/UCM 8.0 and higher, only when more than 2000 agents (up to 4000 agents)
need to be configured in a single UCM cluster with a Unified CVP VRU. This expansion is not supported
with IPIVR.
In this scenario RSM should be configured with two clusters with each specifying the corresponding UCM
PIM Peripheral Number and its UCM subscriber pair.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
190
Unified Contact Center Enterprise Desktop
Cisco Remote Silent Monitoring
Single Cluster, Multiple PG/CTIOS (Agent Expansion Unified CCE Deployment Configuration)
The following diagram shows a setup involving a single UCM cluster and multiple (up to 4) Agent PG/CTIOS
servers:
Figure 89: Single UCM Cluster and Multiple (up to 4) Agent PG/CTIOS Servers
In this scenario, a separate Agent PG/CTI OS server is deployed for each subscriber node pair (primary and
backup). See Deployment of Agent PG in a Unified CM Cluster, on page 318 and Figure 126: Agent PG
Configuration Options with CTI OS, on page 295.
A separate RSM cluster (in a single RSM instance) should be configured corresponding to each Agent PG/CTI
OS server and its UCM subscriber pair.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
191
Unified Contact Center Enterprise Desktop
Cisco Remote Silent Monitoring
Multiple Cluster, Multiple PG/CTIOS (Agent Expansion Unified CCE Deployment Configuration)
This diagram depicts a setup involving multiple UCM clusters and multiple Agent PG/CTIOS servers.
Figure 90: Multiple UCM Clusters and Multiple Agent PG/CTIOS Servers
In this scenario, a separate Agent PG/CTIOS server is deployed for each UCM cluster.
A separate RSM cluster (in a single RSM instance) should be configured corresponding to each Agent
PG/CTIOS Server and its UCM cluster subscriber pair.
Bandwidth Requirements
As part of the network planning done before deploying the RSM solution, you should verify that the network
infrastructure can support the bandwidth requirements of RSM.
The RSM solution has connectivity with multiple components in the larger Cisco environment (as the diagrams
in the previous section demonstrate). The table below lists these components, along with the nature of the
data exchanged and the relative bandwidth requirements of that data. If RSM exchanges multiple types of
data with a specific component, it is listed multiple times.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
192
Unified Contact Center Enterprise Desktop
Cisco Remote Silent Monitoring
RSM Peer Purpose Protocols Used Data Format Relative Bandwidth Link Latency
Requirements Requirements
VRU Service Requests TCP (HTTP) Textual Minimal < 500 ms avg.
/ Responses
VRU Requested Voice TCP (HTTP) For IPIVR - High(about 67 to 87 < 400 ms avg.
Data from G.711 u-law kbps per session)
TCP (RTSP)
PhoneSim to in WAV
VRU UTP (RTP) format and
HTTP
chunked
transfer
encoding
format.
For CVP -
G.711
u-law,
G.711 a-law,
and G.729 in
RTP.
Unified Issuance of Agent TCP (JTAPI) Binary Minimal < 300 ms avg.
CM Phone Monitoring (JTAPI
stream)
CTI OS Environment TCP (CTI OS) Binary (CTI Minimal(< 1000 < 300 ms avg.
Server Events / OS stream) agents)
(PG) Supervisor Logins Moderate(> 1000
agents)
(with 2000 agents,
about 100 kbps)
Agent Simulated Phone TCP or UDP Textual Minimal < 400 ms avg.
Phones Signaling (SIP)
Agent Monitored Phone UDP (RTP) Binary High (about 67 to 87 < 400 ms avg.
Phones Voice Data (g.711 kbps per session)
u-law, g.711
a-law, and
g.729)
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
193
Unified Contact Center Enterprise Desktop
RSM Codec Support
For bandwidth usage information, see the Cisco Voice Over IP - Per Call Bandwidth Consumption Tech Note.
There must be sufficient bandwidth available from the agent IP phone to the RSM server to support the
monitoring voice stream, in addition to the regular voice streams for the call. This is important for agents who
work remotely, at home and in small branches on limited bandwidth or WAN connectivity. Regular Call
Admission Control (CAC) and bandwidth calculations are applicable for monitoring calls.
Since G.711 a-law, G.711 u-law, and G.729 are the codecs supported for monitoring calls between agent IP
phone and RSM server (phonesim), use the Cisco TAC Voice Bandwidth Codec Calculator for bandwidth
capacity planning.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
194
Unified Contact Center Enterprise Desktop
RSM Codec Support
Note If the RSM application is configured using a comprehensive flow, only G.711 a-law or G.711 u-law can
be configured for the RSM-to-CVP call leg. This is due to other dependencies related to Agent Greeting
and other ICM functionality and their inability to handle G.729. To use G.729 for the CVP call leg, RSM
should be configured in a standalone call flow.
For more information, see the “Codec for Monitoring and Recording Calls” topic in “Monitoring and Recording”
chapter of the Cisco Unified Communications Manager Features and Services Guide.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
195
Unified Contact Center Enterprise Desktop
RSM Codec Support
RSM Server (Hardware Callers listening to a voice stream from the failed server have the voice stream
Failure) terminated and be returned to the main menu. Their next attempt to make a
service request to the failed server (or a new caller’s first attempt to make such
a request) will result in a configurable delay of 3 to 5 seconds or so, as the request
times out and an error message is played. Furthermore, any action that attempts
to contact the RSM server (for example, logging in, attempting to monitor an
agent, and so forth), will fail, although the RSM callflow will still be answered
because it is being hosted on the VRU node.
VLEngine or PhoneSIM Service automatically restarted via service wrapper. Supervisors with a request
software failure in-progress are given an error message and have a chance to retry their last
action. During the time either service is not functioning, any action that attempts
to contact the RSM server (for example, logging in, attempting to monitor an
agent, and so forth), will fail, although the RSM callflow will still be answered
because it is being hosted on the VRU node.
Unified CCE fails (CTI RSM will lose connectivity to the CTI OS server when the PG fails or is cycled.
OS) If connectivity to both CTI servers on a cluster fails, RSM will keep retrying
both, connecting to the first server that is available. (The CIL's fail-over code is
used for all of this.) When connectivity comes back up to a CTI server, the agent
and call lists are cleared and refreshed (to avoid "stale" agents). During this time,
no new call events are received, and the system is working from an "out-of-date"
agent and call list. Therefore some monitoring requests fail, saying the agent is
not talking when he or she is, and some monitoring requests fail because the
system thinks the agent is talking when he or she currently is not. This is believed
to be preferable to the scenario where all cached data is deleted when the server
goes down, in which case no monitoring works.
Unified CM fails (JTAPI) Connectivity to one or more JTAPI providers are lost. RSM can be configured
for connectivity to a maximum of 2 JTAPI providers per-cluster. If this is the
case and connectivity to either of the providers is lost, VLEngine will fail-over
to the other provider if necessary, making it the active one and making its requests
through it. If connectivity to both providers is lost, VLEngine will periodically
retry both and re-establish the connectivity to the first that comes up. Attempts
to monitor agents (for example, monitorAgent calls) made during this time fails
until the JTAPI connection is re-established.
Host-Level Security
You can restrict incoming access to the RSM server to only the necessary components with the host-based
Access Control List (ACL) functionality in the Windows Server OS. In the most secure configuration, incoming
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
196
Unified Contact Center Enterprise Desktop
RSM Codec Support
access to the RSM system is permitted from the VRU systems. You can also employ this host-based access
control to allow limited access to other services if desired, such as remote administration mechanisms like
Windows Remote Desktop and VNC.
ACL is not required, but an example ACL Configuration for a single-server RSM configuration is as follows:
• Deny incoming access to all
• Permit incoming TCP on port 8080 to each VRU node in the environment (VLEngine HTTP API Access)
• Permit incoming TCP on port 29001 to each VRU node in the environment (PhoneSim HTTP API
Access)
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
197
Unified Contact Center Enterprise Desktop
Cisco Agent Desktop Presence Integration
• Second generation or older phones, such as the Cisco Unified IP Phones 7940 or 7960
• A media-terminated CTI OS Agent Desktop
• Monitoring of encrypted phone calls
Therefore, support for these products is also not available through RSM. For further information about this
restriction, see the section on Silent Monitoring.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
198
Unified Contact Center Enterprise Desktop
Cisco Agent Desktop Presence Integration
The following figure and description explain how various components of CAD and Cisco Unified Presence
interface with each other.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
199
Unified Contact Center Enterprise Desktop
NAT and Firewalls
Design Considerations
All communication between CAD agents and SMEs is through the Cisco Unified Presence Server and is not
routed through any CAD servers. For deployment guidelines, see the Cisco Collaboration System Solution
Reference Network Designs at http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/
UCgoList.html.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
200
Unified Contact Center Enterprise Desktop
NAT and Firewalls
For detailed port information, see the Port Utilization Guide for Cisco Unified Intelligent Contact Management
Enterprise & Hosted .
The figure above shows that IP voice streams are exchanged between the VoIP providers (CAD, the VoIP
Monitor service, and the Recording and Playback Service) and the VoIP requestors (CSD and the Recording
and Playback Service).
CTI and call control data (agent state, skill information, and call events) flow either from the CTI OS service
(in the case of CAD) or from one or more of the CAD Base Services communicating directly with the CTI
server (in the case of CSD and CAD IPPA agents).
Note that, in the case of the IP Phone Agent XML service, the CTI information exchanged applies only for
agent state changes requested by the agent using the CAD IPPA application and for skill information displayed
on the phone. Call control messages are still exchanged between the phone and Unified CM.
HTTP communication is performed between the SMC applet and the SMC servlet running on the CAD Base
Services machine. HTTP is also the protocol used by the CAD IPPA service to communicate with the Browser
and IP Phone Agent service.
The UDP/TCP traffic shown in the preceding figure represents the socket connections used to exchange
messages between servers and clients, which includes the CORBA connections used by most of the clients
to request services and information from the servers.
The SMC servlet that runs on the CAD Base Services machine uses SNMP to gather status information about
all the CAD services that are part of an installation.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
201
Unified Contact Center Enterprise Desktop
Coresidency of CTI OS and CAD Services on the PG
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
202
Unified Contact Center Enterprise Desktop
Miscellaneous Deployment Considerations
IP Phone Agent
The IP Phone XML service agent application supports only hardware IP phones because there is no desktop.
Layer-3 Devices
Layer-3 network devices (routers and gateways) cannot exist between an agent’s telephone device (hardware
or software phone) and the switch port used by the VoIP Monitor service that is configured to capture voice
packets for Silent Monitoring and Recording. This restriction applies only if a VoIP Monitor Service is
configured as the primary or back-up service for capturing voice streams. If desktop monitoring is configured
as the primary method (with no secondary method), this information does not apply.
Network Hubs
A network hub (including a "smart" hub) is not allowed between an agent’s hardware phone and PC when
Desktop Monitoring is configured for the agent.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
203
Unified Contact Center Enterprise Desktop
Bandwidth and Quality of Service
Desktop Latency
Agent and Supervisor desktops can be located remotely from the Agent PG. Technically, the delay between
the CTI OS Server and CTI Toolkit Desktop clients, as well as between the CAD Server and CAD/CSD
desktop, can be very high because of high time-out values. However, large latency will affect the user experience
and might become confusing or unacceptable from the user perspective. For this reason, Cisco recommends
limiting the latency between the server and agent desktop to 400 ms round-trip time for CTI OS (preferably
less than 200 ms round-trip time) and 200 ms round-trip time for CAD (preferably less than 100 ms round-trip
time). Longer latencies up to a second are technically supported but will affect the agent experience negatively
(for example, the phone will start ringing but the desktop will not be updated until a second later).
Important The Agent PG does not support having both seven All-Event clients on the CTI server and five
monitor-mode connections on the CTI OS server. Your design must trade off one for the other to stay
within the combined maximum of 9.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
204
Unified Contact Center Enterprise Desktop
References to Additional Desktop Information
Note These higher limits assume that the All-Event Clients use Event Minimization in their CTI Server protocol
integration.
Unlike VMs built from the smaller OVA, these limits are not linked. The number of All-Event Clients does
not limit the number of monitor-mode connections that you can have on the large VMs. You can use the
maximum amount of each type, if your system can support the load.
All-Event Clients
Each of the agent desktop solutions (Cisco Finesse, CTI OS Desktop, and Cisco Agent Desktop) use 2 of the
available All-Event clients. Some of the possible consumers of the clients are:
• CAD IP Phone Agent (2)
• Real Time Adherence (2)
• Some third-party recording vendors (2)
• Unified WIM and EIM (2)
• Cisco Media Blender
• B&S MCAL
• Remote Silent Monitor
Monitor-Mode Connections
If your deployment uses the CTI OS server, it begins with two monitor-mode connections on each side of the
redundant pair. However, you cannot configure those connections to fail over to the other side in a failure. In
a failure on Side A, the resources connected to the CTI OS server on Side A cannot reconnect to the Side B
server. Those extra connections would push Side B past the combined maximum of nine.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
205
Unified Contact Center Enterprise Desktop
References to Additional Desktop Information
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
206
CHAPTER 5
Outbound Option Description
The Outbound Option Dialer is a software-only process that co-resides on the Unified CM PG. The SIP
Dialer process communicates with Voice Gateways, Outbound Option Campaign Manager, CTI Server, and
MR PIM. The Dialer process communicates with the Outbound Option Campaign Manager to retrieve
outbound customer contact records and to report outbound call disposition (including live answer, answering
machine, RNA, and busy). The Dialer process communicates with the Voice Gateway to place outbound
customer calls. The Dialer process communicates with the CTI Server to monitor skill group activity and to
perform third-party call control for agent phones. The SIP Dialer process communicates with the MR PIM
to submit route requests to select an available agent.
The SCCP Dialer process has communication sessions with Unified CM, Outbound Option Campaign
Manager, CTI Server, and MR PIM. The SCCP Dialer process communicates with the Outbound Option
Campaign Manager to retrieve outbound customer contact records and to report outbound call disposition
(including live answer, answering machine, RNA, and busy). The SCCP Dialer process communicates with
Unified CM to place outbound customer calls and agent reservation calls from the dialer ports and thus has
an impact on the Unified CM cluster. The SCCP Dialer process communicates with the CTI Server to monitor
skill group activity and to perform third-party call control for agent phones. The SCCP Dialer process
communicates with the MR PIM to submit route requests to select an available agent.
The Outbound Option Dialer can dial customers on behalf of all agents located on its peripheral. The Dialer
is configured with routing scripts that enable it to run in full blended mode (an agent can handle inbound
and outbound calls), in scheduled modes (for example, 8:00 AM to 12:00 PM in inbound mode and 12:01
PM to 5:00 PM in outbound mode), or completely in outbound mode. If blended mode is enabled, the Dialer
competes with inbound calls for agents. The Dialer does not reserve more agents than are configured in the
administrative script Outbound Percent variable. If all agents are busy, then the Dialer does not attempt to
reserve any additional agents.
Multiple Voice Gateways and Unified SIP Proxy Server are used to achieve high-availability for SIP Dialer
deployment, while multiple SCCP dialers are used to achieve high-availability for SCCP dialer deployment.
The redundancy is also achieved with redundant SIP Dialer. See Design SIP Dialer for High Availability.
Outbound Option supports Call Progress Analysis configuration on a campaign basis. When this feature is
enabled, the SIP Dialer instructs the Voice Gateway to analyze the media stream to determine the nature of
the call (such as voice, answering machine, modem, or fax detection).
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
207
Outbound Option Description
Outbound Option Processes
Campaigns are run as agent-based campaigns or IVR-based campaigns. An IVR is generally configured in
an agent-based campaign to allow for handling of overflow calls when all agents are busy. In a transfer to
an IVR-based campaign, all of the calls are transferred to an IVR application after the outbound call is
answered.
Note Precision Routing does not support Outbound Option. Outbound Option campaigns use skill groups.
However, an agent involved in an outbound campaign (through an outbound skill group) can be logged
into a Precision Queue and handle inbound Precision Routing calls.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
208
Outbound Option Description
Best Practices for Outbound Option
• Centralized management and configuration through the Unified CCE Administration & Data Server.
• Call-by-call blending of inbound and outbound calls.
• Flexible outbound mode control. Use the Unified CCE script editor to control the type of outbound mode
and percentage of agents within a skill to use for outbound activity.
• Integrated reporting with outbound specific reporting templates.
Outbound Option enables an agent to participate in outbound campaigns and take inbound calls through a
SCCP software dialer.
Follow these best practices when implementing the SCCP Dialer:
• Use a media routing PG and a media routing PIM for each SCCP Dialer. The Media Routing PG can
be configured for multiple PIMs to support multiple SCCP dialers.
• For high availability, deploy multiple SCCP dialers at a single Unified CM cluster. See Design SCCP
Dialer for High Availability . Deploy SCCP dialers in close proximity to the Unified CM cluster where
the SCCP Dialers are registered.
• Configure the Unified CM node to keep SCCP Dialer traffic localized to one subscriber as much as
possible. See SCCP Dialer Throttling Considerations for Unified CM for more details.
• Configure the same number of ports for SCCP Dialers at a specific peripheral.
• Ensure proper Unified CM server sizing when installing SCCP Dialers. Unified SCCP Dialer places a
large strain on Unified CM. See SCCP Dialer Throttling Considerations for Unified CM for more details.
• Enable SCCP Dialer call throttling to prevent overloading the Unified CM server. See SCCP Dialer
Throttling Considerations for Unified CM.
• The Unified CM routing and dial plans are used for SCCP Dialer to place outbound calls. This allows
calls to be placed using gateways that are deployed to leverage toll-bypass and lower local calling rates.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
209
Outbound Option Description
Best Practices for SIP Dialer
Note The SCCP dialer does not support CUBE for all releases of Unified CCE.
Note Cisco Finesse Release 9.0(1) supports the Outbound Option for Progressive and Predictive modes only.
Cisco Finesse Release 9.1(1) and later supports Progressive, Predictive, and Preview modes.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
210
Outbound Option Description
Outbound Dialing Modes
Perform CPA at gateway DSP resource. Perform CPA at Unified Communications Manager
dialer port.
CPA supports both g.711 and g.729 codecs. CPA supports only g.711 codec.
No need to configure dialer port on Unified CM. Need to configure dialer port on Unified
Communications Manager.
Call Throttling supports 60 CPS per dialer. Call Throttling supports 5 CPS per dialer.
Dialer need NOT be in proximity of Voice Gateway. Dialer needs to be in proximity of Voice Gateway.
Requires one MR PIM for MR PG. Requires two MR PIMs for duplex SCCP Dialers,
and one MR PIM for simplex SCCP Dialer.
Only connected outbound calls, which are transferred All the outbound calls go through Agent PG and
to agents or IVR, go through Agent PG and Unified Unified Communications Manager.
Communications Manager.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
211
Outbound Option Description
Call Flow Description—Agent Based Campaign
• Personal Callback Mode — When the person who is called requests to be called back later, the agent
can specify that the callback is directed to the same agent. The system then calls the customer back at
a pre-arranged time established between the requested agent and the customer.
1 Import is scheduled and campaign starts. Customer records are delivered to Dialer.
2 The dialer process continually monitors peripheral skill group statistics from the CTI server for an available
agent. Concurrently, the campaign manager monitors the database for customer records and forwards
active records to the dialer. When the dialer identifies an available agent for use in an outbound campaign,
it sends a route request to the MR PIM.
3 The MR PIM forwards the route request to the router.
4 The Unified ICM/CCE/CCH CallRouter executes a routing script, selects an available agent, reserves that
agent, and then returns a routing label (phone extension) identifying the reserved agent.
5 The MR PG returns the label for an available agent to the dialer. The dialer then sends an agent reservation
request to the Agent PG. The Agent PG generates a virtual agent reservation call to the agent desktop, and
automatically places that virtual reservation call into answered state and then on hold.
6 The dialer initiates the customer call through Unified CM and the Voice Gateway.
7 If call progress analysis is configured, the dialer process will analyze the RTP stream to detect a live answer
(or answering machine detection). When a live answer is detected, the dialer immediately initiates a transfer
of the call (along with call context for screen pop) to the next reserved agent extension from the list
maintained by the dialer. Similarly, if answering machine detection is enabled, the call can be transferred
to the agent, to an IVR, or dropped.
8 The dialer auto-answers the transferred call for the agent by way of the CTI server so that the voice path
between the customer and the agent can be quickly established. This releases the dialer port used to call
the customer. The dialer then hangs up the reservation call to this agent. The dialer also updates the
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
212
Outbound Option Description
Call Flow Description—Agent Based Campaign
Campaign Manager to indicate a live answer was detected for this call. After the agent completes handling
the outbound call, the agent can be reserved for another outbound call using the same message flow.
The figure below shows the SIP Dialer call flow for agent-based campaigns with direct Voice Gateway
deployment.
Figure 96: SIP Dialer Call Flow for Agent-Based Campaigns—Direct Voice Gateway Deployment
The SIP Dialer call flow with direct Voice Gateway deployment for predictive/progressive dialing proceeds
as follows:
1 Import is scheduled and the campaign starts. Records are delivered to Dialer.
2 The dialer process continually monitors peripheral skill group statistics from the CTI server for an available
agent. Concurrently the campaign manager monitors the database for customer records and forwards active
records to the dialer. When the dialer identifies an available agent for use in an outbound campaign, it
sends a route request to the MR PIM.
3 The MR PIM forwards the route request to the router.
4 The Unified ICM/CCE/CCH CallRouter executes a routing script, selects an available agent, reserves that
agent, and then returns a routing label (phone extension) identifying the reserved agent.
5 Media Routing PIM notifies the Dialer that the agent is available. The dialer then sends an agent reservation
request to the Agent PG. The Agent PG generates a virtual agent reservation call to the agent desktop, and
automatically places that virtual reservation call into answered state and then on hold.
6 Dialer signals the gateway to place outbound calls to the customers by using a SIP INVITE.
7 The Gateway places outbound calls to the customers, and Dialer is notified the Gateway is trying.
8 Call Progress Analysis is done at the Gateway. Voice is detected, and Dialer is notified.
9 The Dialer asks the voice Gateway to transfer the answered outbound call to the reserved agent by its
agent extension.
10 The Gateway directs the answered outbound calls to the agents through Unified CM, using agent extensions
and Unified CM host address. The Dialer auto-answers the transferred call for the agent through the CTI
server so that the voice path between the customer and the agent can be quickly established.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
213
Outbound Option Description
Call Flow Description—Agent Based Campaign
The following figure shows the SIP Dialer call flow for agent-based campaigns in a Unified SIP Proxy Server
deployment.
Figure 97: SIP Dialer Call Flow for Agent-Based Campaigns – Unified SIP Proxy Server Deployment
The SIP Dialer call flow in a Unified SIP Proxy Server deployment for predictive or progressive mode dialing
proceeds as follows:
1 Import is scheduled and the campaign starts. Customer records are delivered to Dialer.
2 Dialer looks for an available agent by using the Media Routing Interface.
3 MR PG forwards the request to the Router.
4 The Routing Script identifies an agent and responds to the MR PG.
5 Media Routing PIM notifies the Dialer that the agent is available.
6 Dialer signals the Unified SIP Proxy Server to find a gateway and tell it to place outbound calls to the
customers through a SIP INVITE.
7 The Gateway places outbound calls to the customer.
8 Call Progress Analysis is done at the gateway. Voice is detected, and Dialer is notified.
9 The Dialer asks the Voice Gateway to transfer the answered outbound call to the reserved agent by its
agent extension.
10 The Gateway initiates the transfer to the Unified SIP Proxy Server, and the SIP Proxy forwards the
invitations onto Unified CM. Unified CM forwards the call invitations to the agent’s phone. The dialer
auto-answers the transferred call for the agent via the CTI server so that the voice path between the customer
and the agent can be quickly established.
The message flows above describe the flow for predictive or progressive mode dialing. The only difference
in these two dialing modes is how the dialer determines its dialing rate (dynamic or fixed). For preview dialing,
the agent will receive a customer record screen pop. If the agent wants to place this call, the agent must click
the Accept button on the agent desktop. This triggers a CTI event, which causes the dialer to call this customer.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
214
Outbound Option Description
Call Flow Description—Transfer to IVR Campaign
Figure 98: SIP Dialer Call Flow for IVR-Based Campaigns –Unified SIP Proxy Server And IP IVR Deployment
1 In this example, an unattended IVR campaign starts. Customer records are delivered to the Dialer.
2 The Dialer initiates a call to the customer.
3 The RTP stream is analyzed and voice is detected.
4 The Dialer requests an in-line transfer to a pre-configured route point.
5 The Unified CM PG requests a translation route for the router.
6 The router responds.
7 The response is translated and sent to Unified CM.
8 Unified CM transfers the call to the IVR.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
215
Outbound Option Description
Call Flow Description—Transfer to IVR Campaign
The SIP Dialer call flow for IVR-based campaigns with a Unified SIP Proxy Server and an IP IVR deployment
proceeds as shown in the following figure:
Figure 99: SIP Dialer call flow for IVR-based campaigns with a Unified SIP Proxy Server and an IP IVR deployment
1 An unattended IVR campaign starts. Customer records are delivered to the Dialer.
2 The Dialer asks the SIP Proxy to forward an invitation to an available gateway to start a call.
3 The Gateway places the call.
4 Voice Gateway does Call Progress Analysis and detects live speech. The Dialer is notified.
5 The Dialer asks the MR PG where the IVR is.
6 MR PG forwards the request to the Router.
7 Routing Script identifies the IVR and notifies the MR PG.
8 The MR PG forwards the route response to the Dialer.
9 The Dialer notifies the Voice Gateway to transfer the call to the IVR.
10 The Gateway initiates the transfer to the SIP Proxy and the SIP Proxy forwards the call invitation to Unified
CM.
11 Unified CM forwards the call invitation to the IP IVR.
12 Media is set up between the Gateway and the IP IVR.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
216
Outbound Option Description
Outbound Options for Unified Contact Center Enterprise and Hosted Deployments
The SIP Dialer call flow IVR-based campaigns with Unified SIP Proxy Server and Unified CVP deployment
proceeds as follows :
Figure 100: SIP Dialer Call Flow for IVR-Based Campaigns –Unified SIP Proxy Server And Unified CVP Deployment
1 In this example, an unattended IVR campaign starts. Customer records are delivered to the Dialer.
2 The Dialer asks the SIP Proxy to forward an invitation to an available Voice Gateway to start a call.
3 The Voice Gateway places the call.
4 The Voice Gateway does Call Progress Analysis and detects live speech. The Dialer is notified.
5 The Dialer asks the MR PG where the IVR is.
6 MR PG forwards the request to the Router.
7 Routing Script identifies the IVR and notifies the MR PG.
8 The MR PG forwards the route response to the Dialer.
9 The Dialer notifies the Voice Gateway to transfer the call to the IVR.
10 The Voice Gateway sends its invitation to the SIP Proxy, which forwards it to Unified CVP. The transfer
is completed and media is set up between Unified CVP and the Voice Gateway.
Enterprise Deployments
Run the Outbound Option on a Windows server that meets the minimum requirements specified in the latest
version of the Hardware & System Software Specification (Bill of Materials) for Cisco Unified ICM/Contact
Center Enterprise & Hosted, Release 9.0(x).
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
217
Outbound Option Description
Enterprise Deployments
The SIP Dialer is preferred for new deployments due to its high scalability by offloading call process resources
and call progress analysis to the gateway. Furthermore, the SIP Dialer has no Unified CM or gateway proximity
requirements.
The SIP or SCCP dialer must be on the same server with the MR-PG and Agent PG. Duplex MR-PGs and
Agent PGs are required even when a simplex SCCP Dialer is installed.
The duplex Agent PG supports only duplex SIP Dialers; one dialer is active and another dialer is in
warm-standby mode. For duplex SIP Dialer installations, each SIP Dialer connects to the MR PIM on the
same MR PG side (Side A or Side B).
For two SCCP dialers installed for an Agent PG, the two MR PIMs on one MR PG side (Side A or Side B)
are active, and one connects to the SCCP Dialer on the same side (Side A) while the other connects to the
SCCP Dialer on the other side (Side B).
When there are fewer than 120 dialer ports, installing one or two SCCP dialers for an Agent PG has both pros
and cons. The installation with a single SCCP Dialer offers better Predictive/Progressive dialing performance
by achieving an agent pooling effect, but it does not provide redundancy. An installation with two SCCP
Dialers, with dialer ports split across the two SCCP dialers (one SCCP dialer on PGA and one SCCP dialer
on PGB), offers redundancy architecture but worse Predictive/Progressive dialing performance.
There is no upgrade path from the SCCP Dialer to SIP Dialer. Any new configuration and setup have to be
created for the SIP Dialer only. It is possible to deploy both the SCCP and SIP Dialers in the same Unified
CCE customer instance. The Campaign Manager is able to communicate with both the SCCP and SIP Dialers.
However, the Campaign Manager performs only the warm standby feature for the SIP Dialer by knowing the
dialer type. You can configure and set up only one dialer type, either SCCP dialer or SIP Dialer, for one Agent
PG duplex.
The hybrid deployment model is usually used for upgrading one large customer so that the old SCCP Dialers
can be removed and their outbound agents can be gradually added to the new SIP Dialer.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
218
Outbound Option Description
Enterprise Deployments
The figure below shows the installation of a single SCCP dialer. The SCCP Dialer is shown installed on Side
A of the duplex PGs. The single SCCP dialer configuration provides capacity for 120 ports. This deployment
model is used when scaling and high availability are not factors.
For Cisco Unified Contact Center Enterprise deployments, the SCCP Dialer and Media Routing PG processes
run on the same physical Server as the Agent PG. In a deployment with two SCCP dialers on a duplex PG
pair, the Media Routing PG has two PIMs because each dialer gets its own Media Routing PIM.
The connection between the SCCP Dialer and the Unified CM cluster consists of multiple Skinny Client
Control Protocol (SCCP) sessions, one for each SCCP dialer port. The duplexed PGs (Side A and Side B)
shown in Figure 98 are composed of a Generic PG (with Unified CCE PIM and a Unified IP IVR PIM), MR
PG, CTI server, and CTI OS server process. The JTAPI links the duplexed PG and the Unified CM cluster.
The following figure shows the deployment model for two dialers. Each dialer is associated with the Unified CM
subscriber on its respective side and has all of its ports in one device pool for that subscriber. The configuration
shown in this figure provides 192 dialer ports. To scale upward, you can add more pairs of dialers (PG Sides
A and B) and subscribers, for up to four pairs (or eight dialers, PG sides, and subscribers) per Unified CM
cluster (see Figure 103: Multiple SCCP Dialer Deployment (Eight Dialers) , on page 220). The use of multiple
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
219
Outbound Option Description
Enterprise Deployments
dialers provides high availability for this deployment model. For more details, see Design SCCP Dialer for
High Availability.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
220
Outbound Option Description
Enterprise Deployments
The SIP Dialer architecture supports only one active SIP Dialer per peripheral. Only one SIP Dialer needs to
be configured. Two Dialers are installed on separate PG platforms, but each Dialer is installed using the same
Dialer Name.
For Cisco Unified Contact Center Enterprise deployments, the SIP Dialer and Media Routing PG processes
run on the same physical Server as the Agent PG. In a deployment with duplexed SIP dialers on a duplex PG
pair, the Media Routing PG has one PIM because each dialer gets its own Media Routing PIM on the same
physical server.
With Unified CM in single gateway deployments, the SIP Dialer uses the local static route file to place and
transfer outbound calls when Sip Server Type is set to Voice Gateway in the Dialer setup dialog. These
outbound calls are transferred to to Unified CVP, IP IVR, or outbound agents. Make sure the SIP Dialer uses
the local static route file for single gateway deployments.
With Unified CM in single gateway deployments, the SIP Dialer uses the Unified SIP Proxy Server to place
and transfer outbound calls when Sip Server Type is set to CUSP Server in the Dialer setup dialog. These
calls are placed or transferred to Unified CVP, IP IVR, or outbound agents.
Note Codec configuration (g.729 versus g.711) impacts port capacity and CPU utilization of gateways.
Configuring g.729 requires more DSP and CPU resources for gateways.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
221
Outbound Option Description
Distributed Deployments
SIP Dialer supports Unified SIP Proxy on the Cisco 3845 Integrated Services Router. For more details, see
Design SIP Dialer for High Availability.
In a multiple gateway deployment, the SIP Dialer requires Server Group and Route Table configurations on
Unified SIP Proxy servers to identify the gateways, as well as numbers so that the gateways can determine
where to send calls to Unified CVP, IP IVR, or agents when the Dialer asks the gateway to transfer customer
calls. Setting the Sip Server Type radio button to SIP Proxy in the Dialer setup dialog is required for multiple
gateway deployment.
Distributed Deployments
A distributed deployment model involves a central Unified CCE system and Unified CM located at one site,
with the Campaign Manager installed on the logger at this site, and a second site reachable over a WAN,
which consists of the dialer, a PG, and a second Unified CM system with Outbound Options.
For SIP Dialer deployment, a Unified SIP Proxy Server is installed for one SIP Dialer on each PG side, and
the Side A/Side B Dialer is targeting the same set of Voice Gateways through its own Unified SIP Proxy
Server. Multiple Voice Gateways can be installed locally to customer phones, or each Voice Gateway can be
installed locally to an area so that tolls are not encountered if leased circuits or IP MPLS WAN circuits are
available.
The Campaign Manager sends dialer records over the WAN, and the dialer places calls to local customers.
The second site would support inbound agents as well. See IPT: Multisite with Distributed Call Processing.
The following bandwidth options are available between India and the US in customer environments:
1 Terrestrial P2P leased 2 Mbps circuits
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
222
Outbound Option Description
Distributed Deployments
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
223
Outbound Option Description
Distributed Deployments
The following figure provides an example of a distributed deployment for an agent-based campaign.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
224
Outbound Option Description
Distributed Deployments
• An answered outbound call with g.711 Codec requires a WAN bandwidth of 80 kbps for the Call Progress
Analysis time period.
• An answered outbound call with g.729 Codec requires a WAN bandwidth of 26 kbps for the Call Progress
Analysis time period.
• An alerting outbound call with g.711 Codec requires a WAN bandwidth of 80 kbps per agent call, and
an alerting outbound call with g.729 Codec needs a WAN bandwidth of 26 kbps per agent call.
• Outbound calls being queued or self-serviced at Unified IP IVR do not require WAN bandwidth.
Figure 107: Distributed Deployment Example for Transfer-to-IVR Campaign – Unified CVP
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
225
Outbound Option Description
Distributed Deployments
The Unified SIP Proxy servers are locally duplexed at Site 2 to avoid the WAN SIP signaling traffic to transfer
live outbound calls.
Each SIP Dialer connects to its own Unified SIP Proxy Server at Site 2. Each Unified SIP Proxy Server
controls the set of Voice Gateways at Site 3 (United States).
The Unified SIP Proxy servers provide (N+1) redundancy.
If recording is enabled at the SIP Dialer, the bandwidth requirements are as follows:
• An answered outbound call with g.711 Codec requires a WAN bandwidth of 80 kbps for the Call Progress
Analysis time period.
• An answered outbound call with g.729 Codec requires a WAN bandwidth of 26 kbps for the Call Progress
Analysis time period.
• An alerting outbound call with g.711 Codec requires a WAN bandwidth of 80 kbps per agent call, and
an alerting outbound call with g.729 Codec needs a WAN bandwidth of 26 kbps per agent call.
• Outbound calls being queued or self-serviced at Unified CVP do not require WAN bandwidth.
The following figure provides an example of a distributed deployment for transfer-to-IVR campaign for IP
IVR.
See the Bandwidth Provisioning and QoS Considerations chapter for further bandwidth requirements for the
Outbound OptionWhere is this chapter – need link.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
226
Outbound Option Description
Voice Gateway Proximity for SCCP Dialer
Colocate the SCCP Dialer with the Unified Contact Center Enterprise PG and the Unified Communications
Manager cluster (including the Voice Gateway). Because the SCCP Dialer supports only g.711 audio codec
for customer calls for answering machine detection, you may need to allocate large blocks of WAN bandwidth.
Even though the Dialer does not support g.729 audio codec for customer calls for answering machine detection,
it is possible to support g.729 for the customer-to-agent portion of the call. This type of configuration is
supported without requiring the use of transcoders.
In this deployment, the SCCP Dialer advertises g.729 capability (although the Dialer does not truly support
g.729). This permits completion of the reservation call from the SCCP Dialer to the agent. The call from the
SCCP Dialer to the customer must be g.711; however, the customer call is then transferred to the agent, and
the call is renegotiated to g.729.
Configure Outbound Option for Unified Contact Center Enterprise and Hosted
Outbound Option can run fully-blended campaigns in which agents can handle inbound and outbound calls
alternately.
See Sizing Unified CCE Components and Servers for information about the MCS inbound capacity.
When sizing your deployment, do not use the maximum number of outbound agents allowed on a PG without
also looking at expected hit rate, lines dialed per agent, and average handle times. An outbound campaign
with a 10 second average handle time and dialing 10 lines per agent can support only about 20 agents while
fully occupying 240 ports on two SCCP dialers. However, with an average 100 second handle time dialing
three lines per agent for a 30% hit rate, 240 ports could handle 100 agents.
For sizing the Outbound Option for SCCP Dialer, use the Cisco Unified Communication Sizing Tool.
SIP Dialer targets the support of 1000 outbound agents for one PIM per PG. (Note that the number is smaller
when deploying mobile agents.) To support this number of agents, the deployment must have at least five
high-end gateways dedicated to outbound dialing.
SIP Dialer can support 1500 ports and 60 calls per second (cps). To achieve the rate of 60 cps, the SIP Dialer
has to support between 1000 and 2000 ports, depending on hit rates and handle times.
Each port is capable of dialing two calls per minute, assuming an average 30 seconds per call attempt, so 30
ports can handle one call per second for the Dialer. If the time to get all ports busy exceeds the average port
busy time, then some number of ports will always be idle.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
227
Outbound Option Description
Configure Outbound Option for Unified Contact Center Enterprise and Hosted
20 720
30 1080
Agent PG Considerations
The Unified Communications Manager PIM can support up to 15 calls per second. The PG can support up to
30 calls per second in a two-PIM deployment, but each dialer is connected to a Peripheral/PIM.
If the voice hit rate for the campaign is 15%, then the PG can sustain dialing at a rate of 100 calls per second.
Unified CM Considerations
The Unified CM subscriber can support a certain number of outbound calls per second. If the Dialer attempts
to transfer a large numbers of live outbound calls per second at the agent PG, then it must be distributed across
multiple subscribers using a Unified SIP Proxy Server.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
228
Outbound Option Description
SCCP Dialer Throttling Considerations for Unified CM
IP IVR Considerations
If the IP IVR is deployed, then all of its calls are front-ended through Unified CM. This deployment results
in a higher call load on the Unified CM subscribers. Because the Unified CM subscriber supports only five
calls per second, it is likely that calls transferred to agents and the IVR needs to be distributed across multiple
subscribers using the Unified SIP Proxy Server.
SCCP Dialer Throttling is controlled by the Port Throttle field in the dialer configuration. Port Throttle
indicates the number of ports to throttle in one second. For Cisco MCS-7845 and MCS-7835 servers, set Port
Throttle = 5. With this setting, the SCCP Dialer will initiate calls on only five ports in one second of the
campaign, and then the next five ports for the next one second, and so forth, until all 120 ports are utilized.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
229
Outbound Option Description
Transferring to Unified CVP Using H.323 and MTP Resources
Setting the value to Port Throttle = 5 enables dialing at a rate of five calls per second per Dialer, which gives
Unified CM sufficient room to allow for other incoming traffic and even allow for some shared resources. It
is a setting that works well for most situations. If your deployment requires a higher call rate, ensure that the
call rate for all traffic for any one subscriber does not exceed 10 calls per second at any time. Also, make sure
that traffic is not shared across subscribers.
Currently, a Unified CM subscriber node running on a dual-processor MCS-7845 server has a maximum
capacity at 10 calls per second. Each SCCP Dialer is capable of dialing at a rate of 10 calls per second. If the
solution is deployed so that it permits the Unified CM subscribers to become overloaded, then there is a risk
of causing dropped customer calls and inefficient dialing.
The throttling mechanism is part of each SCCP Dialer process, and it is not aware that another SCCP Dialer
may be sharing Unified CM resources. Therefore, if two SCCP Dialers share the same device pool or trunk,
there is a risk of dropped calls and inefficient dialing.
The Unified CM configuration must be designed and implemented to limit all traffic for a given Dialer to a
distinct Unified CM subscriber node to prevent two SCCP Dialers from overwhelming any shared resources.
This means that each SCCP Dialer requires separate device pools that point to one and only one subscriber.
Each SCCP Dialer also needs to have a calling search space, partition, translation pattern, and trunk that are
configured on its Unified CM subscriber.
SIP Dialer Throttling Considerations for Voice Gateway and Cisco Unified SIP
Proxy Server
SIP Dialer Throttling is controlled by the field Port Throttle in the dialer configuration. Port Throttle indicates
the number of ports to throttle per second. Setting the value to Port Throttle = 5 will allow SIP Dialer to dial
outbound calls at a rate of five calls per second per Dialer.
When the SIP Dialer connects to the Voice Gateway directly in the deployment, limit the dialer port throttle
by the maximum dialer call setup rate suggested on the gateway sizing table.
When the SIP Dialer connects through the CUSP in the deployment, the port throttle setting on the dialer must
not exceed the total gateway capacity under assumption. Calls is load-balanced through CUSP and each
gateway will reach its maximum available capacity. Limit the port throttle by the CUSP maximum transaction.
Currently, the dialer maximum throttle setting is 60 calls per second. Under normal transfer rate, calls through
CUSP will not exceed maximum CUSP transaction rate given that CUSP is exclusively used by outbound
deployments.
In a single or multiple gateway deployment, the SIP Dialer raises an alarm if any gateway is overloaded, and
it automatically throttles the dialing rate down to ten percent of the configured port throttle value per 5000
customer attempts until fifty percent of the correction is met. Fifty percent of the correction means the SIP
Dialer stops auto--throttling when it reaches fifty percent of the configured port throttle value.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
230
Outbound Option Description
SIP Dialer Throttling Considerations for Voice Gateway and Cisco Unified SIP Proxy Server
SIP Dialer provides the option to disable the auto--throttle mechanism by setting the value of registry key
EnableThrottleDown to 0. The auto--throttle mechanism is enabled by default. SIP Dialer still raises an alarm
even though the auto-throttle mechanism is disabled.
Set the port throttle value to 5 for Cisco 2800 Series Integrated Services Routers, set the port throttle value
to 15 for Cisco 3800 Series Integrated Services Routers, and set this value to 20 for Cisco Access Servers and
Universal Gateways.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
231
Outbound Option Description
SIP Dialer Recording
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
232
Outbound Option Description
Call Transfer Timelines
The Outbound Option with SCCP Dialer provides high availability through multiple dialers per Unified CM
cluster. Calls are distributed evenly among the dialers. If a dialer fails, the calls are re-routed to the other
dialers throughout the enterprise that are configured to support the remaining campaign contacts. The calls
that were in progress on the failed dialer are marked for retry.
Note Campaign Manager and Import process components of Outbound Option are simplex components and
must be co-located with the Logger (Side A).
It is normal practice to set up IP phones to be able to fail-over to another Unified CM in case of a Unified CM
node failure in which phones are distributed across the cluster. The Dialer is not a normal phone, and the ports
for a dialer must not be distributed across multiple nodes within the cluster.
The dialer can tax the Unified CM node when starting a campaign or whenever resources are available (agents
or IVR ports for transfer to an IVR campaign). If two dialers are configured to share the Unified CM as part
of a distribution or node failure, a high-availability attempt can have a negative performance impact on the
rest of the system. Each dialer has its own port throttling mechanism, and is not aware that another dialer may
be sharing the same Unified CM. With two dialers competing, the subscriber might enter into a code-yellow
condition.
The general rule in configuring the dialers for high-availability is to do no harm. As part of this guideline, be
aware that dialers significantly affect Unified CM performance.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
233
Outbound Option Description
Design SIP Dialer for High Availability
SIP Dialer
The SIP Dialer is considered in ready state after it has successfully registered with Campaign Manager, has
been configured successfully, has established a CTI connection to CTI Server/Agent PG, and has successfully
sent a heartbeat to the SIP Server. The SIP Server can be a gateway or Unified SIP Proxy Server to which the
SIP Dialer is connected.
In the case of a CTI link or heartbeat failure, the SIP Dialer sends all active and pending customer records to
the Campaign Manager (dialer flush), or closes them internally if the link to the Campaign Manager is not
available. The SIP Dialer cancels alerting calls, abandons the connected calls that have not yet transferred to
outbound agents or IVR , and leaves the outbound calls that were transferred.
The Dialer sends a heartbeat to the gateway in a single gateway deployment or to the Unified SIP Proxy Server
in a multiple gateway deployment. The Dialer transitions to the ready state only when the heartbeat is enabled
and the initial heartbeat is successful.
The heartbeat can be disabled by setting the Dialer Registry, EnableHeartBeat=0.
If the heartbeat fails in several attempts defined by the Dialer registry HBNumTries, the SIP Dialer changes
the state to not ready and updates the status to the Campaign Manager to trigger the warm standby mechanism.
The gateway or Unified SIP Proxy Server does not play any role in warm standby behavior for the SIP Dialer.
An alarm is raised when the SIP Dialer detects SIP Server heartbeat failure.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
234
Outbound Option Description
Cisco Unified Mobile Agent
References
For more information, see the Cisco Outbound Option documentation.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
235
Outbound Option Description
References
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
236
CHAPTER 6
Cisco Unified Mobile Agent
The Cisco Unified Mobile Agent feature enables an agent using any PSTN phone and a broadband VPN
connection (for agent desktop communications) to function just like a Unified CCE agent sitting in a formal
call center and using a Cisco IP Phone monitored and controlled by Cisco Unified Communications Manager
(Unified CM) JTAPI.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
237
Cisco Unified Mobile Agent
Connection Modes
JTAPI to Unified CM for the two CTI ports to do whatever is needed to the media of the call (see the figure
below).
The two CTI ports (local and remote) are logically and statically linked within the PG software by using the
documented naming convention required. The CTI Ports are registered at PG initialization. Call observers are
added for these two CTI Ports when a mobile agent logs in using these CTI Ports. Call control for the CTI
Ports (and thus the call) is provided by the PG. As mentioned earlier, the voice path is between the two Voice
Gateways.
When a mobile agent is in the office, the agent can log in as a non-mobile agent from a JTAPI monitored and
controlled phone, using the same agent ID. (This document refers to these non-mobile agents as local agents.)
Historical call reporting does not distinguish between calls handled as a mobile agent and those handled as a
local agent.
Mobile agent functionality is supported with Unified CM 7.1(2) and later releases. Mobile Agent functionality
is supported with both the System PG and Generic PG.
Queuing calls to mobile agents is supported with both Cisco Unified IP IVR and Unified CVP.
Connection Modes
With Cisco Unified Mobile Agent, administrators can configure agents to use either call-by-call dialing or a
nailed connection, or the administrator can configure agents to choose the connection mode at login time.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
238
Cisco Unified Mobile Agent
Connection Modes
1 At login, a mobile agent specifies their login name or agent ID, password, a local CTI port DN as the
instrument (CTI OS) or extension (Cisco Agent Desktop), and a phone number at which to call them. This
CTI port DN must be selected carefully by an administrator based on the agent’s location. For more
information about agent locations, see Agent Location and Call Admission Control Design.
2 A customer call arrives in the system and is queued for a skill group or an agent through normal Unified
CCE configuration and scripting. This processing is the same as for local agents.
3 When an agent is selected for the call, and if the agent happens to be a mobile agent, then the new processing
for mobile agent begins. The Unified ICM/CCE/CCH CallRouter uses the directory number for the agent’s
local CTI port as the routing label.
4 The incoming call rings at the agent's local CTI port. The Agent PG is notified that the local CTI port is
ringing but does not answer the call immediately. The caller will hear ringing at this point.
5 Simultaneously, a call to the agent is initiated from the remote CTI port for the selected agent. This process
might take a while to complete, depending on connection time. If the agent does not answer within the
configured time, RONA processing is initiated.
6 When the agent answers their phone by going off-hook, this second call is temporarily placed on hold. At
that time, the original customer call is answered and directed to the agent call media address. The agent
call is then taken off hold and directed to the customer call media address. The result is an RTP stream
directly between the two VoIP endpoints.
7 When the call ends, both connections are disconnected and the agent is set to ready, not ready, or wrap-up,
depending on agent configuration and agent desktop input.
If the agent phone is configured with voicemail, disable voicemail to allow RONA call processing to occur.
With call-by-call connection, an agent must answer the phone by going off hook. The Answer button on the
agent desktop will not be enabled.
Auto-answer is not possible with call-by-call connections because there is no call control mechanism to make
the mobile agent phone go off hook.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
239
Cisco Unified Mobile Agent
Supported Mobile Agent and Caller VoIP Endpoints
7 When the agent presses the Answer button to accept the call, the customer call is answered and directed
to the agent call media address. The agent call is then taken off hold and directed to the customer call
media address.
8 When the call ends, the customer connection is disconnected and the agent connection is placed back on
hold. The agent is set to ready, not ready, or wrap-up, depending on agent configuration and agent desktop
input.
A nailed connection mobile agent can log off by using the desktop or by just hanging up the phone.
With a nailed connection, auto-answer is allowed.
A mobile agent nailed connection call can be terminated by the following two Unified CCM timers, and this
termination can log out a nailed connection mobile agent:
• Maximum Call Duration timer (the default value is 720 minutes)
• Maximum Call Hold timer (the default value is 360 minutes)
To keep the mobile agent logged in, set the values for both these timers to 0, which makes the timer never
expire. These timers can be configured from the Unified CCM Administration web page for the service
parameters under the Cisco Unified CM Service.
In a deployment with a firewall, if an agent in nailed connection mode is idle longer than the firewall H.323
Timeout value (which is typically 5 minutes), the media stream can be blocked by the firewall when the
firewall H.323 timeout expires. To prevent this, increase the firewall H.323 timeout value.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
240
Cisco Unified Mobile Agent
Supported Mobile Agent and Caller VoIP Endpoints
In the following figure, Voice Gateways 1A and 1B both register with cluster 1, and Voice Gateway 2 registers
with cluster 2. The call arrives into ingress Voice Gateway 1A and can be routed to any of the four agents.
Mobile agent 4’s IP phone (not monitored and controlled by JTAPI) registers with cluster 2, and there is no
PG for cluster 2. If Silent Monitoring of mobile agent 3 is required, then a Silent Monitoring server must be
deployed for agents connecting through Voice Gateway 2.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
241
Cisco Unified Mobile Agent
Supported Mobile Agent and Caller VoIP Endpoints
VoIP WAN 2. If Agent 3 logged in using a CTI Port pair with the same location as Voice Gateway 1B, then
call admission control would incorrectly assume that the call was traversing VoIP WAN 1 instead of VoIP
WAN 2.
Call admission control sees this mobile agent call as two separate calls. Call leg 1 is the call from the caller
to the agent’s local CTI port, and call leg 2 is the call from the remote CTI port to the agent. Because the CTI
ports are in the same location as the agent endpoint, call admission control counts only the call from the caller
location to the agent location (just like a normal call). This is why it is important for an agent to use CTI ports
for their current location.
From the perspective of call admission control locations for the mobile agent CTI ports, there are three
deployment scenarios. In Figure 110: Mobile Agent Call Scenarios , on page 241, Agent 1 needs to use CTI
ports configured in the same location as the egress Voice Gateway (Voice Gateway 1B) that calls the agent.
Agent 2 needs to use CTI ports configured in the same location as the ingress Voice Gateway (Voice Gateway
1A). Agents 3 and 4 both need to use CTI ports in the same location as the inter-cluster trunk from Cluster 1
to Cluster 2. For each location possibly used by mobile agents, there must be a pool of local and remote CTI
ports. The three pools of CTI ports shown in Figure 110: Mobile Agent Call Scenarios , on page 241 are shown
to be co-located with the VoIP endpoint type for the agent (Voice Gateway or IP phone).
Callers and agents can also use VoIP endpoints on another Unified Communications Manager cluster. As
shown in Figure 110: Mobile Agent Call Scenarios , on page 241, this configuration would allow agents in
remote locations to be called from local Voice Gateways that are associated with a different Unified
Communications Manager cluster. However, a monitoring server is required at the remote site with the agent
(egress) Voice Gateway if Silent Monitoring were required. For more details on Silent Monitoring, see CTI
OS Silent Monitoring.
For additional information about call admission control design, see the call admission control information in
the Cisco Unified Communications SRND.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
242
Cisco Unified Mobile Agent
Supported Mobile Agent and Caller VoIP Endpoints
Note Do not assign MoH resources to local and remote CTI ports because it is unnecessary and might have
some performance impact on the system.
A Mobile Agent remote call over a nailed connection is put on hold when there is no active call to the agent.
In general, enable MoH to the mobile agent phone for nailed connection calls. If MoH resources are an issue,
consider multicast MoH services.
If MoH is disabled for the nailed connection mobile agent remote phone device associated to the call, it is
possible that hold tone is played to the agent phone during the hold time, depending on the call processing
agent that controls the mobile agent remote phone. For Unified CM, the hold tone is enabled by default and
is very similar to the Mobile Agent connect tone. With the Unified CM hold tone enabled, it is very difficult
for the agent to identify if a call has arrived by listening for the Mobile Agent connect tone. Therefore, disable
the hold tone for Unified CM by changing the setting of the Tone on Hold Timer service parameter on Unified
CM. For details on setting this parameter, see the Unified CM product documentation available at cisco.com.
For additional information about MoH design, see the MoH information in the Cisco Collaboration System
Solution Reference Network Designs at http://www.cisco.com/go/ucsrnd.
Codec Design
Media streams between the ingress and egress Voice Gateways can be g.711 or g.729, but not a mix, because
all CTI ports for a PG must advertise the same codec type. This requirement could result in g.711 (instead of
g.729) calls being sent across the WAN. If most calls are routed to agents in the same location as the ingress
Voice Gateway, then sending a few g.711 calls over the WAN might not be an issue. The alternative is to
make all mobile agent calls be g.729. If a very large portion of all Unified CCE calls will always cross a WAN
segment, then it probably makes sense to have all CTI ports configured for g.729. However, it is not possible
to have g.711 for some mobile agent calls and g.729 for others. A dedicated region is required for the CTI
ports to ensure that all calls to and from this region will use the same encoding format.
From the perspective of Silent Monitoring, the CTI OS Supervisor Desktop can silently monitor g.711 or
g.729. All mobile agents would have to use the same codec, but local agents on the supervisor's team could
use a mix of codecs. For more details on Silent Monitoring, see CTI OS Silent Monitoring.
For additional information about codec design considerations, see the media resources information in the
Cisco Unified Communications SRND.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
243
Cisco Unified Mobile Agent
Cisco Unified Mobile Agent Interfaces
The phone number supplied must route to a VoIP endpoint (Voice Gateway, IP phone, or inter-cluster trunk)
in the same location as the CTI port pair used by the agent. Otherwise, call admission control will not work
correctly.
A supervisor using Cisco Supervisor Desktop (CSD) can view the state and real-time statistics for a mobile
agent using Cisco Agent Desktop (CAD). A supervisor using Cisco Supervisor Desktop can also barge-in and
intercept calls of mobile agents using Cisco Agent Desktop. A supervisor using CSD cannot manage agents
(view statistics, Silent Monitor, record, barge-in, or intercept) using CTI-OS Toolkit applications.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
244
Cisco Unified Mobile Agent
Cisco Unified Mobile Agent Interfaces
The CAD SPAN port monitor server provides a mechanism to access an agent’s RTP stream when desktop
monitoring is not possible (primarily for CAD mobile agents, CAD IP Phone Agents, or agents using lower-end
IP phones without a data port for connection to the agent workstation). When a supervisor clicks the Silent
Monitor button on the CSD application, the CSD application requests the SPAN port monitor server for that
agent to forward a copy of both RTP streams for that agent to the CSD application. The CSD application then
blends the two RTP streams and plays the resulting audio stream to the supervisor through the supervisor
workstation speakers. Silent Monitoring uses two one-way RTP streams flowing from the SPAN port monitor
server to the CSD workstation.
If the supervisor using CSD wants to record an agent using CAD, then the supervisor clicks the record button
and the CSD application requests the recording server to request the appropriate SPAN port monitor server
to forward a copy of both RTP streams to the CAD recording server to be saved onto disk. An agent can also
request for a call to be recorded by clicking the Record button (if enabled) on their CAD application. Clicking
this button also sends a request to the recording server to request the appropriate SPAN port monitor server
to forward a copy of both RTP streams to the recording server to be saved onto disk. When recording, there
are two one-way RTP streams flowing from the SPAN port monitor server to the CAD recording server.
CAD SPAN Port Monitoring of the agent Voice Gateway is somewhat different than CAD SPAN Port
Monitoring of local agent Cisco IP Phones. When SPANning a LAN segment with JTAPI monitored and
controlled Cisco IP Phones being used by Unified CCE local agents, the CAD SPAN Port Monitoring software
is searching for RTP packets with the MAC address of the local agent’s Cisco IP Phone. When SPANning a
LAN segment with mobile agent Voice Gateways, the CAD SPAN Port Monitoring software is searching for
RTP packets to and from the agent Voice Gateway IP address and port.
A single CAD SPAN port monitor server can SPAN a network segment with both local agent Cisco IP Phones
and multiple mobile agent Voice Gateways. The CAD SPAN port monitor server is intelligent enough to find
an agent’s RTP stream, whether it is a local agent using a Cisco IP Phone or a mobile agent connected through
an agent Voice Gateway. With CAD, a single CAD deployment for a PG instance can support up to five CAD
SPAN port monitor servers. Voice gateways are statically mapped to a specific SPAN port monitor server,
and multiple agent Voice Gateways can be mapped to the same SPAN port monitor server (assuming the
network SPAN is set up accordingly). Unlike local CAD agents (which are statically associated in CAD
administration to a SPAN port monitor server), mobile CAD agents are not mapped to a specific SPAN Port
Monitoring server. Therefore, when a CAD agent (who is not using desktop monitoring) is a local agent, they
must be using an IP phone on the appropriate LAN segment that is being SPANned by their associated SPAN
port monitor server. However, when that same agent is logging in as a mobile agent, there is no need to worry
about which Voice Gateway or SPAN port monitor server is used to gain access to the RTP streams.
The CAD SPAN port monitor server must run separately from the agent PG, and one NIC must be connected
to the SPAN port of a Cisco Catalyst switch to capture the RTP streams. A second NIC interface on the SPAN
port monitor server is also required to communicate with other Unified CCE components such as the CSD
and the CAD recording server. There is no redundancy for SPAN port monitor servers.
The CAD SPAN port monitor server supports both g.711 and g.729 RTP streams, but it cannot support
encrypted RTP streams.
CAD SPAN Port Monitoring of the ingress (or customer) Voice Gateway is not supported. CAD SPAN Port
Monitoring of mobile agents using Cisco IP Phones is also not supported. For SPAN Port Monitoring to work,
calls must pass through an egress (or agent) Voice Gateway, and the egress Voice Gateway must be a different
Voice Gateway than the ingress Voice Gateway.
For more information about CAD supervisory Silent Monitoring and Recording, see Unified Contact Center
Enterprise Desktop.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
245
Cisco Unified Mobile Agent
Cisco Unified Mobile Agent Interfaces
CTI OS
The latest CTI OS releases support mobile agents. To use the Mobile Agent feature, the system administrator
must enable the mobile agent while running the CTI OS setup program during or after installation. The CTI
OS agent desktop will contain the Mobile Agent checkbox only after the mobile agent is enabled.
At agent login, if the mobile agent mode is selected, the CTI login dialog box is presented to the agent. The
mobile agent must provide the local CTI port extension as the instrument, select a call mode, and provide a
dialable phone number.
The phone number supplied must route to a VoIP endpoint (Voice Gateway, IP phone, or inter-cluster trunk)
in the same location as the CTI port pair used by the agent. Otherwise, call admission control will not work
correctly.
A supervisor using the CTI OS supervisor desktop can view the state and real-time statistics for a mobile
agent using CTI OS agent desktop. A supervisor using the CTI OS supervisor desktop can also barge-in,
intercept, and Silent Monitor calls of mobile agents using the CTI OS agent desktop. CTI OS does not provide
agent call recording.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
246
Cisco Unified Mobile Agent
Cisco Unified Mobile Agent Interfaces
the second server NIC interface is used for the private WAN connection and thus is not available for Silent
Monitoring. Therefore, in duplex Unified CCE installations and as shown in Figure 110: Mobile Agent Call
Scenarios , on page 241, a separate server must be deployed with the Silent Monitor service running. One
NIC interface communicates with supervisor desktops, and the other NIC interface is used to connect to the
SPAN port on the Cisco Catalyst switch.
Note Some switches do allow the destination port of a SPAN configuration to act as a normal network connection
and in that case, only one NIC card is enough. For information about the catalyst switch types that do not
support outgoing traffic on a SPAN destination port, see the “Network Traffic Restrictions” section in this
tech note.
A Silent Monitoring service can monitor multiple ingress or egress Voice Gateways (but not both), and a CTI
OS instance may have only two monitoring services. However, a Unified CM cluster can support multiple
PGs if more monitoring servers are needed.
Mobile agents using IP phones can use desktop monitoring to obtain the RTP stream.
The CTI OS supervisor desktop supports Silent Monitoring of both g.711 and g.729 media streams. The
supervisor desktop is sent copies of whichever encoding format is used by the agent call. Note that there are
two unidirectional media streams from the monitoring server to the supervisor desktop, which represent the
bidirectional media streams of the agent call. The supervisor desktop blends those media streams and plays
the resulting blended media stream through the sound resources on the supervisor workstation.
The CTI OS supervisor desktop enables a supervisor to silently monitor mobile CTI OS agents connected to
any Voice Gateway that is being SPANned by a CTI OS Silent Monitoring service on the same CTI OS
instance. The CTI OS supervisor desktop also allows a supervisor to silently monitor local CTI OS agents by
using desktop monitoring. For more information about desktop monitoring, see Unified Contact Center
Enterprise Desktop.
Unlike CAD SPAN Port Monitoring, CTI OS SPAN Port Monitoring does not statically associate an agent
with a specific SPAN Port Monitoring service.
Cisco Finesse
Cisco Finesse Release 9.0(1) and later supports mobile agents. The Cisco Finesse server does not need to be
reconfigured to enable the Mobile Agent feature. To use the Mobile Agent feature, the system administrator
must follow all configurations as outlined in the Mobile Agent Guide for Cisco Unified Contact Center
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
247
Cisco Unified Mobile Agent
Cisco Unified Mobile Agent Interfaces
On the Finesse sign-in page, if you select the mobile agent check box, the mobile agent options are presented
to the agent. The mobile agent must provide the local CTI port extension in the Extension field, select a mode
(Call by Call or Nailed Connection), and provide a dial number for the agent’s phone.
The phone number the agent supplies must route to a VoIP endpoint (Voice Gateway, IP phone, or inter-cluster
trunk) in the same location as the CTI port pair used by the agent for call admission control to work properly.
A Finesse mobile supervisor can perform all of the functions that a non-mobile supervisor can perform, except
for Silent Monitoring.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
248
Cisco Unified Mobile Agent
Cisco Unified Mobile Agent with Outbound Option for Cisco Unified Contact Center Enterprise and Hosted
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
249
Cisco Unified Mobile Agent
Cisco Unified Mobile Agent Fault Tolerance
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
250
CHAPTER 7
Video Contact Center
With Cisco Video Remote Expert, customers and agents can have a face-to-face conversation over the
network and collaborate like never before.
Through a combination of technologies and design that allows the contact center caller and remote agent to
feel as if they are in the same room, the Cisco Contact Center Enterprise portfolio has the potential to provide
great productivity benefits and transform your business. Organizations use it to control costs, make decisions
faster, improve customer intimacy, and scale scarce resources.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
251
Video Contact Center
Product Overview
Product Overview
Video Remote Expert allows video callers to be queued. Optionally, with CVP Video In Queue (ViQ), the
caller can interact through high definition video prompt or navigate a video menu using DTMF keys.
Feature Summary
Video Endpoints
• Video Agents
EX60 and EX90 as contact center agents in addition to
the following video endpoints: 8941, 8945, 9951, 9971,
E20, and CTS500
• Video callers
EX60, EX90, 8941, 8945, 9951, 9971, E20, CTS500,
and Cius
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
252
Video Contact Center
Video Contact Center Features
Feature Summary
User Experience
• EX90/EX60 can now be used as a standard Enterprise
Contact Center agent on UCM.
• Show and share capability from agent with screen
sharing using dual desktop support from selected agent
endpoints ( EX60, EX90, CTS500).
• Finesse and CTIOS agent desktop support for agent
login, Agent State (Ready, Not Ready), Dial, Answer,
Release and CTI data.
• Supplementary service (Hold, Retrieve, Alternate,
Reconnect, Blind/Consult, Transfer/Conference), support
from Agent Desktop.
Optional: CVP Video in queue (ViQ) Enables caller interaction through high definition video prompt
or navigation through a video menu using DTMF keys
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
253
Video Contact Center
Topology
Topology
The following diagram illustrates topology call flow.
Call flow:
1 Customer submits video call into CCE-CVP data center from branch kiosk.
2 CCE script invokes CVP VXML Server "Call Studio" application.
3 Call is connected to VXML gateway and video playback is invoked from Media Server.
4 Video RTP steamed from Gateway to Phone at branch.
5 Customer navigates IVR video via DTMF digits.
6 Customer submits DTMF for digit collection and stored in Call Context via CCE.
7 When customer selects to talk to agent and agent becomes available, CVP transfers the call from the
VXML gateway to the UCM managed Video Remote Expert.
8 Customer is connected to Agent and video RTP is streaming from customer video phone to the agent video
phone.
9 Via phones, agent can move the video camera around to pan the video if desired.
10 Desktop sharing is also available feature if required.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
254
Video Contact Center
Logical View
Logical View
Figure 117: Logical View
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
255
Video Contact Center
Video Remote Expert Contact Center Data Sheet
Call Flows
Video Infrastructure
The following table displays the video infrastructure:
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
256
Video Contact Center
Video Remote Expert Contact Center Data Sheet
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
257
Video Contact Center
Video Remote Expert Contact Center Data Sheet
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
258
CHAPTER 8
Securing Cisco Unified Contact Center Enterprise
This topic describes the importance of securing the Cisco Unified Contact Center Enterprise (Unified CCE)
solution and points to the various security resources available.
Introduction to Security
Achieving Unified CCE system security requires an effective security policy that accurately defines access,
connection requirements, and systems management within your contact center. A good security policy enables
you to use many state-of-the-art Cisco technologies to protect your data center resources from internal and
external threats. Security measures ensure data privacy, integrity, and system availability.
The security considerations for Unified CCE at a high level are similar to the considerations for the other
applications in a Cisco Unified Communications solution. Deployments of Unified CCE vary greatly and
often call for complex network designs. These deployments require competence in Layer 2 and Layer 3
networking as well as voice, VPN, QoS, Microsoft Windows Active Directory, and other networking issues.
This chapter provides some guidance that touches on these areas. But, this chapter is not an all-inclusive guide
for deploying a secure Unified CCE network.
Along with the Unified Communications Security Solution portal, use other Cisco solution reference network
design guides (SRNDs) in addition to this document to answer many design and deployment questions. These
documents provide information on properly building a network infrastructure for Cisco Unified
Communications. In particular, consult the following relevant documents about security and Cisco Unified
Communications:
• Cisco Unified Communications SRND Based on Cisco Unified Communications Manager
• Data Center Networking: Server Farm Security SRNDv2
• Site-to-Site IPSec VPN SRND
• Voice and Video Enabled IPSec VPN (V3PN) SRND
• Business Ready Teleworker SRND
Updates and additions to these documents are posted periodically, so visit the SRND web site frequently.
This chapter provides limited guidance on the intricacies of designing and deploying a Windows Active
Directory. More information is available from Microsoft on the following topics:
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
259
Securing Cisco Unified Contact Center Enterprise
Security Layers
In particular, see the Designing and Deploying Directory and Security Services section of the Microsoft
Windows Server 2012 R2 Deployment Kit. That section can assist you in meeting all the Active Directory
design and deployment goals for your organization. This development kit and its related documentation are
available from Microsoft.
Security Layers
An adequately secure Unified CCE deployment requires a multilayered approach to protecting systems and
networks from targeted attacks and the propagation of viruses, among other threats. The goal of this chapter
is to stress the various areas pertinent to securing a Unified CCE deployment, but it does not delve into the
details of each area. Specific details can be found in the relevant product documentation.
Implement the following security layers and establish policies around them:
• Physical Security
You must ensure that the servers hosting the Cisco contact center applications are physically secure.
They must be located in data centers to which only authorized personnel have access. The cabling plant,
routers, and switches also have controlled access. Implementing a strong physical-layer network security
plan also includes utilizing such things as port security on data switches.
• Perimeter Security
While this document does not delve into the details on how to design and deploy a secure data network,
it does provide references to resources that can aid in establishing an effective secure environment for
your contact center applications.
• Data Security
To ensure an increased level of protection from eavesdropping for customer-sensitive information,
Unified CCE provides support for Transport Layer Security (TLS) on the CTI OS and Cisco Agent
Desktops. It also supports IPSec to secure communication channels between servers.
• Host-Based Firewall
Users wishing to take advantage of the Windows Firewall to protect from malicious users and programs
that use unsolicited incoming traffic to attack servers can use the Windows Firewall Configuration Utility
on servers or the Agent Desktop Installers to integrate with the firewall component of Windows Server
2008 R2, and Windows XP SP3, respectively.
• Virus Protection
All servers must be running antivirus applications with the latest virus definition files (scheduled for
daily updates). The Hardware & System Software Specification (Bill of Materials) for Cisco Unified
ICM/Contact Center Enterprise & Hosted, Release 9.0(x) contains a list of all the tested and supported
antivirus applications.
• Patch Management
A system is typically not connected to a live network until all security updates have been applied. It is
important for all hosts to be kept up-to-date with Microsoft (Windows, SQL Server, Internet Explorer,
and so forth) and other third-party security patches.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
260
Securing Cisco Unified Contact Center Enterprise
Platform Differences
For most of these security layers, the Unified CCE solution supports a number of capabilities. However, what
Cisco cannot control or enforce is your enterprise policies and procedures for deploying and maintaining a
secure Unified CCE solution.
Platform Differences
Before discussing how to design the various security layers required for a Unified CCE network, this section
introduces the differences that are inherent in the applications making up the Unified CCE solution.
The Unified CCE solution consists of a number of application servers that are managed differently. The
primary servers, those with the most focus in this document, are the Routers, Loggers (also known as Central
Controllers), Peripheral Gateways, Administration & Data Servers, and so forth. These application servers
can be installed only on a standard (default) operating system installation. All installations can be done on
Windows Server 2008 R2 Standard or Enterprise Edition. The maintenance of this operating system in terms
of device drivers, security updates, and so forth, is the responsibility of the customer, as is acquiring the
necessary software from the appropriate vendors. This category of application servers is the primary focus of
this topic.
The secondary group of servers, those running applications that are part of the solution but that are deployed
differently, are Cisco Unified Communications Manager (Unified CM), Cisco Unified IP IVR, and so forth.
Customers are required to obtain all relevant patches and updates to this operating system from Cisco. The
security hardening specifications for this operating system can be found in the Cisco Unified Communications
Solution Reference Network Design (SRND) Guide and other Unified CM documentation at http://
www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html.
The approach to securing the Unified CCE solution as it pertains to the various layers listed above differs
from one group of servers to another. It is useful to keep this in mind as you design, deploy, and maintain
these servers in your environment. Cisco is constantly enhancing its Unified Communications products with
the eventual goal of having them all support the same customized operating system, antivirus applications,
and security path management techniques. Some examples of these enhancements include the support of
Cisco's host-based intrusion prevention software (Cisco Security Agent) and default server hardening provided
by the customized operating system or applications.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
261
Securing Cisco Unified Contact Center Enterprise
Security Best Practices
For the most current security best practices, see the Security Best Practices Guide for Cisco Unified ICM/
Contact Center Enterprise & Hosted, Release 9.x(y).
The guidelines contained in this guide are based in part on hardening guidelines published by Microsoft, such
as those found in the Windows Server 2008 Security Guide, as well as other third-party vendors’ hardening
guidelines. It also serves as a reference point for most of the security functionality in the product. The guide
is also the installation guide for the Automated OS and SQL Security Hardening bundled with the application
installer, Windows Firewall Configuration Utility, the SSL Configuration Utility, the Network Isolation IPSec
Utility, and the Unified CC Security Wizard.
Cisco Security Agent Cisco Security Agent Installation/Deployment Guide for Cisco Unified ICM/Contact
Center Enterprise & Hosted
CTI OS encryption CTI OS System Manager’s Guide for Cisco Unified ICM/Contact Center Enterprise
& Hosted
and
Cisco CAD Installation Guide/Cisco Unified Contact Center Enterprise and Hosted
Release 9.0
SNMPv3 SNMP Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted
authentication and
encryption
Unified ICM Administration Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted
partitioning (Database
Note Partitioning is supported only for Unified ICM Enterprise. It is not supported
object/access control)
in Unified CCE, Unified ICM Hosted, or Unified Contact Center Hosted.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
262
Securing Cisco Unified Contact Center Enterprise
Network Firewalls
Validating real-time Setup and Configuration Guide for Cisco Unified Contact Center Hosted
clients
Network Firewalls
There are several important factors to consider when deploying firewalls in a Unified CCE network. The
application servers making up a Unified CCE solution are not meant to reside in a demilitarized zone (DMZ)
and must be segmented from any externally visible networks and internal corporate networks. The application
servers must be placed in data centers, and the applicable firewalls or routers must be configured with access
control lists (ACL) to control the traffic that is targeted to the servers, thereby allowing only designated
network traffic to pass through.
Deploying the application in an environment in which firewalls are in place requires the network administrator
to be knowledgeable about which TCP/UDP IP ports are used, firewall deployment and topology considerations,
and impact of Network Address Translation (NAT).
TCP/IP Ports
For an inventory of the ports used across the contact center suite of applications, see the Port Utilization Guide
for Cisco Unified Intelligent Contact Management Enterprise & Hosted at http://www.cisco.com/c/en/us/
support/customer-collaboration/unified-contact-center-enterprise/products-configuration-examples-list.html.
To aid in firewall configuration, these guides list the protocols and ports used for agent desktop-to-server
communication, application administration, and reporting. They also provide a listing of the ports used for
intra-server communication.
Topology
The deployment in Figure 119: Active Directory and Firewall Deployment Topology , on page 266 represents
the placement of firewalls and other network infrastructure components in a Unified CCE deployment. The
design model in Figure 116 incorporates a parent Unified ICM system with legacy peripheral hosts and a
child Cisco Unified Contact Center Enterprise with a Unified CM cluster. The following best practices apply
to this type of deployment:
• Block the following ports at the enterprise perimeter firewall:
◦UDP ports 135, 137, 138, and 445
◦TCP ports 135, 139, 445, and 593
• Deploy Layer-3 and Layer-4 ACLs that are configured as described in the port guides.
• Isolate database and web services by installing dedicated historical data servers.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
263
Securing Cisco Unified Contact Center Enterprise
Active Directory Deployment
• Minimize the number of Administration & Data Servers (ADS) and make use of Administration Clients
(no database required) and Internet script editor clients.
• Use the same deployment guidelines when the parent Unified ICM or child Unified CCE central
controllers are geographically distributed.
• Deploy Windows IPSec (ESP) to encrypt intra-server communications. The use of hardware off-load
network cards is required to minimize the impact of encryption on the main CPU and to sustain the load
level (including number of agents and call rate) that is supported with the Unified CCE system. See
IPSec Deployment for a more detailed diagram and further information.
• Use Cisco IOS IPSec for site-to-site VPNs between geographically distributed sites, remote branch sites,
or outsourced sites.
Parent/Child Deployments
The deployment of parent/child systems can be done on the same AD Domain or Forest, but they may also
be deployed in totally disparate AD environments. The scenario where this deployment is common occurs
when the child Unified CCE system is housed at an outsourced contact center site. In this case, the Gateway
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
264
Securing Cisco Unified Contact Center Enterprise
Active Directory Deployment
PG that is a parent node is a member of the parent AD domain. (Do not use Workgroup membership due to
the administration limitations.) This type of deployment is common today for having remote branch offices
with PGs that are added as members of the central site's domain to which the Routers, Loggers, and Distributors
are members.
The topology shown in Figure 119: Active Directory and Firewall Deployment Topology , on page 266
attempts to represent the AD Boundaries for each of the two AD domains involved in this deployment and to
which domain the application servers are joined. The parent AD Domain Boundary is extended beyond the
central data center site to include the Unified ICM Central Controllers and accompanying servers as well as
the ACD PG (at the legacy site) and Gateway PG at the child Unified CCE site. The child Unified CCE site
and its AD Boundary have the Unified CCE servers as members. This may or may not be as part of an
outsourcer’s corporate AD environment. Of course, it may also be a dedicated AD domain for Unified CCE.
AD Site Topology
In a geographically distributed deployment of Unified ICM or Unified CCE, redundant domain controllers
must be located at each of the sites, and properly configured Inter-Site Replication Connections must be
established with a Global Catalog at each site. The Unified CCE application is designed to communicate with
the AD servers that are in their site, but this requires an adequately implemented site topology in accordance
with Microsoft guidelines.
Organizational Units
Application Created
The installation of Unified ICM or Unified CCE software requires that the AD Domain in which the servers
are members must be in Native Mode. The installation will add a number of OU objects, containers, users,
and groups that are necessary for the operation of the software. Adding these objects can be done only in an
Organizational Unit in AD over which the user running the install program has been delegated control. The
OU can be located anywhere in the domain hierarchy, and the AD Administrator determines how deeply
nested the Unified ICM/Unified CCE OU hierarchy is created and populated.
Note Local Server Accounts and groups are not created on the application servers. All created groups are Domain
Local Security Groups, and all user accounts are domain accounts. The Service Logon domain account
is added to the Local Administrators' group of the application servers.
Unified ICM and Unified CCE software installation is integrated with a Domain Manager tool that can be
used standalone for pre-installing the OU hierarchies and objects required by the software, or can be used
when the Setup program is invoked to create the same objects in AD. The AD/OU creation can be done on
the domain in which the running server is a member or on a trusted domain.
AD Administrator Created
As mentioned, there are certain AD objects that may be created by an administrator. The primary example in
Figure 116 is represented by an OU container, Unified CCE Servers, which is manually added to contain the
servers that are members of a given domain. These servers must be moved to this OU once they are joined to
the domain. This ensures that some segregation is applied to control who can or cannot administer the servers
(delegation of control) and, most importantly, which AD Domain Security Policy can or cannot be inherited
by these application servers that are in the OU.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
265
Securing Cisco Unified Contact Center Enterprise
Active Directory Deployment
As noted before, Unified ICM/Unified CCE servers ship with a customized security policy. This policy can
be applied at this server OU level through a Group Policy Object (GPO), but any differing policies must be
blocked from being inherited at the Unified ICM/Unified CCE Servers' OU. Keep in mind that blocking
inheritance, a configuration option at the OU object level, can be overridden when the Enforced/No Override
option is selected at a higher hierarchy level. The application of group policies must follow a very well
thought-out design that starts with the most common denominator, and those policies must be restrictive only
at the appropriate level in the hierarchy. For a more in-depth explanation on how to deploy group policies
properly, see the Windows Server 2008 R2 Security Guide.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
266
Securing Cisco Unified Contact Center Enterprise
IPSec Deployment
• Cisco_ICM organizational unit object hierarchies are created by the application setup.
• Unified ICM Servers and Unified CCE Servers organizational unit objects must be created by the AD
administrators to separately apply custom Cisco Unified ICM Security Policies through a GPO if required.
• Flexible Single Master Operation servers must be distributed across Domain Controllers in the appropriate
sites according to Microsoft guidelines.
IPSec Deployment
The Unified CCE solution relies on Microsoft Windows IPSec and/or Cisco IOS IPSec to secure critical links
between application servers and sites. The solution can be secured either by deploying peer-to-peer IPSec
tunnels between the servers and sites, or by deploying a more restrictive and preconfigured Network Isolation
IPSec policy, or by using a combination of both. The peer-to-peer IPSec deployment requires manual
configuration for each communication path that needs to be secured, using the tools provided by Microsoft.
However, the Network Isolation IPSec policy can be deployed automatically on each server by using the
Network Isolation IPSec utility, and it secures all communication paths to or from that server unless an
exception is made. The Network Isolation IPSec utility is installed by default on all Unified CCE 8.0 servers.
For more details, see the Security Best Practices Guide for Cisco Unified ICM/Contact Center Enterprise &
Hosted, Release 9.x(y).
This guide not only lists the supported paths, but also information to help users deploy Windows IPSec,
including appropriate settings and much more.
Figure 119: Active Directory and Firewall Deployment Topology , on page 266 shows a number of connection
paths where IPSec is supported. The figure below illustrates the guidelines provided in this chapter and shows
the various server interconnections that must be secured with either Windows IPSec or Cisco IOS IPSec. The
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
267
Securing Cisco Unified Contact Center Enterprise
Host-Based Firewall
diagram also shows a number of paths that support TLS. More information about TLS support can be found
in Endpoint Security.
Host-Based Firewall
By providing host firewall protection on the innermost layer of your network, Windows Firewall can be an
effective part of your defense-in-depth security strategy. Unified CCE supports the deployment of Windows
Firewall on the application servers. The Security Best Practices Guide for Cisco Unified ICM/Contact Center
Enterprise & Hosted Release 9.x(y) contains a chapter on the implementation and configuration of this feature.
The configuration of the exceptions and the opening of the ports required by the application will still be done
locally using the Windows Firewall Configuration Utility, which is included with the Unified CCE application.
The Windows Firewall is set up during Unified CCE installation, during which required ports are opened.
For more information about the Windows Firewall, see the Windows Firewall Operations Guide.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
268
Securing Cisco Unified Contact Center Enterprise
Configuring Server Security
Virus Protection
Antivirus Applications
A number of third-party antivirus applications are supported for the Unified CCE system. For a list of
applications and versions supported on your particular release of the Unified CCE software, see the Hardware
& System Software Specification (Bill of Materials) for Cisco Unified ICM/Contact Center Enterprise &
Hosted, Release 9.0(x)) and the Hardware and System Software Specification for Cisco Unified Customer
Voice Portal (Unified CVP), as well as the Cisco Unified CCX and Unified Communications Manager product
documentation for the applications supported. These documents are available on cisco.com.
Deploy only the supported applications for your environment, otherwise a software conflict might arise.
Configuration Guidelines
Antivirus applications have numerous configuration options that allow very granular control of what and how
data must be scanned on a server.
With any antivirus product, configuration is a balance of scanning versus the performance of the server. The
more you choose to scan, the greater the potential performance overhead. The role of the system administrator
is to determine what the optimal configuration requirements for installing an antivirus application within a
particular environment. See the Security Best Practices Guide for Cisco Unified ICM/Contact Center Enterprise
& Hosted, Release 9.x(y) and your particular antivirus product documentation for more detailed configuration
information about a Unified ICM environment.
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, resulting in lower overhead on servers.
• Avoid scanning of any files accessed from remote drives (such as network mappings or UNC connections).
Where possible, each of these remote machines must have its own antivirus software installed, thus
keeping all scanning local. With a multitiered antivirus strategy, scanning across the network and adding
to the network load might not be required.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
269
Securing Cisco Unified Contact Center Enterprise
Intrusion Prevention
• Due to the higher scanning overhead of heuristics scanning over traditional antivirus scanning, use this
advanced scanning option only at key points of data entry from untrusted networks (such as email and
Internet gateways).
• Real-time or on-access scanning can be enabled, but only on incoming files (when writing to disk). This
is the default setting for most antivirus applications. Implementing on-access scanning on file reads will
yield a higher impact on system resources than necessary in a high-performance application environment.
• While on-demand and real-time scanning of all files gives optimum protection, this configuration does
have the overhead of scanning those files that cannot support malicious code (for example, ASCII text
files). Exclude files or directories of files in all scanning modes that are known to present no risk to the
system. Also, follow the guidelines for which specific Unified CCE files to exclude in Unified CCE
implementation, as provided in the Security Best Practices Guide for Cisco Unified ICM/Contact Center
Enterprise & Hosted, Release 9.x(y).
• 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, see the Security Best Practices Guide for
Cisco Unified ICM/Contact Center Enterprise & Hosted, Release 9.x(y) listed in the previous item.
Intrusion Prevention
Cisco does not test or support intrusion prevention products by vendors such as Sygate, McAfee, and so on.
Such products are capable of blocking legitimate application functionality if they incorrectly identify that
application as a security threat. These products must be configured to allow legitimate operations to execute.
Patch Management
Security Patches
The security updates qualification process for Contact Center products is documented.
This process applies to the application servers running the standard Windows Operating System, not the
customized Cisco Unified Communications operating system (CIPT OS).
Follow Microsoft guidelines regarding when and how to apply updates. All Contact Center customers must
separately assess all security patches released by Microsoft and install those deemed appropriate for their
environments. For information about tracking Cisco-supported operating system files, SQL Server, and security
files, see Cisco IP Telephony Operating System, SQL Server, Security Updates.
The Security Patch and Hotfix Policy for Unified CM specifies that any applicable patch deemed Severity 1
or Critical must be tested and posted to cisco.com within 24 hours as Hotfixes. All applicable patches are
consolidated and posted once per month as incremental Service Releases.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
270
Securing Cisco Unified Contact Center Enterprise
Endpoint Security
by polling a server that is running Microsoft Window Update Services in place of the default Windows Update
Web site.
For more configuration and deployment information, see the Deployment Guide and other step-by-step guides.
More information is also available on this topic in the Security Best Practices Guide for Cisco Unified ICM/
Contact Center Enterprise & Hosted, Release 9.x(y).
The Cisco Unified Communications Operating System configuration and patch process does not currently
allow for an automated patch management process.
Endpoint Security
Agent Desktops
The CTI OS (C++/COM toolkit) and CAD agent desktops both support TLS encryption to the server. This
encryption protects agent login and CTI data from snooping. A mutual authentication mechanism was
implemented for the CTI OS Server and client to agree on a cipher suite used for authentication, key exchange,
and stream encryption. The cipher suite used is as follows:
• Protocol: SSLv3
• Key exchange: DH
• Authentication: RSA
• Encryption: AES (128)
• Message digest algorithm: SHA1
The following figure shows the encryption implementation's use of X.509 certificates on the agent desktops
as well as on the servers. The implementation supports the integration with a Public Key Infrastructure (PKI)
for the most secure deployment. By default, the application installs and rely on a self-signed certificate authority
(CA) used to sign client and server requests. However, Cisco supports integration with a third-party CA. This
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
271
Securing Cisco Unified Contact Center Enterprise
Endpoint Security
integration is the preferred method due to the increased security provided by a corporate-managed CA or
external authority such as Verisign.
The following figure shows the Certificate Authority enrollment procedure to generate certificates used by
the agent and the servers. The agent desktop certificate enrollment process is manual, requiring the creation
of certificate signing requests (CSRs) at each endpoint, which are then transferred to the certificate authority
responsible for signing and generating the certificates.
Cisco Finesse Release 9.1(1) and later supports HTTPS for the Administration Console and Agent and
Supervisor Desktops. HTTPS is not supported for Agent and Supervisor Desktops in large deployments (over
1000 agents).
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
272
Securing Cisco Unified Contact Center Enterprise
Endpoint Security
IP Phone Hardening
The IP phone device configuration in Unified CM provides the ability to disable a number of phone features
to harden the phones, such as disabling the phone's PC port or restricting a PC from accessing the voice VLAN.
Changing some of these settings can disable the monitoring/recording feature of the Unified CCE solution.
The settings are defined as follows:
• PC Voice VLAN Access
◦Indicates whether the phone will allow a device attached to the PC port to access the Voice VLAN.
Disabling Voice VLAN Access will prevent the attached PC from sending and receiving data on
the Voice VLAN. It will also prevent the PC from receiving data sent and received by the phone.
Disabling this feature will disable desktop-based monitoring and recording.
◦Setting: Enabled (default)
• Span to PC Port
◦Indicates whether the phone will forward packets transmitted and received on the Phone Port to
the PC Port. To use this feature, PC Voice VLAN access must be enabled. Disabling this feature
will disable desktop-based monitoring and recording.
◦Setting: Enabled
Disable the following setting to prevent man-in-the-middle (MITM) attacks unless the third-party monitoring
and/or recording application deployed uses this mechanism for capturing voice streams. The CTI OS Silent
Monitoring feature and CAD Silent Monitoring and Recording do not depend on Gratuitous ARP.
• Gratuitous ARP
◦Indicates whether the phone will learn MAC addresses from Gratuitous ARP responses.
◦Setting: Disabled
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
273
Securing Cisco Unified Contact Center Enterprise
Endpoint Security
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
274
CHAPTER 9
Sizing Contact Center Resources
Central to designing a Cisco Unified Contact Center (or any contact center) is the proper sizing of its resources.
This chapter discusses the tools and methodologies needed to determine the required number of contact
center agents (based on customer requirements such as call volume and service level desired), the number
of Unified IP IVR ports required for various call scenarios (such as call treatment, prompt and collect,
queuing, and self-service applications), 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.
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 resources in a Unified CCE deployment. Examples
are provided to illustrate how resources can be impacted under various call scenarios such as call treatment
(prompt and collect) in the Unified IP IVR and agent wrap-up time. These tools and methodologies are
intended as building blocks for sizing contact center resources and for any telephony applications in general.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
275
Sizing Contact Center Resources
Contact Center Basic Traffic Terminology
sized for the peak periods. In some retail environments, additional trunks can be added during the peak season
and disconnected afterwards.
Servers
Servers are resources that handle traffic loads or calls. There are many types of servers in a contact center,
such as PSTN trunks and gateway ports, agents, voicemail ports, and VRU ports.
Talk Time
Talk time is the amount of time an agent spends talking to a caller, including the time an agent places a caller
on hold and the time spent during consultative conferences.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
276
Sizing Contact Center Resources
Contact Center Basic Traffic Terminology
Erlang
Erlang is a measurement of traffic load during the busy hour. The Erlang is based on having 3600 seconds
(60 minutes, or 1 hour) of calls on the same circuit, trunk, or port. (One circuit is busy for one hour regardless
of the number of calls or how long the average call lasts.) If a contact center receives 30 calls in the busy hour
and each call lasts for six minutes, this equates to 180 minutes of traffic in the busy hour, or 3 Erlangs (180
min/60 min). If the contact center receives 100 calls averaging 36 seconds each in the busy hour, then total
traffic received is 3600 seconds, or 1 Erlang (3600 sec/3600 sec).
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. K. Erlang, the originator of queuing theory used
in traffic engineering.
Blocked Calls
A blocked call is a call that is not serviced immediately. Callers are considered blocked if they are rerouted
to another route or trunk group, if they are delayed and put in a queue, or if they hear a tone (such as a busy
tone) or announcement. The nature of the blocked call determines the model used for sizing the particular
resources.
Service Level
This term is a standard in the contact center industry, and it refers to the percentage of the offered call volume
(received from the Voice Gateway and other sources) that are answered within x seconds, where x is a variable.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
277
Sizing Contact Center Resources
Contact Center Resources and the Call Timeline
A typical value for a sales contact center is 90% of all calls answered in less than 10 seconds (some calls are
delayed in a queue). A support-oriented contact center might have a different service level goal, such as 80%
of all calls answered within 30 seconds in the busy hour. Your contact center's service level goal determines
the number of agents needed, the percentage of calls that are queued, the average time calls spend in queue,
and the number of PSTN trunks and Unified IP IVR ports needed. For an additional definition of service level
within Unified CCE products, see the Unified CCE glossary, which is available in the Configuration Manager’s
online help.
Queuing
When agents are busy with other callers or are unavailable (after call wrap-up mode), subsequent callers must
be placed in a queue until an agent becomes available. The percentage of calls queued and the average time
spent in the queue are determined by the service level desired and by agent staffing. Cisco's Unified CCE
solution uses a Unified IP IVR to place callers in queue and play announcements. It can also be used to handle
all calls initially (call treatment, 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, airline arrival/departure times, and so forth). Each of
these scenarios requires a different number of Unified IP IVR ports to handle the different applications because
each has a different average handle time and possibly a different call load. The number of trunks or gateway
ports needed for each of these applications will also differ accordingly.
It is helpful first to understand the anatomy of an inbound contact center call as it relates to the various resources
used and the holding time for each resource. The following figure shows the main resources and the occupancy
(hold/handle time) for each of these resources.
Ring delay time (network ring) must be included, if calls are not answered immediately. This delay can be a
few seconds on average, and it must be added to the trunk average handle time.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
278
Sizing Contact Center Resources
Erlang Calculators as Design Tools
For purposes of this document, there are mainly two traffic models that are commonly used in sizing contact
center resources, Erlang-B and Erlang-C. There are many other resources on the internet that give detailed
explanations of the various models (search using traffic engineering).
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 VRU ports do I need?
Before you can answer these basic questions, 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, or percent blockage, desired for PSTN trunks and Unified IP IVR ports
The next two sections of this chapter present a brief description of the generic Erlang models in simple terms.
Also described are the input/output of the Erlang models and which model to use for sizing the specific contact
center resource (agents, gateway ports, and Unified IP IVR ports). There are various web sites that provide
contact center sizing tools free of charge (some offer feature-rich versions for purchase), but they all use the
two basic traffic models, Erlang-B and Erlang-C. Cisco does not endorse any particular vendor product; it is
up to the customer to choose which tool suits their needs. The input required for any of the tools, and the
methodology used, are the same regardless of the tool itself.
Erlang-C
The Erlang-C model is used to size agents in contact centers that queue calls before presenting them to agents.
This model assumes:
• Call arrival is random.
• If all agents are busy, new calls are queued and not blocked.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
279
Sizing Contact Center Resources
Erlang Calculators as Design Tools
• The delay or service level desired, 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, the percentage of calls delayed or
queued when no agents are available, and the average queue time for these calls.
Erlang-B
The Erlang-B model is used to size PSTN trunks, gateway ports, or Unified IP IVR ports. It assumes the
following:
• Call arrival is random.
• If all trunks/ports are occupied, new calls are lost or blocked (receive busy tone) and not queued.
The input and output for the Erlang B model consists of the following three factors. You need to know any
two of these factors, and the model will calculate the third:
• Busy Hour Traffic (BHT), or the number of hours of call traffic (in Erlangs) during the busiest hour of
operation. BHT is the product of the number of calls in the busy hour (BHCA) and the average handle
time (AHT).
• Grade of Service, or the percentage of calls that are blocked because not enough ports are available.
• Ports (lines), or the number of Unified IP IVR or gateway ports.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
280
CHAPTER 10
Sizing Unified CCE Components and Servers
Proper sizing of your Cisco Unified Contact Center Enterprise (Unified CCE) solution is important for
optimum system performance and scalability. Sizing considerations include the number of agents the solution
can support, the maximum busy hour call attempts (BHCA), and other variables that affect the number, type,
and configuration of servers required to support the deployment. Regardless of the deployment model chosen,
Unified CCE is based on a highly distributed architecture, and questions about capacity, performance, and
scalability apply to each element within the solution as well as to the overall solution.
This chapter presents design practices focusing on scalability and capacity for Unified CCE deployments.
The design considerations and capacities presented in this chapter are derived primarily from testing and, in
other cases, extrapolated test data. This information is intended to enable you to size and provision Unified
CCE solutions appropriately.
Sizing Tools
Sizing tools are available online.
The sizing tools are available to Cisco internal employees and Cisco partners only, and proper login
authentication is required.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
281
Sizing Unified CCE Components and Servers
Sizing Considerations for Unified CCE
Note Unless otherwise explicitly noted, the capacity information presented in Operating Conditions specifies
capacity for inbound calls only and does not apply equally to all implementations of Unified CCE. The
data is based on testing in particular scenarios, and it represents the maximum allowed configuration. This
data, along with the sizing variables information in this chapter, serves only as a guide. As always, be
conservative when sizing and plan for growth.
Note Sizing considerations are based on capacity and scalability test data. Major Unified CCE software processes
were run on individual servers to measure their specific CPU and memory usage and other internal system
resources. Reasonable extrapolations were used to derive capacities for co-resident software processes
and multiple CPU servers. This information is meant as a guide for determining when Unified CCE
software processes can be co-resident within a single Server and when certain processes need their own
dedicated server. Table 1 assumes that the deployment scenario includes two fully redundant servers that
are deployed as a duplexed pair.
Note The Cisco Unified Contact Center solution does not provide a quad-processor Cisco MCS Unified CM
appliance at this time. For the most current server specifications, see the latest version of the Hardware
& System Software Specification (Bill of Materials) for Cisco Unified ICM/Contact Center Enterprise &
Hosted.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
282
Sizing Unified CCE Components and Servers
Operating Conditions
Operating Conditions
The sizing information presented in this chapter is based on the following operating conditions:
• Maximum of 30 busy hour call attempts (BHCA) per agent.
• Five skill groups or precision queues per agent.
• The total number of agents indicated in the following tables and figures consists of 90% agents and 10%
supervisors. For example, if a table or figure indicates 100 agents, the assumption is that there are 90
agents and 10 supervisors.
• Supervisors do not handle calls.
• Total number of teams is equal to 10% of total number of agents.
• Team members consist of 90% agents and 10% supervisors.
• Call types consist of 85% straight calls, 10% consultative transfers, and 5% consultative conferences.
• The default refresh rate for skill group updates is 10 seconds.
• The default number of skill group statistics columns configured at the CTI OS server is 17 columns.
• Agent Statistics is turned ON.
• The default number of agent statistics columns configured at the CTI OS server is 6 columns.
• Average of five Voice Response Unit (VRU) scripts, running consecutively in the Unified CCE script,
per IVR call.
• Five Expanded Call Context (ECC) scalars.
• Transport Layer Security (TLS) for CTI OS is turned OFF.
• No mobile agents.
• One all-events CTI server client.
• Outbound hit rate is averaged at 30%.
The following notes apply to all figures and tables in this topic:
• The number of agents indicates the number of logged-in agents
• Server types:
◦APG = Agent Peripheral Gateway
◦PGR = Progger
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
283
Sizing Unified CCE Components and Servers
Operating Conditions
◦RGR = Rogger
Figure 124: Minimum Servers Required for Release 8.0(x) Unified CCE Deployments with CTI OS Desktop
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
284
Sizing Unified CCE Components and Servers
Operating Conditions
Note The terms Rogger and Central Controller are used interchangeably throughout this chapter.
Figure 125: Minimum Servers Required for Release 8.0(x) and Later Unified CCE Deployments with Cisco Agent Desktop
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
285
Sizing Unified CCE Components and Servers
Operating Conditions
Table 11: Sizing Information for Unified CCE Components and Servers
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
286
Sizing Unified CCE Components and Servers
Operating Conditions
Logger GEN-50-006-Class 12,000 After you install the Unified Contact Center
Enterprise Logger component in a large
GEN-50-007-Class
capacity deployment (>8,000 agents), you must
adjust the Microsoft SQL server Jobs for daily
purge. Use Microsoft SQL Management
Studio; adjust the following purge jobs to be
30 minutes apart from one another during a
non-busy call volume interval: TCD, RCD,
RCV, and TCV. It is important to monitor the
SQL server purge jobs to be sure that they are
completing successfully and the four purge
jobs mentioned before are not overlapping. If
they are overlapping, and causing performance
related issues on the logger, further
adjustments of the jobs may be required.
Router MCS-40-005-Class 8000 MCS-30-00x-Class servers are not supported.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
287
Sizing Unified CCE Components and Servers
Operating Conditions
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
288
Sizing Unified CCE Components and Servers
Operating Conditions
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
289
Sizing Unified CCE Components and Servers
More Sizing Factors
In addition to the MCS models listed above, there are other server models based on Intel Xeon Nehalem
quad-core technology that can be used for Unified CCE deployments. For further details, see the latest version
of the Hardware & System Software Specification (Bill of Materials) for Cisco Unified ICM/Contact Center
Enterprise & Hosted, Release 9.0(x).
Agents
The number of agents is another important metric that impacts the performance of most Unified CCE server
components, including Unified Communications Manager clusters. For the impact of agents on the performance
of Unified Communications Manager components, see Sizing Cisco Unified Communications Manager
Servers.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
290
Sizing Unified CCE Components and Servers
More Sizing Factors
You can also manage the effects on the CTI OS Server by increasing the value for the frequency of statistical
updates.
The Finesse server does not display statistics for unused skill groups. Therefore, the number of skill groups
that are assigned to agents affects the performance of the Finesse server more than the total number of skill
groups configured. The Finesse server supports a maximum of 1961 skill groups assigned to agents, not
including the default skill group.
Queue (skill group) statistics are updated on the Finesse Desktop at 10-second intervals. The Finesse Desktop
also supports a fixed number of queue statistics fields. These fields cannot be changed.
The first table shows examples of how the number of skill groups or precision queues (PQ) per agent can
affect the capacity of the Unified CCE system. The numbers in this table are based on the information listed
in the section on Operating Conditions, and it shows capacity per CTI OS instance. The Finesse server supports
the same number of agents and skill groups as CTI OS. The Finesse server supports a maximum of 50 unique
skill groups across all agents on a supervisor’s team, including the supervisor’s own skill groups. If this number
is exceeded, all skill groups monitored by the supervisor still appear on the Finesse Desktop. However,
exceeding this number may cause performance issues and is not supported.
Note Each Precision Queue that you configure creates a Skill Group per Agent PG and counts toward the
supported number of Skill Groups per PG.
The numbers in this table are subject to specific hardware and software requirements. For information about
12,000 agent support, see the Hardware and System Software Specification (Bill of Materials) for Cisco
Unified ICM / Contact Center Enterprise & Hosted.
Table 12: Sizing Effects Due to Number of Skill Groups/Precision Queues Per Agent (12,000 Agents)
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
291
Sizing Unified CCE Components and Servers
More Sizing Factors
Table 13: Sizing Effects Due to Number of Skill Groups/Precision Queues Per Agent (8000 Agents)
Note CTI OS monitor mode applications are supported only at 20 or lower skill groups per agent.
Note Supervisors can monitor only agents within their own team, all whom must be configured on the same
peripheral.
A Unified CCE 9.x system can support a maximum of 50 agents per supervisor with the following assumptions.
If a particular environment requires more than 50 agents per supervisor, then use the following formula to
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
292
Sizing Unified CCE Components and Servers
More Sizing Factors
ensure that there is no impact to the CTI OS Server and Supervisor desktop. The most important factor in this
calculation is the number of updates per second.
X = (Y * (N + 1) / R) + ((Z * N * A) / 3600), rounded up to the next integer
Where:
X = Number of updates per second received by the CTI OS Supervisor desktop.
Y = Weighted Average of Number of Skill Groups or Precision Queues per Agents. For example, if total of
10 agents have the following skill group distribution: 9 have 1 skill group and 1 agent has 12 Skill Groups.
The number of skills per agent ('Y') is, Y = 90% * 1 + 10% * 12 = 2.1. (The number of configured statistics
in CTI OS server is 17.)
Z = Calls per hour per agent.
A = Number of agent states. (Varies based on call flow; average = 10.)
N = Number of agents per supervisor.
R = The skill group or precision queue refresh rate configured on the CTI OS Server. (Default = 10 seconds.)
(Y * (N + 1) / R) = Number of updates per second, based on skill groups.
(Z * N * A) / 3600 = Number of updates per second, based on calls.
The CTI OS Supervisor desktop is not impacted as long as there are fewer than 31 updates per second. This
threshold value is derived with the previous formula to calculate the update rate for 50 agents per supervisor
(N = 50), as follows:
X = (5 * (50 + 1) / 10) + ((30 * 50 * 10) / 3600) = 25.5 + 5 = 31 updates per second
The maximum number of agents per supervisor must not exceed 200 for any given configuration, still holding
updates per sec to a max of 31 with above formula.
Call Types
The call type is also an important metric that impacts performance of most Unified CCE server components.
An increase in the number of transfers and conferences increase the load on the system and, thus, decrease
the total capacity.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
293
Sizing Unified CCE Components and Servers
More Sizing Factors
Queuing
The Unified IP IVR and Unified Customer Voice Portal (CVP) place calls in a queue and play announcements
until an agent answers the call. For sizing purposes, 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, or whether the agents
will handle calls immediately and the IVR will queue only unanswered calls when all agents are busy. The
answer to this question determines different IVR sizing requirements and affects the performance of the Call
Router/Logger and Voice Response Unit (VRU) PG.
Reporting
Real-time reporting can have a significant effect on Logger, Progger, and Rogger processing due to database
access. A separate server is required for an Administration & Data Server to off-load reporting overhead from
the Logger, Progger, and Rogger.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
294
Sizing Unified CCE Components and Servers
Peripheral Gateway and Server Options
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
295
Sizing Unified CCE Components and Servers
Cisco Agent Desktop Component Sizing
Maximum number of PG types per server platform Up to two PG types are permitted per server, provided
that any given server is limited to the maximum agent
and VRU port limitations outlined in Table 11: Sizing
Information for Unified CCE Components and
Servers, on page 286.
Maximum number of Unified CM PGs per server Only one Unified CM PG, Generic PG, or System
PG is allowed per physical server.
Maximum number of Unified CM PIMs per PG 10 Unified CM PIMs with associated Agents can be
configured per PG, provided that any given server is
limited to the maximum agent and VRU port
limitations outlined in Table 11: Sizing Information
for Unified CCE Components and Servers, on page
286.
However, if any VRU PIM is configured, a generic
PG cannot support configuration of more than 1 CM
PIM.
See Peripheral Gateway Design Considerations for
more information.
Maximum number of IVRs controlled by one Unified See the Cisco Unified Communications Solution
CM Reference Network Design (SRND) Guide at http://
www.cisco.com/en/US/products/sw/voicesw/ps556/
tsd_products_support_series_home.html.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
296
Sizing Unified CCE Components and Servers
CTI OS for Cisco VXI
This section presents sizing guidelines for the Cisco Agent Desktop Server components.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
297
Sizing Unified CCE Components and Servers
Agent Greeting Sizing Considerations
Dedicated 80
Central Controller
Agent Greeting has an impact of up to 1.5 regular calls on the Router and Logger. This implies that the
maximum call rate on Unified CCE is reduced from 60 calls per second to 40 calls per second, as measured
by new calls that originate from the service provider. As each Agent Greeting involves an additional route
request, the Router PerfMon counter displays 80 calls per second under a full supported load. The number of
agents supported per System is dependent upon the overall call rate. For a specific scenario, see the Unified
CCE Sizing Tool.
Peripheral Gateway
Agent Greeting does have an impact on the PG resource utilization, but it is not enough impact to require
reducing the supported agent capacity per PG. Other factors like additional skill groups per agent or total
configured skill groups also play a factor in PG sizing, as does having two agent peripherals on the same PG.
When sizing the PG, the sizing calculator factors in Agent Greeting.
Communications Manager
When Agent Greeting and/or Mobile Agent and Unified IP IVR are in use, the number of agents supported
by a Unified Communications Manager subscriber is impacted.
The Cisco Unified Collaboration Sizing Tool takes call rate and the other factors into account to determine
the capacity for a specific scenario.
Mobile Agent
Agent Greeting with Mobile Agent uses additional Conference Bridge and MTP resources. The agent greeting
calls are relatively short and they need not be factored into sizing considerations. To properly size Conference
Bridge and UCM resources, indicate a conference in place of an Agent Greeting for each Mobile Agent (when
Agent Greeting is enabled) for each inbound call.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
298
Sizing Unified CCE Components and Servers
CVP and VXML Gateway
Congestion Control
Unified CCE 9.0 introduced the Congestion Control Feature, which provides protection to the Central Control
Router from overload conditions, due to high call rates. The main objective of congestion control is to keep
the system running close to its rated capacity, when faced with extreme overload. The goal is to give satisfactory
service to a smaller percentage of calls (your capacity) rather than a highly degraded service to all the calls,
during an overloaded condition. This is achieved by restricting capacity on the system by rejection calls by
the Routing Clients at the call entry point. Throttling the capacities ensures the service of those calls routed
is successful, meaning no lates or timeouts.
The measured CPS at router is the trigger for identifying congestion in the system. For a given deployment,
the supported capacity is set when the deployment type is selected. The router measures the new incoming
call requests from all the routing clients and computes moving weighted average over sample duration. If the
average CPS exceeds beyond the thresholds for each level, the congestion levels are changed along with the
reduction percentage. The congestion control algorithm utilizes 3 congestion levels and rejects/treats the
incoming calls as per the reduction percentage for that level. The change in congestion level is notified to the
routing clients: NICs and PGs. The routing clients start rejecting/treating calls based on reduction percentage.
For every instance of ICM/CCE deployment, the user needs to select the type of deployment. As part of the
deployment type selection, the CPS capacity is automatically set. In a multiple instance deployments like
Network Application Manager/Customer ICM (NAM/CICM) as shown in the following diagram, the congestion
control is done based on the call rate measured at each instance. The calls rejected are treated based on the
congestion level in that instance. For example, if a call arrives at NAM instance through VRU PGs or NICs,
if NAM router is congested, then the VRU PGs or NICs will apply the congestion logic and reject/treat the
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
299
Sizing Unified CCE Components and Servers
Deployment Types
calls. Similarly if the CICM is congested, and NAM does CICM lookup for routing any calls, such calls are
subjected to congestion control at INCRP NIC at CICM instance.
Deployment Types
After upgrading or installing the system, configure the system to a valid deployment type. The following table
lists the supported deployment types with guidelines for selecting a valid deployment type.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
300
Sizing Unified CCE Components and Servers
Deployment Types
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
301
Sizing Unified CCE Components and Servers
Deployment Types
5 Unified CCE 8000 Agents Router/ Select this deployment for type
Logger CCE Enterprise system where only
CCE PGs are deployed. The system
should be distributed deployment
with Router and Logger installed
on different servers which meet the
requirements for 8000 CCE agents
as specified in Cisco ICM/Contact
Center Enterprise and Hosted
Hardware and System Software
Specification (Bill of Materials
(BOM)).
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
302
Sizing Unified CCE Components and Servers
Deployment Types
9 Unified CCE 4000 Agents Rogger Select this deployment type for
CCE Enterprise system where only
CCE PGs are deployed. The system
should be distributed deployment
with Router and Logger installed
on different servers which meet the
requirements for 4000 CCE agents
as specified in Cisco ICM/Contact
Center Enterprise and Hosted
Hardware and System Software
Specification (Bill of Materials
(BOM)).
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
303
Sizing Unified CCE Components and Servers
Congestion Treatment Mode
13 Unified CCE 450 Agents Progger Select this deployment type when
Router, Logger and PG are
installed on the same server. For
all lab deployments, this type
should be selected although Router,
Logger and PG are not on the same
box.
Note Progger deployment is not
supported for production
use.
Note It is very important to assess the deployment type of the system and set it in the configuration. In case of
wrong deployment type selection, the system will either be unprotected from overload or will reject/treat
the calls based on incorrect capacity settings.
The treatment options are set either at routing client or at global level system congestion settings. If the
treatment mode is not selected at the routing client, the system congestion settings are applied for treating the
calls.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
304
Sizing Unified CCE Components and Servers
Congestion Control Levels and Thresholds
Note If you select the treatment option to return a label back to treat the call with an announcement, then the
announcement system should be external to CCE instance. In any case the call that is treated should not
be re-entered into system for further processing.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
305
Sizing Unified CCE Components and Servers
Real-Time Capacity Monitoring
Note The onset, abate and reduction settings are system defined and are not configurable by the user. These
values are defined as a percentage of the CPS capacity that is defined for the system.
For a detailed description of these reports refer to the Reporting Guide for Cisco Unified ICM/CCE and Hosted
at http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/
products-user-guide-list.html.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
306
Sizing Unified CCE Components and Servers
Congestion Control Configuration
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
307
Sizing Unified CCE Components and Servers
Peripheral Throttling
• Upgrade all PG before enabling the congestion control - Enable congestion to reject/treat calls only after
all the PGs in the system is upgraded to 9.0. This will ensure uniform rejection of calls across all the
routing clients in system.
• Upgrade selected PGs: If there are options in the enterprise where few PGs can reject more calls, upgrade
those PGs first and then the remaining PG.
Peripheral Throttling
To mitigate possible overload conditions on the agent peripheral, Precision Routing limits the number of calls
to the peripheral when it detects an overload condition. When this occurs, the system stops routing Precision
Routing calls to that peripheral for a short period of time.
Important The Agent PG does not support having both seven All-Event clients on the CTI server and five
monitor-mode connections on the CTI OS server. Your design must trade off one for the other to stay
within the combined maximum of 9.
Note These higher limits assume that the All-Event Clients use Event Minimization in their CTI Server protocol
integration.
Unlike VMs built from the smaller OVA, these limits are not linked. The number of All-Event Clients does
not limit the number of monitor-mode connections that you can have on the large VMs. You can use the
maximum amount of each type, if your system can support the load.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
308
Sizing Unified CCE Components and Servers
System Performance Monitoring
All-Event Clients
Each of the agent desktop solutions (Cisco Finesse, CTI OS Desktop, and Cisco Agent Desktop) use 2 of the
available All-Event clients. Some of the possible consumers of the clients are:
• CAD IP Phone Agent (2)
• Real Time Adherence (2)
• Some third-party recording vendors (2)
• Unified WIM and EIM (2)
• Cisco Media Blender
• B&S MCAL
• Remote Silent Monitor
Monitor-Mode Connections
If your deployment uses the CTI OS server, it begins with two monitor-mode connections on each side of the
redundant pair. However, you cannot configure those connections to fail over to the other side in a failure. In
a failure on Side A, the resources connected to the CTI OS server on Side A cannot reconnect to the Side B
server. Those extra connections would push Side B past the combined maximum of nine.
The following list highlights some of the important counters for the critical system components, along with
their threshold values:
• Monitoring the CPU
◦%Processor Time; the threshold of this counter is 60%.
◦ProcessorQueueLength; this value must not go above (2 * [the total number of CPUs on the system]).
• Monitoring Memory
◦% Committed Bytes; this value must remain less than (0.8 * [the total amount of physical memory]).
◦Memory\Available MByte; this value must not be less than 16 MB.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
309
Sizing Unified CCE Components and Servers
Summary
Note The above performance counters for CPU, memory, disk, and network are applicable to all servers within
the deployment. The preferred sample rate is 15 seconds.
Summary
Proper sizing of Unified CCE components requires analysis beyond the number of agents and busy hour call
attempts. Configurations with multiple skill groups per agent, significant call queuing, and other factors
contribute to the total capacity of any individual component. Careful planning and discovery in the pre-sales
process uncovers critical sizing variables; apply these considerations to the final design and hardware selection.
Correct sizing and design can ensure stable deployments for large systems up to 8000 agents and 216,000
BHCA. For smaller deployments, cost savings can be achieved with careful planning and co-resident Unified
CCE components (for example, Progger, Rogger, and Agent PG).
Additionally, pay careful attention to the sizing variables that will impact sizing capacities such as skill groups
per agent. While it is often difficult to determine these variables in the pre-sales phase, it is critical to consider
them during the initial design, especially when deploying co-resident PGs and Proggers. While new versions
will scale far higher, 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.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
310
CHAPTER 11
Sizing Cisco Unified Communications Manager
Servers
This chapter discusses the concepts, provisioning, and configuration of Cisco Unified Communications
Manager (Unified CM) clusters when used in a Unified CCE deployment. Unified CM clusters provide a
mechanism for distributing call processing across a converged IP network infrastructure to support Cisco
Unified Communications, facilitate redundancy, and provide feature transparency and scalability.
This chapter covers only the Unified CCE operation with Unified CM clusters and proposes reference designs
for implementation.
The information in this chapter builds on the concepts presented in the Cisco Unified Communications
SRND. Some duplication of information is necessary to clarify concepts relating to Unified CCE as an
application supported by the Unified CM call processing architecture. However, the foundational concepts
are not duplicated here; become familiar with them before continuing with this chapter.
This chapter documents general best practices and scalability considerations for sizing the Unified CM
servers used with your Unified CCE deployments. Within the context of this document, scalability refers to
Unified CM Server and/or cluster capacity when used in a Unified CCE deployment. For information about
sizing and choosing a gateway, see the gateway information in the latest version of the Cisco Unified
Communications SRND.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
311
Sizing Cisco Unified Communications Manager Servers
Cluster Sizing Concepts
After you complete these tasks, you can begin to accurately size the necessary Unified Communications
Manager clusters. Many factors impact the sizing of a Unified Communications Manager cluster, and the
following list mentions some of those factors:
• Number of office phones and the busy hour call attempt (BHCA) rate per phone
• Number of inbound agent phones and the BHCA rate per phone
• Number of CTI ports and the BHCA rate on those VoIP endpoints (can be zero if Unified CVP is used
for call treatment, self service, and queuing)
• Number of Voice Gateway ports and the BHCA rate on those VoIP endpoints
• Type of outbound dialer (SCCP or SIP Dialer)
• Number of outbound agent phones, outbound dialing mode, and BHCA rate per phone
• Number of outbound dialer ports, number of IVR ports for outbound campaigns, and the BHCA rate
per port for both
• Number of mobile agents and the BHCA rate per mobile agent
• Number of voicemail ports and the BHCA rate to those VoIP endpoints
• Signaling protocols used by the VoIP endpoints
• Percent of agent call transfers and conferences
• Dial plan size and complexity, including the number of dialed numbers, lines, partitions, calling search
spaces, locations, regions, route patterns, translations, route groups, hunt groups, pickup groups, route
lists, and so forth
• Amount of media resources needed for functions such as transcoding, conferences, encryption, and so
forth
• Co-resident applications and services such as CTI Manager, E-911, and Music on Hold
• Unified Communications Manager release (sizing will vary per release)
• Desired hardware server model (sizing will vary per hardware server model)
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
312
Sizing Cisco Unified Communications Manager Servers
Cisco Unified Collaboration Sizing Tool
Other factors can affect cluster sizing, but the above list shows the most significant factors in terms of resource
consumption.
The general process to sizing a Unified Communications Manager cluster is to estimate the resource
consumption (CPU, memory, and I/O) for each of these factors and then to choose hardware that will satisfy
the resource requirements. It is important to gather information with regard to the factors listed above before
attempting to size a cluster with any accuracy.
The next section describes the tools for sizing Cisco Unified Communications Manager deployments.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
313
Sizing Cisco Unified Communications Manager Servers
Cluster Guidelines and Considerations
When sizing the Unified CM Cluster to support Contact Center solutions for the appropriate number of CTI
resources, remember to also account for additional configured phones from non-logged in agents, additional
applications like Call Recording, Attendant Console, PC-clients which remotely control the device, and other
3rd-Party applications which consume additional CTI resources. Multiple lines on the same device prior to
Unified CM 7.1(3) also require additional CTI resources.
Unified CM 7.1(3) (or later) has been enhanced to support more CTI resources. Consider upgrading when
multiple lines and/or multiple applications (e.g. Contact Center and Recording) is used concurrently. Those
CTI resources follow the same CTI rules as described in theCisco Unified Communications Solution Reference
Network Design (SRND) Guide at http://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_
support_series_home.html. All deployment must be sized by using the Cisco Unified Communications Sizing
Tool.
• Devices (including phones, music on hold, route points, gateway ports, CTI ports, JTAPI Users, and
CTI Manager) must never reside or be registered on the publisher. Any administrative work on Unified
CM will impact call processing and CTI Manager activities if there are any devices registered with the
publisher.
• Do not use a publisher as a fail-over or backup call processing server unless you have fewer than 150
agent phones and the installation is not mission critical or is not a production environment. The Cisco
MCS-7825 server is the minimum server supported for Unified CCE deployments. (Refer to Table 18:
Capacity When Deploying Only One Unified CM Subscriber Server, on page 316 for more details.) Any
deviations will require review by Cisco Bid Assurance on a case-by-case basis.
• Any deployment with more than 150 agent phones requires a minimum of two subscriber servers and a
combined TFTP and publisher. The load-balancing option is not available when the publisher is a backup
call processing subscriber.
• If you require more than one primary subscriber to support your configuration, then distribute all agents
equally among the subscriber nodes. This configuration assumes that the BHCA rate is uniform across
all agents.
• Similarly, distribute all gateway ports and Unified IP IVR CTI ports equally among the cluster nodes.
• If you require more than one Unified CCE JTAPI user (CTI Manager) and more than one primary Unified
CM subscriber, then group and configure all devices monitored by the same Unified CCE JTAPI User
(third-party application provider), such as Unified CCE route points and agent devices, on the same
server if possible.
• Enable CTI Manager only on call processing subscribers, thus allowing for a maximum of eight CTI
Managers in a cluster. To provide maximum resilience, performance, and redundancy, load-balance CTI
applications across the various CTI Managers in the cluster. For additional CTI Manager best practices,
see the Cisco Unified Communications Solution Reference Network Design (SRND) Guide at http://
www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html.
• If you have a mixed cluster with Unified CCE and general office IP phones, group and configure each
type on a separate server if possible (unless you need only one subscriber server). For example, all
Unified CCE agents and their associated devices and resources (gateway ports, CTI ports, and so forth)
are on one or more Unified CM servers, and all general office IP phones and their associated devices
(such as gateway ports) are on other Unified CM servers, as long as cluster capacity allows. If you use
the Cisco Unified CM Capacity Tool, you have to run it multiple times with the specific device
configuration for each primary Unified CM Server Because the tool assumes all devices are equally
balanced in a cluster. In this case, use the 1:1 redundancy scheme.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
314
Sizing Cisco Unified Communications Manager Servers
Unified CM Servers
• (See Unified Communications Manager redundancy for details.) If you use the Unified Communications
Sizing Tool instead, you do not have to run it multiple times because this tool supports deployments
with dedicated Unified CM servers for agent phones or with a mixed cluster.
• Use hardware-based conference resources whenever possible. Hardware conference resources provide
a more cost-effective solution and allow better scalability within a Unified CM cluster.
• Configure all CTI route points associated with the Unified CCE Peripheral Gateway (PG) JTAPI user
to register with the subscriber node running the CTI Manager instance that is communicating with that
Unified CCE PG.
• The Cisco Unified CM Capacity Tool and the Unified Communications Sizing Tool do not currently
measure CTI Manager impact on each server separately. However, CTI Manager does place an additional
burden on the subscriber node running that process. The Cisco Unified CM Capacity Tool and the Unified
Communications Sizing Tool report the resource consumption based on these nodes. The actual resource
consumption on the other Cisco Unified CM nodes might be slightly lower.
• Count devices that are associated with a Unified CCE PG JTAPI user, but are not used by a call center
agent, as an agent device, because the PG will still be notified of all device state changes for that phone
even though it is not being used by an agent. If a device is unlikely to be used regularly by a call center
agent, do not associate the device with the Unified CCE PG JTAPI user to increase cluster scalability.
• For deployments requiring large numbers of IVR ports, use Unified CVP instead of IP IVR. IP IVR
ports place a significant call processing burden on Unified CM, while Unified CVP does not. Thus,
Unified CCE deployments with Unified CVP will allow more agents and higher BHCA rates per cluster.
Size all deployments by using the Unified Communications Sizing Tool.
• In deployments with multiple IP IVRs, associate those servers with different CTI Managers on different
subscriber nodes to better balance call processing across the cluster.
• Unified CM CPU resource consumption varies, depending on the trace level enabled. Changing the trace
level from Default to Full on Unified CM can increase CPU consumption significantly under high loads.
Changing the tracing level from Default to No tracing can decrease CPU consumption significantly at
high loads, but this configuration is not supported by Cisco Technical Assistance Center.
• Under normal circumstances, place all servers from the Unified CM cluster within the same LAN or
MAN. Do not place all members of a cluster on the same VLAN or switch.
• If the cluster spans an IP WAN, you must follow the specific guidelines for clustering over the IP WAN
as described in both IPT: Clustering Over the WAN in this guide and the section on Clustering over the
IP WAN in the Cisco Unified Communications Solution Reference Network Design (SRND) Guide at
http://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html.
For the most current information about Unified CM and Unified CCE supported releases, see the latest version
of the Cisco Unified Communications Manager Compatibility Matrix.
Unified CM Servers
Unified CM clusters utilize various types of servers, depending on the scale, performance, and redundancy
required. They range from non-redundant, single-processor servers to highly redundant, multiprocessor servers.
Unified CM is supported only on specific hardware platforms. For a list of the currently supported hardware
configurations, see the documentation on Cisco MCS 7800 Series Unified CM appliances.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
315
Sizing Cisco Unified Communications Manager Servers
Unified Communications Manager redundancy
To size a Unified CM deployment, you must use the Cisco Unified CM Capacity Tool or the Unified
Communications Sizing Tool, both of which indicate the number of Unified CM servers needed for each type
of platform.
Avoid deploying only one Unified CM subscriber for mission-critical contact center deployments and for
deployments with more than 150 agents. The table below lists the maximum number of agents in a system
where only one Unified CM subscriber server is deployed, with the Unified CM publisher used as backup.
Table 18: Capacity When Deploying Only One Unified CM Subscriber Server
The Cisco MCS-7815 and MCS-7816 servers are not supported with Unified CCE deployments, but lab or
demo setups can use these servers. They are, however, a supported Unified CM platform for Cisco Unified
Communications deployments only.
Due to the higher phone usage in contact centers and the increased downtime required during upgrades, do
not use the 2:1 redundancy scheme for Unified Communications Manager deployments with Unified CCE.
The following figure illustrates these options. This illustration shows only call processing subscribers and
does not show publisher, TFTP, music on hold (MoH), or other servers. For details on additional cluster
deployment and redundancy options, see the latest version of the Cisco Unified Communications Solution
Reference Network Design (SRND) Guide at http://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_
products_support_series_home.html.
In the following figure, the options shown all provide 1:1 subscriber redundancy. Option 1 is used for clusters
supporting fewer than 150 Unified CCE agents on any supported version of Unified CM. Options 2 through
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
316
Sizing Cisco Unified Communications Manager Servers
Load Balancing for Unified CM
5 illustrate increasingly larger clusters. In this figure, for deployments with Unified Communications Manager
8.x and Unified CVP (not IP IVR), N is equal to 1000. For deployments with IP IVR, N is equal to 500. For
other types of deployments, use the Cisco Unified Communications Manager Capacity Tool or the Unified
Communications Sizing Tool. In all types of deployments, the exact number of servers depends on the hardware
platforms chosen or required, as determined by the Cisco Unified Communications Manager Capacity Tool
or the Unified Communications Sizing Tool.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
317
Sizing Cisco Unified Communications Manager Servers
Deployment of Agent PG in a Unified CM Cluster
Figure 131: Deploy Agent PG for Each Pair of Unified CM Subscriber Nodes
• Another possible method is to deploy a single Agent PG for the entire Cisco Unified CM cluster. This
type of deployment requires a single pair of Cisco Unified CM subscriber nodes running CTI Manager.
Spread agent phone registration among all the Cisco Unified CM subscriber nodes, including the Unified
CM subscribers running the CTI Manager service. The following diagram shows an example where four
primary Unified CM subscribers are required and four backup Unified CM subscribers are deployed to
provide 1:1 redundancy.
One benefit of this model is the reduction of the server count for the PG. Another benefit is that there
is a single PIM for the entire Unified CM cluster. This makes it possible to create teams that span across
many Unified CM subscribers, thus allowing supervisors, for example, to monitor agent phones registered
to any Unified CM subscriber node in the Unified CM cluster. However, the resource utilization on the
Unified CM cluster might be slightly higher in this type of deployment. Use the Cisco Unified CM
Capacity Tool or the Unified Communications Sizing Tool to size the Unified CM servers for a particular
deployment.
A variation of this type of deployment is available with Unified CM 8.0 or later releases, when Unified
CVP only is deployed. (This model is not supported when IP IVR is deployed.) Up to 4000 agents can
be supported in a single Unified CM cluster in this case. When deploying more than 2000 agents, a
minimum of two CTI Manager pairs are required. One Agent PG with two PIMs can be deployed, with
each PIM configured with a separate pair of Unified CM subscribers running the CTI Manager service
and each PIM configured with up to 2000 agents. Spread agent phone registration among all the Cisco
Unified CM subscriber nodes, including the Unified CM subscribers running the CTI Manager service.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
318
Sizing Cisco Unified Communications Manager Servers
Upgrading Unified CM
The following diagram shows an example where four primary Unified CM subscribers are required, and
four backup Unified CM subscribers are deployed to provide 1:1 redundancy.
Upgrading Unified CM
The 1:1 redundancy scheme allows upgrades with only the fail-over periods impacting the cluster. The 1:1
redundancy scheme enables you to upgrade the cluster using the following method:
1 Upgrade the publisher server.
2 Upgrade dedicated TFTP and music-on-hold (MoH) servers.
3 Upgrade the backup subscribers one at a time. This step will affect some users if 50/50 load balancing is
implemented.
4 Fail-over the primary subscribers to their backups, and stop the Cisco Unified CM Service on the primaries.
All users are on primaries and are moved to backup subscribers when the Cisco Unified CM 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.
5 Upgrade the primaries, and then re-enable the Cisco Unified CM Service.
With this upgrade method, there is no period (except for the fail-over period) when devices are registered to
subscriber servers that are running different versions of the Unified CM 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.
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 preferred scheme for Unified CCE deployments, although it is supported if it
is a customer requirement and, if possible, outage of call processing is not a concern to the customer.
The 2:1 redundancy scheme enables you to upgrade the cluster using the following method. If the Cisco
Unified CM Service does not run on the publisher database server, upgrade the servers in the following order:
1 Upgrade the publisher database server.
2 Upgrade the Cisco TFTP server if it exists separately from the publisher database server.
3 Upgrade servers that have services related only to Unified CM (music on hold, Cisco IP Media Streaming
Application, and so forth) running on them. Make sure that you upgrade only one Server at a time. Make
sure that the Cisco Unified CM Service does not run on these servers.
4 Upgrade each backup server, one Server at a time.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
319
Sizing Cisco Unified Communications Manager Servers
Cisco Unified Mobile Agent
Note Do not oversubscribe the backup server or servers during the upgrade. The number of agent phones
registered to the backup server during the upgrade must not exceed the maximum capacity indicated by
the Cisco Unified CM Capacity Tool or the Unified Communications Sizing Tool. Perform the upgrade
during off-peak hours when the call volume is low.
5 Upgrade each primary server that has the Cisco Unified CM Service running on it. Remember to upgrade
one Server at a time. During the upgrade of the second primary subscriber, there is some outage for users
and agents subscribed on that server, until the server is upgraded. Similarly, when you upgrade the fourth
primary subscriber, there is some outage for users and agents subscribed on that server, until the server is
upgraded.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
320
CHAPTER 12
Bandwidth Provisioning and QoS Considerations
This chapter presents an overview of the Unified CCE network architecture, deployment characteristics of
the network, and provisioning requirements of the Unified CCE network. Essential network architecture
concepts are introduced, including network segments, keep-alive (heartbeat) traffic, flow categorization,
IP-based prioritization and segmentation, and bandwidth and latency requirements. Provisioning guidelines
are presented for network traffic flows between remote components over the WAN, including information
on how to apply proper Quality of Service (QoS) to WAN traffic flows.
Cisco Unified CCE has traditionally been deployed using private, point-to-point leased-line network
connections for both its private (Central Controller or Peripheral Gateway, side-to-side) as well as public
(Peripheral Gateway to Central Controller) WAN network structure. Optimal network performance
characteristics (and route diversity for the fault-tolerant fail-over mechanisms) are provided to the Unified
CCE application only through dedicated private facilities, redundant IP routers, and appropriate priority
queuing.
Enterprises deploying networks that share multiple traffic classes, of course, prefer to maintain their existing
infrastructure rather than revert to an incremental, dedicated network. Convergent networks offer both cost
and operational efficiency, and such support is a key aspect of Cisco Powered Networks.
Provided that the required latency and bandwidth requirements inherent in the real-time nature of this product
are satisfied, Cisco supports Unified CCE deployments in a convergent QoS-aware public network as well
as in a convergent QoS-aware private network environment. This chapter presents QoS marking, queuing,
and shaping information for both the Unified CCE public and private network traffic.
Historically, two QoS models have been used: Integrated Services (IntServ) and Differentiated Services
(DiffServ). The IntServ model relies on the Resource Reservation Protocol (RSVP) to signal and reserve the
desired QoS for each flow in the network. Scalability becomes an issue with IntServ because state information
of thousands of reservations has to be maintained at every router along the path. DiffServ, in contrast,
categorizes traffic into different classes, and specific forwarding treatments are then applied to the traffic
class at each network node. As a coarse-grained, scalable, and end-to-end QoS solution, DiffServ is more
widely used and accepted. Unified CCE applications are not aware of RSVP, and the QoS considerations in
this chapter are based on DiffServ.
Adequate bandwidth provisioning and implementation of QoS are critical components in the success of
Unified CCE deployments. Bandwidth guidelines and examples are provided in this chapter to help with
provisioning the required bandwidth.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
321
Bandwidth Provisioning and QoS Considerations
Unified CCE Network Architecture Overview
This topic focuses primarily on the types of data flows and bandwidth used between the following:
• A remote Peripheral Gateway (PG) and the Unified CCE Central Controller (CC)
• Sides A and B of a PG or a CC
• The desktop application and the Finesse, CTI OS, or Cisco Agent Desktop servers
Guidelines and examples are presented to help estimate required bandwidth and to help implement a
prioritization scheme for these WAN segments.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
322
Bandwidth Provisioning and QoS Considerations
Network Segments
The flows discussed in this chapter encapsulate call control and data traffic. Because media (voice and video)
streams are maintained primarily between Cisco Unified Communications Manager and its endpoints, voice
and video provisioning are not addressed here.
For bandwidth estimates for the voice RTP stream generated by the calls to Unified CCE agents and the
associated call control traffic generated by the various protocols, see the Cisco Collaboration System Solution
Reference Network Designs at http://www.cisco.com/c/en/us/support/unified-communications/
unified-communications-manager-callmanager/tsd-products-support-series-home.html.
Data traffic and other mission-critical traffic varies according to the specific integration and deployment model
used. For information about proper network design for data traffic, see the Network Infrastructure and Quality
of Service (QoS) documentation at http://www.cisco.com/en/US/netsol/ns742/networking_solutions_program_
category_home.html .
Network Segments
The fault-tolerant architecture employed by Unified CCE requires two independent communication networks.
The private network (using a separate 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 each side of the synchronized system and foreign systems. The public
network is also used as an alternate network by the fault-tolerance software to distinguish between node
failures and network failures.
Note The terms public network and visible network are used interchangeably throughout this document.
A third network, the signaling access network, may be deployed in Unified CCE systems that also interface
directly with the carrier network (PSTN) and that deploy the Unified CCE architecture. The signaling access
network is not addressed in this chapter.
Note Cisco Unified CCH is deprecated. Use Cisco HCS for Contact Center instead.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
323
Bandwidth Provisioning and QoS Considerations
Network Segments
The figure below illustrates the fundamental network segments for a Unified CCE system with a duplexed
PG and a duplexed Central Controller (with Sides A and B geographically separated).
Figure 134: Example of Public and Private Network Segments for a Unified CCE System
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
324
Bandwidth Provisioning and QoS Considerations
IP-Based Prioritization and QoS
Controller) route diversity throughout the network. Avoid routes that result in common path selection
(and, thus, a common point of failure) for the multiple PG-to-CC sessions.
Note Layer-2 802.1p marking is also possible if Microsoft Windows Packet Scheduler is enabled (for PG/Central
Controller traffic only). However, this is not supported. Microsoft Windows Packet Scheduler is not well
supported or suited to Unified CCE, and support is removed in future versions. 802.1p markings are not
widely used, nor are they required when DSCP markings are available.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
325
Bandwidth Provisioning and QoS Considerations
HSRP-Enabled Network
point, a TCP Reset message is typically generated from the closing side. Various factors can cause loss of
heartbeats, such as:
• The network failed.
• The process sending the heartbeats failed.
• The VM with the sending process is shut down.
• The UDP packets are not properly prioritized.
There are several parameters associated with heartbeats. In general, leave these parameters set to their system
default values. Some of these values are specified when a connection is established, while others can be
specified by setting values in the Microsoft Windows 2008 registry. 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 between redundant components is 100 milliseconds. One side can
detect the failure of the circuit or the other side within 500 ms. The default heartbeat interval between a central
site and a peripheral gateway is 400 ms. In this case, it takes 2 seconds to reach the circuit failure threshold.
As part of the Unified CCE QoS implementation, a TCP keep-alive message in the public network connecting
a Central Controller to a Peripheral Gateway replaces the UDP heartbeat. A consistent heartbeat or keep-alive
mechanism is enforced on public network interface whereas keep-alive mechanism is enforced on private
network interface. When QoS is enabled on the network interface, a TCP keep-alive message is sent; otherwise
UDP heartbeats are retained.
The TCP keep-alive feature, provided in the TCP stack, detects inactivity and then causes the server or client
side to terminate. The TCP keep-alive feature sends probe packets (namely, keep-alive packets) across a
connection after the connection has been idle for a certain period. The connection is considered down if a
keep-alive response from the other side is not heard. Microsoft Windows 2012 allow you to specify keep-alive
parameters on a per-connection basis. For Unified CCE public connections, the keep-alive timeout is set to 5
* 400 ms, matching the failure detection time of 2 seconds with the UDP heartbeat.
The reasons for moving to TCP keep-alive with QoS enabled are as follows:
• In a converged network, algorithms used by routers to handle network congestion conditions can have
different effects on TCP and UDP. As a result, delays and congestion experienced by UDP heartbeat
traffic can result in connection failures from timeouts.
• The use of UDP heartbeats creates deployment complexities in a firewall environment. With the dynamic
port allocation for heartbeat communications, you open a large range of port numbers which weakens
the security of your firewall.
HSRP-Enabled Network
In a network where Hot Standby Router Protocol (HSRP) is deployed on the default gateways that are
configured on the Unified CCE servers, follow these requirements:
• Set the HSRP hold time and its associated processing delay lower than five times the heartbeat interval
(100 ms on the private network and 400 ms on the public network). This level avoids Unified CCE
private network communication outage during HSRP active router switch-over.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
326
Bandwidth Provisioning and QoS Considerations
RSVP
Note With convergence delays that exceed private or public network outage notification,
HSRP fail-over times can exceed the threshold for network outage detection which
results in a fail-over. If the HSRP configuration has primary and secondary designations
and the primary path router fails over, HSRP reinstates the primary path when possible.
That reinstatement can lead to a second private network outage detection.
For this reason, do not use primary and secondary designations with HSRP convergence delays that
approach 500 ms for the private network and 2 seconds for the public network. On the other hand,
convergence delays below the detected threshold (which result in HSRP fail-overs that are transparent
to the application) do not mandate a preferred path configuration. This approach is preferable. Keep
enabled routers symmetrical if path values and costs are identical. However, if available bandwidth and
cost favor one path (and the path transition is transparent), then designation of a primary path and router
is advised.
• The Unified CCE fault-tolerant design requires the private network to be physically separate from the
public network. Therefore, do not configure HSRP to fail-over one type of network traffic to the other
network link.
• The bandwidth requirement for Unified CCE must be guaranteed at all times with HSRP, otherwise the
system behavior is unpredictable. For example, if HSRP is initially configured for load sharing, ensure
that sufficient bandwidth for Unified CCE remains on the surviving links in the worst-case failure
situations.
RSVP
Cisco Unified Communications Manager provides support for Resource Reservation Protocol (RSVP) between
endpoints within a cluster. As a protocol for call admission control, RSVP is used by the routers in the network
to reserve bandwidth for calls.
RSVP traces the path between two RSVP agents that reside on the same LAN as the phones. The RSVP agent
is a software media termination point (MTP) that runs on Cisco IOS routers. The RSVP agents are controlled
by Unified CM and are inserted into the media stream between the two phones when a call is made. The RSVP
agent of the originating phone will traverse the network to the RSVP agent of the destination phone, and
reserve bandwidth. Since the network routers keep track of bandwidth usage instead of Unified CM, multiple
phone calls can traverse the same RSVP controlled link even if the calls are controlled by multiple Unified
CMs.
The figure below shows a scenario in which two different Unified CM clusters provide service to phones at
the same remote site. This may occur if a Unified CM cluster is assigned to handle an IP call center. In the
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
327
Bandwidth Provisioning and QoS Considerations
Traffic Flow
scenario, two users at the same office are serviced by different clusters. RSVP offloads the bandwidth calculation
responsibilities of Unified CM to the network routers.
For more information about Unified CM RSVP, see the Cisco Unified Communications SRND.
Traffic Flow
This section briefly describes the traffic flows for the public and private networks.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
328
Bandwidth Provisioning and QoS Considerations
Bandwidth and Latency Requirements
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
329
Bandwidth Provisioning and QoS Considerations
Quality of Service
cannot be guaranteed unless the stringent bandwidth, latency, and prioritization requirements of the product
are met.
In general, Agent Greeting feature requires shorter latency cross system. For example, the PG-to-CC path has
a maximum one-way latency of 50 ms to support Agent Greeting feature as designed.
Quality of Service
This section covers the planning and configuration issues to consider when moving to a Unified CCE QoS
solution.
Note While Cisco allows Microsoft Packet Scheduler with Unified CCE 8.5, it is not supported and future
releases will remove this option.
There are several disadvantages to marking traffic in Unified CCE. First, it is hard to make changes. For
instance, to change the marking values for the public network traffic, you have to make changes on all the
PGs. For a system with more than 30 PGs, for example, all those changes would require quite a lot of work.
Second, QoS trust has to be enabled on access-layer routers and switches, which could open the network to
malicious packets with inflated marking levels.
Note In Windows 2008, you can use the Group Policy Editor to apply a QoS policy to apply DSCP Level 3
markings to packets. You can also administer these policies through the Active Directory Domain Controller.
This may simplify the administration issue. For more information, see appropriate Microsoft documentation.
In contrast, marking traffic at the network edge allows for centralized and secured marking policy management,
and there is no need to enable trust on access-layer devices. A little overhead is needed to define access lists
to recognize Unified CCE packets. For access-list definition criteria on edge routers or switches, see Table
19: Public Network Traffic Markings (Default) and Latency Requirements, on page 331, Table 20: Router
Private Network Traffic Markings (Default) and Latency Requirements, on page 332, and Table 21: PG Private
Network Traffic Markings (Default) and Latency Requirements, on page 332. Do not use port numbers in the
access lists for recognizing Unified CCE traffic (although they are provided in the tables for reference purposes)
because port numbers make the access lists extremely complex and you would have to modify the access lists
every time a new customer instance is added to the system.
Note A typical Unified CCE deployment has three IP addresses configured on each NIC, and the Unified CCE
application uses two of them. For remote monitoring using PCAnywhere or VNC, because the port numbers
are not used in the access lists, use the third IP address to prevent the remote monitoring traffic from being
marked as the real Unified CCE traffic.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
330
Bandwidth Provisioning and QoS Considerations
How to Mark Traffic
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, reserve both AF31 and CS3 for call signaling.
Table 19: Public Network Traffic Markings (Default) and Latency Requirements
UDP port: 39500 to 39999 for UDP heartbeats if QoS is not enabled
on Unified CCE
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
331
Bandwidth Provisioning and QoS Considerations
How to Mark Traffic
Table 20: Router Private Network Traffic Markings (Default) and Latency Requirements
Table 21: PG Private Network Traffic Markings (Default) and Latency Requirements
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
332
Bandwidth Provisioning and QoS Considerations
QoS Configuration
QoS Configuration
This section presents some QoS configuration examples for the various devices in a Unified CCE system.
Note The marking value, bandwidth data, and queuing policy in the examples below are provided for
demonstration purpose only. Do not copy and paste the examples without making corresponding changes
in the real working system.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
333
Bandwidth Provisioning and QoS Considerations
QoS Configuration on Cisco IOS Devices
mls qos
interface mod/port
mls qos trust dscp
policy-map ICM_Public_Queuing
class ICM_Public_High
priority 500
class ICM_Public_Low
bandwidth 250
You can also use the commands priority percent and bandwidth percent to assign bandwidth on a percentage
basis. Assign 90% of the link bandwidth to the priority queue.
If it is a shared link, then use the sizing tools introduced in the section on Bandwidth Provisioning, to calculate
the bandwidth requirement at each priority level and add it to the allocation for non-CCE traffic in the same
queue. For example, if the link is shared with Unified CM ICCS traffic and RTP traffic and they respectively
require 600 kbps and 400 kbps, and if the link also carries the private traffic in case of fail-over and the
high-priority and low-priority private Unified CCE traffic respectively require 200 kbps and 100 kbps, the
configuration is:
policy-map Converged_Link_Queuing
class RTP
priority 400
class ICCS
bandwidth 600
class ICM_Public_High
bandwidth 500
class ICM_Public_Low
bandwidth 250
class ICM_Private_High
bandwidth 200
class ICM_Private_Low
bandwidth 100
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
334
Bandwidth Provisioning and QoS Considerations
QoS Performance Monitoring
You can also use the commands priority percent and bandwidth percent to assign bandwidth on a percentage
basis. If the link is dedicated to Unified CCE traffic only, assign 90% of the link bandwidth to the priority
queue. If it is a shared link, use the sizing tools to calculate the bandwidth requirement at each priority level
and add it to the allocation for non-CCE traffic in the same queue.
Finally, the queuing policy is applied to the outgoing interface:
interface mod/port
service-policy output ICM_Public_Queuing
policy-map ICM_Public_Marking
class ICM_Public_High
set ip dscp af31
class ICM_Public_Low
set ip dscp af11
Finally, apply the marking policy to the incoming interface:
interface mod/port
service-policy input ICM_Public_Marking
Bandwidth Provisioning
This section discusses bandwidth provisioning considerations for the Unified CCE system.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
335
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Unified CCE Public and Private Networks
At this time, no tool exists that specifically addresses communications between the Unified CCE Central
Controller and the Cisco Unified Customer Voice Portal (Unified CVP) PG. Testing has shown, however,
that the tool for calculating bandwidth needed between the Unified CCE Central Controller and the Unified
IP IVR PG will also produce accurate measurements for Unified CVP if you perform the following substitution
in one field:
For the field labeled Average number of RUN VRU script nodes, substitute the number of Unified CCE
script nodes that interact with Unified CVP.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
336
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Unified CCE Public and Private Networks
If one dedicated link is used between sites for private communications, add all link sizes together and use the
Total Link Size at the bottom of the table above. If separate links are used, one for Router/Logger Private and
one for PG Private, use the first row for Router/Logger requirements and the bottom three (out of four) rows
added together for PG Private requirements.
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, including conferences and transfers. For example,
10,000 BHCA ingress with 10% conferences or transfers are 11,000 effective BHCA.
Unified CM PG
This value includes all calls that come through Unified CCE Route Points controlled by Unified CM
and/or that are ultimately transferred to agents. This assumes that each call comes into a route point
and is eventually sent to an agent. For example, 10,000 BHCA ingress calls coming into a route point
and being transferred to agents, with 10% conferences or transfers, are 11,000 effective BHCA.
Unified IP IVR PG
This value is the total BHCA for call treatment and queuing. For example, 10,000 BHCA ingress calls,
with all of them receiving treatment and 40% being queued, are 14,000 effective BHCA.
Unified CVP PG
This value is the total BHCA for call treatment and queuing coming through a Unified CVP. 100%
treatment is assumed in the calculation. For example, 10,000 BHCA ingress calls, with all of them
receiving treatment and 40% being queued, are 14,000 effective BHCA.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
337
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Unified CCE Public and Private Networks
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
338
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Unified CCE Clustering Over the WAN
For the combined dedicated link in this example, the results are as follows:
• Total Link Size = 2,550,000 bps
• Router/Logger high-priority bandwidth queue of 264,000 bps
• PG high-priority queue bandwidth of 1,998,000 bps
If this example were implemented with two separate links, Router/Logger private and PG private, the link
sizes and queues are as follows:
• Router/Logger link of 330,000 bps (actual minimum link is 1.5 Mb, as defined earlier), with high-priority
bandwidth queue of 264,000 bps
• PG link of 2,220,000 bps, with high-priority bandwidth queue of 1,998,000 bps
When using Multilink Point-to-Point Protocol (MLPPP) for private networks, set the following attributes for
the MLPPP link:
• Use per-destination load balancing instead of per-packet load balancing.
Note You must have two separate multilinks with one link each for per-destination load
balancing.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
339
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Unified CCE Clustering Over the WAN
Example: With 10,000 BHCA and 20 ECC variables with average length of 40 bits:
10,000 * (20 + ((20 * 40) / 40) = 10,000 * 40 = 400,000 bps = 400 kbps
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
340
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Gateway PG to System PG
These bandwidth requirements assume proper design and deployment based on the recommendations contained
throughout this document. Inefficient design (for example, if ingress calls to Site 1 are treated in Site 2) will
cause additional intra-cluster communications, possibly exceeding the defined bandwidth requirements.
Note Do not deploy the gateway PG remote from the system PG that it is monitoring.
The following factors affect the amount of data coming over the link once it is initialized:
• Message sizes can vary depending on their content (such as the size of extensions, agent IDs, and call
data). A Route Request with no data, for example, can be a very small message. If all call variables and
ECC variables are populated with large values, this will drastically affect the size of the message.
• Call scenarios can cause great variation in the number of messages per call that are transmitted over the
line. A simple call scenario might cause 21 messages to be transmitted over the line. More complex call
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
341
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Finesse Client to Finesse Server
scenarios involving queuing, hold retrieves, conferences, or transfers will add greatly to the number of
messages per call that are transmitted over the line.
• The more skill groups to which an agent belongs, the more messages are transmitted over the line. In a
simple call scenario, each additional skill group adds two messages per call. These messages are
approximately 110 bytes each, depending on field sizes.
Note Call variables used on the child PG are transmitted to the parent PG regardless of their use or the setting
of the MAPVAR parameter. For example, if call variables 1 through 8 are used on the child PG but are
never referenced on the parent PG (and assume MAPVAR = EEEEEEEEEE, meaning Export all but
Import nothing), they will still be transmitted to the PG where the filtering takes place, therefore bandwidth
is still required. For the reverse situation, bandwidth is spared. For example, if the map setting is MAPVAR
= IIIIIIIIII (Import all but Export nothing), then bandwidth is spared. Call variable data will not be
transmitted to the child PG on a ROUTE_SELECT response.
Note A more complex call flow or a call flow involving call data could easily increase this bandwidth requirement.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
342
Bandwidth Provisioning and QoS Considerations
Auto Configuration
Note that during failover, agents are redirected to the alternate Finesse server and required to log in again.
For example, if you configure your bandwidth so that login takes 5 minutes and a client failover event occurs,
agents will take 5 minutes to successfully log in to the alternate Finesse server.
After login is complete, the most intensive operation for both an agent and a supervisor is making an outbound
call to a route point. For the supervisor, updates to the Team Performance and Queue Statistics gadgets may
be occurring concurrently. You can use the Cisco Finesse bandwidth calculator to calculate the total bandwidth
required for connections between all Finesse clients and the Finesse server.
Note The Cisco Finesse bandwidth calculator does not include the bandwidth required for any third-party
gadgets in the Finesse container or any other applications running on the agent desktop client.
Other applications at the remote client location may compete for total bandwidth to that remote client.
The bandwidth listed in the bandwidth calculator must be available for Finesse after you account for the
bandwidth used by other applications, including voice traffic that may share this bandwidth. The performance
of the Finesse interface, and potentially the quality of voice sharing this bandwidth, may degrade if sufficient
bandwidth is not continuously available.
Auto Configuration
If auto configuration is used, the child PG might send the entire agent, skill group, and route-point configuration
to the parent PG. If not much bandwidth is available, it could take considerable time for this data to be sent.
This table lists the approximate number of bytes (worst case) that are sent for each of the data entities. If you
know the size of the configuration on a child PG, you can calculate the total number of bytes of configuration
data that is sent. The values in the table are worse-case estimates that assume sending only one item per record,
with each field having the maximum size (which is unlikely).
Table 24: Bytes Sent Per Data Item Under Worst-Case Conditions
For example, if the child PG has 100 agents, 10 call types, 5 skill groups, and 20 route points, then you can
estimate the amount of configuration data sent as follows:
100 agents * 500 bytes = 50,000 bytes
10 call types * 250 bytes = 2500 bytes
5 skill groups * 625 bytes = 3125 bytes
20 route points * 315 bytes = 6300 bytes
50,000 + 2500 + 3125 + 6300 = 61,925 bytes
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
343
Bandwidth Provisioning and QoS Considerations
Options for Gateway PG and Unified CCE
The total amount of data (approximate maximum) sent for this configuration is 61,925 bytes.
Note Eliminating Import (I or B setting) of data does not save any bandwidth because, even though the Gateway
PG does not import the data, the child Unified CCE system still transmits it.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
344
Bandwidth Provisioning and QoS Considerations
Distributed SIP Dialer Deployment
Adequate bandwidth provisioning is an important component in the success of the Outbound Option
deployments.
Figure 137: Distributed Outbound SIP Dialer Deployment for an Agent-Based Campaign
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
345
Bandwidth Provisioning and QoS Considerations
Distributed SIP Dialer Deployment
Example 1
With call throttling of 60 cps on the SIP Dialer, a 20% hit rate for the agent-based campaign, and a WAN link
with g.711 codec and average call duration of 40 seconds, the bandwidth usage is:
60 * (20% * (80 * 40 + 100) + (1 – 20%)*49.6) = 41980.8 kbps = 41.98 Mbps
Example 2
With call throttling of 60 cps on the SIP Dialer, a 20% hit rate for the agent-based campaign, and a WAN link
with g.729 codec and average call duration of 40 seconds, the bandwidth usage is:
60 * (20% * (26 * 40 + 100) + (1 – 20%)*49.6) = 16060.8 kbps = 16.06 Mbps
Example 3
With call throttling of 60 cps on the SIP Dialer, a 20% hit rate for the agent campaign, and a WAN link with
average g.711 codec and average call duration of 40 seconds, the bandwidth usage is:
60 * (80 * 40 + 20% *100 + (1 – 20%)*49.6) = 199180.8 kbps = 199.18 Mbps
Example 4
With call throttling of 60 cps on the SIP Dialer, a 20% hit rate for the agent campaign, and a WAN link with
average g.729 codec and average call duration of 40 seconds, the bandwidth usage is:
60 * (26 * 40 + 20% *100 + (1 – 20%)*49.6) = 67660.8 kbps = 67.66 Mbps
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
346
Bandwidth Provisioning and QoS Considerations
Distributed SIP Dialer Deployment
Figure 138: Distributed Outbound SIP Dialer Deployment for Transfer to a VRU Campaign Using Cisco Unified CVP
Figure 139: Distributed Outbound SIP Dialer Deployment for Transfer to a VRU Campaign Using Cisco Unified IP IVR
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
347
Bandwidth Provisioning and QoS Considerations
Distributed SIP Dialer Deployment
Example 5
With call throttling of 60 cps on the SIP Dialer, a 20% hit rate for the transfer-to-IVR campaign, and a WAN
link with g.711 codec, the bandwidth usage is:
60 * 20% * 100 + 60 *(1 – 20%)*49.6= 3600 kbps = 3.6 Mbps
Example 6
With call throttling of 60 cps on the SIP Dialer, a 20% hit rate for the agent campaign, and a WAN link with
g.711 codec and average call duration of 40 seconds, the bandwidth usage is:
60 * (80 * 40 + 20% *100 + (1 – 20%)*49.6) = 199180.8 kbps = 199.18 Mbps
Example 7
With call throttling of 60 cps on the SIP Dialer, a 20% hit rate for the transfer-to-VRU campaign, and a WAN
link with g.729 codec and average call duration of 40 seconds, the bandwidth usage is:
60 * (26 * 40 + 20% *100 + (1 – 20%)*49.6) = 67660.8 kbps = 67.66 Mbps
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
348
Bandwidth Provisioning and QoS Considerations
Distributed SCCP Dialer Deployment
Call control signaling uses H.323 over the WAN between the Voice Gateway and the Unified CM to which
the SCCP dialers are connected. The typical H.323 outbound call flow uses an average of 4,000 bytes per call
that is transferred to an outbound agent. The average hit call signaling bandwidth usage is:
Hit Call Signaling Bandwidth = (4,000 bytes/call) (8 bits/byte) = 32,000 bits per call = 32 Kb per call
The typical H.323 outbound call flow uses about 6,200 bytes per call that is disconnected by the outbound
dialer. Those outbound calls can be the result of a busy ring no-answer, an invalid number, and so forth. The
average non-hit call signaling bandwidth usage is:
Non-Hit Signaling Call Bandwidth = (2,000 bytes/call) (8 bits/byte) = 8,000 bits per call = 8 Kb per call Codec
Bandwidth = 80 Kbps per call for g.711 Codec, or 26 Kbps per call for g.729 Codec
The figure below shows an example of the distributed Outbound SCCP Dialer deployment for an agent-based
campaign.
Figure 140: Distributed Outbound SCCP Dialer Deployment for an Agent-Based Campaign
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
349
Bandwidth Provisioning and QoS Considerations
Distributed SCCP Dialer Deployment
The following figures show examples of the distributed Outbound SCCP Dialer deployment for transfer to
an IVR campaign.
Figure 141: Distributed Outbound SCCP Dialer Deployment for Transfer to an IVR Campaign Using Cisco Unified CVP
Figure 142: Distributed Outbound SCCP Dialer Deployment for Transfer to an IVR Campaign Using Cisco Unified IP IVR
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
350
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements and QoS for Agent and Supervisor Desktops
Example 8
For two SCCP Dialers with call throttling of 5 cps, a 20% hit rate for the agent campaign, and a WAN link
with g.711 codec and average call duration of 40 seconds, the bandwidth usage is:
5*2 * (80 * 40 + 20% *100 + (1 – 20%)*49.6) = 33196.8 kbps = 33.20 Mbps
Example 9
With call throttling of 60 cps on the SCCP Dialer, a 20% hit rate for the transfer-to-IVR campaign, and a
WAN link with g.729 codec and average call duration of 40 seconds, the bandwidth usage is:
5 * 2 * (26 * 40 + 20% *100 + (1 – 20%)*49.6) = 11276.8 kbps = 11.28 Mbps
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
351
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for CTI OS Agent Desktop
• Method used for silently Monitoring and Recording agent calls. The method used dictates the bandwidth
load on a given network link.
• Cisco Unified Mobile Agent deployments that use QoS mechanisms optimize WAN bandwidth utilization.
• Use advanced queuing and scheduling techniques in distribution and core areas as well.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
352
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for CTI OS Agent Desktop
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
353
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Cisco Agent Desktop
If more limited statistics traffic is acceptable for the remote site, a remote supervisor or selected agents can
still log statistics through a different connection profile with statistics enabled.
If Unified Mobile Agents have their skill group statistics turned off, but the supervisor needs to see the agent
skill group statistics, the supervisor could use a different connection profile with statistics turned on. In this
case, the volume of traffic sent to the supervisor is considerably less. For each skill group and agent (or
supervisor), the packet size for a skill-group statistics message is fixed. So an agent in two skill groups would
get two packets, and a supervisor observing five skill groups would get five packets. Assume there are 10
agents at a remote site and one supervisor, all with the same two skill groups configured. In Unified CCE, the
supervisor sees all the statistics for the skill groups to which any agent in the agent team belongs. If only the
supervisor has statistics turned on to observe the two skill groups and agents have statistics turned off, then
this approach reduces skill-group statistics traffic by 90%.
Also, at the main location, if agents want to have their skill-group statistics turned on, they could do so without
impacting the traffic to the remote location if the supervisor uses a different connection profile. Again, in this
case no additional CTI OS servers are required.
In the case where there are multiple remote locations, assuming only supervisors must see the statistics, it is
sufficient to have only one connection profile for all remote supervisors.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
354
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Cisco Agent Desktop
Cisco Supervisor Desktops send Silent Monitoring requests when the supervisor wants to listen to an agent’s
call in real-time or listen to a call that was recorded earlier. The Recording and Playback service send recording
requests when a supervisor or agent wants to record a call. For listening to or recording a live call, the VoIP
provider will capture the voice streams and send them to the requestor. On the supervisor's desktop, these
streams are decoded and played through the supervisor's desktop sound card. For recording, the Recording
and Playback service receives the voice streams and saves them to disk.
A Unified CCE installation may have one or two Recording services.
The Cisco Agent Desktop application contains a module referred to as the Desktop Monitor service, which
runs on the agent’s desktop. It is responsible for processing Silent Monitoring requests only for the agent
logged into the CAD application on the desktop. It captures voice packets sent to the phone or IP Communicator
software phone associated with the logged-in agent. The phone must be a Cisco Unified IP Phone 7910, 7940,
7960, or 7970 connected in series with the agent desktop on the network. These phones are supported because
they contain an additional network port that allows the phone to be connected to a network and also to an
agent’s computer. They also support the ability of hubs and switches to propagate network traffic through this
additional port. This capability is what allows the Desktop Monitor service to see the phone conversations on
the agent’s phone.
By default, this service is active on all agent desktops when the application is started. After initial installation
of the CAD servers, all agents are already configured to use the Desktop Monitor service for the Silent
Monitoring feature.
A VoIP Monitor service is able to handle multiple requests for Silent Monitoring simultaneously. It captures
packets directly from the switch through the switch's Switched Port Analyzer (SPAN) configuration. An
installation may have up to five VoIP Monitor services on different machines. Off-board VoIP services may
be installed at remote office locations. In some instances, this service may be required due to network complexity
and capacity planning. Agents must be explicitly configured to use a VoIP Monitor service if this is the method
desired for Silent Monitoring for that agent’s device.
Note Cisco Unified IP Phone Agents who do not have a desktop must be configured to use a VoIP Monitor
service for the Silent Monitoring feature.
The Recording and Playback service may also provide the two streams representing a phone call when a
supervisor plays back a recorded agent call. In this case, the streams have already been stored on disk from
an earlier recording session. The Recording and Playback service reads the raw data files from the disk and
sends the RTP streams over the network to the supervisor's desktop, where they are played through the sound
card.
As this description indicates, the Recording and Playback service may be either the requestor (for recording
a live call) or a provider (for playing back a recorded call).
A VoIP and Recording and Playback services are usually installed along with the CAD base services. Additional
VoIP services and a second Recording and Playback service may be installed on other boxes.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
355
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Cisco Agent Desktop
The figure below shows a representative Unified CCE installation supporting a remote office over a WAN.
Both the main office and the remote office have a VoIP Monitor service on-site.
When you locate the requestors and providers, you can determine where the bandwidth is required for the
Silent Monitoring feature. The following notes regarding bandwidth apply:
• Although an administrator can assign a specific VoIP service to an agent device, the Recording service
that is used when calls are recorded is determined at the time the request is made. The same rule applies
if two Recording services are installed to load-balance the installation. In some cases, the provider and
requestor may be separated by a WAN and would require the bandwidth on the WAN. If a second
Recording and Playback service is to be installed, install it on a server at the main office (on the LAN
with the CAD base services).
• If the VoIP provider is a VoIP Monitor service, if the requestor is a Recording service, and if these
services reside on the same machine, then there is no additional bandwidth used on the network to record
the call.
Regardless of who is the requestor and VoIP provider, the bandwidth requirement between these two points
is the bandwidth of the IP call being monitored and/or recorded. For purposes of calculating total bandwidth,
you can think of each monitoring/recording session as being a new phone call. Therefore, to calculate bandwidth
to support the Silent Monitoring feature, you can use the same calculations used to provision the network to
handle call traffic, with the exception that the voice stream provided by the VoIP provider consists of two
streams in the same direction. Whereas a normal IP phone call has one stream going to the phone and one
stream coming from the phone, the VoIP provider has both streams coming from the provider. Keep this
difference in mind when provisioning upload and download speeds for your WANs.
To determine the bandwidth requirements for these voice streams, see the Cisco Unified Communications
Solution Reference Network Design (SRND) Guidehttp://www.cisco.com/en/US/products/sw/voicesw/ps556/
tsd_products_support_series_home.html.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
356
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Cisco Agent Desktop
These applications also require a certain amount of bandwidth, although far less than the Silent Monitoring
feature. In addition, the type of communication across the network is bursty. In general, bandwidth usage is
low when the agents are not performing any actions. When features or actions are requested, the bandwidth
increases for the time it takes to perform the action, which is usually less than one second, then the bandwidth
usage drops to the steady-state level. From a provisioning standpoint, one must determine the probability of
all the CAD agents performing a particular action at the same time. It might be more helpful to characterize
the call center and determine the maximum number of simultaneous actions (in the worst case) to determine
instantaneous bandwidth requirements, and then determine what amount of delay is tolerable for a percentage
of the requested actions.
For example, the raw bandwidth requirement for 1000 CAD agents logging in simultaneously is about 6.4
kilobytes per second and the login time is about 9 seconds (with no network delay) for each agent. If the WAN
link did not have this much bandwidth, logins would take longer as packets were queued before being sent
and received. If this queuing delay caused the login attempts to take twice as long (18 seconds in this case),
would this delay be acceptable? If not, provision more bandwidth.
Each of these applications communicates with the base CAD services running on server machines. In addition,
the agent desktop application communicates with the CTI server through the CTI OS server for call control
actions and state changes. The table below lists the types of messages for each application.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
357
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Cisco Agent Desktop
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
358
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Cisco Agent Desktop
Note The bandwidth requirements shown do not include the bandwidth of the RTP streams for the call, recording,
or monitoring sessions, but include only the messaging needed to start and stop the sessions.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
359
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Cisco Agent Desktop
Best Practices and Recommendations for Cisco Agent Desktop Service Placement
In a Unified CCE installation using Cisco Agent Desktop, all CAD services except the VoIP Monitor service
and the Recording and Playback service must coreside with the PG. You can install the VoIP Monitor Service
and Recording and Playback Service on other servers (off-board).
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
360
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for an Administration and Data Server and Reporting
You can have a maximum of five VoIP Monitor servers in a CAD installation. Only one VoIP Monitor Service
may exist on a single server.
The main load on a VoIP Monitor Service is the amount of network traffic that is sent to the VoIP Monitor
Service for the devices that are assigned to that VoIP service, not the number of simultaneous monitoring
sessions. When Switched Port Analyzer (SPAN) is configured to send traffic from a device to a particular
VoIP service, the VoIP services packet sniffer monitors network traffic even without active monitoring
sessions. The amount of traffic monitored limits the number of devices that you can assign to a VoIP service.
If a VoIP Monitor Service coresides with the CAD base services on the PG, it supports the network traffic of
up to 100 agents. You can dedicate a third NIC for SPAN destination port in this environment, although it is
not necessary. If more than 100 agents are configured to use a single VoIP Monitor Service, you must move
that service off-board to another server. A single VoIP Monitor Service supports the network traffic of 400
agent phones if you use a 100 Megabit NIC to connect to the switch. A single VoIP Monitor Service supports
the network traffic of 1000 agent phones if you use a Gigabit NIC to connect to the switch.
Note If the switch does not support ingress and egress traffic on the same switch port, then you must use a
dedicated NIC to support SPAN services.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
361
Bandwidth Provisioning and QoS Considerations
Bandwidth Requirements for Cisco EIM/WIM
Table 29: Latency and Bandwidth Requirements for the User List Tool
15 2 Mbits 500
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
362
CHAPTER 13
Cisco Unified Contact Center Management Portal
Cisco Unified Contact Center Management Portal (Unified CCMP) is a browser-based management application
designed for use by contact center system administrators, business users, and supervisors. It is a dense
multitenant provisioning platform that overlays the Cisco Unified Contact Center Enterprise (Unified CCE),
Cisco Unified Communications Manager (Unified CM), and Cisco Unified Customer Voice Portal (Unified
CVP) equipment.
From a Unified CCMP perspective, the underlying Unified CCE equipment is viewed as configuration items,
generally known as resources, such as agents or IP phones. Unified CCMP partitions the resources in the
equipment using a familiar folder paradigm, and these folders are then secured using a sophisticated security
structure that allows administrators to specify which users can perform which actions within the specified
folders.
The Unified CCMP focus on supplying dense multi-tenancy functionality helps support the business plans
of large enterprises because it allows the distributed or disparate contact center equipment to be partitioned
or segmented to satisfy the following business goals:
• Unified CCMP abstracts and virtualizes the underlying contact center equipment, thereby allowing
centralized deployment and decentralized control, which in turn provides economies of scale while
supporting multilevel user command and control.
• Unified CCMP allows the powerful and flexible native Unified CCE provisioning operations to be
abstracted into simple high-level tasks that enable business users to rapidly add and maintain contact
center services across the virtualized enterprise (or a portion thereof).
• Unified CCMP users see only the resources in the platform that they are entitled to see, thereby providing
true multi-tenancy.
• Unified CCMP users may manipulate only those resources visible to them by using Unified CCMP
tools and features they have been authorized to use, thereby providing role-based task control.
The Unified CCMP Web interface allows for the concurrent provisioning activities of hundreds of end-users,
thus avoiding the surge of activity at the Administration & Data Server (formerly known as Admin
Workstation, or AW) sometimes experienced in Unified CCE deployments where provisioning requests can
stack up during busy periods. This surge of activity is smoothed by Unified CCMP, so that the central site
is not overloaded with provisioning requests.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
363
Cisco Unified Contact Center Management Portal
Unified CCMP Architecture
Portal Interfaces
Users connect to Unified CCMP through an HTTP/S connection. This is a standard Internet Explorer browser
connection to the Unified CCMP web server.
Unified CCMP uses three interface points with the rest of Unified CCE:
• The Configuration Management Service (CMS) server, which runs on an Administration & Data Server,
acts as the provisioning interface for Unified CCE. It uses the Java RMI protocol, and the CMS server
option must be selected as part of the Administration & Data Server installation.
• The Administration & Data Server “AWDB” database catalog acts as the read-only configuration
confirmation interface for Unified CCE. This is an OLEDB protocol interface that uses either Integrated
Security or SQL Server integration. Integrated Security means that either Unified CCMP must be in the
same Active Directory domain as the Administration & Data Server, or that suitable permissions between
the domains must be set up.
• The Unified CM AXL interface acts as both the provisioning interface and the confirmation interface
for Unified CM. This is the standard web service using HTTP and XML SOAP protocol.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
364
Cisco Unified Contact Center Management Portal
Deployment Modes
Deployment Modes
Unified CCMP supports all Unified CCE Release 8.0 (x) deployment modes, including parent/child. This
section explains the deployment modes and guidelines that pertain to them.
Note For all deployments, each Unified CCE instance connected to a Unified CCMP system requires a separate
Unified CCE physical server configured as an Administration & Data Server.
Lab Deployment
In lab environments only, Unified CCMP software can be installed on the Unified CCE Administration &
Data Server. This co-located model can be used only in labs due to the high processing requirements of the
Administration & Data Server and the maximum configuration of 200 Named Agents.
Standard Deployments
In dedicated server mode, two deployments are supported:
• Single Server. In this simplex mode, all Unified CCMP components are installed on a single server.
Most Unified CCE customers use this deployment because it represents the lowest cost of deployment
and ongoing cost of ownership. This mode supports a maximum configuration of 1500 Concurrent
Agents.
• Dual Server. In this mode, the front-end Unified CCMP components are installed on one server (the
Web Server) and back-end components on another (the Database Server). This allows the use of a firewall
between the Web and Database Servers, which creates a DMZ for Internet connectivity and provides
for higher capacity and performance throughout the system. This mode supports a maximum configuration
of 8000 Concurrent Agents.
Note Both of the above deployments are non-resilient in nature. The workaround in the event of Portal failure
is to revert to provisioning on Unified CCE or Unified CM until Unified CCMP is returned to service, at
which time an automatic resynchronization occurs.
Resilient Deployments
Either of the two standard deployment modes can be enhanced to a resilient configuration using a duplicate
set of hardware with Unified CCMP integrated data replication facilities to provide a geographically dispersed
solution.
Unified CCMP uses SQL Server replication to keep the two sides synchronized. Use the resilient forms of
these deployments if you require fault tolerance. The system capacity limits remain unchanged from the
equivalent standard deployments.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
365
Cisco Unified Contact Center Management Portal
Parent/Child Deployment
Note If a load balancing solution is to be provided to the front end (for example, Cisco Local/Remote Director),
then it must support ‘sticky’ connections.
Parent/Child Deployment
In parent/child deployments, a single Unified CCMP instance connects to each of the child Unified CCE
Administration & Data servers, which must be configured as physically separate Primary Administration &
Data Servers. Each child instance appears as a tenant within Unified CCMP. Resources added via Unified
CCMP are linked to a tenant, and the added resource is replicated from the Unified CCE child to its parent
using the standard replication process.
Roles
The Administration & Data Servers are classified into roles based on the system configuration and the call
load that they can handle. The Administration & Data Server role, known as a Configuration-Only
Administration Server, was designed for use with Unified CCMP when a lightweight Administration & Data
Server running on VMs is desirable.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
366
Cisco Unified Contact Center Management Portal
Administration Server (Configuration-Only Administration Server)
Software Compatibility
Unified CCMP 8.0(x) is backward compatible with Unified CCE versions starting with Unified CCE 7.1.
Always install the latest version of Unified CCMP to get the latest feature set.
Reporting
The provisioning audit information collected by Unified CCMP can be viewed by the end-user using the
Unified CCMP multi-tenanted and partitioned reporting engine. For reporting of Unified CCE call data, use
Cisco Unified Intelligence Center (Unified IC), Unified CCE's advanced reporting platform.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
367
Cisco Unified Contact Center Management Portal
Bandwidth Requirements
Bandwidth Requirements
Unified CCMP does not have any voice data or call signaling paths; therefore, it does not have any QoS
requirements. Very low bandwidth or the use of congested network links will either increase the latency of
the requests or cause application time-outs to be returned to the user.
Use the following bandwidths:
• A minimum of a 256 kbps link between Unified CCMP and Unified CCE /AXL.
Note AXL is particularly sensitive to slow networks due to the relatively verbose SOAP
packets returned during the import phase.
• A minimum of 2 Mbps links between the client browsers and Unified CCMP Web Servers, and 2 Mbps
between the Unified CCMP Web Servers and Unified CCMP Database Servers if quad deployment
mode is used.
References
For further information, see the Unified CCMP product documentation at http://www.cisco.com/c/en/us/
support/customer-collaboration/unified-contact-center-enterprise/tsd-products-support-series-home.html.
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
368
APPENDIX A
Acronym List
Numerics
3DES
Triple Data Encryption Standard
A
ACD
Automatic call distribution
AD
Active Directory
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
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
369
Acronym List
ASR
Automatic speech recognition
AVVID
Cisco Architecture for Voice, Video, and Integrated Data
AW
Administrative Workstation
AWDB
Administrative Workstation Database
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
C
CAD
Cisco Agent Desktop
CC
Contact Center
CCE
Contact Center Enterprise
CG
CTI gateway
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
370
Acronym List
CIPT OS
Cisco Unified Communications Operating System
CIR
Cisco Independent Reporting
CMS
Configuration Management Service
ConAPI
Configuration Application Programming Interface
CPE
Customer premises equipment
CPI
Cisco Product Identification tool
CRM
Customer Relationship Management
CRS
Cisco Customer Response Solution
CSD
Cisco Supervisor Desktop
CSS
Cisco Content Services Switch
CSV
Comma-separated values
CTI
Computer telephony integration
CTI OS
CTI Object Server
CVP
Cisco Unified Customer Voice Portal
D
DCA
Dynamic Content Adapter
DCS
Data Collaboration Server
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
371
Acronym List
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
DSCP
Differentiated Services Code Point
DSL
Digital subscriber line
DSP
Digital signal processor
DTMF
Dual Tone Multi Frequency
E
ECC
Expanded Call Context
H
HA WAN
Highly available WAN
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
372
Acronym List
HDS
Historical Data Server
HSRP
Hot Standby Router Protocol
I
ICCS
Intra-Cluster Communication Signaling
ICM
Cisco Unified Intelligent Contact Management
IDF
Intermediate distribution frame
IDS
Intrusion detection system
IntServ
Integrated services
IP
Internet Protocol
IPCC
Cisco IP Contact Center
IPM
Internetwork Performance Monitor
IPPA
Unified IP Phone Agent
ISN
Internet service node
IVR
Interactive voice response
IXC
Inter-exchange carrier
J
JTAPI
Java Telephony Application Programming Interface
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
373
Acronym List
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
LAA
Longest available agent
LSPAN
Local switched port analyzer
M
MAC
Media access control
Mbps
Megabits per second
MC
Management center
MCS
Media Convergence Server
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
374
Acronym List
MDF
Main distribution frame
MDS
Message delivery Subsystem
MED
Minimum expected delay
MGCP
Media Gateway Control Protocol
MoH
Music on hold
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
OAMP
Operations, Administration, Maintenance, and Provisioning
OPC
Open peripheral controller
OS
Object server
OU
Organizational unit
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
375
Acronym List
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, router, and logger
PSPAN
Port switched port analyzer
PSTN
Public switched telephone network
PVC
Permanent virtual circuit
Q
QoS
Quality of Service
R
RAID
Redundant array of inexpensive disks
RIS
Real-time information server
Rogger
Router and Logger
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
376
Acronym List
ROI
Return on investment
RONA
Reroute On No Answer
RSPAN
Remote switched port analyzer
RSVP
Resource Reservation Protocol
RTD
Real-Time Distributor
RTMT
Real-Time Monitoring Tool
RTP
Real-Time Transport Protocol
S
S1, 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
Systems engineer
SIP
Session Initiation Protocol
SLG
Service level goal
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
377
Acronym List
SNMP
Simple Network Management Protocol
SPAN
Switched port analyzer
SRND
Solution Reference Network Design
SRST
Survivable remote site telephony
SSL
Secure Socket Layer
SUS
Microsoft Software Update Services
T
TAC
Cisco Technical Assistance Center
TAPI
Telephony application programming interface
TCD
Telephony Call Dispatcher
TCP
Transmission Control Protocol
TDM
Time-division multiplexing
TES
Task event services
TFTP
Trivial File Transfer Protocol
TLS
Transport Layer Security
TNT
Takeback N Transfer
TOS
Test other side
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
378
Acronym List
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
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
379
Acronym List
WUS
Microsoft Windows Update Services
X
XML
Extensible markup language
Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
380