Cisco Unified Contact Center Express solution architecture for Cisco Unified Communications Manager
Cisco Unified Contact Center Express (Unified CCX) is a
solution composed of many components. These components include not just the
Unified CCX software and the servers upon which that software runs, but
also include Cisco Unified Communications Manager (Unified CM), Cisco
routers, Cisco data switches, Cisco Voice Gateways, and Cisco IP Phones.
Unified CCX software is part of the Unified CCX software
platform. Unified CCX provides the software capabilities for not just
Unified CCX, but also Cisco Unified IP IVR.
Cisco Unified IP IVR is primarily used for Cisco Unified Contact Center
Enterprise (Unified CCE) deployments.
A single physical server can run only one of the Unified CCX
packages, either Unified CCX or Cisco Unified IP IVR.
The Unified CM Telephony subsystem provides a mechanism
for Unified CCX to communicate with Unified CM for call processing.
Within Unified CM, an application user with CTI permissions is defined
and that user ID is used by the Unified CM Telephony subsystem to log
into Unified CM through JTAPI messaging. This user ID is referred to as
the Unified CM Telephony user ID. This login process is what allows Unified CCX to begin communications with Unified CM and offer services
like routing control.
When a caller dials the number of an extension configured on
an IP Phone, Unified CM is capable of setting up that call without the
aid of Unified CCX. However, sometimes callers dial generic numbers that
are not associated with any particular phone. In those situations, Unified CM needs a mechanism to request routing instruction from some other
application. One such mechanism is a route request message and one such
application that can provide routing control is Unified CCX. In order for
Unified CM to request routing from another application for a particular
dialed number, there must be a CTI Route Point defined within Unified CM
for that dialed number. In Unified CCX, this CTI Route Point is defined
in the Cisco Unified CM Telephony Trigger. Within Unified CM the CTI
Route Point is also associated with the user (application) that can provide
routing control. This Unified CM configuration is what enables Unified CM to ask Unified CCX how to route a call. The creation of a CTI
Route Point, the association of that CTI Route Point to the dialed number, and
the user association of that CTI Route Point to the Cisco Unified CM Telephony
user responsible for routing control are done automatically by the Unified
CCX Server as part of the creation of a Cisco Unified CM Telephony trigger
within Unified CCX.
The Unified CM Telephony trigger also specifies what
CTI port group and Unified CCX application to use for a specified dialed
number. As discussed in Chapter 1, Unified CCX provides IVR
functionality. A Unified CCX system can provide up to 400 logical IVR
ports (also called CTI Ports). The CTI ports within Unified CCX are
logical VoIP endpoints where calls can be terminated—very similar to a
softphone. The difference is that these softphones are controlled by an
application that has the ability to encode .wav files from disk into one of the
supported VoIP formats (G.711 or G.729) and then stream those VoIP packets out
the Ethernet interface on the Unified CCX Server to the calling VoIP
endpoint (IP Phone or Voice Gateway port). Each CTI Port must be defined within
Unified CM as a device with a type of
"CTI Port." Each CTI Port device is assigned a unique directory
number (extension), just like a phone. This allows Unified CM to set up
calls to these devices and endpoints. The creation of the CTI Ports on Cisco
Unified CM is done automatically by the Unified CCX server when a group
of CTI Ports (Call Control Group) is defined.
When a caller dials a dialed number that is associated with a
CTI Route Point, Unified CM sends a route request to Unified CCX
which has the dialed number associated with a group of CTI Ports. The Unified CCX software selects an available CTI Port from that CTI Port Group and
returns the extension of that CTI Port to Unified CM. Unified CM
then attempts to set up a call to that extension (CTI Port) by sending a ring
message to the Unified CCX server. When the Unified CCX server gets
the ring message for a particular CTI Port for a particular dialed number, the
Unified CCX server begins executing the script associated with that
trigger's application. The first step in a script is typically an Accept step.
The Accept step in the application will answer the call by sending a message to
Unified CM to establish an RTP stream between the selected CTI Port and
the Voice Gateway (VG) port (or calling IP Phone). The application can then
prompt callers for input and provide the caller self service. When either the
caller hangs up or the application executes a Terminate step, Unified CM
tears down the call.
Within the application, it is also possible to route or
transfer the call to an available agent. If no agents are available, queuing
treatment is provided to the caller. Agents in Unified CCX are called
resources. There is a subsystem within Unified CCX called the Resource
Manager which is responsible for monitoring the state of agents and selecting
agents based upon the agent skills and queue skills required. Queues in Unified CCX are called Contact Service Queues (CSQ). Agents use Cisco Agent
Desktop (CAD) or IP Phone Agent (IPPA) state controls to log in and make
themselves ready. The Resource Manager is updated upon every agent state
Administrators use the Unified CCX Administration web
interface to configure agent skills and competencies. Unified CCX
Administration is also used to define CSQ skill and competency requirements and
the agent selection criteria to be used for that CSQ. Applications use the
Select Resource step to specify the CSQ into which the caller shall be placed.
The Resource Manager subsystem is queried by the application to select the
appropriate agent based upon the agent selection criteria. If no agent is
available, the Select Resource step has a queued branch where queuing treatment
is defined. When the Resource Manager finds an available and appropriately
skilled agent, it will reserve that agent and then request for that call to be
transferred to the agent's IP Phone (using JTAPI messaging to Unified CM).
After the call has been transferred to and answered by the agent, the CTI Port
being used for that call is released.
An agent must be configured in Unified CM as a user.
This adds a record to the Unified CM user table. The Unified CM
user table can be synchronized with LDAP directories like Microsoft's Active
Directory. Details on LDAP integration can be found in Appendix C. Unified CM supports usage of one of the following LDAP directory servers—DC
Directory (default), Netscape IPlanet, and Microsoft Active Directory. In Unified CM, an agent's phone and directory number are associated with the
agent's Unified CM user name and the directory number is also marked as a
Unified CCX extension. This allows Unified CCX to know that this
Unified CM user is an agent, and the user then shows up in the resource
list in Unified CCX Administration.
In Unified CM, agent phones also are associated with
another application user with CTI permissions called the Resource Manager user.
This user is referred to as the RmCm Provider. The RmCm Provider allows Unified CCX to monitor the state of the phone. For example, when an agent goes
off hook to make an outbound call using the Unified CCX extension, the
Unified CCX application needs to be notified so that the Resource Manager
can update its agent state machine to show that agent being on an outbound
call. The RmCm Provider also allows Unified CCX to control the state of
the phone. For example, when an agent clicks Answer on CAD, this triggers Unified CCX to send the RmCm Provider signal to Cisco Unified CM to have that
agent's phone go off hook.
If you use Extension Mobility (EM) together with Unified CM 8.0 or later, associate the device profile, instead of the device, with the Resource Manager application user. Irrespective of the device profile you associate the application user with, set the Intra-Cluster Multiple Login Behavior Extension Mobility Service parameter in Unified CM to Auto Logout.
This action helps to overcome design limitations in CTI/JTAPI noticed in the following scenarios, which occur when the Intra-Cluster Multiple Login Behavior Extension Mobility Service parameter in Unified CM is set to Multiple Logins Allowed:
Agent logs in to EM on a Cisco IP Communicator (CIPC) and also logged in to Cisco Agent Desktop (CAD).
If CIPC unregisters from Unified CM while the agent is still logged in to EM, it does not reregister. This failure to register may happen when the agent closes CIPC without logging out of EM or when the network is severed.
Agent logs into EM from a different device.
When the agent attempts to login to CAD, the system displays the error message: Login failed due to a configuration error with your phone and JTAPI or Unified CM. Contact your administrator.
Unified CCX Call Processing
The figure below and the description that follows explain a
typical Unified CCX call flow:
Figure 1. Unified CCX call flow
Call arrives at Voice Gateway (VG).
Voice Gateway asks Unified CM how to route the call (using H.323
Unified CM has the dialed number (DN) associated with a CTI
Route Point that is associated with a Unified CM Telephony user for Unified CCX. This triggers a JTAPI route request to be sent to Unified
Based upon the DN, which is mapped to a Unified CM Telephony
trigger, the Cisco Unified CCX server selects an available CTI port and replies
back to Unified CM with the extension of the CTI Port to send this call
to. Unified CM then sends a call setup (ring) message to Unified
CCX, which then maps the DN to the appropriate Unified CCX script. The
Accept step (typically the first step) in the script will answer the call and
trigger Unified CM to establish an RTP stream between the Voice Gateway
port and the selected CTI Port. Then the script prompts the caller for an
account number and does a database lookup. Then the caller is prompted to
select from a menu of choices and is provided self-service treatment. If the
user presses 0, we go to the transfer to agent section of the script. In this
scenario, we are assuming no appropriately skilled agents are available, so the
script executes the queued loop logic until an appropriately skilled agent
An appropriately skilled agent becomes available as a result of
logging in and going ready or completing a previous call.
The agent is selected or reserved by the Unified CCX server
and this triggers the call to be transferred to the agent phone and
subsequently causes the agent phone to ring (using Unified CM signaling).
In addition, the Unified CCX server delivers a screen pop to the selected
agent desktop and enables the answer button on the agent desktop.
The agent answers the call, which causes Unified CCX to
complete the transfer from the CTI Port to the agent phone and Unified CM
to initiate the establishment of an RTP VoIP data stream between the agent's
phone and the VG port. The transfer releases the CTI Port on the Unified
CCX server. But the Unified CCX software continues to monitor the agent
state for the duration of that call. When the agent or caller releases, a
Contact Call Detail Record (CCDR) is written to the CCDR table in the database,
and the agent's state is updated to reflect the agent's new state (Work, Ready,
or Not ready).
Unified CCX Web Chat
The Web Chat feature of the Unified CCX is a solution comprising many components. These components include the Unified CCX software, the servers upon which that software runs, Cisco SocialMiner, the customer's website, proxies, firewalls, Cisco Agent Desktop, and Cisco Supervisor Desktop.
A single physical Cisco SocialMiner server can run only on one Unified CCX deployment.
Figure 2. Unified CCX Web Chat flow
The preceding figure and the following description explain a typical Unified CCX Web Chat flow:
Configuration: This is a configuration step and is a precursor to the Web Chat flow depicted in the figure. The Unified CCX administrator configures the chat parameters, making sure that the administrator has a SocialMiner, chat CSQ, and a chat widget with a problem statement defined and configured. The Unified CCX administrator also reviews and verifies other Web Chat configuration parameters.
The Unified CCX administrator preconfigures the customer widget form fields using the Unified CCX Administration in the chat widget creation step. The configuration process generates the skeletal web code that the administrator passes over to the web developer for the customer website. The web developer formats the chat widget code and embeds it into an HTML page on the customer website.
Web Chat request: A customer logs in to the customer (CU) website and initiates a Web Chat request by filling in the customer widget form and selecting an appropriate problem statement.
SocialMiner receives the request: SocialMiner receives the Web Chat request and opens the chat UI at the customer website. Also, SocialMiner sends the new contact notification to the Unified CCX.
Contact queuing: After receiving the contact notification from SocialMiner, Unified CCX matches the problem statement chosen by the contact, and queues* the contact in a specific service queue.
*An alternate flow is a case where the Unified CCX already has an agent waiting for a contact in that queue and the contact is immediately routed to the available agent.
Agent login: A Web Chat agent belonging to the service queue on which the contact was queued logs in from the Web Chat Agent desktop.
Agent becomes ready: An agent sends a request to the Unified CCX to make the agent ready to chat. This request triggers the Unified CCX to start an allocation process and find the appropriate contact for the agent from the service queues. The CSQ configuration decides the allocation logic (either most skilled or longest available).
After a contact is identified for the agent, the contact is allocated and the agent is moved to the Busy state and is prompted to accept the contact through a dialog event.
Agent accepts: An agent responds to the dialog event. If the agent does not accept during the configured accept time out, the contact is re-queued and is ready to be allocated to the other agent. After receiving a confirmation from the Unified CCX for the accept request, the Cisco Agent Desktop launches the chat reply template.
Chat session creation: When SocialMiner gets the request to open the chat reply template from the Cisco Agent Desktop, the SocialMiner serves the template page to the Cisco Agent Desktop and connects the agent to the chat session.
Chat session complete: When an agent or a customer ends the chat session, SocialMiner sends the event back to the Unified CCX to indicate the session ended.
Unified CCX receives session end message: After receiving the message, the Unified CCX updates the session records and moves the agent back to the Ready state.
Unified CCX System Management
Several applications are available for administering and
monitoring a Unified CCX deployment. The primary tool an administrator
uses to manage a Unified CCX deployment is the Unified CCX
Administration web interface. Unified CCX Administration is a web-based
application accessed using a web browser. Using Unified CCX
Administration, administrators perform tasks such as uploading applications,
uploading prompts, mapping applications to dialed numbers, configuring agent
skills and CSQs, starting and stopping Unified CCX subsystems, and
monitoring overall server status.
In addition to Unified CCX Administration, an
administrator uses the Unified CCX Editor. The Unified CCX Editor
is a client-based utility that produces .aef files which the administrator
uploads using Unified CCX Administration. The Unified CCX Editor
can be downloaded and installed from Unified CCX Administration onto
The Cisco Desktop Administrator (CDA) is another client-based
utility that can be downloaded and installed from Unified CCX
Administration. CDA allows an administrator to perform tasks such as
configuring the agent interface, setting up reason codes, and defining agent
workflows and keystroke macros.
Another client utility to monitor a Unified CCX
deployment is the Historical Reports client application. You download and
install the Historical Reports client from Unified CCX Administration.
There are 34 historical reporting templates available. Taken in combination
with filtering parameters and chart or no-chart options, there are 282 possible
reports available. Some of them provide integrated information about voice and
multichannel activities. Custom reporting templates can be created with Crystal
Reports development toolkit. Within Unified CCX Administration, there are
also 11 browser-based real-time reports. The CSD and CAD both also provide
reports to allow real-time monitoring of a Unified CCX deployment. Both
CSD and CAD are downloaded and installed from Unified CCX Administration.
For additional information about Unified CCX
Administration, see the
Cisco Unified CCX Administration Guide.
Unified CCX Engine and Database components
Unified CCX has four core software components:
Unified CCX Engine
Every Unified CCX deployment must have a Unified
CCX Engine component and a Database component. The Monitoring and Recording
components are optional and are discussed in the next section of this chapter.
With Unified CCX, only one instance of each component can be
installed, and all components must be on the same server.
The Unified CCX Engine (and closely related subsystems)
is the component that provides functions such as the following:
JTAPI communications with Unified CM
Execution of scripts
Encoding and streaming of .wav files for all CTI Ports defined
Communications with CAD for agent state control, call control, and
Agent monitoring and selection
Unified CCX Administration web interface.
Simply put, the Unified CCX Engine
component provides the core ACD, IVR, and CTI services. The other
components—Database, Monitoring, and Recording—are auxiliary software
The Database component is required for any Unified CCX deployment and manages access to the
database. The Unified CCX Database contains four data stores. They are as
Configuration data store
Repository data store
Agent data store
Historical data store
The configuration data store contains Unified CCX
configuration information such as resources (agents), skills, resource groups,
teams, and CSQ information. The repository data store contains user prompts,
grammars, and documents. The agent data store contains agent logs, statistics,
and pointers to the recording files. The historical data store contains Contact
Call Detail Records (CCDRs).
Unified CCX Monitoring and Recording components
The previous section introduced the Unified CCX Engine
and Database components. This section introduces the Monitoring and the
Recording components, which are optional.
Unified CCX Enhanced and Premium allow a supervisor to silently monitor agents. Unified CCX Enhanced and
Premium also allow agent calls to be recorded. Agent call
recording can be triggered in the following ways:
Supervisor clicks the Record button on CSD for a specified agent call
Agent clicks the Record button on CAD or IPPA
Workflow configuration automatically triggers complete call
recording on certain types of calls for agents using CAD
In order to use the silent monitoring or recording features, it requires
access to the RTP (Real-Time Protocol) packet streams. Silent
monitoring and recording will work with either G.711 or G.729 RTP streams, and a
mixture of agents using G.711 and G.729 phones is supported. However, silent
monitoring and recording will not work with encrypted media streams. Unified CCX provides two mechanisms for access to the RTP packet stream—SPAN
port monitoring and desktop monitoring.
SPAN port monitoring requires the Unified CCX server to
be connected to the SPAN port of a VLAN on a Catalyst switch where voice
traffic from the agent phones can be captured. The SPAN port is like a
broadcast port for all data traffic (including voice RTP streams) traversing a
VLAN segment. When a supervisor clicks the Silent Monitor button on the CSD, it
signals to the Monitoring component to forward a copy of the captured RTP
streams for the selected agent to the requesting CSD. The CSD then plays the
packets through the sound card on the CSD workstation. No IP Phone (or any type
of phone) is involved when the silent monitoring stream is being played using
CSD. The CSD can reside anywhere on the Cisco Unified Communications network,
but no routing device should exist between agent phones and the Catalyst switch
where Unified CCX server is connected for SPAN port monitoring. The
Catalyst switch RSPAN feature allows a VLAN to extend across multiple Catalyst
switches. Please see Appendix B for more detail on SPAN port monitoring
Desktop monitoring provides a mechanism for the CAD
application to obtain a copy of the RTP packet streams directly from the phone
and therefore removes the need for a Monitoring component connected to the SPAN
port on the Catalyst switch. A Cisco phone supporting desktop monitoring is
required and the agent workstation running CAD must be connected to the data
port on the back of the agent phone. The Cisco IP Communicator also
supports using desktop monitoring for silent monitoring and recording.
For all deployments in which agents use CAD and agent phones support
desktop monitoring, use desktop monitoring instead of SPAN port monitoring.
When a supervisor clicks the Silent Monitor button on the CSD
for an agent using desktop monitoring, the RTP streams are sent directly from
CAD to CSD, and the SPAN port monitoring component is not required. However,
for silent monitoring to occur with desktop monitoring, at least
one VoIP Monitor service must be running. CAD uses this service to retrieve the
MAC address of the agent phone from the Unified CM. Appendix
C of the
Cisco CAD Installation Guide provides a quick and simple
test to determine if a workstation NIC will operate properly with the desktop-monitoring feature of CAD.
CAD recording is not designed for use as a compliance recording solution. The functionality is best deployed to facilitate on-demand recording or recording on a filtered list of calls only. Users must address requirements to record all calls by implementing a compliance recording solution.
CAD does not support 802.1Q VLAN-tagged traffic with SPAN based monitoring.
A Unified CCX deployment can have a mixture of some
agents using desktop monitoring and some agents using SPAN port monitoring.
If an agent call requires recording, a copy of the RTP
packet streams is sent to the Recording Server process. If the agent being recorded is using the desktop monitoring, CAD sends the RTP streams to
the Recording component. If the agent
being recorded is using SPAN port monitoring, the Monitoring component sends the RTP streams to the
Recording component. Agents can be silently monitored and recorded at the same
time. When that occurs in a desktop monitoring environment, CAD sends one copy
of the RTP packet streams to the requesting CSD and one copy of the RTP packet
streams to the Recording component.
A normal G.7xx VoIP RTP call has two RTP streams (one
representing what the agent is hearing and one representing what the agent is
saying). These two streams flow in opposite directions across the network. When
an agent call is being silent monitored or recorded, both of those RTP streams
must be sent. For example, if a supervisor is silent monitoring an agent, two
G.7xx RTP streams will be sent from either CAD (desktop monitoring) or the
Monitoring component to the CSD. If an agent call is being recorded, two G.7xx
RTP streams are sent to the Recording component. If the agent is being silent
monitored and recorded, four RTP streams are being sent. This is in addition to
the two bidirectional RTP streams of the actual call.
The monitoring and recording packet streams are true G.7xx
RTP streams and therefore these packets are tagged like any other RTP stream to
ensure that they are delivered with appropriate priority and minimal
latency. Chapter 6 further discusses bandwidth requirements.
The agent call recordings are stored on the hard drive of the
Unified CCX server with agent data store locator records pointing to the
actual recording files. The call recordings in Unified CCX are stored in
a raw format that can only be played using the CSD Record Viewer. The CSD Record
Viewer shows 7 days' worth of call recording as well as those tagged for 30-day
extended archiving. The CSD Record Viewer also provides the supervisor the
option to save selected individual recordings into a .wav format in a specified
The amount of disk storage allocated for recordings on a single-server non-high-availability deployment of Unified CCX is 2.6 GB.. On a two-server high-availability deployment of Unified CCX, the recordings are alternated between the two servers in a round-robin fashion to provide load balancing and redundancy. Hence the amount of disk storage allocated on each server is 2.6 GB for a combined solution storage of 5.2 GB.
The recording capability of Unified CCX is not intended
for use as a permanent recording archival solution. However, an export
utility is also available to bulk export all recordings into a .wav format. The
export utility has no ability to specify selected recordings and will export
all recordings on the Unified CCX server. System administrators can
build their own customized command macros or process to perform regular
(at least weekly) exporting of the recordings for permanent archival of agent
When a supervisor is playing back or saving a recording using
the CSD Record Viewer application, a recording resource is used and therefore
counts against the maximum simultaneous call recording capacity for the
duration of that recording playback. Maximum simultaneous call recording and
playback capacity depends on the server size. The
Cisco Unified CCX Data Sheet can help you choose
an appropriately sized server for the amount of recording required.
Because IPPA does not include an agent using CAD, IPPA
requires a SPAN port Monitor component on the local VLAN segment for silent
monitoring or recording. Also the Cisco Unified IP Phones 7902, 7905, 7912, and
7920 require a SPAN port Monitor component because there are either no data ports on
these phones or these data ports are not compatible with desktop monitoring.
IPPA also cannot be configured to have calls automatically recorded.
Unified CCX Premium is required for remote supervisory
monitoring. Remote supervisory monitoring provides a mechanism to silent
monitor calls using an IP Phone or PSTN phone. This form of silent monitoring
does not require a CSD or any data network connectivity and is ideally suited
for management from outsourcer customers of a call center service provider.
Agents are unaware when they are being silent monitored using remote
supervisory monitoring. A remote supervisor is configured with a numeric user
ID and password and also with the CSQs and agents that the remote supervisor is
allowed to silent monitor in this fashion. The remote supervisor then dials a
specific number that invokes a Unified CCX application. The application
begins by prompting the supervisor for the user ID and password. After the
remote supervisor is authenticated, the remote supervisor is prompted to choose to silent monitor calls for a specific agent or for a
specific CSQ. Then the Unified CCX application requests a copy of the RTP
streams for the selected types of calls, and the Unified CCX application
and CTI Port relays those packets to the remote supervisor's phone. Remote
supervisory monitoring works with both SPAN port monitoring and desktop
monitoring. However, remote supervisory monitoring only works with a Unified CCX Engine and CTI Ports and agent phones using G.711 encoding. Remote
supervisory monitoring also places an additional performance impact on the
Unified CCX server Unified CCX Engine. This activity is reflected
in the Cisco Unified Communications Sizing Tool.
For remote monitoring to work, the agent desktop must be daisy chained to the agent phone .
Cisco Unified Wireless IP Phone 7920 IP Phone support
Unified CCX supports use of the Cisco Unified Wireless
IP Phone 7920 Wireless IP Phone by agents. Agents can be using CAD with the
Cisco Unified Wireless IP Phone 7920 Wireless IP Phone, or agents can use the
IPPA interface with the Cisco Unified Wireless IP Phone 7920 Wireless IP Phone.
When planning to use the Cisco Unified Wireless IP Phone 7920 for agents with
Unified CCX, the following considerations need to be taken into account:
If a logged-in agent using a Cisco Unified Wireless IP Phone 7920
Wireless IP Phone roams outside Wireless Access Point (WAP) range for greater
than 60 seconds (possibly slightly longer depending upon Unified CM time-out), Unified CM unregisters the Cisco Unified Wireless IP Phone 7920
Wireless IP Phone (and ends any call in progress if the Cisco Unified Wireless
IP Phone 7920 Wireless IP Phone was off hook). This generates a device
unregistered JTAPI event to be sent to Unified CCX, which causes the Unified CCX agent state to change to
"not ready". When agents roam between WAPs, the hand off
occurs within a second or two (depending upon wireless LAN design, encryption,
and authentication techniques used). Therefore, roaming between WAPs is
supported. If an agent is using the Cisco Unified Wireless IP Phone 7920
Wireless IP Phone with CAD, but is away from the CAD workstation, there is no
way for the agent to know that the agent state is
"not ready" and there is no way for the agent to change the
agent state to
"ready". If the agent is using the Cisco Unified Wireless IP
Phone 7920 Wireless IP Phone with IPPA, then the agent can check the agent
state via IPPA and can change the agent state to
"ready" via IPPA. Therefore, if agents anticipate roaming
outside WAP range for greater than 60 seconds, then it is recommended that they
log in to Unified CCX via IPPA for that login session. If agents
anticipate working at their desk or not roaming outside WAP range, then it is
okay for them to log in to Unified CCX via CAD for that login session.
Due to the mobile nature of the 7920 phone, there are certain
conditions under which monitoring and/or recording calls may result in gaps in
Agent-to-agent conversations when both agents are using the
same wireless access point
When an agent roams from one monitoring domain to another
Deployment of 7920 wireless IP Phone in a Cisco Unified Wireless
Meshed Network based on 802.11n and 802.11i is highly recommended to eliminate
session time-outs during roaming between WAPs.
The Cisco Unified Wireless IP Phone 7920 Wireless IP Phone is not
supported as a second-line appearance for a wired IP phone for the Unified CCX agents. Second-line appearance is not supported for IPPA.
Cisco WAPs currently support only a maximum of seven G.711 or
eight G.729 active calls. Therefore, do not have a large volume of agents in
one location all using the Cisco Unified Wireless IP Phone 7920 Wireless IP
Phone. The maximum number of agents that can be equipped with Cisco Unified
Wireless IP Phone 7920 Wireless IP Phones depends upon the agent utilization of
the phone during busy hour, the codec being used by the phone, and the
proximity of agent phones to WAPs.
Use of the Cisco Unified Wireless IP Phone 7920 Wireless IP Phone
as an agent phone requires using SPAN port monitoring for supervisory silent
monitoring and call recording. This applies to the Cisco Unified Wireless IP
Phone 7920 Wireless IP Phone when used with either CAD or IPPA. The port that
is to be included in the SPAN is the one to which the WAP is wired. Unified CCX supports only one monitoring domain. However, that monitoring
domain may include multiple WAPs on the same VLAN segment. This will allow
agents to roam between WAPs and still be silently monitored by supervisors and
have their calls recorded. For Cisco Unified Wireless IP Phone 7920 Wireless IP
Phone caller to Cisco Unified Wireless IP Phone 7920 Wireless IPPA phone
conversations where both are on the same WAP, the RTP stream will not leave the
WAP and thus will never traverse the LAN segment that the SPAN port monitoring
server is monitoring. Therefore, silent monitoring or recording of those phone
calls is not possible.
For more details on designing wireless LANs with optimal Cisco
Unified Wireless IP Phone 7920 Wireless IP Phone QoS and necessary security,
please reference the campus design Solution Reference Network Design (SRND)
documents for wireless LAN and Cisco Unified Wireless IP Phone 7920 Wireless IP
Phone. These SRNDs can be found at:
Multiple lines support
Unified CCX provides multiple line support using the 6900/7900/8900/9900 series phones as agent devices. The Join Across Line (JAL) and Direct Transfer Across Line (DTAL) operations are supported on the 7900/8900/9900 series phones. Up to four lines are monitored by Unified CCX, including one ACD line and three non-ACD lines (but only the ACD line can be controlled from the agent desktop). The agent state depends only on the ACD line on the agent's device.
Unified CCX allows more than four lines to be configured on the agent device but monitors only the first four lines, provided these lines are not shared. The ACD line should be among the first four lines. The Agent can perform JAL and DTAL operations for the ACD call only by using the monitored lines.
The Unified CCX Engine receives CTI events on the first four configured lines of a monitored device, but it filters events that occur on non-ACD lines.
Cisco Agent Desktop does not show activities that occur on non-ACD lines with the exception of JAL calls that are on non-ACD lines.
Historical reports display call activity on monitored lines. Agent state is determined based on the ACD line only.
For agent devices with monitored non-ACD lines, make sure to include the non-ACD lines as the CTI controlled lines when performing sizing for Unified CM server(s).
Unified CCX agents may use Unified CM Session
Initiation Protocol (SIP) phone models 7941, 7961, 7970, and 7971. The 7940 and
7960 phones do support SIP with Unified CM 5.x and 6.x but may not be
used for Unified CCX agents (because the necessary third-party call
control and monitoring required is not present). The lower-end phone models are
also not available to be used as SIP phones for Unified CCX agents. SCCP
support for Cisco IP Phones continues to be supported for agent phones.
Unified CCX CTI ports are notified of caller-entered
digits (DTMF input) via JTAPI messages from Unified CM. Unified CCX
does not support any mechanism to detect in-band DTMF digits where DTMF digits
are sent with voice packets. In deployments with voice gateways or SIP phones
that only support in-band DTMF or are configured to use in-band DTMF, an MTP
resource must be invoked by Unified CM to convert the in-band DTMF
signaling so that Unified CM can notify Unified CCX of the
caller-entered digits. Be sure to enable out-of-band DTMF signaling when
configuring voice gateways in order to avoid using the previous MTP resources.
For detailed design consideration related to DTMF handling, media resources and
voice gateway deployments, please refer the
Cisco Unified Communications Solution Reference Network Design
Unified CCX does not support IPv6 but it can
inter-operate with Unified CM running in IPv6. All CTI Ports, CTI Route
Points and agent phones have to be configured as IPv4 devices. Unified
CCX servers, machines running the agent desktop and other optional servers (for
example, ASR/TTS, WFM, QM etc) should be running in IPv4 segment, However, the
calling device can be configured as either IPv4 or IPv6. Beware that if the
calling device is in IPv6 and the receiving device is in IPv4, Unified CM
dynamically inserts a media termination point (MTP) to convert the media
between the two devices from IPv4 to IPv6 or vice versa. This would have an
impact on Unified CM performance.
For more information on IPv6 deployment with Unified
CM, refer to the document
Deploying IPv6 in Unified Communications Networks with Cisco
Unified Communications Manager available at:
Citrix terminal services support for Cisco Agent Desktop
Unified CCX supports the running of CAD within a
Citrix terminal services environment. When planning to use Citrix terminal
services for CAD, the following considerations need to be taken into account:
All Cisco Desktop client applications are supported in a Citrix
terminal services environment. Refer to the Citrix integration document below
for the supported Cisco Desktop applications.
Desktop monitoring (for silent monitoring and recording) is not
supported with Citrix terminal services. SPAN port monitoring must be used.
Macros work only if they involve applications running on the
Citrix server, and not those running on the client PC.
Only one Citrix user name is supported per CAD application login.
Integrating CAD with Thin Client
and Virtual Desktop Environments
for implementation details. This document can be found
Unified CCX supports remote agents (for example,
at-home agents) using Cisco Unified IP Phone over a broadband internet
connection. The Cisco Voice and Video Enabled IPSec VPN (V3PN) ADSL or Cable
connection can use a Cisco 800 Series router as an edge router to the broadband
network. The Cisco 800 Series router can provide the remote agent with V3PN,
Encryption, Network Address Translation (NAT), Firewall, Cisco IOS Intrusion
Detection System (IDS), and QoS on the broadband network link to the Unified CCX campus. Remote agent V3PN aggregation on the campus is provided via
LAN to LAN VPN routers.
Cisco recommends using the Cisco 800 Series router with the
following features for remote agent over broadband:
Quality of Service (QoS) with Low-Latency Queuing (LLQ) and
Class-Based Weighted Fair Queuing (CBWFQ) support
Power over Ethernet (optional)
The Cisco 830, 870, and 880 Series routers are examples of
the recommended routers. Cisco does not support using the Cisco 850 and 860
Series routers for this application because they have limited QoS feature
The Cisco VPN Client feature available in select Cisco
Unified IP Phones provides another option for remote agents to connect their IP
Phones to the enterprise.
The enterprise will need to deploy and set up a Cisco ASA
5500 series Adaptive Security Appliance which supports SSL VPN connectivity as
detailed in the following link:
The VPN feature needs to be configured on the
Cisco Unified Communication Manager as per the Cisco Unified
Communications Manager Security Guide.
The Cisco Unified IP Phone should then be configured within
the enterprise as detailed in the
Cisco Unified IP Phone Administration Guide for Cisco Unified
Communications Manager. This guide can be accessed at the following
This guide also has the list of Cisco Unified IP Phones that
support the VPN Client feature.
After the IP Phone has been configured in the enterprise,
the agent can then take it home and connect it to a regular broadband router to
obtain VPN connectivity to the enterprise. The agent will then be able to use
the configured extension for receiving and placing calls from home.
Cisco TelePresence Virtual Agent solution
Cisco TelePresence CTS-1000
The Cisco TelePresence Virtual Agent solution enables
organizations to create a live,
"face-to-face" interaction with their customers—over the network
with Cisco TelePresence. The life-size, high-definition video, CD-quality
audio, and interactive elements of the TelePresence solution give customers the
feeling of being
"in person" with a specialist agent, while the agent maintains all
of the contact center functions that they would expect.
For example, a national bank has a limited number of
property insurance specialists on staff, resulting in customers being unable to
receive the guidance and service the bank wants to deliver. By providing
insurance and mortgage experts at branch offices through Cisco TelePresence
Virtual Agent, quality service is always available to customers. At the bank
branch, a customer can enter an office designated for the virtual agent, make a
selection on the Cisco Unified IP Phone, and have an in-person remote meeting
with an expert.
This solution consists of the following hardware and software
Cisco TelePresence System with single screen, for example,
CTS-500 and 1000
Unified CCX Software
Cisco Unified IP Phone 7970G (SIP), for caller and agent
Cisco Agent Desktop Software
Cisco Unified IP Phone 7970G phone includes the Cisco IP
Phone Service, the contents of which are sent over from the primary codec in
XML format over HTTP. The phone provides the user interface to interact with
the primary codec for call control and other functions. The phone and primary
codec are registered with Cisco Unified CM as SIP devices and they share the
same line appearance. However, on the agent side, the phone is associated with
the RmCm Provider user so that Cisco Unified CCX can monitor the phone for any
state changes. Because call signaling and media stream traverse through the
primary codec (but not the agent phone), the following guidelines apply:
Agent must perform all call control actions from the phone but not
Supervisor cannot perform barge-in or intercept from CSD.
Calls cannot be monitored or recorded.
Cisco TelePresence supports both wideband/AAC and G.711
audio codec. However, the virtual agent solution only supports G.711, which is
the common supported audio codec between Unified CCX and Cisco
TelePresence. Cisco recommends using Wideband/AAC audio codec for inter- or
intra-region setting when configuring Cisco TelePresence device. In this case,
Cisco TelePresence will automatically negotiate down to G.711 when connecting
to Cisco Unified CCX.
The figure below and the description that follows explain
the virtual agent solution call flow:
Customer (caller usually calls inside the corporate network) dials
a number to reach an application.
Cisco Unified CM finds the dialed number associated with a CTI
route point that is associated with a Unified CCX Unified CM Telephony
user for Unified CCX. This event triggers a JTAPI route request to be
sent to Unified CCX.
Based upon the DN, which is mapped to a Unified CM Telephony
trigger, Unified CCX finds an available CTI port and redirects the call
to the port. Unified CCX runs a script that finds an available agent and
reserves the agent. The call is transferred to the primary codec on the agent
side and the call is presented to the agent device.
The agent presses the "Answer" button on the agent device to answer
the call. This action causes Unified CCX to instruct Cisco Unified CM to
complete the transfer and establishes audio and video between the Cisco
Unified CCX supports Cisco TelePresence EX 60 and EX 90 endpoints as agent phones. You can configure these endpoints similar to other IP phones.
Deployment of Cisco TelePresence EX series endpoints with Unified CCX requires the engagement of the Cisco Remote Expert Team. For further guidance, see Cisco Remote Expert Design Guide, available here:
The following operations are not supported in Cisco Agent Desktop/Cisco Supervisor Desktop if you are using Cisco TelePresence EX 60 and EX 90 as agent phones:
Conference and transfer
Desktop monitoring and recording
Barge in and Intercept
However, you can perform all the call operations such as conference, transfer, barge in and intercept from EX 60/90 phones.
The following features are not supported if you are using Cisco TelePresence EX 60 and EX 90 as agent phones:
Multiline (ACD and non-ACD)
Unified CCX Outbound Dialer
Unified CCX supports the following outbound dialers:
Unified CCX Outbound Preview Dialer
Unified CCX Outbound IVR Dialer
Unified CCX Outbound Preview Dialer allows Outbound
agents to participate in outbound campaigns in addition to handling inbound
calls. This feature selects those agents who are not busy with inbound calls to
handle outbound calls, thereby maintaining a high level of agent productivity.
Unified CCX Outbound IVR Dialer allows for Outbound
calls to be placed to contacts in a campaign and subsequently for live contacts
to be serviced by an IVR application. Call progress analysis (CPA) capabilities
of the SIP Voice gateway are used to filter non live contacts (which could be
fax and no answer). Live calls which are answered by a
customer and answering machine contact are transferred to a CTI route point to be serviced by an
associated IVR application. An Outbound IVR call that is answered by a customer
contact but cannot be serviced due to unavailability of an IVR port is said to
The figure below and the following table describe the
components involved in Cisco Unified Outbound:
Figure 4. Cisco Unified Outbound components
Responsible for starting and stopping each campaign and
retrieving and updating contact records from and to the database.
Receives contacts from the Campaign Manager and initiates
the outbound calls. Notifies the Campaign Manager of the call status and call
result after the call is answered. The dialer software is IP based and does not
require any telephony cards for making outbound calls. In Outbound Preview, the
dialer uses the CAD agent IP phone to place outbound calls through a voice
gateway configured in Unified CM. In Outbound IVR, the dialer uses the
SIP protocol to place outbound calls through the SIP gateway configured for the
Outbound IVR feature.
Monitors agent states, reserves agents and receives
instructions from the Dialer to place the outbound call. This component is used
only in the Outbound Preview feature.
Handles requests and responses from and to the CAD and
passes the customer data to the CAD for screen pop. This component is used only
in the Outbound Preview feature.
Responsible for execution of the IVR application
associated with the campaign when a live contact has been detected by the SIP
gateway and transferred to the configured CTI Route Point on the Unified
CM. This component is used only in the Outbound IVR feature.
Config Datastore (CDS)
Contains the customer contacts information.
All of these components run as part of the Unified CCX
Engine and cannot be installed separately.
There are typically four types of dialing modes in today's
outbound ACDs: predictive, progressive, preview, and direct preview.
The Outbound Preview feature supports only the direct
preview dialing mode. It uses a 3-stage process for making an outbound call. The
first stage is to find an available agent and retrieve the customer information
for making the outbound call. The second stage is the reservation call, and its
purpose is to reserve an agent and send customer data to the agent desktop.
During this stage, the agent is reserved and the data appears on the desktop so
that the agent can review the data and decide whether to accept the call by
pressing the corresponding button on the CAD. If the agent does not accept the
call, the call is handled by other outbound agents or closed for the campaign.
If the agent does accept the call, Outbound Preview kicks in the last stage
where Unified CM is instructed to place the outbound call using the CAD
agent's phone. When the outbound call is answered, Outbound Preview updates the
customer contact in the database with the call status and call result.
When the outbound call connects with the customer, the agent
can perform all call control operations that are normally supported on inbound
calls (transfer, conference, hold, retrieve, and so on). Cisco recommends that
the agent transfers or conferences the outbound call only if the call is
answered by a person but not through other media such as an answering machine
or a fax machine.
The Outbound IVR feature supports two types of dialing modes
namely progressive and predictive. Each dialer dials an appropriate number of
contacts to make efficient use on the available system resources (IVR Ports).
Both algorithms use a ratio called lines per port (LPP) to determine the number
of outbound calls to place per available IVR port.
Progressive algorithm uses an LPP value configured by the
administrator via Unified CCX Administration.
Predictive algorithm dynamically varies the LPP to ensure
that the abandon rate does not exceed the threshold configured via Unified CCX Administration (abandon rate is the percentage of live calls that
had to be dropped due to the unavailability of an IVR port).
Outbound IVR uses the Call Progress Analysis (CPA)
capability of the SIP gateway to place and filter outbound calls. The SIP
gateway filters out non-live contacts such as fax, invalid
number, and no answer and forwards only the live calls answered by a customer
contact and answering machine to a CTI Route Point on the Unified CM. This in turn triggers
execution of an IVR application associated with the campaign at Unified
You can use the IVR campaign only with service providers that work with TDM, because such gateways support CPA capability, which is an IVR feature. Gateways using SIP or H323 trunks do not support CPA; hence the IVR campaign does not work with such service providers.
Behavior under high availability
The CDS is required for normal operation of Outbound for call status and call result updates of contact records. When deploying in a two node high availability system, as long as the publisher CDS is up, the Outbound subsystem will be operational.
The following events occur during a failover in Outbound Preview:
If a reservation call is at the agent desktop waiting for the agent to accept the call, and the master engine goes down, the agent is automatically logged out and the reservation call disappears from the agent's desktop. If the master engine restarts during failover, the call status for that contact record is be set to unknown. If the master engine does not restart during failover, the contact is called when the campaign starts and there are available agents.
If a reservation call has been accepted by the agent and the call is ringing on the customer phone, there is no effect on the call. However, the agent is logged off and will be able to invoke call control capabilities only through the phone.
In the case of Outbound IVR, the CTI ports on the master engine will go out of service on a failover, which will result in calls in progress between customers and CTI ports to be disconnected. The standby server will resume dialing out the remaining contacts in the outbound IVR campaigns after the failover.
When deploying Outbound in a high availability environment, only the dialer in the master node is active. Outbound calls cannot be distributed or load balanced to the dialer in the standby node.
Outbound Preview supports different capacities and limits
when compared to inbound agents. Refer to Chapter 1 for more details.
For Outbound IVR, the number of active outbound IVR ports is
limited by the maximum number of Outbound IVR ports that are supported for a
given platform. In addition, the sum of the active IVR ports in use for inbound
and outbound cannot exceed the maximum number of IVR ports that are supported
for the platform. Refer to Appendix A to find these limits on the
IVR ports for your platform.
Since IVR for inbound and outbound contend for the same set
of IVR ports, the actual number of active IVR ports in use for inbound and
outbound depends on multiple parameters:
Number of licensed inbound ports
Number of licensed outbound ports
Sum of the number of ports dedicated across outbound IVR
Please refer to the
"Configuring Unified CCX Dialer" chapter of the Unified CCX
Administration Guide for details on how the numbers of active IVR ports for
inbound and outbound are determined by the above parameters.
In the direct preview mode, the agent hears the ring-out on
the agent phone. The direct preview call flow proceeds as illustrated in the
figure below and the description that follows.
Figure 5. Call flow for direct preview mode
An agent in Ready state is available and the Dialer has retrieved
contact records from the Campaign Manager. The Dialer requests the Resource
Manager to reserve the agent.
The Resource Manager reserves the agent by moving the agent to
The Dialer sends a reservation call to the agent desktop and, at
the same time, a screen pops that contains the customer information and is
presented to the agent. The agent reviews the customer data and decides whether
to take the call.
The agent can choose to accept, skip, reject, or cancel this
reservation call. If the agent chooses to accept it, the agent clicks the Accept
button on the desktop.
The Dialer instructs the Resource Manager to place an outbound
call from the agent phone via Unified CM out to the voice gateway.
Because this call is a direct preview call, the agent immediately hears the
ringback of the customer phone.
Note that no CTI Port is needed to place the outbound call.
As soon as the call is answered, the Dialer closes the contact,
classifies it as a voice call and sends the result to the Campaign Manager. If
an answering machine answers the call, the number is invalid, or the customer
requests a callback, and the agent can reclassify the call from the desktop
accordingly. If the customer requests a callback and the agent reclassifies the
call, the customer is called back using the same number, an alternate number,
or a callback number specified by the customer.
The call flow description for Outbound IVR is illustrated in
the figure below and the description that follows.
Figure 6. Call flow for IVR mode
Outbound IVR dialer determines the number of contacts to dial per
the configured algorithm (progressive or predictive) and places outbound calls
using SIP through the voice gateway.
Voice gateway detects non live contact via its CPA capabilities
and sends status of non live contact to the dialer. The dialer uses this to
update contact status information in the configuration database.
Voice gateway detects live contact via its CPA capabilities and
sends status of live contact to the dialer. The dialer uses this to update
contact status information in the configuration database and also sends a SIP
refer message to the SIP gateway which in turn transfers the call to the
configured CTI Route Point on Cisco Unified CM.
Cisco Unified CM transfers the call to a IVR port on Cisco Unified
The IVR subsystem then associates the call with the IVR
application associated with the campaign. The engine starts execution of the
application and an IVR session takes place between the IVR application for the
campaign on Cisco Unified CCX and the customer contact.
The following guidelines should be followed when deploying
Outbound supports a maximum of 15 campaigns and a maximum of
10,000 active outbound records for each campaign.
Outbound does not come pre-installed with any US National Do Not
Call lists. The system administrator should manually filter the contact list
against the Do Not Call list prior to importing contacts.
The following guidelines are specific to Outbound Preview:
Outbound Preview supports a maximum of 10 CSQs for each campaign.
Only CAD agents are supported. IPPA agents are not supported.
Outbound Preview cannot detect an answering machine, fax, or
modem. The agent should manually reclassify the call to
"answer machine" or
"fax" from the desktop. The contact will be called again using
the same number (in the case of
"answer machine") or using an alternate number (in the case of
Agent should not transfer or conference the outbound call if the
call is answered by the media other than a person, such as an answering machine
or fax machine.
The following guidelines are specific to Outbound IVR:
It is possible to only have a single instance of the SIP gateway
in the deployment.
Cisco recommends to install the SIP Gateway on the same site
(i.e., same campus LAN) as the Unified CCX primary engine. However, if
the SIP Gateway is installed over the WAN from the Unified CCX primary
engine, it is still supported but not recommended.
The primary engine is always the first node that was installed
in the Unified CCX cluster and cannot be changed.
No redundancy of the SIP Gateway or usage of any SIP Proxy is
The protocol supported between the SIP Gateway and Unified
CM for transferring the outbound call to an IVR application includes SIP and
It is possible to use the same gateway for both inbound and
Unified CCX Agent E-mail
As part of the Premium offering, Unified CCX agents
can service customer e-mails using the CAD interface. This capability does not
exist with Cisco Agent Desktop - Browser Edition.
CSD includes real-time displays and information that enable
supervisors to manage e-mail CSQs and their e-mail capable agents. When creating
a CSQ in Unified CCX Administration, you designate the CSQ as either
e-mail or voice. A single CSQ cannot be both an e-mail CSQ and a voice CSQ. Agent
association with e-mail CSQs is done in the same manner as voice CSQs.
The agent states READY and NOT READY for e-mail and voice are
independent of each other. An agent can handle both e-mails and voice calls
simultaneously. An agent can receive e-mails only if he manually moves himself
to email READY state. Only agents that have been assigned to at least one e-mail
CSQ will see the e-mail functionality in CAD. Likewise with supervisors; only supervisors that service at least one e-mail capable team OR at least one e-mail capable agent will see e-mail functionality in CSD.
The Agent E-mail feature requires the use of an external mail
store (Microsoft Exchange is supported). This mail store is not provided,
installed, or configured as part of the CAD installation.
Agent E-mail uses the IMAPv4 (for message retrieval) and SMTP
protocols (for message sending). These protocol types must be enabled in
Microsoft Exchange and host/IP information must be specified using Cisco
Desktop Administrator. These protocol types are not typically enabled by
default. CAD and the Cisco Desktop Agent E-mail Service make IMAP connections to
the mail store. Cisco Desktop Agent E-mail Service also makes an SMTP connection
to the mail store. Agent E-mail supports both secure and plain text connections
to the mail store.
CAD components (Cisco Agent Desktop and Cisco Desktop Agent
E-mail Service) will connect to the mail store using a single dedicated mail
store account. This account must be created by the mail store administrator.
CAD must be configured to use this account via Cisco Desktop Administrator.
This account should be a dedicated account, and not used for purposes other
than the Agent E-mail feature.
While CAD uses a single e-mail account, it can, and typically
will, have multiple distribution list addresses associated with that user. This
e-mail account and corresponding distribution lists must be configured manually
by the mail store administrator. Routing information for the distribution list
addresses can then be specified using Cisco Desktop Administrator.
Review CSQs can be associated with normal email contact
CSQs. E-mails sent from a Contact CSQ associated with a Review CSQ will be
transferred to the Review CSQ. Members of a Review CSQ who receive e-mails
transferred in this manner will be able to perform all of the normal e-mail
operations on the message, including editing the draft, and transferring,
requeuing, and sending the message.
Messages sent from a review CSQ will be sent using the
configured email address of the original CSQ that the message was sent from.
An additional restriction is imposed on the Transfer feature for
normal CSQs which prevents transfer to Review CSQs.
In addition to the CSQ setting, an agent must belong to a workflow
group that has been configured to be reviewed. This configuration provides
flexibility in configuring which agents should be reviewed, and to what CSQ the
reviewed messages are sent.
Microsoft Exchange allows you to associate multiple e-mail addresses
with an e-mail account. Administrators may be tempted to use this feature
instead of distribution lists. However, Microsoft Exchange may rewrite the To:
address in the incoming e-mail to the primary address of the account, which then
causes the Agent E-mail feature to be unable to properly route e-mails to agents.
Agent E-mail supports secure IMAP and SMTP connections to the mail
store. For more details on the specific security settings that are supported,
Cisco CAD Installation Guide.
Figure 7. Unified CCX Agent E-mail components and interfaces
The following steps describe how an email is routed using
the Agent E-mail feature:
The Cisco Desktop Agent E-mail Service on the Unified CCX
server connects to the mail store (IMAP and SMTP) on startup.
An e-mail capable agent in the e-mail CSQ logs in using CAD. CAD
connects to the Cisco Desktop Agent E-mail Service and to the mail store (IMAP).
The agent goes to an e-mail ready state. CAD requests an e-mail from
the Cisco Desktop Agent E-mail Service.
A customer sends an e-mail to, for example, firstname.lastname@example.org.
The website email@example.com is a distribution list with Agent E-mail's
account as the only member. Microsoft Exchange presents the e-mail to that
The Cisco Desktop Agent E-mail Service has been monitoring the
Agent E-mail's account inbox, and sees the new e-mail. Based on the routing rules
specified in Cisco Desktop Administrator, it sees that e-mails to
firstname.lastname@example.org are associated with the e-mail CSQ and that an agent in
the e-mail CSQ is in the Ready state. The service then assigns the e-mail to the
agent and notifies the agent.
CAD receives notification of the assignment and retrieves the
e-mail from the mail store directly.
The agent is presented with the e-mail from the customer.
The agent authors a response and presses the
If review CSQs are enabled, the message is routed to the review
CSQ before final approval is sent out.
The agent's response is saved to the outbox folder on the mail
store using IMAP commands.
The Cisco Desktop Agent E-mail Service periodically checks the
outbox folder and sends all messages in it.
Cisco Agent Desktop integration with Cisco IM and Presence
CAD agents and supervisors communicate with each other via the chat services built into the desktop
applications. If you have deployed Cisco IM and Presence in their
environments, agents and supervisors can use these same desktop applications to
see the presence status of SMEs as well as other critical members of the
enterprise, and to initiate chat sessions with them. The SMEs use the Cisco
Unified Personal Communicator to initiate chat sessions with agents who are
configured as Cisco IM and Presence users and respond to the chat requests
from them. SMEs can also use Microsoft Office Communicator or other clients
that are supported with Cisco IM and Presence if Cisco IM and Presence is
configured to support federated users. The Cisco IM and Presence integration
feature is available in the Standard, Enhanced, and Premium packages.
For example, a customer calls a Cisco Unified Contact Center
that has integrated Cisco IM and Presence with CAD. The customer's call is
routed to an available agent. If the agent requires assistance in addressing
the caller's needs, the agent can launch the contact selection window from the
Agent Desktop toolbar. The contact selection window will display the presence
status of other agents, supervisors, and SMEs who are assigned to the agent's
work flow group. The agent can then select a contact who is available and
initiate a chat session with the contact. If appropriate, the agent can also
use the contact selection window to conference a contact into the call, or even
transfer the customer's call to the contact.
The figure below and the description that follows describe
how various components of Cisco Agent Desktop and Cisco IM and Presence
interface with each other.
Figure 8. Interface between Cisco Agent Desktop and Cisco IM and Presence
Cisco Desktop Administrator retrieves LDAP configuration profile
through the SOAP Interface.
Cisco Desktop Administrator binds to the LDAP server for SME
searches and information, such as name and telephone number.
Administrator places SMEs in logical groups called contact lists
and then assigns them to specific work flow groups. This way, Administrators
can segment contact lists and ensure that only those agents assigned to a
specific work flow group have visibility to the appropriate contact list. This
configuration is saved in CAD's LDAP so that each agent/supervisor does not
have to access the Unified Presence's LDAP server which might have limitations
on number of connections, etc. Administrators can also control the SMEs ability
to see the agent's present state.
CAD retrieves the contact list associated with the agent's workflow
CAD retrieves various configuration profiles via the SOAP
interface, for example, Unified Presence server information.
CAD sends a SIP REGISTER to register with Cisco IM and Presence,
followed by individual SIP SUBSCRIBE messages for each user in its contact
list. CAD also sends a SIP SUBSCRIBE for
"user-contacts" for contacts configured on Cisco IM and Presence. A SIP NOTIFY is received whenever a contact in the contact list
changes state. CAD does not allow agents to change their presence states. It
only sends a single SIP PUBLISH message to Cisco IM and Presence when an agent
Call Control is done via the existing CAD main window using
CTI. All SIP traffic and presence information sent between CAD and Cisco IM and Presence is not encrypted and is done via TCP or UDP.
Cisco IM and Presence can assign the users registered with
it across all nodes within the Cisco IM and Presence cluster. If the user
attempts to connect to a node that is not assigned to him, CAD will connect to
the SOAP and Presence servers specified in redirect messages from the
All communication between CAD agents and SMEs is via the
Cisco IM and Presence server and is not routed through any CAD server. Refer
the chapter on
Cisco IM and Presence in the Cisco Unified Communications
SRND for deployment guidelines.
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 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 CCX 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.
Cisco Unified Workforce Optimization
Cisco Unified Workforce Optimization (WFO) for Unified
CCX is a full-featured solution for optimizing performance and quality and is
an integral component of the Cisco Unified Communications System. WFO suite
provides these solutions:
Workforce Management (WFM)—Allows for forecasting and development
of schedules for agents across multiple sites and channels. It also provides
real-time dashboards, enabling supervisors to track key performance indicators,
and manage agent's adherence to schedules.
Quality Management (QM)—A voice and screen recording, compliance
and evaluation solution for agent performance optimization and dispute
The figure below shows the overall service communications
medium between the WFO solutions and the Unified CCX system.
Figure 9. Service communications medium between WFO solutions and Unified CCX
This figure illustrates a couple of integration points
between the WFO solutions and Unified CCX system.
Workforce Management - Uses the ACMI link to monitor agent's
adherence to the schedules. It uses the ODBC link to download the historical
data from Unified CCX database to generate the forecasting data.
Quality Management - Uses JTAPI to monitor the call progress on
the agent phone so that it knows when to start and stop the voice recording. It
uses the ODBC link to download the agent, supervisor and team configuration
data from Unified CCX database.
For more details on components architecture, deployment
configuration and sizing, refer the
Cisco Workforce Optimization System Configuration Guide
available at the link:
Unified CCX allows integration with Media Resource
Control Protocol (MRCP) compliant Automatic Speech Recognition (ASR) and
Text-To-Speech (TTS) servers. Nuance, Scansoft, and IBM are the only ASR and
TTS providers that have been tested and will be supported. ASR and TTS software
must be purchased from one of these vendors. These vendors can provide design
and server sizing requirements for their software. Cisco no longer resells
Nuance ASR and TTS as a Unified CCX option.
From Unified CCX Administration, you must configure
the address of an MRCP server and the number and type of resources provided by
that MRCP server. Multiple Unified CCX clusters can interact with the
same MRCP servers. Multiple Unified CCX servers can interact with the
same MRCP servers. A Unified CCX server can also define multiple MRCP
servers, and resources from those servers are selected based upon the system
and application configuration.
Calls requiring ASR require the Unified CCX Engine to
pass the media stream from the CTI port to the ASR Server. This activity
impacts system performance and system sizing. The impact is reflected in the
Cisco Unified Communications Sizing Tool.
When using ASR, the ASR resource is allocated at the time of
the first step that uses ASR. The ASR resource is then allocated for the
duration of the call. When using ASR, you must calculate the required number of
ASR resources (ports) similar to the way you calculate any IVR port
requirement. You will need the average time the ASR port is used (similar to
average call treatment time) and the number of calls using ASR in the busy
hour. You can then input this data into any Erlang-B traffic calculator or
other tool to compute the number of ASR resources required. In environments
where you have long queue times, it might be economical to transfer the call to
another CTI Route Point and pass call data to the second application (via
session data steps) in order to allow the ASR resource to be released.
For TTS, each
"Generate TTS Prompt" allocates and releases a TTS resource, and
the TTS resource is typically only allocated for a couple of seconds and then
released (this might vary depending on the application). To determine the
number of TTS resources, use the same methodology described above for ASR
Unified CCX integration with Unified ICME software
Unified CCX can also be implemented as a child ACD of
Cisco Unified Intelligent Contact Management Enterprise (Unified ICME)
software. The Unified CCX integration with Unified ICME software
requires a Unified CCX Gateway PG process to be on a separate server from the
Unified CCX. This integration provides the following capabilities:
The ability for Unified CCX to send agent, queue, and call
state changes to the Unified ICME.
The ability for Unified ICME software to intelligently route
and load balance calls across multiple ACD sites which can include one or more
Unified CCX systems, Cisco Unified Contact Center Enterprise (Unified
CCE) systems, or traditional ACDs (that are supported by Unified ICME
software). Calls routed to a Unified CCX application can also be sent
call data so that it can be popped onto an agent's screen.
The ability for Unified CCX to send post-route requests with
call data to the Unified ICME in order to request intelligent routing
instruction. This could be in response to a transfer request from an agent or
from a step within and Unified CCX application running on a CTI port.
The ability for ICM software to provide multi-site ACD reporting
for a mixed network of ACD sites which can include one or more Unified
CCX systems, Unified Contact Center Enterprise systems, or traditional ACD's.
The ability for Unified CCX to send post-route requests with
call data to the Unified ICME software in order to request routing
instructions. This could be in response to a new call that just arrived at
Unified CCX or a call that is being transferred from an IVR port or
agent. Call data included in the post-route request can be used by the Unified ICME software to profile route the call, and call data is also passed
to the terminating ACD site (Unified CCX, Unified CCE, or
traditional ACD) for an agent screen pop.
This parent/child deployment is not supported when Unified CCX
is integrated with Unified ICME.
The following figure shows one Unified ICME
integration deployment scenario. In this scenario, the Unified ICME
routes and load balances calls between two Unified CCX deployments. A
separate deployment of Cisco Unified IP IVR's is also included to demonstrate
how additional IVR capacity (beyond 300 IVR ports) could be added to a Unified CCX deployment. The IVR PG allows call data from IVR applications to be
passed to Unified CCX agents at either site. The IVR PG could also
connect traditional IVRs (that are supported by the Unified ICME) to
allow an organization that has existing IVR applications to continue using
those IVR applications.
Figure 10. Unified CCX gateway solution with two Unified CCX
The following figure shows another Unified ICME
integration deployment scenario. In this scenario, the Unified ICME
routes and load balances calls between a Unified CCX site, a Unified CCE site, and a traditional ACD site. Call data for agent screen pop
can be passed between these sites via the Unified ICME.
Figure 11. Unified ICME integration with two Unified gateway sites
and one traditional ACD site
For Unified CCX to integrate with Unified ICME
software, there must be a Unified CCX Gateway PG installed on a separate
server from the Unified CCX server.
The Unified CCX Gateway PG must be ordered as a part
of the Unified ICME software suite. The Unified CCX Gateway PG
software is installed from the Unified ICME software installation CD—not
from the Unified CCX software CD.
Partners must have Unified ICME/Unified CCE ATP status to
order and deploy the Cisco Unified Gateway PG with Unified ICME software.
The Cisco Unified Communications Sizing Tool can assist
solution planners and designers in sizing the hardware required for a Unified CCX deployment.
When the Unified ICME routes calls to Unified
CCX, it is really routing them to a Unified CM dialed number. Then Unified CM goes through the process of resolving the dialed number association
to the CTI Route Point and Unified CM Telephony user and offering the
call to Unified CCX. Unified CCX then invokes the appropriate
For more information about the Unified CCX Gateway,
Cisco Unified Gateway Deployment Guide.
Unified CCX fault tolerance
The Unified CCX solution offers a number of
capabilities to provide fault tolerance. To begin with, a Unified CCX
deployment utilizes a Cisco Unified Communications network composed of Cisco
data switches and routers, which provide for a highly available data network
with many options for redundancy. Cisco campus and network design guides
discuss best practices for designing highly available networks with Cisco
switches and routers.
A Unified CM deployment utilizes a cluster approach
with up to eight call processing servers per Unified CM cluster. Unified CM groups devices (voice gateways, IP Phones, and CTI Ports) into
device pools and allows for device pools to have a primary, secondary, and
tertiary Unified CM server. When a device pool's primary Unified CM
server fails, the devices within that device pool automatically fail over to
the secondary or tertiary Unified CM server. Unified CCX CTI Ports are
grouped together into CTI call control groups (often called a CTI port group).
Each CTI port group is configured as part of a device pool. Unified CM
also supports voice gateways deployed at many locations with trunks from
different service providers.
Unified CM has a subsystem called the CTI Manager that
abstracts the device management from the JTAPI communications to an application
server (like Unified CCX). This implementation allows an application to
not be concerned with what specific server a device (voice gateway, agent
phone, or CTI port) is currently registered. Unified CCX has the ability
to communicate with up to two CTI Managers within a Unified CM cluster,
but only actively communicates with one at a time. If the active CTI Manager
subsystem or the Unified CM node running the active CTI Manager fails,
Unified CCX closes the sockets for all CTI ports and immediately begins
JTAPI communications with the backup CTI Manager. Calls being handled by agents
survive, but if their phones are registered with the failed Unified CM,
they will not be able to perform any subsequent call control. Upon completion
of existing calls, agent phones will automatically re-register to the secondary
Unified CM server. For agents who were not off hook, their phones will
re-register to the secondary Unified CM immediately.
In addition to being able to fail over to another Unified CM node within the cluster, Unified CCX itself provides a
clustering mechanism. In a high availability deployment, up to two servers can
be deployed, each server configured with the Unified CCX Engine and
Database components with the optional, Monitoring and Recording components.
The four components all provide some level of redundancy and
fault tolerance, but each functions a bit differently.
When deploying with high availability, two Unified CCX Engine components must be deployed on separate servers. If one server initiates the engine mastership election first, it becomes master. The other server becomes standby. If both servers are started approximately at the same time, it is not specified which server becomes master. If the Unified CCX Engine component server fails over, the standby server becomes the master server and remains as the master server until another failure occurs. Any active calls being processed by applications on CTI Ports will be released upon failure of the master Unified CCX Engine server.
All ACD, IVR, and desktop services will failover within 5 seconds in a LAN environment and 12 seconds in a WAN environment. Any incoming call arriving at Unified CM destined for Unified CCX route points can be accepted by the Unified CCX engine and all Unified CCX call treatment and ACD routing services are operational. During failover, agents are automatically logged out and then back into the ACD. The simultaneously logging in large numbers of agents can take significantly longer than the general, more random, log in of individual agents. It is not uncommon for agents to experience log time is excess of 1 minute in a LAN environment and 3 minutes in a WAN environment. Additionally, system and network delays could significantly impact the ultimate login time of each agent.
Historical Report generation is done by giving preference to non-Engine master node so that generation of Historical Reports does not affect the Unified CCX Engine performance. In a two-node scenario, if the current Engine master fails, the historical reports are generated from the new Engine node. Therefore, in a deployment with high availability and with both Unified CCX servers running, the maximum number of historical reporting sessions that is supported during normal operating hours is higher. If a server fails, this number reverts to the limit in a deployment without high availability. Note that this support for higher number of historical reporting sessions in a high availability deployment only applies to newer platforms. Refer the Cisco Unified Communications Sizing Tool for the limits on each platform.
For Web Chat, the Unified CCX uses SocialMiner in the same way the Unified CM is used for voice calls.
SocialMiner does not support High Availability (HA) deployment options. The fault tolerance for Web Chat is provided in the Unified CCX. In an HA deployment, SocialMiner is configured to communicate with both the Unified CCX nodes. When a new contact arrives at SocialMiner, both the Unified CCX nodes are notified. The master server takes the contact and queues it in its service queues, and the secondary server ignores the notification about this contact.
If a chat agent is logged in to the Unified CCX and there is a failover, the agent is logged out from the Cisco Agent Desktop and is redirected to the new master server with a login prompt. An agent who is busy in an active chat with a customer continues with the chat session until it is terminated by either the agent or the customer. This agent cannot make any subsequent state transitions due to the failover. The agent should log out to be automatically redirected to the new master server.
In the case of a failover, all queued or unread contacts are reintroduced by SocialMiner into the Unified CCX, and the new master server will queue these contacts and start the allocation.
When deploying with high availability, for Historical Data store, Agent Data store, and Repository Data store, the two servers running the Database components are set up with one being the publisher and one being the subscriber. These roles do not change in the event of a failure. If both the publisher and the subscriber are up and running, the server running the Engine Master is given DB mastership, where data is written to and read from.
If the database is down on the Engine Master, the other server (which is not the Engine Master) is given the DB mastership, where data is written to and read from. Informix Enterprise Replication replicates the data between the publisher and subscriber. Database replication will be automatically removed along with an alert sent to the administrator when the two nodes are unable to communicate for an extended period of time and the replication queue (which holds the data to be replicated) becomes full. Historical data, agent data and repository data may still be written on both the databases when replication is removed, but will not get replicated. Once the root cause of the replication has been identified (say a network issue) and fixed, the command to reset replication should be issued from Unified CCX Administration or from the CLI. This will result in the replication being set up followed by merging of data between both the nodes by means of a repair process. Merging ensures that the data on both the nodes is the same after the repair process. The state of this repair process can be monitored from Unified CCX Serviceability.
Under normal call load volume, a latency of 1 to 3 minutes for Informix Enterprise Replication is expected; this period could be higher for higher call load. The effect could be more when historical reports are running as it affects the SQL processing. Due to replication latency, the historical reports that are generated from a subscriber might not have the latest call records; the historical reports will be generated up to the last replicated time.
Distributed transactions with the Java Transaction Manager are used to replicate Configuration Data Store data in high availability deployments. The way it works is that when both servers with Database components are operational, configuration data store changes, such as skills and resource groups, are written to both the servers with Database components. If one server with a Database component is down, configuration data store changes are not possible. However, configurations can be read in Unified CCX Administration; that is, no configuration data store data writes are possible, but data reads are possible when one server with a Database component is down. However, call processing, historical data writing, and call activity reporting can continue even when one Database component is down.
In the case where the secondary Database server is not operational and configuration data store changes are required, you can temporarily deactivate the configuration data store component on the secondary Database component server using Unified CCX Serviceability. After that, you can make configuration data store changes on the active (primary) Database server. Once the secondary Database server is back in service, you can activate the configuration data store component on that Database server during off-peak hours as the whole active database configuration data store data will get synchronized.
When the network is partitioned (split into two islands), each island elects its own master. When the partition is restored, the primary engine is always elected as the master and the other node becomes the standby. As a result, all calls with the primary engine node remain and all calls under treatment or in queue with the other node are dropped. This primary engine concept does not apply to the master election process in the normal failover. It only applies to the master election after partition restoration or master election initiated from Unified CCX Administration website.
The primary engine is always the first node that was installed in the Unified CCX cluster and cannot be changed.
Unified CCX Monitoring and Recording redundancy
The Monitoring component is automatically installed on the
Unified CCX server and should be activated to enable agent monitoring.
When deploying with high availability and agent monitoring, the Monitoring
components on each server should be activated. The two servers running the
Monitoring service are sometimes considered as one
monitoring domain. When configuring a phone with SPAN port
monitoring, only one SPAN port monitoring server can be assigned to this phone.
When desktop monitoring is configured, CAD forwards the RTP
stream to CSD. A server running the Monitoring component is still required for
CAD to retrieve the agent phone's MAC address from the Cisco Unified CM. Any
one of the two monitoring servers could be chosen for this purpose. If one
Monitoring components fail, desktop monitoring still works, as long as the
other server running the Monitoring component is still available in the Unified CCX cluster. It is possible to configure and enable both SPAN port
monitoring and desktop monitoring for a phone. However, only one method is used
at any time for that phone. If both SPAN port monitoring and desktop monitoring
are configured correctly, desktop monitoring is chosen. If desktop monitoring
fails, SPAN port monitoring is used as a backup. Refer the
Cisco Desktop Administrator User's Guide for more
When deploying with high availability and agent call
recording, the Recording components on each server must be activated. The two
physical recording servers work as a single logical recording server (a
recording domain) and recording tasks are load balanced in a
round robin fashion across the two physical Recording Servers. A Unified
CCX deployment only supports one recording domain. The actual call recordings
are stored only on the disk of the physical Recording component server where
the recording task took place. Therefore, if a recording server fails, the
supervisor will be unable to playback those recordings on the failed Recording
server until that Recording server is operational again.
The two servers where the Recording components are running
also serve as a backup for each other. To function properly during a period
when one of the servers fails, the two Recording servers must be sized to be
capable of supporting all recording for the Unified CCX cluster. For
example, under normal operating conditions, a large call center may be set up
to handle 16 recording sessions on each Recording component, for a total of 32
simultaneous call recordings. If either server with a Recording component
fails, the other server processes all call recordings. In this failure
scenario, make sure that the total number of call recordings does not exceed
the server capacity that is shown in the Cisco Unified Communications Sizing
Recording requires a Monitoring component. When SPAN port
monitoring is configured for silent monitoring, the SPAN port monitoring server
forwards the RTP stream to the Recording component. If that SPAN port
monitoring server fails, recording is not possible. When desktop monitoring is
configured, the Monitoring component is still required in order for CAD to
retrieve the agent phone's MAC address from the Unified CM. Either of the
two monitoring servers could be used for this purpose. If one Monitoring
component fails, recording still works, as long as the other server running the
Monitoring component is still available in the Unified CCX cluster.
Unified CCX 9.0 upgrade
Unified CCX 9.0 supports software upgrade from previous
versions. Refer the
Cisco Unified CCX Installation Guide from the link below for
compatible upgrade versions. If you wish to upgrade to 9.0 and add high
availability, one additional physical server of equal performance as the
existing server must be added.
The Windows to Linux upgrade tool, which is downloadable from
CCO, can be used to upgrade from select versions of earlier Unified CCX Windows
releases to the CCX 9.0 release.
Unified CCX software compatibility
Unified CCX software is dependent upon integration with
many other software components, especially Unified CM. Ensure to check that the Unified CCX release you are planning is supported with the
Unified CM release for which this deployment is planned.
The Unified CCX 9.0(1) installation on the MCS servers is supported only on few of the specific models.
The minimum RAM disk requirement on MCS/VMWare servers for installing Unified CCX 9.0(1) is increased to 4GB.
The RAM disk needs to be upgraded to 4GB before installing Unified CCX 9.0(1) on MCS 7816I4 and MCS 7825I4.
For the list of MCS servers supported for Unified CCX 9.0(1), see
Cisco Unified CCX Software and Hardware Compatibility Guide available at:
This section provides information about determining disk
space usage and requirements when you install the Unified CCX. The historical
reporting (HR) database (DB) size of the Unified CCX depends on the size of
the hard disk on which it is stored. The table below provides an example of
disk space usage for these DB types.
Table 1 Cisco Unified CCX Disk Space Usage
Server Disk Size
HR DB Size
Repository DB Size
Agent Db Size (rascal)
Configuration DB Size
Architecture for Cisco Unified Intelligence Center
Cisco Unified Intelligence Center (Unified Intelligence Center) is a comprehensive, end-to-end reporting solution built using Web 2.0 frameworks. It is designed to make the task of creating reports easier for the user.
The core reporting component of Unified Intelligence Center is bundled with Unified CCX. Cisco Unified Intelligence Center serviceability is integrated with the Cisco Unified CCX serviceability page.
Historical reporting client is the default reporting solution on Unified CCX. The Unified CCX administrator should switch to Unified Intelligence Center as the preferred reporting solution before accessing the Unified Intelligence Center web interface.
To perform this, configure the following from the Cisco Unified CCX Administration
Configure Unified Intelligence Center as the reporting client.
Set the maximum number of simultaneous database connections permitted (optional – the default values are used for most cases).
Configure SMTP for emailing scheduled reports.
Assign reporting capability to users optionally. Any existing historical reporting users are automatically assigned as Unified IC reporting users.
Flow diagram for reporting operation
Figure 12. Flow diagram for reporting operation
The flow diagram for the reporting operation is explained below:
Reporting user accesses the Unified Intelligence Center web interface and provides the necessary login credentials.
Unified Intelligence Center authenticates the user with Unified CCX.
Unified CCX authenticates the user with Unified CM using AXL.
On successful authentication, the user is logged in and shown the main Unified Intelligence Center web interface.
User launches a report with appropriate filters.
Unified Intelligence Center invokes the stored procedure corresponding to that report on the Unified CCX database.
Report data is rendered and displayed in the browser.
In a two node HA setup, reporting users can connect to any node to run the reports. Auto-redirection is a feature introduced in Unified CCX that redirects the user to the most appropriate node that provides correct data while minimizing the load on the system. The redirection logic is based on the following:
User is redirected to the non-master Engine node where CDS/HDS replication is enabled and Unified Intelligence Center is running.
User is redirected to the database master node where Unified Intelligence Center is running.
If Tomcat is not running on the non-master Engine node, there is no redirection and the user connects to the current node.
If Tomcat is not running on the current node, there is no redirection and connection fails.
In any case where redirection does not occur, the user connects to the current node.
Data source update
A single Unified CCX data source is configured in Unified IC. It will point to a node which has correct data while minimizing database load. In a two node HA setup, the data source will point to the secondary node. This may change depending on the following conditions: