This figure shows the logical connections under general operating conditions between the sides in a redundant data center.

This figure shows the logical connections under general operating conditions between the sides in a redundant data center.

This figure shows the logical connections under general operating conditions between the sides in a redundant data center.

For the 24000 Agent Reference Design, the logical connections under general operating conditions follow the pattern of the 12000 Agent Reference Design. However, there are a minimum of 12 CVPs, PGs, and Finesse servers.

Unified CVP supports Cisco IOS XE software with the following limitations:

• The ASR 1000 Series gateways do not support VXML. So, route the VRU leg of the call to a separate VXML Gateway. Do not use the Send To Originator setting on the CVP Call Server to route the VRU leg of the callback to the originating ASR CUBE Gateway. Route standalone CVP calls to a separate VXML Gateway.

• Unified CVP does not support the global Pass Thru SDP setting on the ASR 1000 Series gateways.

• The Courtesy Callback call flow does not work if you configure the ASR as CUBE for the media flow-around, instead of the media flow-through.

• Typically, you position a proxy server behind the session border controller. If the proxy is in front of the ASR session border controller, use the proxy servers to perform UDP to TCP Up-Conversion when receiving large packet SIP messages. In this case, turn off the proxy servers to ensure that UDP transport is used for the connection on the inbound call.

• Do not use the following Survivability.tcl options on the ASR. These options are traditionally for POTS dial peers:

  • ani-dnis-split.

  • takeback-method.

  • -- *8.

  • -- hf.

  • icm-tbct.

  • digital-fxo.

• The following Survivability.tcl options are not supported:

  • aa-name—This option is not supported because ASR does not support the CME auto-attendant service.

  • standalone—This option is not supported because ASR does not support VXML.

  • standalone-isntime—This option is not supported because ASR does not support VXML.

• Due to ASR limitations, the following features are not supported:

  • Refer with Re-query

  • Legacy Transfer Connect using DTMF *8 label

• ASR 1000 does not terminate the TDM trunks. Therefore, the following TDM Gateway features do not apply to ASR 1000:

  • PSTN Gateway trunk and DS0 information for SIP calls to Unified CCE

  • Resource Availability Indication (RAI) of DS0 trunk resources through the SIP OPTIONS message to Unified CCE

Note	If your solution uses ASR 1000 Series gateways, it requries an Assessment to Quality (A2Q) review. This review is required for new contact center enterprise solutions and existing solutions that are upgrading to the ASR 1000.

Unified CVP supports ISR with the following limitations:

• The Courtesy Callback call flow does not work with ISR as CUBE configured for the media flow-around. Configure it for the media flow-through instead.

The VXML Gateway allows customers to interact with the VXML browser through DTMF tones or ASR/TTS. Because the gateway does not have PSTN interfaces, voice traffic is sent using Real-Time Transport Protocol (RTP) to the VXML Gateway. The RFC 2833 uses in-band signaling in RTP packets to transmit DTMF tones. A VXML with DTMF or ASR and TTS allows you to increase the scale of the deployment and support hundreds of VXML sessions.

In a branch office topology, you can deploy a separate PSTN Gateway and a VXML Gateway to provide an extra layer of redundancy In addition, provide support for Survivable Remote Site Telephony (SRST) at the branch office.

The VXML Server and Voice browser communicate with request-response cycles using VXML over HTTP. Uniform Resource Identifiers (URI) link the VXML documents together. Users input information by web forms similar to HTML. The forms contain input fields that the user edited and sent back to a server.

Resources for the Voice browser are located on the VXML Server. These resources are VXML files, digital audio, instructions for speech recognition (Grammars), and scripts. The VXML browser begins every communication process with the Voice application as a request to the VXML Server. The VXML files contain grammars that specify expected words and phrases. A link contains the URL for the Voice application. The browser connects to that URL when it recovers a match between spoken input and one of the grammars.

Note	The CVP installer installs the CVP Call Server, the CVP VXML Server, and the Media Server together.

The following points are key to determining the VXML Server performance:

• QoS and network bandwidth between the Web application server and the voice gateway

