Cisco Overview

CH A P T E R 1
Architecture Overview
Last revised on: August 18, 2009
Cisco Unified Contact Center Enterprise (Unified CCE) is part of Cisco Unified Communications
application suite, which delivers intelligent call routing, network-to-desktop Computer Telephony
Integration (CTI), and multi-channel 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 Cisco Unified CCE is an integrated suite of products that includes Cisco Unified Intelligent Contact
Management (Unified ICM), Cisco Unified Communications Manager (Unified CM, Cisco IP
Interactive Voice Response (Unified IP IVR), Cisco Unified Customer Voice Portal (Unified CVP),
Cisco Voice over IP (VoIP) Gateways and Cisco Unified IP phones. Together these products provide
Cisco Unified Communications and contact center solutions to achieve intelligent call routing,
multi-channel 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 ICM to support networking with legacy ACD systems while providing a smooth migration
path to a converged communications platform.
The Cisco Unified CCE solution is designed for implementation in both single-site and multi-site contact
centers. It utilizes 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. Figure 1-1 illustrates a typical Unified CCE setup.
Cisco Unified Contact Center Enterprise 7.5 SRND

OL-16594-06 1-1
Chapter 1 Architecture Overview
Figure 1-1 Typical Unified CCE Deployment
Signaling/CTI
PSTN IP Voice
TDM Voice
Unified CM Cluster
M
V
M M
Unified CCE M M
IP IVR/CVP
IP
143298
Agent
The Cisco Unified CCE solution consists of four primary Cisco software components:
• Unified Communications infrastructure: Cisco Unified Communications Manager (Unified CM)
• Queuing and self-service: Cisco Unified IP Interactive Voice Response (Unified IP IVR) or
Unified CVP
• Contact center routing and agent management: Unified CCE is based on the Unified ICM software.
It includes Call Router, Logger, Peripheral Gateway, Historical Data Server, Administrative
Workstation, and so forth.
• Agent desktop software: Cisco Agent Desktop (CAD), Cisco Toolkit Agent Desktop (CTI OS), or
integrations with third-party customer relationship management (CRM) software through Cisco
Unified CRM Connector.
In addition to these core components, the following Cisco telephony and infrastructure hardware
products may be required for a complete Unified CCE deployment:
• Cisco Unified IP phones
• Cisco voice gateways
• Cisco LAN/WAN infrastructure
The following sections discuss each of the software components in more detail and describe the data
communications between each of these components. For more information on a particular product, refer
to the specific product documentation available online at
http://www.cisco.com

1-2 OL-16594-06
What's New in This Chapter
What's New in This Chapter

Table 1-1 lists the topics that are new in this chapter or that have changed significantly from previous
releases of this document.
Table 1-1 New or Changed Information Since the Previous Release of This Document
New or Revised Topic Described in:

Agent interfaces Unified CCE Agent Options, page 1-10
Agent phones Agent Phones, page 1-4
Logical Partitioning and toll bypass Agent Phones in Countries with Toll-Bypass
Regulations, page 1-30
Removed reference to Unified IP Queue Manager Various sections
Unified Intelligence Suite Cisco Unified Intelligence Suite, page 1-16
Unified System Contact Center Enterprise Unified System CCE, page 1-21
Video queuing and agent support in Unified CVP Cisco Unified Customer Voice Portal (Unified
CVP), page 1-4
Cisco Unified Communications Manager

Cisco Unified Communications Manager (Unified CM, formerly Cisco Unified CallManager) is a
software application that controls the voice gateways and IP phones, thereby providing the foundation
for a Voice over IP (VoIP) solution. Unified CM runs on Cisco Media Convergence Servers (MCS). The
software running on a server is referred to as a Unified CM server. Multiple Unified CM servers can be
grouped into a cluster to provide for scalability and fault tolerance. Unified CM communicates with the
gateways using standard protocols such as H.323, Media Gateway Control Protocol (MGCP), and
Session Initiation Protocol (SIP). Unified CM communicates with the IP phones using SIP or Skinny
Call Control Protocol (SCCP). For details on Unified CM call processing capabilities and clustering
options, refer to the latest version of the Cisco Unified Communications Solution Reference Network
Design (SRND) guide, available at:
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides
_list.html
A single Unified CM subscriber server is capable of supporting hundreds of agents. In a fault-tolerant
design, a Unified CM 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 the chapter on Sizing Cisco Unified Communications Manager
Servers, page 11-1.
Typically, when designing a Unified CCE solution, you first define the deployment scenario, including
arrival point(s) for voice traffic and the location(s) of the contact center agents. After defining the
deployment scenario, you can determine the sizing of the individual components within the Unified CCE
design for such things as how many Unified CM servers are needed within a Unified CM 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 ICM software, how many Unified IP IVR or Unified CVP
servers are needed, and so forth.

OL-16594-06 1-3
Cisco Unified Customer Voice Portal (Unified CVP)
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 being used in pure contact center deployments, Cisco recommends provisioning a maximum
of four T1/E1 interfaces to ensure that the call processing capacity of the voice gateway is satisfactory.
Agent Phones
For a list of supported agent phones, refer to the Cisco Unified Contact Center Enterprise (Unified CCE)
Software Compatibility Guide, available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_device_support_tables_list.h
tml
The following design considerations apply to the Cisco Unified IP Phone 6900 Series:
• The IP Phone Agent feature is not currently supported.
• Join and Direct Transfer policy for the same line and across lines should be disabled in the
Unified CM phone administration page for the agent phones.
• Outbound campaign capability requires Cisco Unified Contact Center Enterprise 7.5(6) or later
release.
• Unified CM silent monitoring and recording and Remote Silent Monitoring (RSM) is not supported
for Cisco Unified IP Phone 6900 Series agent phones at this time.
Cisco Unified Customer Voice Portal (Unified CVP)

Unified CVP is a software application running 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 ICM software for application
control. It interfaces with Unified ICM using the VRU Peripheral Gateway Interface. The Unified ICM
scripting environment controls the execution of building-block functions such as play media, play data,
menu, and collect information. The Unified ICM 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 ICM 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 via the Cisco Unified ICM software.

1-4 OL-16594-06
Cisco Unified IP Interactive Voice Response (Unified IP IVR)
Unified CVP also provides a queuing platform for the Unified CCE solution. Telephone 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, he or she is able to push videos to a caller from the agent desktop application. For more
information, refer to the latest version of the Cisco Unified Customer Voice Portal SRND, available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_implementation_design_gui
des_list.html
Cisco Unified IP Interactive Voice Response (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 like Unified CVP because it is behind Unified CM
and under the control of the Unified ICM software via the Service Control Interface (SCI). When an
agent becomes available, the Unified ICM 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 via the Java Telephony Application
Programming Interface (JTAPI), and the Unified IP IVR communicates with Unified ICM via the
Service Control Interface (SCI) with a VRU Peripheral Gateway or System Peripheral Gateway.
The chapter on Sizing Call Center Resources, page 9-1 discusses how to determine the number of IVR
ports required. For deployments requiring complete fault tolerance, a minimum of two Unified IP IVRs
is required. The chapter on Design Considerations for High Availability, page 3-1, provides details on
Unified CCE fault tolerance.
Cisco Unified Intelligent Contact Management (Unified ICM)

Software
The Cisco Unified ICM software provides contact center features in conjunction with Unified CM and
the IP Queuing platform. Features provided by the Unified ICM software include agent state
management, agent selection, call routing and queue control, IVR control, CTI Desktop screen pops, and
contact center reporting. Unified ICM software for Unified Contact Center Enterprise (Unified CCE)
runs on Cisco MCS servers or exact equivalents, unless otherwise specified in the chapter on Sizing
Unified CCE Components and Servers, page 10-1, and the Hardware and System Software Specification
Guide. It relies on the Microsoft Windows 2003 operating system software and Microsoft SQL Server
2005 database management system. The supported servers can be single, dual, or quad Pentium CPU
servers in single or multi-core variations with varying amounts of RAM. This variety of supported
servers allows the ICM software to scale and to be sized to meet the needs of the deployment
requirements. The chapter on Sizing Unified CCE Components and Servers, page 10-1, provides details
on server sizing.

OL-16594-06 1-5
Cisco Unified Intelligent Contact Management (Unified ICM) Software
Basic Unified CCE Call and Message Flow

Figure 1-2 shows the flow of a basic Unified CCE call using Unified IP IVR. In this scenario, all of the
agents are assumed to be not ready when the call arrives, so the call is routed by the ICM to the
Unified IP IVR. While the call is connected to the Unified IP IVR, call queuing treatment (for example,
announcements or music) is provided. When an agent becomes available, the ICM directs the
Unified IP IVR to transfer the call to that agent's phone. At the same time the call is being transferred,
the ICM sends the caller data, such as Automatic Number Identification (ANI), Directory Number (DN),
and any CTI/call data variables, to the agent desktop software.
Figure 1-2 Basic Unified CCE Call Flow Using Unified IP IVR
IP IVRs ICM
7 9
Public
network 7 6 3
10 4 7
5
1
5 10 9
M
M 5
V
2 Unified CM 8
cluster
10
8 Agent available IP IP IP
IP voice
9 Screen pop TDM voice
Call control and
11 Call answered CTI data
143300
IP phones and agent desktops
The call flow in Figure 1-2 is as follows:

1. Call delivered from PSTN to voice gateway.
2. Voice gateway queries Unified CM for a destination.
3. JTAPI Route Request sent to ICM.
4. ICM runs routing script. No available agent found, so Unified IP IVR label returned from routing
script.
5. ICM instructs Unified CM to transfer call to Unified IP IVR.
6. Unified IP IVR notifies ICM that call has arrived.
7. ICM instructs Unified IP IVR to play queue announcements.
8. Agent becomes ready (completed previous call or just went ready).
9. ICM sends call data to selected agent screen and instructs the Unified IP IVR to transfer the call to
the agent phone.
10. Unified IP IVR transfers the VoIP voice path to selected agent phone.

1-6 OL-16594-06
11. Call is answered by agent.

Figure 1-3 shows the flow of a basic Unified CCE call using Unified CVP.
Figure 1-3 Basic Unified CCE Call Flow Using Unified CVP
Caller
CVP ICM
1 4 6
PSTN 2 3
8
1
8 7
M
M
V Unified CM
cluster
Ingress
Gateway
5 IP IP IP
IP voice
TDM voice
9 Call control and
CTI data
143301
IP phones and agent desktops
The call flow in Figure 1-3 is as follows:

1. Call is delivered from PSTN to ingress voice gateway.
2. Voice gateway sends SIP or H. 225 request to Unified CVP for the incoming call.
3. Unified CVP sends route request to Unified ICM, requesting instructions.
4. Unified ICM runs routing scripts and instructs Unified CVP for prompting and announcements.
5. Agent becomes ready (completed previous call or just went ready).
6. Unified ICM instructs Unified CVP to send the call to the available agent on Unified CM.
7. Unified ICM sends call data to selected agent screen.
8. Unified CVP transfers the VoIP voice path to the selected agent phone on Unified CM.
9. Call is answered by the agent.
Unified ICM Software Modules

The Cisco Unified ICM software is a collection of modules that can run on multiple servers. The amount
of software that can run on one server is primarily based upon busy hour call attempts (BHCA) and the
size of the server being used (single, dual, or quad CPU). Other factors that impact the hardware sizing

OL-16594-06 1-7
are the number of agents, the number of skills per agent, the number of Unified IP IVR ports, the number
of VRU Script nodes in the ICM routing script, Extended Call Context (ECC) usage, and which statistics
agents need at their desktops.
The core Unified ICM software modules are:
• Call Router
• Logger
• Agent Peripheral Gateway (PG)
• Unified CM Peripheral Interface Manager (PIM)
• IP IVR or CVP VRU PIM
• CTI Server
• CTI Object Server (CTI OS)
• Administrative Workstation (AW) or Real-Time Distributor
• Historical Data Server (HDS)
• WebView Reporting Server
The Call Router is the module that makes all routing decisions on how to route a call or customer contact.
The Logger is the database server that stores contact center configuration and reporting data. The
Unified CM PIM is the process that interfaces to a Unified CM cluster via the JTAPI protocol. The VRU
PIM is the process that interfaces to the Unified IP IVR or Unified CVP via the Service Control Interface
(SCI) protocol. The CTI Server is the process that interfaces to the CTI OS, the CTI Object Server to
which Agent Desktops connect.
Each ICM software module can be deployed in a redundant fashion. When a module is deployed in a
redundant fashion, we refer to the two sides as side A and side B. For example, Call Router A and Call
Router B are redundant instances of the Call Router module (process) running on two different servers.
This redundant configuration is also referred to as duplex mode, whereas a non-redundant configuration
is said to be running in simplex mode. (Simplex mode is not supported for production environments.)
When processes are running in duplex mode, they are not load-balanced. 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 Call Router. The Call Routers run in synchronized execution
across the two servers, which means both sides of the duplex servers process every call. In the event of
a failure, the surviving Call Router will pick up the call mid-stream and continue processing in real-time
and without user intervention.
Other components in the ICM, such as the Peripheral Gateways, 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 said to be running in simplex mode and will continue to function this way
until the redundant/duplex side is restored to service, then it will automatically return to duplex
operation.
Another important component of the architecture is the Historical Data Server (HDS). This is
instantiated by installing a Real-time Distributor with the HDS option to enable this server to maintain
a historical reporting database that is synchronized from the Logger to enable the latter to maintain a
limited set of records for optimum operation. The HDS follows an n+1 scalability architecture with each
HDS, choosing a Logger side (A or B) as its preferred and primary data source. The HDS is a required
component for historical reporting by WebView or the Unified Intelligence Suite. WebView can be
co-resident with the HDS or deployed in standalone web server mode to achieve higher scalability in
terms of reporting users that need access to the application for real-time and historical reporting. Refer
to the chapter on Sizing Unified CCE Components and Servers, page 10-1, for more details.

1-8 OL-16594-06
The Unified ICM software uses the concept of a customer instance to group all of the components under
a single Call Router and Logger or Central Controller. The instance relationship ensures that all of the
components related to the same system are joined under a single logical Unified CCE IP ACD. This
concept is used only to support multiple customer instances in the Unified Contact Center Hosted
(Unified CCH) that supports multi-tenant or shared servers that manage multiple customer instances. All
Unified CCE systems are deployed as a single instance (using the same instance number in ICM Setup)
across all the Unified ICM components.
Combined Routers and Loggers are often called the ICM Central Controller. When the Router and
Logger modules run on the same server, the server is referred to as a Rogger. When the Call Router,
Logger, and Peripheral Gateway modules run on the same server, the server is referred to as a Progger.
In lab environments, the system Administrative Workstation (AW) can also be loaded onto the Progger
to create a server known as a Sprawler configuration (also known as All-in-One configuration for Unified
System CCE); however, this configuration is approved only for lab use and is not supported in customer
production environments.
For each Unified CM cluster in your Unified CCE environment, you need a Unified CM PIM on a
separate Peripheral Gateway and physical server. For deployments requiring multiple PIMs for the same
Unified CM cluster, you need a separate PG and physical server for each PIM. Starting from
Unified CCE 7.5, deployments with multiple Unified CM PIMs and with CTI OS do not require a
separate PG or separate physical server.
For each Unified CM Peripheral Gateway, you need one CTI Server and one CTI OS to communicate
with the desktops associated with the phones for that Unified CM cluster. For each Unified IP IVR or
CVP Call Server, you need one VRU PIM. The server that runs the Unified CM PIM, the CTI Server,
and the CTI OS is referred to as an Agent Peripheral Gateway (APG). VRU PIMs could also be part of
the Agent PG in the case of the Generic PG or System PG. Often, the Unified CM PIM, the CTI Server,
the CTI OS, and multiple VRU PIMs will 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. Figure 1-4 shows the
communications among the various PG software processes.

OL-16594-06 1-9
Unified CCE Components, Terminology, and Concepts
Figure 1-4 Communications Among Peripheral Gateway Software Processes
ICM central controller Unified CCE Agent

desktops
PG server
PG 1
IP phones
PG Agent
IP
CTI OS server IP
IP
Unified CM
Cluster IP
CTI server
M
JTAPI
CCM PIM M
IP IVR 1 JTAPI
M
OPC SCI JTAPI
IVR 1 PIM
IP IVR 2 PSTN
V
SCI
IVR 2 PIM IP voice
TDM Voice
132072
CTI/Call
control data
In larger, multi-site (multi-cluster) environments, multiple PGs are usually deployed. Each PG requires
a local Unified CM node. When multiple Unified CM clusters are deployed, the ICM software makes
them all appear to be part of one logical enterprise-wide contact center with one enterprise-wide queue.

This section describes the major components and concepts employed in a Unified CCE solution.
Unified CCE Agent Options

Cisco offers the following interfaces for Unified CCE agents (see Figure 1-5):
• 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 Toolkit
The CTI Toolkit provides a software toolkit for building custom desktops, desktop integrations into
third-party applications, or server-to-server integrations to third-party applications.

1-10 OL-16594-06
• CRM Connectors
CRM Connectors provide pre-built integrations into the major CRM applications such as SAP,
Siebel, Salesforce, Microsoft CRM, and Peoplesoft.
Figure 1-5 Variety of Agent Interfaces for Unified CCE
188798
Cisco Agent Desktop

Cisco Agent Desktop (CAD) is an out-of-the-box desktop application that enables the agent to perform
agent state control (including login, logout, ready, not ready, and wrap up) and call control (including
answer, release, hold, retrieve, transfer, conference, make call). CAD requires use of a Cisco Unified IP
phone or Cisco IP Communicator (softphone). Other phones can be used as well using the Mobile Agent
option (see Cisco Unified Mobile Agent, page 1-21, for more details). Other features, such as an
integrated chatting application, call recording, and workflow automation, may also be included. (See
Figure 1-6.)

OL-16594-06 1-11
Figure 1-6 Cisco Agent Desktop
Through integration with Cisco Unified Presence, contact center agents and supervisors using CAD can
see subject matter experts (SMEs) who use Cisco Unified Presence Communicator. They can initiate chat
sessions with SMEs for consultation on various customer questions or issues and, if needed, can initiate
a transfer or a conference to achieve first-caller resolution. The agent or supervisor also has the
capability to extend the call data received using Instant Messaging.
CAD also comes in a browser-based edition as a thin client application, which allows more flexibility in
deployment and operation with the same rich set of capabilities highlighted above.
CAD also provides IP Phone Agent as an agent interface that does not require a desktop application. It
is implemented as an XML application that is rendered on the screen of the IP phone and controlled
through the softkeys and buttons on the phone. The XML application performs agent state control, while
call control is handled through the normal phone softkeys and buttons. Other enhanced features,
including silent monitoring, call recording, screen pop, and call center statistics, are also available
through this interface.
Agents using the Cisco Agent Desktop, the browser edition, or IP Phone Agent can be managed by a
supervisor using the Cisco Supervisor Desktop, which enables the supervisor to monitor and control
agent state, monitor some call center statistics, monitor agents silently, barge in on agents, intercept
calls, and initiate agent call recording.
Cisco Toolkit
Cisco Toolkit is a software development kit that provides the capability to build a customized agent
desktop, customize the shipped custom desktop samples, or integrate a toolbar into a third-party
application. Desktop applications built using CTI Toolkit interact with the CTI Object Server (CTI OS).
The APIs available in CTI toolkit include COM/C++, Java, and .NET. A Cisco toolkit desktop can
provide the same agent state controls and call controls as CAD. Cisco toolkit desktops require the agent
to use a Cisco Unified IP Phone or Cisco IP Communicator (software phone). Other phones can be used
as well using the Mobile Agent option (see Cisco Unified Mobile Agent, page 1-21, for more details).

1-12 OL-16594-06
Cisco Toolkit also provides the capabilities to develop a custom supervisor desktop. Supervisory
functions enable a supervisor to monitor and control agent state, monitor some call center statistics,
monitor agents silently, barge in on agents, intercept calls, and initiate agent call recording. Note that
supervisors using a supervisor desktop based on CTI Toolkit cannot perform these functions for agents
using Cisco Agent Desktop.
The section on CTI Object Server (CTI OS), page 1-13, provides some more details on the components
and interfaces in CTI Toolkit.
CRM Connectors
Cisco offers pre-built, certified CRM Connectors for a number of major CRM packages including SAP,
Siebel (using CTI OS driver), Salesforce.com, Microsoft Dynamics CRM, and Peoplesoft. 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 using a third-party CRM user interface connected through a CRM Connector can be supervised
using a CTI Toolkit-based supervisor desktop.
For more information about desktop selection and design considerations, see Unified Contact Center
Enterprise Desktop, page 4-1.
CTI Object Server (CTI OS)

The Computer Telephony Integration Object Server (CTI OS) is Cisco's next-generation customer
contact integration platform. CTI OS combines a powerful, feature-rich server and an object-oriented
software development toolkit to enable rapid development and deployment of complex CTI applications.
Together with the Cisco CTI Server Interface, CTI OS Server and CTI OS Client Interface Library (CIL)
create a high-performance, scalable, fault-tolerant CTI architecture.
The CTI OS application architecture consists of three tiers:
• The CIL is the first tier, providing an application-level interface for developers. This is part of the
CTI Toolkit described above.
• The CTI OS Server is the second tier, providing the bulk of the event and request processing and
enabling the object services of the CTI OS system.
• The Cisco CTI Server is the third tier, providing the event source and the back-end handling of
telephony requests. CTI OS Server connects to CTI Server for its event and request handling. CTI
Server also provides an open published protocol for CTI integration that is sometimes useful for
server-to-server integrations. This is part of the CTI Toolkit as well.
Fault-tolerance is provided 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.
CTI OS connects customer contact servers such as CTI Server with client applications. (See Figure 1-7.)
The connection to a contact server is established through a CTI Server Driver library. This library
receives state change events on agents, and calls. Those events are sent to the Service Broker, which
determines what objects to update. These objects generate update events to the Event Notification
Engine, which then notifies all subscribing clients.

OL-16594-06 1-13
Figure 1-7 Generalized View of Information Flow in CTI OS
CTI Server
CTI OS
CTI Server Driver Lib
Service Broker
Object Map
Service Call Object
Agent Object
Request Service Event Notification

Engine
Client Connection
143303
CTI OS Client
The type of messages received by the client application depends on the connection mode. Clients may
connect in agent or monitor mode. In agent mode, the client receives events specific to that agent (calls
delivered or originated on the agent's instrument, agent state changes, and skill group statistics). In
monitor mode, the client provides a message filter expression, and the expression selects the types of
messages that the client will receive.
Clients may initiate requests such as answering or dropping a call. The request is received by CTI OS
through the client connection interface. Requests are brokered by the request service which forwards the
request to the correct object, which then forwards it to the CTI Server.
Administrative Workstation
The Administrative Workstation (AW) provides a collection of administrative tools for managing the
ICM software configuration. The two primary configuration tools on the AW are the Configuration
Manager and the Script Editor. The Configuration Manager tool is used to configure the ICM database
to add agents, add skill groups, assign agents to skill groups, add dialed numbers, add call types, assign
dialed numbers to call types, assign call types to ICM routing scripts, and so forth. The Script Editor tool
is used to build ICM routing scripts. ICM routing scripts specify how to route and queue a contact (that
is, the script identifies which agent should handle a particular contact).
For details on the use of these tools, refer to the Cisco Unified Contact Center Administration Guide,
available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1844/prod_maintenance_guides_list.html

1-14 OL-16594-06
The AW is the only software module that must run on a separate server from all of the other Unified CCE
software modules. An AW can be deployed in the same location as, or remote from, the ICM Central
Controller. Each AW is independent of other AWs, and redundancy is provided by deploying multiple
AWs.
Some AWs communicate directly with the ICM Central Controller, and they are called Distributor AWs.
(See Figure 1-8.) An ICM deployment must have at least one Distributor AW. Additional AWs
(distributors or clients) are also allowed for redundancy (primary and secondary distributors) or for
additional access by the AW clients in a site. At any additional site, at least one distributor and multiple
client AWs can be deployed; however, client AWs should always be local to their AW distributor.
Figure 1-8 Communication Between ICM Central Controller and Distributor AW
Central Controller AW Distributor with HDS
Real-Time
Router WebView
Data
Config and AWDB

Logger
Historical Data and
HDS
143304
Client AWs communicate with a Distributor AW to view and modify the ICM Central Controller
database and to receive real-time reporting data. Distributor AWs off-load the Central Controller (the
real-time call processing engine) from the task of constantly distributing real-time contact center data to
the client AWs.
AWs can be installed with the following software options:
• Historical Data Server (HDS)
• WebView Server
• Internet Script Editor Server
• Web Administration Tool Server (Unified System CCE deployments only)
The Historical Data Server (HDS) is the database used for longer-term data storage and reporting.
WebView Server is the reporting server that can be installed either on an HDS server or on a standalone
server. For information on the reporting deployment options, refer to the chapters on Sizing Unified CCE
Components and Servers, page 10-1, and Securing Unified CCE, page 8-1.
The WebView Server option provides browser-based reporting. This option enables reporting to be done
from any computer with a browser. The Internet Script Editor Server can be installed only on a
Distributor AW, and it provides an HTTPS (default protocol) connection for Script Editor clients. The
Web Administration Tool Server provides a browser-based configuration tool for Unified System CCE,
and it can be installed only on a Distributor AW (called an Administration and WebView Reporting
server in Unified System CCE).
The reason for requiring the AW to run on a separate server for production systems is to ensure that
complex reporting queries do not interrupt the real-time call processing of the Call Router and Logger
processes. For lab or prototype systems, the AW (with the WebView Server option) can be installed on

OL-16594-06 1-15
the same server as the Call Router and Logger. If the AW is installed on the same server as the Logger,
then HDS is no longer required because a complete copy of the Logger database is already present on
the server.
For more details on the design and configuration of the AWs, refer to the ICM product documentation
available online at Cisco.com.
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:
• WebView — the reporting user interface
• Reporting Data — contained on a Distributor AW
– Administrative Workstation Database (AWDB) — contains real-time and configuration data
– Historical Data Server (HDS) — contains the historical data
WebView
The reporting user interface is a web-based application referred to as WebView. WebView performs the
basic operations of gathering user input, querying the databases and presenting the requested data.
Additionally, WebView is a full-featured reporting application server that provides functions such as
authentication, storing users' favorite reports, launching scheduled reports, and so forth. WebView can
be installed on an AW or, to increase scalability, it can be installed on a standalone server. The WebView
architecture is described in the WebView Installation and Administration Guide, available at
http://www.cisco.com/en/US/products/sw/custcosw/ps4145/prod_installation_guides_list.html
WebView comes with a number of categories of report templates. Each category presents different views
of the data generated by call center activity. To determine which templates are best suited for your
reporting requirements, refer to the WebView Template Reference Guide, available at
http://www.cisco.com/en/US/products/sw/custcosw/ps4145/products_user_guide_list.html
Cisco Unified Intelligence Suite

The Cisco Unified Intelligence Suite is an advanced reporting option that can be substituted for, or used
in conjunction with, WebView. This platform is a web-based application offering many Web 2.0 features,
greater scalability, better performance, and advanced features such as the ability to integrate data from
other Cisco Unified Communications products or third-party data sources.
The Cisco Unified Intelligence Suite consists of two components: Intelligence Server and the Archiver.
Both of these components require a separate and dedicated server.
The Intelligence Server is a web-based reporting application that provides real-time and historical
reports and dashboards as well as several developer tools for extending the platform and customizing the
user experience.
The Archiver is an MSSQL data repository containing a normalized data schema and the infrastructure
of tables and processes that will enable customers to Extract, Transform, and Load (ETL) data from any
data source.
A unique ETL process is created for each data source and is referred to as a Data Connector. Refer to
the Archiver installation and configuration guide for more information on Data Connectors.

1-16 OL-16594-06
Reporting Data
The data sources for WebView reports reside on a Distributor AW. For a detailed description of the
reporting data flow and the concepts introduced here, refer to the WebView Installation and
Administration Guide, available at
Administrative Workstation Database (AWDB)
The AWDB stores real-time and configuration data. Real-time reports combine these two types of data
to present a near-current transient snapshot of the system. Real-time reports refresh on a regular interval
so that the most current data is always displayed.
Historical Data Server (HDS)
The HDS stores historical data. Historical reports query the AWDB to gather configuration data and join
that data with data found in the HDS. Historical reports are typically available in two forms: reports
generated on the half hour and reports generated daily. Half-hour reports should be used to report on
periods of time less than one day in length.
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 move/add/modify phones,
agents, skill groups, 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 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
Support Tools
Cisco Support Tools is an application that contains a suite of utilities that allow you to manage and
troubleshoot servers that run a broad range of Cisco Unified product software components.Through
Support Tools, you can troubleshoot configuration and performance problems on these systems from any
machine running a supported version of Windows and Internet Explorer on your network that can access
the Support Tools Server.
Access to utilities in the Support Tools suite is through a browser-based interface – the Support Tools
Dashboard – installed on the Support Tools Server. Levels of security control both access to the
Dashboard and the ability to use specific tools once logged in. In low bandwidth conditions (for example,
via dial-up access) or when Web browsing is otherwise impractical, many Support Tools utilities can also
be accessed and run via the command line interface.

OL-16594-06 1-17
JTAPI Communications
In order for JTAPI communications to occur between Unified CM and external applications such as the
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 upon startup of the Unified IP IVR, the JTAPI user ID and
password are used to log in to Unified CM. This login process by the application (Unified CM PIM or
Unified IP IVR) establishes the JTAPI communications between the Unified CM cluster and the
application. A single JTAPI user ID is used for all communications between the entire Unified CM
cluster and the ICM. A separate JTAPI user ID is also 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 the ICM application and two JTAPI user IDs for the two
Unified IP IVRs.
The Unified CM software includes a module called the CTI Manager, which is the layer of software that
communicates via JTAPI to applications such as the ICM 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/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 the ICM. When a new call arrives at this voice gateway and needs
to be routed by the ICM, node 1 sends an intra-cluster message to node 2, which will send a route request
to the ICM to determine how the call should be 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 could each communicate with
different CTI Managers (nodes) or they could all communicate with the same CTI Manager (node).
However, each communication uses a different user ID. The user ID is how the CTI Manager keeps track
of 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 on failover, refer to the chapter on Design Considerations for High
Availability, page 3-1.
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
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 communication within a few seconds. When
a new call arrives, Unified CM requests routing instructions from the ICM. For example, when
Unified CM receives the routing response from the ICM, Unified CM attempts delivery of the call to the
agent phone by instructing the phone to begin ringing. At that point, Unified CM notifies the ICM that

1-18 OL-16594-06
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, the ICM 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 the ICM JTAPI user ID, and this enables Unified CM to generate a
route request to the ICM 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. In a Unified CCE environment, the IP phones are associated with the ICM JTAPI user
ID. 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
the ICM to monitor or control that phone. If the device has not been associated with the ICM JTAPI user
ID, then the agent login request will fail.
Because the Unified IP IVR also communicates with Unified CM using the same JTAPI protocol, these
same three types of communication also occur with the Unified IP IVR. Unlike the ICM, the
Unified IP IVR provides both the application itself and the devices to be monitored and controlled.
The devices that the ICM monitors and controls are the physical phones. The Unified IP IVR does not
have real 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 will send 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
(via JTAPI routing control) which CTI Port (device) should handle the call. Assuming the
Unified IP IVR has an available CTI Port, the Unified IP IVR will respond to the Unified CM routing
control request with the Unified CM device identifier of the CTI Port that is going to handle that call.
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. These
scenarios are examples of device and call control performed by the Unified IP IVR.
When a caller releases the call while interacting with the Unified IP IVR, the voice gateway detects the
caller release and notifies Unified CM via H.323 or Media Gateway Control Protocol (MGCP), which
then notifies the Unified IP IVR via 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 via JTAPI. These
scenarios are examples of device and call monitoring performed by the Unified IP IVR.
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 would have 300 CTI ports. Half of the CTI ports (150) would be associated with
JTAPI user Unified IP IVR #1, and the other 150 CTI ports would be 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 should be done by the ICM (even if you have only one
Unified IP IVR and all calls require an initial IVR treatment). Doing so will ensure proper Unified CCE
reporting. For deployments with multiple Unified IP IVRs, this routing practice also allows the ICM to
load-balance calls across the multiple Unified IP IVRs.

OL-16594-06 1-19
Multichannel Subsystems
The ICM has the capability to provide a multichannel contact center that includes email and web
collaboration. It does this through interactions with Cisco E-Mail Manager (CeM) and Cisco
Collaboration Server (CCS). (See Figure 1-9.). Starting from Cisco Unified CCE 7.2, Cisco Interaction
Manager (CIM), which includes E-mail Interaction Manager (EIM) and Web Interaction Manager
(WIM), should be deployed with new installations in order to provide multichannel capabilities. For
more details, refer to the Unified CCE Software Compatibility Guide, available on
http://www.cisco.com.
With CeM and CCS, ICM has three integration points that are used for its multimedia subsystems:
• Media Routing (MR) interface — The MR interface is through the MR Peripheral Gateway (PG).
Cisco E-Mail Manager and Cisco Collaboration Server use this interface to tell the ICM that they
have a new task that needs to be serviced, and they would like an agent to be assigned.
• Agent Reporting and Management (ARM) interface — The ARM interface is through the CTI server
on the PG to which a given agent is assigned. Cisco E-Mail Manager and Cisco Collaboration Server
use the ARM interface to tell the ICM when the agent is working on a task in their subsystem, and
to monitor the status of agents in the ICM.
• Configuration Application Programming Interface (ConAPI) — The ConAPI is through the
Administrative Workstations (AWs). Cisco E-Mail Manager and Cisco Collaboration Server use this
interface to ensure that their configuration and the ICM's configuration are in sync. The ConAPI is
used to create skill groups, configure agents, and create ICM services for routing. This API is
internal to the Cisco Unified CCE solution and cannot be used for third-party customizations.
Figure 1-9 Multichannel Subsystem
Central Controller
Administrative
MR PG Agent PG
Workstation
MR ARM ConAPI
CeM Media Blender
Firewall
143305
CCS
Cisco E-Mail Manager

Cisco E-Mail Manager provides inbound and outbound email services for agents. Cisco E-Mail Manager
enables incoming email to be processed with a rules engine, categorized into folders for processing, and
queued to agents. When emails are assigned to agents, the agents are able to respond to them, with Cisco
E-Mail Manager providing storage of the conversation and tracking of multi-leg responses.
Cisco E-Mail Manager has the ability to escalate overdue emails to be synchronously routed through the
ICM router so that they get attention right away. It also has the ability to do some email routing itself.

1-20 OL-16594-06
Cisco Collaboration Server

The Cisco Collaboration Server provides web-based collaboration and chat capabilities to agents. These
capabilities can be used independently or as a supplement to voice calls. Cisco Collaboration Server
connects to the ICM through its Media Blender component. This component is required because Cisco
Collaboration Server itself must sit outside the corporate firewall to allow for incoming connections
from customers.
When doing blended voice and collaboration sessions with IP-based agents, Media Blender talks to the
Media Routing PG to route calls. When doing blended voice and collaboration with TDM-based agents,
Media Blender talks directly to the TDM switch to queue phantom calls to agents.
Cisco Collaboration Server provides desktop user interfaces for both callers and agents. These
components allow the callers and agents to collaborate using a variety of media, including chat, web
page sharing, advanced web page sharing (using the Dynamic Content Adapter), application sharing,
white boarding. Cisco Collaboration Server also provides an API for developing custom media.
Cisco Collaboration Server can use its own internal routing engine or it can use the ICM's routing engine
to assign incoming calls to agents. Cisco Collaboration Server provides the ability, through its
multi-session chat desktop, for agents to work with more than one caller at a time.
Cisco Interaction Manager

Cisco Interaction Manager provides an integrated suite of interaction channels that include Cisco
Unified E-mail Interaction Manager (Unified EIM) and Cisco Unified Web Interaction Manager (Unified
WIM).
There is a design guide specifically for the Cisco Interaction Manager platform, Cisco Unified Web and
E-Mail Interaction Manager Solution Reference Network Design (SRND) Guide For Unified Contact
Center Enterprise, Hosted, and ICM, available at
http://www.cisco.com/en/US/products/ps7236/products_implementation_design_guides_list.html
Cisco Unified Outbound Option

Agents can handle both inbound and outbound contacts, which helps in optimizing contact center
resources. The Cisco Unified Outbound Option enables the multi-functional 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.
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 chapter on Cisco Unified Mobile
Agent, page 6-1.
Unified System CCE

Cisco Unified System Contact Center Enterprise (Unified System CCE) is a deployment model that
simplifies installation and configuration by using three predefined configurations for Unified CCE that
eliminate unnecessary Unified ICM and non-Unified CCE deployment options. Unified System CCE

OL-16594-06 1-21
utilizes a single installer to simplify installation and configuration, and it provides web-based
administration. Configuration of Unified System CCE is further simplified by removing Services,
Translation Routes, Device Targets, Labels, Sub Skill Groups, and Agent IDs. If desired, Agent IDs can
be configured in Unified System CCE 7.2(2) and later releases.
Unified System CCE supports new installations and upgrades from previous System CCE releases. It
continues to provide fault tolerance through the duplex operation on the Central Controller and
Agent/IVR Controller. Unified System CCE can connect to a parent Unified ICM, and the connection is
made between the child Unified CCE System PG and the parent Gateway PG.
Unified System CCE consists of the following internal components, illustrated in Figure 1-10 and
Figure 1-11:
• Central Controller — Includes Call Router and Logger (SQL Server must be pre-installed).
• Agent/IVR Controller — Agent Peripheral Gateway (Unified CCE System PG), CTI Server, and
CTI Object Server. Optionally, beginning with Unified System CCE 7.5(1), VRU Peripheral
Gateway for Unified CVP.
• Administration and WebView Reporting — Distributor Administrative Workstation (AW),
WebView, Historical Data Server (HDS), and Internet Script Editor Server (Requires Microsoft
Internet Information Service (IIS) and SQL Server pre-installed).
• Unified CM — Unified System CCE connects to single a Unified CM cluster.
• Unified IP IVR or Unified CVP — Queue and prompting platform for Unified System CCE.
• Optional Components:
– Outbound Controller — Dialer and Media Routing Peripheral Gateway for Outbound Option
(Outbound Controller can be co-located on the Agent/IVR Controller in Unified
System CCE 7.5(1)).
– Multichannel Controller — Media Routing Peripheral Gateway for Cisco Interaction Manager
(CIM).
– Unified CCE gateway to Unified ICM
– Cisco Agent Desktop Services (co-located with the Agent Peripheral Gateway)
– Unified Contact Center Management Portal (Unified CCMP) — Co-located with the
Administration and WebView Reporting machine or installed separately on a standalone server

1-22 OL-16594-06
Figure 1-10 Unified System CCE with IP IVR
Optional
CCMP
Admin Browser Admin and Reporting Optional
Outbound
WebView Browser
Controller
Central Controller
Multichannel
Controller
Agent Desktop Agent/IVR Controller CAD Services
143306
Unified CM Cluster
IPIVR
Figure 1-11 Unified System CCE with Unified CVP
Optional
CCMP
Admin Browser Admin and Reporting

Optional
WebView Browser
Outbound Controller
CVP Controller Central Controller

Multichannel Controller
CVP CAD Services
Admin Desktop Agent/IVR Controller
Unified CM Cluster
188792

OL-16594-06 1-23
Unified ICM Routing Clients
For more information on Unified System CCE, see the chapter on Deployment Models, page 2-1.

A Unified ICM routing client is anything that can generate a route request to the Unified ICM Central
Controller. The Unified CM PIM (representing the entire Unified CM cluster) and each
Unified IP IVR/Unified CVP PIM are routing clients. Routing clients generate route requests to the
Unified ICM Central Controller. The Unified ICM Central Controller then executes a routing script and
returns a routing label to the routing client. A redundant PIM is viewed as a single logical routing client,
and only one side of a PIM is active at any point in time. In a Unified CCE deployment with one
Unified CM cluster (with any number of nodes) and two Unified IP IVRs, three routing clients are
required: the Unified CM PIM and the two Unified IP IVR/Unified CVP PIMs.
The public switched telephone network (PSTN) can also function as a routing client. The Unified ICM
supports a software module called a Network Interface Controller (NIC), which enables the Unified ICM
to control how the PSTN routes a call. Intelligently routing a call before the call is delivered to any
customer premise equipment is referred to as pre-routing. Only certain PSTNs have NICs supported by
the Unified ICM. For a detailed list of PSTN NICs and details on Unified ICM pre-routing, refer to the
Pre-installation Planning Guide for Cisco ICM Enterprise & Hosted Editions, available at
Other applications such as the Cisco Media Blender, the Cisco Collaboration Server, the Cisco E-Mail
Manager, Web Interaction Manager, or E-mail Interaction Manager can also function as routing clients
to allow the Unified ICM to become a multi-channel contact routing engine. Details of currently
available multi-channel routing are available on Cisco.com.
Device Targets
Each IP phone must be configured in the Unified ICM Central Controller database as a device target.
Only one extension on the phone can be configured as a Unified ICM device target. Additional
extensions may be configured on the phone, but those extensions will not be known to the Unified ICM
software and, thus, no monitoring or control of those additional extensions is possible. The Unified ICM
provides call treatment for Reroute On No Answer (RONA), therefore it is not necessary to configure
call forwarding on ring-no-answer in the Unified CM configuration for the phones. Unless call center
policy permits warm (agent-to-agent) transfers, the Unified CCE extension also should not be published
or dialed by anyone directly, and only the Unified ICM software should route calls to this Unified CCE
phone extension.
At agent login, the agent ID and phone extension are associated, and this association is released when
the agent logs out. This feature allows the agent to log in to any agent phone. At agent login, the
Unified CM PIM requests Unified CM to begin monitoring the agent phone and to provide device and
call control for that phone. As mentioned previously, each phone must be mapped to the Unified ICM
JTAPI user ID in order for the agent login to be successful.
Labels
Labels are the response to a route request from a routing client. The label is a pointer to the destination
where the call is to be routed (basically, the number to be dialed by the routing client). Many labels in a
Unified CCE environment correspond to the Unified CCE phone extensions so that Unified CM and
Unified IP IVR can route or transfer calls to the phone of an agent who has just been selected for a call.

1-24 OL-16594-06
Often, the way a call is routed to a destination depends upon where the call originated and where it is
being terminated. This is why Unified CCE uses labels. For example, suppose we have an environment
with two regionally separated Unified CM clusters, Site 1 and Site 2. A phone user at Site 1 will typically
just dial a four-digit extension to reach another phone user at Site 1. In order to reach a phone user at
Site 2 from Site 1, users might have to dial a seven-digit number. To reach a phone user at either site
from a PSTN phone, users might have to dial a 10- digit number. From this example, we can see how a
different label would be needed, depending upon where the call is originating and terminating.
Each combination of device target and routing client must have a label. For example, a device target in
a Unified CCE deployment with a two-node Unified CM cluster and two Unified IP IVRs will require
three labels. If you have 100 device targets (phones), you would need 300 labels. If there are two
regionally separated Unified CM clusters, each with two Unified IP IVRs and 100 device targets per site,
then we would need 1200 labels for the six routing clients and 200 device targets (assuming we wanted
to be able to route a call from any routing client to any device target). If calls are to be routed to device
targets only at the same site as the routing client, then we would need only 600 labels (three routing
clients to 100 device targets, and then doubled for Site 2).
Labels are also used to route calls to Unified IP IVR CTI Ports. Details on configuring labels are
provided in the Unified CCE Installation Guide, available on Cisco.com. A bulk configuration tool is
also available to simplify the configuration of the labels.
Agent Desk Settings

Agent Desk Settings provide a profile that specifies parameters such as whether auto-answer is enabled,
how long to wait before rerouting a call for Ring No Answer, what DN to use in the rerouting, and
whether reason codes are needed for logging out and going not-ready. Each agent must be associated
with an agent desk setting profile in the Unified ICM configuration. A single agent desk setting profile
can be shared by many agents. Changes made to an agent’s desk setting profile while the agent is logged
in are not activated until the agent logs out and logs in again.
Agents
Agents are configured within the Unified ICM and are associated with one specific Unified CM PIM
(that is, one Unified CM cluster). Within the Unified ICM configuration, you also configure the
password for the agent to use at login. These passwords are local only to the Unified CCE application
and do not interact with the Active Directory or any other encryption or authentication system.
Skill Groups
Skill groups are configured within the Unified ICM so that agents with similar skills can be grouped
together. Agents can be associated with one or more skill groups. Skill groups are associated with a
specific Unified CM PIM. Skill groups from multiple PIMs can be grouped into Enterprise Skill
Groups. Creating and using Enterprise Skill Groups can simplify routing and reporting in some
scenarios.

OL-16594-06 1-25
Unified CCE Routing
Directory (Dialed) Numbers and Routing Scripts

In order for Unified CM to generate a route request to the Unified ICM, Unified CM must associate the
DN with a CTI Route Point that is associated with the Unified ICM JTAPI User. The DN must also be
configured in the Unified ICM. Once the Unified ICM receives the route request with the DN, that DN
is mapped to a Unified ICM Call type, which is then mapped to a Unified ICM routing script.
Agent Login and State Control

Agents log in to Unified CCE from their Unified CCE agent desktop application. When logging in, the
agent is presented with a dialog box that prompts for agent ID or login name, password, and the Unified
CCE phone extension to be used for this login session. It is at login time that the agent ID, phone
extension (device target), agent desk setting profile, skills, and desktop IP address are all dynamically
associated. The association is released upon agent logout.
Unified CCE Routing

The example routing script in Figure 1-12 illustrates how Unified CCE routes calls. In this routing script,
the Unified CM PIM (or cluster) is the routing client. Upon receipt of the route request, the Unified ICM
maps the DN to a call type and then maps the call type to this routing script. In this routing script, the
Unified ICM router first uses a Select node to look for the Longest Available Agent (LAA) in the
BoatSales skill group on the CCM_PG_1 peripheral gateway (or cluster). The Unified ICM router
determines that agent 111 is the LAA. Agent 111 is currently logged in from device target 1234
(Unified CM phone extension 1234 in this scenario). The Unified ICM router then determines the label
to be returned, based upon the device target and routing client combination. The appropriate label is then
returned to the routing client (Unified CM cluster) so that the call can be routed properly to that phone
(device target).

1-26 OL-16594-06
Unified CCE Routing
Figure 1-12 Routing Script Example
Route request (DN, ANI, CED) Unified CM

cluster
Agent ID Dev Target

111 1234
Dev Target Rtg Client Label

1234 CM Cluster 1234
1234 IPIVR 1 1234
1234 IPIVR 2 1234
Route response returned

to Unified CM Cluster
76581
Translation Routing and Queuing
If no agents are available, then the router exits the Select node and transfers the call to a Unified IP IVR
to begin queuing treatment. The transfer is completed using the Translation Route to VRU node. The
Translation Route to VRU node returns a unique translation route label to the original routing client, the
Unified CM cluster. The translation route label will equal a DN configured in Unified CM. In
Unified CM, that DN is mapped to a CTI Route Point that is associated with the JTAPI user for the
Unified IP IVR to which the call is being transferred.
Unified CM and Unified IP IVR will execute the JTAPI routing control messaging to select an available
CTI Port.
When the call is successfully transferred to the Unified IP IVR, the Unified IP IVR translation routing
application first sends a request instruction message to the Unified ICM via the SCI between the
Unified IP IVR and the Unified ICM. The Unified ICM identifies the DN as being the same as the
translation route label and is then able to re-associate this call with the call that was previously being
routed. The Unified ICM then re-enters the routing script that was previously being run for this call. The
re-entry point is the successful exit path of the Translation Route to VRU node. (See Figure 1-13.) At
this point, the routing client has changed from the Unified CM cluster to IPIVR1.
While the call was being transferred, the routing script was temporarily paused. After the transfer to the
Unified IP IVR is successfully completed, the Unified IP IVR becomes the routing client for this routing
script. Next the routing script queues the call to the BoatSales skill group and then instructs the
Unified IP IVR to run a specific queue treatment via the Run VRU Script node. Eventually agent 111

OL-16594-06 1-27
Unified CCE Routing
becomes available, and as in the previous example, the label to be returned to the routing client is
identified based upon the combination of device target and routing client. Note that the routing client is
now the Unified IP IVR. The label returned (1234) when agent 111 becomes available causes the
Unified IP IVR to transfer the call to agent 111 (at extension 1234).
Figure 1-13 Translation Routing and Queuing
Original
Original route request routing client
Unified CM
Cluster
New routing client

IPIVR 1
Agent ID Dev Target

111 1234
Dev Target Rtg Client Label

1234 CM Cluster 1234
1234 IPIVR 1 1234
1234 IPIVR 2 1234
Route response returned

to IPIVR 1
76582
For each combination of Unified CM cluster and Unified IP IVR, a translation route and a set of labels
is required. For example, if a deployment has one Unified CM cluster and four Unified IP IVRs, then
four translation routes and sets of labels are required.
For deployments with multiple Unified IP IVRs, the Unified ICM routing script should select the
Unified IP IVR with the greatest number of idle Unified IP IVR ports and then translation-route the call
to that specific Unified IP IVR. If no Unified IP IVR ports are available, then the script should execute
a Busy node. If a high number of calls are executing Busy nodes, then it is important to resize your
Unified IP IVR port capacity.
Reroute On No Answer (RONA)

When a call is routed to an agent but the agent fails to answer the call within a configurable amount of
time, the Unified CM PIM for the agent who did not answer will change that agent’s state to not ready
(so that the agent does not get more calls) and launch a route request to find another agent. Any call data
is preserved and popped onto the next agent's desktop. If no agent is available, the call can be sent back
to the Unified IP IVR for queuing treatment again. Again, all call data is preserved. The routing script

1-28 OL-16594-06
Combining IP Telephony and Unified CCE in the Same Unified CM Cluster
for this RONA treatment should set the call priority to “high” so that the next available agent is selected
for this caller. In the agent desk settings, you can set the RONA timer and the DN used to specify a
unique call type and routing script for RONA treatment.
Combining IP Telephony and Unified CCE in the Same

Unified CM Cluster
It is possible for a Unified CM 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 CM
clusters with both IP Telephony and Unified CCE extensions, it is important to realize that sometimes
the most recent Unified CM software release will not immediately be supported in Unified CCE
deployments until testing is completed later. It is also important to note that many contact center
environments have very stringent maintenance windows. Additionally, Unified CCE agents process far
more calls than typical administrator phone users on a Unified CM 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 2,000 agents because of the higher call volume and messaging that
Unified CM is required to maintain to support those agents. Because of these software and
environmental limitations, it might sometimes be advantageous to separate the Unified CM clusters for
IP Telephony extensions from the Unified CM clusters for Unified CCE extensions. It is important to
consider the environment where Unified CCE is being deployed to determine whether a separate
Unified CM 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 typically will not have voicemail
or any 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 configured with voicemail and other calling
features.
The position of the line on the phone determines which line will be answered or used if the agent just
picks up the handset. In a typical call center, the ACD line would be the first line on the phone to make
it easier for the agent to answer inbound ACD calls and also to ensure that any calls the agent makes
using the phone are tracked by the system as external calls for that agent. Additionally, the agent's state
will change based upon this line. If the agent picks up the phone to place a call, they will be put into
not ready mode and the Unified CCE will not route a call to them.
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 would not want to track all of 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 will allow the users to pick up the phone and
answer the first line as well as use this line for all calls they place by default. To answer an ACD call,
they will have to select that line on the phone or use the agent desktop to answer that line appearance
directly. They should also be aware that they will 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 will 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 could interrupt a customer
call. To prevent this from happening, agent-to-agent routing can be used and the agent-to-agent routing

OL-16594-06 1-29
Queuing in a Unified CCE Environment
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 CM instead of the agent DID in order 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 CM wildcard feature can be used, although the ICM will require distinct routing DNs, one for
each agent.
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 of the regulations in such countries, agents typically used to have only
one line with access to customer calls only, and they were required to have a different phone (for
example, a softphone) to access a VoIP line for contacting fellow teammates or experts located outside
the contact center.
The Logical Partitioning feature in Cisco Unified CM 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, therefore configurations are required to provide controlled access and to avoid toll
bypass. The Logical Partitioning feature can be enabled and configured in Unified CM 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 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 due to ring-no-answer, waiting for handling by an initial or subsequent agent
When planning your Unified CCE deployment, it is important to consider how queuing and requeuing
are going to be handled.
Call queuing in a Unified CCE deployment requires use of an IVR platform that supports the SCI
interface to the Unified ICM. The Unified IP IVR is one such platform. Cisco also offers another IVR
platform, Unified CVP, that can be used as a queuing point for Unified CCE deployments. The chapter
on Deployment Models, page 2-1, provides considerations for deployments with Unified CVP.
Traditional IVRs can also be used in Unified CCE deployments, and the chapter on Deployment Models,
page 2-1, also provides considerations for deployments with traditional IVRs.
In a Unified CCE environment, an IVR is used to provide voice announcements and queuing treatment
while waiting for an agent. The control over the type of queuing treatment for a call is provided by the
Unified ICM via the SCI interface. The Run VRU Script node in a Unified ICM routing script is the
component that causes the Unified ICM to instruct the IVR to play a particular queuing treatment.
While the IVR is playing the queuing treatment (announcements) to the caller, the Unified ICM waits
for an available agent with a particular skill (as defined within the routing script for that call). When an
agent with the appropriate skill becomes available, the Unified ICM reserves that agent and then
instructs the IVR to transfer the voice path to that agent's phone.

1-30 OL-16594-06
Transfers in a Unified CCE Environment
Transfers in a Unified CCE Environment

Transfers are a commonly used feature in contact centers, therefore it is very important to consider all
of the possible transfer scenarios desired for your Unified CCE installation. This section explains basic
transfer concepts, and the transfer scenarios themselves are discussed in the chapter on Deployment
Models, page 2-1.
Transfers involve three parties: the original caller, the transferring agent, and the target agent. The
original caller is the caller that made the original call that was routed to the transferring agent. The
transferring agent is the agent requesting the transfer to the target agent. The target agent is the agent
receiving the transfer from the transferring agent. This terminology is used throughout this document
when referring to the different parties.
Note Cisco recommends that all call control (answer, release, transfer, conference, and so on) be done from
the agent desktop application.
When a transferring agent wants to transfer a call to another skill group or agent, the transferring agent
clicks on the transfer button on the Unified CCE Agent Desktop. A dialog box allows the transferring
agent to enter the dialed number of a skill group or agent. An alphanumeric dialed number string (such
as sales or service) is also valid. The transferring agent also selects whether this transfer is to be a
single-step (blind) transfer or a consultative transfer. (Single-step transfer is the default.) The
transferring agent then clicks OK to complete (single-step) or initiate (consultative) the transfer. The
transfer request message flows from the transferring agent desktop to the CTI Server and then to the
Unified CM PIM.
Any call data that was delivered to the transferring agent or added by the transferring agent is sent along
with the transfer request to the Unified CM PIM.
Conferences in a Unified CCE Environment

Conferences are a commonly used feature in contact centers, therefore it is very important to consider
all of the possible conference scenarios desired for your Unified CCE installation. This section explains
basic conference concepts, and the conference scenarios themselves are discussed in the chapter on
Deployment Models, page 2-1.
Conferences involve three or more parties: the original caller, added participants, the conferencing agent,
and the target agent. The original caller is the caller that made the original call that was routed to the
conferencing agent. Added participants are parties that are already in an existing conference call. The
conferencing agent is the agent requesting the conference to add the target agent. The target agent is the
agent being added to the conference. This terminology is used throughout this document when referring
to the various parties in a conference.
Note Cisco recommends that all call control (answer, release, conference, transfer, and so on) be done from
the agent desktop application.
When a conferencing agent wants to conference a call to another skill group or agent, the conferencing
agent clicks on the conference button on the Unified CCE Agent Desktop. A dialog box allows the
conferencing agent to enter the dialed number of a skill group or agent. An alphanumeric dialed number

OL-16594-06 1-31
string (such as sales or service) is also valid provided it is configured in the Unified CCE Dialed Number
Plan. The conferencing agent then clicks OK to initiate the conference. The conference request message
flows from the conferencing agent desktop to the CTI Server and then to the Unified CM PIM.
Note that single-step blind transfers are not supported.
Any call data that was delivered to the conferencing agent or added by the conferencing agent is sent
along with the conference request to the Unified CM PIM.
When Call Recording is enabled in the DN configuration for an agent phone, the codec will not be
renegotiated when establishing a conference. As a result, if two phones are connected using G.722 and
a conference call is initiated, the codec will not be renegotiated to G.711 and a hardware conference
bridge or transcoder will be required.
Dialed Number Plan

The Unified CM PIM then attempts to match the dialed number with an entry in the Dialed Number Plan.
The Unified ICM Dialed Number Plan (DNP) is currently administered via the Bulk Configuration tool
on the Unified ICM Administrative Workstation (AW). Entries in the DNP are entered per peripheral
(PIM), and all DNP entries for a particular PIM are downloaded to the PIM upon PIM startup. Updates
and additions to the DNP are also sent to the PIM dynamically, and they take effect immediately and are
used for the next call being conferenced. In order for the Unified ICM to route the conference and have
all call data move with the conference and be saved for cradle-to-grave reporting, a match for the dialed
number must be found in the DNP for the PIM where the agent is currently logged in.
Within the DNP, fuzzy (wildcard) matching of dialed number strings is allowed. The DNP is not the same
as the Dialed Number table used by the Unified ICM router and managed via the AW Configuration
Manager tool. The Unified ICM router maps dialed numbers to call types, and call types are mapped to
Unified ICM routing scripts. This is how a specific dialed number is mapped to a routing script in the
Unified ICM router. For administration details on editing dialed numbers, call types, and routing scripts,
refer to the Cisco Unified Contact Center Administration Guide, available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1844/prod_maintenance_guides_list.html
For help with designing a dial plan for your Unified CCE deployment, consult your Cisco Systems
Engineer (SE).
Note For network blind transfer (NBT) scenarios using a route point, there are discrepancies in the Telephony
Call Dispatcher (TCD) table. Therefore, Cisco recommends using the Dialed Number Plan (DNP)
instead of a route point for NBT scenarios.
Dial Plan Type

Entries in the Dialed Number Plan must be configured with a dial plan type. There are six predefined
(via a list box) DNP types that correspond to the types specified in the agent desk settings profile. In
order for a call or conference to proceed any further, the DNP type for that call must be allowed in the
agent desk setting profile used by the conferencing agent. Because the Unified CM calling search spaces
override any desk settings, it is best to allow all dial plan types in the agent desk settings.
Note Changes to the agent desk settings profile do not take effect until the agent logs out and logs in again.

1-32 OL-16594-06
Post Route
Entries in the Dialed Number Plan must also be configured to indicate whether a post-route is required.
For dialed numbers to be used in conference scenarios, Cisco recommends that the post-route option be
set to Yes for conferences. When this field is set to Yes, the dialed number to be used for the route request
must be supplied in the Dialed Number column of the Dialed Number Plan Editor.
Route Request
Assuming a match is found in the DNP for the conference, the DNP type is allowed for the conferencing
agent, and the post-route option is set to Yes, then the PIM logic will generate a route request to the
Unified ICM central controller using the dialed number specified in this same DNP entry.
Upon receipt of the route request, the Unified ICM router matches the dialed number to a call type and
executes the appropriate routing script to find an appropriate target agent for the call. Within the routing
script, any of the call data collected so far could be used in the intelligent routing of the call. The Unified
ICM router will determine which device target (phone extension and desktop) the agent is logged into
and will then return the label that points to that device target to the Unified CM PIM.
At this point there are numerous scenarios that can occur, depending upon the type of conference being
performed, as described in the following sections:
• Single-Step (Blind) Conference, page 1-33
• Consultative Conference, page 1-34
Single-Step (Blind) Conference

A blind conference is used when the conferencing agent does not need to speak with the target agent.
After specifying a blind conference in the conference dialog box on the agent desktop, the conferencing
agent enters a DN and clicks the Initiate Conference button. The desktop then sends the conference
request to the Unified CM PIM. Assuming a match is found in the DNP, the DNP type is valid, and
post-route is selected, the Unified CM PIM generates the route request to get a routing label and then
instructs the Unified CM to perform a single-step conference (without any further action from the
conferencing agent). The conferencing agent will see the call disappear from their desktop and they will
transition to the next agent state (wrap-up, ready, or not ready), depending on the agent desk settings for
the conferencing agent. While the call is being placed to the target agent, the original caller is
temporarily placed on hold. When the target agent's phone begins ringing, the original caller hears the
ringing (assuming auto-answer is not enabled). The target agent receives a screen pop with all call data,
and the Answer button on their agent desktop is enabled when the phone begins ringing. Upon answering
the call, the target agent is speaking with the original caller and the conference is then complete. If the
target agent does not answer, then RONA (reroute on no answer) call rerouting logic will take over.
If auto-answer is enabled, the original caller and the target agent do not hear any ringing; the call is just
connected between the original caller and the target agent.
If the agent is conferencing the call to a generic (skill-group) DN to find an available agent with a
particular skill, but no such agent is currently available, then the Unified ICM routing script should be
configured to translation-route the call to a Unified IP IVR for queuing treatment. The call would still
be released from the conferencing agent desktop almost immediately. Any call data collected by the
conferencing agent would automatically be passed to the IVR. The caller will not hear any ringback
tones because the Unified IP IVR CTI Port will answer immediately. When the target agent becomes
ready, the Unified ICM will instruct the IVR to conference the call, and the Unified ICM will pop the
agent desktop with all call data.

OL-16594-06 1-33
If the agent has conferenced the call to a number that is not within the Unified ICM Dialed Number Plan,
then the caller will be conferenced anyway. The destination for the conferenced call depends upon the
number that was dialed and what is configured in the Unified CM dial plan. Conferences not using the
dialed number plan are not recommended because of agent roaming restrictions, call data not following
the call, and reporting limitations.
Consultative Conference
When the Unified CM PIM receives the label from the Unified ICM router indicating where to
conference the call, the Unified CM PIM tells Unified CM to initiate a consultative conference to the
number specified in the label. Unified CM places the original caller (or parties) on hold and makes a
consultative call to the number specified in the label. The caller generally hears tone on hold while the
conference is being completed. The exception is that if it is already a conference call, the parties will
still be able to hear and talk to each other but not the agent who is controlling the conference. There is
a Unified CM configuration parameter for music on hold that, if enabled, will play music to the
participants.
When the target agent phone begins ringing, Unified CM generates a Consult Call Confirmation message
and a Device Ringing message.
The Consult Call Confirmation message causes the Unified CM PIM to notify the conferencing agents
desktop that the call is proceeding, and it enables the Conference Complete button. The conferencing
agent can hear the target agent's phone ringing (assuming auto-answer is not enabled for the target
agent). At any time after this, the agent can click the Conference Complete button to complete the
conference (before or after the target answers their phone).
The Device Ringing message causes the Unified CM PIM to pop the target agent's desktop with call data
and to enable their Answer button (assuming auto-answer is not enabled). When the target agent clicks
the Answer button (or auto-answer is invoked), a voice path between the conferencing agent and target
agent is established (assuming the conferencing agent has not clicked the Conference Complete button).
Generally the conferencing agent will not click the Conference Complete button before the target agent
answers because the probable reason they used consultative conference was that they wanted to talk with
the target agent before completing the conference. However, the conferencing agent can click on the
Conference Complete button at any time after it is enabled.
If the agent is conferencing the call to a generic DN to find an available agent with a particular skill, but
no such agent is currently available, then the Unified ICM routing script should be configured to route
the call to an IVR for queuing. In this scenario, the conferencing agent would hear the Unified IP IVR
queue announcements. The conferencing agent could press the Conference Complete button at any time
to complete the conference. This particular scenario is known as warm transfer. The caller and the agent
would then begin hearing the Unified IP IVR queuing announcements while the agent still guides the
caller or continues to process the call while waiting. Upon availability of an appropriately skilled agent,
the Unified IP IVR conferences the call to this target agent and pops any call data onto their screen.
If the agent is conferencing the call to a number that is not in the Unified ICM Dialed Number Plan and
a number that is not valid on the Unified CM, the conferencing agent will hear the failed consultation
call and will be able to reconnect with the original caller, as explained in the section on Reconnect,
page 1-35.

1-34 OL-16594-06
Reconnect
During the consultation leg of a consultative conference, the conferencing agent can reconnect with the
caller and release the consult call leg. To do so, the agent simply clicks the Reconnect button. This action
causes the agent desktop to instruct the Unified CM PIM to instruct Unified CM to release the
consultation call leg and to reconnect the agent with the original caller.
This is basically the process an agent should use when they want to make a consultation call but for
foreseen or unforeseen reasons do not desire to complete the conference. After a call is successfully
reconnected, the conferencing agent's desktop functionality will be exactly the same as before they
requested the conference. Therefore, the conferencing agent can later request another conference, and
there is no limit to the number of consultation calls an agent can make.
Consultative conferences and reconnects are all done from the agent desktop and use the single
Unified CM extension that is associated with the Unified CCE. The Unified CCE system does not
support allowing the conferencing agent to place the original caller on hold and then use a second
extension on their hardware phone to make a consultation call. The hardware phone offers a button to
allow this kind of conference, but it is not supported in a Unified CCE environment. If an agent
conferences a call in this way, any call data will be lost because the Unified ICM did not route the call.
Alternate
Alternate is the ability for the agent to place the consultation call leg on hold and then retrieve the
original (or conference) call leg while in the midst of a consultative conference. The agent can then
alternate again to place the original caller back on hold and retrieve the consultation call leg. An agent
can alternate a call as many times as they would like.
When the conferencing agent has alternated back to the original caller, the only call controls (buttons)
that are enabled are Release and Alternate. The Conference (Complete) and Reconnect controls will be
disabled. The Alternate control will alternate the conferencing agent back to talking with the consulted
party. When the agent has alternated back to the consultation leg, the Release, Alternate, Conference,
and Reconnect call controls will be enabled. The Alternate control will alternate the conferencing agent
back to talking with the original caller. The Conference control will complete the conference, and the
Reconnect button will drop the consulted party and reconnect the agent with the original caller.
Non-DNP Conferences
Conferences to numbers not in the DNP or to numbers configured in the DNP with post-route set to No
are allowed but do not result in a Unified ICM-routed call. In these scenarios, the PIM simply sends a
call conference request directly to Unified CM and uses the dialed number from the conference dialog
on the agent desktop. Call data is lost if the Unified ICM does not route the call. Cisco recommends that
any dialed number for a conference should have a match in the DNP, that it be marked for post-route,
and that it have a DNP type that is allowed for the conferencing agent (based on the agent’s desk
settings).
Agent-to-Agent Conferences
If the conference is to a specific agent, then the agent requesting the conference must enter the agent ID
into the conference dialog box. The DNP entry matching the dialed number (agent ID) must have DNP
type equal to PBX. This causes the PIM to place the dialed number (agent ID) into the CED field before
it sends the route request to the Unified ICM router. In the script editor, use the agent-to-agent routing
node and specify the CED field as the location of the agent ID so that the Unified ICM router will route
this call properly.

OL-16594-06 1-35
Agent IDs should not match any of the extensions on the Unified CM cluster. If you begin all agent IDs
with the same number and they all have the same length, you could set up a generic wildcard string that
matches all agent IDs so that you need only one entry in the DNP for agent-to-agent routing.
If your environment has multiple PIMs, then you must use an agent ID number plan to determine which
PIM contains this agent. Agent IDs by themselves are not unique. Agent IDs are associated with a
specific PIM and can be reused on other PIMs. By not repeating agent IDs across the enterprise and by
setting up a consistent agent ID assignment plan (such as all PIM 1 agent IDs begin with a 1, all PIM 2
agent IDs begin with a 2, and so on), you can parse the CED field in the script editor to determine which
PIM contains the agent. The parsing may be done via a series of “if” nodes in the script editor or via a
route-select node. The agent-to-agent node requires the PIM to be specified.
In the event that the target agent is not in a ready state, the agent-to-agent script editor node allows
alternative routing for the call.
Transferring Conference Calls

Transferring of conference calls is allowed with the same conditions as described in the section on
Transfers in a Unified CCE Environment, page 1-31.
Conference Reporting
After a conference call is completed, a call detail record for the original call leg will exist and a new call
detail record will be opened for the new call leg. The two call records are associated with one another
via a common call ID assigned by the Unified ICM. The time during the consultation call leg, and before
the conference is completed, is considered as talk time for the conferencing agent.
For more details, refer to the Unified CCE Reporting Guide, available online at Cisco.com.
Combination or Multiple Conferences

During a conference, only the controller may (through the softphone) conference in other participants.
Hardware phones might allow this function, but it is not supported by Unified CCE.
After a call has been successfully conferenced, another party can be conferenced in by the controller.
The limit on the number of participants depends on the bridging hardware used, the Unified CM
configuration, and so forth.
PSTN Transfers (Takeback N Transfer, or Transfer Connect)

Many PSTN service providers offer a network-based transfer service. These services are generally
invoked by the customer premises equipment (CPE) outpulsing a series of DTMF tones. The PSTN is
provisioned to detect these tones and perform some specific logic based upon the tones detected. A
typical outpulse sequence might be something like *827500. This DTMF string could mean, “transfer
this call to site 2 and use 7500 as the DNIS value when delivering the call to site 2.” Unified CCE has
the ability to invoke these types of transfers.

1-36 OL-16594-06

Cisco Overview

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Cisco Overview

Hochgeladen von

Copyright:

Verfügbare Formate

CH A P T E R 1

Last revised on: August 18, 2009

Cisco Unified Contact Center Enterprise 7.5 SRND

Figure 1-1 Typical Unified CCE Deployment

Cisco Unified Contact Center Enterprise 7.5 SRND

What's New in This Chapter

New or Revised Topic Described in:

Cisco Unified Communications Manager

Cisco Unified Contact Center Enterprise 7.5 SRND

Cisco Voice Gateways

Cisco Unified Customer Voice Portal (Unified CVP)

Cisco Unified Contact Center Enterprise 7.5 SRND

Cisco Unified IP Interactive Voice Response (Unified IP IVR)

Cisco Unified Intelligent Contact Management (Unified ICM)

Cisco Unified Contact Center Enterprise 7.5 SRND

Basic Unified CCE Call and Message Flow

The call flow in Figure 1-2 is as follows:

Cisco Unified Contact Center Enterprise 7.5 SRND

11. Call is answered by agent.

The call flow in Figure 1-3 is as follows:

Unified ICM Software Modules

Cisco Unified Contact Center Enterprise 7.5 SRND

Cisco Unified Contact Center Enterprise 7.5 SRND

Cisco Unified Contact Center Enterprise 7.5 SRND

Figure 1-4 Communications Among Peripheral Gateway Software Processes

ICM central controller Unified CCE Agent

Unified CCE Components, Terminology, and Concepts

Unified CCE Agent Options

Cisco Unified Contact Center Enterprise 7.5 SRND

Figure 1-5 Variety of Agent Interfaces for Unified CCE

Cisco Agent Desktop

Cisco Unified Contact Center Enterprise 7.5 SRND

Figure 1-6 Cisco Agent Desktop

Cisco Unified Contact Center Enterprise 7.5 SRND

CTI Object Server (CTI OS)

Cisco Unified Contact Center Enterprise 7.5 SRND

Figure 1-7 Generalized View of Information Flow in CTI OS

CTI Server Driver Lib

Request Service Event Notification

Cisco Unified Contact Center Enterprise 7.5 SRND

Figure 1-8 Communication Between ICM Central Controller and Distributor AW

Central Controller AW Distributor with HDS

Config and AWDB

Cisco Unified Contact Center Enterprise 7.5 SRND

Unified CCE Reporting

Cisco Unified Intelligence Suite

Cisco Unified Contact Center Enterprise 7.5 SRND

Administrative Workstation Database (AWDB)

Historical Data Server (HDS)

Unified Contact Center Management Portal

Cisco Unified Contact Center Enterprise 7.5 SRND

Cisco Unified Contact Center Enterprise 7.5 SRND

Cisco Unified Contact Center Enterprise 7.5 SRND

Figure 1-9 Multichannel Subsystem

CeM Media Blender

Cisco E-Mail Manager

Cisco Unified Contact Center Enterprise 7.5 SRND

Cisco Collaboration Server

Cisco Interaction Manager

Cisco Unified Outbound Option

Cisco Unified Mobile Agent

Unified System CCE

Cisco Unified Contact Center Enterprise 7.5 SRND