-
Cisco Unified Contact Center Enterprise 7.5 Solution Reference Network Design (SRND)
-
Preface
-
Architecture Overview
-
Deployment Models
-
Design Considerations for High Availability
-
Unified Contact Center Enterprise Desktop
-
Cisco Unified Outbound Option
-
Cisco Unified Mobile Agent
-
Cisco Unified Expert Advisor Option
-
Securing Unified CCE
-
Sizing Call Center Resources
-
Sizing Unified CCE Components and Servers
-
Sizing Cisco Unified Communications Manager Servers
-
Bandwidth Provisioning and QoS Considerations
-
Cisco Unified Contact Center Management Portal
-
Glossary
-
Index
-
Table Of Contents
Enterprise Unified CCE Peripheral
Unified CCE: Unified CCE System PG
IVR: Treatment and Queuing with Unified IP IVR
IVR: Treatment and Queuing with Unified CVP
Unified CCE: Enterprise Unified CCE PG
IVR: Treatment and Queuing with Unified IP IVR
IVR: Treatment and Queuing with Unified CVP
IPT: Multi-Site with Centralized Call Processing
IPT: Centralized Voice Gateways
IVR: Treatment and Queuing with Unified IP IVR
IVR: Treatment and Queuing with Unified CVP
IPT: Distributed Voice Gateways
Unified CCE: Unified CCE System PG
IPT: Multi-Site with Distributed Call Processing
Unified CCE: Distributed Voice Gateways with Treatment and Queuing Using Unified IP IVR
Unified CCE: Unified CCE System PG
IVR: Distributed Voice Gateways with Treatment and Queuing Using Unified CVP
Unified CCE: Unified CCE System PG
Unified CCE: Distributed Unified ICM Option with Distributed Call Processing Model
Centralized Voice Gateways with Centralized Call Treatment and Queuing Using Unified IP IVR
Clustering Over the WAN with Unified CCE System PG
Centralized Voice Gateways with Centralized Call Treatment and Queuing Using Unified CVP
Considerations for Clustering Over the WAN
Distributed Voice Gateways with Distributed Call Treatment and Queuing Using Unified CVP
Site-to-Site Unified ICM Private Communications Options
Unified ICM Central Controller Private and Unified CM PG Private Across Dual Links
Unified ICM Central Controller Private and Unified CM PG Private Across Single Link
Failure Analysis of Unified CCE Clustering Over the WAN
Private Connection Between Site 1 and Site 2
Connectivity to Central Site from Remote Agent Site
Remote Agent with Unified IP Phones Deployed via the Cisco Virtual Office Solution
Using Unified CM Transfer and IVR Double Trunking
Deployment Models
Last revised on: August 18, 2009
There are numerous ways that Unified CCE can be deployed, but the deployments can generally be categorized into the following major types or models:
•
Single Site
•
•
•
Many variations or combinations of these deployment models are possible. The primary factors that cause variations within these models are as follows:
•
•
•
•
•
•
•
•
•
This chapter discusses the impact of these factors (except for sizing) on the selection of a design. With each deployment model, this chapter also lists considerations and risks that must be evaluated using a cost/benefit analysis. Scenarios that best fit a particular deployment model are also noted.
In this chapter, section titles are prefaced by the type of factor discussed in the section. The factors are classified into the following categories:
•
•
•
A combination of these deployment models is also possible. For example, a multi-site deployment may have some sites that use centralized call processing (probably small sites) and some sites that use distributed call processing (probably larger sites). Examples of scenarios where combinations are likely are identified within each section.
Also in this chapter is a section on integration of traditional ACD and IVR systems into a Unified CCE deployment, with considerations on hybrid PBX/ACD deployments. Sizing and redundancy are discussed in later chapters of this Unified CCE design guide. For more information on the network infrastructure required to support a Unified CCE solution, refer to the latest version of the Cisco Enterprise QoS Solution Reference Network Design Guide, available at
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book.html
For more information on deployment models for Unified CCE and Cisco Unified Communications, refer to the latest version of the Cisco Unified Communications Solution Reference Network Design (SRND) guide, available at
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
What's New in This Chapter
The following topics that are new in this chapter or that have changed significantly from previous releases of this document.
•
Beginning with Unified CCE 7.5, Unified System CCE with Unified CVP is supported as a standalone solution or as a Child to a Parent Unified ICM Enterprise.
•
This feature allows multiple CTI-OSs to be deployed over a single PG that has multiple PIMs and peripherals under it. This feature reduces box count in deployments that have several small ACD or Unified CCE PGs and allows scaling on a machine that has reached the CTI-Manager device limit on Cisco Unified Communications Manager (Unified CM).
•
•
•
•
•
•
Note
General Deployment Options
This section describes options that can apply to many of the specific deployment models listed in the rest of this document. It describes at a high level the trade-offs that can be made when installing the Unified CCE software.
Agent Peripheral Options
Starting with Cisco Unified CCE 7.0, there are two types of peripherals that can be installed to handle Unified CCE agents. This section talks about those two types of peripherals and the strengths and weaknesses of each.
Enterprise Unified CCE Peripheral
This description applies to either the Cisco Unified Communications Manager (Unified CM) PG deployed independently or the Unified CM and VRU peripherals both deployed in a Generic PG. The Cisco Intelligent Contact Management (Unified ICM) software treats the two entities (VRU and Unified CM) as separate peripherals. This treatment means that routing must be done once for each peripheral, and Termination Call Detail records are created for each peripheral each time a call touches the peripheral. Until Unified CCE 7.0, this was the only way of deploying Unified CCE.
When using independent VRU and Unified CM peripherals, you must create Translation Routes to send calls between the VRU and the Unified CM.
The deployment with an Enterprise Unified CCE peripheral and separate VRU peripheral allows a large degree of flexibility in configuration. For example, this deployment is capable of using either a Unified CVP or a Unified IP IVR attached to the VRU peripheral, load balancing between multiple IVRs can be configured and scripted using translation routes, and so forth.
When Unified CCE is configured using the Unified CM peripheral, Unified CCE cannot act as a child to a Unified ICM through a Gateway PG; this option is possible only while using the Unified CCE System peripheral. For more information on parent-child, see the section on Parent/Child.
Unified CCE System Peripheral
The Unified CCE System peripheral combines the functionality of both the VRU peripherals (up to five Unified IP IVR peripherals) and a single Unified CM peripheral together into a single logical Unified ICM peripheral. The Unified CCE treats these Unified IP IVR and Unified CM peripherals as a single peripheral, eliminating the need to translation-route calls to the Unified IP IVR for treatment and queueing. If multiple Unified IP IVRs are configured, the Unified CCE System peripheral automatically load-balances calls between the Unified IP IVRs that have available capacity.
Additionally, because the Unified CCE System PG is a single peripheral, Termination Call Detail (TCD) records and other reporting data include the information for the call during the entire time it is on the peripheral. Instead of getting up to three TCDs for each call (one for the original route, one for the IVR, and one for the agent handle time), only a single record is created with the Unified CCE System PG.
The Unified CCE System PG does not support Unified CVP, therefore all queuing and treatment in the Unified CCE System PG are done using Unified IP IVR. Note that a separate Unified CVP on its own PG can be used in conjunction with the Unified CCE System Peripheral.
Unified System CCE
Beginning with Unified CCE Release 7.0, there are two ways to install Unified CCE:
•
•
Unified System CCE (Unified System CCE) is available for a select subset of Unified CCE deployment models, and it greatly simplifies installation and configuration of the system. It is installed using a streamlined DVD-based install and configured using the Unified CCE Web Administration tools instead of the traditional Unified ICM Configuration Manager on an Administrative Workstation.
For Unified System CCE, there are two significantly different ways to install and deploy it:
•
•
The new Unified CVP deployment model offers the following advantages:
•
•
•
In deployments with Unified CVP, the following additional deployment considerations also apply:
•
•
•
•
Unified System CCE is available in two specific production models and one demo/lab deployment model. All these deployment models are single agent peripheral Unified CCE System PG deployments, meaning that they connect to a single Unified CM cluster and from one to five Unified IP IVRs or from one to ten Unified CVP Call Servers used for queuing.
Because Unified System CCE is installed and configured differently, it does not support the number of options that Unified CCE traditionally supports. Unified System CCE supports the following specific deployments:
•
Server 1: Central Controller: Call Router, Logger
Server 2: Agent/IVR Controller: Unified CCE System PG (including CTI Server and CTI OS). Optionally, if Unified CVP is deployed as the IVR, the VRU Peripheral Gateway for Unified CVP is enabled. At deployment time, the Outbound Controller can be located on the Agent/IVR Controller as well.
Server 3: Administration and WebView Reporting: AW, HDS, Web Administration Server
•
Server 1: Central Controller + Agent/IVR Controller
Server 2: Administration and WebView Reporting
•
Server 1: Central Controller + Agent/IVR Controller + Administration and WebView Reporting
Note that, when the Unified CVP option is chosen, three PGs can be running concurrently on one box. This overcomes the previous limitation of two running PGs per box. Three PGs running concurrently is available only on Unified System CCE and is not available in Unified CCE or other deployments.
The large deployment typically supports over 1,000 concurrent agents, while the medium/small deployment typically supports up to 300 concurrent agents. The specific number of agents that can be supported in each configuration depends upon several sizing factors, such as the desktop being used (CTI OS, CAD, or CRM-integrated), any multi-channel options selected, or the use of Unified Outbound Option (on the Outbound Controller). For specific sizing requirements, refer to the chapter on Sizing Unified CCE Components and Servers, page 10-1.
The installation software for Unified System CCE has been optimized and tested for use with Cisco MCS servers and should be run using only the Cisco MCS servers or equivalent. This requirement also applies to the optional servers discussed below. For more details on the specifications of supported servers, refer to the latest version of the Hardware & System Software Specification (Bill of Materials) for Cisco ICM/IPCC Enterprise & Hosted Editions, available at
Each of the three deployment models can be redundant or have duplexed servers for the Central Controller and/or Agent Controller and can support up to two Administration and WebView Reporting machines. The duplexed servers can also be split over the WAN. Additionally, they support installation of the following options:
•
This option is no longer supported in Unified CCE 7.5.1.
•
This option is installed from the Unified System CCE DVD. It installs a media routing peripheral gateway (MR PG) that is preconfigured with one Unified Outbound Option. When co-located on the Agent/IVR controller, it is possible to duplex this option. If installed on its own server, it cannot be duplexed
•
Unified CCMP software is available on the Unified System CCE DVD. In each of the deployment models mentioned above, Unified CCMP can be installed co-located on the Administration and WebView Reporting machine. Unified CCMP provides a simple to use web-based user interface to streamline the day-to-day provisioning and configuration operations performed by a contact center manager, team lead, or administrator.
Note
•
This Peripheral Gateway is installed from the Unified ICM Setup CD (not the Unified System CCE DVD), and it is used to connect a Unified System CCE System PG to a parent Unified ICM Enterprise system. To the Parent Unified ICM, this makes the Unified System CCE look like any other Peripheral Gateway controlled ACD. This Peripheral Gateway may not be installed on any of the Unified System CCE servers. It can be deployed in a redundant mode using a duplex (A/B) Peripheral Gateway pair. Note that this Peripheral Gateway is configured only on the parent Unified ICM and counts against the maximum number of PGs that are allowed for the supported PG count.
These are the only possible deployments of Unified System CCE. It is installed and configured using a specific set of tools, and those tools cannot handle any other options. For example:
•
•
•
However, if the deployment that is being installed falls within the parameters required by Unified System CCE, there are several benefits:
•
•
•
For a large number of Unified CCE customers, Unified System CCE will meet their requirements and provide benefits of simpler installation and administration. For customers with more complex requirements, traditional Unified CCE is supported with manual installation and administration using Unified ICM Setup and Unified ICM Configuration Manager. For those configurations that Unified System CCE does fit, the reduced deployment time and ease of administration provide significant benefits. Note that migration from Unified System CCE to Unified CCE, or vice versa, is not possible.
Parent/Child
Unified CCE Gateway PG allows Unified CCE or Unified CCX to appear as a traditional ACD connected to the Unified ICM system. Unified CCE Gateway PG does this by providing a PG to the Unified ICM system that communicates to the CTI interface of Unified CCE System PG or Unified CCX.
When Unified CCE Gateway PG is used in a deployment, its relationship of Unified ICM is termed a parent and Unified CCE is called the child:
•
The Unified ICM system that serves as the network or enterprise routing point. The child looks like an ACD to the parent, which uses the appropriate Unified CCE Gateway PG (Enterprise or Express) to communicate to the CTI interface on the child Unified CCE. The parent can perform all functions that a Unified ICM can usually perform, including pre- and post-routing and end-to-end call tracking using translation routes. However, if Unified CVP is used on the child system to queue calls, the parent system will not have visibility of these queued calls and therefore will not be able to compute average wait time or any other statistic based on queuing time.
•
The Unified CCE System PG or Unified CCX system that is set up to function as an ACD. The child can receive calls that are translation-routed from the parent, but it is not aware of any other peripherals attached to the parent. The child can also post-route calls from the Unified CCE to the parent, where the call can be handled like any other Unified ICM call. For example, the call could be translation-routed to any (TDM or IP) ACD controlled by the Unified ICM or queued in the Unified ICM network queue point with Unified CVP.
In the parent/child model, the child Unified CCE is configured to function completely on its own and does not need the connection to the parent to route calls to agents. This independence provides complete local survivability for mission-critical contact centers if the network between the child and parent goes down or if there is a problem with the parent or the Unified CCE Gateway PG connection. Configuration objects entered into the child system can automatically be sent to the parent Unified ICM and inserted into the Unified ICM configuration, thus eliminating the need to configure objects twice, once in the local ACD and again to match the configuration in the Unified ICM itself for routing and reporting. This functionality can also be turned off for situations where the customer does not want automatic configuration updates, such as with an outsourcer using the Unified CCE child system where not all of the agents, skill groups, and call types on that child system apply to the customer's Unified ICM system.
The Unified CCE Gateway PG can connect only to a Unified CCE child that is using the Unified CCE System PG or to Unified CCX 4.0x or later release. If the Unified CCE child has multiple Unified CCE System PGs and peripherals, a separate Unified CCE Gateways PG peripheral must be installed and configured for each one in the Unified ICM parent system. A Unified CCE Gateway PG can manage multiple child Unified CCE peripherals, with up to five child systems.
In the Unified CCE child, either IP IVR or Unified CVP could be deployed for call treatment and queuing. If Unified CVP is deployed, an additional VRU PG must be configured, and this model does not follow the single peripheral model used when IP IVR is deployed. For this reason, information on calls queued at the child (and queue time of call) is not available on the parent, so any computation involving queue time will be inaccurate (for example, minimum expected delay (MED) and average answer wait time).
Special Note on Network Consultative Transfer (NCT) for Parent/Child Systems
One restriction of parent/child is that calls terminating on child systems cannot be transferred via network consultative transfer (NCT) through the NIC or any other routing client on the parent. Although NCT works for TDM ACDs, and at first glance parent/child seems virtually identical in architecture, parent/child is not the same. For a TDM PG, the CTI-Server is connected to the PG ACD, which is part of the parent system. This would be the equivalent of having a CTI-Server connected to the Gateway PG. To think of it another way, it is like using CTI directly to an ACD instead of the CTI Server, in which case network consultative transfer is not possible either. In parent/child deployments, CTI is connected to the child PG. Having CTI connected to the child PG does not provide the necessary network call ID and other information necessary to allow network consultative transfer.
Note, however, that network blind transfer is still possible using any client (for example, Unified CVP or a NIC) on the parent system when a post route is initiated to the parent system from the child.
SIP Support
Unified CCE 7.0 agents can use Unified CM 5.0 SIP phone models 7941, 7961, 7970, and 7971. The 7940 and 7960 phones support SIP with Unified CM 5.0, but they cannot be used for Unified CCE agents. The lower-end Cisco IP phone models and third party phones also cannot be used as SIP phones for Unified CCE agents.
Unified IP IVR is notified of caller entered digits (DTMF input) by way of JTAPI messages from Unified CM. Unified IP IVR and Unified QM do not support mechanisms to detect inband DTMF digits. In deployments with SIP voice gateways or SIP phones that support only in band DTMF (or are configured to use inband DTMF per RFC 2833), Unified CM must invoke an MTP resource to convert the inband DTMF signaling to out-of band signaling so that the Unified IP IVR can be notified of the caller entered digits. Therefore, in environments that include these SIP phones or gateways, it is necessary to provision sufficient MTP resources. Keep this in mind if the phones need to interact with Unified IP IVR. Likewise, CTI ports do not support in-band DTMF (RFC 2833). The Mobile Agent feature relies on CTI ports, so MTP resources are required when in-band DTMF (RFC 2833) is negotiated.
Q.SIG Support
Cisco Unified CCE does not support using Q.SIG trunks with the Unified CM deployment.
Cisco Unified Mobile Agent
For deployments using Cisco Unified Mobile Agent, it is important to consider the location of the voice gateways that will be used to call agents because their location has design considerations for silent monitoring, call admission control, and other areas. For design guidance and considerations for implementing Cisco Unified Mobile Agent, see the chapter on Cisco Unified Mobile Agent, page 6-1.
CTI-OS Multi-Server Support
Cisco Unified CCE 7.5.1 introduces support for multiple instances of CTI OS over a single PG. Prior to Release 7.5, only one instance of CTI OS could exist on a Peripheral Gateway/CTI Gateway configuration regardless of the number of peripherals configured on the Peripheral Gateway. Release 7.5.1 adds support to allow multiple CTI OS servers connecting to a single CTI Server. Up to ten CTI OS servers are allowed per PG.
This deployment provides the following benefits:
•
•
•
•
Because the motivation for this new deployment model is to reduce box count, CTI OS Servers are required to reside on the same server with the rest of the PG processes.
This deployment has the following restrictions:
•
•
•
•
Note
Scaling is reduced when this deployment model is implemented to 75% of the scaling capacity for a single CTI OS. For example, if a given configuration supports 1000 agents with a single CTI OS server, it will support 750 agents using multiple CTI OS servers. This is due to the extra overhead of extra CTI OS processes and to the extra processing load incurred by the CTI Server due to the extra clients. The exception to this is when this feature is used for supporting over 2000 agents (the CTI Manager limit) on Unified CCE. (See Figure 2-1 for an example.) Note that this deployment is supported only when using the Unified CCE PG, and it does not support a VRU under the same PG (no Generic type supported).
Figure 2-1 Multiple CTI OS Servers
Virtualization Support
Beginning with Cisco Unified ICM and Unified Contact Center Enterprise and Hosted Editions Release 7.5(3), servers can be consolidated by deploying a virtualization solution for Client Administrative Workstations (AWs) and certain Peripheral Gateways (PGs) on the VMware platform. For the virtualization requirements, mapping to discrete servers, and CPU processor and RAM requirements for each of the supported PG and Client AW virtual machines (VMs), refer to the latest version of the Hardware & System Software Specification (Bill of Materials) for Cisco ICM/IPCC Enterprise & Hosted Editions, available at
Before you incorporate virtual machines into your contact center design and deployment, you must read through and follow the guidelines and restrictions described in the Virtualization Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted, available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_user_guide_list.html
Other Unified ICM and Unified CCE components, such as the Call Router, Logger, AW Distributor, HDS, WebView server, and CAD server, as well as the Cisco Unified Contact Center Management Portal (Unified CCMP), Cisco Unified Intelligence Suite, Unified Web Interaction Manager (WIM), and Unified E-mail Interaction Manager (EIM), are not supported in a virtualized environment at this time.
IPT: Single Site
A single-site deployment refers to any scenario where all voice gateways, agents, desktops, phones, and call processing servers (Unified CM, Unified ICM/Unified CCE, and Unified IP IVR or Cisco Unified Customer Voice Portal (Unified CVP)) are located at the same site and have no WAN connectivity between any Unified CCE software modules. Figure 2-2 illustrates this type of deployment using the Unified System CCE model.
Figure 2-2 Single-Site Deployment
Figure 2-2 shows a Unified IP IVR, a Unified CM cluster, redundant Unified System CCE servers, an Administration and WebView Reporting machine and Historical Data Server (HDS), and a direct connection to the PSTN from the voice gateways. The Unified System CCE server in this scenario is running the following major software processes:
•
•
•
•
•
•
Optionally the Central Controller and Agent/IVR Controller (Unified CCE System PG and so forth) can be split onto separate servers. For information on when to install the Unified ICM Central Controller and PG on separate servers, refer to the chapter on Sizing Unified CCE Components and Servers, page 10-1.
This system can be installed using the traditional Unified CCE model (not Unified System CCE), which would allow for several different options. For example, two Unified CCE System PGs could be installed along with a single Unified CVP.
Unified System CCE or traditional Unified CCE must be deployed in a redundant fashion. Simplex deployments are supported only for lab or non-production deployments. For information on Unified CCE redundancy, see to the chapter on Design Considerations for High Availability, page 3-1.
The number of Unified CM nodes and the hardware model used is not specified along with the number of Unified IP IVRs. For information on determining the number and type of servers required, refer to the chapter on Sizing Unified CCE Components and Servers, page 10-1.
Also not specified in this model is the specific data switching infrastructure required for the LAN, the type of voice gateways, or the number of voice gateways and trunks. Cisco campus design guides and Cisco Unified Communications design guides are available to assist in the design of these components. The chapter on Sizing Call Center Resources, page 9-1, discusses how to determine the number of gateway ports.
Another variation in this model is to have the voice gateways connected to the line side of a PBX instead of the PSTN. Connection to multiple PSTNs and a PBX all from the same single-site deployment is also possible. For example, a deployment can have trunks from a local PSTN, a toll-free PSTN, and a traditional PBX/ACD. For more information, see Traditional ACD Integration, and Traditional IVR Integration.
This deployment model also does not specify the type of signaling (ISDN, MF, R1, and so on) to be used between the PSTN and voice gateway or the specific signaling (H.323 or MGCP) to be used between the voice gateway and Unified CM.
The amount of digital signal processor (DSP) resources required for placing calls on hold, consultative transfers, and conferencing is also not specified in this model. For information on sizing of these resources, refer to the latest version of the Cisco Unified Communications Solution Reference Network Design (SRND) guide, available at
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
The main advantage of the single-site deployment model is that there is no WAN connectivity required. Given that there is no WAN in this deployment model, there is generally no need to use G.729 or any other compressed Real-Time Transport Protocol (RTP) stream, so transcoding would not be required.
Unified CCE: Unified CCE System PG
In this deployment model, the agent PG that is deployed is a Unified CCE System PG. Only a single peripheral is needed to handle both the Unified CM and any Unified IP IVRs that may exist. This peripheral unifies the appearances of the multiple PIMs and also handles load balancing calls between multiple Unified IP IVRs. Alternatively, this model may be configured to use Unified CVP. When Unified CVP is used, its connectivity to Cisco Unified Presence handles load balancing by distributing the incoming calls among Unified CVP Call Servers. In this deployment, the VRU PIMs (up to 10) communicating with the Unified CVP Call Server(s) reside on their own PG and not under the Unified CCE System PG. Figure 2-3 shows a single-site deployment utilizing Unified CVP instead of IP-IVR in a Unified System CCE system. In this model, no longer do all calls reside under a single peripheral; Unified CVP is its own peripheral(s).
Figure 2-3 Single-Site Deployment Using Unified CVP
When using this configuration, the VRU PGs must be deployed redundantly with one to ten Unified CVP Call Servers, depending upon the number of agents and call volume required. From a practical point of view, this deployment is similar to a single-PG Unified CCE system with the major exception of greatly simplified setup and configuration.
IVR: Treatment and Queuing with Unified IP IVR
In this deployment model, all initial and subsequent queuing is done on the Unified IP IVR. Up to five Unified IP IVRs can be deployed in this model (with the Unified CCE System PG). The Unified IP IVRs are placed behind the Unified CM, using Unified CM's dial plan and call switching under control of Unified CCE. All calls come into a CTI Route Point on Unified CM, controlled by Unified CCE, and are then automatically translation-routed to the Unified IP IVR by the Unified CCE System PG. The Unified CCE handles load balancing between available Unified IP IVR ports, and configuring translation routes between the Unified IP IVR and Unified CM is not needed.
In most cases, deployments using this model can also be handled by Unified System CCE.
IVR: Treatment and Queuing with Unified CVP
Although not usually deployed in a single-site model, the Unified CVP could be used to provide the call treatment and queuing in this model as well. Unified System CCE supports one VRU PG for Unified CVP with up to 10 Unified CVP peripherals. If more than one Unified CVP PG is desired, traditional Unified CCE and not Unified System CCE should be deployed, and the web configuration tools would not be available so all configuration would have to be done using the ConfigManager application on the Unified ICM Admin Workstation. Because Unified CVP is not part of the Unified CCE System PG peripheral, translation routes must be configured to transfer calls with call data between the peripherals.
In this deployment model, all initial and subsequent queuing is done using Unified CVP. A single server may be used, with all Unified CVP processes co-located on that server. Multiple servers, on the other hand, allow scaling and redundancy. For more information about redundancy, see the chapter on Design Considerations for High Availability, page 3-1.
For more information about Unified CVP, refer to the Cisco Unified Customer Voice Portal Solution Reference Network Design (SRND), available at
Unified CCE: Enterprise Unified CCE PG
In these deployment models the Enterprise Unified CCE peripheral is used to handle interactions with the Unified CM, and a separately configured VRU peripheral is used to handle interactions with the Unified IP IVR or Unified CVP. Unified System CCE does not support the use of the Enterprise Unified CCE PG; therefore, the system would have to be installed using the traditional Unified CCE Setup CD. This means that the web configuration tools are not available in these scenarios.
IVR: Treatment and Queuing with Unified IP IVR
In this deployment model, all initial and subsequent queuing is done on the Unified IP IVR. If multiple Unified IP IVRs are deployed, the Unified ICM should be used to load-balance calls across those Unified IP IVRs. Translation routes must be configured manually between the Unified CM peripheral and the Unified IP IVR peripheral(s) and used to move calls and data between Unified CM and the Unified IP IVRs. Load balancing is done manually in the Translation Route To VRU node in the Unified CCE call routing script.
IVR: Treatment and Queuing with Unified CVP
Although not usually deployed in a single-site model, Unified CVP could be used to provide the call treatment and queuing in this model as well. Unified CVP would have its own VRU PG, either loaded on the same server as the Unified CM PG or part of a Generic PG combination.
In this deployment model, all initial and subsequent queuing is done using Unified CVP. A single server may be used, with all Unified CVP processes co-located on that server. Multiple servers, on the other hand, allow scaling and redundancy. For more information about redundancy, see the chapter on Design Considerations for High Availability, page 3-1.
For more information about Unified CVP, refer to the Cisco Unified Customer Voice Portal Solution Reference Network Design (SRND), available at
Unified CCE: Transfers
In this deployment model (as well as in the multi-site centralized call processing model), both the transferring agent and target agent are on the same peripheral. This also implies that both the routing client and the peripheral target are the same peripheral. The transferring agent generates a transfer to a particular dialed number configured as a CTI Route Point in Unified CM (for example, looking for any specialist in the specialist skill group).
The Agent peripheral (either the Unified CCE System peripheral or the Enterprise Unified CCE peripheral) will generate a route request to the Unified ICM router. The Unified ICM router will match the dialed number to a call type and activate the appropriate routing script. The routing script looks for an available specialist.
If a target agent (specialist) is available to receive the transferred call, then the Unified ICM router will return the appropriate label to the requesting routing client (the Agent peripheral). In this scenario, the label is typically just the extension of the phone where the target agent is currently logged in. Upon receiving the route response (label), the Unified CM PIM will then initiate the transfer by sending a JTAPI transfer request to the Unified CM.
At the same time that the label is returned to the routing client, pre-call data (which includes any call data that has been collected for this call) is delivered to the peripheral target. In this scenario, the routing client and peripheral target are the same Agent peripheral. This is because the transferring agent and the target agent are both associated with the same peripheral. In some of the more complex scenarios to be discussed in later sections, sometimes the routing client and peripheral target are not the same.
If a target agent is not available to receive the transferred call, then the Unified ICM routing script is typically configured to transfer the call to an IVR so that queue treatment can be provided. In this scenario the logic in the Unified CCE System PG differs from the logic in the Unified CCE PG if the IP-IVR variant is used.
In both cases the label is a dialed number that will instruct the Unified CM to transfer the call to an IVR. The translation-route or correlationID is not needed when using the Unified CCE System peripheral but is needed when deploying Unified CVP.
IPT: Multi-Site with Centralized Call Processing
A multi-site deployment with centralized call processing refers to any scenario where call processing servers (Unified CM, Unified ICM, and Unified IP IVR or Unified CVP) are located at the same site, while any combination of voice gateways, agents, desktops, and phones are located remotely across a WAN link or centrally. Figure 2-4 illustrates this type of deployment.
There are two variations of this IPT model:
•
•
IPT: Centralized Voice Gateways
If an enterprise has small remote sites or offices in a metropolitan area where it is not efficient to place call processing servers or voice gateways, then this model is most appropriate. As sites become larger or more geographically dispersed, use of distributed voice gateways might be a better option.
Figure 2-4 illustrates this model using a Unified System CCE deployment. The illustration shows the deployment using IP-IVR, but it could also use Unified CVP instead of IP-IVR.
Figure 2-4 Multi-Site Deployment with Centralized Call Processing and Centralized Voice Gateways
Advantages
•
•
•
•
•
As with the single-site deployment model, all the same options exist when using traditional Unified CCE configurations. For example, multi-site deployments can run the Unified ICM software all on the same server or on multiple servers. The Unified ICM software can be installed as redundant or simplex. (Simplex mode is not supported for production environments.) The Unified ICM software can be deployed either with the Unified CCE System PG or the Unified CCE PG. The system can be a Unified System CCE deployment. The number of Unified CM and Unified IP IVR or Unified CVP servers is not specified by the deployment model, nor are the LAN/WAN infrastructure, voice gateways, or PSTN connectivity. For other variations, see IPT: Single Site.
Best Practices
•
•
•
•
•
•
•
IVR: Treatment and Queuing with Unified IP IVR
As in the single-site deployment, all call queuing is done on the Unified IP IVR at a single central site. While calls are queuing, no RTP traffic flows over the WAN. If requeuing is required during a transfer or reroute on ring-no-answer, the RTP traffic flow during the queue treatment also does not flow over the WAN. This reduces the amount of WAN bandwidth required to the remote sites.
IVR: Treatment and Queuing with Unified CVP
In this model, Unified CVP is used in the same way as Unified IP IVR.
Unified CCE: Transfers
Transfers in this scenario are, from the point of view of the contact center, the same as in the single-site scenario. Therefore, the same call and message flows will occur as in the single-site model, whether the transferring agent is on the same LAN as the target or on a different LAN. The only differences are that QoS must be enabled and that appropriate LAN/WAN routing must be established. For details on provisioning your WAN with QoS, refer to the latest version of the Cisco Enterprise QoS Solution Reference Network Design Guide, available at
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book.html
During consultative transfers where the agent (not the caller) is routed to a Unified IP IVR port for queuing treatment, transcoding is required because the Unified IP IVR can generate only G.711 media streams.
IPT: Distributed Voice Gateways
A variation of the centralized call processing model can include multiple ingress voice gateway locations. This distributed voice gateway model might be appropriate for a company with many small sites, each requiring local PSTN trunks for incoming calls. This model provides local PSTN connectivity for local calling and access to local emergency services. Figure 2-5 illustrates this model.
Figure 2-5 Multi-Site Deployment with Centralized Call Processing and Distributed Voice Gateways
In this deployment model, shown with Unified IP IVR for queuing and treatment, it might be desirable to restrict calls arriving at a site to be handled by an agent within that site, but this is not required. By restricting calls to the site where it arrived, the following conditions apply:
•
•
•
•
•
In order to restrict a call to the site at which it arrived in this deployment model, it is necessary to create separate skill groups for agents at each location. In order to route a call to any agent in a given skill regardless of location, the location-specific skill groups can be combined using an enterprise skill group.
It is important for deployment teams to carefully assess the trade-offs between operational costs and customer satisfaction levels to establish the right balance on a customer-by-customer basis. For example, it may be desirable to route a specific high-profile customer to an agent at another site to reduce their queue time and allow the call to be handled by a more experienced representative, while another customer may be restricted to an agent within the site where the call arrived.
A Unified CCE deployment may actually use a combination of centralized and distributed voice gateways. The centralized voice gateways can be connected to one PSTN carrier providing toll-free services, while the distributed voice gateways can be connected to another PSTN carrier providing local phone services.
Inbound calls from the local PSTN could be both direct inward dial (DID) and contact center calls. It is important to understand the requirements for all inbound and outbound calling to determine the most efficient location for voice gateways. Identify who is calling, why they are calling, where they are calling from, and how they are calling.
In the traditional Unified CCE model, with multi-site deployments and distributed voice gateways, the Unified ICM pre-routing capability can also be used to load-balance calls dynamically across the multiple sites. For a list of PSTN carriers that offer Unified ICM pre-routing services, refer to the Pre-installation Planning Guide for Cisco ICM Enterprise & Hosted Editions, available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1001/prod_installation_guides_list.html
In multi-site environments where the voice gateways have both local PSTN trunks and separate toll-free trunks delivering contact center calls, the Unified ICM pre-routing software can load-balance the toll-free contact center calls around the local contact center calls. For example, suppose you have a two-site deployment where Site 1 currently has all agents busy and many calls in queue from locally originated calls, and Site 2 has only a few calls in queue or maybe even a few agents currently available. In that scenario, you could have the Unified ICM instruct the toll-free provider to route most or all of the toll-free calls to Site 2. This type of multi-site load balancing provided by the Unified ICM is dynamic and automatically adjusts as call volumes change at all sites. Note that Unified ICM pre-routing is not supported in the Unified System CCE deployment models; it is an option only for traditional Unified CCE or the parent/child models where the Unified ICM parent would have the pre-routing interface to the PSTN.
Just as in the two previous deployment models, much variation exists in the number and types of Unified ICM, Unified CM, and Unified IP IVR or Unified CVP servers; LAN/WAN infrastructure; voice gateways; PSTN connectivity; and so forth.
In multi-site environments with distributed voice gateways, Unified CVP can be used to leverage the ingress voice gateways at the remote sites as part of the traditional Unified CCE system to provide call treatment and queueing at the remote location, using the VoiceXML Browser built into the Cisco IOS voice gateway locally. Using the distributed gateways with Unified CVP permits calls to queue locally in the ingress voice gateway and rather than requiring the call to cross the VoIP WAN to a centralized queue platform. Only call signaling (H.323 and VoiceXML) pass over the WAN to instruct the remote site voice gateway how to treat, queue, and transfer the call to an agent. In these models, pre-routing to the site might not be necessary because Unified ICM takes control of the call as soon as it arrives at the site. Basic carrier percent allocation can be used to allocate calls to the sites and failover (rollover) trunks used to address local failures as needed.
Advantages
•
•
•
•
Best Practices
•
–
–
–
–
–
•
•
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
Unified CCE: Unified CCE System PG
Because the deployment of contact center components is essentially the same as in other multi-site centralized call processing deployments, the same benefits and restrictions apply to Unified CCE deployed using the Unified CCE System PG.
Additionally, if Unified ICM pre-routing is used to interact with carriers and distribute calls to the voice gateways, translation routes for the NIC routing client to the Unified CCE System PG must be configured manually using the ConfigManager application on the Unified ICM Admin Workstation. Pre-routing is not supported as part of the Unified System CCE deployment.
Unified CCE & IVR: Treatment and Queuing with Unified IP IVR
WAN bandwidth must be provisioned to support all calls that will be treated and queued at the central site.
Centralized Unified IP IVRs provide efficiency of Unified IP IVR ports when compared with smaller deployments of Unified IP IVRs at each remote site.
IVR: Treatment and Queuing with Unified CVP
Unified CVP is not supported with a Unified CCE System PG. A separate VRU peripheral must be configured and deployed. This means that translation routes must be configured to transfer calls with call data between the peripherals. However, Unified CVP does provide benefits of queuing and treatment for callers at the remote distributed ingress voice gateways in this model because the calls do not have to cross the VoIP WAN for treatment in the centralized Unified IP IVR.
Using Unified CVP for treatment and queuing allows you to reduce the amount of voice bearer traffic traveling across the WAN. Unified CVP queues and treats calls on the remote gateways, thus eliminating the need to terminate the voice bearer traffic at the central site. WAN bandwidth must still be provisioned for transfers and conferences that involve agents at other locations.
Unified CCE: Unified CCE PG
Because the deployment of contact center components is essentially the same as in other multi-site centralized call processing deployments, the same benefits and restrictions apply to Unified CCE deployed using the Unified CCE PG.
Additionally, if Unified ICM pre-routing is used to interact with carriers and distribute calls to the voice gateways, translation routes must be configured for the NIC routing client using traditional Unified CCE with separate Unified CVP and Unified CM peripherals in the Unified ICM.
IVR: Treatment and Queuing with Unified IP IVR
WAN bandwidth must be provisioned to support all calls that will be treated and queued at the central site.
Centralized Unified IP IVRs provide efficiency of Unified IP IVR ports when compared with smaller deployments of Unified IP IVRs at each remote site.
IVR: Treatment and Queuing with Unified CVP
Using Unified CVP for treatment and queuing allows you to reduce the amount of voice bearer traffic traveling across the WAN. Unified CVP queues and treats calls on the remote gateways, thus eliminating the need to terminate the voice bearer traffic at the central site. WAN bandwidth must still be provisioned for transfers and conferences that involve agents at other locations.
Unified CCE: Transfers
Intra-site or inter-site transfers using the VoIP WAN to send the RTP stream from one site to another occur basically the same way as a single-site transfer or a transfer in a deployment with centralized voice gateways.
An alternative to using the VoIP WAN for routing calls between sites is to use a carrier-based PSTN transfer service. These services allow the Unified CCE voice gateways to outpulse DTMF tones to instruct the PSTN to reroute (transfer) the call to another voice gateway location. Each site can be configured within the Unified ICM as a separate Agent Peripheral. The label then indicates whether a transfer is intra-site or inter-site, using Take Back and Transfer (*8) or Transfer Connect. These transfer tones are played in-band over the voice path and must be played from a recorded file in Unified IP IVR or outpulsed as digits from Unified CVP.
IPT: Multi-Site with Distributed Call Processing
Enterprises with multiple medium to large sites separated by large distances tend to prefer a distributed call processing model. In this model, each site has its own Unified CM cluster, treatment and queue points, PGs, and CTI Server. However, as with the centralized call processing model, sites could be deployed with or without local voice gateways. Some deployments may also contain a combination of distributed voice gateways (possibly for locally dialed calls) and centralized voice gateways (possibly for toll-free calls) as well as centralized or distributed treatment and queue points.
The Unified System CCE deployment models are not appropriate in this case because they are limited to a single Unified CM cluster. Alternatively, the Unified ICM Enterprise (parent) and Unified CCE (child) model would be appropriate to provide local, distributed call processing with a local Unified CM and Unified CCE at each site, controlled under a centralized Unified ICM Enterprise parent for enterprise-wide routing, reporting, and call control.
Regardless of how many sites are being deployed in this model, there will still be only one logical Unified ICM Central Controller. If the Unified ICM Central Controller is deployed with redundancy, sides A and B can be deployed side-by-side or geographically separated (remote redundancy). For details on remote redundancy, refer to the Unified ICM product documentation available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1001/tsd_products_support_series_home.html
Unified CCE: Distributed Voice Gateways with Treatment and Queuing Using Unified IP IVR
This deployment model is a good choice if the company has multiple medium to large sites. In this model, voice gateways with PSTN trunks terminate into each site. Just as in the centralized call processing model with distributed voice gateways, it might be desirable to limit the routing of calls to agents within the site where the call arrived (to reduce WAN bandwidth). An analysis of benefits from customer service levels versus WAN costs is required to determine whether limiting calls within a site is recommended. Figure 2-6 illustrates this model using a traditional Unified CCE deployment with the Unified CCE System PG.
Figure 2-6 Multi-Site Deployment with Distributed Call Processing and Distributed Voice Gateways with Unified IP IVR
As with the previous models, many options are possible. The number and type of Unified ICM Servers, Unified CM servers, and Unified IP IVR servers can vary. LAN/WAN infrastructure, voice gateways, PSTN trunks, redundancy, and so forth are also variable within this deployment model. Central processing and gateways may be added for self-service, toll-free calls and support for smaller sites. In addition, the use of a pre-routing PSTN Network Interface Controller (NIC) is also an option.
Advantages
•
•
•
•
•
•
•
•
Best Practices
•
•
•
•
•
•
Treatment and Queuing
Initial call queuing is done on a Unified IP IVR co-located with the voice gateways, so no transcoding is required. When a call is transferred and subsequent queuing is required, the queuing should be done on a Unified IP IVR at the site where the call is currently being processed. For example, if a call comes into Site 1 and gets routed to an agent at Site 2, but that agent needs to transfer the call to another agent whose location is unknown, the call should be queued to a Unified IP IVR at Site 2 to avoid generating another intercluster call. A second intercluster call would be made only if an agent at Site 1 was selected for the transfer. The RTP flow at this point would be directly from the voice gateway at Site 1 to the agent's phone at Site 1. However, the two Unified CM clusters would still logically see two calls in progress between the two clusters.
Transfers
Transfers within a site function just like a single-site transfer. Transfers between Unified CM clusters use either the VoIP WAN or a PSTN service.
If the VoIP WAN is used, sufficient intercluster trunks must be configured. An alternative to using the VoIP WAN for routing calls between sites is to use a PSTN transfer service. These services allow the Unified CCE voice gateways to outpulse DTMF tones to instruct the PSTN to reroute (transfer) the call to another voice gateway location. Another alternative is to have the Unified CM cluster at Site 1 make an outbound call back to the PSTN. The PSTN would then route the call to Site 2, but the call would use two voice gateway ports at Site 1 for the remainder of the call.
Unified CCE: Unified CCE System PG
This model, as designed with multiple remote locations, is not supported under the Unified System CCE deployment model. However, in Unified CCE 7.0, the Unified CCE System PG was introduced as a single peripheral that joins the Unified CM and Unified IP IVR peripherals of former versions to simplify installation, configuration, and routing. In this model, the PGs at the remote sites can be installed as Unified CCE System PGs to combine the Unified IP IVR and Unified CM peripherals under a single logical PG instance and peripheral.
This model does not, however, allow the use of the Web Configuration tools. The core of the system would still be the traditional Unified CCE model that requires manual configuration using the ConfigManager application on the Unified ICM Admin Workstation. This is a unique design wherein the two deployment models can share a common component (the Unified CCE System PG) while not actually using the Unified System CCE deployment model itself. This model is perhaps more typical of outsourcers that would set up a call center specifically for a single client and deploy it as a Unified CCE System PG to allow their client company to connect their Unified ICM Enterprise system to the outsourcer Unified CCE System PG with the Unified CCE Gateway PG, as they would any outsourced ACD.
Unified CCE: Unified CCE PG
This model, as designed with multiple remote locations, is more suited for the traditional Unified CCE design with multiple distributed peripheral gateways. The system could be deployed with the Generic PG or both Unified CM and Unified IP IVR PGs at the sites; however, the new Unified CCE System PG that combines both of these peripherals into a single peripheral for routing and reporting under the traditional model might be easier for new deployments of this solution. Existing customers upgrading to Unified CCE 7.0 may stay on their existing Generic PG or multi-PG model.
Alternative: Parent/Child
An alternative to this deployment model is the parent/child deployment model with a child Unified CCE at each of the distributed sites. This model has the advantage of being more tolerant of WAN outages, and each site is completely survivable. Figure 2-7 shows this same model deployed using the parent/child model.
Figure 2-7 Multi-Site Deployment with Distributed Call Processing and Parent/Child
In this design, there is a parent Unified ICM Enterprise system deployed with the Unified CVP and its own Admin Workstation/HDS server. At each distributed site, there is a complete Unified System CCE deployment using the small/medium model that loads both Central Controller and Agent/IVR Controller on the system server. There is also a local Administration and WebView Reporting machine for the Unified System CCE to perform configuration, scripting, and reporting tasks for that specific site. There is a Unified CCE Gateway PG that connects the Unified System CCE to the Unified ICM parent, and it is part of the Peripheral Gateways deployed on the parent Unified ICM.
In this design, the local Unified System CCE deployments act as their own local IP ACDs with no visibility to any of the other sites in the system. Users at Site 1 cannot see any of the calls or reports from Site 2 in this model. Only the Unified ICM Enterprise parent system has visibility to all activity at all sites connected to the Unified ICM Enterprise system.
The Unified CVP at the Unified ICM parent site is used to control the calls coming into the distributed sites, providing local call queueing and treatment in the VoiceXML Browser in the voice gateway. The local Unified IP IVR servers are used only for a local backup if the connection from these voice gateways is lost to the parent Unified CVP Call Control server. The local Unified IP IVR also provides local queue treatment for calls that are not answered by the local agents (RONA), rather than sending the call back to the Unified CVP to be re-queued.
The child Unified System CCE deployments can also transfer calls across the system between the sites using Unified ICM post-routing by the Unified CCE Gateway PG. The Unified CCE Gateway PG allows the child Unified System CCE to ask the Unified ICM to transfer a call to the best agent at another site or to queue it centrally for the next available agent.
Unlike traditional Unified CCE models with distributed Unified CM Peripheral Gateways, the parent/child model provides for complete local redundancy at the contact center site. The local Unified System CCE will take over call processing for inbound calls from the Unified CVP gateways and provide local call queueing and treatment in the local Unified IP IVR. This is an excellent design for call center sites that require complete redundancy or 100% up-time and that cannot be down because of a WAN failure.
This design is a good approach for customers who have Unified ICM already installed with their TDM ACD platforms and who want either to add new sites with Unified CCE or to convert an existing site to Unified CCE. It allows the Unified ICM to continue performing enterprise-wide routing and reporting across all of the sites while inserting new Unified CCE technology on a site-by-site basis.
Note also that Unified CVP could be both at the parent and child given that Unified System CCE now allows Unified CVP in its deployment. This is virtually identical to Unified CVP at the parent and IP-IVR at the child from a call flow perspective. One key difference, though, is that information on queued calls at the child Unified CVP will not be available at the parent (through the Gateway PG), as is the case if IP-IVR is used. This means that minimum expected delay (MED) over services cannot be used.
Advantages
•
•
•
•
•
•
•
•
•
Disadvantages
•
Best Practices
•
•
•
•
•
•
IVR: Distributed Voice Gateways with Treatment and Queuing Using Unified CVP
This deployment model is the same as the previous model, except that Unified CVP is used instead of Unified IP IVR for call treatment and queuing. In this model, voice gateways with PSTN trunks terminate into each site. Just as in the centralized call processing model with distributed voice gateways, it might be desirable to limit the routing of calls to agents within the site where the call arrived (to reduce WAN bandwidth). Call treatment and queuing can also be achieved at the site where the call arrived, further reducing the WAN bandwidth needs. Figure 2-8 illustrates this model using traditional Unified CCE deployment.
Figure 2-8 Multi-Site Deployment with Distributed Call Processing and Distributed Voice Gateways with Unified CVP
As with the previous models, many options are possible. The number and type of Unified ICM Servers, Unified CM servers, and Unified CVP servers can vary. LAN/WAN infrastructure, voice gateways, PSTN trunks, redundancy, and so forth, are also variable within this deployment model. Central processing and gateways may be added for self-service, toll-free calls and support for smaller sites. In addition, the use of a pre-routing PSTN Network Interface Controller (NIC) is also an option.
Advantages
•
•
•
•
•
•
•
•
•
Best Practices
•
•
•
•
IVR: Treatment and Queuing
Unified CVP queues and treats calls on the remote gateways, eliminating the need to terminate the voice bearer traffic at the central site. Unified CVP servers may be located at the central site or distributed to remote sites. WAN bandwidth must still be provisioned for transfers and conferences that involve agents at other locations.
Unlike Unified IP IVR, with Unified CVP the call legs are torn down and reconnected, avoiding signaling hairpins. With Unified IP IVR, two separate call signaling control paths will remain intact between the two clusters (producing logical hairpinning and reducing the number of intercluster trunks by two).
Transfers
Transfers within a site function just like a single-site transfer. Transfers between Unified CM clusters use either the VoIP WAN or a PSTN service.
If the VoIP WAN is used, sufficient intercluster trunks must be configured. An alternative to using the VoIP WAN for routing calls between sites is to use a PSTN transfer service. These services allow the Unified CCE voice gateways to outpulse DTMF tones to instruct the PSTN to reroute (transfer) the call to another voice gateway location. Another alternative is to have the Unified CM cluster at Site 1 make an outbound call back to the PSTN. The PSTN would then route the call to Site 2, but the call would use two voice gateway ports at Site 1 for the remainder of the call.
Unified CCE: Unified CCE System PG
The Unified CCE System PG is not a good fit for this model because it does not support Unified CVP for queuing, and the IVR PIMs on the Unified CCE System PG would go unused.
Unified CCE: Unified CCE PG
The Unified CCE PG is the recommended PG for this deployment model.
Unified CCE: Distributed Unified ICM Option with Distributed Call Processing Model
Figure 2-9 illustrates this deployment model.
Figure 2-9 Distributed Unified ICM Option Shown with Unified IP IVR
Advantages
The primary advantage of the distributed Unified ICM option is the redundancy gained from splitting the Unified ICM Central Controller between two redundant sites.
Best Practices
•
•
•
•
•
IPT: Clustering Over the WAN
As part of the centralization of call processing, many customers prefer to combine the redundancy of the distributed Unified CM call processing model with the simplicity of having a single Unified CM cluster for a single dial plan and voice system to administer. This combination of models provides for a single Unified CM cluster with its subscriber servers split across data center locations to provide a single cluster with multiple distributed call processing servers for a highly available and redundant design, known as clustering over the WAN.
Unified CM clustering over the WAN may also be used with Unified CCE for contact centers to allow full agent redundancy in the case of a data center (central site) outage. Implementation of clustering over the WAN for Unified CCE does have several strict requirements that differ from other models. Bandwidth between central sites for Unified ICM public and private traffic, Unified CM intra-cluster communication signaling (ICCS), and all other voice-related media and signaling must be properly provisioned with QoS enabled. The WAN between central sites must be highly available (HA) with redundant links and redundant routers.
Advantages
•
•
•
•
Best Practices
•
Figure 2-10 Highly Available WAN Network for the Unified ICM Public Traffic
Figure 2-11 Separate WAN link for Unified ICM Private Traffic
•
–
–
–
Figure 2-12 Network Architecture Under Normal Operations
•
The links must also be sized correctly in order to accommodate this failover situation where the private link carries the entire WAN traffic, including the public and ICCS traffic. QoS and bandwidth must be configured according to the guidelines in the chapter on Bandwidth Provisioning and QoS Considerations, page 12-1.
Figure 2-13 Network Architecture After Failure of the Unified ICM Public Network
•
•
•
Figure 2-14 Network Architecture Based on a SONET Ring Under Normal Operations
•
•
•
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
•
•
–
–
–
–
•
•
•
•
•
•
•
Centralized Voice Gateways with Centralized Call Treatment and Queuing Using Unified IP IVR
In this model, the voice gateways are located in the central sites. Unified IP IVR is centrally located and used for treatment and queuing on each side. Figure 2-15 illustrates this model.
Figure 2-15 Centralized Voice Gateways with Centralized Call Treatment and Queuing Using Unified IP IVR
Advantages
•
•
Best Practices
•
•
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
•
•
Clustering Over the WAN with Unified CCE System PG
Clustering over the WAN with Unified CCE System PG is now supported. However, due to the fact that a single Unified CCE System peripheral is controlling all of the Unified IP IVRs and the Unified CM, the load-balancing of calls between Unified IP IVRs does not take into account which site the call came into; it simply distributes the calls to whichever Unified IP IVR is least loaded. This means that calls coming into Site A might be treated by a Unified IP IVR in Site B. Additionally, both the A-side and B-side Unified CCE System PG know about all of the Unified IP IVRs. PIM activation logic will determine if the A-side or the B-side PIM will connect to each of the Unified IP IVRs. This means that the PG at site A might connect to the Unified IP IVR at site B. This means traffic that might not be sent optimally over the WAN. In this model, care should be taken to make sure the WAN is sized for proper operation given this fact.
Centralized Voice Gateways with Centralized Call Treatment and Queuing Using Unified CVP
In this model, the voice gateways are VoiceXML gateways located in the central sites. Unified CVP is centrally located and used for treatment and queuing. Figure 2-16 illustrates this model.
Figure 2-16 Centralized Voice Gateways with Centralized Call Treatment and Queuing Using Unified CVP
Advantages
•
•
•
Best Practices
•
•
Centralized Voice Gateways with Centralized Call Treatment and Queuing Using Unified System CCE with Unified CVP
Load balancing of calls across Unified CVP Call Servers is managed by SIP and Cisco Unified Presence Proxy Services. The load balancing does not take into account the site where the call came in, but calls are distributed based on simple load balancing rules define in Cisco Unified Presence (for example, alternate call distributions across configured Unified CVP Call Servers and preferential weighting of Call Servers).
Currently, if the system is designed to do so, Unified CVP can queue the call at the ingress gateway. This requires that Unified CVP be configured with settransferlabel for H.323 or Send To Originator for SIP, to match the NetworkVRU label. This will cause Unified CVP to send the call back to the ingress gateway for queuing when a label matching this NetworkVRU label is returned from Unified ICM. Currently Unified ICM is unaware of the location of the initial gateway, therefore it cannot make a label selection based on the original ingress location of the call.
Considerations for Clustering Over the WAN
Figure 2-17 illustrates a deployment with clustering over the WAN.
Figure 2-17 Clustering Over the WAN
The following guidelines and considerations apply to deployments with clustering over the WAN:
•
•
•
•
•
•
•
•
The underlying network infrastructure for LAN and WAN provisioned should meet all the above requirements. Key factors are isolation of visible and private paths as well as critical low-latency and bandwidth, especially on the private path. The isolated private networks for PGs and Central Controllers provide some degree of independence from each other's private link failures. The more path/route diversity provisioned, the greater the fault tolerance. For example, if the private network between the parent central controllers goes down, the child central controllers can still continue to function in duplex mode.
MPLS Considerations
If an MPLS network can guarantee the route diversity, latency, and bandwidth, and if it is configured to support label switch paths that route via independent topologies and hardware elements to meet the above requirements, then the application will work as designed. It is important to ensure that the route autonomy is not compromised over time through adaptive change.
For additional information regarding best practices and high availability deployments, refer to the section on IPT: Clustering Over the WAN.
Distributed Voice Gateways with Distributed Call Treatment and Queuing Using Unified CVP
In this model, the voice gateways are VoiceXML gateways distributed to agent locations. Unified CVP is centrally located and used for treatment and queuing on the remote gateways. Figure 2-18 illustrates this model.
Figure 2-18 Distributed Voice Gateways with Distributed Call Treatment and Queuing Using Unified CVP
Advantages
•
•
•
•
Best Practices
•
•
Site-to-Site Unified ICM Private Communications Options
Unified ICM private communications must travel on a separate path from the public communications between Unified ICM components. There are two options for achieving this path separation: dual and single links.
Unified ICM Central Controller Private and Unified CM PG Private Across Dual Links
Dual links, shown in Figure 2-19, separate Unified ICM Central Controller Private traffic from VRU/CM PG Private traffic.
Figure 2-19 Unified ICM Central Controller Private and Unified CM PG Private Across Dual Links
Advantages
•
•
•
•
Best Practices
•
•
•
Unified ICM Central Controller Private and Unified CM PG Private Across Single Link
A single link, shown in Figure 2-20, carries both Unified ICM Central Controller Private traffic and VRU/CM PG Private traffic. Single-link implementations are more common and less costly than dual-link implementations.
Figure 2-20 Unified ICM Central Controller Private and Unified CM PG Private Across Single Link
Advantages
•
•
Best Practices
•
•
•
•
Failure Analysis of Unified CCE Clustering Over the WAN
This section describes the behavior of clustering over the WAN for Unified CCE during certain failure situations. The stability of the highly available (HA) WAN is extremely critical in this deployment model, and failure of the highly available WAN is considered outside the bounds of what would normally happen.
For illustrations of the deployment models described in this section, refer to the figures shown previously for IPT: Clustering Over the WAN.
Entire Central Site Loss
Loss of the entire central site is defined as the loss of all communications with a central site, as if the site were switched off. This can result from natural disasters, power issues, major connectivity issues, and human error, among other things. If a central site retains some but not all connectivity, it is not considered a site loss but rather a partial connectivity loss, and this scenario is covered in subsequent sections.
When an entire central site has completely lost Unified CCE clustering over the WAN, Remote Agents will fail-over properly to the redundant site. Failover times can range from 1 to 60 seconds for agents. Variations are due to agent count, phone registration location, and agent desktop server used.
When using distributed VoiceXML gateways and Unified CVP, the gateways must fail-over from one site to another if their primary site is lost. This failover takes approximately 30 seconds, and calls coming into the remote gateways during those 30 seconds will be lost.
Private Connection Between Site 1 and Site 2
If the private connection between Unified ICM Central Controller sides A and B should fail, one Unified ICM Router will go out-of-service and the other Unified ICM Router will then be running in simplex mode until the link is reinstated. This situation will not cause any call loss or failure.
If the private connection between PG side A and PG side B should fail, the non-active PG will go out-of-service, causing the active PG to run in simplex mode until the link is reinstated. This situation will not cause any call loss or failure.
When using a combined private link, Unified ICM Central Controller and PG private connections will be lost if the link is lost. This will cause both components to switch to simplex mode as described above. This situation will not cause any call loss or failure.
Connectivity to Central Site from Remote Agent Site
If connectivity to one of the central sites is lost from a Remote Agent site, all phones and agent desktops will immediately switch to the second central site and begin processing calls. Failover typically takes between 1 and 60 seconds.
Highly Available WAN Failure
By definition, a highly available (HA) WAN should not fail under normal circumstances. If the HA WAN is dual-path and fully redundant, as it should be, a failure of this type would be highly unusual. This section discusses what happens in this unlikely scenario.
If the HA WAN is lost for any reason, the Unified CM cluster becomes split. The primary result from this occurrence is that Unified ICM loses contact with half of the agent phones. Unified ICM is in communication with only half of the cluster and cannot communicate with or see any phones registered on the other half. This causes Unified ICM to immediately log out all agents with phones that are no longer visible. These agents cannot log back in until the highly available WAN is restored or their phones are forced to switch cluster sides.
Split Unified CCE Gateway PGs
To enhance the distributed architecture of the Unified System CCE deployment, the support for geographically distributed Cisco Unified CCE Gateway PGs is needed. The Unified CCE Gateway PGs are deployed in the same location as the System PGs, adding maximum recovery capabilities in the event of a site failure. Figure 2-21 shows a distributed Unified System deployment supporting two Remote Data Centers with Unified CCE Gateway PGs co-located with each of the distributed Unified System CCEs. Note that the same would apply if the children were Unified CCEs utilizing the Unified CCE System PG.
Figure 2-21 Gateway PG Co-Located
Remote Agent Over Broadband
An organization might want to deploy Unified CCE to support remote agents (for example, at-home agents) using a Cisco Unified IP Phone over a broadband internet connection. This section outlines the remote agent solution that can be deployed using a desktop broadband asymmetric digital subscriber line (ADSL) or Cable connection as the remote network. Another option is to use the Cisco Unified Mobile Agent solution (for details, see Cisco Unified Mobile Agent, page 6-1). Both Cisco Unified Mobile Agent and Remote Agent over Broadband can be supported concurrently using the same back-end infrastructure with the Cisco Virtual Office solution, which is an underlying end-to-end secure infrastructure for remote teleworkers utilizing a converged VPN architecture.
The Cisco Voice and Video Enabled IPSec VPN (V3PN) ADSL or Cable connection can use a Cisco 800 Series router as an edge router to the broadband network. The Cisco 800 Series router can provide the remote agent with V3PN, Encryption, Network Address Translation (NAT), Firewall, Cisco IOS Intrusion Detection System (IDS), and QoS on the broadband network link to the Unified CCE campus. Remote agent V3PN aggregation on the campus is provided via LAN to LAN VPN routers.
Cisco recommends using the Cisco 800 Series router with the following features for remote agent over broadband:
•
•
•
The Cisco 830, 870, and 880 Series routers are examples of the recommended routers. Cisco does not recommend using the Cisco 850 and 860 Series routers for this application because they have limited QoS feature support.
Advantages
•
•
•
•
•
•
•
•
•
•
•
Best Practices
•
http://www.cisco.com/go/designzone
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
–
–
http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_device_support_tables_list.html
–
http://www.cisco.com/en/US/products/sw/custcosw/ps1844/prod_release_notes_list.html
•
Remote Agent with Unified IP Phones Deployed via the Cisco Virtual Office Solution
In this model, the Remote Agent's IP phone and workstation are connected via the VPN tunnel to the main Unified CCE campus. Customer calls routed to the remote agent are handled in the same manner as campus agents. (See Figure 2-22.)
Figure 2-22 Remote Agent with IP Phones Deployed via the Cisco Virtual Office Solution
Advantages
•
•
•
•
Best Practices
•
•
•
•
•
•
•
•
•
Traditional ACD Integration
For enterprises that want to integrate traditional ACDs with their Unified CCE deployment, several options exist. For enterprises that want to load-balance calls between a traditional ACD site and a Unified CCE site, a pre-routing Network Interface Controller (NIC) could be added. (See Figure 2-23.) This requires that the Unified ICM have a NIC that supports the PSTN service provider. In this scenario, the PSTN will query the Unified ICM Central Controller (via the NIC) to determine which site is best, and the Unified ICM response back to the PSTN will instruct the PSTN where (which site) to deliver the call. Any call data provided by the PSTN to the Unified ICM will be passed to the agent desktop (traditional ACD or Unified CCE).
In order to transfer calls between the two sites (ACD site and Unified CCE site), a PSTN transfer service could be used. Use of a PSTN transfer service avoids any double trunking of calls at either site. An alternative to using a PSTN transfer service is to deploy TDM voice circuits between the traditional ACD and Unified CCE voice gateways. In that environment, any transfer of a call back to the original site will result in double trunking between the two sites. Each additional transfer between sites will result in an additional TDM voice circuit being utilized.
Figure 2-23 Integrating a Traditional ACD with a Unified CCE Site
An alternative to pre-routing calls from the PSTN is to have the PSTN deliver calls to just one site or to split the calls across the two sites according to some set of static rules provisioned in the PSTN. When the call arrives at either site, either the traditional ACD or the Unified CM will generate a route request to the Unified ICM to determine which site is best for this call. If the call needs to be delivered to an agent at the opposite site from where the call was originally routed, then TDM circuits between sites will be required. Determination of where calls should be routed, and if and when they should be transferred between sites, will depend upon the enterprise business environment, objectives, and cost components.
Additionally, customers may choose to front-end all calls with the Unified CVP to provide initial call treatment and queuing across both the TDM ACD and Unified CCE agents. (See Figure 2-24.)
Figure 2-24 Integrating Unified CVP with a Traditional ACD and a Unified CCE Site
In this design, all calls come to the Unified CVP-controlled voice gateway first, and they are then controlled by Unified ICM immediately. The Unified ICM uses the PG connections to the TDM ACD and Unified CCE PG to monitor for available agents. Calls are queued in the Unified CVP until an agent becomes available in either environment. When a call needs to be transferred to the TDM ACD, it will hairpin in the voice gateway, meaning that it comes into the gateway on a T1 interface from the PSTN carrier network and goes out on a second physical T1 interface to appear as a trunk on the TDM ACD. Most TDM ACDs are unable to accept inbound calls in IP from the voice gateway and require this physical T1 interface/connection. Unified CCE agents will receive their calls directly over the IP voice network.
This design could also be deployed using the parent/child model, as illustrated in Figure 2-25.
Figure 2-25 Parent/Child Model for Integrating a Traditional ACD with a Unified CCE Site
In this model, the Unified ICM Enterprise parent has PGs connected to a Unified System CCE at one site with a complete installation, and a second site with a TDM ACD that is using a Unified ICM TDM ACD PG. In this model, the Unified ICM still provides virtual enterprise-wide routing, call treatment, and queuing with the distributed Unified CVP voice gateways at the sites. The Unified ICM also has full visibility to all the sites for agents and calls in progress. The difference in this model is that the Unified System CCE provides local survivability. If it loses connection to the Unified ICM parent, the calls will still be treated locally just as they would be at the TDM ACD site.
In either mode, customers can use these deployments to migrate from existing TDM ACDs to Unified CCE, or work with them together as a single virtual contact center across both IP and TDM.
Traditional IVR Integration
There are numerous ways that traditional IVRs can be integrated into a Unified CCE deployment. Determination of which way is best will depend upon many factors that are discussed in the following sections. The primary consideration, though, is determining how to eliminate or reduce IVR double trunking when transferring the call from the IVR.
Using PBX Transfer
Many call centers have existing traditional IVR applications that they are not prepared to rewrite. In order to preserve these IVR applications, but yet integrate them into a Unified CCE environment, the IVR must have an interface to the Unified ICM. (See Figure 2-26.)
There are two versions of the IVR interface to the Unified ICM. One is simply a post-routing interface (Call Routing Interface, or CRI), which just allows the IVR to send a post-route request with call data to the Unified ICM. The Unified ICM returns a route response instructing the IVR to transfer the call elsewhere. In this scenario, the traditional IVR will invoke a PBX transfer to release its port and transfer the call into the Unified CCE environment. Any call data passed from the IVR will be passed by the Unified ICM to the agent desktop or Unified IP IVR.
The other IVR interface to the Unified ICM is the Service Control Interface (SCI). The SCI allows the IVR to receive queuing instructions from the Unified ICM. In the PBX model, the SCI is not required.
Even if the IVR has the SCI interface, Cisco still recommends that you deploy Unified CVP or Unified IP IVR for all call queuing because this prevents any additional utilization of the traditional IVR ports. In addition, use of the Unified IP IVR for queuing provides a way to requeue calls on subsequent transfers or RONA treatment.
Figure 2-26 Traditional IVR Integration Using PBX Transfer
In this design, calls come first to the PBX from the PSTN carrier network on a standard T1 trunk interface. The PBX typically uses a hunt group to transfer the call to the IVR, putting all of the IVR ports into the hunt group as agents in auto available mode. The PBX looks like the PSTN to the Unified ICM because it does not have a PG connected to the PBX. The Unified ICM cannot track the call from the original delivery to the IVR, and it will have reporting only from the time the call arrived at the IVR and the IVR informed the Unified ICM of the call.
When the caller opts out of the IVR application, the IVR sends a Post-Route to the Unified ICM using the Call Routing Interface (CRI). Because this application does not require calls to queue in the IVR, the CRI would be the preferred interface option. The Unified ICM will look at the agent states across the system and select the agent to send the call to (via agent phone number or device target) or translation-route the call to the Unified IP IVR for queuing.
When the call is sent to an agent or into queue, it is hairpinned in the PBX, coming in from the PSTN on a T1 trunk port and then going out to a voice gateway on a second T1 trunk port in the PBX. This connection is used for the life of the call.
Alternatively, if you want to track the call from its entry at the PBX or if you need to capture the caller ANI or original dialed number, you can install a PG on the PBX. The PBX can request (via a Post-Route to the Unified ICM) which IVR port to send the call to behind the PBX. The PBX cannot use a hunt group to deliver the call from the PBX to the IVR. The Unified ICM requires direct DNIS termination to ensure that the translation route maintains the call data collected in the PBX and makes it available to the IVR.
Using PSTN Transfer
This model is very similar to the previous model, except that the IVR invokes a PSTN transfer (instead of a PBX transfer) so that the traditional IVR port can be released. (See Figure 2-27.) Again, the Unified IP IVR would be used for all queuing so that any additional occupancy of the traditional IVR ports is not required and also so that any double trunking in the IVR is avoided. Any call data collected by the traditional IVR application will be passed by the Unified ICM to the agent desktop or Unified IP IVR.
Figure 2-27 Traditional IVR Integration Using PSTN Transfer
In this model, the TDM IVR is set up as a farm of IVR platforms that have direct PSTN connections for inbound calls. The IVR has a PG connection to the Unified ICM, which tracks all calls in the system. When a caller opts out of the IVR treatment, the IVR sends a post-route request to the Unified ICM, which returns a label that will direct the call either to an agent or to the Unified IP IVR for queuing.
The label that is returned to the TDM IVR instructs it to send an in-band transfer command using transfer tones (*8 with a destination label in the carrier network). The IVR has to outpulse these tones to the service provider with tone generation or play the tones via a recorded file.
Using IVR Double Trunking
If your traditional IVR application has a very high success rate, where most callers are completely self-served in the traditional IVR and only a very small percentage of callers ever need to be transferred to an agent, then it might be acceptable to double-trunk the calls in the traditional IVR for that small percentage of calls. (See Figure 2-28.) Unlike the previous model, if the traditional IVR has a Service Control Interface (SCI), then the initial call queuing could be done on the traditional IVR. The reason this is beneficial is that, in order to queue the call on the Unified IP IVR, a second traditional IVR port would be used to transfer the call to the Unified IP IVR. By performing the initial queuing on the traditional IVR, only one traditional IVR port is used during the initial queuing of the call. However, any subsequent queuing as a result of transfers or RONA treatment must be done on the Unified IP IVR to avoid any double trunking. If the traditional IVR does not have an SCI interface, then the IVR will just generate a post-route request to the Unified ICM to determine where the call should be transferred. All queuing in that scenario would have to be done on the Unified IP IVR.
Figure 2-28 Traditional IVR Integration Using IVR Double Trunking
In this model, the TDM IVR is set up as a farm of IVR platforms that have direct PSTN connections for inbound calls. The IVR has a PG connection to the Unified ICM, which tracks all calls in the system. When a caller opts out of the IVR treatment, the IVR sends a post-route request to the Unified ICM, which returns a label that will either direct the call to an agent or queue the call locally on the TDM IVR using the Service Control Interface (SCI). The transfer to the agent is done by the TDM IVR selecting a second port to hairpin the call to the voice gateway and to the Unified CCE agent. This takes up two ports for the time the call is at the agent.
Using Unified CM Transfer and IVR Double Trunking
Over time, it might become desirable to migrate the traditional IVR applications to the Unified CVP or Unified IP IVR. However, if a small percentage of traditional IVR applications still exist for very specific scenarios, then the IVR could be connected to a second voice gateway. (See Figure 2-29.) Calls arriving at the voice gateway from the PSTN would be routed by Unified CM. Unified CM could route specific DNs to the traditional IVR or let the Unified ICM or Unified CVP or Unified IP IVR determine when to transfer calls to the traditional IVR. If calls in the traditional IVR need to be transferred to a Unified CCE agent, then a second IVR port, trunk, and voice gateway port would be used for the duration of the call. Care should be taken to ensure that transfer scenarios do not allow multiple loops to be created because voice quality could suffer.
Figure 2-29 Traditional IVR Integration Using Unified CM Transfer and IVR Double Trunking
In this model, the TDM IVR is front-ended by either the Unified CVP using the voice gateway or the Unified IP IVR and Unified CM with Unified CCE to determine the location to provide call treatment.
With Unified CVP, calls coming into the voice gateway would immediately start a routing dialog with the Unified ICM using the Service Control Interface (SCI). Based upon the initial dialed number or prompting in the Unified CVP, the Unified ICM would decide if the call needs to be sent to the TDM IVR for a specific self-service application or if the Unified CVP has the application available for the caller. If the call was sent to the TDM IVR, the TDM IVR sends a route request to the Unified ICM when the caller opts out. The reply is not sent back to the TDM IVR but back to the Unified CVP as the original routing client. Unified CVP would then take the call leg away from the TDM IVR and transfer it to the Unified CCE agent over the VoIP network or hold it in queue locally in the voice gateway.
With Unified CM, calls coming into the voice gateway would hit a CTI route point for Unified CM to send a route request to Unified ICM to determine the appropriate call treatment device for the caller. If the CTI route point indicated an application that still is on the TDM IVR, Unified ICM would instruct Unified CM to transfer the call to the TDM IVR by hairpinning the call using a second T1 port on the voice gateway to connect to the TDM IVR. The Unified ICM could also instruct Unified CM to translation-route the call to the Unified IP IVR for call processing or prompting, then make a subsequent transfer to the TDM IVR for further processing. When the caller opts out of the TDM IVR, it sends a post-route request to the Unified ICM, and the Unified ICM returns a label to the TDM IVR. This label instructs the TDM IVR to transfer the call using a second T1 port on the IVR and to pass the call back to the voice gateway and over to the Unified CCE agent under Unified CM's dial plan.
In the model controlled by Unified CM, calls are initially received by the voice gateway and hairpinned to the TDM IVR on a second T1 port. When the IVR sends the call back to the Unified CCE agent, it uses a second TDM IVR port and a third port on the voice gateway. All three ports would be tied up on the voice gateway as long as the agent is talking with the caller, and both of the TDM IVR ports would be tied up for the duration of this call as well.
