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 change.
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 or MGCP).
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 CCX.
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 becomes available.
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 other workstations.
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 screen pop
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 components.
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 follows:
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 design.
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 folder.
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 call recordings.
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 the voice:
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: http://www.cisco.com/go/designzone
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 line involved and original nature of the call.
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 (SRND).
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.
Please reference Integrating CAD with Thin Client and Virtual Desktop Environments for implementation details. This document can be found at:
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 support.
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 location:
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
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 components:
Cisco TelePresence System with single screen, for example, CTS-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 from CAD.
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 TelePresence devices.
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 be abandoned.
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 CCX.
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 campaigns
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 Reserved state.
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 CCX server.
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:
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 "fax").
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 supported.
The protocol supported between the SIP Gateway and Unified CM for transferring the outbound call to an IVR application includes SIP and H323.
It is possible to use the same gateway for both inbound and outbound voice.
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, see the 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 account's inbox.
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 Send button.
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 group.
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 logs in.
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 publisher.
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-bBypass 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 resolution.
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.
Cisco Unified CCX Enhanced Version 10.0(1) supports Workforce Optimization. Unified CCX Enhanced Version users can add-on QM, AQM, and WFM licenses, and also upgrade the existing CR license to QM and AQM licenses.
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 resources.
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 Sites
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 script.
For more information about the Unified CCX Gateway, see the 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 one minute in a LAN environment and six 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 information.
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 Tool.
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
100 Agent VM profile
300 Agent VM profile
400 Agent VM profile
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 page:
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 of Reporting Operation
Figure 12. Flow Diagram of 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: