Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

Cisco Unified Contact Center Enterprise Design Guide, Release 11.0(1)

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco Unified Contact Center Enterprise Design Guide, Release 11.0(1)

Chapter Title

Unified CCE Desktop Deployment Scenarios

Results

Updated:
October 13, 2019

Chapter: Unified CCE Desktop Deployment Scenarios

Unified CCE Desktop Deployment Scenarios

Desktop Architecture

Desktop applications typically run on agent or supervisor desktops, Administration & Data servers, or administration clients. Services that support the desktop applications can run on the Unified CCE Peripheral Gateway (PG) server or on their own server. For each PG, there is one set of active desktop services.

Peripheral Gateway and CTI Server

In the Unified CCE solution, you deploy the Peripheral Gateway (PG) in a redundant configuration, with a Side A and a Side B. You install the CTI server on the PG. Agent CTI services connect to one side or the other, depending on which side is active.

Desktop applications forward call control and agent requests to the Agent PG. The Agent PG processes agent state requests and updates the Central Controller for consideration in routing decisions. The Agent PG forwards call control requests to the Unified Communications Manager, which monitors and controls the phone end points. The Agent PG and desktop services keep the agent desktop application synchronized with the agent's IP phone state.

Cisco Finesse Server

You deploy the Cisco Finesse server on a dedicated VMware virtual machine (VM) that runs on the Cisco Voice Operating System (VOS) platform. The Finesse server is a required component for the Cisco Finesse desktop solution. The Cisco Finesse software is fault-tolerant and deploys on redundant VMs. Both Finesse servers are simultaneously active.

The Finesse server connects to the CTI server on the Agent PG. Authentication with Unified CCE is provided over a connection to the Administration & Data Server.

Figure 1. Cisco Finesse Desktop Architecture

Finesse requires that you deploy the Administration & Data Server with a backup Administration & Data Server. If the primary Administration & Data Server goes down, Finesse connects to the backup server for authentication so that agents can still sign in.

The Finesse server exposes supported client operations through a Representational State Transfer (REST) API. The REST API shields the developer from many of the details surrounding the CTI server wire protocol.

To connect to the Unified CCE administration database, Finesse supports connections using either SQL authentication or Windows authentication.

Finesse clients connect to the Finesse server over a web browser that points to the fully qualified domain name (FQDN) of the Finesse server.

You deploy the Finesse server in an active/active deployment, where both Finesse servers connect to the active CTI server on the Agent PG. The standard Cisco VOS replication mechanism provides redundancy.

Finesse Server Services

You can access the following Finesse services using the CLI:

  • Cisco Finesse Notification service: This service is used for messaging and events. The Finesse desktop uses this service to view call events, agent state changes, and statistics.

  • Cisco Finesse Tomcat service: This service contains all deployed Finesse applications. These applications include the following:

    • Finesse desktop application: This application provides the user interface for agents and supervisors.

    • Finesse IP Phone Agent application: This application allows agents and supervisors to perform Finesse operations on their Cisco IP Phone.

    • Finesse REST API application: Finesse provides a REST API that enables client applications to access the supported server features. The REST API can use HTTP or HTTPS to transport application data. The REST API also provides a programming interface that third-party applications can use to interact with Finesse. See the Cisco Finesse documentation at http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​finesse/​tsd-products-support-series-home.html for more information on the REST API.

    • Finesse administration application: This application provides the administrative operations for Finesse.

    • Finesse Diagnostic Portal application: This application provides performance-related information for Finesse.

CTI Object Server

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. The CTI OS server runs as a redundant pair, one server on each VM that hosts an Agent PG.

Desktop applications pass communications, such as agent state change requests and call control, to the CTI OS server. CTI OS is a single point of integration for 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 the CTI server over TCP/IP and forwards call control and agent requests to the CTI server.

Figure 2. CTI OS Desktop Architecture

The CTI OS server also manages CTI Toolkit desktop configuration and behavior information, 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 CIL SDK can use the desktop security feature.


    Note

    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.


    Note

    QoS is not currently available in the .NET and Java CILs.

  • Failover recovery: Supports automatic agent sign-in upon failover.

  • 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 or stop the VoIP packet stream forwarding.

You deploy the CTI Object server in redundant pairs, one on Agent PG A and one on Agent PG B. Both CTI OS servers are active simultaneously. The CTI Toolkit desktop applications randomly connect to one of the two servers. If the connection to the original server fails, the desktops automatically fail over to the alternate server.


Note

The CTI OS server interfaces to any desktop application built using the CTI Toolkit SDK.

Related Information
Sizing Unified CCE Components and Servers

Agent Desktops

A Unified CCE deployment requires an agent desktop application. The agent uses this desktop for agent state control and call control. In addition to these required features, the desktop can provide other useful features.

Cisco offers the following primary types of Unified CCE agent desktop applications:

  • Cisco Finesse: 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. The desktop supports full customization and integration with other applications, customer databases, and Customer Relationship Management (CRM) applications.


    Note

    The CTI Toolkit Desktop was deprecated in Unified CCE Release 11.0(1). Do not include the CTI Toolkit Desktop in new deployments. Support for the CTI Toolkit Desktop will be removed in a future release.

  • Cisco Unified CRM Connector for Siebel: A CTI driver for the Siebel Communication Server.

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. The Finesse REST API also enables partner desktop integration.

  • Prepackaged CRM integrations: CRM integrations are available through Cisco Unified CRM Technology Partners. These integrations are based on the CTI Toolkit and are not discussed individually in this document.

Related Information
Cisco Agent Desktop

Supervisor Desktops

In addition to the agent desktop application, Cisco offers a supervisor desktop application. The contact center supervisor uses this application to monitor the agent state for members of their team. The supervisor desktop also allows the silent monitoring of agents during calls.

Cisco offers the following types of Unified CCE supervisor desktop applications:

  • Cisco Finesse: A fully browser-based supervisor application that extends the base Finesse agent desktop with supervisor capabilities.

  • CTI Toolkit supervisor desktop: A supervisor desktop application built with the CTI Toolkit. The desktop supports customization and integration with other applications, customer databases, and CRM applications.

  • Supervisor desktop applications offered through Cisco partners.

  • Prepackaged CRM integrations: CRM integrations are available through Cisco Unified CRM Technology Partners. These integrations are based on the CTI Toolkit and are not discussed individually in this document.


Note

CAD also provides a supervisor desktop. For more information, see the CAD documentation.

Related Information
Cisco Agent Desktop

Agent Mobility

The Unified CCE deployment does not statically associate the agent desktop with any specific agent or IP phone extension. You configure agents and phone extensions within Unified CCE and associate them with a specific Unified Communications Manager cluster.

When agents sign in to their desktop, a dialog prompts for an agent ID or username, password, and the phone extension to use 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 signs out.

This mechanism allows an agent to work (or hot-desk) at any workstation. The mechanism also allows agents to take their laptops to any appropriately configured Cisco Unified IP Phone and sign in from that device.

Agents can also sign in to other phones using the Cisco Extension Mobility feature. For more information about this feature, see the Extension Mobility section of the Feature Configuration Guide for Cisco Unified Communications Manager at http:/​/​www.cisco.com/​c/​en/​us/​support/​unified-communications/​unified-communications-manager-callmanager/​products-maintenance-guides-list.html.

Desktop Solutions

Your choice of a desktop solution depends on the requirements of your contact center. The following table provides an abbreviated list of the functionality available in the various desktop applications. The table provides a starting point to help you determine the desktop that best meets your specific solution requirements.

You can find more information for each of the Cisco desktops in the following sections and in their respective product specifications at Cisco.com.

Desktop functionality

Cisco Finesse

CTI Toolkit

Cisco Unified CRM Connector for Siebel

Browser-based desktops

Yes

Custom development

Yes (using standard web components such as HTML, JavaScript)

Yes (using C++, .NET, and Java)

Desktop security

Yes

Note   

Finesse supports HTTPS only for deployments of 1500 agents or less.

Yes

Workflow automation

Yes

Mobile (remote) agents

Yes

Yes

Yes

Silent monitoring

Yes

Yes

Monitor mode applications

Yes

Outbound calls

Yes

Yes

Yes

Microsoft Terminal Services support

No

Yes

Citrix presentation server support

Yes

Agent mobility

Yes

Yes

Agent Greeting

Yes

Yes

Cisco Finesse Desktop Solution

Cisco Finesse is a supervisor and agent desktop for use with Cisco Unified Contact Center solutions. Cisco Finesse provides the following:

  • An agent and supervisor desktop that integrate traditional contact center functions into a thin-client desktop

  • A browser-based desktop implemented through a Web 2.0 interface

  • A single, customizable interface that gives contact center agents access to multiple assets and information sources

  • Open Web 2.0 APIs that simplify the development and integration of applications

You install the Cisco Finesse server on a VM. Clients then use a web browser to point to the Finesse server. No Finesse software is installed on the client, which speeds and simplifies installation and upgrade.

See the Unified CCE Solution Compatibility Matrix for supported browsers and operating systems for Finesse clients (administration console, agent desktop, and supervisor desktop).


Note

Cisco Finesse supports the use of Compatibility View with all supported versions of Internet Explorer.

The Finesse desktop application consists of the client and server components. The client is composed of standard web programming elements (HTML, JavaScript) that are distributed as gadgets using the OpenSocial 1.0 specification. You can configure the agent desktop to use Cisco and third-party gadgets through a layout management mechanism.

Cisco Finesse is part of a class of applications called Enterprise Mashups. An Enterprise Mashup is a web-centric method of combining applications on the client side. The gadget-based architecture of Finesse enables client-side mashup and easier integration. Version compatibility dependencies are reduced because gadget upgrades are handled independently.

You can customize the agent and supervisor desktops through the Finesse administration console. Administrators can define the tab names that appear on the desktops and configure which gadgets appear on each tab.

Finesse REST API

Finesse provides a REST API that allows client applications to access the supported server features. The REST API can use HTTP or secure HTTP (HTTPS) as the transport with XML payloads.

Finesse also provides a JavaScript library and sample gadget code that can help expedite third-party integration. You can find developer documentation for the REST API, the JavaScript library, and sample gadgets on the Cisco Developer Network at https:/​/​developer.cisco.com/​site/​finesse/​.

Finesse Agent Desktop

The Finesse out-of-the-box agent desktop provides the following features:

  • Basic call control (answer, hold, retrieve, end, and make call)

  • Advanced call control (consultation, transfer after consult, conference after consult)

  • Single-step transfer (agents can transfer a call without first initiating a consultation call)

  • Queue statistics gadget (to view information about the queues to which the agent is assigned)

  • Not Ready and Sign Out reason codes

  • Phonebooks

  • Workflows

  • Mobile agent support

  • Progressive, Predictive, Preview Outbound, and Direct Preview Outbound

Finesse Supervisor Desktop

The Finesse supervisor features extend the agent desktop with more gadgets that are accessible to supervisors. These features include the following:

  • Team performance gadget to view agent status

  • Queue statistics gadget to view queue (skill group) statistics for the supervisor's queues

  • Unified Communications Manager Silent Monitoring

  • Barge-in

  • Intercept

  • Change agent state (a supervisor can sign out an agent, force an agent into Not Ready state, or force an agent into Ready state)

Finesse IP Phone Agent

With Finesse IP Phone Agent (IPPA), agents can access Finesse capabilities on their Cisco IP Phone as an alternative to accessing Finesse through the browser. Finesse IPPA does not provide the full set of Finesse features that are supported using the browser, but it does allow agents and supervisors to receive and manage Finesse calls if they lose or do not have access to a PC.


Note

Supervisors can sign in to Finesse on their IP Phones and perform all agent tasks, but supervisor tasks such as monitor, barge, and intercept are not supported. To perform supervisor tasks, supervisors must sign in to the Finesse desktop.

Finesse IPPA supports the following functionality:

  • Sign in/sign out

  • Call variables display

  • Pending state

  • Wrap-up reasons

  • Optional wrap-up

  • Not Ready reasons

  • State change using reason codes

  • One Button Sign In

Finesse Administration Console

Cisco Finesse includes an administrative application that allows administrators to configure the following:

  • Connections to the CTI server and the Administration & Data server database

  • Cluster settings for VOS replication

  • Not ready and sign out reason codes

  • Wrap-up reasons

  • Phonebooks

  • Workflows and workflow actions

  • Call variable and ECC variable layouts

  • Desktop layout

  • Team resources

  • Finesse IP Phone Agent (IPPA)

Reason codes, wrap-up reasons, phonebooks, workflows, and desktop layouts can be global (apply to all agents) or assigned to specific teams.

Finesse Multiserver Support

A single Agent PG supports two instances of Finesse. Each Finesse server can support the maximum of 2,000 users supported by the CTI server. This capacity enables one Finesse server to handle the full load if the other server fails. The total number of users between the two Finesse servers cannot exceed 2,000. Each Finesse server requires a single CTI connection, as shown in the following figure:

Figure 3. Multiple Finesse Servers

Finesse can be deployed according to coresidency policies outlined in the Unified Communications Virtualization DocWiki at http:/​/​docwiki.cisco.com/​wiki/​Unified_​Communications_​Virtualization.

Finesse Load and Capacity

Finesse is qualified to support up to 1800 agents and 200 supervisors (for a total of 2000 users) per Finesse server pair. Additionally, Finesse supports:

  • Up to 1000 Outbound Option agents

  • Up to 500 Finesse IPPA agents

    Finesse IPPA agents can also access the Finesse desktop (but not both at the same time) without affecting the total number of supported users, license permitting.

For example, you can have 200 supervisors, 1000 Outbound Option desktop agents, 500 Finesse IPPA inbound agents, and 300 inbound desktop-only agents.

Finesse supports up to 54,000 calls per hour.


Note

HTTPS is not supported for deployments of more than 1500 users.

If you use HTTPS, you can have up to 1350 agents and 150 supervisors (for a total of 1500 users).

Configure Custom Dialed Number for Finesse Agent Greeting Record

Finesse does not support the default Record Greeting button that ships with CTI OS. To record Agent Greetings with Finesse, create your own custom dialed number for recording. You may want to create different dialed numbers for different customers.

To record the greeting, your agents can enter the record dialed number using the dial pad on their desktops.

If you use different network VRUs to record Agent Greetings for different customers, use the TranslationRouteToVRU node in your routing script to explicitly select the network VRU.

Use the following steps to create a custom dialed number for Finesse Agent Greeting Record:

  1. Create a CTI Route Point in Unified CM and associate it with an Application User (PG User).

  2. Create a Dialed Number in Unified ICM for the CTI Route Point created in Unified CM.

  3. Create a Call Type for the Custom Dialed Number.

  4. Associate the Call Type and Dialed Number with the Record Agent Greeting Script.

  5. Create a Phonebook Entry in Finesse for the agent to dial the Custom Dialed Number.


Note

If you use a Send to VRU node in the Unified ICM script, make sure to create a VRU label for the Unified CM PG routing client.

Load Balancing for Finesse

After agents sign in to the Finesse desktop, the Finesse desktop client manages failover. For example, if a Finesse server goes out of service, the Finesse client automatically redirects and signs the agent in to the other Finesse server. The client can manage various network and server failure use cases. Given this client-side logic, the use of a load balancer after sign-in is not required nor supported.