• Performance on the VXML Server

• Use of prerecorded audio versus Text-to-Speech (TTS)

  Voice user-interface applications tend to use prerecorded audio files wherever possible. Recorded audio sounds better than TTS. Choose the quality of the prerecorded audio fileso that it does not impact download time and browser interpretation. Make the recordings in the 8-bit mu-law 8 kHz format.

• Audio file caching

  Ensure that the voice gateway is set to cache audio content. Caching prevents delays in downloading files from the media source.

• Use of Grammars

  You can discover problems in a voice application only through formal usability testing or observation of the application in use. Poor speech recognition accuracy is a common problem with voice applications. It is most often caused by poor grammar implementation. When users mispronounce words or say things that the grammar designer did not expect, the recognizer cannot match their input against the grammar. Another common problem for grammars is many difficult-to-distinguish entries. These entries result in many incorrectly recognized inputs and decrease the performance of the VXML Server. Improve the recognition accuracy by analysizing its performance and tuning the grammar appropriately.

Your solution can use Ingress Voice Gateways at a branch office to provide callers with access by local phone numbers, instead of by centralized or nongeographic numbers. This capability is important for solutions that span multiple countries.

Your solution can use Egress Gateways at branches either for a localized PSTN breakout or to integrated decentralized TDM platforms into your solution.

The other components of your solution are centrally located. The WAN links provide data connectivity from each branch location to the main site.

Other voice services that run at the branch can affect the Ingress or VXML Gateways. For example, if the branch is a remote Unified CM site, Unified CM can support both ACD agent lines and nonagent lines. This deployment uses the PSTN gateway for new contacts and traffic from the nonagent lines. When a branch has the VXML and Voice Gateway functions on separate devices, ensure that the dial plan sends the VRU leg to the local VXML resource. This is because the Unified CVP Call Server settransferlabel label applies only to coresident VXML and Voice Gateway configurations.

Your solution can either have all gateways and servers centralized or have a set of colocated Unified CVP VXML Servers and VXML Gateways at each site.

Colocation has the following advantages:

• A WAN outage does not affect self-service applications.

• VXML uses no WAN bandwidth.

Colocation has the following disadvantages:

• Replicated branch offices require extra Unified CVP VXML Servers.

• Deploying applications to multiple Unified CVP VXML Servers creates more overhead.

Advantages of centralized VXML:

• Administration and reporting are centralized.

• Branch offices can share Unified CVP VXML Server capacity.

Disadvantages of centralized VXML:

• Branch survivability is limited.

• Requires more WAN bandwidth for VXML over HTTP traffic.

When you set up a dial plan and call routing, you can combine Unified CVP features to achieve the required effect. For example, you can use Location Based CAC, SigDigits, SendToOriginator, LocalSRV, and Use Outbound Proxy.

CVP uses this process to formulate the destination SIP URI for the outbound calls from Unified CVP. This description covers CONNECT messages that include labels from the Unified CCE (for example, VXML Gateway, and Unified CM). It also applies for calls to the ringtone service, recording servers, and error message playback service.

Note

This process only describes calls using the SIP subsystem, which includes audio only and basic video SIP calls. CVP supports the SendToOriginator algorithm only for a colocated IOS VXML Gateway and Ingress Voice Gateway. Cisco Virtualized Voice Browser (VVB) does not support this algorithm because the gateways cannot be colocated when you use Cisco VVB.

The process for creating the destination SIP URI host portion for outbound calls, which includes the Unified CCE label, is as follows:

1. The process starts with the Unified CCE label. The Unified CCE subsystem might already have inserted the Location siteID. If you're using SigDigits, they are prepended. For network VRU labels, the Unified CCE subsystem passes in the entire prefix and correlation ID as the label.

2. If SendtoOriginator is matched for the Unified CCE label, the Unified CVP algorithm uses the IP or hostname of the caller (Ingress Voice Gateway). The gateway returns the SIP URI.

   The setting for SendtoOriginator only applies to callers on Cisco Ingress Voice Gateways (the SIP UserAgent header is selected). Non-Cisco IOS Gateways do not have the CVP bootstrap service that the Cisco IOS VXML Gateway uses.

