-
Cisco Unified Contact Center Enterprise 7.0, 7.1, and 7.2 Solution Reference Network Design (SRND)
-
Preface
-
Architecture Overview
-
Deployment Models
-
Design Considerations for High Availability
-
Unified Contact Center Enterprise Desktop
-
Cisco Unified Outbound Dialer
-
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
-
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
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
Clustering Over the WAN with Unified CCE System PG
Failure Analysis of Unified CCE Clustering Over the WAN
Private Connection Between Site 1 and Site 2
Connectivity to Central Site from Unified MA Site
Remote Agent with Unified IP Phones Deployed via the Business Ready Teleworker Solution
Using Unified CM Transfer and IVR Double Trunking
Deployment Models
Last revised on: November 13, 2008
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 Network Infrastructure Quality of Service Design guide, available at
http://www.cisco.com/go/designzone
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/go/designzone
What's New in This Chapter
Table 2-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.
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 queueing and treatment in the Unified CCE System PG are done using Unified IP IVR.
System Unified CCE
Beginning with Unified CCE Release 7.0, there are two ways to install Unified CCE:
•
•
System Unified 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 new 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.
System Unified CCE is available in two specific production models and one demo/lab deployment model. All these deployment models are single-peripheral Unified CCE System PG deployments, meaning that they connect to a single Unified CM cluster and from one to five Unified IP IVRs.
Because System Unified CCE is installed and configured differently, it does not support the number of options that Unified CCE traditionally supports. System Unified 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)
Server 3: Administration and Reporting: AW, HDS, Web Administration Server
•
Server 1: Central Controller and Agent/IVR Controller: Call Router, Logger, Unified CCE System PG
Server 2: Administration and Reporting: AW/HDS/Web Administration Server
•
Server 1: All-in-one: Call Router, Logger, Unified CCE System PG, AW, Web Administration Server
The large deployment typically supports up to 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 OUTD. For specific sizing requirements, refer to the chapter on Sizing Unified CCE Components and Servers, page 10-1.
The installation software for System Unified CCE has been optimized and tested for use with Cisco MCS Unified CM appliances and should be run using only the Cisco server models specified in the chapter on Sizing Unified CCE Components and Servers, page 10-1. This requirement also applies to the optional servers discussed below.
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 Admin Controllers or AWs. Additionally, they support installation of the following options:
•
This option is installed from the System Unified CCE DVD, and it installs a Media Routing Peripheral Gateway (MR PG) preconfigured for the Web Collaboration Option. The Multichannel Controller for Web Collaboration must reside on the same server as the Cisco Media Blender component installed as part of the Web Collaboration option installation. There is no option to make this controller redundant or to use a duplex server.
•
This option is installed from the System Unified CCE DVD, and it installs a Media Routing Peripheral Gateway (MR PG) preconfigured for E-Mail Option. The Multichannel Controller for E-Mail must reside on the same server as the eMail TServer installed as part of the E-Mail option installation. There is no option to make this controller redundant or to use a duplex server.
•
This option is installed from the System Unified CCE DVD. It installs a media routing peripheral gateway (MR PG) that is preconfigured with one Unified OUTD. The outbound controller must be installed on its own server. It is not possible to make this controller redundant, to add a duplex server, or to add multiple outbound controllers to the system Unified CCE.
•
This Peripheral Gateway is installed from the Unified ICM Setup CD (not the System Unified CCE DVD), and it is used to connect a System Unified CCE System PG to a parent Unified ICM Enterprise system. To the Parent Unified ICM, this makes the System Unified CCE look like any other Peripheral Gateway controlled ACD. This Peripheral Gateway may not be installed on any of the System Unified 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 as part of the 80 supported PGs in the Unified ICM Enterprise system.
These are the only possible deployments of System Unified 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 System Unified CCE, there are several benefits:
•
•
•
For a large number of Unified CCE customers, System Unified 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 System Unified CCE does fit, the reduced deployment time and ease of administration provide significant benefits.
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/CRS.
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.
•
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.
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 and Cisco Unified Queue Manager are 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 or IP QM 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. This should be kept in mind if the phones need to interact with Unified IP IVR or Unified QM applications.
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.
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-1 illustrates this type of deployment using the System Unified CCE model.
Figure 2-1 Single-Site Deployment
Figure 2-1 shows a Unified IP IVR, a Unified CM cluster, redundant System Unified CCE servers, an Admin Controller (Administrative Workstation) and Historical Data Server (HDS), and a direct connection to the PSTN from the voice gateways. The System Unified CCE server in this scenario is running the following major software processes:
•
•
•
•
•
•
Optionally the Central Controller and Agent Controller (Unified CCE System PG) could 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 could be installed using the traditional Unified CCE model (not System Unified CCE), which would allow for several different options. For example, Unified CVP could be used instead of the Unified IP IVR for queuing and treatment of calls.
System Unified 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/go/designzone
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.
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 System Unified 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 queueing in this model as well. System Unified CCE does not support the use of Unified CVP; therefore, the system would need to be installed using the traditional Unified CCE Setup CD. The 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. The web configuration tools would not be available in this model, so all configuration would be done using the ConfigManager application on the Unified ICM Admin Workstation directly. Additionally, 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
http://www.cisco.com/go/designzone
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. System Unified 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. The 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
http://www.cisco.com/go/designzone
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.
In both cases the label is a dialed number that will instruct the Unified CM to transfer the call to an IVR. In the case of the Unified CCE System PG, the peripheral target and routing client are both the Unified CCE System peripheral. Translation routing is done without having to configure the translation routes explicitly in the Unified ICM.
In the case of the Unified CCE peripheral, the routing client and peripheral target are different. The routing client is the Unified CCE peripheral, while the peripheral target is the specific IVR PIM to which the call is being transferred. Translation routes must be configured explicitly.
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-2 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-2 illustrates this model using a System Unified CCE deployment.
Figure 2-2 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. The Unified ICM software can be deployed either with the Unified CCE System PG or the Unified CCE PG. The system can be a System Unified 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 Network Infrastructure Quality of Service Design guide, available at
http://www.cisco.com/go/designzone
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-3 illustrates this model.
Figure 2-3 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 System Unified 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/go/designzone
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 System Unified 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 System Unified CCE. 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. When using Unified CVP for queuing and treatment, the Unified CCE PG is the only deployment choice.
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 System Unified 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-4 illustrates this model using a traditional Unified CCE deployment with the Unified CCE System PG.
Figure 2-4 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 System Unified 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 System Unified 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-5 shows this same model deployed using the parent/child model.
Figure 2-5 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 System Unified CCE deployment using the small/medium model that loads both Central Controller and Agent Controller on the system server. There is also a local Admin Server (Admin Workstation) for the System Unified CCE to perform configuration, scripting, and reporting tasks for that specific site. There is a Unified CCE Gateway PG that connects the System Unified 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 System Unified 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 System Unified 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 System Unified 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 System Unified 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.
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-6 illustrates this model using traditional Unified CCE deployment.
Figure 2-6 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
•
•
http://www.cisco.com/web/partners/tools/steps-to-success/index.html
•
•
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-7 illustrates this deployment model.
Figure 2-7 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 red