However, the following are two scenarios in which you can use a load balancer with Finesse.


Note

These scenarios only apply to the Finesse desktop and not to Finesse IP Phone Agents.

When Agents Navigate to the Finesse Sign-In Page

If an agent attempts to navigate to a Finesse server that is down or not reachable, they cannot access the sign-in page. The agent receives an error and must manually sign in to the other Finesse server. To avoid this manual step, customers can use a load balancer using URL redirect mode to direct the agent to a Finesse server that is operational. One option is to use the Finesse SystemInfo REST API, which provides the status of the Finesse server. For details about this API, see the Cisco Finesse Web Services Developer Guide.

When you configure a load balancer to determine the status of the Finesse servers, the call flow is as follows:

  1. When agents sign in to Finesse, they point their browsers to the load balancer.

  2. The load balancer redirects the agent browser to an appropriate Finesse server.

  3. The agent signs in to the Finesse server directly. At this stage, the load balancer is no longer part of the call flow.

When Customers Use the Finesse API Directly

If a customer uses the Finesse REST API directly, the Finesse client-side failover logic is not in the call flow. In this case, customers can opt to use a load balancer to manage high availability. This load balancer is considered part of a custom application which, like all custom applications, Cisco does not support. The customer or partner must provide the required support for the load balancer.

Before you configure the load balancer, remember that there are two connections between Finesse clients and the Finesse server:

  • A REST channel for request and response

  • An XMPP channel that the server uses to send notifications to the client

Both channels for a given client must connect to the same Finesse server.

You cannot connect the load balancer to the REST connection for one Finesse server and to the XMPP channel connection for the other Finesse server. This setup provides unpredictable results and is not supported.

CTI OS Desktop Toolkit Solution


Note

The CTI Toolkit Desktop was deprecated in Unified CCE Release 11.0(1). Do not include the CTI Toolkit Desktop in new deployments. Support for the CTI Toolkit Desktop will be removed in a future release.

The CTI OS Desktop Toolkit (CTI Toolkit) provides an out-of-the-box agent and supervisor desktop and contact center monitoring applications. You can use these applications as-is or customize them to meet the particular needs of your contact center.

The CTI Toolkit also provides an SDK for custom development of desktop applications. The CTI Toolkit supports C++, Java, and .NET development CILs and provides sample applications for customization.

The CTI toolkit offers advanced tools for integrating desktop applications with a database, CRM applications, and other contact center applications.

The CTI Toolkit offers the following contact center features:

  • Collaboration: Supervisors can chat directly with agents. Agents can chat with supervisors or other team members (if enabled). Interactive collaboration allows for better communication within the contact center, which can increase productivity and improve customer responsiveness. Collaboration can also help supervisors coach and train agents.

  • Secure desktop connection: The CTI Toolkit provides desktop security between the agent and supervisor desktops and the CTI OS server.

  • Silent monitoring: Supervisors can start silent monitoring sessions with agents who are on their team.

CTI OS Desktop Toolkit SDK and User Applications

The following figure illustrates the architecture of the CTI OS Desktop Toolkit.

Figure 4. CTI OS Toolkit Desktop Architecture

The CTI Toolkit provides the following user tools and applications.

CTI Toolkit Agent Desktop

The CTI Toolkit agent desktop is a Microsoft Windows Visual Basic application built on the COM CIL and ActiveX controls. The desktop runs on an agent PC and works with either a hardware IP phone or the Cisco IP Communicator. The CTI Toolkit agent desktop interfaces with the CTI OS server for call control and agent state events.

The CTI Toolkit agent desktop allows the agent to turn on or turn off Agent Greeting playback (Enable/Disable) on routed incoming calls to the desktop. The CTI Toolkit agent desktop also allows the agent to record new Agent Greetings.

The CTI Toolkit agent desktop supports desktop monitoring, which captures the voice stream on the agent IP phone. This feature allows the CTI Toolkit agent desktop to provide silent monitoring and call recording.

CTI Toolkit Supervisor Desktop

The CTI Toolkit supervisor desktop is a Microsoft Windows Visual Basic application built on the COM CIL and ActiveX controls. The CTI Toolkit supervisor desktop runs on a supervisor PC and interfaces with the CTI OS server for agent state change events and real-time statistics updates.

Supervisors can use the CTI Toolkit supervisor desktop to manage a team of agents. Supervisors can view real-time information about the agents on their team and interact with these agents. A supervisor can select an agent to change that agent's state, view information specific to that agent, or chat with the agent. The supervisor can also silently monitor an agent's call and barge in or intercept that call. Agents can send requests for emergency assistance to the supervisor through the supervisor desktop.

In Unified CCE, supervisors can also be configured to act as agents. In this scenario, 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 Visual Basic application built on the COM CIL and ActiveX controls. The outbound desktop runs on an agent PC and works with either a hardware IP phone or the Cisco IP Communicator. The CTI Toolkit outbound desktop interfaces with the CTI OS server for call control and agent state change events. In addition to the standard CTI Toolkit agent desktop controls, the outbound desktop provides a set of controls to manage outbound call campaigns. Unified CCE automatically manages outbound calls and the agent uses the additional controls to accept outbound calls.

CTI Toolkit Combo Desktop

The CTI Toolkit combo desktop is a Microsoft Windows .NET application that runs on the agent PC and works with either a hardware IP phone or the Cisco IP Communicator. The CTI Toolkit combo desktop interfaces with the CTI OS server for call control and agent state change events.

The combo desktop combines the functionality of the CTI Toolkit agent, supervisor, and outbound desktops into a single .NET application. The combo desktop source code is provided as a starting point for custom desktop development using the Microsoft .NET framework.

The CTI Toolkit combo desktop does not support Agent Greeting Enable/Disable or recording new Agent Greetings.

CTI Toolkit All-Agents Monitor

The CTI OS Desktop Toolkit provides a ready-to-run all-agents monitor application. With this application, an administrator can monitor agent login and state activity within the contact center. The CTI Toolkit All-Agents Monitor is a Windows application based on the C++ CIL.


Note

You can use the CTI Toolkit All-Agents Monitor application only if the number of skill groups per agent is less than 20.

CTI Toolkit All-Calls Monitor

The CTI OS Desktop Toolkit provides a ready-to-run all-calls monitor application. With this application, an administrator can monitor call activity within the contact center. The CTI Toolkit All-Calls Monitor is a Windows application based on the C++ CIL.


Note

You can use the CTI Toolkit All-Calls Monitor application only if the number of skill groups per agent is less than 20.

C++ CIL API

The C++ CIL API is a Windows SDK for developing C++ CTI applications. The CIL provides a set of header files and static libraries for building C++ CTI applications using Microsoft Visual Studio .NET. The C++ CIL supports a secure desktop connection between the agent PC and the CTI Object Server on the PG.

The CTI Toolkit C++ CIL supports Agent Greeting Enable/Disable and Agent Greeting Recording.

Java CIL API

The Java CIL API is a cross-platform library for developing Java CTI applications. This CIL does not provide APIs for Agent Greeting Enable/Disable or Agent Greeting Recording.

.NET CIL API

The .NET CIL API is a Windows SDK for developing custom .NET framework CTI applications. The CIL provides native .NET class libraries and a .NET combo desktop. The .NET combo desktop is a sample application build using the .NET CIL.

This CIL does not provide APIs for Agent Greeting Enable/Disable or Agent Greeting Recording.

COM CIL API

The COM CIL API is a set of COM Dynamic Link Libraries (COM DLL) for building Visual Basic 6.0 CTI applications. The CTI Toolkit agent and supervisor desktops are sample applications built with Visual Basic 6.0 using the COM CIL.

The CTI Toolkit COM CIL supports Agent Greeting Enable/Disable and Agent Greeting Recording.

CTI OS Runtime Callable Wrappers

The CTI OS runtime callable wrappers provide a set of .NET assemblies that allow you to use the COM CIL and ActiveX controls in native .NET applications.

ActiveX Controls

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, and other applications that support the OC96 ActiveX standard.

The CTI Toolkit includes the following ActiveX controls:

  • Agent Greeting Enable/Disable Control

  • Agent State Control

  • Chat Control

  • Emergency Assist Control

  • Alternate Control

  • Answer Control

  • Bad Line Control

  • Call Appearance Control

  • Conference Control

  • Hold Control

  • Make Call Control (allows Agent Greeting recording)

  • Reconnect Control

  • Status Bar Control

  • Record Control

  • Transfer Control

  • Agent Statistics Control

  • Skill Group Statistics Control

  • Agent Select Control

  • Supervisor Control

  • Silent Monitor Control

For more information about the CTI OS Desktop Toolkit, see the CTI OS Developer Guide for Cisco Unified ICM/Contact Center Enterprise at http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​computer-telephony-integration-option/​products-programming-reference-guides-list.html.

Cisco Unified CRM Connector for Siebel Solution

The Cisco Unified CRM Connector for Siebel is a component that you install to enable integration of Unified CCE with the Siebel CRM environment. In this solution, the Siebel agent desktop provides the agent state and call control interface. The connector is built on top of the CTI OS Desktop Toolkit C++ CIL. The Siebel desktop uses the connector to communicate with the CTI OS server.

The Cisco Unified CRM Connector for Siebel does not support the following:

  • Agent Greeting Enable/Disable

  • Recording new agent greetings

For more information about the Cisco Unified CRM Connector for Siebel, see product documentation at http:/​/​www.cisco.com/​en/​US/​products/​ps9117/​tsd_​products_​support_​series_​home.html. For more information about the Siebel eBusiness solution, see the Siebel website.

Silent Monitoring

Silent monitoring allows supervisors to monitor the conversations of agents within their team. Supervisors cannot participate actively in the conversations and agents and callers are not aware that they are being monitored. Cisco Finesse and CTI Object Server (CTI OS) provide solutions support for silent monitoring.

Cisco Finesse supports Unified Communications Silent Monitoring only. You configure silent monitoring on Unified Communications Manager. No additional configuration is required on the Finesse server.

CTI OS supports two types of silent monitoring: Unified Communications Manager Silent Monitoring and CTI OS-based Silent Monitoring. You can configure the CTI OS server to use CTI OS-based Silent Monitoring or Unified Communications Manager Silent Monitoring, or to disable silent monitoring. When supervisor desktops connect to the CTI OS server, the desktops download the configuration. The supervisor desktop invokes the configured type of silent monitoring when the Start Silent Monitor button is clicked. The CTI OS server uses the initial message from the supervisor desktop to drive either CTI OS- based Silent Monitoring or Unified Communications Manager Silent Monitoring.

For information about how to configure silent monitoring for CTI OS, see the CTI OS System Manager Guide for Cisco Unified ICM/Contact Center Enterprise at http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-installation-guides-list.html. For information about how to implement CTI OS based or Unified Communications Manager Silent Monitoring, see the CTI OS Developer Guide for Cisco Unified ICM/Contact Center Enterprise at http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​computer-telephony-integration-option/​products-programming-reference-guides-list.html.


Note

Even for regions that are configured to use G.711, Unified CCE uses G.722 as the default codec for devices that support G.722. However G.722 is not supported with Silent Monitoring and Call Recording based on CTI OS or Unified Communications Manager. To disable this default, in Unified Communications Manager Administration, go to Enterprise Parameters and set Advertise G.722 Codec to disabled.


Note

If voice streams are encrypted, silent monitoring does not work correctly. Although the voice streams can still be captured, the silent monitoring service cannot decode them correctly.

Unified Communications Manager Silent Monitoring

Unified Communications Manager accomplishes silent monitoring with a call between the supervisor (monitoring) device and the agent (monitored) device. The agent phone mixes and sends the agent's conversation to the supervisor phone, where it is played out to the supervisor.

Unified CCE supports the Silent Monitoring functionality available in Unified Communications Manager. Unified Communications Manager Silent Monitoring supports only one silent monitoring session and one recording session for the same agent phone.


Note

Unified Communications Manager Silent Monitoring does not support mobile agents.

Unified Communications Manager Silent Monitoring can monitor any Unified CCE agent desktop, including Siebel, if the following conditions exist:

Supervisors can use any Cisco IP Phone, including Cisco IP Communicator, to silently monitor agents.

Unified Communications Manager Silent Monitoring works the same as other call control functionality provided by Unified Communications Manager (such as conference and transfer). When the silent monitoring session begins, the desktop sends a message through Unified CCE, through Unified Communications Manager, and out to the phones where silent monitoring is executed.

Messaging through Unified CCE and Unified Communications Manager impacts Unified CCE performance.


Note

We only support agent phones in Enterprise. We do not support agent phones behind a phone proxy or over the edge behind VCS Expressway.

Related Information
Sizing Unified CCE Components and Servers

Cisco Finesse

Cisco Finesse provides silent monitoring functionality through Unified Communications Manager Silent Monitoring. Finesse works with Unified Communications Manager Silent Monitoring as follows:

  1. The supervisor application sends a REST request to the Finesse server to initiate silent monitoring.

  2. The Finesse server sends the AgentSuperviseCall() message to Unified CCE to start the silent monitoring session.

  3. Unified CCE sends the CallStartMonitor() message to Unified Communications Manager.

  4. Unified Communications Manager instructs the supervisor phone to call the Built-In Bridge (BIB) on the agent phone.

  5. The supervisor phone places the call to the BIB on the agent phone.

  6. The agent phone forwards a mix of the agent voice stream and customer voice stream.

  7. Unified Communications Manager sends call events for the silently monitored call to Unified CCE.

  8. Unified CCE sends update events to the Finesse server.

  9. The Finesse server sends XMPP updates to the Finesse supervisor application.

Finesse does not support silent monitoring of mobile agents. Supervisors cannot silent monitor mobile agents and mobile supervisors cannot perform silent monitoring.

Supervisors cannot perform silent monitoring from a Finesse IP Phone. Supervisors can only perform silent monitoring from the Finesse desktop.

CTI OS

When the CTI OS server uses Unified Communications Silent Monitoring, CTI OS provides silent monitoring as follows:

  1. The supervisor initiates Silent Monitoring by sending the Agent.SuperviseCall() message to Unified CCE.
  2. Unified CCE sends the Call.startMonitor() message to Unified Communications Manager.
  3. Unified Communications Manager instructs the supervisor phone to call the Built-In Bridge (BIB) in the agent phone.
  4. The supervisor phone places the call to the BIB in the agent phone.
  5. The agent phone forwards a mix of the agent voice stream and customer voice stream.
  6. Call events for the silently-monitored call are sent from Unified Communications Manager to Unified CCE.
  7. CTI OS sends a SilentMonitorStarted event to the supervisor desktop.
  8. CTI OS sends a SilentMonitorStarted event to the agent desktop.
  9. CTI OS sends call events for the silently-monitored call to the supervisor desktop.
Figure 5. Unified CM Silent Monitoring for CTI OS

CTI OS-Based Silent Monitoring

CTI OS-based Silent Monitoring uses one or more VoIP monitoring services located on the agent desktop (desktop-based monitoring) or on a separate VoIP monitor server (server-based monitoring). CTI OS uses desktop-based monitoring to support traditional Unified CCE agents and server-based monitoring to support mobile agents.

To allow for silent monitoring in a mobile agent or Citrix deployment, the silent monitoring functionality is not part of the CIL. This functionality resides in a separate silent monitoring service. You can then deploy the service where it can access the agent's voice stream and the supervisor's sound card.

The following figures show where to deploy the silent monitoring service for each deployment model. The red line in each diagram illustrates the path of the monitored voice stream.

The following figure illustrates a deployment where the agent uses an IP phone. In this deployment, you configure silent monitoring the same whether the agent is a local agent or a mobile agent. The silent monitoring service runs alongside the CIL to provide silent monitoring functionality.

Figure 6. CTI OS-Based Silent Monitoring for Cisco Unified CCE when a Mobile or Local Agent Uses an IP Phone

The following figure illustrates a Citrix deployment where the agent uses an IP phone. The agent in this deployment can be local or mobile. The silent monitoring service is deployed on Citrix clients, where it can access the agent's voice stream and the supervisor's sound card. The CIL makes a connection to the silent monitoring service and sends instructions over a TCP connection to start and stop the silent monitoring sessions.

Figure 7. CTI OS-Based Silent Monitoring for Cisco Unified CCE with Citrix when a Mobile or Local Agent Uses an IP Phone

The following figure illustrates the deployment model for mobile agents using PSTN phones. In this model, one silent monitoring service is deployed on a switch's SPAN port to gain access to voice traffic passing through the agent gateway. Agents use the service attached to the SPAN port to forward their voice streams to the supervisor silent monitoring services. Local supervisors are deployed the same as Unified CCE supervisors. Remote supervisors are deployed the same as Unified CCE supervisors with one exception. A Cisco 800 Series Router with a hardware-based VPN is required for the supervisor to receive agent voice streams.

Figure 8. Silent Monitoring for a Mobile Agent Using a PSTN Phone

The following figure illustrates silent monitoring deployment for a mobile agent using a PSTN phone in a Citrix or Microsoft Terminal Services environment. One silent monitoring service is deployed on a switch's SPAN port to gain access to voice traffic that passes through the agent gateway. Agents use the service attached to the SPAN port to forward their voice streams to the supervisor silent monitoring services. Mobile agents need to run only their Citrix clients. Agent desktops running on the Citrix server connect to the silent monitoring server.

Local supervisors are deployed the same as Citrix Unified CCE supervisors. Remote supervisors are deployed the same as Citrix Unified CCE supervisors with one exception. A Cisco 800 Series Router with a hardware-based VPN is required for the supervisor to receive agent voice streams.

Figure 9. Silent Monitoring for a Mobile Agent Using a PSTN Phone with Citrix or Microsoft Terminal Services

In mobile agent deployments where the agents use PSTN phones, calls where the voice traffic does not leave the agent gateway cannot be silently monitored. These calls include agent-to-agent calls and agent consultations with other agents. Because the mobile agent solution requires separate gateways for callers and agents to ensure that voice traffic is put on the network, only calls between agents and customers can be reliably monitored.

Clusters

If mobile agent log in can be handled by one of two gateways, you can cluster two silent monitoring servers together. The clustered servers provide silent monitoring functionality regardless of the gateway that handles the call. A cluster-based (SPAN) deployment supports a maximum of two silent monitoring servers.

When a silent monitoring server receives a request to silently monitor an agent from the agent desktop, it forwards the request to its peer. Both silent monitor servers then attempt to detect the stream. When a server detects the agent voice stream, it forwards the stream to the supervisor's silent monitoring service.

For more information about deployment and configuration of the silent monitoring service, see the CTI OS System Manager Guide for Cisco Unified ICM/Contact Center Enterprise at http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-installation-guides-list.html.

Connection Profiles

In mobile agent deployments, agent desktops use a CTI OS connection profile to decide where and how to connect to the silent monitoring server. When an agent signs in, the agent desktop uses the following algorithm to determine the location of the silent monitoring service:

  1. If a silent monitoring service is present in the connection profile, attempt to connect to it.

  2. If no silent monitoring service is present, determine if the desktop is running under Citrix.

  3. If the desktop is running under Citrix, connect to the silent monitoring service running at the IP address of the Citrix client.

  4. 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 the silent monitoring service:

  1. If the desktop is running under Citrix, connect to the silent monitoring service running at the IP address of the Citrix client.

  2. 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, the desktops do not attempt to connect to a silent monitoring service.

Cisco Remote Silent Monitoring

Cisco Remote Silent Monitoring (RSM) allows for real-time monitoring of agents as a dial-in service. You can use RSM with the CTI-OS Toolkit desktop solution.

The RSM solution consists of three components:

  • VLEngine

  • PhoneSim

  • Callflow scripts for Unified CVP and Unified IP IVR

For more information about these components, see the Cisco Remote Silent Monitoring Installation and Administration at http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-installation-guides-list.html.

RSM Platform Considerations

The RSM solution is highly integrated into the Cisco Unified CCE environment. RSM requires resources from other components of the Unified CCE platform to function. You must understand how RSM interacts with the rest of the environment to properly integrate RSM and to plan, provision, and manage capacity.

RSM interacts mainly with the Unified Communications Manager cluster.

The RSM server ties in to each Unified Communications Manager cluster in the environment that it is configured to use as follows:
  • Simulated Phones

    The RSM PhoneSim component requires that you create a Cisco Unified IP Phone 7941 device entry on the Unified Communications Manager cluster for each of the simulated phones (simphones) that 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 Communications Manager cluster must have at least 100 simphones. To the Unified Communications Manager cluster, these simphones appear as Cisco Unified IP Phone 7941 SIP phones. However, instead of being a physical phone device, the simphones are homed to PhoneSim and controlled by PhoneSim.

    Compared to the usage profile of a physical phone device, the simphone usually puts a lighter load on the Unified Communications Manager cluster. The simphone exhibits only a small set of behaviors, consisting of:
    • Registering with the Unified Communications Manager cluster when PhoneSim starts.
    • 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 agent's conversation to the simphone.
  • JTAPI

    When 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 on the cluster.

    When supervisor monitors an agent, the RSM server makes a JTAPI monitor request call to the Unified Communications Manager cluster that manages that agent’s phone. Also, while RSM is in use, a JTAPI CallObserver is attached to each simphone device. The JTAPI CallObserver 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, encryption induces 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 at http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-installation-guides-list.html.

CTI OS Server

RSM makes a persistent monitor-mode connection to each CTI OS server that it is configured to use. Certain platform events (such as call start, call end, and agent on hold) are streamed in real-time through this connection.

RSM makes an additional, short-lived agent-mode connection to each CTI OS server when a supervisor dials in and authenticates. This connection performs a corresponding login to CTI OS to validate the supervisor's credentials. RSM does not make this connection 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, the RSM server requests the supervisor's team membership. After the request is returned, a logout is called and the connection terminates.


Note

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. In this example, the total supervisor count between CTI OS and RSM must not exceed 200.

Optionally, CTI OS connections can be encrypted through the use of IP Sec configurations. However, this optional encryption induces a significant performance penalty on the server itself when higher agent loads are used. For more information about enabling CTI OS connection security, see the Cisco Remote Silent Monitoring Installation and Administration at http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-installation-guides-list.html.

CTI Server

RSM also supports Unified CCE integration through the CTI protocol. In RSM configuration manager, you can pick either CTI or CTI OS for Unified CCE integration. When you choose between CTI and CTI OS integrations, consider these points:

  • Finesse installations without any CTI OS servers require a CTI integration.

  • To support 2000 Active Agents and 12000 Configured agents for each PG pair, use CTI integration for RSM. With CT IOS (using Java CIL), RSM can support 2000 Active agents and 8000 configured agents.

  • In most deployments, the CTI OS server supports a maximum of five monitor-mode connections. The CTI server supports a maximum of seven All-Event clients. The combined maximum of monitor-mode connections and All-Event clients on an Agent PG is nine. On VMs created from the large 4-core OVAs, you can increase those limits if the All-Event Clients use Event Minimization in their CTI Server protocol integration.