3. If use outbound proxy is set, then use the host of the proxy and return SIP URI.

4. If local static route is found for the label, return the SIP URI.

   Note	If local static route is not found, the algorithm throws a RouteNotFoundException exception.

Consider these points for calls using the SIP subsystem:

• To avoid complex Dialed Number strings, do not use the SigDigits feature with Locations CAC siteIDs.

• You can specify an Outbound Proxy FQDN as a Server Group FQDN (local SRV FQDN). You can also configure a local static route destination as a Server Group FQDN.

• Ringtone DN (91919191), Recording Server (93939393), and Error message services (92929292) follow the same process.

• SendtoOriginator can work with a REFER label.

• A REFER label can work with the SigDigits setting.

You can deploy voice prompts with the following methods:

• Local File System

  Store the voice prompt files on a local system. Audio prompt retrieval uses no bandwidth. With this method, Voice Browsers do not have to retrieve audio files for playing prompts, so WAN bandwidth is not affected. However, to change a prompt, you change it on every Voice Browser.

  • IOS VXML Gateway—Prompts are deployed on flash memory.

    An IOS VXML Gateway is either a VXML Gateway or a PSTN Gateway, which has the Ingress Voice Gateway and VXML Gateway colocated. Store only critical prompts here, such as error messages or messages for when the WAN is down.

    When recorded in G.711 mu-law format, typical prompts are about 10 to 15 KB in size. For these gateways, size the flash memory by factoring in the number of prompts and their sizes. Also leave space for storing the Cisco IOS image.

  • Cisco VVB—Prompts are uploaded on the local file system.

    Cisco VVB includes built-in CVP prompts. You can change the Error tone default prompt through the Cisco VVB Administrator console.

• Media Server

  Each local Voice Browser, if configured properly, can cache many prompts, depending on the size of the prompts. Cisco VVB can cache up to 512 MB and Cisco IOS can cache up to 100 MB. To test whether your Media Server is appropriately serving the media files, specify the URL of a prompt on the Media Server in a browser. Your web browser downloads and plays the .wav file without any authentication.

The design of a Media Server deployment depends on the following factors:

• The number of media files that each gateway plays

• The network connectivity between the gateway and the Media Server

• How often you change the media files

If your gateway plays many different media files to your customers, the gateway might not have space to cache all the media files.

For example, consider an enterprise with many agents. Each agent has their own agent greeting file. You cannot cache all those files in the gateway flash memory.

Consider the following points when designing your solution with the CVP Reporting Server:

• You can size the Informix database up to 100 GB. You cannot use a 2 GB or smaller database in a production environment.

• The Reporting Server supports the Analysis Manager tool. The Analysis Manager can query the Reporting Server with an authenticated user's credentials.

• The Reporting Server aggregates Unified CVP data in 15-minute increments. Cisco Unified Intelligence Center provides templates to display call data and dominant path information at 15-minute, daily, and weekly intervals.

• All metadata for administrative processes is in the Ciscoadmin database. This location removes the tables from the general view of reporting users.

• All database backup files are compressed and stored on the Reporting Server. The backup file is called cvp_backup_data.gz and is stored on the %INFORMIXBACKUP% drive in the cvp_db_backup folder.

• Using the system CLI, you can make the request to list log files on the Reporting Server (show log). This request includes the Informix Database Server Engine logs. The show tech-support command also includes these files.

• With the debug level 3 (or 0) command from within the System CLI, you can turn on and turn off the debug. When turned on, this command generates trace files for all administrative procedures, Purge, Statistics, and Aggregator.

  Note	After the command is turned on, trace files place an elevated burden on the database.

• Log data for administrative procedures are written on a nightly basis to the %CVP_HOME%\logs folder.

• All the StartDateTime, EndDateTime, and EventDateTime values are stored as UTC in Reporting Server tables.

• Transfer Type data and Transfer Labels for SIP call events are stored in the call event table.

• Summary purge results are logged in the log table.

