Cisco Unified Contact Center Enterprise Design Guide, Release 10.0(1)
Architecture Overview
Downloads: This chapterpdf (PDF - 1.63 MB) The complete bookPDF (PDF - 12.77 MB) | The complete bookePub (ePub - 6.46 MB) | The complete bookMobi (Mobi - 11.28 MB) | Feedback

Architecture Overview


Architecture Overview

Architecture Overview

Cisco Unified Contact Center Enterprise (Unified CCE) is a solution that delivers intelligent call routing, network-to-desktop Computer Telephony Integration (CTI), and multichannel contact management to contact center agents over an IP network. Unified CCE combines software IP automatic call distribution (ACD) functionality with Cisco Unified Communications to enable companies to deploy an advanced, distributed contact center infrastructure rapidly.

You must be familiar with the basic Unified Communications architecture and functionality as described in the Cisco Unified Communications and Collaboration Solutions Design Guidance at http:/​/​​c/​en/​us/​support/​unified-communications/​unified-communications-system/​products-implementation-design-guides-list.html. Make sure that you become familiar with the concepts described in that manual for topics such as routes, labels, and dialed numbers.

This design guide describes the deployment models and their implications including scalability, fault tolerance, and interaction between the solution components.

The Unified CCE product integrates with Cisco Unified Communications Manager, Cisco Unified IP IVR, Cisco Unified Customer Voice Portal, Cisco VoIP Gateways, and Cisco Unified IP Phones. Together these products provide contact center solutions to achieve intelligent call routing, multichannel ACD functionality, voice response unit (VRU) functionality, network call queuing, and consolidated enterprise-wide reporting. Unified CCE can optionally integrate with Cisco Unified Intelligent Contact Manager to network with legacy ACD systems while providing a smooth migration path to a converged communications platform.

The Unified CCE solution is designed for implementation in both single and multisite contact centers. Unified CCE uses your existing Cisco IP network to lower administrative expenses and to include branch offices, home agents, and knowledge workers in your contact center. The following figure illustrates a typical Unified CCE setup.

Figure 1. Typical Unified CCE Solution Deployment

The Unified CCE solution consists primarily of four Cisco software products:
  • Unified Communications infrastructure: Cisco Unified Communications Manager
  • Queuing and self-service: Cisco Unified Customer Voice Portal (Unified CVP) or Cisco Unified IP Interactive Voice Response (Unified IP IVR)
  • Contact center routing and agent management: Unified CCE. The major components are CallRouter, Logger, Peripheral Gateway, and the Administration & Data Server/Administration Client.
  • Agent desktop software: Cisco Finesse, CTI Toolkit Desktop (CTI OS), or integrations with third-party customer relationship management (CRM) software through Cisco Unified CRM Connector.
The solution is built on the Cisco IP Telephony infrastructure, which includes:
  • Cisco Unified IP Phones
  • Cisco Voice Gateways
  • Cisco LAN/WAN infrastructure

The following sections discuss each of the software products in more detail and describe the data communications between each of those products. For more information about a particular product, see the specific product documentation available online at


Cisco Packaged CCE is a predesigned, bounded deployment model of Unified CCE. If your contact center requirements fit the boundaries of the Packaged CCE solution, you can enjoy the advantages of the simplified management interface, smaller hardware footprint, and reduced time to install. Packaged CCE customers also benefit from the comprehensive feature set of Unified CCE and Unified CVP. Packaged CCE supports up to 1000 agents, and uses Cisco Unified Intelligence Center for comprehensive reporting and Cisco Finesse desktop software. For more information, see http:/​/​​c/​en/​us/​support/​customer-collaboration/​packaged-contact-center-enterprise/​tsd-products-support-series-home.html.

Solution Components

Cisco Unified Communications Manager

Cisco Unified Communications Manager is a software application that controls the Voice Gateways and IP phones, thereby providing the foundation for a VoIP solution. Unified Communications Manager runs on Cisco Unified Computing System (UCS) hardware or a specification-based equivalent. The software running on a VM is referred to as a Unified Communications Manager server. Multiple Unified Communications Manager servers can be grouped into a cluster to provide for scalability and fault tolerance. Unified Communications Manager communicates with the gateways using standard protocols such as Media Gateway Control Protocol (MGCP) and Session Initiation Protocol (SIP). Unified Communications Manager communicates with the IP phones using SIP or Skinny Call Control Protocol (SCCP). For details on Unified Communications Manager call processing capabilities and clustering options, see the latest version of the Cisco Collaboration System Solution Reference Network Designs at http:/​/​​go/​ucsrnd.

Unified Communications Manager communicates with Unified CCE through the Java Telephony Application Programming Interface (JTAPI).  In a fault-tolerant design, a Unified Communications Manager cluster is capable of supporting thousands of agents. However, the number of agents and the number of busy hour call attempts (BHCA) supported within a cluster varies and must be sized according to Cisco guidelines.

Typically, when designing a Unified CCE solution, you first define the deployment scenario, including the arrival point (or points) for voice traffic and the location (or locations) of the contact center agents. After defining the deployment scenario, you can determine the sizing of the individual components within the Unified CCE design, including how many Unified Communications Manager servers are needed within a cluster.

Cisco Service Advertisement Framework Call Control Discovery (SAF CCD) allows Unified Communications Manager to advertise directory number ranges that it owns and discover and dynamically create routes for other Unified Communications Manager clusters. SAF CCD replaces the need for gatekeepers and SIP proxies.


Unified CCE supports interoperability with an IPv6-enabled Unified Communications Manager cluster. All of the Unified CCE compontents run with IPv4 enabled including Unified CVP, Unified IP IVR, the CTI OS agent desktops, and agent phones. The Unified CCE Agent PG uses IPv4 to integrate with Unified Communications Manager CTI Manager.

Caller phones or voice gateways can run either IPv4 or IPv6. If the caller's environment is IPv6 only, you must use Media Terminating Point (MTP) resources for call treatment (Unified CVP VXML gateways and Unified IP IVR).

IPv6 is not supported for agent phones. The agent phone might support dual stack IPv4 or IPv6, but the agent sign-in is denied unless you register the phone as IPv4. You must configure Mobile Agent and Outbound Option endpoints (CTI ports and Dialer ports) as IPv4 devices.

Cisco Voice Gateways

When you select Voice Gateways for a Unified CCE deployment, it is important to select Voice Gateways that satisfy not only the number of required PSTN trunks but also the busy hour call completion rate on those trunks. Busy hour call completion rates per PSTN trunk are typically higher in a contact center than in a normal office environment. For Cisco Catalyst Communications Media Module (CMM) Voice Gateways used in pure contact center deployments, provision a maximum of four T1/E1 interfaces to ensure that the call processing capacity of the Voice Gateway is satisfactory.

Agent Phones

Unified CCE supports both monitoring of a single line for all agent devices (Single-Line Agent Mode) and monitoring multiple agent lines when Multi-Line Agent Mode is enabled for the Peripheral. Multi-Line Agent Mode provides the following capabilities:
  • Monitoring and reporting of calls on all lines on the phone.
  • Other than call initiation, all other call control on the non-ACD extensions is supported from multiline capable desktops. Calls initiated from the hard phone can be controlled after initial call setup.
  • Requires a busy trigger of 1 (no call waiting), although calls can be forwarded to other extensions on the phone when busy.
  • Requires a maximum of two call appearances.
  • Supports a maximum of four lines per phone, one ACD line and up to three non-ACD lines.
  • Shared lines are supported on non-ACD lines but not on ACD Lines.

  • Call Park is not supported on ACD and non-ACD lines.
  • Unified CCE may not be backward compatible with third-party CTI applications when Multi-Line Agent Mode is enabled. Multiline support must be validated with the third-party vendor.


Use of the Join Across Line (JAL) and Direct Transfer Across Line (DTAL) phone features is deprecated. Do not use these features in any new deployment.

For a list of supported agent phones, see the Compatibility Matrix for Unified CCE at http:/​/​​wiki/​Compatibility_​Matrix_​for_​Unified_​CCE.

The Agent Greeting feature relies on the phone's Built-In Bridge (BIB) functionality to play back the greeting to both the caller and the agent.

Agent Greeting requires:

  • The phones have the BIB feature.
  • The phones must be running the latest firmware version delivered with Unified Communications Manager.
  • The phones must be configured as BIB enabled in Unified Communications Manager.


These requirements apply to local agents only.

For a list of agent phones and required firmware to support the Agent Greeting feature, see the Compatibility Matrix for Unified CCE .

Finesse and Multiline

Finesse does not support the configuration of multiple lines on agent phones. However, if your agents use 8900 Series or 9900 Series phones, you must enable Multi-Line on the Unified Communications Manager peripheral. Because this configuration option is a peripheral-wide option, if you enable Multi-Line for even one agent who uses an 8900 Series or 9900 Series phone, you must enable it for all agents.

Although you must enable Multi-Line on the Unified Communications Manager peripheral for 8900 Series and 9900 Series phones, you must configure only one extension for each phone in Unified Communications Manager.

If you do not have 8900 Series or 9900 Series phones in your deployment, configure the Unified Communications Manager peripheral for Single Line. Disable the Join Across Line (JAL) feature on all 6900 Series and 7900 Series phones. When running in Single Line mode, Finesse does support configuring more than one line on the phone. However, Unified CCE only monitors a single line. If the agent is on a call on the secondary line appearance, the agent state in Finesse is Ready and Unified CCE may route a call to that agent. Additionally, call activity on the secondary line appearance is not reported.

You must configure all phones with the following settings:

  • Set Maximum number of calls to 2.

  • Set Busy trigger to 1.

Cisco Unified Customer Voice Portal

Unified Customer Voice Portal (Unified CVP) is a software application that runs on Cisco Unified Computing System (UCS) hardware or specification-based equivalents. CVP provides prompting, collecting, queuing, and call control services using standard web-based technologies. The CVP architecture is distributed, fault tolerant, and highly scalable. With the CVP system, voice is terminated on Cisco IOS gateways that interact with the Unified CVP application server using VoiceXML (speech) and SIP (call control).

The Unified CVP software is tightly integrated with the Cisco Unified CCE software for application control. CVP interacts with Unified CCE using the Voice Response Unit (VRU) Peripheral Gateway Interface. The Unified CCE scripting environment controls the execution of building-block functions such as play media, play data, menu, and collect information. The Unified CCE script can invoke external VoiceXML applications for execution by the CVP VoiceXML Server, an Eclipse and J2EE-based scripting and web server environment. VoiceXML Server is suited for sophisticated and high-volume VRU applications and it can interact with custom or third-party J2EE-based services. These applications can return results and control to the Unified CCE script when complete. Advanced load balancing across all CVP solution components can be achieved by Cisco Content Services Switch (CSS) and Cisco IOS Gatekeepers or Cisco Unified Presence SIP Proxy Servers.


Unified CCE deployments with multiple clusters do not support Unified CVP's Enhanced Location Call Admission Control feature.

Unified CVP can support multiple grammars for prerecorded announcements in several languages. CVP can optionally provide automatic speech recognition and text-to-speech capability. CVP can also access customer databases and applications through the Cisco Unified CCE software.

Unified CVP also provides a queuing platform for the Unified CCE solution. Voice and video calls can remain queued on 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. When Unified CCE routes the call to an agent, the agent can send videos to a caller from the agent desktop application. For more information, see the latest version of the Design Guide for Cisco Unified Customer Voice Portal at http:/​/​​c/​en/​us/​support/​customer-collaboration/​unified-customer-voice-portal/​products-implementation-design-guides-list.html.

Unified CVP also supports Agent Greeting recording and playback when integrated with Unified CCE. A preinstalled CVP VXML application is provided to allow agents to record and manage their greetings.  Unified CCE instructs the CVP to play back the agent’s specific greeting to the caller and agent when the agent answers the call.

Unified CVP also supports the Whisper Announcement feature to play a prerecorded announcement to the agent when the agent answers the call.

Cisco Unified IP IVR

The Unified IP IVR provides prompting, collecting, and queuing capability for the Unified CCE solution. Unified IP IVR does not provide call control as Unified CVP does because it is behind Unified Communications Manager and under the control of the Unified CCE software by way of the Service Control Interface (SCI). When an agent becomes available, the Unified CCE software instructs the Unified IP IVR to transfer the call to the selected agent phone. The Unified IP IVR then requests Unified Communications Manager to transfer the call to the selected agent phone.

Unified IP IVR is a software application that runs on Cisco Unified Computing System (UCS) hardware or a specification-based equivalent. You can deploy multiple Unified IP IVR servers with a single Unified Communications Manager cluster under control of Unified CCE.

Unified IP IVR has no physical telephony trunks or interfaces like a traditional VRU. The telephony trunks are terminated at the Voice Gateway. Unified Communications Manager 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 Communications Manager through the Java Telephony Application Programming Interface (JTAPI), and the Unified IP IVR communicates with Unified CCE through the Service Control Interface (SCI) with a VRU Peripheral Gateway or System Peripheral Gateway.

For deployments requiring complete fault tolerance, a minimum of two Unified IP IVRs are required.

Unified Intelligent Contact Manager

Unified CCE may be deployed with Unified ICM to form a complete enterprise call management system. Unified ICM interfaces with ACDs from various vendors (including Cisco Unified CCE), VRUs (including Cisco Unified IP IVR and Unified CVP), and telephony network systems to efficiently and effectively treat customer contacts such as calls and e-mail regardless of where the resources are located in the enterprise.

Unified CCE may be deployed in a hybrid model with Unified ICM where the CallRouter, Logger, Administrative & Data Servers, and other components are shared between Unified ICM and Unified CCE.

Alternatively, Unified CCE may be deployed in a parent/child model where Unified ICM is the parent and Unified CCE is the child. This closely resembles the deployment model of Unified ICM with ACDs from other vendors. It is used for a highly scalable deployment because it provides CallRouters, data servers, and so forth for each product; although there are more components to manage and maintain. It is also used for a distributed model where isolation is needed between Unified ICM and Unified CCE, such as in an outsourced operation.

Related Information

Time Synchronization

To ensure accurate operation and reporting, all the components in your contact center solution must use the same value for the time. You can synchronize the time across your solution using a Simple Network Time Protocol (SNTP) server. The following table outlines the needs of various component types in your solution.


Use the same NTP sources throughout your solution.

Type of component


Domain controllers

Domain controllers must all point to the same NTP servers.

ESXi hosts

All ESXi hosts must point to the same NTP servers as primary domain controllers.

Windows components in the contact center domain

Windows machines in the domain point to, and are automatically in synch with, the primary domain controller for NTP. They require no configuration for NTP.

Windows components not in the contact center domain

Follow the Microsoft documentation to synchronize directly with the NTP server.

Non-Windows components

Components such as Unified Intelligence Center, Finesse, Social Miner, and Unified Communications must point to the same NTP servers as the domain controllers.

Cisco Integrated Service Routers

To provide accurate time for logging and debugging, use the same NTP source as the solution for the Cisco IOS Voice Gateways.

Cisco Unified Contact Center Enterprise

Cisco Unified Contact Center Enterprise (CCE) is the software application that provides the contact center features, including agent state management, agent selection, call routing and queue control, VRU control, CTI Desktop screen pops, and contact center reporting. Unified CCE runs in virtual environments on Cisco Unified Computing System (UCS) hardware or specification-based equivalents. Unified CCE relies on the Microsoft Windows Server 2012 R2 operating system software and the Microsoft SQL Server 2014 database management system. With the flexibility of virtual machines, you can scale and size Unified CCE software to meet various deployment requirements.

Unified CCE Software Components

This topic describes the main components of the Unified CCE product. Following sections describe some key concepts and terminology and go into more detail on some of the components.

The Cisco Unified CCE software is a collection of components that can run on multiple virtual machines (VMs). The number and type of components that can run on one server is primarily based on busy hour call attempts (BHCA) and the size of the VM. Other factors that impact the hardware sizing are the number of agents, the number of skill groups per agent, the number of Unified IP IVR ports, the number of VRU Script nodes in the routing script, Expanded Call Context (ECC) usage, and which statistics the agents need at their desktops.

The core Unified CCE software components are listed here and described in greater detail later in this chapter.

Table 1 Core Unified CCE Software Components

Unified CCE Software Components



Makes all routing decisions on how to route a call or customer contact. Often just referred to as the "Router" in the context of Unified CCE components. The Router is a part of the Central Controller.


The database server that stores contact center configuration data and temporarily stores historical reporting data for distribution to the data servers. The Logger is a part of the Central Controller.

Cisco Finesse Server

The Finesse server connects Finesse desktops to the CTI server on the Agent PG.

CTI Object Server (CTI OS)

CTI interface for CTI OS Agent Desktops.

Peripheral Gateway (PG)

Interfaces to various peripheral devices, specifically to Unified Communications Manager, VRU (Unified IP IVR or Unified CVP), or Multichannel products (EIM and WIM for email and chat). The PG includes one or more Peripheral Interface Managers (PIMs) for the specific device interfaces.

Agent PG

PG that has a Unified Communications Manager PIM.

Unified Communications Manager Peripheral Interface Manager (PIM)

Part of a PG that interfaces to a Unified Communications Manager cluster by using the JTAPI protocol.


Part of a PG that interfaces to the Unified IP IVR or Unified CVP through the Service Control Interface (SCI) protocol.


Part of a PG that interfaces to call center Multimedia products, specifically EIM and WIM for email and chat.

CTI Server

Part of the PG that interfaces to CTI OS and provides an open CTI interface, which is useful for some server-to-server communications and Finesse and third-party CTI applications

Administration & Data Server

Configuration interface and real-time and historical data storage (for example, for reporting). There are several different deployment models described later in this chapter.

Administration Client

Configuration interface. This component has a subset of the functionality of the Administration & Data Server. It is a lighter weight deployment because it does not require a local database and it is deployed to allow more places from which to configure the solution.

Cisco Unified Intelligence Center (Unified Intelligence Center)

Provides web browser-based real-time and historical reporting. Unified Intelligence Center also works with other Cisco Unified Communications products.