Related References
All-Event Client and Monitor-Mode Connection Limits
Voice Response Unit

The RSM platform does not directly media-terminate inbound calls. Instead, supervisors dial in to a Unified CVP or Unified IP IVR-based Voice Response Unit (VRU) system. The VRU system runs call flow script logic that interacts with services hosted on the RSM server over HTTP. Therefore, if a given RSM installation supports up to 40 supervisors, a VRU must be present (as well as the necessary PRI/network resources) that offers the same level of support.

RSM calls often place higher loads on the VRU processor and memory than more traditional VRU-type calls. More traditional VRU call flows play shorter, and often cached or non-streamed prompts. These prompts are separated by periods of gathering caller input and silence. With RSM, the predominant caller activity is monitoring agent calls. To the VRU, monitoring a call looks like the playback of a long-streaming audio prompt, which requires a relatively higher level of VRU processor involvement.

For Unified CVP deployments, supported VXML gateway models are listed in the Hardware and System Software Specification for Cisco Unified Customer Voice Portal at http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​unified-customer-voice-portal/​products-technical-reference-list.html.

When you provision a VRU for use by RSM, count each RSM call as 1.3 non-RSM calls for processor and memory usage. For example, for a VRU that can normally handle 40 concurrent calls, plan for it to handle only 30 RSM calls (40/1.3=30).

Also note that RSM makes extensive use of VXML Voice Browser functionality under both Unified CVP and Unified IP IVR.

RSM supports RTSP prompt streaming and does not require a dedicated VXML Gateway for Unified CVP installations. You do not need to configure the "ivr prompt streamed http option" in the VXML Gateway, which conflicts with Unified CVP IOS requirements. RSM scalability on Unified CVP supports 80 concurrent sessions on any Unified CVP-supported VXML Voice Gateway model and IOS version.

Agent Phones

RSM requires that agent phones have Built-In Bridge (BIB). The BIB allows the phone to fork off a copy of the current conversation stream to the RSM server. For an up-to-date list of phone models that support BIB feature, refer to the Unified CM Silent Monitoring Recording Supported Device Matrix at https:/​/​developer.cisco.com/​web/​sip/​wiki/​-/​wiki/​Main/​Unified+CM+Silent+Monitoring+Recording+Supported+Device+Matrix

Cisco Unified Contact Manager provides a maximum of one active monitoring session per agent. The agent phone can handle only one active monitoring session and one active recording session at any given time. If a third-party recorder is recording an agent's conversation, the supervisor can still monitor the agent using the supervisor's desktop or RSM. However, if both an RSM-based supervisor and a supervisor desktop-based supervisor try to monitor an agent during the same time period, the request fails with the last one to try because it exceeds the monitoring limit.

RSM sets up only one monitoring session through Unified Communications Manager for a single monitored agent. If two or more RSM users make a request to monitor the agent's call at the same time, RSM forks the stream to cover all RSM users. More than two RSM -based supervisors can monitor the same agent. However, if multiple RSM servers exist in the environment that monitor the same agent, each server makes a separate monitoring call to that agent.

If the monitoring limit is reached for a specific agent and a dialed-in supervisor then attempts to monitor the same agent, the supervisor's request is denied. The supervisor receives an audio prompt from the system that states the agent cannot be monitored.

RSM Server Considerations

An RSM server can support 12000 active agents, 72000 configured agents, and a maximum of 80 concurrent monitoring sessions. RSM can support monitoring these agents distributed across multiple PGs and supports up to a six PG clusters configuration on each server. To support greater numbers, you can deploy additional RSM servers. In all supported RSM configurations, the VLEngine and PhoneSim components are installed on the same VM.

For more information about remote silent monitoring, see the Cisco Remote Silent Monitoring Installation and Administration at http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-installation-guides-list.html.

RSM Component Interaction

The following figure illustrates the interactions that occur when a supervisor dials into an RSM-enabled platform and monitors an agent.

Figure 10. Remote Silent Monitor-Enabled Call Flow