• Three new scheduled tasks have been added to the Reporting Server scheduler:

  • CVPSummary, which builds summary tables.

  • CVPCallArchive, which archives Callback data to maintain callback database performance.

  • CVPLogDump, which extracts the administrative logs on a nightly basis.

Using the Operations Console, you can schedule daily database backups or run database backups on-demand. In a major failure, you can restore the database manually to the last backup time. This limits the loss of data to 24 hours at most.

The Agent PG communicates with the Unified CM cluster through the CTI Manager. An Agent PG can control agent phones and CTI route points anywhere in the cluster. The Agent PG registers with the CTI Manager on a Unified CM subscriber in the cluster. The CTI Manager accepts all JTAPI requests from the PG for the cluster. When the PG requests a phone or route point on another subscriber, the CTI Manager forwards the request to the other subscriber.

Note	The Agent PG is the PG that includes the Unified CM PIM. It is sometimes called a Unified CM PG. In Non-Reference Designs only, the Agent PG might be a Generic PG.

A fault-tolerant design deploys Agent PGs in a redundant configuration, because a PG only connects to the cluster through a single CTI Manager. If that CTI Manager fails, the PG cannot communicate with the cluster. A redundant PG provides a secondary pathway through a different CTI Manager on a different subscriber in the cluster.

The minimum design for a high-availability cluster is one publisher and two subscribers. If the primary subscriber fails, the devices rehome to the secondary subscriber and not to the publisher for the cluster.

The redundant PGs keep in synchronization through a private network that is isolated from the public network. If the two PG servers are geographically distributed, use a separate WAN connection for the private network. To avoid a single point of failure in the network, do not use the same circuits or network gear as for the public network.

Within the Agent PG, the JTAPI Gateway and Unified CM PIM manage the connectivity to the cluster. The JTAPI Gateway handles the JTAPI socket connection protocol and messaging between the PIM and the CTI Manager. The PIM manages the interface between Unified CCE, the JTAPI Gateway, and the cluster. It requests specific objects to monitor and handle route requests from the cluster. The PG starts the JTAPI Gateway and PIM automatically as node-managed processes. The PG monitors the processes and automatically restarts them if they fail.

The JTAPI services from both redundant Agent PGs sign in to the CTI Manager after initialization. Agent PG-A signs in to the primary CTI Manager; Agent PG-B signs in to the secondary CTI Manager. Only one PG in each pair actively registers and monitors phones and CTI route points. The redundant PG runs in hot-standby mode. The redundant PG signs into the secondary CTI Manager only to initialize the interface and make it available for a failover. This arrangement significantly decreases the time for the failover.

When the system starts, the PG that first connects to the Router server and requests configuration information is the active PG. The Router ensures that the PG with the best connection becomes active. The nominal designations of “Side A” and “Side B” do not affect which PG becomes active. During a PG failover caused by a private link failure, a weighting mechanism chooses which PG is active to minimize the impact on the contact center.

If calls arrive at the CTI Route Points before the PIM is operational, the calls fail unless you set up a recovery number. Place the recovery number in the route points' Call Forward on Unregistered or Call Forward on Failure setting. For example, you can set the recovery numbers to the Cisco Unity voicemail system for the Auto Attendant.

Note	You cannot use the DN for a CTI Route Point on a different CTI Route Point in another partition. Ensure that DNs are unique across all CTI Route Points on all partitions.

In the standard three PG model, the VRU PG includes two PIMs with a 1:1 pairing to a CVP servers on Side A and Side B.

In the standard three PG model, the MR PG includes PIMs to support these functions:

• Outbound Option

• Enterprise Chat and Email

• Customer Collaboration Platform—This PIM handles Task Routing and Agent Request.

• Third-party integrations

Use the Live Data coresident configuration for 2000 Agent Reference Designs. For solutions with a standalone Live Data server, you typically use the small Live Data deployment configuration with a Unified CCE Rogger deployment. You typically use the large Live Data deployment configuration with a separate Router and Logger.

Note	The standard Cisco Finesse agent desktop includes the Live Data gadget.

