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
This design guide describes the deployment models and their implications
including scalability, fault tolerance, and interaction between the solution
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, interactive voice response (IVR), 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
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 contact center
enterprise to include branch offices, home agents, and knowledge workers. The
figure below illustrates a typical Unified CCE setup.
Figure 1. Typical Unified CCE Solution Deployment
The Unified CCE solution consists primarily of four Cisco software
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
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 solution is built on the Cisco IP Telephony infrastructure, which
Cisco Unified IP Phones
Cisco Voice Gateways
Cisco LAN/WAN infrastructure
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.
Communications Manager (Unified Communications Manager) is a software
application that controls the Voice Gateways and IP phones, thereby providing
the foundation for a VoIP solution. Unified Communications Manager runs on
Cisco Media Convergence Servers (MCS). The software running on a server is
referred to as a Unified Communications Manager server. Multiple Unified
Communications Manager servers can be grouped into a cluster to provide for
scalability and fault tolerance. Unified Communications Manager communicates
with the gateways using standard protocols such as H.323, Media Gateway Control
Protocol (MGCP), and Session Initiation Protocol (SIP). Unified Communications
Manager communicates with the IP phones using SIP or Skinny Call Control
Protocol (SCCP). For details on Unified Communications Manager call processing
capabilities and clustering options, see the latest version of the
Cisco Unified Communications
Solution Reference Network Design (SRND) Guide at
Communications Manager communicates with Unified CCE through the Java Telephony
Application Programming Interface (JTAPI). A single Unified Communications
Manager subscriber server is capable of supporting hundreds of agents. In a
fault-tolerant design, a Unified Communications Manager cluster is capable of
supporting thousands of agents. However, the number of agents and the number of
busy hour call attempts (BHCA) supported within a cluster varies and must be
sized according to guidelines defined in
Sizing Cisco Unified Communications Manager Servers.
designing a Unified CCE solution, you first define the deployment scenario,
including the arrival point (or points) for voice traffic and the location (or
locations) of the contact center agents. After defining the deployment
scenario, you can determine the sizing of the individual components within the
Unified CCE design, including how many Unified Communications Manager servers
are needed within a Unified Communications Manager cluster, how many Voice
Gateways are needed for each site and for the entire enterprise, how many
servers and what types of servers are required for the Unified CCE software,
and how many Unified IP IVR or Unified CVP servers are needed.
Cisco Voice Gateways
When you select Voice Gateways for a Unified CCE deployment, it is important to select Voice Gateways that satisfy not only the number of required PSTN trunks but also the busy hour call completion rate on those trunks. Busy hour call completion rates per PSTN trunk are typically higher in a contact center than in a normal office environment. For Cisco Catalyst Communications Media Module (CMM) Voice Gateways used in pure contact center deployments, provision a maximum of four T1/E1 interfaces to ensure that the call processing capacity of the Voice Gateway is satisfactory.
Prior to 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:
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.
The following three families of phones are in the Cisco portfolio:
Cisco Unified IP Phones 7900 Series
The Unified CCE Agent Phone device supported prior to Release 8.0 of Unified CCE.
JAL and DTAL are disabled by default.
The 7900 Series phones support Multi Line Control.
Cisco Unified IP Phones 6900 Series
Outbound campaign capability requires Cisco Unified Contact Center Enterprise 7.5(6) or later release.
The 6900 Series phones do not support call waiting.
JAL and DTAL features are enabled by default.
The 6900 Series phones are supported in Single Line mode only when JAL and DTAL are disabled.
Unified Communications Manager Silent Monitoring and Recording and Remote Silent Monitoring (RSM) are supported with the Release 8.5(4) firmware load or higher.
The 6900 Series phones support Multi Line Control.
Cisco Unified IP Phones 8900 Series and 9900 Series
The 8900 Series and 9900 Series phones support cancel and swap features.
JAL and DTAL features are on all of the time, so contact center agents can merge or transfer calls on the ACD line with calls on other extensions on the phone. Because of this, 8900 Series and 9900 Series phones are supported only when the Multi Line Agent Mode feature of Unified CCE is
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.
Multiline is not supported and must be disabled on all phones.
Unified CCE Release 8.5 added support for the Agent Greeting feature. This feature relies on the Unified CM phone Built-In-Bridge (BIB) functionality to play back the greeting to both the caller and the agent.
Agent Greeting requires:
The phones have the BiB feature.
The phones must be running the firmware version delivered with Unified Communications Manager 8.5(1) or greater.
The phones must be configured as BiB enabled in Unified Communications Manager.
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.
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 Design Mentoring Service to assure that the deployment model is designed and sized correctly to support the Agent Greeting feature.
Cisco Finesse 9.1(1) and later supports Jabber for Windows 9.2 as a contact center voice endpoint.
Finesse supports the following Jabber functionality:
Voice media termination
Built-In Bridge (for silent monitoring)
IM and Presence
Finesse does not support the following:
transfer or conference using Jabber (agents must use Finesse for transfer or conference)
You must change the default configuration for Jabber as follows:
Change Maximum number of calls from 6 to 2.
Change Busy trigger from 2 to 1.
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.
Precision Routing is supported only on Unified CCE Communications Manager PG.
Customer Voice Portal
Voice Portal (Unified CVP) is a software application that runs on
industry-standard servers such as Cisco Media Convergence Servers (MCS). It
provides prompting, collecting, queuing, and call control services using
standard web-based technologies. The Unified CVP architecture is distributed,
fault tolerant, and highly scalable. With the Unified CVP system, voice is
terminated on Cisco IOS gateways that interact with the Unified CVP application
server using VoiceXML (speech) and H.323 or SIP (call control).
The Unified CVP
software is tightly integrated with the Cisco Unified CCE software for
application control. It interacts with Unified CCE using the Voice Response
Unit (VRU) Peripheral Gateway Interface. The Unified CCE scripting environment
controls the execution of building-block functions such as play media, play
data, 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
Communications Solution Reference Network Design (SRND) Guide at
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
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 IP IVR
The Unified IP IVR provides prompting, collecting, and queuing capability for the Unified CCE solution. Unified IP IVR does not provide call control as Unified CVP does because it is behind Unified CM and under the control of the Unified CCE software by way of the Service Control Interface
(SCI). When an agent becomes available, the Unified CCE software instructs the Unified IP IVR to transfer the call to the selected agent phone. The Unified IP IVR then requests Unified CM to transfer the call to the selected agent phone.
Unified IP IVR is a software application that runs on Cisco MCS Servers. You can deploy multiple Unified IP IVR servers with a single Unified CM cluster under control of Unified CCE.
Unified IP IVR has no physical telephony trunks or interfaces like a traditional IVR. The telephony trunks are terminated at the Voice Gateway. Unified CM provides the call processing and switching to set up a g.711 or G.729 Real-Time Transport Protocol (RTP) stream from the Voice Gateway to
the Unified IP IVR. The Unified IP IVR communicates with Unified CM through the Java Telephony Application Programming Interface (JTAPI), and the Unified IP IVR communicates with Unified CCE through the Service Control Interface (SCI) with a VRU Peripheral Gateway or System Peripheral Gateway.
Unified IP IVR supports the Whisper Announcement features starting in Release 8.5(1) SU1 with the following requirements:
You must have Unified CCE Release 8.5(2) or later.
Only in Parent/Child deployment and when the IP IVR is deployed in Child with Unified CCE System PG.
Unified Presence Server
Cisco Unified Presence Server is used by the Cisco Agent Desktop product in the solution to locate appropriate resources (agents or other employees of the enterprise) for managing the call. See the chapter Unified Contact Center Enterprise Desktop for details on Cisco Agent Desktop.
Unified Intelligent Contact Manager
Unified CCE may be deployed with Unified ICM to form a complete enterprise call management system. Unified ICM interfaces with ACDs from various vendors (including Cisco Unified CCE), VRUs (including Cisco Unified IP-IVR and Unified CVP), and telephony network systems to efficiently and effectively treat customer contacts such as calls and e-mail regardless of where the resources are located in the enterprise.
Unified CCE may be deployed in a hybrid model with Unified ICM where the CallRouter,
Logger, Administrative & Data Servers, and other components are shared between
Unified ICM and Unified CCE.
Alternatively, Unified CCE may be deployed in a parent/child model where Unified ICM is the parent and Unified CCE is the child. This closely resembles the deployment model of Unified ICM with ACDs from other vendors. It is used for a highly scalable deployment because it provides CallRouters, data servers, and so forth for each product; although there are more components to manage and maintain. It is also used for a distributed model where isolation is needed between Unified ICM and Unified CCE, such as in an outsourced operation.
Cisco Unified Contact Center Enterprise (Unified CCE)
This topic describes the main components of the Unified CCE Product. Following sections describe some key concepts and terminology and go into more detail on some of the components.
The Cisco Unified CCE software is a collection of components that can run on multiple servers. The number and type of components that can run on one server is primarily based on busy hour call attempts (BHCA) and the size of the server being used (single, dual, or quad CPU). Other factors
that impact the hardware sizing are the number of agents, the number of skill groups per agent, the number of Unified IP IVR ports, the number of VRU Script nodes in the routing script, Expanded Call Context (ECC) usage, and which statistics the agents need at their desktops.
The core Unified CCE software components are listed here and described in greater detail later in this chapter.
Table 1 Core Unified CCE Software Components
Unified CCE Software Components
Makes all routing decisions on how to route a call or customer contact. Often just
referred to as the "Router" in the context of Unified CCE components.
The database server that stores contact center configuration data and temporarily stores historical reporting data for distribution to the data servers.
CTI Object Server (CTI OS)
CTI interface for Agent Desktops.
Peripheral Gateway (PG)
Interfaces to various peripheral devices, specifically to Unified CM,
VRU (Unified IP IVR or Unified CVP), or Multichannel products (EIM and WIM for email
and chat). The PG includes one or more Peripheral Interface Managers (PIMs) for the
specific device interfaces.
PG that has a Unified CM PIM.
Unified CM Peripheral Interface Manager (PIM)
Part of a PG that interfaces to a Unified CM cluster by using the JTAPI protocol.
Part of a PG that interfaces to the Unified IP IVR or Unified CVP through the Service Control Interface (SCI) protocol.
Part of a PG that interfaces to call center Multimedia products, specifically EIM and WIM for email and chat.
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.
Configuration interface. This component has a subset of the functionality of the
Administration & Data Server. It is a lighter weight deployment
because it does not require a local database and it is deployed to allow more places
from which to configure the solution.
Cisco Unified Intelligence Center (Unified Intelligence Center)
Provides web browser-based real-time and historical reporting. Unified Intelligence Center also works with other Cisco Unified Communications products.
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.
Redundancy and Fault Tolerance
The CallRouter and Logger are deployed in a paired redundant fashion. This redundant configuration is also referred to as duplex mode, whereas a non-redundant configuration is said to be running in simplex mode. (Note: Simplex mode is not supported for
production environments.) The two sides of the redundant deployment are referred to as Side A and Side B. For example, CallRouter A and CallRouter B are redundant instances of the CallRouter running on two different servers. When both sides are running (normal operation), the configuration is
in duplex mode. When one side is down, the configuration is said to be running in simplex mode. The two sides are for redundancy, not load-balancing. Either side is capable of running the full load of the solution. The A and B sides are both executing the same set of
messages and, therefore, producing the same result. In this configuration, logically, there appears to be only one CallRouter. The CallRouters run in synchronized execution across the two servers, which mean both sides of the duplex servers process every call. In the event of a failure, the
surviving Call Router picks up the call mid-stream and continue processing in real-time and without user intervention.
The Peripheral Gateway components run in hot-standby mode, meaning that only one of the Peripheral Gateways is actually active and controlling Unified CM or the IVR. When the active side fails, the surviving Side Automatically takes over processing of the application. During a failure, the
surviving side is running in simplex mode and continues to function this way until the redundant side is restored to service and the configuration automatically returns to duplex operation.
The CTI OS component provides fault tolerance through a pair of servers that operate together and back up each other. There is no notion of an active and passive server, or of a primary and secondary server. Both servers are always active. Clients may connect to either server. In the event of
the failure of any one server, clients can automatically reconnect to the alternate server.
The Administration & Data Servers for configuration and real-time data are deployed in pairs for fault tolerance, with multiple pairs deployed for scalability. The data flows are described in Administration and Data Server and Administration Client. The Administration & Data Servers for historical data follow
an n+1 architecture for redundancy and scalability with each having a Logger side (A or B) as its preferred and primary data source.
Customer Instance and Unified CCH
The Cisco Unified Contact Center Hosted (Unified CCH) solution is largely the same as Unified CCE, but it supports multi-tenant or shared servers to manage multiple customer instances.
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.
Peripheral Gateway (PG) and PIMs
For each Unified CM cluster in the Unified CCE environment, there is a Unified CM PIM on an Agent Peripheral Gateway. For scalability requirements, some deployments may require multiple PIMs for the same Unified CM cluster; they may be on the same PG and physical server or they may be
For each Agent PG, there is one CTI Server component and one or more CTI OS components to communicate with the desktops associated with the phones for that Unified CM cluster.
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.
Figure 2. Communications Among Peripheral Gateway Software Processes
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.
Network Interface Controller
The Network Interface Controller (NIC) is an optional component that interfaces to the public switched telephone network (PSTN). Intelligently routing a call before the call is delivered to any customer premise equipment is referred to as pre-routing. Only certain PSTNs have NICs supported by Unified CCE. For a detailed list of PSTN NICs and details on Unified CCE pre-routing, see the Pre-installation Planning Guide for Cisco Unified ICM Enterprise & Hosted.
Cisco offers the following interfaces for Unified CCE agents:
Cisco Finesse Desktop: Cisco Finesse is a web-based desktop
solution that allows for the extension of the desktop through standardized web
components. Cisco Finesse offers:
a browser-based solution only
an extensible desktop interface using standard OpenSocial
server features available to applications using documented REST
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:
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
Figure 3. Variety of Agent Interfaces for Unified CCE
Administration and Data Server and Administration Client
Administration & Data Servers have several roles: Administration, Real-time data server, Historical Data Server, and Detail Data Server. A Unified CCE deployment must have Administration & Data Servers to fill these roles. The servers may be deployed in the following combinations to
achieve the needed scalability with the minimum number of servers:
Administration Server and Real-Time Data Server (AW)
Configuration-Only Administration Server
Administration Server, Real-Time and Historical Data Server, and Detail Data Server (AW-HDS-DDS)
Administration Server and Real-Time and Historical Data Server (AW-HDS)
Historical Data Server and Detail Data Server (HDS-DDS)
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.
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).
Server, Configuration-Only Administration Server, and Administration Client
provide a Configuration Manager tool that is used to configure Unified CCE. The
configuration options include, for example, the ability to add agents, add
skill groups, assign agents to skill groups, add dialed numbers, add call
types, assign dialed numbers to call types, or assign call types to routing
Server and Administration Client also have the tool Script Editor, which is
used to build routing scripts. Routing scripts specify how to route and queue a
contact (that is, the script identifies which skill group or agent handles a
In Unified CCE
Release 9.0(1), a new feature, Precision Routing is available. To configure
Precision Routing, you can use a web-based application — Unified CCE
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
AW communicates directly with the Central Controller for configuration
data (see Figure 4) and the
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.
Administration Clients can be deployed and connected to either primary or
secondary AWs. An Administration Client must be geographically local to its AW.
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
Figure 5. Communication
Between Unified CCE Central Controller and Multiple Administration & Data
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.
The Real-Time Data Server portion of the AW uses the AW database to store real-time data along with the configuration data. Real-time reports combine these two types of data to present a near-current transient snapshot of the system.
Historical Data Server And Detail Data Server
The Historical Data Server (HDS) and Detail Data Server (DDS) are used for longer-term historical data storage. The HDS stores historical data summarized in 15 or 30 minute intervals and is used for reporting. DDS stores detailed information about each call or call segment and is used for call tracing. Data may be extracted from either of these sources for warehousing and custom reporting.
Typically these Data Servers are deployed with a primary AW as a single server serving all three roles (AW-HDS-DDS). In very large deployments, it might be desirable to separate them for scalability.
Unified CCE Reporting
The Unified CCE Reporting solution provides an interface to access data describing the historical and real-time states of the system.
The reporting solution consists of the following components:
Cisco Unified Intelligent Center—Reporting user interfaces
Configuration and Reporting Data—Contained on one or more Administration & Data Servers
Cisco Unified Intelligence Center (Unified Intelligence Center) is an advanced reporting product used for Unified CCE and other products. This platform is a web-based application offering many Web 2.0 features, high scalability, performance, and advanced features such as the ability to integrate data from other Cisco Unified Communications products or third-party data sources. Unified Intelligence Center incorporates a security model that defines different access and capabilities for specific users.
Unified Intelligence Center Standard is included with Unified CCE. Unified Intelligence Center Premium is an optional product with additional features. See the Cisco Unified Intelligence Suite Intelligence Center User Guide. Unified Intelligence Center must be installed on a separate server; it cannot be co-resident with other Unified CCE components.
Unified Contact Center Management Portal
The Unified Contact Center Management Portal provides a simple-to-use web-based user interface to streamline the day-to-day provisioning and configuration operations performed by a contact center manager, team lead, or administrator. The management portal provides the following key benefits:
Simple-to-use web user interface for performing basic tasks such as moving, adding, or modifying phones, agents, skill groups, and teams and other common contact center administrative functions for an IP contact center
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
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
communications between the Unified CM and Unified CCE include three distinct
types of messaging:
messages provide a way for Unified CM to request routing instructions from
Device and call monitoring
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
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
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.
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
Communications System Solution Reference Network Design (SRND) Guide at
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, 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.
scenarios are examples of device and call control performed by the Unified IP
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
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.
Multichannel Subsystems: EIM and WIM
Unified CCE has the capability to provide a multichannel contact center with E-mail Interaction Manager (EIM) and Web Interaction Manager (WIM).
Agents can handle both inbound and outbound contacts, which helps in optimizing contact center resources. The Cisco Unified Outbound Option enables the multifunctional contact center to take advantage of Cisco Unified CCE enterprise management. Contact center managers in need of outbound
campaign solutions can take advantage of the enterprise view that Cisco Unified CCE maintains over agent resources. (See Outbound Option for Cisco Unified Contact Center Enterprise and Hosted for details.)
Cisco Unified Mobile Agent
Cisco Unified CCE provides the capability for an agent to use any PSTN phone and a quality high-speed data connection between the agent desktop and the CTI OS server. (For design guidance and considerations for implementing Cisco Unified Mobile Agent, see the Cisco Unified Mobile Agent chapter.)
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.
Unified CCE is managed using the Simple Network Management Protocol (SNMP). Unified CCE devices have a built-in SNMP agent infrastructure that supports SNMP v1, v2c, and v3 and it exposes instrumentation defined by the CISCO-CONTACT-CENTER-APPS-MIB. This MIB provides configuration, discovery, and health instrumentation that can be monitored by standard SNMP management stations. Unified CCE provides a rich set of SNMP notifications that alerts administrators of any faults in the system. Unified CCE also provides a standard syslog event feed (conforming to RFC 3164) for those administrators who want to take advantage of a more verbose set of events.
For managing a Unified Communications deployment, customers are encouraged to use the Cisco Unified Operations Manager (Unified Operations Manager) product. Unified Operations Manager is a member of the Cisco Unified Communications family of products and provides a comprehensive and efficient solution for network management, provisioning, and monitoring of Cisco Unified Communications deployments.
Unified Operations Manager monitors and evaluates the current status of both the IP communications infrastructure and the underlying transport infrastructure in your network. Unified Operations Manager uses open interfaces such as SNMP and HTTP to remotely poll data from different devices in the IP communications deployment. In addition to the infrastructure, Unified Operations Manager offers capabilities specific to Unified Communications applications including Unified CCE. For more information, see the Unified Operations Manager documentation.
Combining IP Telephony and Unified CCE in the Same Unified Communications Manager Cluster
It is possible for a Unified Communications Manager cluster to support Cisco Unified IP phones with both normal IP Telephony (office) extensions and Unified CCE (call center) extensions. When running dual-use Unified Communications Manager clusters with both IP Telephony and Unified CCE extensions, it is important to ensure all elements of the solution are compatible, as documented in the
Cisco Unified Contact Center Enterprise Compatibility Matrix at http://docwiki.cisco.com/wiki/Compatibility_Matrix_for_Unified_CCE.
It is also important to note that many contact center environments have very stringent maintenance windows. Unified CCE agents process far more calls than typical administrator phone users in a Unified Communications Manager cluster, so their device weight (or the amount of processing power required per agent) is higher than a typical business phone user. For example, an administrator-only cluster might be able to support 20,000 phones, but a Unified CCE cluster might support only a fraction of those as agents because of the higher call volume and messaging that Unified Communications Manager is required to maintain to support those agents.
Because of these software and environmental limitations, it might sometimes be advantageous to separate the Unified Communications Manager clusters for IP Telephony extensions from the Unified Communications Manager clusters for Unified CCE extensions. It is important to consider the environment where Unified CCE is being deployed to determine whether a separate Unified Communications Manager cluster is advantageous.
Combining IP Telephony and Unified CCE Extensions on the Same IP Phone
Unified CCE supports only one agent ACD line on the IP phone, which does not have voice-mail or call forwarding defined so that Unified CCE can manage and control all calls sent to the agent on this line. Typically, the agent extension is not used as the agent’s DID or personal line. A separate line can be assigned to the agent’s phone for that purpose and can be configured with voice-mail and other calling features.
The position of the line on the phone determines which line is answered or used if the agent just picks up the handset. In a typical call center, the ACD line is the first line on the phone to make it easier for the agent to answer inbound ACD calls and ensure that calls the agent makes using the phone are tracked by the system as external calls. The agent’s state changes based the activity on this line. If the agent picks up the phone to place a call, the agent is put into not-ready mode and the Unified CCE does not route a call to that agent.
In some cases, the agents are knowledge workers or they do not take as many ACD calls as they do normal extension calls. The call center manager does not track their phone activity that is not ACD related, and it might be inconvenient for those users to always get the ACD line first when they want to pick up a DID call instead. In this case, the order of the lines might best be reversed, placing the ACD line on the last (or bottom) line appearance on the phone and placing the DID or normal extension on the first line on the phone. This arrangement allows users to pick up the phone and answer the first line as well as use this line for all calls they place. To answer an ACD call, they have to select that line on the phone or use the agent desktop to answer that line appearance directly. Also, be aware that they have to manage their agent state and go into not-ready mode manually when they want to place a call on their normal extension so that Unified CCE does not attempt to route a call to them while they are on the other line.
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).
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.
Agent Phones in Countries with Toll-Bypass Regulations
Some countries, such as India, have telecommunications regulations that require the voice infrastructure to be partitioned logically into two systems: one for Closed User Group (CUG) or Voice over IP (VoIP) to enable communications across the boundaries within the organization, and a second one to access the local PSTN. To ensure adherence to the regulations in such countries, agents used to have only one line with access to customer calls and a different phone (for example, a soft phone) to access a VoIP line for contacting teammates or experts located outside the contact center.
The Logical Partitioning feature in Cisco Unified Communications Manager provides the same capability through a telephony system to control calls and features on the basis of specific allowed or forbidden configurations. A common telephony system in a contact center environment can provide access to both the PSTN and VoIP networks, and therefore configurations are required to provide controlled access and to avoid toll bypass.
The Logical Partitioning feature can be enabled and configured in Unified Communications Manager to prevent toll-bypass calls, thus allowing agents in a Unified CCE system to use the same phone for receiving customer calls and for making or receiving VoIP calls to and from other people within the organization. Although this 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.
Queuing in a Unified CCE Environment
Call queuing can occur in three distinct scenarios in a contact center:
New call waiting for handling by initial agent
Transferred call waiting for handling by a second (or subsequent) agent
Rerouted call because of ring-no-answer, waiting for handling by an initial or subsequent agent
When planning your Unified CCE deployment, it is important to consider how to handle queuing and requeuing.
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.
Transfers and Conferences in a Unified CCE Environment
Transfers and conferences are commonly used in contact centers, and they require special attention to ensure the proper system resources are available and configured correctly. (See Deployments)
When Call Recording is enabled in the DN configuration for an agent phone, the codec is not renegotiated when establishing a conference. As a result, if two phones are connected using g.722 and a conference call is initiated, the codec is not renegotiated to g.711 and a hardware conference
bridge or transcoder is required.