The RSM call flow steps are as follows:

  1. A supervisor calls in and the call is media-terminated on the VRU (Unified CVP or Unified 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.

  2. The VRU makes a login request to RSM over HTTP.

  3. The VLEngine component in RSM interacts with the CTI or CTI OS server to validate the authentication credentials.

  4. The VLEngine replies to the VRU node over HTTP with the authentication result.

  5. If the supervisor is authenticated, the script in the VRU plays the main menu prompt.

  6. The supervisor chooses to monitor a single agent from the main menu and enters the directory number (DN) for the agent to monitor.

  7. The VRU checks with the VLEngine whether that agent can be monitored. The VLEngine checks wither the agent with that DN is logged in, is in talking state, and belongs to the supervisor's team, using previously cached event feed information from the CTI or CTI OS server. If the agent is available to be monitored, the VLEngine replies back to the VRU node.

  8. The VRU node sends a monitor request to the PhoneSim to monitor the entered DN. For Unified CVP, this request is sent using RSTP protocol. For Unified IP IVR, this request is sent over HTTP.

  9. The VLEngine works internally using HTTP.

  10. The VLEngine sends a JTAPI request to Unified Communications Manager to monitor the agent's phone. The VLEngine then receives a JTAPI success response.

  11. The PhoneSim component receives a SIP-based instruction from Unified Communications Manager to establish a monitoring call with the agent’s phone.

  12. The simulated phone establishes the monitoring call with the agent phone.

  13. After the monitoring call is established, the Built-In Bridge (BiB) on the agent phone forwards the call conversation to the PhoneSim in the form of RTP packets.

  14. For Unified IP IVR, the PhoneSim strips the RTP headers and streams this data to the VRU node over HTTP as a response to the request made in step 8. For Unified CVP, the PhoneSim streams the audio back to the CVP Gateway using RTSP and RTP protocols.

  15. The VRU then plays the data to the supervisor as if it were a streaming audio prompt.

RSM Deployment Models

The following sections describe some basic supported RSM deployments.

Single Site

The following figure illustrates the basic network connectivity of RMS deployed within a typical single-site configuration.

Figure 11. Typical RSM VLAN Configuration

As shown in the preceding figure, supervisors may dial in through a VoIP phone or through the PSTN. The VRU that handles the supervisor's call in this case is Unified IP IVR.

This RSM VLAN configuration also illustrates the various protocol interfaces that RSM has into the rest of the system:

  • HTTPs: VRU-based requests into the RSM system use HTTP as the carrier protocol. A request takes standard URL form as shown in the following examples: 

    http://rsmserver:8080/vlengine/checkUserCredentials?supervisorID=1101&pin=1234&outputFormat=plain
 
    http://rsmserver:8080/vlengine/canMonitorAgentID?supervisorID=1101&agentID=1001&outputFormat=vxml

    The first request is for the checkUserCredentials API call, while the second is for the canMonitorAgentID API call. Parameters to these requests are passed using the GET method. The return data (as an HTTP response) is either plain text or encapsulated in VoiceXML, depending on the API call used and on the value specified for the outputFormat parameter (if available for that call).

  • CTI or CTI OS: The RSM server makes several connections to CTI or CTI OS. One connection is for receiving platform events (monitor-mode connection). The other connections (agent-mode connections) are used to authenticate supervisor sign-ins if standard authentication facilities are used.

  • JTAPI: The request to start monitoring an agent phone is made through JTAPI. A JTAPI application user must be defined on each Unified Communications Manager cluster in the environment and be associated to all agent phones.

  • RTP: While a dialed-in supervisor monitors an agent, a monitoring call is in place from the BIB of the agent phone to the RSM server. The signaling data for this call runs through Unified Communications Manager while the RTP traffic flows between the agent phone and the RSM server.

Multisite WAN

The following figures illustrate basic supported configurations for RSM in a multisite deployment.

Figure 12. Multisite Deployment with a Single Unified Communications Manager Cluster and Single VRU

In this scenario, the Unified Communications Manager and Unified CCE environment are co-located in Atlanta. The Austin location contains the entire end-user population. The VRU is a VXML Gateway/Voice Gateway in Atlanta, controlled by a Unified CVP Server, which is also in Atlanta.

The supervisor in Austin has two ways of dialing in to the RSM system:

  • Through the PSTN — In this case, the supervisor dials an E.164 number and the call is hairpinned through the Voice Gateway. The Unified CVP RSM call flow application handles the call as normal from that point.
  • As a VoIP extension — In this case, Unified Communications Manager has a trunk configuration set up to the VRU. The call remains VoIP all the way through. The Unified CVP RSM call flow application handles the call .

In this scenario, all RSM traffic is confined to the Atlanta site except the following:

  • the RTP traffic of the monitored agent

  • the actual supervisor call into the platform

The following figure depicts a multisite deployment with a single Unified Communications Manager cluster and multiple VRUs.

Figure 13. Multisite Deployment with a Single Unified Communications Manager Cluster and Multiple VRUs

This scenario is similar to the previous scenario, 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 used, as well as the Unified CVP 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 Communications Manager and Unified CCE environment, all RSM-related JTAPI and CTI or CTI OS traffic is still confined there. However, the addition of a VXML Gateway at Austin leads to HTTP-based traffic 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 responses. The responses themselves can be sizeable, especially when it is the data for a monitored conversation.

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.

The following figure depicts a multisite deployment with multiple Unified Communications Manager clusters and a single VRU.

Figure 14. Multisite Deployment with Multiple Unified Communications Manager Clusters and a Single VRU

This scenario includes a Unified Communications Manager cluster at both the Atlanta and Austin sites and a single Unified 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 links to the CTI or CTI OS servers of both clusters to track all agents in the enterprise.

As Unified IP IVR is in use, a supervisor call to the RSM call flow is routed to, and media-terminated on, this Unified IP IVR system over either the PSTN or IP WAN. No VXML Gateway is involved in this configuration, and all RSM-related HTTP interaction is confined to the Atlanta site, between the RSM and Unified IP IVR systems.

Because a Unified Communications Manager cluster exists at the Austin site, several classes of data that RSM uses to track environment state and initiate agent monitoring requests (CTI or CTI OS and JTAPI traffic) are sent over the IP WAN.

The following figure depicts a multisite deployment with multiple Unified Communications Manager clusters and multiple VRUs.

Figure 15. Multisite Deployment with Multiple Unified Communications Manager Clusters and Multiple VRUs

In this scenario, a Unified Communications Manager cluster and a Unified CVP VXML Gateway/Voice Gateway exist at each site. This deployment model is a combination of the previous models, and has the following characteristics:
  • The Unified CVP Server controls the VXML Gateway 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. A supervisor can dial in from either site (or from anywhere in the world through PSTN) and listen to an agent in Atlanta or Austin.
Single Cluster with Multiple PG/CTI OS
The following diagram depicts a setup involving a single Unified Communications Manager cluster and multiple (up to 4) Agent PG/CTI OS servers:
Figure 16. Single Unified Communications Manager Cluster and Multiple (up to four) Agent PG/CTI OS Servers

In this scenario, a separate Agent PG/CTI OS server is deployed for each subscriber node pair (primary and backup).

A separate RSM cluster (in a single RSM instance) should be configured that corresponds to each Agent PG/CTI OS server and its Unified Communications Manager subscriber pair.

Related Concepts
Deployment of Agent PG in Unified Communications Manager Cluster
Multiple Cluster with Multiple PG/CTI OS

The following diagram depicts a setup involving multiple Unified Communications Manager clusters and multiple Agent PG/CTI OS servers.

Figure 17. Multiple Unified Communications Manager Clusters and Multiple Agent PG/CTI OS Servers

In this scenario, a separate Agent PG/CTI OS server is deployed for each Unified Communications Manager cluster.

A separate RSM cluster (in a single RSM instance) should be configured that corresponds to each Agent PG/CTI OS Server and its Unified Communications Manager cluster subscriber pair.

Remote Silent Monitoring Bandwidth Requirements

Before you deploy the RSM solution, verify that your network infrastructure can support the bandwidth requirements of RSM.

The RSM solution connects with multiple components in the larger Cisco environment. The following table 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 1 Bandwidth Requirements

RSM peer

Purpose

Protocols used

Data format

Relative bandwidth requirements

Link latency requirements

VRU

Service requests / responses

TCP (HTTP)

Textual

Minimal

< 500 ms avg.

VRU

Requested voice data from PhoneSim to VRU

TCP (HTTP)

TCP (RTSP)

UDP (RTP)

For IP IVR - 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.

Unified CM

Issuance of agent phone monitoring

TCP (JTAPI)

Binary (JTAPI stream)

Minimal

< 300 ms avg.

CTI or CTI OS server (PG)

Environment events / supervisor logins

TCP (CTI or CTI OS)

Binary (CTI or CTI OS stream)

Minimal(< 1000 agents)

Moderate(> 1000 agents)

(with 2000 agents, about 100 kbps)

< 300 ms avg.

Agent phones

Simulated phone signaling

TCP or UDP (SIP)

Textual

Minimal

< 400 ms avg.

Agent phones

Monitored phone voice data

UDP (RTP)

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

The simulated phones on the 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 information about bandwidth usage, see the Cisco Voice Over IP - Per Call Bandwidth Consumption Tech Note.

Sufficient bandwidth must be 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.

Use the Cisco TAC Voice Bandwidth Codec Calculator for additional bandwidth capacity planning.

RSM Codec Support

The monitoring call established between the RSM simulated phone (simphone) and agent phone is subject to regular call admission control (CAC) procedures. The simphones on the 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.

Incoming Calls from Phone (BIB) to RSM

For all incoming calls from phone (BIB) to RSM, the built-in phone transcoding resources transcode the call (if necessary) and send it on to the monitoring call leg. No additional transcoding resources are needed on Unified Communications Manager or Voice Gateway. If the incoming call is G.729, configure the RSM Sim Phones Region to allow a Max Audio Bit Rate of 8 Kbps. If the incoming call is G.711, configure the RSM Sim Phones Region to allow a Max Audio Bit Rate of 64 Kbps.


Note

The Cisco IP phone's BIB does not support dual codec calls. If the Caller-Agent conversation is in G.729, the media forking to RSM is also in G.729.

Outgoing Calls to Unified 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. The RSM server performs the necessary transcoding. No Voice Gateway transcoding resources are needed.


Note

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 requirement 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, configure RSM in a standalone call flow.

Outgoing Calls to Unified IP IVR Systems from RSM

The outgoing monitoring call leg is G.711 u-law. The RSM server transcodes to G.711 u-law, if transcoding is necessary.

For more information, see the section on codecs for monitoring and recording calls in the Feature Configuration Guide for Cisco Unified Communications Manager at http:/​/​www.cisco.com/​c/​en/​us/​support/​unified-communications/​unified-communications-manager-callmanager/​products-installation-and-configuration-guides-list.html.

Failover Redundancy and Load Balancing

RSM does not support true failovers or load balancing. RSM does support the deployment of multiple standalone RSM servers within a single Unified CCE environment. This concept is demonstrated in the advanced deployment scenarios described in this document.

The following table indicates how a failure of each of the various components affects a live supervisor call.

Table 2 Impact of Failures on a Supervisor Call

Component that fails

Worst possible impact

VRU node (Unified IP IVR, Unified CVP)

The supervisor's call is terminated as any VRU fail-over occurs (depends). The 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 are 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) results in a configurable delay of 3 to 5 seconds, 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 or attempting to monitor an agent), fails. The RSM callflow is answered because it is hosted on the VRU node.

VLEngine or PhoneSIM software failure

Service automatically restarted via service wrapper. Supervisors with a request in-progress receive an error message and can 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 or attempting to monitor an agent), fails. The RSM callflow is still answered because it is being hosted on the VRU node.