Cisco Finesse supports the configuration of multiple lines on agent phones if Unified CCE is configured for multiline. You can configure several secondary lines on an agent phone. However, the Cisco Finesse server blocks any events that the CTI server sends in response to operations on secondary lines. The Cisco Finesse server does not publish these events to the Cisco Finesse clients. Information about calls on secondary lines does not appear on the Cisco Finesse desktop.

If your agents use 8900 Series or 9900 Series phones, enable Multi-Line on the Unified CM peripheral. This configuration option is a peripheral-wide option. If you enable Multi-Line for even one agent with an 8900 Series or 9900 Series phone, enable it for all agents.

To support multiline, configure all phones with the following settings:

• Set Maximum number of calls to 2.

• Set Busy trigger to 1.

Contact center enterprise solutions support running the Cisco Finesse desktop within a Citrix environment. Cisco Finesse supports Citrix XenApp and XenDesktop.

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

For more information about supported versions, see the Compatibility Matrix for your solution at https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.html.

Some solutions have two or more disjointed networks that interconnect with Network Address Translation (NAT).

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

The following caveats apply to Cisco Finesse and NAT:

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

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

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

Note	For more information about NAT and firewalls, see the chapter on solution security.

Cisco Finesse supports Cisco Jabber for Windows as a contact center enterprise voice endpoint. Cisco 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 Cisco Finesse desktop for transfer and conference.

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

• Change Maximum number of calls from 6 to 2.

• Change Busy trigger from 2 to 1.

For more information on support for Jabber, see the Compatibility Matrix for your solution at https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.html.

Unified CCE publishes real-time updates in agent, skill group, and calltype states through WebSockets. Unified Intelligence Center reports consume these messages directly from Live Data Services and display the updates in real time.

In Unified CCE, the Live Data Service resides on its own VM.

Live Data reports can run in the Unified Intelligence Center Report Viewer. Cisco Finesse desktops can show Live Data reports in gadgets. They use a WebSocket tunnel from the Cisco Finesse desktop parent container to one of the Live Data Services. The gadget creates the tunnel during loading.

If a WebSocket connection fails, the Live Data reports automatically fail over to the currently connected Live Data node.

This figure shows the architecture for Live Data reporting in a contact center enterprise deployment:

The Unified Intelligence Center stock reports use the Administration & Data Server as their data source. A contact center enterprise deployment can have multiple Administration & Data Servers. Unified Intelligence Center uses the database and its views as the tables for the data source queries.

The Unified Intelligence Center installation adds two data sources to the reporting (member) nodes:

• The historical data source, which supplies data for the historical reports and user integration

• The realtime data source, which supplies data for the realtime reports

Your deployment can use the same AW-HDS for both data sources, or you can configure a different server for each data source. Unified Intelligence Center requires an AW-HDS as a data source for standard historical reports. But, it can also use an AW as a data source for standard real-time reports. Unified Intelligence Center requires an AW-HDS-DDS or HDS-DDS as the data source for custom reports on TCD records.

For deployments that import reports from Unified CVP, Unified Intelligence Center uses the CVP Reporting Server as the data source.

The CVP Reporting Server houses the Reporting Service and hosts an IBM Informix Dynamic Server (IDS) database management system. The database's schema is available to enable you to write custom reports for the database. Your solution can include several CVP Reporting Servers.

Unified Intelligence Center only connects to the CVP Reporting Server. The CVP Reporting Server mediates between the other Unified CVP subcomponents and Unified Intelligence Center.

Use the Task Routing APIs to request, queue, route, and handle third-party multichannel tasks in CCE.

We support these use cases:

• Agents handling multiple concurrent tasks in a single Media Routing Domain (MRD), and across MRDs.

• Interruptible MRDs. Agents handling tasks in those MRDs can be interrupted by tasks in other MRDs. For example, you can set an email MRD to be interruptible, meaning that an agent handling an email task can be interrupted by a task from another MRD, such as a voice call or a chat.

• Blind transfer to a specified script selector. Direct transfer is not supported.