The combination of CallRouter and Logger is called the Central Controller. When the CallRouter and Logger modules run on the same VM, the server is referred to as a Rogger.

Redundancy and Fault Tolerance

You deploy the CallRouter and Logger in a paired redundant fashion. The two sides of the redundant deployment are referred to as Side A and Side B. For example, CallRouter A and CallRouter B are redundant instances of the CallRouter running on two different VMs. In normal operation, both sides are running. When one side is down, the configuration is running in stand-alone mode. These modes are occasionally referred to as duplex and simplex modes.


Stand-alone (simplex) deployments of the CallRouter and Logger are not supported in production environments. You must deploy these components in redundant pairs.

The two sides are for redundancy, not load-balancing. Either side can run the full load of the solution. The A and B sides both execute the same set of messages and produce the same result. In this configuration, there logically appears to be only one CallRouter. The CallRouters run in synchronized execution across the two VMs, which mean both sides process every call. During a failure, the surviving Call Router picks up the call midstream and continue processing in real time and without user intervention.

The Peripheral Gateway (PG) components run in hot-standby mode, meaning that only one PG is active and controlling Unified Communications Manager or the appropriate peripheral. When the active side fails, the surviving side automatically takes over processing of the application. During a failure, the surviving side runs in simplex mode until the redundant side is restored and the configuration automatically returns to redundant operation.

The CTI OS component provides fault tolerance through a pair of servers that operate together and back up each other. There is no notion of an active and passive server, or of a primary and secondary server. Both servers are always active. Clients can connect to either server. During the failure of any one server, clients can automatically reconnect to the alternate server.

The Administration & Data Servers, which handle configuration and real-time data, are deployed in pairs for fault tolerance. You can deploy multiple pairs for scalability. The Administration & Data Servers for historical data follow an n+1 architecture for redundancy and scalability. Each Administration & Data Server has a Logger (Side A or B) as its preferred and primary data source.

Peripheral Gateway and PIMs

For each Unified Communications Manager cluster in the Unified CCE environment, there is a Unified Communications Manager PIM on an Agent Peripheral Gateway (PG). For scalability requirements, some deployments may require multiple PIMs for the same cluster. You must deploy each PIM on a different Agent PG. Each Agent PG with a Unified Communications Manager PIM can support a maximum of 2000 agents.

For each Agent PG, there is one CTI Server component and one or more CTI OS components to communicate with the desktops associated with the phones for that cluster.


The CTI OS components on Side A and Side B are simultaneously active to load-balance desktop communication.

For each Unified IP IVR or CVP Server, there is one VRU PIM. VRU PIMs may be part of the Agent PG.

Often, the Unified Communications Manager PIM, the CTI Server, the CTI OS, and multiple VRU PIMs may run on the same VM.

Internal to the PG is a process called the PG Agent which communicates to the Central Controller. Another internal PG process is the Open Peripheral Controller (OPC), which enables the other processes to communicate with each other and is also involved in synchronizing PGs in redundant PG deployments. The following figure shows the communications among the various PG software processes.

Figure 2. Communications Among Peripheral Gateway Software Processes

In larger, multisite (multi-cluster) environments, multiple Agent PGs are usually deployed. When multiple clusters are deployed, Unified CCE tracks all the agents and calls centrally. Unified CCE is able to route the calls to the most appropriate agent independent of the site or cluster that they are using, thus making them all appear to be part of one logical enterprise-wide contact center with one enterprise-wide queue.

Unified CCE Agent Desktop Options

Cisco offers the following interfaces for Unified CCE agents:

  • Cisco Finesse Desktop—Cisco Finesse is a web-based desktop solution that allows for the extension of the desktop through standardized web components. Cisco Finesse offers:

    • a browser-based solution

    • an extensible desktop interface using standard OpenSocial gadgets

    • server features available to applications using documented REST APIs

  • Cisco CTI OS Desktop Toolkit—The CTI OS Desktop Toolkit provides a software toolkit for building custom desktops, desktop integrations into third-party applications, or server-to-server integrations to third-party applications.

These integrated solutions enable call control (Answer, Drop, Hold, Un-Hold, Blind or Warm Transfers, and Conferences), outbound calls, consultative calls, and delivery and manipulation of Call Context Data (CTI screen pop).

Figure 3. Variety of Agent Interfaces for Unified CCE

Agents who use a third-party CRM user interface that is connected through a CRM Connector can be supervised using a CTI OS Desktop Toolkit-based supervisor desktop.

Administration and Data Server and Administration Client

Administration & Data Servers have several roles: Administration, Real-time data server, Historical Data Server, and Detail Data Server. A Unified CCE deployment must have Administration & Data Servers to fill these roles. The servers may be deployed in the following combinations to achieve the needed scalability with the minimum number of VMs:
  • Administration Server and Real-Time Data Server (AW)
  • Configuration-Only Administration Server
  • Administration Server, Real-Time and Historical Data Server, and Detail Data Server (AW-HDS-DDS)
  • Administration Server and Real-Time and Historical Data Server (AW-HDS)
  • Historical Data Server and Detail Data Server (HDS-DDS)


    See the Deployments chapter for more details on deployment options and requirements.

  • An Administration Client (formerly known as a client AW) serves the administration role but is deployed as a client to an Administration Server for scalability. The Administration Client may view and modify the configuration and receive real-time reporting data from the AW, but it does not store the data itself and does not have a database.

Install each Administration & Data Server on a separate VM for production systems to ensure no interruptions to the real-time call processing of the CallRouter and Logger processes. For lab or prototype systems, the Administration & Data Server can be installed on the same VM as the CallRouter and Logger.

The AW acts as the authentication server for Cisco Finesse. In a Finesse deployment, the AW is mandatory and must run in high-availability mode (both a primary and backup AW).

For information about data storage in virtualized deployments, see the Virtualization for Unified CCE DocWiki at http:/​/​​wiki/​Virtualization_​for_​Unified_​CCE.

Administration Server and Administration Client