Unified CCE fails (CTI or CTI OS)

RSM loses connectivity to the CTI or CTI OS server when the PG fails or is cycled. If connectivity to both CTI servers on a cluster fails, RSM keeps retrying both, and connects to the first available server. (The CIL failover 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 works 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 Communications Manager 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 fails 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 periodically retries both and re-establishes connectivity to the first available provider. Attempts to monitor agents (for example, monitorAgent calls) made during this time fail until the JTAPI connection is re-established.

Host-Level Security

You can restrict incoming access to the RSM server to only the necessary components with the host-based Access Control List (ACL) functionality in the Windows Server OS. In the most secure configuration, incoming access to the RSM system is permitted from the VRU systems. You can also employ this host-based access control to allow limited access to other services, such as remote administration mechanisms like Windows Remote Desktop and VNC.

ACL is not required, but an example 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)

Transport or Session-Level Security

Because RSM maintains multiple connections to a number of components in the contact center environment, support for transport or session-level security varies by protocol type. The following notes describe RSM support for transport or session-level security by protocol type:

RSM to VRU (HTTP, RTSP, and RTP)
Encryption of the HTTP-, RTSP-, and RTP-based data exchange between RSM and the VRU node is not supported.
RSM to PG/CTI OS Server (CTI)
Because RSM makes use of the Java CIL, all CTI OS servers that use RSM 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 section on security settings in the Cisco Remote Silent Monitoring Installation and Administration at http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​unified-contact-center-enterprise/​products-installation-guides-list.html.
RSM to Unified Communications Manager (JTAPI)
Like CTI OS traffic, JTAPI traffic may be encrypted through the use of IPSec transport mode encryption. For more information, see the section on security settings in the Cisco Remote Silent Monitoring Installation and Administration.
RSM to Agent Phone (RTP)
Encryption of the RTP stream between agent phones (BIB) and the RSM SimPhone is not supported. RSM SimPhones do not support secure RTP (SRTP).

Support for Mobile Agent, IP Communicator, and Other Endpoints

Unified Communications Manager monitoring functionality does not provide monitoring support for endpoints using any one of the following:
  • Cisco Mobile Agent
  • Phones that do not have a Built-In Bridge (BIB).
  • A media-terminated CTI OS agent desktop
  • Monitoring of encrypted phone calls

Therefore, support for these products is also not available through RSM. See the Unified CCE Solution Compatibility Matrix at http:/​/​docwiki.cisco.com/​wiki/​Compatibility_​Matrix_​for_​Unified_​CCE for a list of supported phones.

Related References
Silent Monitoring

Deployment Considerations

Citrix and Microsoft Terminal Services

This section discusses Unified CCE desktops in a Citrix or Microsoft Terminal Services (MTS) environment.


Note

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

Cisco Finesse

Cisco Unified CCE supports running the Cisco Finesse desktop within a Citrix environment. Finesse supports Citrix XenApp and XenDesktop.

For more information about supported versions, see the Unified CCE Solution Compatibility Matrix at http:/​/​docwiki.cisco.com/​wiki/​Compatibility_​Matrix_​for_​Unified_​CCE.


Note

You cannot use Cisco Finesse with Microsoft Terminal Services.

CTI OS Toolkit Desktop

Cisco Unified CCE supports running CTI Toolkit Desktop within the Citrix and Microsoft Terminal (MTS) Services environments. if you plan to use Citrix terminal services with the CTI Toolkit Desktop, take the following considerations into account:

  • 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.

For implementation details, see Integrating Cisco CTI OS Into a Citrix Metaframe Presentation Server/Microsoft Terminal Services Environment at http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​computer-telephony-integration-option/​products-installation-and-configuration-guides-list.html.


Note

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.

NAT and Firewalls

This section discusses deploying CTI Toolkit Desktop and Cisco Finesse in an environment where two or more disjointed networks are interconnected using Network Address Translation (NAT).

For more information about NAT and firewalls, see the chapter "Securing Cisco Unified Contact Center Enterprise".

Cisco Finesse and NAT

Cisco Finesse provides limited support for NAT. Finesse does support basic NAT (one-to-one IP address mapping) between Finesse servers and Finesse clients.

The following caveats apply to Finesse and NAT:

  • You cannot use PAT/NPAT (one-to-many address mapping that uses ports) between Finesse servers and Finesse clients.

  • You cannot use NAT between the Finesse servers and any of the servers to which they connect (such as Unified CCE or Unified Communications Manager servers).

  • Finesse IP Phone Agent (IPPA) does not support NAT.

CTI Toolkit Desktop and NAT

When you deploy the Cisco CTI Toolkit Desktop in a network environment where NAT connects two or more disjointed networks, Unified Communications Manager, the physical IP phone, the CTI OS server, CTI Toolkit Desktop, and the CTI OS Unified CCE supervisor desktop must all be on the same network.

Cisco 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 with the following limitations:

  • The maximum number of CTI all events connections supported by the CTI server (seven) is not exceeded.

  • The total number of combined Finesse and CTI OS agents does not exceed the capacity of the common PG.

If a mix is deployed, the sizing limitations of Finesse apply.


Note

The Finesse supervisor application can monitor only Finesse agents and the CTI OS supervisor application can only monitor CTI OS agents.

IP Phone and IP Communicator Support

Cisco Finesse and the CTI Toolkit Desktop support the use of Cisco IP hardware phones and the Cisco IP Communicator software phone.

For more information about the phone models and IP Communicator versions that each desktop supports, see the Unified CCE Compatibility Matrix at http:/​/​docwiki.cisco.com/​wiki/​Compatibility_​Matrix_​for_​Unified_​CCE.

IP Phones and Silent Monitoring

Silent monitoring supports both IP hardware phones and Cisco IP Communicator.

IP Phones and Mobile Agent

The Mobile Agent feature does not require any specific type of phone. You can even use analog phones with this feature.

IP Phones and Citrix or MTS

Finesse and the CTI Toolkit Desktop support both IP hardware phones and Cisco IP Communicator when using Citrix or MTS. In these environments, you must install Cisco IP Communicator on the agent desktop PC. You cannot deploy Cisco IP Communicator on the Citrix or MTS server.

Cisco Jabber Support

Cisco Finesse supports Cisco Jabber for Windows as a contact center voice endpoint. Finesse supports the following Jabber functionality:

  • Voice and Video

  • Built-In Bridge (BIB) for silent monitoring

  • IM and Presence


Note

Agents cannot use Jabber to transfer or conference calls. Agents must use the Finesse desktop for transfer and conference.

To use Jabber with Finesse, you must change the default Jabber configuration as follows:

  • Change Maximum number of calls from 6 to 2.

  • Change Busy trigger from 2 to 1.

Desktop Latency

You can locate Agent and Supervisor desktops remotely from the Agent PG. In a poorly designed deployment, high time-out values can cause the delay between the desktop server and desktop clients to be too high. Large latency affects the user experience and can become confusing or unacceptable from the user perspective. For example, the phone can start ringing before the desktop updates. Limit the latency between the server and agent desktop to 400-ms round-trip time for Finesse and CTI OS.

Finesse also requires that you limit latency between the Finesse server and the PG to 200-ms round-trip time.

Was this Document Helpful?

FeedbackFeedback

Contact Cisco

Related Cisco Community Discussions

About Us
Contact Us
Work with Us