• Agent sign out with assigned tasks. Those tasks are either closed or transferred, depending on the agent's dialogLogoutAction setting in the Finesse Media API.

• RONA. If an agent does not accept an offered task within the Start Timeout threshold for the MRD, Finesse resubmits the task for routing and makes that agent not routable.

This task flow describes a typical multichannel scenario, in which an agent is configured to handle email and chat tasks.

The email Media Routing Domain (MRD) is interruptible, and the agent is set to accept interrupts in that MRD. Because the email MRD is interruptible, an agent handling an email task can be interrupted with tasks from other MRDs. Because the agent is set to accept interrupts, the state of the agent, email task, and Finesse dialog in the email MRD change to INTERRUPTED if the agent is assigned a task in another MRD. The agent also cannot perform work on the email task while interrupted.

The chat MRD is non-interruptible.

See the Cisco Unified Contact Center Enterprise Features Guide at https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.html for more information about MRD interruptibility and accepting or ignoring interrupts.

The partner has developed email and chat applications that are integrated with the Finesse and Customer Collaboration Platform APIs.

1. A customer sends an email to the company. The email application submits a new email task request to CCE. The task request includes a script selector and Call and ECC variables with customer-specific information, including the handle to the email.

2. CCE maps the script selector to a call type, which determines which routing script to run. The routing script queues the email task to the appropriate skill group or precision queue in the email MRD.

3. The email application polls for status and Estimated Wait Time (EWT).

4. An agent signs in to the email MRD and changes to Ready state.

5. CCE assigns the email to the agent. The Call and ECC variables used to create the task are included in the dialog's media properties. The application uses these variables to allow the agent to reply to the email. The agent starts work on the email dialog in Finesse.

6. Another customer sends a chat request to the company. The chat application submits a new chat task request to CCE. The Call and ECC variables include the chat room URL.

7. CCE maps the script selector submitted with the chat request to a call type, which determines which routing script to run. The routing script queues the chat task to the appropriate skill group or precision queue in the chat MRD.

8. The chat application polls for status and Estimated Wait Time (EWT).

9. While working on the email task, the same agent signs in to the chat MRD and changes to Ready state.

10. CCE assigns the chat task to the agent. The application uses the Call and ECC variables to add the agent to the chat room with the customer. The agent starts work on the chat dialog in Finesse.

11. The agent's state in the email MRD changes to Interrupted, and the email dialog state changes to Interrupted. The application disables actions for the email dialog.

12. The agent transfers the chat task to a different script selector. Finesse closes the chat dialog and resubmits the task to Customer Collaboration Platform. The application closes the chat room.

13. The agent is not handling other non-interruptible dialogs, and the email dialog becomes active.

14. The agent continues working on the email dialog. The agent pauses the dialog to take a short break, and then resumes the dialog.

15. When the email reply is complete, the agent performs wrap up work for the dialog. The agent closes the dialog. Finesse sends a handle event to Customer Collaboration Platform for the email task. The application sends the email reply to the customer.

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

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

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

3. Unified CCE sends the CallStartMonitor() message to Unified CM.

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

5. The supervisor phone calls the BIB on the agent phone.

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

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

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

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

Cisco 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 Cisco Finesse IP Phone. Supervisors can only perform silent monitoring from the Cisco Finesse desktop.

Unified CM 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 plays to the supervisor.

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

Note	Unified CM Silent Monitoring does not support mobile agents.

Unified CM Silent Monitoring can monitor any Unified CCE agent desktop, if the following conditions exist:

• The monitored agent uses a compatible Cisco Unified IP phone or Cisco IP Communicator. For more details, see the Compatibility Matrix for your solution.

• The contact center uses a compatible version of Cisco Unified CM. For more information, see the Compatibility Matrix for your solution.

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

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

Messaging through Unified CCE and Unified CM impacts Unified CCE performance.

• For agent to agent call transfer, network-based recording does not work but phone-based recording does. If you want to use network-based recording, you can use an ISR gateway between Unified CVP and Unified CM.

• The NBR feature is supported only on selected IOS image trains. For more information about the supported IOS image trains, see the Compatibility Matrix for your solution.