The Administration Server, Configuration-Only Administration Server, and Administration Client provide a Configuration Manager tool that is used to configure Unified CCE. The configuration options include, for example, the ability to add agents, add skill groups, assign agents to skill groups, add dialed numbers, add call types, assign dialed numbers to call types, or assign call types to routing scripts.

The Administration Server and Administration Client also have the tool Script Editor, which is used to build routing scripts. Routing scripts specify how to route and queue a contact (that is, the script identifies which skill group or agent handles a particular contact).

Precision Routing is available in Unified CCE. To configure Precision Routing, you can use a web-based application, Unified CCE Administration. For more information about Precision Routing, see the Cisco Unified Contact Center Enterprise Features Guide at http:/​/​​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-feature-guides-list.html. For third-party configuration, you can use REST API. For more information about using API to configure Precision Routing, see the Cisco Unified Contact Center Enterprise Developer Reference Guide at http:/​/​​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-programming-reference-guides-list.html.

The Administration Server and Configuration-Only Administration Server also support the following configuration tools:
  • Internet Script Editor Server—HTTPS (default protocol) connection for Script Editor clients

For information about these and other configuration tools, see the Administration Guide for Cisco Unified Contact Center Enterprise & Hosted at http:/​/​​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-maintenance-guides-list.html.

The Administration Server is deployed as part of the Administration and Real-time Data Server, known as AW. AWs are deployed in pairs for fault tolerance. During normal operation, the primary AW communicates directly with the Central Controller for configuration data and the secondary AW connects to the primary AW for the data. If the primary AW fails, the secondary AW connects to the Central Controller. Both types of AW store the configuration and real-time data in the AW Database, or AWDB. Each AW can be deployed in the same location as, or remote from, the Central Controller. A secondary AW need not be co-located with the primary AW.

Multiple Administration Clients can be deployed and connected to either primary or secondary AWs. An Administration Client must be geographically local to its AW.


Administration Clients and Administration Workstations can support remote desktop access. But, only one user can access a client or workstation at a time. Unified CCE does not support simultaneous access by several users on the same client or workstation.

Configuration Only Administration Servers are the same as AWs, but without the real-time data. As such, Administration Clients cannot connect to them and they cannot display real-time data in Script Editor.

Figure 4. Communication Between Central Controller and Administration & Data Server

Figure 5. Communication Between Central Controller and multiple Administration & Data Servers

AWs, Configuration-Only Administration Servers, and Administration Clients may operate only as a single instance on a given VM.

Real-time Data Server

The Real-Time Data Server portion of the AW uses the AW database to store real-time data along with the configuration data. Real-time reports combine these two types of data to present a near-current transient snapshot of the system.

Historical Data Server And Detail Data Server

The Historical Data Server (HDS) and Detail Data Server (DDS) are used for longer-term historical data storage. The HDS stores historical data summarized in 15 or 30 minute intervals and is used for reporting. DDS stores detailed information about each call or call segment and is used for call tracing. Data may be extracted from either of these sources for warehousing and custom reporting.

Typically these Data Servers are deployed with a primary AW as a single server serving all three roles (AW-HDS-DDS). In very large deployments, it might be desirable to separate them for scalability.

Unified CCE Reporting

The Unified CCE Reporting solution provides an interface to access data describing the historical and real-time states of the system.

The reporting solution consists of the following components:
  • Cisco Unified Intelligent Center—Reporting user interfaces
  • Configuration and Reporting Data—Contained on one or more Administration & Data Servers


Reporting concepts and data descriptions are described in the Reporting Concepts for Cisco Unified ICM/Contact Center Enterprise & Hosted at http:/​/​​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-configuration-examples-list.html. (This description is independent of the reporting user interface being used.)

Cisco Unified Intelligence Center

Cisco Unified Intelligence Center (Unified Intelligence Center) is an advanced reporting product used for Unified CCE and other products. This platform is a web-based application offering many Web 2.0 features, high scalability, performance, and advanced features such as the ability to integrate data from other Cisco Unified Communications products or third-party data sources. Unified Intelligence Center incorporates a security model that defines different access and capabilities for specific users.

Unified Intelligence Center Standard is included with Unified CCE. Unified Intelligence Center Premium is an optional product with additional features. See the Cisco Unified Intelligence Center User Guide at http:/​/​​c/​en/​us/​support/​customer-collaboration/​unified-intelligence-center/​products-user-guide-list.html. Install Unified Intelligence Center on a separate VM; it cannot be co-resident with other Unified CCE components.

Unified Contact Center Management Portal

The Unified Contact Center Management Portal provides a simple-to-use web-based user interface to streamline the day-to-day provisioning and configuration operations performed by a contact center manager, team lead, or administrator. The management portal provides the following key benefits:
  • Simple-to-use web user interface for performing basic tasks such as moving, adding, or modifying phones, agents, skill groups, and teams and other common contact center administrative functions for an IP contact center
  • Unified Configuration; that is, tenant provisioning of both the applicable IP contact center elements and the Cisco Unified Communications Manager components through a single task-based web interface
  • Partitioned System supporting multiple business units with complete autonomy
  • Hierarchical Administration supporting multiple business-level users where each user is defined with specific roles and responsibilities
  • Audit Trail Reports that detail configuration changes and usage by all users of the management portal

JTAPI Communications

For JTAPI communications to occur between Unified Communications Manager and external applications such as Unified CCE and Unified IP IVR, configure a JTAPI user ID and password with Unified Communications Manager. When the Unified Communications Manager PIM or Unified IP IVR starts, they use the JTAPI user ID and password to sign in to the cluster. The Unified Communications Manager PIM or Unified IP IVR application sign-in process establishes JTAPI communications between the cluster and the application. Each Unified IP IVR server requires a separate JTAPI user ID. A Unified CCE deployment with one cluster and two Unified IP IVRs requires three JTAPI user IDs: one for Unified CCE and two for the two Unified IP IVRs. Use one PG user for each PG pair.

The Unified Communications software includes a module called the CTI Manager. The CTI Manager communicates through JTAPI to applications such as Unified CCE and Unified IP IVR. Every subscriber within a cluster can execute an instance of the CTI Manager process. But, the Unified Communications Manager PIM on the Agent PG communicates with only one CTI Manager (and thus one node) in the cluster. The CTI Manager process passes CTI messages to and from other nodes within the cluster.

