The Unified CCE delivers intelligent contact routing, call treatment, network-to-desktop computer telephony
integration (CTI), and multichannel contact management over an IP infrastructure. It combines multi-channel automatic call distributor (ACD) functionality with IP telephony in a unified solution, enabling customers to rapidly deploy a distributed contact center infrastructure.
Unified Contact Center provides the following services:
Segmentation of customers and monitoring of resource availability
Delivery of each contact to the most appropriate resource anywhere in the enterprise
Comprehensive customer profiles using contact-related data, such as dialed number and calling line ID
Routing to the most appropriate resource to meet customer needs based on real-time conditions (such as agent
skills, availability, and queue lengths) continuously gathered from various contact center components
The Unified Contact Center enables customers to smoothly integrate inbound and outbound voice applications with
Internet applications such as real-time chat, web collaboration, and email. This integration enables a single agent to support multiple interactions simultaneously regardless of which communications channel the customer chooses.
The Unified Contact Center is a distributed solution with no single-server implementation, but rather, the Unified
CCE employs multiple servers each with multiple software components. Deployment options are extremely flexible with performance, capacity, and network topology driving the deployment design.
The Unified Contact Center was derived from the Unified ICME with the primary difference being that the Unified
Contact Center integrates only with the Cisco Unified Communications Manager (Unified CM) IP PBX. All other major components of the Unified Contact Center solution are the same as a Unified ICM solution.
The Unified ICM platform was originally designed to route calls between various nodes in the TDM telephone
network. It is designed with an emphasis on reliability and flexibility. All processing in these components is message based. The processing of each message is determined entirely by the content of the message, and the current state of the process. The messages are delivered to these
components using the Unified ICM Message Delivery Service (MDS). MDS ensures that both processes are fed the exact same set of messages in the same order.
One of the most important concepts to understand about the Unified Contact Center is its redundancy strategy. The
components that contain centralized state are run in duplex, in that two of these components work in lockstep to ensure redundancy and immediate recovery from a (single point of failure) fault.
From a device standpoint, a typical Unified CCE deployment looks as follows:
Figure 1. Unified CCE Architecture
There are four major components of a Unified CCE deployment: the Router, the Logger, the Peripheral Gateway (PG)
and the Administration & Data Server. The basic function of each is as follows:
Router: Make the routing decisions – select a peripheral or agent to receive an inbound contact (voice call, email, chat and so on).
Logger: Store (and replicate) all configuration, real-time and historical data.
Peripheral Gateway: Act as a gateway to a peripheral device – an IP PBX or an Interactive Voice Response
(IVR) unit – as well as a CTI gateway linking agent desktops.
Administration Workstation: A server implementation that provides a copy of configuration data (from the
Logger), an interface for real-time data, and a platform for the historical data server (HDS). The Administration & Data Server also offers an interface for administrators to alter configuration and routing scripts (Script Editor, Internet Script Editor).
The Router is the brain of the Unified CCE. The Unified CCE can run user-defined scripts to make decisions on what happens with calls, and can determine how to get a call from one place to another. The Router communicates with several other components, including the Logger, the PGs, and the Administration & Data Servers (ADSs).
The Router receives notification from routing clients (PGs) that a call is in need of some form of routing. It then executes a user-defined script to determine what to tell the routing client to do with the call.
In addition, the Router receives status events and reporting events from PGs. The Router uses these messages to update its current representation of the agents and resources in the system, which is used by the scripts to determine where to send calls. It also sends these messages to the Logger for storage and some of the messages to the Admin Workstations for real-time reporting.
Routers, Loggers and PGs are fault tolerant, having two instances of each component so that a failure of one provides for bump-less continuation of function through the remaining half of a duplex pair. Routers are duplex entities, which means that two separate, distributed instances (identified as Side A and Side B) use the MDS to keep in lockstep with the other side, ensuring that any outage of one side guarantees that the system continues operating without failures or impairments—the opposite side assuming sole responsibility for making routing decisions. All data as well as call control messaging is shared between sides to ensure that both sides have the same data by which to make (the same) routing decisions. Both Router sides are concurrently in service.
Like a PG, a Network Interface Controller (NIC) is a type of routing client. However, a NIC is more limited than a PG. A NIC is used to interact with a telephony network, usually the TDM. A NIC is typically coresident with the Router and used for Unified ICM deployments.
The Unified CCE uses the Logger to store historical data and configuration data about the call center. The Logger
is the place where historical data is first stored, and from which it is later distributed. The Logger receives messages from the Router. These messages include detail messages about the calls as well as summary messages that the PGs compute and send through the Router. Examples of these
are half-hour summaries (how many calls were received during a given period).
The Logger uses a synchronization process that is a little different than the Router. The messages coming to the
Logger are sent only from the corresponding Router. Side A Router sends messages only to the Side A Logger. Side B Router sends messages only to the Side B Logger. Because the Routers are running in lockstep, it is guaranteed that while messages are flowing they are the same messages;
however, recovery happens directly from Logger to Logger, using bulk database copy algorithms for efficiency.
The Loggers also distribute historical data to HDS and configuration and real-time data to the Administration
& Data Servers through MDS. Loggers are duplex as well and are tightly coupled with their respective Router. In many deployments, a side of the Router and Logger are collocated on the same physical server; a Router/Logger combination is often referred to as the Central
Figure 2. Central Controller Architecture
The PG is the
component that talks to the telephony devices through their own proprietary CTI
interface in a Unified CCE system. These devices can be ACDs, IVR devices or,
in cases such as with the Unified CCE, an IP PBX. The PG normalizes whatever
protocol the telephony device speaks, and keeps track of the state of agents
and calls that are on that device. The PG sends this status to the Router, as
well as forwards requests requiring customer logic to the Router.
The PG also exposes
a normalized CTI interface to clients. These clients can be traditional CTI
clients (wallboards, agent/supervisor desktop clients, and so on), or they can
be another instance of Unified CCE, as is the case in a parent/child
The component of the
PG that does the normalization is called a Peripheral Interface Manager (PIM).
This component talks to the peripheral and translates whatever proprietary
language it speaks into the normalized one that the Open Peripheral Controller
(OPC) and the rest of the PG understand.
PGs fall into
several groups. The first classification of PG includes those that talk to an
ACD or Unified CM that has agents on it. This is the typical case for a PG. It
talks a proprietary CTI protocol to the switch, and maintains the state of
agents and calls in queue on the device. While all of these PGs report agent
state to the Central Controller, they do it in a different way. In the case of
a PG talking to an ACD, the PG mirrors the state of the agents on the ACD; it
keeps a copy of the master state of the agents tracked by the ACD. In the case
of a PG attached to a Unified CM, the Unified CM does not know about agents or
agent states, it only knows about phone lines. In this case the PG is the
master for the agent state.
classification of PG is a VRU or Media Routing (MR) PG. These PGs expose an
interface that is client-neutral. In the case of the VRU PG, this interface is
tailored to voice calls; in the case of the MR PG, it is more generic task
routing that is exposed. These PGs do not maintain agent state, but only
maintain the state of calls (or tasks) and expose an interface for the devices
to get instructions from the Router.
classification of PG is the group PG. There are two types of PGs that talk to
groups of peripherals. The first is the Generic PG. This PG allows multiple
PIMs of different types to reside inside of the same PG. Each peripheral on
this PG behaves completely independently. Currently the Generic PG is supported
only for the Unified CCE, where it contains a Communications Manager PIM and a
VRU PIM talking to an IP-IVR or Customer Voice Portal (CVP). The second type of
group PG is a Unified CCE System PG. This PG, like the generic PG, has one Call
Manager PIM and one or more VRU PIMs. The System PG ties these multiple PIMs
together. In a traditional Unified CCE, a call that comes into the
Communications Manager then gets transferred to the IP-IVR and then back to an
agent looks like three separate calls to the Unified CCE. The System PG
coordinates these calls and makes that call look like a single call. This is
what happens on a traditional TDM ACD, where the ACD also has a queue point.
Figure 3. Peripheral
The PG is duplexed
using the same technology as the Central Controller, MDS. This means that there
are two PGs operating at any time. All of the messages to the critical process
on the PG (OPC) go through the MDS queue, to keep the two operating in
lock-step. However, the PG operates slightly different from the Router – from a
fault tolerance standpoint – in that while both sides share the same data, for
many PG components, only one side is active. Should a fault occur, the opposite
side activates and continues functioning, having the context of the other side
without losing calls.
PGs use the Device
Management Protocol (DMP) to communicate between themselves and the central
controller. The following figure depicts the components involved in this
communication and the communication links employed.
Figure 4. DMP
Coresident with the
PG is the CTI Gateway (CG - CTI Server component) and the Cisco Computer
Telephony Integration Option (CTI OS).
The Open Peripheral Controller (OPC) computes and maintains the state of agents on the PG, reporting that state to the Router, knowing when a call needs to request instructions from the Router, and performing the CTI operations on the telephony device as necessary. OPC is the critical process on the PG. It is kept in lock-step with its sibling on the other side.
Peripheral Interface Manager
The Peripheral Interface Manager (PIM) is responsible for the connection to the peripheral (ACD, PBX, IVR). This process is not a lock-step process nor is data shared between the two sides. Instead either the Side A or Side B PIM is active for each peripheral. If one side loses its connection, the other side activates.
The Communications Manager PIM provides the interface between the Unified CM and the Unified CCE OPC process. This PIM communicates with the Unified CM through the JTAPI Gateway.
The VRU PIM provides an interface to a VRU (or IVR). The communication protocol used between the PIM and the VRU is GED-125.
Media Routing PIM
The Media Routing (MR) PIM provides the integration point for multimedia contacts such as emails or collaboration (chat) sessions. It is also a necessary component for integration of the Outbound Option Dialer.
TDM ACD PIMs
Unified ICME/Unified ICMH only
The TDM ACD PIMs provide interfaces to various manufacturers’ Automatic Call Distributors. The communication protocol between the PIM and the ACD is typically proprietary.
Unified CCE/Unified CCH only
The JTAPI Gateway is a process that connects to the Unified CM CTI Manager and provides the link between the peripheral gateway and the Unified CM cluster. The Unified CM CTI Manager communicates CTI messages to and from other nodes in the Unified CM cluster. The JTAPI Gateway provides an added level of translation between the (Java) JTAPI interface and the (C++) Unified Communications Manager PIM.
CTI Gateway (CTI Server)
The CTI Server is the interface from OPC to CTI clients. It provides an interface (protocol) specified as GED-188.
This interface has many variances and message sets. It has been used as a direct CTI connection to agent desktops or third-party desktops. This use has been deprecated.
GED-188 helps to make the details of individual peripherals hidden, but does not fully complete the job. The
messages sent from a CTI Server connected to an Aspect PG are different than the messages sent from a CTI Server connected to a Unified CCE PG.
Today the CTI Server connects to several types of clients:
CTI OS – this is the client of choice for agent and supervisor desktops, as well as CRM integration.
Agent Reporting and Monitoring (ARM) clients – this variance of GED-188 allows reporting agent status and
receiving information about the status of agents. It is one of the integration points for multi-channel (e-mail and web collaboration) applications as well as for the Outbound Dialing options.
Parent ICM – a single connection is allowed to a CTI Server attached to a Unified CCE System PG. This
connection allows the parent ICM to receive status about agents and calls on this PG, as well as to take control of certain incoming calls and route them itself. This variance of GED-188 is known as ACMI.
At any given time, only Side A or Side B CTI Server is active, not both. Clients must connect to one or the
Computer Telephony Integration Option
The Computer Telephony Integration Option (CTI OS) is the connection from the PG to desktop clients and is also used for CRM integration. CTI OS completes the abstraction of peripheral type. The set of messages and commands are the same no matter what type of peripheral you connect the PG to.
CTI OS is also used as the per-agent connection to the Cisco Agent Desktop. CTI OS can connect to both Side A and Side B CTI Servers to provide a reliable connection.
The Cisco Agent
Desktop (CAD) base services consist of a set of services that run as Windows
Server services. The base services include:
Browser and IP
Phone Agent Service
Resource Manager Service
Service and BIPPA Service interact with the CTI service, typically running on a
PG. You can place additional services on the same or separate computer as the
base services. These additional services include:
Voice over IP
A set of the base
services plus the additional services is a logical contact center, or LCC. The
maximum number of agents that can be supported by a single LCC is 2,000
(approximately 15,000 Busy Hour Call Completion [BHCC] with a call volume of 20
calls per agent per hour).
The Cisco Agent
Desktop services typically reside coresident on the same server with PG and CTI
To check if a
service is running, use the following table to match the name shown in the
Services window (accessed through the Windows control panel) with a particular
The Unified CCE configuration system is also based around the concept of reliability and scalability. There can be multiple configuration database copies, which are kept in sync using MDS and a synchronization process from the central controller. Each of these can send updates to the Router, but only the Logger configuration database is authoritative.
The configuration system consists of the DBAgent process on the Router, which accepts connections from the Administration & Data Servers, and distributes configuration updates to those Administration & Data Servers. The Administration & Data Servers have a copy of the configuration and expose a GUI for browsing and making changes. The Administration & Data Servers also expose an API (ConAPI) for accessing the configuration information and for making changes.
The Administration & Data Server is the main interface to the Unified ICM/Unified CCE configuration. On the
Administration & Data Server resides a database that contains a copy of the configuration information in the Logger. A Distributor process, which receives updates from the central controller, writes to the database to keep everything in sync. Multiple clients read the configuration
from the database and send update messages to the central controller DBAgent process.
The two main clients in the Administration & Data Server are the configuration tools, which are used to
provide a GUI to update the configuration, and the Configuration Management Server (CMS) process, which is used to provide the Configuration API (ConAPI).
Processes that connect to ConAPI are the multi-channel components for agent and skill group management and
The Administration & Data Server does not have a dependent twin but rather provides fault tolerance in
numbers (N+1 model). A typical Unified ICM/Unified CCE deployment often has two or more Administration & Data Servers. Administration & Data Servers connect to each central controller side – a primary and a secondary – so that if a failure occurs on the primary link, the
secondary is utilized to recover from the failure and restore connectivity.
Configuration data is supported on multiple Administration & Data Server types:
Administration Server and Real-time Data Server (AW Distributor) (with no HDS; configuration and
real-time data but no historical or call detail data)
Administration Server, Real-time and Historical Data Server, and Detail Data Server (AW-HDS-DDS),
(configuration, real-time, historical and call detail data)
Administration Server and Real-time and Historical Data Server (AW-HDS) (configuration, real-time and
historical data but no call detail data)
Administration & Data Server configuration (AW-CONFIG, configuration data only)
Configuration changes are not supported on the HDS-DDS type (which includes historical and call detail data but
excludes real-time data); this type includes only configuration data needed for historical reporting purposes.
Figure 5. Configuration System Message Flow
Figure 5 illustrates how a configuration update may happen in the Unified CCE:
In the first step (not shown) an Administration Client reads configuration from the database, and
determines that a change is required.
When this happens, the GUI connects to the DBAgent process on the central controller and sends the
update (Step 1).
DBAgent sends the message to the Router, through MDS (Steps 2, 3).
The Router validates the configuration message and sends it to the Logger to be executed (Steps 4, 5).
The Logger updates its configuration (Step 6).
The Logger sends confirmation of the update to the Router (Steps 7, 8).
The Router then sends the update to all of its clients (DBAgent, PGs, etc) (Step 9, 10).
DBAgent sends this message to each of its Administration Server and Real-time Data Servers (Step 11).
The Administration Server and Real-time Data Servers update their database (Step 12).
The Configuration GUI detects the change happen (Step 13).
The reporting system
for Unified ICM/Unified CCE is similar to its configuration system; they use
the same distribution channel:
are generated by PGs (this includes both detail messages and summary messages)
and then are sent to the Central Controller, which consists of the Router and
The Router feeds
real-time data to the Administration Server and Real-time Data Servers.
The Logger stores
historical data and replicates it to the Historical Database.
Server and Real-time Data Servers write those records into the real-time
reporting database. Those Administration Server and Real-time Data Servers that
are configured to have Historical Data Servers also write the appropriate
records to the historical database. Cisco Unified Intelligence Suite (Unified
IS) are web applications that uses Java Servlets to build reports to be viewed
from thin (web browser) clients.
The Historical Data Server (HDS) is an option to be installed with an Administration Server and Real-time Data
Server. It uses the same distributor technology used to keep the configuration database up to date. The HDS provides a long-term repository for historical data and offloads historical reporting from the Logger. Historical data is replicated from the Logger to one or more HDSs.
There are three types of HDSs:
Administration Server, Real-time and Historical Data Server, and Detail Data Server (AW-HDS-DDS):
HDS with call detail data store. This type includes both real-time and configuration data and you can use it to source historical data for the Analysis Call Path tool. This type is intended for small- to medium-sized deployments. There may be a maximum of two AW-HDS-DDS servers
per Logger side in small/medium deployments but only one per Logger side in a large deployment (presumably with multiple AW-HDS servers).
Administration Server and Real-time and Historical Data Server (AW-HDS): HDS without a call
detail data store (no call detail, call variable, agent state data). This type also includes both real-time and configuration data but you cannot use it to source data for the Analysis Call Path tool. This type is intended for large deployments. There may be a maximum of three
AW-HDS per Logger side.
HDS-DDS: HDS with call detail data store but no real-time data or configuration data. This type
may be used to source historical data for the Analysis Call Path tool. This type is intended for large deployments and for use in conjunction with multiple AW-HDS servers. There may be a maximum of one HDS-DDS per Logger side (presumably with multiple AW-HDS servers).
Unified Intelligence Center
Unified Intelligence Center is a web-based reporting platform for the Cisco Unified Communications products and
is supported by Unified ICME, Unified ICMH, Unified CCE and Unified CCH.
You can install Unified Intelligence Center as a standalone server or in a cluster of a maximum of eight server
nodes. There is one mandatory publisher node (called the Controller) and up to seven subscriber nodes (called Members). The Controller node includes a Member, which means a deployment can consist of a Controller only.
Cisco Unified Intelligence Center offers both a web-based reporting application and an administration interface.
The reporting application runs on the Members. The administration application runs on the Controller.
Unified Intelligence Center reporting features include multi-user support, customized reports, security, multiple
display formats, web accessibility, and Web 2.0-like mashup support to display data from multiple sources on a single dashboard. These features make Unified Intelligence Center a valuable tool in the information technology arsenal of any organization and position it as a drop-in
replacement or solution for most reporting requirements.
Cisco Unified Intelligence Center reporting capabilities include:
Web 2.0 based dashboard mashups
Powerful grid presentations of reports with sorting and grouping
Chart and gauge presentations of reports
Association of multiple report displays with the same report definition
Custom thresholds to alert on the data
Pre-installed stock report templates for Unified CCE data
Ability to report data from JDBC compatible data sources
Unified Intelligence Center supports the following:
Customized dashboards and custom reports
Detailed security levels and LDAP/local database authentication
Import and export of report XML files
Export of grid reports to Microsoft Excel
Management support through Simple Network Management Protocol (SNMP), Java Management Extensions (JMX),
and Cisco Analysis Manager
Unified Intelligence Center Standard Deployment Model
The Unified Intelligence Center deployment with the Unified CCE utilizes the AW-HDS as its data source server.
You can connect to multiple AW-HDS databases to handle the load from multiple Unified Intelligence Center reporting nodes. You can use other data sources, such as the CVP Reporting Server, along with the Unified CCE AW-HDS as data source servers. The ACE load balancer, an optional
component, provides load balancing for report queries across the multiple reporting nodes and servers as a single point of access to the cluster.
You can use Unified CCE deployments with a distributed AW-HDS as a data source for Unified Intelligence Center
reports. However, local area network AW-HDS access ensures better throughput in data extracted and ensures faster response times for reports, especially real-time reports with repeated refresh intervals.
Figure 6. Unified Intelligence Center Standard Deployment
Intelligence Center Scaled Deployment Model
You can deploy the
Unified Intelligence Center as the reporting solution with Unified CCE
deployments that scale over WAN networks. In these deployments, the Unified
Intelligence Center is deployed locally with one section/data center of the
scaled Unified CCE deployment and can access the local AW-HDS over the Local
Area Network (LAN), as well as the remote AW-HDS, which is deployed along with
the remote section of the Unified CCE over the Wide Area Network (WAN).
The Unified CCMP is a suite of server components that simplify the operations and procedures for performing basic
administrative functions such as managing agents and equipment, and provide a common, web-based user interface within the entire Unified CCE and Unified CCH product set. The Unified CCMP consists of four components:
The Database Server component, which utilizes an application called the Importer to import enterprise data from different data sources into a Microsoft SQL Server management information database.
The database consists of separate database elements that sit on top of the SQL Server and that provide data to different reporting elements:
RDBMS Database (known as the datamart) holds the imported enterprise data.
Reporting Services Database imports and processes data from the datamart so that SQL Server Reporting Services can use it to populate reports.
The Application Server component manages security and failover. It manages security by ensuring that users can view only specific folders and folder content as defined by their security sign-in
credentials. It verifies that a user is valid and then loads the system configuration that applies to that user. It also manages failover, so if one database server fails, the application can automatically retrieve the required data via an alternative database server.
The Web Server component provides a user interface to the platform that allows users to work with report data, and perform administrative functions.
The Data Import Server component is an Extract, Transform and Load (ETL) server for data warehouses. The Data Import component imports the data used to build reports. It is designed to handle high
volume data (facts) such as call detail records as well as data that is rarely changed (dimensions) such as agents, peripherals, and skill groups
If you install these components on more than one server, you normally install the Data Import and Database
components on the Database Server. You usually install the Application and Web components on the Web Application Server.
The Unified CCMP maintains a complete data model of the contact center equipment to which it is connected and
periodically synchronized. In addition to configuration information, for example agents or skill groups, the Unified CCMP can optionally record the events logged by the equipment, such as call records for management information and reporting purposes. The Unified CCMP data model and
synchronization activity allows for items to be provisioned either through the Unified CCMP Web interface or from the standard equipment specific user interfaces.
The Unified CCMP system architecture is shown below. The top half of the diagram is a traditional three tier
application. This includes a presentation layer (an ASP.NET web application), a business logic application server, and a SQL Server database. The lower half of the system architecture is a process orchestration and systems integration layer called the Data Import Server.
Figure 8. Unified CCMP Architecture
The user interface to the Unified CCMP is via a web application you access by a web browser (Microsoft
Internet Explorer). You gain access to the Unified CCMP application through a secure sign-in screen. Every user has a unique username. This user is assigned privileges by the system administrator, which defines the system functions the user can access and perform.
The user interface is time-zone aware and connections to it are secured through HTTPS. The web application is
hosted on the server by Microsoft Internet Information Services (IIS) and so is suitable for lockdown in secure environments.
The Unified CCMP Application Server component provides a secure layer in which all business logic is
implemented. The application server component runs in a separate service and is always hosted with the web server component. The application server component also includes caching to improve performance and audits all actions taken by signed-in users.
The Unified CCMP utilizes Microsoft Reporting Services technology for generating reports. Microsoft Reporting
Services is an integral part of SQL Server Enterprise Edition. The Unified CCMP provides a flexible reporting system in which reports are authored in the industry standard Report Definition Language (RDL).
Data Import Server
The Data Import Server component is an Extract, Transform and Load application for the Unified CCMP. The Data
Import Server component imports the data used in the Unified CCMP. It is designed to handle high volume data (facts), such as call detail records as well as data which is changed irregularly (resources), such as agents, peripherals and skill groups. The Data Import Server component
is also responsible for monitoring changes in the Unified CCMP system and ensuring that those changes are updated onto the Unified ICM/Unified CCE and Unified Communications Manager. The Data Import Server component orchestrates the creation, deletion and update of resources to the
Unified ICM/Unified CCE and Unified Communications Manager. The Microflow Runtime is the heart of the Data Import Server component. It orchestrates systems without resorting to low level programming languages. The Microflow Runtime is a general purpose scripting environment and can
be applied to a wide range of problems. The term microflow describes any modular, reusable and independent unit of business logic. An example microflow might update an agent on the Unified ICM/Unified CCE when changes are made in the Unified Communications Manager web server
Unified CCMP Services
Management Portal, Data Import Server: The Data Import Server is responsible for importing new
dimensions and changes to dimensions such as agents, skill groups, call types and dialed numbers from the Unified CCE. The Data Import Server periodically checks whether there are any new dimensions to import or whether there have been any changes made to dimensions that have
already been imported. This allows for closed-loop management of changes made to dimensions provisioned by the Unified CCMP.
Management Portal, Provisioning Server: The Provisioning Server is responsible for sending
provisioning requests from the Unified CCMP to the Unified CCE. The requests are move, add, change and delete (MACD) operations for the resource types that the Unified CCMP can manage such as creation of new resources, for example a new agent, or new memberships, such as an Agent
to Skill Group membership. These updates are applied via the ConAPI interface.
Figure 9. Unified CCMP Services
The Unified CCMP exposes a rich set of performance (known as PerfMon) counters that you can monitor in real
time to gauge status, performance and health.
On Windows 2008 R2 systems, a shortcut to Performance Monitor is available in the Start Menu > Cisco
Unified CCE Tools folder. The shortcut launches the 64-bit version of PerfMon so that you can easily monitor the Unified CCE 64-bit process.
The Unified ICM and
Unified CCE support outbound campaign dialing through its Outbound Dialing
subsystem (also known as Blended Agent or BA). The Outbound Dialing subsystem
consists of three major components: the Campaign Manager, the Import Process,
and the Dialers.
start with the Import process. The customer uses the Import process to import a
set of outbound calls into the BA database. This data defines what calls are
made and how they are made.
The Campaign Manager
is responsible for running the Outbound Dialing campaigns. It reads the
campaigns from the BA DB. It then distributes the calls to be made to the
Dialers. It takes the results of calls and sends reporting information to the
Unified ICM/Unified CCE central controller where it is recorded in the Unified
ICM/Unified CCE reporting database.
The Dialers make the
calls, performing the two tasks of agent reservation and dialing. The IP Dialer
uses the MR PG to reserve an agent to handle the call and it talks to the
Unified Communications Manager directly using Skinny Call Control Protocol
(SCCP) (Communications Manager phone protocol) to perform the dialing. After
everything is connected it uses the Unified Communications Manager to connect
The Outbound Option
Dialer maximizes the resources in a contact center by dialing several customers
per agent. This component resides on the PG server.
deployments can use the Session Initiation Protocol (SIP) Dialer alongside the
SCCP Dialer. In an Outbound Option deployment that uses the SIP Dialer,
functions such as dialing, call control, and Call Progress Analysis for
Outbound campaigns are handled by the Voice Gateway, and not by the Unified CM.
This increases the number of Outbound agents that a deployment can service on a
PG, and reduces the number of PGs and Dialers customers need to deploy for
larger enterprise systems.
diagram provides a high level view of the Outbound Option components and their
relationship with other Unified ICM components.