The desktop applications themselves typically run on Agent desktops, Supervisor desktops, Administration & Data Servers or Administration Client. Services supporting the desktop applications typically run on the Unified CCE Peripheral Gateway (PG) server. Within the Unified CCE
deployment, there may be one or more PG systems, and for each PG there is one set of active desktop services, which includes the CTI Object Server (CTI OS) and the Cisco Agent Desktop Base Services for Cisco Agent Desktop (CAD) deployments. The following figure depicts the components within a Unified CCE
deployment that support the various desktop applications.
Figure 1. Generic Unified CCE Desktop Components
In the Unified CCE solution, the Peripheral Gateway may be deployed in either a simplex or duplex configuration. (Simplex mode is not supported for production environments.) Duplex configurations provide redundant desktop services for fail-over recovery support. These systems are typically
identified as the primary, or A-side, and the backup, or B-side. For production deployments, a duplex configuration is required.
The CTI Object Server (CTI OS) is a high-performance, scalable, fault-tolerant, server-based solution for deploying CTI applications. CTI OS is a required component for the CTI Toolkit Desktop and Cisco Agent Desktop (CAD) solutions and is Cisco's latest version of the CTI implementation.
Communications from the desktop applications, such as agent state change requests and call control, are passed to the CTI OS server running on the Cisco Unified Peripheral Gateway. CTI OS serves as a single point of integration for CAD desktops, CTI Toolkit Desktops, and third-party
applications such as Customer Relationship Management (CRM) systems, data mining, and workflow solutions.
The CTI Object Server connects to CTI Server over TCP/IP and forwards call control and agent requests to CTI Server, which in turn forwards to the Open Peripheral Controller (OPC). From there, depending on the type of request, OPC will forward to either the CCM Peripheral Interface
Manager (PIM) or to the Unified CCE Central Controller.
Requests initiated from the desktop application that affect the agent state are sent to the Unified CCE Central Controller, while requests initiated from the desktop application that affect call control are sent to the CCM PIM. The Unified CCE Central Controller monitors the agent state
so that it knows when it can and cannot route calls to that agent and can report on that agent’s activities.
Call control flows from the agent desktop application to Cisco Unified Communications Manager (Unified CM). Unified CM then performs the requested call or device control. The desktop services located on the PG keep the agent desktop application synchronized with the agent’s IP phone
CTI Toolkit desktop configuration and behavior information is also managed at the CTI OS server, simplifying customization, updates, and maintenance, and supporting remote management.
CTI Object Server Services
Desktop Security — Supports secure socket connections between the CTI Object Server on the PG and the agent, supervisor, or administrator desktop PC. Any CTI application built using the CTI OS Desktop Toolkit (CTI Toolkit) C++/COM Client Interface Library (CIL) Software
Development Kit (SDK) can utilize the desktop security feature.
Desktop Security is not currently available in the .NET and Java CILs.
Quality of Service (QoS) — Supports packet prioritization with the network for desktop call control messages.
QoS is not currently available in the .NET and Java CILs.
Fail-over Recovery — Supports automatic agent login upon fail-over.
Chat — Supports message passing and the text chat feature between agents and supervisors.
Silent Monitoring — Supports VoIP monitoring of active calls. The CTI Object Server communicates with the Silent Monitor Service (SMS) to start/stop the VoIP packet stream forwarding.
The CTI Object Server is typically installed in duplex mode, with two CTI OS servers running in parallel for redundancy, one on PG side-A and one on PG side-B. The CTI Toolkit Desktop applications randomly connect to one of the two servers and automatically fails-over to the alternate
server if the connection to the original CTI OS server fails. CTI OS can also run in simplex mode with all clients connecting to a single server, but Cisco does not recommend this configuration. (Simplex mode is not supported for production environments.)
The CTI OS server interfaces to any desktop application built using the CTI Toolkit Software Development Kit. A single CTI OS server can support the use of both CAD and CTI Toolkit desktops concurrently.
CAD Base Services
Cisco Agent Desktop (CAD) is a software suite that provides a feature-rich packaged solution. CAD consists of user applications and the CAD Base Services, which can run co-resident on the Peripheral Gateway within a Unified CCE deployment and are required for CAD deployments only. The CAD
Base Services provide redundancy and warm standby capabilities.
CAD Base Services
Cisco Chat Service — Supports message passing and the text chat feature.
Cisco Enterprise Service — Communicates with the Unified CCE components to provide call data to the user applications.
Cisco Browser and IP Phone Agent Service — Provides services for CAD-BE and IPPA agent applications.
Cisco Synchronization Service — Synchronizes the Unified CCE and CAD-specific configuration data.
Cisco LDAP Monitor Service — Manages the storage and retrieval of CAD configuration data.
Cisco Recording and Statistics Service — Manages the storage and retrieval of call recording, agent call, and agent state change data used in reports.
Cisco Licensing and Resource Manager Service — Manages user licenses and controls fail-over behavior.
Cisco Recording and Playback Service — Provides the call recording and playback feature.
Cisco VoIP Monitor Service — Provides the voice streams for the call recording and Silent Monitoring features if server-based monitoring is used.
Cisco Unified Contact Center Enterprise (Unified CCE) supports a variety of desktop application choices for agents and supervisors, as described in the following sections.
An agent desktop application is a required component of a Unified CCE deployment. The contact center agent uses this application to perform agent state control (login, logout, ready, not ready, and wrap-up) and call control (answer, release, hold, retrieve, make call, transfer, and
conference). In addition to these required features, the application can provide enhanced features that are useful in a contact center environment.
Cisco offers the following primary types of Unified CCE agent desktop applications:
Cisco Agent Desktop (CAD) — A packaged agent desktop solution supporting an embedded browser and scripted workflow automation.
Cisco Finesse Desktop — A browser-based agent desktop solution that provides a gadget-based architecture for extending base agent functionality.
CTI Toolkit Desktop — An agent desktop application built with the CTI Toolkit that supports full customization and integration with other applications, customer databases, and Customer Relationship Management (CRM) applications.
Cisco Unified CRM Connector for Siebel — A CTI driver for the Siebel Communication Server.
Cisco Unified IP Phone Agent — An agent desktop solution provided through the Cisco Unified IP Phone display.
Cisco Agent Desktop Browser Edition (CAD-BE) — A browser-based agent application that supports many of the features of the CAD windows-based agent application with lower platform requirements.
Cisco partners offer the following types of agent desktop applications:
Partner Agent Desktops — Custom agent desktop applications are available through Cisco Technology Partners. These applications are based on the CTI Toolkit and are not discussed individually in this document.
Prepackaged CRM integrations — CRM integrations are available through Cisco Unified CRM Technology Partners. They are based on the CTI Toolkit and are not discussed individually in this document.
Within the Unified CCE deployment, the agent desktop application is not statically associated with any specific agent or IP phone extension. Agents and phone extensions (device targets) are configured within the Unified CCE configuration and associated with a specific Unified CM cluster.
When logging in from an agent desktop application, the agent is presented with a dialog box that prompts for agent ID or login name, password, and the phone extension to be used for that session. At that time the agent ID, phone extension, and agent desktop IP address are dynamically associated. The association is released when the agent logs out.
This mechanism enables an agent to work (or hot-desk) at any workstation. It also enables agents to take their laptops to any Cisco Unified IP Phone and log in from that device (assuming the phone has been configured in Unified CCE and in Unified CM to be used in the Unified CCE deployment). Agents can also log in to other phones using the Cisco Extension Mobility feature. For more information about Extension Mobility, see the Extension Mobility section of the Cisco Unified Communications Manager Features and Services Guide.
In addition to the agent desktop application, Cisco offers a supervisor desktop application. The contact center supervisor uses this application to monitor agent state for members of their team. The supervisor desktop also enables Silent Monitoring of agents during active calls.
Cisco offers the following types of Unified CCE supervisor desktop applications:
Cisco Supervisor Desktop (CSD) — A packaged supervisor desktop solution.
CTI Toolkit Supervisor Desktop — A supervisor desktop application, built with the CTI Toolkit that supports customization and integration with other applications, customer databases, and Customer Relationship Management (CRM) applications.
Cisco Finesse Supervisor Desktop — A fully browser-based supervisor application that extends the base Finesse Agent Desktop with supervisor capabilities.
Supervisor Desktop Applications Offered through Cisco partners
Prepackaged CRM integrations — CRM integrations are available through Cisco Unified CRM Technology Partners. They are based on the CTI Toolkit and are not discussed individually in this document.
Depending on the requirements of the contact center, a particular type
of desktop might be better suited to the solution. The following table provides an
abbreviated list of the functionality available in the various desktop
applications. It is intended to provide a starting point to determine the
desktop that best meets specific solution requirements. Further information is
available for each of the Cisco desktops in the sections below and in their
respective product specifications at
Table 1 Features Supported by Cisco Desktop Solutions
Cisco Agent Desktop
Cisco Agent Desktop Browser Edition
Cisco Unified CRM Connector for Siebel
IP Phone Agent
Cisco Finesse Desktop
Turn-key desktop applications
Custom desktop development using C++, .NET, and Java
Custom development using standard web components (HTML,
Note: Finesse does not support HTTPS for large deployments (over 1000 agents).
Mobile (Remote) Agents
Integrated Recording Capacity
Monitor Mode Applications
Finesse Release 9.0(1) supports Progressive and Predictive mode only. Finesse Release 9.1(1) supports Progressive, Predictive, and Preview mode.
Microsoft Terminal Services Support
Citrix Presentation Server Support
IP Phone Solution (no soft desktop)
Specific capability or integration not offered by Cisco
The Cisco Agent Desktop (CAD) solution is a suite of packaged desktop applications and services. CAD offers a rich set of features for the contact center environment, including:
Agent state and call controlAgent Desktop provides call control capabilities (call answer, hold, conference, and transfer) and ACD state control (ready/not ready, wrap up and so forth).
Work Flow AutomationThe Work Flow Automation feature allows an administrator to customize the agent environment and how the user applications interact with that environment. Work Flow Automation enables data processing actions to be scheduled based on telephony events (for example,
popping data into a third-party application on the answer event and sending email on the dropped event). Work Flow Automation interfaces with applications written for Microsoft Windows browsers and terminal emulators. Some customizations can be as simple as using keystroke macros for
On-demand Recording The supervisor (and, if enabled, the agent) can record a customer phone call for later review by a supervisor.
Cisco IP Phone Agent serviceWith this XML service, agents using Cisco IP phones can log in and use their phone to perform most of the agent functions found in an agent desktop application.
CollaborationSupervisors can text-chat directly with agents or agent teams. Agents can text-chat with supervisors or other team members (if enabled). The supervisor can push web pages to agents and send team messages to agent desktops. This interactive collaboration enables the
contact center to communicate better, increase productivity, improve customer responsiveness, and coach or train agents.
Task Automation Routine agent tasks, such as email, conferences to knowledge workers, launching other applications, and high-priority chat, can be configured as task buttons on the agent’s toolbar to reduce call duration and improve customer responsiveness.
Silent Monitoring Supervisors can initiate a Silent Monitoring session with an agent on their team.
CAD User Applications
CAD user applications are for contact center agents, supervisors, and administrators and include the following:
Cisco Finesse Desktop is a browser-based agent desktop application that runs on Windows-based PCs using the Microsoft Internet Explorer browser. Beginning in Release 9.1(1), Finesse also supports Mozilla Firefox and Mac OS X. Finesse provides support for 6900, 7800, and 8800 series IP phones.
third-party gadgets using a layout management mechanism.
The Finesse server is deployed as a VMware virtual machine and runs on the Cisco VOS platform. The Finesse server provides the integration to CTI Server. Supported client operations are exposed by the Finesse server through a REST API that shields the application developer from many of the
details surrounding the CTI Server wire protocol.
Finesse integration with Unified CCE includes the following:
Authentication with Unified CCE over a direct connection to the Unified CCE AW Database. Finesse requires that the AW Database is configured to use Windows authentication and that the user configured for Finesse database access is a domain user.
An active/active deployment model where both Finesse servers connect to the active CTI Server on the Agent PG.
Redundancy through the standard Cisco VOS replication mechanism.
Finesse supervisor features extend the agent desktop with additional gadgets that are accessible to supervisors configured in Unified CCE. These features include the following:
Team Performance gadget for viewing agent status
Queue Statistics gadget for viewing queue (skill group) statistics for the supervisor’s queues
Cisco Finesse includes an administrative application that allows for the configuration of the following:
CTI Server And AW Database connections
Cluster settings for VOS replication
Reason and Wrap Up codes
Finesse layout configuration (media properties and gadget layout)
Finesse provides a REST API that enables client applications to access the supported server features. The REST API can use HTTP or HTTPS as the transport with XML payloads.
Cisco Agent Desktop
Cisco Agent Desktop is a Windows application that runs on the agent PC. It works with either a hardware IP phone or the Cisco IP Communicator soft phone. Agent Desktop interfaces with the CTI OS service for call control and agent state change events; for all other features, it communicates
with the CAD services.
Agent Desktop supports Desktop, SPAN, and Unified CM Monitoring and Recording.
The figure below illustrates various ways agent desktops can be configured in a contact center.
Figure 3. CAD Agents and Components
Agent A shows an agent who uses a hardware IP phone. The IP phone connects directly to the agent’s PC through a network cable. This is the configuration required for desktop monitoring. CAD supports a VPN connection between the agent PC and the contact center network.
Agent B shows an agent who uses Cisco IP Communicator. This configuration also supports a VPN connection to the contact center network. This is the most common configuration for mobile agents.
Agent C shows Agent Desktop used with the Mobile Agent feature. Mobile agents are agents whose phones are not directly controlled by Unified CM. Agents might use their home phones or cell phones as their agent device. In this case, the agent provides a CTI port to associate with their
remote phone when logging in. ACD calls for the logged-in agent are sent to the CTI port, which causes the call to appear at the mobile agent’s phone device. There is a logical relationship (the dashed line) between the agent and the mobile phone. CAD supports a VPN connection between the
agent and the contact center network in this configuration. Mobile agents can be monitored and recorded using SPAN monitoring.
Cisco Agent Desktop—Browser Edition (CAD-BE) is a Java applet that runs in Microsoft Internet Explorer (Windows machines) or in Mozilla Firefox (Windows and Linux machines). CAD-BE interfaces with the BIPPA service for call control; BIPPA in turn interfaces with the CTI service. For all
other features, CAD_BE communicates with the CAD services.
CAD-BE can use the abilities and features of any Java applet. This enables CAD-BE to have a small footprint on the agent desktop and still provide essential agent features.
Some limitations of CAD-BE beyond those listed in Table 1 include:
Desktop Monitoring and Recording is not supported. CAD-BE does Support Server Monitoring and Recording and Unified CM monitoring.
The integrated browser is external to the CAD-BE window and is launched when CAD-BE is launched.
The click to dial from browser feature is not
Agents cannot modify enterprise data.
The dial pad does not support dial string formatting, phone books, or recent call list.
Window behavior (for example, stealth or always on top) cannot be configured by the agent.
Cisco IP Phone Agent (IPPA) runs as an IP phone XML service. The agent is not required to have a PC. IPPA includes all the basic features required by a contact center agent, as well as advanced features such as reason codes, wrap-up data, and On-demand Recording.
IPPA agents can be monitored and recorded using server monitoring, and monitored using Unified CM monitoring.
The following figure illustrates the components used by IP Phone agents.
Figure 4. Cisco IP Phone Agent Components
Cisco Supervisor Desktop
Cisco Supervisor Desktop provides a graphical view of the agent teams managed by the supervisor. An expandable navigation tree, similar to that in Windows Explorer, is used to navigate to and manage team resources.
Supervisors are able to view real-time information about the agents in a team as well as interact with those agents. The supervisor can:
View and change an agent’s state
View contact information specific to the agent
Silently monitor and/or record the agent’s calls
Barge-in or intercept an agent’s call
Chat with the agent using an instant message window
Push a web page to the agent’s desktop
When Supervisor Desktop is installed, an instance of Agent Desktop is installed as well. Agent Desktop is needed by the supervisor to take calls, barge in, intercept, and retrieve skill group statistics.
The Supervisor Work Flow module enables configurable actions to be triggered when specific events occur in the contact center. For example, a supervisor work flow can be set up so that whenever more than ten calls are in queue for a specified skill group, an audible alert sounds and the
skill group name is highlighted in red on the supervisor’s desktop. Another work flow sends an email to specified email addresses when certain events occur. The email contains information related to the condition that caused the event, as well as custom text.
Supervisors can use the Supervisor Record Viewer to review recordings and mark selected recordings for extended retention. The supervisor can also save recordings for permanent retention in a format that can be played by any media player.
Cisco Desktop Administrator enables an administrator to configure the CAD services and CAD client applications. Individual work flow groups containing agents and supervisors can be configured separately to provide specific functionality to particular groups of agents.
Desktop Administrator consists of two components:
Cisco Desktop Work Flow Administrator, a Windows-based application
Cisco Desktop Administrator, a web-based application
Cisco Desktop Work Flow Administrator is used to configure the following:
Work flow groups
Dial strings, phone books, reason codes, and wrap-up data can be configured on the global and work flow group level.
Work flows and user interfaces can be configured for specific agent types (CAD agents and CAD-BE agents).
Cisco Desktop Administrator is used to configure the following:
The Cisco Desktop Monitoring Console is a Java application that monitors the status of the CAD services. It provides a convenient interface for an administrator to use to get real-time information about the CAD system.
CTI OS Desktop Toolkit Solution
The CTI OS Desktop Toolkit (CTI Toolkit) provides a Software Development Kit (SDK) for custom development of desktop applications. The CTI Toolkit supports C++, Java, and .NET development Client Interface Libraries (CILs) and provides sample applications for customization.
Additionally, the CTI Toolkit ships complete with pre-built, ready-to-run agent desktop, supervisor desktop, and call center monitoring applications. These applications can be used as-is or can be customized further to meet the particular needs of a call center.
The CTI Toolkit also offers advanced tools for integrating desktop applications with a database, Customer Relation Management (CRM) applications, or other contact center applications.
The CTI Toolkit solution offers a rich set of features for the contact center environment, including:
Collaboration — A supervisor can text-chat directly with agents, and agents can text-chat with supervisors or other team members (if enabled). Interactive collaboration enables the contact center to communicate better, increase productivity, improve customer responsiveness, and coach or
Secure Desktop Connection — Desktop security is provided between the agent/supervisor desktops and the CTI OS server.
Silent Monitoring — A supervisor can initiate a Silent Monitoring session with an agent within their team.
CTI OS Desktop Toolkit Software Development Kits and User Applications
The CTI Toolkit provides the following user tools and applications.
C++ CIL API—A Windows software development kit for developing C++ CTI applications
Java CIL API—A cross-platform library for developing Java CTI applications
.NET CIL API—A Windows software development kit for developing custom .NET framework CTI applications
COM CIL API—A set of COM Dynamic Link Libraries (COM DLL) for building a Visual Basic 6.0 CTI application
ActiveX Controls—A set of Windows GUI controls for custom desktop development using Development environments that support ActiveX technology. For example Visual Basic 6.0
CTI OS Runtime Callable Wrappers—A set of .NET assemblies that allows the use of COM CIL and ActiveX controls in native .NET applications
CTI Toolkit Agent Desktop — A Windows Visual Basic application built on the COM CIL and Active-X controls, providing agent desktop functionality
CTI Toolkit Supervisor Desktop—A Windows Visual Basic application built on the COM CIL and Active-X controls, providing supervisor desktop functionality
CTI Toolkit Outbound Desktop—A Windows Visual Basic application built on the COM CIL and Active-X controls, supporting outbound call center campaigns in addition to standard agent desktop functionality
CTI Toolkit Combo Desktop—A Windows agent and supervisor application based on the .NET CIL, which combines support for agent, supervisor, and outbound functionality
CTI Toolkit All-Agents Monitor—A Windows Admin application based on the C++ CIL, providing call center agent status monitoring
CTI Toolkit All-Calls Monitor—A Windows Admin application based on the C++ CIL, providing call center call status monitoring
The CTI Toolkit All-Agents and All-Calls Monitor applications can be used only if the number of skill groups per agent is less than 20.
The CTI OS Desktop Toolkit C++/COM CIL is the only APIs that support Agent Greeting Enable/Disable and Agent Greeting Recording.
The CTI OS Desktop Toolkit C++ CIL provides a set of header files and static libraries for building C++ CTI applications using Microsoft Visual Studio .NET. The C++ CIL also supports a secure desktop connection between the agent PC and the CTI Object Server on the PG.
Java CIL API
The CTI OS Desktop Toolkit Java CIL provides a powerful cross-platform library for developing Java CTI applications. It does not provide APIs for Agent Greeting Enable/Disable or Agent Greeting Recording.
.NET CIL API
The CTI OS Desktop Toolkit .NET CIL provides native .NET class libraries for developing native .NET Framework applications. The .NET Combo Desktop is provided as a sample application built using the .NET CIL. It does not provide APIs for Agent Greeting Enable/Disable or Agent Greeting
COM CIL API
The CTI OS Desktop Toolkit COM CIL provides a set of COM Dynamic Link Libraries for building Visual Basic 6.0 CTI applications. The CTI Toolkit Agent and Supervisor Desktops are provided as sample applications built with Visual Basic 6.0 and using the COM CIL.
The CTI Toolkit includes a set of ActiveX controls to enable rapid application development. The ActiveX controls are UI components that enable easy drag-and-drop creation of custom CTI applications in a variety of container applications. Container applications include Microsoft Visual
Basic.NET, Microsoft Internet Explorer, Microsoft Visual C++ 8.0, Borland Delphi, Sybase PowerBuilder, and other applications supporting the OC96 ActiveX standard.
The ActiveX Controls include:
Agent Greeting Enable/Disable Control
Agent State Control
Emergency Assist Control
Bad Line Control
Call Appearance Control
Make Call Control (Provides a new functionality to allow Agent Greeting Recording)
Status Bar Control
Agent Statistics Control
Skill Group Statistics Control
Agent Select Control
Silent Monitor Control
CTI Toolkit Agent Desktop
The CTI Toolkit Agent Desktop is a Microsoft Windows application that runs on an agent’s desktop PC and works with either a hardware IP phone or the Cisco IP Communicator software phone. The CTI Toolkit Agent Desktop interfaces with the CTI OS server for call control and agent state change
The CTI Toolkit Agent Desktop includes:
Support for the agent to turn on/off (Enable/Disable) Agent Greeting playback on the routed incoming calls on their current logon session. In addition, the CTI Toolkit Agent Desktop enables the agent to record new Agent Greetings.
Support for desktop monitoring, which captures the voice stream on the agent’s IP phone to support the Silent Monitoring and Call Recording features.
CTI Toolkit Supervisor Desktop
The CTI Toolkit Supervisor Desktop is a Microsoft Windows application that runs on a supervisor's desktop PC. The CTI Toolkit Supervisor Desktop interfaces with the CTI OS server for agent state change events and real-time statistics updates. The CTI Toolkit Supervisor Desktop provides the
contact center supervisor with the ability to manage a team of agents. Supervisors are able to view real-time information about the agents in a team as well as interact with these agents. A supervisor can select an agent to change the agent’s state, view information specific to that agent,
silently monitor the agent’s call, barge in or intercept the agent’s call, or chat with the agent.
A supervisor may also receive emergency assistance requests from agents on their team through the supervisor desktop.
In Unified CCE, supervisors may also be configured to act as agents. When this is done, the standard set of agent phone controls is available on the Supervisor Desktop.
CTI Toolkit Outbound Desktop
The CTI Toolkit Outbound Desktop is a Microsoft Windows application that runs on an agent’s desktop PC and works with either a hardware IP phone or the Cisco IP Communicator software phone. The CTI Toolkit Outbound Desktop interfaces with the CTI OS server for call control and agent state
change events. In addition to the standard set of agent controls present in the CTI Toolkit Agent Desktop, the Outbound Desktop provides a set of controls for managing outbound call campaigns. Outbound calls are automatically managed by Unified CCE, and the agent uses the additional controls
to accept the next outbound call.
CTI Toolkit Combo Desktop
The CTI Toolkit Combo Desktop is a Microsoft Windows .NET application that runs on an agent’s desktop PC and works with either a hardware IP phone or the Cisco IP Communicator software phone. The CTI Toolkit Combo Desktop interfaces with the CTI OS server for call control and agent state
The Combo Desktop integrates the functionality of the Toolkit Agent, Supervisor, and Outbound desktops into a single .NET application. The Combo Desktop source code is also provided as a starting point for custom desktop development using the Microsoft .NET Framework.
The CTI Toolkit Combo Desktop does not provide support for Agent Greeting Enable/Disable or recording new Agent Greetings.
CTI Toolkit All-Agents Monitor
The CTI OS Desktop Toolkit ships complete with a ready-to-run All-Agents Monitor application. This application provides a call center administrator with the ability to monitor agent login and state activity within the call center.
CTI Toolkit All-Calls Monitor
The CTI OS Desktop Toolkit ships complete with a ready-to-run All-Calls Monitor application. This application provides a call center administrator with the ability to monitor call activity within the call center.
Cisco Unified CRM Connector for Siebel Solution
The Cisco Unified CRM Connector for Siebel is an installable component developed by Cisco that enables integration of the Cisco Unified CCE with the Siebel CRM Environment. In this solution, the Siebel Agent Desktop provides the agent state and call control interface. The Siebel Desktop uses the Cisco Unified CRM Connector for Siebel, which is built on top of the CTI OS Desktop Toolkit C++ CIL to communicate with the CTI Object Server.
The Cisco Unified CRM Connector for Siebel does not provide support for Agent Greeting Enable/Disable or Recording new Agent Greetings.
For more information about the capability of the Siebel eBusiness solution, see the Siebel website.
Citrix and Microsoft Terminal Services (MTS)
This section discusses deploying Cisco Agent Desktop and Cisco Toolkit Desktop in a Citrix or Microsoft Terminal Services (MTS) environment.
Cisco Unified CCE supports running Cisco Agent Desktop within a Citrix terminal services environment. When planning to use Citrix terminal services for CAD, take the following considerations into account:
Cisco Supervisor Desktop (CSD) and Cisco Desktop Administrator (CDA) are not supported in a Citrix terminal services environment.
Desktop Monitoring (for Silent Monitoring and Call Recording) is not supported with Citrix terminal services. SPAN Port Monitoring must be used instead.
Macros work only if they involve applications that are running on the Citrix server.
Macros do not work if they involve applications that are running on the client PC.
Only one Citrix user name is supported per CAD application login.
The login ID and extension that appear by default in the login dialog box when CAD is started, are those associated with the last login by any user.
The Citrix web client is not supported.
Citrix 4.0 runs on Windows 2000 Server and Windows 2003 Server.
Citrix 4.5 runs on Windows 2003 Server.
Citrix 5.0, 6.0, and 6.5 run on Windows 2008 Server.
Cisco Unified CCE supports running CTI Toolkit Desktop within the Citrix and Microsoft Terminal (MTS) Services environments. When planning to use Citrix terminal services with the CTI Toolkit Desktop, take into account the following considerations:
Versions of Citrix MetaFrame Presentation Server prior to Version 4.0 or 4.5 are not supported. Earlier versions have limitations for publishing Microsoft .NET applications.
CTI OS Java CIL client applications are supported only on Citrix MetaFrame Presentation Server 4.0 and 4.5 for the Windows platform. There is no planned support for Citrix MetaFrame Presentation Server 4.0 or 4.5 on UNIX.
Silent Monitoring is supported within a Citrix or MTS environment.
CTI OS Client Desktop sounds such as dial tones and DTMF tones are not audible.
CTI-OS supports virtualized desktop infrastructure from Citrix and VMware. CTI-OS also supports Cisco VXI endpoints. When you deploy VDI or VXI, the performance, bandwidth, and timing requirements for CTI-OS, as defined in this document, must still be met.
Silent Monitoring enables supervisors to monitor the conversations of agents within their team. Supervisors are not able to participate actively in the conversation, and the agents and callers are unaware they are being monitored. Cisco Agent Desktop, CTI Object Server (CTI OS), and Cisco
Finesse provide solutions support for Silent Monitoring. CAD Server-based monitoring supports Agent Desktops, IP Phone Agents, and Mobile Agents. Desktop Monitoring supports only desktop agents. CTI OS Releases 7.2 and higher support two types of Silent Monitors: CTI OS based Silent
Monitor and Unified CM Silent Monitor. Cisco Finesse supports Unified CM Silent Monitor only.
CTI OS based Silent Monitoring is accomplished by using one or more VoIP monitoring services located either on the agent’s desktop (desktop monitoring) or on a separate VoIP monitor server (server-based monitoring). CTI OS uses server-based Silent Monitoring to support mobile agents and
desktop-based Silent Monitoring to support traditional (non-mobile) Unified CCE agents.
Unified CM accomplishes Silent Monitoring with a call between the supervisor's (monitoring) device and agent’s (monitored) device. The agent’s phone mixes and sends the agent’s conversation to the supervisor's phone, where it is played out to the supervisor. Unified CM Silent Monitoring
can be initiated by any of the CTI OS supervisors’ desktops (out-of-the-box, Java, or .NET).
Any Unified CCE agent desktop, including Siebel, can be silently monitored using Unified CM Silent Monitoring, provided that the following requirements are met:
The agent that is silently monitored is using a Cisco Unified IP Phone 7941, 7942, 7945, 7961, 7962, 7965, 7970, 7971, or 7975, and Cisco IP Communicator Release 7.0 or higher.
When a CTI OS based Silent Monitor is used, the Cisco IP Phones, including Cisco IP Communicator, must be configured to use RTP streams (SRTP streams cannot be silently monitored).
Unified CM Silent Monitoring does not support mobile agents.
Unified CM Silent Monitoring supports a maximum of one Silent Monitoring session and one recording session for the same agent phone.
Supervisors can use any Cisco IP Phone, including Cisco IP Communicator, to monitor silently.
g.722 is used as the default codec for regions that are configured for g.711 on devices that support g.722. However, g.722 is not supported with Silent Monitoring and Call Recording based on CAD, CTI OS, or Unified CM. To disable this default, in Unified CM Administration go to
Enterprise Parameters and set Advertise g.722 Codec to disabled.
Any given CTI OS Server can be configured to use CTI OS based Silent Monitor, to use Unified CM Silent Monitor, or to disable Silent Monitoring. When supervisor desktops connect to the CTI OS Server, this configuration is downloaded. The supervisor desktop uses this information to invoke the
configured type of Silent Monitor when the Start Silent Monitor button is pressed. The initial message from the supervisor desktop is used by the CTI OS Server to drive either the CTI OS Silent Monitor or Unified CM Silent Monitor.
This topic describes how CTI OS accomplishes Silent Monitoring when the CTI OS Server is configured to use the Unified CM Silent Monitor.
Unified CCE supports the Silent Monitoring functionality available in Unified CM Release 6.0 and higher.
ASA does not currently support the type of call flow that the Silent Monitoring feature uses.
The following figure illustrates the following message flow, which occurs when the Unified CM Silent Monitor is initiated by the supervisor’s desktop:
The supervisor initiates Silent Monitoring by sending the Agent.SuperviseCall() message to Unified CCE.
Unified CCE sends the Call.startMonitor() message to Unified CM.
Unified CM instructs the supervisor's phone to call the built-in-bridge in the agent’s phone.
The supervisor's phone places the call to the built-in-bridge in the agent’s phone.
The agent’s phone forwards a mix of the agent’s voice stream and customer's voice stream.
Call events for the silently-monitored call are sent from Unified CM to Unified CCE.
CTI OS sends a SilentMonitorStarted event to the supervisor’s desktop.
CTI OS sends a SilentMonitorStarted event to the agent’s desktop.
CTI OS sends call events for the silently-monitored call to the supervisor’s desktop.
Figure 6. Unified CM ing for Unified CCE
Cisco Finesse provides Silent Monitoring as follows:
The supervisor application initiates Silent Monitoring by sending a REST request to the Finesse server.
The Finesse server sends the AgentSuperviseCall() message to Unified CCE to start Silent Monitoring.
Unified CCE sends the CallStartMonitor() message to Unified CM.
Unified CM instructs the supervisor’s phone to call the built-in-bridge in the agent’s phone.
The supervisor’s phone places the call to the built-in-bridge in the agent’s phone.
The agent’s phone forwards a mix of the agent voice stream and customer voice stream.
Unified CM sends call events for the silently-monitored call to Unified CCE.
Unified CCE sends update events to the Finesse server.
The Finesse server sends XMPP updates to the Finesse supervisor application.
Unified CM Silent Monitoring works the same as other call control functionality provided by Unified CM (such as conference, transfer, and so forth). When Unified CM is used for Silent Monitoring, a message is sent from the desktop, through Unified CCE, through Unified CM, and out to the
phones where Silent Monitoring is executed.
The messaging through Unified CCE and Unified CM impacts Unified CCE performance. For further details regarding the impact of Unified CM Silent Monitoring on Unified CCE sizing, see Sizing Unified
CCE Components and Servers.
Unified CM Silent Monitoring is supported only for agents that are connected to Unified CCE on the LAN; Unified CM Silent Monitoring does not support mobile agents and mobile agents.
CTI OS Based Silent Monitor
This section describes how CTI Object Server (CTI OS) accomplishes Silent Monitoring when the CTI OS Server component is configured to use the CTI OS Based Silent Monitor.
The Silent Monitoring solution provided by CTI OS in Release 7.0 and earlier was integrated in the Client Interface Library (CIL). The CIL had components to capture and forward voice packets as well as components to play back a stream of forwarded voice packets to the supervisor's sound card.
This feature limited Silent Monitoring support to Unified CCE agent desktops deployed behind a Cisco IP Phone and Unified CCE supervisor desktops deployed on the supervisor's desktop.
Starting CTI OS Release 7.1, two deployment types are supported: Citrix and Mobile Agent. In these two deployments, the CIL is not deployed where it has access to the voice stream. In Citrix, the CIL is located on the Citrix Server. Agents and supervisors use a Citrix client to run the
desktop. When this is done, the desktop runs on the Citrix server. The Citrix client merely displays the UI of the desktop. Because it is the agent’s Citrix client that is deployed behind the IP phone, the CIL no longer has access to the voice path. Similarly, it is the supervisor's Citrix
client that has the sound card. In this case, the CIL is running on the Citrix Server And does not have access to the sound card.
In Mobile Agent deployments, the CIL is deployed on an agent’s remote PC. When the agent uses an analog phone, the CIL does not have access to the voice stream.
To support these two deployment models, it was necessary to remove the Silent Monitor components from the CIL and put them on a separate service. This allows the service to be deployed where it has access to the agent’s voice stream or the supervisor's sound card.
The following figures show where the Silent Monitoring service should be deployed for each deployment model. The red line in each diagram illustrates the path of the monitored voice stream.
Figure 1 and Figure 2 illustrate deployments where the
agent uses an IP phone. In these deployments, Silent Monitoring is configured the same way
regardless of whether the agent is mobile or not.
Figure 7. CTI OS Based Silent Monitoring for Cisco Unified CCE When a Mobile or Local Agent Uses an IP Phone
The deployment in Figure 1 is very similar to CTI OS Release 7.0 and earlier
deployments. The only difference is that the Silent Monitoring service is running alongside
the CIL to provide Silent Monitoring functionality.
Figure 8. CTI OS Based Silent Monitoring for Cisco Unified CCE with Citrix When a Mobile or Local Agent Uses an IP Phone
In the deployment model in Figure 2, the Silent Monitoring service is
deployed on Citrix clients, where it has access to the agent’s voice stream and the
supervisor's sound card. The CIL makes a connection to the Silent Monitoring service and sends
it instructions over a TCP connection to start and stop Silent Monitoring sessions.
Figure 9. Silent Monitoring for a Mobile Agent Using a PSTN Phone
In the deployment model in Figure 3, one Silent Monitoring service is
deployed on a switch's SPAN port to gain access to voice traffic passing through the agent
gateway. Agents to forward their voice streams to the supervisor Silent Monitoring services
use the Silent Monitoring service attached to the SPAN port.
Supervisors running locally are deployed the same as Unified CCE supervisors. Supervisors running remotely are also deployed the same as Unified CCE supervisors, but a Cisco 800 Series Router with hardware-based VPN is required in order for the supervisor to receive agent voice streams.
Figure 10. Silent Monitoring for a Mobile Agent Using a PSTN Phone with Citrix or Microsoft Terminal Services
In the deployment model in Figure 4, one Silent Monitoring service is
deployed on a switch's SPAN port to gain access to voice traffic passing through the agent
gateway. Agents to forward their voice streams to the supervisor Silent Monitoring services
use the Silent Monitoring service attached to the SPAN port. Mobile agents need to run only
their Citrix clients. Agent desktops running on the Citrix server will connect to the Silent
Supervisors running locally are deployed the same as Citrix Unified CCE supervisors. Supervisors running remotely are also deployed the same as Citrix Unified CCE supervisors, but a Cisco 800 Series Router with hardware-based VPN is required in order for the supervisor to receive agent voice
In the two mobile agent deployments above (Figure 3 and Figure 4), calls whose voice traffic does not leave the agent gateway
cannot be silently monitored. This includes agent-to-agent calls as well as agent
consultations with other agents. The only calls that can be reliably monitored in this case
are calls between agents and customers. This is because the mobile agent solution requires
separate gateways for callers and agents to ensure that voice traffic is put on the network.
If a mobile agent’s login can be handled by one of two gateways, it is possible to cluster two and only two Silent Monitoring servers together to provide Silent Monitoring functionality regardless of the gateway that handles the call. A maximum of two Silent Monitoring servers are supported in a cluster (SPAN) based deployment. When a request to silently monitor the agent is received, the Silent Monitoring server that receives the request from the agent desktop will forward the request to its peer, and then both Silent Monitoring servers will attempt to detect the stream. Once the agent’s voice stream is detected, it is forwarded to the supervisor's Silent Monitoring service by the Silent Monitoring server that detected the stream.
The figure below illustrates the messaging that occurs between the desktops, CIT OS Server, and Silent Monitoring services when a Silent Monitor session is initiated. Note that messaging between the desktops and the CTI OS Server has not changed from CTI OS Release 7.0.
Figure 11. Message Flow Between Desktops, CTI OS Server, and Silent Monitoring Service
In mobile agent deployments, agent desktops learn where and how to connect to their Silent Monitoring server using a CTI OS connection profile. When an agent logs in, the agent desktop uses the following algorithm to determine where the Silent Monitoring service is located:
If a Silent Monitoring service is present in the connection profile, attempt to connect to it.
If no Silent Monitoring service is present, determine if the desktop is running under Citrix.
If the desktop is running under Citrix, connect to the Silent Monitoring service running at the Citrix client's IP address.
If the desktop is not running under Citrix, connect to the Silent Monitoring service running at localhost.
Supervisor desktops use the following algorithm to find their Silent Monitoring service:
If the desktop is running under Citrix, connect to the Silent Monitoring service running at the Citrix client's IP address.
If the desktop is not running under Citrix, connect to the Silent Monitoring service running at localhost.
If the IPCCSilentMonitorEnabled key is set to 0 in the connection profile, no attempt is made to connect to a Silent Monitoring service.
CAD Silent Monitoring and Recording
This section describes Cisco Agent Desktop (CAD) Silent Monitoring.
CAD recording is not suitable for use as a compliance recording solution. This functionality is best for on-demand recording or recording on a filtered list of calls only.
CAD-based monitoring consists of three types of monitoring:
Mobile Agent Monitoring
Desktop Monitoring uses software running on the agent’s desktop (Cisco Agent Desktop) to sniff the network traffic going to and from the agent’s phone (hardware phone or software phone) for RTP packets. The monitoring software then sends the RTP packets to the appropriate software over the network for decoding. Desktop Monitoring relies on the ability for certain Cisco IP Phones to be daisy-chained with the agent’s PC by using a network connection and for the phones to send all its network traffic along this connection to the software running on the PC. In this case, the packet-sniffing software can see the voice traffic flowing to and from the agent’s phone. It will copy this traffic and send it to the supervisor that is monitoring the agent or to a recording service for the call to be stored and to be listened to at some later time. Desktop Monitoring is not a true service, at least from the perspective of the Service Control Manager. It is a Dynamic-Link Library (DLL), an executable module that is part of Cisco Agent Desktop.
Server monitoring uses one or more Cisco Desktop VoIP Monitor Services to sniff the network running over a Cisco Catalyst switch for voice streams. The Cisco Desktop VoIP Monitor Service looks for particular streams to and from phones being monitored or recorded. It then sends the voice packets to the supervisor desktop that is performing the monitoring or to a recording service for storage.
The Cisco Desktop VoIP Monitor Service uses the Switched Port Analyzer (SPAN) or Remote SPAN (RSPAN) monitoring feature of certain Cisco Catalyst switches to sniff the network. The switch uses the monitoring feature to copy the network traffic from one or more sources to a destination port. Sources can be ports and/or Virtual LANs (VLANs). RSPAN allows the source ports to reside on remote switches. The Cisco VoIP Monitor Service connects to the switch by using the destination port. This allows the Cisco VoIP Monitor Service to see the voice traffic going to and coming from IP phones.
Mobile Agent Monitoring
Cisco Agent Desktop has the ability to monitor and record mobile agents' RTP sessions by deploying a Cisco VoIP Monitor Service that can see traffic coming from Agent Voice Gateways (this also uses the SPAN feature).
For more information, see the Cisco Agent Desktop product documentation available on cisco.com.
Fault Tolerance for CAD-Based Monitoring and Recording
Desktop Monitoring is fault tolerant by design. If an agent’s desktop fails, only that agent is unavailable for monitoring and recording.
Server Monitoring and Mobile Agent Monitoring
Server monitoring and mobile agent monitoring are not fault tolerant. If a Cisco Desktop VoIP Monitor Service fails, all agent phones and mobile agent Voice Gateways associated with that service is unavailable for monitoring and recording. No backup service can be specified. Monitoring and recording will continue to be available for devices associated with other Cisco Desktop VoIP Monitor Services.
Recording is fault tolerant. If a recording service fails in a high-availability deployment, the other recording service will assume all recording responsibilities.
Playback of recordings is not fault tolerant. Recordings are tied to the recording service that captured the recording. If a recording service fails, all recordings associated with that service is unavailable until it is restored.
Load Balancing for CAD-Based Monitoring and Recording
Desktop Monitoring is load-balanced by design. Monitoring load is distributed between the agent desktops.
Server Monitoring and Mobile Agent Monitoring
Load balancing can be achieved when configuring SPAN ports for, and associating devices with, the Cisco Desktop VoIP Monitor Services. To achieve load balancing, have each VoIP Monitor Service monitor an equal number of agent phones.
Recording services are selected in round-robin fashion at runtime by the desktops. However, no attempt is made to ensure that the load is balanced between the recording services.
Cisco Remote Silent Monitoring
This section covers Cisco Remote Silent Monitoring. Remote Silent Monitoring (RSM) allows for the real-time monitoring of agents as a dial-in service.
The RSM solution consists of three components:
Callflow Scripts for Unified CVP and IP IVR
For a further description of these components, see the Cisco Remote Silent Monitoring Installation and Administration Guide, available at cisco.com.
The Remote Silent Monitoring solution is highly integrated into the Cisco Unified Contact Center Enterprise environment. Because of this, the functioning of RSM requires resources from various other components of the platform as a whole. To properly integrate RSM, then, requires an
understanding of its interactions with the rest of the environment so that capacity can be properly planned, provisioned, and managed.
In particular, RSM interacts mainly with the Unified CM cluster.
The RSM server has two tie-ins with each Unified CM cluster in the environment that it is configured to use:
Simulated PhonesThe RSM PhoneSim component requires that a Cisco Unified IP Phone 7941 device entry be created on the Unified CM cluster for each of the simulated phones ("simphones") it is configured to manage. For instance, a RSM system that is configured to handle up to 100
dialed-in supervisors monitoring agents on a particular Unified CM cluster must have at least 100 simphones. To the Unified CM cluster, these simphones appear as Cisco Unified IP Phone 7941 SIP phones; however, in reality they are homed to PhoneSim and controlled by PhoneSim,
instead of being an actual physical phone device.
When compared with the usage profile of a physical phone device, the simphone usually puts a lighter load on the Unified CM cluster. This is because it exhibits only a small set of behaviors, consisting of:
Registering with the Unified CM cluster when PhoneSim is started.
Making a "monitoring call" to an agent’s phone when a dialed-in supervisor requests to monitor that agent. The agent’s phone then forks off a copy of the conversation that the agent is having to the simphone.
JTAPIWhen RSM is integrated into the environment, a JTAPI user is created and associated with each agent phone device that can be monitored, as well as with each simphone device that was created on the cluster.
When an agent is to be monitored, a JTAPI monitor request
call is made from the RSM server to the Unified CM cluster that manages that agent’s phone. Also, while RSM is in use, a JTAPI CallObserver is kept attached to each simphone device. It is also attached to an agent phone device, but only while the JTAPI monitor request is
being issued to that device.
JTAPI connections may optionally be encrypted. However, this will induce a slight performance penalty on the server itself when higher agent loads are utilized. For more information about enabling JTAPI connection security, see the
Cisco Remote Silent Monitoring Installation and Administration Guide, available at cisco.com.
CTI OS Server
RSM makes a persistent "monitor-mode" connection to each CTI OS server that it is configured to use. Through this connection, certain platform events are streamed in real-time. These platform events include call start, call end, agent on hold, and so forth.
RSM also makes an additional, short-lived "agent-mode" connection to possibly each CTI OS server when a supervisor dials in and authenticates. The purpose of this connection is to validate the supervisor's credentials by performing a corresponding login into CTI OS. Note that this
connection is not made if the built-in authentication mechanisms of the RSM call flow (for example, the checkCredentials API call) are not used. If the login is successful, that supervisor's team membership is requested by the RSM server. Once returned, a logout is called and the
connection is terminated.
Note that the total supervisor count in Unified CCE must be spread across CTI OS desktop users and RSM. For example, in a 2,000 agent configuration, up to 200 agents can be supervisors. This means that the total supervisor count between CTI OS and RSM must not exceed 200.
CTI OS connections can be optionally encrypted through the use of IP Sec configurations. However, this optional encryption will induce a significant performance penalty on the server itself when higher agent loads are utilized. For more information about enabling CTI OS connection
security, see the Cisco Remote Silent Monitoring Installation and Administration Guide, available at cisco.com.
Voice Response Unit (VRU)
The RSM platform does not directly media-terminate inbound calls. Instead, supervisors dial into a Unified CVP or IP IVR-based Voice Response Unit (VRU) system, which runs call flow script logic that interacts with services hosted on the RSM server over HTTP. Thus, if a given RSM
installation is to support up to 40 dialed-in supervisors, there must be a VRU present (as well as the necessary PRI/network resources) that can offer this same level of support.
Furthermore, RSM calls often place higher loads on the VRU processor and memory than more traditional IVR-type calls. These RSM loads are higher because more traditional IVR call flows play shorter, and oftentimes cached or non-streamed prompts. These prompts are separated by periods
of caller input gathering and silence. With RSM, however, the predominant caller activity is monitoring an agent’s call. To the VRU, this looks like the playback of a long-streaming audio prompt, which requires a relatively higher level of VRU processor involvement.
With Unified CVP deployments, supported VXML gateway models are listed in the Hardware and System Software Specification for Cisco Unified Customer Voice Portal (Unified CVP), otherwise known as Unified CVP Bill of Materials (BOM), available at cisco.com.
When provisioning a VRU for use by RSM, a good rule of thumb is to count each RSM call as 1.3 non-RSM calls on a processor/memory-usage basis. So for a VRU that can normally handle 40 concurrent calls, plan for it to be able to handle only 30 RSM calls, that is (40/1.3) = 30.
Also note that RSM makes extensive use of VXML Voice Browser functionality under both Unified CVP and IP IVR.
RSM Release 9.1 and later support RTSP prompt streaming, and, therefore, no longer require a dedicated VXML Gateway for CVP installations. (In other words, you do not need to configure the 'ivr prompt streamed http' option in VXML Gateway, which conflicts with CVP IOS requirements). Due to this change, RSM scalability on CVP has been improved to support 80 concurrent sessions on any CVP-supported VXML Voice Gateway model and IOS version. RTSP streaming support for CVP eliminates the previous high gateway memory requirement, as well as the CVP monitoring call duration limit default (a maximum of twenty minutes).
Use of RSM to monitor an agent requires that that agent’s phone be a third-generation Cisco Unified IP Phones 79x1, 79x2, 79x5, 7970, or newer. This is because these third-generation phones include extra DSP resources in the form of a Built-in-Bridge (BiB). The BiB allows the phone to
fork off a copy of the current conversation stream to the RSM server.
Cisco Unified Contact Manager provides for a maximum of one active monitoring session per agent because the agent’s phone can handle only one active monitoring session and one active recording session at any given time.
So, if a third-party recorder is recording the agent’s conversations, the agent can still be monitored by a supervisor using supervisor’s desktop or RSM. However, if both a RSM-based supervisor and a supervisor-desktop-based supervisor both tried to monitor the agent during the same
time period, the request fails with the last one to try because it exceeds the above-mentioned monitoring limit.
Note that RSM will set up only one monitoring session through Unified CM for a single monitored agent, even if two or more RSM users are requesting to monitor the agent’s call at the same time. In this case, RSM forks the stream to cover all RSM users. This allows more than two
RSM-based supervisors to monitor the same agent, for instance. However, if there are multiple RSM servers in the environment that monitor the same agent, they will each make a separate monitoring call to that agent.
If the monitoring call limit has been reached for a specific agent and a dialed-in supervisor then attempts to monitor this same agent, the supervisor's request is denied through an audio prompt feedback from the system stating that the agent cannot be monitored.
RSM Hardware Considerations
RSM is supported in installations where the number of agents in the enterprise is fewer than 10,000 and the number of maximum concurrent supervisors using the system is fewer than 80. RSM can support monitoring these agents distributed across multiple PGs and supports up to six PG clusters configuration on each server. In all supported RSM configurations, the VLEngine and PhoneSim components are installed on the same physical
For more information, see the "RSM Requirements" section of the Cisco Remote Silent Monitoring Installation and Administration Guide, available at cisco.com.
RSM Component Interaction
The following figure illustrates the types of interactions that occur when a supervisor dials into an RSM-enabled platform and monitors an agent.
The figure above shows the following call flow steps:
A supervisor calls in, and the call is media-terminated on the VRU (Unified CVP or IP IVR). The VRU runs the RSM callflow script to handle the call. The call begins with a request for the user to authenticate. The user then enters credentials.
The VRU makes a login request to RSM over HTTP.
The VLEngine component in RSM interacts with the CTI OS server to validate the authentication credentials.
VLEngine replies back to the VRU node by using HTTP with the authentication result.
If the supervisor is successfully authenticated, the script in the VRU will play the main menu prompt. From here, the supervisor is allowed to monitor an agent.
The supervisor chooses to monitor a single agent from the main menu, and enters a Directory Number (DN) of an agent to be monitored.
The VRU checks with VLEngine if the given agent can be monitored. VLEngine then checks whether the agent with that DN is logged in, is in talking state, and is in the supervisor's team, using previously cached event feed information from the CTI OS server. If so, it replies back to the
The VRU node then sends a monitor request to PhoneSim to monitor the entered DN. For CVP, this request is sent using RSTP protocol; for IPIVR, this request is sent over HTTP.
VLEngine works internally using HTTP.
Following that, VLEngine sends a JTAPI request to Unified CM to monitor the agent’s phone, and it gets a JTAPI success response.
The PhoneSim component will then receive a SIP-based instruction from Unified CM for a simulated phone that it manages, to establish a monitoring call with the agent’s phone.
The chosen simulated phone establishes the monitoring call with the agent’s phone based on Unified CM's above request.
After the establishment of a monitoring call from RSM server to agent, the agent phone's Built-in-Bridge (BiB) forwards the call conversation to PhoneSim in the form of RTP packets.
In turn, for IPIVR, PhoneSim strips the RTP headers and streams this data to the VRU node over HTTP as a response to the request made earlier in step 8. For CVP, PhoneSim streams the audio back to CVP Gateway using RTSP and RTP protocols.
The VRU then plays the data to the supervisor as if it were a streaming audio prompt.
RSM Deployment Models
This section illustrates some basic supported RSM deployments.
The following figure illustrates the basic network connectivity of RSM deployed within a typical single-site configuration.
Figure 13. Typical RSM VLAN Configuration
As shown in the preceding figure, supervisors may dial in through a VoIP phone as well as through the PSTN. The VRU that handles the supervisor's call is IP IVR in this case.
This typical RSM VLAN configuration also illustrates the various protocol interfaces that RSM has into the rest of the system:
HTTPs: As stated previously, HTTP is used as the carrier protocol for VRU-based requests into the RSM system. A request takes standard URL form and may look like one of the following URLs:
The first request is for the checkUserCredentials API
call, while the second is for the canMonitorAgentID API call. Parameters to these requests are passed by using the GET method. The return data (as an HTTP response) is either plain text or encapsulated in VoiceXML, depending on the API call being used and on the value specified for the
outputFormat parameter (if available for that call).
CTI OS: The RSM server makes several connections to CTI OS. One of these connections is for receiving platform events. (In the language of CTI OS, it is a monitor-mode connection.) The others are what CTI OS calls agent mode connections and they are used to authenticate logging-in
supervisors if the standard authentication facilitates are being utilized.
JTAPI: The request to start monitoring an agent’s phone is made through JTAPI. This requires a JTAPI application user to be defined on each Unified CM cluster in the environment, and to be associated to all agent phones.
RTP: While a dialed-in supervisor is monitoring an agent, there is a monitoring call in progress from the BiB (built-in-bridge) of that agent’s phone to the RSM server. While the signaling data for this call is run through Unified CM (just like any other call), the RTP traffic will flow
between the agent phone and the RSM server.
The following scenarios depict basic supported configurations for the RSM product in a multisite deployment.
Single Cluster, Single VRU
The following figure depicts a simple multisite setup involving a single Unified CM cluster and a single VRU.
Figure 14. Multisite Deployment with a Single Unified CM Cluster and Single VRU
In this scenario, the Unified CM and Unified CCE environment is co-located in Atlanta, and the Austin location contains the entire end-user population. The VRU is a VXML Gateway/Voice Gateway in Atlanta, controlled by a Unified CVP Call Server also in Atlanta.
The supervisor in Austin could possibly have two ways of dialing into the RSM system:
Through the PSTN — Here the supervisor would dial an E.164 number, and the call is hairpinned through the Voice Gateway. The Unified CVP RSM call flow application would handle the call as normal from that point.
As a VoIP extension — In this case, Unified CM would have a trunk configuration set up to the VRU. The call would remain VoIP all the way through, and the call would likewise be handled by the Unified CVP RSM call flow application.
In this scenario, all RSM traffic is confined to the Atlanta site except:
The RTP traffic of the agent being monitored
The actual supervisor call into the platform
Single Cluster, Multiple VRUs
The following figure depicts a multisite deployment with a single Unified CM cluster and multiple VRUs.
Figure 15. Multisite Deployment with a Single Unified CM Cluster and Multiple VRUs
This scenario is similar to the previous one, with the addition of PSTN access at the Austin site. This scenario also adds personnel to the Atlanta site.
With the addition of a PSTN egress point in Austin, a call from a supervisor at the Austin location to the RSM system can be backhauled across the WAN (if VoIP end-to-end) or sent across the PSTN if the Atlanta DID associated with the RSM application was dialed.
In this example, Unified CVP is still used as well as the Unified CVP Call Server. However, there are two VXML Gateways, one at each site. The environment is configured so that a supervisor dialing RSM from Austin is routed to the RSM call flow application on the Austin VXML Gateway, while a
supervisor dialing in from Atlanta is routed to the Atlanta VXML Gateway.
Because the Atlanta site houses the Unified CM and Unified CCE environment, all RSM-related JTAPI and CTI OS traffic is still confined there. However, the addition of a VXML Gateway at Austin leads to HTTP-based traffic being streamed between the sites over the WAN. This traffic consists of
relatively small requests from the gateway to the RSM server for services, and the RSM server's responses. The responses themselves can be sizeable, especially when it is the data for a monitored conversation.
Also, when an agent in Austin is monitored, the RTP data for that conversation is sent over the WAN back to the RSM server as well.
Multiple Cluster, Single VRU
Multisite Deployment with Multiple Unified CM Clusters and a Single VRU depicts a multisite deployment with multiple Unified CM clusters and a single VRU.
Figure 16. Multisite Deployment with Multiple Unified CM Clusters and a Single VRU
This scenario includes a Unified CM cluster at both the Atlanta and Austin sites and a single IP IVR VRU in Atlanta. Cluster 1 handles the phone devices at the Atlanta site, while Cluster 2 handles the ones at the Austin site. The RSM server is linked to the CTI OS servers of both
clusters to track all agents in the enterprise.
As IP IVR is in use, a supervisor call to the RSM call flow is routed to, and media-terminated on, this IP IVR system over either the PSTN or IP WAN (as discussed previously). No VXML Gateway is involved in this configuration, and all RSM-related HTTP interaction is confined to the Atlanta
site, between the RSM and IP IVR systems.
Because a Unified CM cluster now exists at the Austin site, several classes of data that RSM uses to track environment state and initiate agent monitoring requests (CTI OS and JTAPI traffic) are sent over the IP WAN.
Multiple Cluster, Multiple VRUs
The following figure depicts a multisite deployment with multiple Unified CM clusters and multiple VRUs.
Figure 17. Multisite Deployment with Multiple Unified CM Clusters and Multiple VRUs
This scenario illustrates a Unified CM cluster as well as a Unified CVP VXML Gateway/Voice Gateway at each site. It is a combination of the previous deployment models, and it has the following characteristics:
The Unified CVP Call Server controls the VXML Gateways at each site.
Because there are agent phones at both sites, RTP data can be streamed either within the LAN at Atlanta (if the requested agent to monitor is in Atlanta) or across the WAN (if the requested agent is in Austin).
As with the previous multisite, multicluster deployment, the RSM tracks the state of the entire enterprise. This means that a supervisor could dial in from either site (or anywhere in the world through PSTN) and listen to an agent in Atlanta or Austin.
Single Cluster, Single PG/CTIOS with two UCM PIMs (agent expansion Unified CCE deployment configuration)
This diagram depicts a setup involving a single UCM cluster and single Agent PG/CTIOS server configured with two UCM PIMs.
Figure 18. Single UCM cluster and single Agent PG/CTIOS server configured with two UCM PIMs
In this scenario, the single PG/CTIOS server is configured with two PIMs and each PIM points to a separate subscriber pair in the UCM cluster.
This is supported in Unified CCE/UCM 8.0 and higher, only when more than 2000 agents (up to 4000 agents) need to be configured in a single UCM cluster with a Unified CVP VRU. This expansion is not supported with IPIVR.
In this scenario RSM should be configured with two clusters with each specifying the corresponding UCM PIM Peripheral Number and its UCM subscriber pair.
Single Cluster, Multiple PG/CTIOS (agent expansion Unified CCE deployment configuration)
The following diagram shows a setup involving a single UCM cluster and multiple (up to 4)
Agent PG/CTIOS servers:
Figure 19. Single UCM cluster and multiple (up to 4) Agent PG/CTIOS servers
This diagram depicts a setup involving multiple UCM clusters and multiple Agent PG/CTIOS servers.
Figure 20. Multiple UCM clusters and multiple Agent PG/CTIOS servers
In this scenario, a separate Agent PG/CTIOS server is deployed for each UCM cluster.
A separate RSM cluster (in a single RSM instance) should be configured corresponding to each Agent PG/CTIOS Server and its UCM cluster subscriber pair.
As part of the network planning done before deploying the RSM solution, you should verify that the network infrastructure can support the bandwidth requirements of RSM.
The RSM solution has connectivity with multiple components in the larger Cisco environment (as the diagrams in the previous section demonstrate). The table below lists these components, along with the nature of the data exchanged and the relative bandwidth requirements of that data. If
RSM exchanges multiple types of data with a specific component, it is listed multiple times.
Table 3 Bandwidth Requirements
Relative Bandwidth Requirements
Link Latency Requirements
Service Requests / Responses
< 500 ms avg.
Requested Voice Data from PhoneSim to VRU
For IPIVR - G.711 u-law in WAV format and HTTP chunked transfer encoding format.
For CVP - G.711 u-law, G.711 a-law, and G.729 in RTP.
High(about 67 to 87 kbps per session)
< 400 ms avg.
Issuance of Agent Phone Monitoring
Binary (JTAPI stream)
< 300 ms avg.
CTI OS Server (PG)
Environment Events / Supervisor Logins
TCP (CTI OS)
Binary (CTI OS stream)
Minimal(< 1000 agents)
Moderate(> 1000 agents)
(with 2000 agents, about 100 kbps)
< 300 ms avg.
Simulated Phone Signaling
TCP or UDP (SIP)
< 400 ms avg.
Monitored Phone Voice Data
Binary (g.711 u-law, g.711 a-law, and g.729)
High (about 67 to 87 kbps per session)
< 400 ms avg.
Agent Phone Bandwidth Figures
For RSM Release 9.1 and later, the simulated phones on RSM server support and advertise g.711 u-law, g.711 a-law, and g.729 codecs to establish the monitor call with agent phones.
There must be sufficient bandwidth available from the agent IP phone to the RSM server to support the monitoring voice stream, in addition to the regular voice streams for the call. This is important for agents who work remotely, at home and in small branches on limited bandwidth or WAN
connectivity. Regular Call Admission Control (CAC) and bandwidth calculations are applicable for monitoring calls.
Since G.711 a-law, G.711 u-law, and G.729 are the codecs supported for monitoring calls between agent IP phone and RSM server (phonesim), use the Cisco TAC Voice Bandwidth Codec Calculator for additional
bandwidth capacity planning.
RSM Codec Support
The monitoring call established between RSM’s simulated phone (simphone) and Agent’s phone is subject to regular call admission control (CAC) procedures. The simulated phones on RSM server support and advertise G.711 u-law, G.711 a-law, and G.729 codecs to establish the monitor call with agent phones.
For all incoming calls from phone (BiB) to RSM
For all incoming calls from phone (BiB) to RSM, the built-in phone transcoding resources are used to transcode the call (if necessary) and send it on to the monitoring call leg. No additional transcoding resources are needed on UCM or Voice Gateway. If the incoming call is G.729, RSM Sim Phones Region should be configured to allow a Max Audio Bit Rate of 8 Kbps. If the incoming call is G.711, RSM Sim Phones Region should be configured to allow a Max Audio Bit Rate of 64 Kbps.
For outgoing calls to CVP systems from RSM
The outgoing monitoring call to the CVP gateway can be G.711 u-law, G.711 a-law, or G.729. RSM server will perform the necessary transcoding. No Voice Gateway transcoding resources are needed.
Figure 21. Outgoing calls to CVP from RSM
If the RSM application is configured using a comprehensive flow, only G.711 a-law or G.711 u-law can be configured for the RSM-to-CVP call leg. This is due to other dependencies related to Agent Greeting and other ICM functionality and their inability to handle G.729. To use G.729 for the CVP call leg, RSM should be configured in a standalone call flow.
For outgoing calls to IPIVR systems from RSM
The outgoing monitoring call leg is G.711 u-law. RSM server will transcode to G.711 u-law if transcoding is necessary.
Load balancing support is defined as the act of multiple RSM servers being associated together so that the incoming request load is distributed among them. The definition of fail-over is multiple RSM servers being associated together so that if one fails, the others can act in its place.
In the future, RSM will support load balancing and fail-over with both the Unified CVP and IP IVR VRUs. Currently, this support is not available in RSM 1.0. RSM 1.0 does, however, support the deployment of multiple standalone RSM servers within a single Unified CCE environment, and this
concept is demonstrated in the advanced deployment scenarios described in this document.
The table below indicates how a failure of each of the various components affects a live supervisor call.
Table 4 Impact of Failures on a Supervisor Call
Component That Fails
Worst Possible Impact
VRU Node (IP IVR, Unified CVP)
Supervisor's call is terminated as any VRU fail-over occurs (depends). Supervisor may dial back in and log in again once VRU fail-over is complete and/or the original failed VRU is working again.
RSM Server (Hardware Failure)
Callers listening to a voice stream from the failed server have the voice stream terminated and be returned to the main menu. Their next attempt to make a service request to the failed server (or a new caller’s first attempt to make such a request) will result in a
configurable delay of 3 to 5 seconds or so, as the request times out and an error message is played. Furthermore, any action that attempts to contact the RSM server (for example, logging in, attempting to monitor an agent, and so forth), will fail, although the RSM
callflow will still be answered because it is being hosted on the VRU node.
VLEngine or PhoneSIM software failure
Service automatically restarted via service wrapper. Supervisors with a request in-progress are given an error message and have a chance to retry their last action. During the time either service is not functioning, any action that attempts to contact the RSM server
(for example, logging in, attempting to monitor an agent, and so forth), will fail, although the RSM callflow will still be answered because it is being hosted on the VRU node.
Unified CCE fails (CTI OS)
RSM will lose connectivity to the CTI OS server when the PG fails or is cycled. If connectivity to both CTI servers on a cluster fails, RSM will keep retrying both, connecting to the first server that is available. (The CIL's fail-over code is used for all of this.)
When connectivity comes back up to a CTI server, the agent and call lists are cleared and refreshed (to avoid "stale" agents). During this time, no new call events are received, and the system is working from an "out-of-date" agent and call list. Therefore some
monitoring requests fail, saying the agent is not talking when he or she is, and some monitoring requests fail because the system thinks the agent is talking when he or she currently is not. This is believed to be preferable to the scenario where all cached data is
deleted when the server goes down, in which case no monitoring works.
Unified CM fails (JTAPI)
Connectivity to one or more JTAPI providers are lost. RSM can be configured for connectivity to a maximum of 2 JTAPI providers per-cluster. If this is the case and connectivity to either of the providers is lost, VLEngine will fail-over to the other provider if
necessary, making it the active one and making its requests through it. If connectivity to both providers is lost, VLEngine will periodically retry both and re-establish the connectivity to the first that comes up. Attempts to monitor agents (for example, monitorAgent
calls) made during this time fails until the JTAPI connection is re-established.
Incoming access to the RSM server can be restricted to only the necessary components by using the host-based Access Control List (ACL) functionality built into the Windows Server OS. In the most secure configuration, incoming access to the RSM system is permitted from the VRU systems.
Built-in host-based access control can also be employed to allow limited access to other services if desired, such as remote administration mechanisms like Windows Remote Desktop and VNC.
Even though this is not required, a recommended ACL Configuration for a single-server RSM configuration is as follows:
Deny incoming access to all
Permit incoming TCP on port 8080 to each VRU node in the environment (VLEngine HTTP API Access)
Permit incoming TCP on port 29001 to each VRU node in the environment (PhoneSim HTTP API Access)
Cisco Security Agent
As part of the installation procedure, Cisco highly recommends that you install the Cisco Security Agent (CSA) software on the RSM system. This topic is covered in the Security Settings chapter of the Cisco Remote Silent Monitoring Installation and Administration Guide, available at cisco.com.
Transport or Session Level Security
Because RSM maintains multiple connections to a number of components in the larger Cisco Contact Center environment, there is no simple answer to whether transport or session level security is supported or not. The follow notes describe RSM's support for this feature by protocol type:
RSM to VRU (HTTP, RTSP, and RTP)
Currently there is no support for encryption of the HTTP-, RTSP-, and RTP-based data exchange between RSM and the VRU node.
RSM to PG/CTI OS Server (CTI)
Because RSM makes use of the Java CIL, all CTI OS servers used by it must be set up with security disabled. CTI OS traffic may be encrypted through the use of IPSec transport mode encryption. For more information, see the Security Settings chapter of the Remote Silent
Monitoring Configuration and Administration Guide, available at cisco.com.
RSM to UCM (JTAPI)
Like CTI OS traffic, JTAPI traffic may be encrypted through the use of IPSec transport mode encryption. For more information, see the Security Settings chapter of the Remote Silent Monitoring Configuration and Administration Guide, available at cisco.com.
RSM to Agent Phone (RTP)
Currently there is no support for encryption of the RTP stream between Agent Phone (BiB) and RSM SimPhone. Secure RTP (SRTP) is not supported by RSM SimPhones.
Support for Mobile Agent, IP Communicator, and Other Endpoints
Currently, the underlying Unified CM 8.0 monitoring functionality does not provide monitoring support for endpoints using any one of the following:
Cisco Mobile Agent
Second generation or older phones, such as the Cisco Unified IP Phones 7940 or 7960
A media-terminated CTI OS Agent Desktop
Monitoring of encrypted phone calls
Therefore, support for these products is also not available through RSM. For further information about this restriction, see the section on Silent Monitoring.
Support for 6900, 8900, and 9900 Phone Models
6900, 8900 and 9900 phone models have Join, Join Across Lines (JAL), Direct Transfer, and Direct Transfer Across Lines (DTAL) features, which RSM does not support.
Since 6900 phones allow disabling of these features, RSM can supPort Monitoring these phones if these features are disabled.
Since 8900 and 9900 do not allow for disabling of these features, RSM does not supPort Monitoring of these phones.
Cisco Agent Desktop Presence Integration
Cisco Agent Desktop agents and supervisors have long been able to communicate with each other by using the chat services built into the desktop applications. Now, for customers who have deployed Cisco Unified Presence in their environments, agents and supervisors can use these same desktop
applications to see the presence status of subject matter experts (SMEs) as well as other critical members of the enterprise and to initiate chat sessions with them. The subject matter experts use the familiar Cisco Unified Personal Communicator to initiate chat sessions with agents who are
configured as Unified Presence users and to respond to chat requests from them. Subject matter experts can also use Microsoft Office Communicator if Cisco Unified Presence is configured to support federated users.
For example, suppose that a customer calls a Cisco Unified Contact Center that has integrated Cisco Unified 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 subject matter experts who are assigned to the agent’s work flow group. The agent can then select a contact that is available and can 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 following figure and description explain how various components of CAD and Cisco Unified Presence interface with each other.
Figure 23. Interface Between CAD and Cisco Unified Presence
The figure above depicts the following sequence of events:
Cisco Desktop Administrator binds to the LDAP server for SME searches and information (name, telephone number, and so forth).
The Administrator places SMEs in logical groups called contact lists and then assigns them to specific work flow groups. In 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 the CAD LDAP directory so that each agent/supervisor does not have to access the Cisco Unified Presence LDAP server, which might have limitations on the number of connections and other parameters. Administrators can also control whether SMEs can
see the agent’s presence state.
CAD retrieves the contact list associated with the agent’s workflow group.
CAD sends a SIP REGISTER message to register with Cisco Unified Presence, followed by individual SIP SUBSCRIBE messages for each user in its contact list. CAD also sends a SIP SUBSCRIBE message for "user-contacts" for contacts configured on Cisco Unified Presence. A SIP NOTIFY message 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 Unified Presence when the agent logs in.
Call control is done via the existing CAD main window call controls using CTI.
All SIP traffic and presence information sent between CAD and Cisco Unified Presence is not encrypted and is done by using TCP or UDP.
Cisco Unified Presence can evenly assign the users registered with it across all nodes within the Cisco Unified Presence cluster. If a user attempts to connect to a node that is not assigned to him, CAD will connect to the Cisco Unified Presence server specified in redirect messages from the
All communication between CAD agents and SMEs is through the Cisco Unified Presence Server And is not routed through any CAD servers. For deployment guidelines, see the Cisco Unified Communications SRND.
NAT and Firewalls
This section discusses deploying Cisco Agent Desktop (CAD), CTI Toolkit Desktop, and Cisco Finesse in an environment where two or more disjointed networks are interconnected using Network Address Translation (NAT).
When Cisco Finesse is deployed in a network environment where two or more disjointed networks are interconnected using NAT, the Finesse clients and Finesse servers must all be located on the same network. In addition, the Finesse server must be located on the same network as the CTI Server on the Agent PG.
Cisco Agent Desktop and NAT
When the CAD desktop is deployed in a network environment where two or more disjointed networks are interconnected using NAT, the CAD Base Services must all be located on the same network. Network Address Translation (NAT) and Port Address Translation (PAT) are not supported between CAD Base
Services servers. The CAD, CAD-BE, and Cisco Supervisor Desktop (CSD) applications support NAT and PAT but only over a VPN connection. Cisco Desktop Administrator (CDA) and Services Management Console (SMC) do not support NAT or PAT and must be installed on the same network as the CAD Base
Firewalls are supported between the CAD services and desktop applications, and are supported between the desktop applications as long as the firewall allows the required type of traffic through and the appropriate ports are open. Internet Control Message Protocol (ICMP) must be allowed in the
firewall for Unified CCE and Unified CM to communicate with CAD. ICMP is also needed for heartbeat time-out detection between CAD, the CTI Server (CTISVR), and Unified CM. The following figure shows the traffic types that are used between the CAD components.
The figure above shows that IP voice streams are exchanged between the VoIP providers (CAD, the VoIP Monitor service, and the Recording and Playback Service) and the VoIP requestors (CSD and the Recording and Playback Service).
CTI and call control data (agent state, skill information, and call events) flow either from the CTI OS service (in the case of CAD) or from one or more of the CAD Base Services communicating directly with the CTI server (in the case of CAD-BE, CSD, and IPPA agents).
Note that, in the case of the IP Phone Agent XML service, the CTI information exchanged applies only for agent state changes requested by the agent using the IPPA application and for skill information displayed on the phone. Call control messages are still exchanged between the phone and
HTTP communication is performed between the SMC applet and the SMC servlet running on the CAD Base Services machine. HTTP is also the protocol used by the IPPA service and CAD-BE applet to communicate with the Browser and IP Phone Agent service.
The UDP/TCP traffic shown in the preceding figure represents the socket connections used to exchange messages between servers and clients, which includes the CORBA connections used by most of the clients to request services and information from the servers.
The SMC servlet that runs on the CAD Base Services machine uses SNMP to gather status information about all the CAD services that are part of an installation.
CTI Toolkit Desktop and NAT
When the Cisco CTI Toolkit Desktop is deployed in a network environment where two or more disjointed networks are interconnected using NAT, then Unified CM, the physical IP Phone, the Cisco CTI OS Server, the Cisco CTI Toolkit Desktop, and the Cisco CTI OS IPCC Supervisor Desktop must all be on the same network.
Coresidency of CTI OS and CAD Services on the PG
Cisco recommends that you install CTI OS and CAD Services (including VoIP Monitor and Recording) on the PG. This does reduce the supported maximum agent capacity on the PG. If the supported PG capacity numbers provided in the chapter on Sizing Unified CCE Components and Servers are not sufficient and you want to run these software components on separate servers to increase agent capacity on the PG, then prior approval from the Unified CCE product management team is required.
Legacy deployments where CTI OS or CAD Services were previously installed on separate servers are still supported. However, customers are encouraged to migrate CTI OS and CAD Services onto the PG. For more information regarding deployment configurations, see Deployment Models.
Support for Mix of CAD and CTI OS Agents on the Same PG
Unified CCE deployments can support a mix of CAD and CTI OS agents on the same PG. If a mix is deployed, the sizing limitations of CAD apply. Note that Cisco Supervisor Desktop (CSD) can monitor only CAD agents, and the CTI OS supervisor application can monitor only CTI OS agents.
Support for Mix of Finesse and CTI OS Agents on the Same PG
Unified CCE deployments can support a mix of Finesse and CTI OS agents on the same PG. If a mix is deployed, the sizing limitations of Finesse apply. Note that the Cisco Finesse supervisor application can monitor only Finesse agents, and the CTI OS supervisor application can monitor only CTI OS agents.
Support for IP Phones and IP Communicator
CAD, CAD-BE, and the CTI Toolkit Desktop support the use of Cisco IP hardware phones and/or the Cisco IP Communicator software phone.
Some CAD agent application features (CAD, CAD-BE, and IPPA) require particular phone models, and some installations support either hardware phones or software phones but not both. For information about the exact phone models and IP Communicator versions supported, see the CAD documentation on cisco.com.
IP Phones and Silent Monitoring
Silent Monitoring of agents is supported using either IP hardware phones or Cisco IP Communicator.
IP Phones and Mobile Agent
The Mobile Agent feature does not require any specific type of phone. Even analog phones can be used for this feature.
IP Phones and Citrix or MTS
Both the Cisco IP hardware phones and Cisco IP Communicator are supported when using Citrix or MTS with either CAD or the CTI Toolkit desktops. In these environments, Cisco IP Communicator must be installed on the Agent desktop PC and cannot be deployed on the Citrix or MTS server.
IP Phone Agent
The IP Phone XML service agent application supports only hardware IP phones because there is no desktop.
Miscellaneous Deployment Considerations
This section briefly describes the following additional deployment considerations.
Layer-3 network devices (routers and gateways) cannot exist between an agent’s telephone device (hardware or software phone) and the switch port used by the VoIP Monitor service that is configured to capture voice packets for Silent Monitoring and Recording. This restriction applies only if
a VoIP Monitor Service is configured as the primary or back-up service for capturing voice streams. If desktop monitoring is configured as the primary method (with no secondary method), this information does not apply.
A network hub (including a "smart" hub) is not allowed between an agent’s hardware phone and PC when Desktop Monitoring is configured for the agent.
Multiple Daisy-Chained Hardware Phones
There may be only a single hardware phone connected in series between the agent’s PC and the switch when Desktop Monitoring is configured for the agent.
NDIS Compliance of NICs
The network interface cards (NICs) used by the VoIP Monitor services and on the agent’s PC (when Desktop Monitoring is configured) must support promiscuous mode packet sniffing as stated. If the NIC card or driver does not support this functionality through the NDIS interface, the
Monitoring and Recordingfeature will not work.
Encrypted Voice Streams
If the voice streams are encrypted using SRTP, the Silent Monitoring and Recording feature will not work correctly. Although the voice streams can still be captured, they will not be decoded correctly. The end result is that speech is unintelligible.
Agent and Supervisor desktops can be located remotely from the agent PG. Technically, the delay between the CTI OS Server And CTI Toolkit Desktop clients, as well as between the CAD Server And CAD/CSD desktop, can be very high because of high time-out values. However, large latency will affect the user experience and might become confusing or unacceptable from the user perspective. For this reason, Cisco recommends limiting the latency between the Server And agent desktop to 400 ms round-trip time for CTI OS (preferably less than 200 ms round-trip time) and 200 ms round-trip time for CAD (preferably less than 100 ms round-trip time). Longer latencies up to a second are technically supported but will affect the agent experience negatively (for example, the phone will start ringing but the desktop will not be updated until a second later).
References to Additional Desktop Information
The following additional information related to Cisco Agent Desktop and Cisco Supervisor Desktop is available at the listed URLs:
Cisco CAD Service Information
This document provides release-specific information such as product limitations, service connection types and port numbers, configuration files, registry entries, event/error logs, error messages, and troubleshooting.