For example, a deployment uses to subscriber 1 to connect to a Voice Gateway (VG) and uses subscriber 2 to communicate with Unified CCE through the CTI Manager. When a call for the contact center arrives at the VG, subscriber 1 sends an intra-cluster message to subscriber 2. Subscriber 2 sends a route request to Unified CCE to determine how to route the call.

Each Unified IP IVR also communicates with only one CTI Manager within the cluster. The PIM and the two Unified IP IVRs from the example can communicate with different CTI Managers or they can all communicate with the same CTI Manager. However, they each use a different user ID. The user ID is how the CTI Manager tracks the different applications.

When the PIM is redundant, only one side is active and in communication with the cluster. The PIM on Agent PG A communicates with the CTI Manager on another subscriber. Unified IP IVR is not deployed in redundant pairs. But, if its primary CTI Manager is out of service, Unified IP IVR can fail over to another CTI Manager within the cluster.

The JTAPI communications between the cluster and Unified CCE include three distinct types of messaging:

  • Routing control

    Routing control messages provide a way for the cluster to request routing instructions from Unified CCE.

  • Device and call monitoring

    Device monitoring messages provide a way for the cluster 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 the cluster to receive instructions from Unified CCE on how to control a device (phone) or a call.

A typical Unified CCE call includes all three types of JTAPI communications within a few seconds. When a new call arrives, Unified Communications Manager requests routing instructions from Unified CCE. For example, when a subscriber receives the routing response from Unified CCE, the subscriber sends the call to an agent phone. The subscriber notifies Unified CCE that the phone is ringing. That notification enables the answer button on the agent desktop. When the agent clicks the answer button, Unified CCE instructs the subscriber to make the phone go off-hook and answer the call. In order for the routing control communication to occur, subscriber needs a CTI Route Point. You associate a CTI Route Point with a specific JTAPI user ID. Through this association, the subscriber knows which application provides routing control for that CTI Route Point. Dialed Numbers (DNs) are then associated with the CTI Route Point. Then, the subscriber can generate a route request to Unified CCE when a new call to that DN arrives.


You cannot use the DN for a CTI Route Point on a different CTI Route Point in another partition. Ensure that DNs are unique across all CTI Route Points on all partitions.

To monitor and control the phones, associate the phones with a JTAPI user ID in Unified Communications Manager. When you use Extension Mobility or Extension Mobility Cross Cluster, you can associate an Extension Mobility device profile instead. In a Unified CCE environment, you associate the IP phones or the corresponding Extension Mobility device profiles with Unified CCE JTAPI user IDs. When an agent desktop signs in, the PIM requests a subscriber to allow the PIM to begin monitoring and controlling that phone. Until the agent signs in, the subscriber does not allow Unified CCE to monitor or control that phone. If the device or the corresponding Extension Mobility device profile is not associated with a Unified CCE JTAPI user ID, then the agent sign-in request fails.

Using Extension Mobility Cross Cluster (EMCC), when a Unified CCE PIM phone registers to the local cluster after Extension Mobility sign in, the phone looks like an agent situated across a WAN. The Unified CCE peripheral manages the agent devices based on the Extension Mobility profile rather than on a phone device in the Application User on the cluster. For more information, see the Cisco Collaboration System Solution Reference Network Designs at http:/​/​​c/​en/​us/​support/​unified-communications/​unified-communications-manager-callmanager/​products-implementation-design-guides-list.html.

You can associate Extension Mobility devices using two methods; either by device or by user profile. Associate the Extension Mobility profile to the CCE Application User on Unified Communications Manager.

Configuring the EM Profile, instead of the device, provides more flexibility in which phones agents can use in the call center. Configuring the phone device limits which devices the agents can use. The option that you use in a contact center depends on the customer business case.

Because Unified IP IVR also communicates with the cluster using the JTAPI protocol, the same three types of communications also occur with Unified IP IVR. Unlike Unified CCE, the Unified IP IVR provides both the application itself and the devices being monitored and controlled.

The devices that Unified CCE monitors and controls are the physical phones. The Unified IP IVR does not have physical ports like a traditional VRU. Unified IP IVR ports are logical ports called CTI Ports. For each CTI Port on Unified IP IVR, there needs to be a CTI Port device defined in Unified Communications Manager.

Unlike a traditional PBX or telephony switch, Unified Communications Manager does not select the Unified IP IVR port to which it sends the call. When a call is made to a DN that is associated through a CTI Route Point with a Unified IP IVR JTAPI user, the subscriber asks the Unified IP IVR which CTI Port handles the call. If Unified IP IVR has an available CTI Port, Unified IP IVR responds to the routing control request with the device identifier of the CTI Port to handle that call.

SIP sends Dual Tone Multi-Frequency (DTMF) digits, however Unified IP IVR and Unified Communications Manager only support out-of-band DTMF digits. JTAPI messages from the cluster notify Unified IP IVR of caller-entered DTMF digits. The cluster uses an MTP resource to convert in-band signaling to out-of-band signaling. CTI ports only support out-of-band DTMF digits. If your deployment includes SIP phones or gateways, provision sufficient MTP resources to support the conversion. The Mobile Agent feature also requires extra MTP resources for this conversion.

The following scenarios are examples of Unified IP IVR device and call control. When an available CTI Port is allocated to the call, a Unified IP IVR workflow starts within Unified IP IVR. When the workflow executes the accept step, a JTAPI message is sent to the subscriber to answer the call for that CTI Port. When the Unified IP IVR workflow wants the call transferred or released, the workflow again instructs the subscriber on what to do with that call.

When a caller releases the call while interacting with the Unified IP IVR, the VG detects the caller release. The VG notifies the subscriber with the Media Gateway Control Protocol (MGCP), which then notifies the Unified IP IVR with JTAPI. When the VG detects DTMF tones, the VG notifies the subscriber through H.245 or MGCP, which then notifies the Unified IP IVR through JTAPI.

In order for the CTI Port device control and monitoring to occur, associate the CTI Port devices on Unified Communications Manager with the appropriate Unified IP IVR JTAPI user ID. If you have two 150-port Unified IP IVRs, you have 300 CTI ports. Associate half of the CTI ports with JTAPI user Unified IP IVR 1, and associate the other half of the CTI ports with JTAPI user Unified IP IVR 2.

While you can configure Unified Communications Manager to route calls to Unified IP IVRs on its own, Unified CCE routes calls to the Unified IP IVRs in a Unified CCE environment (even if you have only one Unified IP IVR and all calls require an initial VRU treatment). Doing so ensures proper Unified CCE reporting. For deployments with multiple Unified IP IVRs, this routing practice also allows Unified CCE to load-balance calls across the multiple Unified IP IVRs.

Multichannel Subsystems: EIM and WIM

Unified CCE has the capability to provide a multichannel contact center with E-mail Interaction Manager (EIM) and Web Interaction Manager (WIM).

For design information about these products, see the Cisco Unified Web and E-Mail Interaction Manager Solution Reference Network Design Guide at http:/​/​​c/​en/​us/​support/​customer-collaboration/​unified-email-interaction-manager/​products-implementation-design-guides-list.html.

Cisco Outbound Option

Agents can handle both inbound and outbound contacts, which helps in optimizing contact center resources. The Cisco Outbound Option enables the multifunctional contact center to take advantage of Cisco Unified CCE enterprise management. Contact center managers in need of outbound campaign solutions can take advantage of the enterprise view that Cisco Unified CCE maintains over agent resources.

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.

Related Information


Diagnostic Tools

Unified CCE has a built-in web-based (REST-like) interface for diagnostics called the Diagnostic Framework, which is resident on every Unified CCE server. The Analysis Manager functionality integrated with the Unified Communications Manager Real-Time Monitoring Tool (RTMT) is provided as the client-side tool to collect diagnostic information from this diagnostic framework. In addition to the Analysis Manager, a command line interface—Unified System CLI tool—is available that allows a client to access the diagnostic framework on any Unified Communications server. (A user need not use Remote Desktop first to gain access to use the CLI.)

Using the Analysis Manager, the administrator connects to one or more Unified Communications devices to set trace levels, collect trace and log files, and gather platform and application configuration data as well as version and license information. The Analysis Manager is the one tool that allows administrators to collect diagnostic information from all Cisco Unified Communications applications and devices.

The Analysis Manager offers local user and domain security for authentication and secure HTTP to protect data exchanged by it and the diagnostic framework.

For more information about the Unified CCE Diagnostic Framework (that runs on every Unified CCE server), see the Serviceability Best Practices Guide for Cisco Unified ICM/Contact Center Enterprise at http:/​/​​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-configuration-examples-list.html.

Network Management Tools

Unified CCE is managed using the Simple Network Management Protocol (SNMP). Unified CCE devices have a built-in SNMP agent infrastructure that supports SNMP v1, v2c, and v3 and it exposes instrumentation defined by the CISCO-CONTACT-CENTER-APPS-MIB. This MIB provides configuration, discovery, and health instrumentation that can be monitored by standard SNMP management stations. Unified CCE provides a rich set of SNMP notifications that alerts administrators of any faults in the system. Unified CCE also provides a standard syslog event feed (conforming to RFC 3164) for those administrators who want to take advantage of a more verbose set of events.

For managing a Unified Communications deployment, customers are encouraged to use the Cisco Unified Operations Manager (Unified Operations Manager) product. Unified Operations Manager is a member of the Cisco Unified Communications family of products and provides a comprehensive and efficient solution for network management, provisioning, and monitoring of Cisco Unified Communications deployments.

Unified Operations Manager monitors and evaluates the current status of both the IP communications infrastructure and the underlying transport infrastructure in your network. Unified Operations Manager uses open interfaces such as SNMP and HTTP to remotely poll data from different devices in the IP communications deployment. In addition to the infrastructure, Unified Operations Manager offers capabilities specific to Unified Communications applications including Unified CCE. For more information, see the Unified Operations Manager documentation at http:/​/​​c/​en/​us/​support/​cloud-systems-management/​prime-unified-operations-manager/​tsd-products-support-series-home.html.

For more information about configuring the Unified CCE SNMP agent infrastructure and the syslog feed, see the SNMP Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted at http:/​/​​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-configuration-examples-list.html.

For details on the health monitoring and management capabilities of Unified CCE, review the Serviceability Best Practices Guide for Cisco Unified ICM/Contact Center Enterprise at http:/​/​​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-configuration-examples-list.html.

Combining IP Telephony and Unified CCE in the Same Unified Communications Manager Cluster

It is possible for a Unified Communications Manager cluster to support Cisco Unified IP phones with both normal IP Telephony (office) extensions and Unified CCE (call center) extensions. When running dual-use Unified Communications Manager clusters with both IP Telephony and Unified CCE extensions, it is important to ensure all elements of the solution are compatible, as documented in the Compatibility Matrix for Unified CCE at http:/​/​​wiki/​Compatibility_​Matrix_​for_​Unified_​CCE.

It is also important to note that many contact center environments have very stringent maintenance windows. Unified CCE agents process far more calls than typical administrator phone users in a Unified Communications Manager cluster, so their device weight (or the amount of processing power required per agent) is higher than a typical business phone user. For example, an administrator-only cluster might be able to support 20,000 phones, but a Unified CCE cluster might support only a fraction of those as agents because of the higher call volume and messaging that Unified Communications Manager is required to maintain to support those agents.

Because of these software and environmental limitations, it might sometimes be advantageous to separate the Unified Communications Manager clusters for IP Telephony extensions from the Unified Communications Manager clusters for Unified CCE extensions. It is important to consider the environment where Unified CCE is being deployed to determine whether a separate Unified Communications Manager cluster is advantageous.

Combining IP Telephony and Unified CCE Extensions on the Same IP Phone

Unified CCE supports only one agent ACD line on the IP phone, which does not have voice-mail or call forwarding defined so that Unified CCE can manage and control all calls sent to the agent on this line. Typically, the agent extension is not used as the agent’s DID or personal line. A separate line can be assigned to the agent’s phone for that purpose and can be configured with voice-mail and other calling features.

The position of the line on the phone determines which line is answered or used if the agent just picks up the handset. In a typical call center, the ACD line is the first line on the phone to make it easier for the agent to answer inbound ACD calls and ensure that calls the agent makes using the phone are tracked by the system as external calls. The agent’s state changes based the activity on this line. If the agent picks up the phone to place a call, the agent is put into not-ready mode and the Unified CCE does not route a call to that agent.

In some cases, the agents are knowledge workers or they do not take as many ACD calls as they do normal extension calls. The call center manager does not track their phone activity that is not ACD related, and it might be inconvenient for those users to always get the ACD line first when they want to pick up a DID call instead. In this case, the order of the lines might best be reversed, placing the ACD line on the last (or bottom) line appearance on the phone and placing the DID or normal extension on the first line on the phone. This arrangement allows users to pick up the phone and answer the first line as well as use this line for all calls they place. To answer an ACD call, they have to select that line on the phone or use the agent desktop to answer that line appearance directly. Also, be aware that they have to manage their agent state and go into not-ready mode manually when they want to place a call on their normal extension so that Unified CCE does not attempt to route a call to them while they are on the other line.

It is possible to have a deployment where the agent extension is the same as the agent’s DID or personal line. When call waiting is configured on the agent phone, agent-to-agent calls can interrupt a customer call. To prevent this from happening, agent-to-agent routing can be used and the agent-to-agent routing script can be set up to queue or reject the call if the agent is busy. This is a good option if there is a need to see all agent activity and to avoid all interruptions for the agent. The configuration involves using CTI Route Points in Unified Communications Manager instead of the agent DID to send the calls to Unified CCE for agent-to-agent routing. For ease of configuration and to reduce the number of CTI route points, the Unified Communications Manager wildcard feature can be used, although Unified CCE requires distinct routing DNs (one for each agent).


You cannot use the DN for a CTI Route Point on a different CTI Route Point in another partition. Ensure that DNs are unique across all CTI Route Points on all partitions.

Agent Phones in Countries with Toll-Bypass Regulations

Telecommunications regulations in some countries, such as India, 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 an organization

  • Another one to access the local PSTN

To comply with such regulations, agents had one line to access customer calls and a different phone for VoIP access to teammates or experts located outside the contact center.

The Logical Partitioning feature in Cisco Unified Communications Manager provides the same capability to control calls and features based on specific allowed or forbidden configurations. A common telephony system in a contact center provides access to both the PSTN and VoIP networks. Therefore, the system requires configurations to provide controlled access and to avoid toll bypass.

You can enable and configure the Logical Partitioning feature to prevent toll-bypass calls. With the feature, agents in a Unified CCE system can use the same phone for receiving customer calls and for making or receiving VoIP calls with other employees. Although this feature eliminates the need for agents to have a second phone, contact center managers can choose to have a dedicated line or phone for customer calls and can allocate a different line or phone for other calls.

Queuing in a Unified CCE Environment

Call queuing can occur in three distinct scenarios in a contact center:
  • New call waiting for handling by initial agent
  • Transferred call waiting for handling by a second (or subsequent) agent
  • Rerouted call because of ring-no-answer, waiting for handling by an initial or subsequent agent

When planning your Unified CCE deployment, it is important to consider how to handle queuing and requeuing.

Call queuing in a Unified CCE deployment requires use of an VRU platform that supports the SCI interface to Unified CCE. Unified IP IVR is one such platform. Cisco offers another VRU platform, Unified CVP, which you can use as a queuing point for Unified CCE deployments. For more information, see Deployments.

In a Unified CCE environment, a VRU provides voice announcements and queuing treatment while waiting for an agent. Unified CCE provides the control over the type of queuing treatment for a call through the SCI interface. The Run VRU Script node in a Unified CCE routing script is the component that causes Unified CCE to instruct the VRU to play a particular queuing treatment.

While the VRU plays the queuing treatment to the caller, Unified CCE waits for an available agent with the skill defined in the routing script. When an agent with the defined skill becomes available, Unified CCE reserves that agent. Unified CCE instructs the VRU to transfer the voice path to that agent phone.

Transfers and Conferences in Unified CCE Environments

Transfers and conferences are commonly used in contact centers. They require special attention to ensure the proper system resources are available and configured correctly. Some points to consider when designing your contact center's handling of transfers and conferences:

  • When Call Recording is enabled in the DN configuration for an agent phone, the codec is not renegotiated when establishing a conference. As a result, if two phones are connected using g.722 and a conference call is initiated, the codec is not renegotiated to g.711 and a hardware conference bridge or transcoder is required.

  • To maintain call context during single-step transfers, route to agents or configured routing DNs on the same peripheral.

  • To execute a network transfer from Unified CVP, configure a routing DN on the same peripheral.

Related Information

Dial Plans

Whatever your deployment model for the Unified CCE, it is always helpful to have a dial plan before you begin. The Dial Plan you use is associated with telephone networks and dialing patterns. Many books about dial plans are available. Although written for a different Cisco product, "Implementing Cisco Unified Communications: Introducing Dial Plans" provides an introduction to the concepts and shows the necessity of having a dial plan.

The following section provides a simple, sample dial/configuration plan that you can use as a model.

Sample Unified CCE with Unified CVP Dial Plan

The following table provides a sample dial plan for a Unified CCE system that uses the Unified CVP as its VRU application for queuing.


The dots in some of the values shown represent data that you enter when you configure the gateway. For example, in the value "55551291.." the dots represent any number from 00 through 99.

Dial Peer


Destination-Pattern or Incoming called number

Type or Service

Session Target

Voice Gateway




Unified CVP






Unified CVP

Dialed Number







<correlation ID>

VRU label

Voice Gateway


55551291[00 - 99]

55551291[00 - 99]

CVP Route Point

Unified CVP





Unified Communications Manager

Unified CM (Route Pattern)

Dialed Number







<correlation ID>

Unified Communications Manager Label

Unified CVP

1[000 - 9999]

5555121[000 - 999]

Agent Extensions

Unified Communications Manager

2[000 - 9999]

2[000 - 999]

Route Points

Unified Communications Manager