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/​.

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

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)

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

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.

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

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.

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.

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

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

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.

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.

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

The following sections describe some basic supported RSM deployments.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.