The Unified CCE Gateway PG allows Unified CCE to appear as a traditional ACD connected to the Unified ICM system. The Unified CCE Gateway PG provides the Unified ICM system with a PG that communicates with the CTI interface of the Unified CCE System PG.
In the parent/child model, you configure the child Unified CCE to function on its own. Unified CCE does not need a connection to the parent to route calls to agents. This independence provides local survivability for mission-critical contact centers during connection failures between the
child and parent.
The child system can automatically send configuration objects to the parent Unified ICM for insertion into the Unified ICM configuration. This process eliminates the need to configure objects twice (on the local ACD and again on the Unified ICM). You can also turn off this functionality for situations where the customer does not want automatic configuration updates. For example, you do not want automatic updates from an outsourcer child system that also supports agents for another customer.
The Unified CCE Gateway PG can connect to a Unified CCE child that is using the Unified CCE System PG. If the child has multiple Unified CCE System PGs and peripherals, install and configure a separate Unified CCE Gateway PG in
the parent system for each child PG. When deployed on a separate VM, a Unified CCE Gateway PG can manage multiple child Unified CCE peripherals.
In the Unified CCE child, you can deploy IP IVR or Unified CVP for call treatment and queuing. If you deploy Unified CVP, configure another VRU PG. This model does not follow the single peripheral model used when IP IVR is deployed. For this reason, information about calls
queued at the child (and queue time of a call) is not available on the parent. Any computation involving queue time by the parent is inaccurate, which can lead to adverse impacts to routing on the parent.
The Unified ICME data center location contains the Unified ICME Central Controller. The data center has a redundant pair of Central Controllers. A Central Controller has Call Router and Logger servers.
You can deploy the servers as individual Call Routers and Loggers and deploy the servers in two geographically distributed data centers for extra fault tolerance.
The Unified ICME Central Controllers control Peripheral Gateways (PGs) at the data center location. A redundant pair of VRU PGs controls Unified CVP across the architecture.
You can insert more PGs at this layer to control TDM or legacy ACDs and VRUs. This approach can support a migration to Unified CCE or support outsource locations that use the TDM or legacy ACDs.
The Unified ICME parent does not support any directly controlled agents in this model. So, in parent/child deployments, Unified ICME does not support classic Unified CCE with a Unified Communications Manager PG installed on this Unified ICME parent. Control all agents externally to this Unified ICME
The Unified CVP VRU PG pair controls the Unified CVP Call Server. The Call Server translates the VRU PG commands from Unified ICME into VoiceXML and directs the VoiceXML to the Voice Gateways (VGs) at the child sites. Calls from the data center location can come into the
remote call centers under control of the Unified CVP at the parent location. The parent then has control over the entire network queue of calls across all sites. The parent holds the calls in queue on the VGs at the sites until an agent becomes available.
Unified CCE Call Center (Child) Site
The Unified CCE call center contains a Unified Communications Manager cluster for local IP-PBX functionality and call control for the IP phones. A local Unified IP IVR also provides local call queuing for the Unified CCE site. A
redundant pair of Unified CCE Gateway PGs connects this site over the WAN to the Central Controller at the Unified ICME parent. You can deploy the Unified CCE Gateway PGs on separate VMs or coresident with the CCE System PG
with the following caveats:
If the Unified CCE Gateway PG and Unified CCE System PG Instance Numbers are the same, then use different PG numbers for those PGs.
If the Unified CCE Gateway PG and Unified CCE System PG Instance Numbers are different, then you can use the same PG number for those PGs.
Do not add other PGs (such as VRU PG or MR PG) to this VM.
Follow the scalability limits of the coresident Unified CCE Gateway PG and Unified CCE System PG.
The Unified CCE Gateway PGs provide real-time event data and agent states to the parent from the Unified CCE child. The Unified CCE Gateway PGs also capture some, but not all, configuration data and send it to the parent Unified ICME configuration database.
You can replace the IP IVR at the child site with a local Unified CVP instance. Unified CVP is not integrated as part of the System PG for the Agent Controller. The installation for Unified CCE with Unified CVP defines a separate VRU PG specifically for Unified CVP. Because
Unified CVP is not part of the System PG, the Unified CCE Gateway PG does not report calls in queue or treatment to the parent Unified ICME. If your parent routing requires queueing or treatment information, deploying with Unified CVP might not meet your needs.
A local Unified CCE child system provides ACD functionality. You can size the Unified CCE child system as a Rogger with a separate Unified CCE Agent PG server. The Rogger contains a Call Router and Logger. The set of redundant Agent PG servers contain the System PG for Unified Communications Manager and IP IVR, CTI Server and CTI OS Server, and the optional
VRU PG for Unified CVP.
In either configuration, you need a separate Administration & Data Server to host the configuration and scripting tools for the system, as well as the optional Historical Database Server, and the web-based Unified Intelligence Center reporting tool.
You can deploy the Unified CCE Gateway PG at the Unified ICME data center as shown in the following figure. This deployment model allows you to manage and control the Unified CCE Gateway PGs centrally. When different companies own and manage the child and parent sites, that condition can force you to deploy the Unified CCE Gateway PG at the Unified ICME data center. For example, an Outsourcer/Service Bureau manages child site and connects to the Unified CCE Gateway PGs at the parent site.
Figure 1. Parent/Child Deployment with Unified CCE Gateway PGs at Data Center
There are several drawbacks with moving the Unified CCE Gateway PGs to the data center. One drawback is recovering reporting data after a network failure. If the network connection between the parent site and the Unified CCE System PGs at the child drops, all reporting at the
parent site is lost for that period.
You can deploy the Unified CCE Gateway PG locally to the Unified CCE System PG. Then, if the connection between the parent and child sites drops, the historical data in the parent site updates when the network connection comes back.
Another drawback with centralizing the Unified CCE Gateway PGs is higher network bandwidth requirements for the connections between the PGs.
The following figure shows the connection between the parent PG/PIM and the child system
Figure 2. Connection Between Gateway PG and System PG
In general, you deploy the Gateway PG on the same VM with the System PG that it is monitoring. For an outsource model, you can deploy the Gateway PG remote from the System PG.
The following factors affect the amount of data coming over the link once it is initialized:
Message sizes can vary depending on their content (such as the size of extensions, agent IDs, and call data). For example, a Route Request with no data is a small message. If all call variables and ECC variables are populated with large values, the data drastically affects the
size of the message.
Call scenarios can cause great variation in the number of messages per call that are sent over the line. A simple call scenario can send 21 messages over the line. More complex call scenarios involving queuing, hold retrieves, conferences, or transfers send even more messages over the line for each call.
The more skill groups to which an agent belongs, the more messages are sent over the line. In a simple call scenario, each additional skill group adds two messages per call. These messages are approximately 110 bytes each, depending on field sizes.
Bandwidth Calculation for Basic Call Flow
A basic call flow (simple ACD call without other steps) with a single skill group typically generates 21 messages. Plan for a minimum required bandwidth of 2700 bytes/second.
In a basic call flow, there are four places where call variables and ECC data can be sent. If you use call data and ECC variables, they are sent four times during the call flow. Using many variables could easily cause the 2700 bytes/second of
estimated bandwidth per call to more than double.
Call variables used on the child PG are sent to the parent PG regardless of their use or the setting of the MAPVAR parameter. For example, assume that the child PG uses call variables 1 through 8 but the parent PG never uses those variables. If MAPVAR = EEEEEEEEEE, meaning
Export all but Import nothing, the variables are sent to the PG where the filtering takes place. The bandwidth is still required. But, if the map setting is MAPVAR = IIIIIIIIII, Import all but Export nothing, then
bandwidth is spared. Call variable data is not sent to the child PG on a ROUTE_SELECT response.
Basic Call Flow Example
Assume a call rate of 300 simple calls per minute (five calls per second). The agents are all in a single skill group with no passing of call variables or ECC data. The required bandwidth in this case is:
A more complex call flow or a call flow involving call data could easily increase this bandwidth requirement.
Unified CCE System Peripheral
The Unified CCE System Peripheral acts as a single logical Unified ICM peripheral that combines the functionality the VRU peripherals and a Unified Communications Manager peripheral. Unified CCE treats the Unified IP IVR and Unified Communications Manager peripherals as
a single peripheral eliminating the need to translation-route calls to the Unified IP IVR for treatment and queuing. 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.
As a single peripheral, Termination Call Detail (TCD) records and other reporting data include the information for the call during the entire time the call 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), the Unified CCE System PG generates only a single record.
The Unified CCE System PG does not support Unified CVP. All queuing and treatment in the Unified CCE System PG uses Unified IP IVR. You can use a separate Unified CVP on its own PG with the Unified CCE System Peripheral.
Precision Routing is not supported in a parent/child deployment. Precision Routing does not support the Unified CCE System Peripheral.
In parent/child configurations, there is no multichannel routing and integration through the parent Unified ICM. Media Routing PGs must connect to the child Unified CCE. A separate Cisco Interaction Manager or partition is required for each child.
Enterprise Unified CCE Peripheral deployments
You cannot use Enterprise Unified CCE (CallManager and VRU deployed as separate peripherals) deployments where Unified CCE is a child to a Unified ICM. Use a Unified CCE System Peripheral deployment for that solution.
Whisper Announcement only supports a specific Parent/Child configuration. That configuration queues calls and sources whisper announcements with an IP IVR on the child system PG. If you also use agent greetings, the configuration also requires a dedicated CVP at the child on a dedicated VRU PG to provide agent greetings. Cisco must approve any use of Whisper Announcement in Parent/Child configurations. Cisco must analyze and approve any such designs.
Whisper Announcement with IP IVR in Parent/Child has no impact on agent sizing on the Child System PG, but incurs great impact on the IP IVR.
Agent Greeting only supports a specific Parent/Child configuration. That configuration queues calls at an IP IVR on the child system PG. The configuration requires a dedicated CVP at the child on a dedicated VRU PG to provide the agent greetings. Cisco must approve any use of Agent Greeting in Parent/Child configurations. Cisco must analyze and approve any such designs.
Your configuration must meet the following conditions:
Use IP IVR on the child for call treatment, queuing, and Whisper Announcement.
Use CVP on the child only for Agent Greeting. Do not use CVP for call queuing. Use a separate VRU PG for the CVP.
Network Consultative Transfer
In a parent/child deployment, you cannot transfer calls terminating on child systems by network consultative transfer (NCT) through the routing clients on the parent. Although NCT works for TDM ACDs, and the parent/child deployment
architecture is similar, the parent/child deployment does not work the same.
For a TDM PG, the CTI Server is connected to the ACD PG, which is part of the parent system. This arrangement is the same as a CTI-Server connected to the Gateway PG. In parent/child deployments, CTI connects to the child PG. Having CTI connected to the child PG does not provide the network call ID and other information that are needed for allow network consultative transfer.
When a post route is initiated to the parent system from the child, network blind transfer is possible using any client (for example, Unified CVP) on the parent system.
Active Directory Deployments for Parent/Child
You can deploy parent/child systems on the same AD Domain or Forest, but you can also deploy parent/child systems in disparate AD environments. The common scenario for this deployment occurs when an outsourced contact center site houses the child Unified CCE system. In this
case, the parent AD domain contains the Gateway PG that is a parent node. (Do not use Workgroup membership because of the administration limitations.) This deployment supports remote branch offices with PGs that are members of the central site
domain which contains the Routers, Loggers, and Distributors.
The topology shown in the following figure represents the AD Boundaries for the two AD domains in this deployment. The figure also shows to which domain the application servers are joined. The parent AD Domain
Boundary extends beyond the central data center. The parent AD Boundary includes the Unified ICM Central Controllers and accompanying servers with the ACD PG (at the legacy site) and Gateway PG at the child Unified CCE site. The child Unified CCE site and its AD Boundary have the Unified CCE servers
as members. The AD Boundary can be part of an outsourcer corporate AD environment, or the AD Boundary can be a dedicated AD domain for Unified CCE.
Figure 3. Active Directory and Firewall Deployment
Unified CCMP for Parent/Child Deployments
In parent/child deployments, a single Unified CCMP instance connects to each of the child Unified
CCE Administration & Data servers. Configure these servers as physically separate Primary
Administration & Data Servers. Each child instance appears as a tenant within
Unified CCMP. Resources added through Unified CCMP are linked to a tenant. The standard process replicates the added resource
from the Unified CCE child to its parent.
Parent/Child Deployments Across Sites
The Parent/Child model provides local, distributed call
processing with a local Unified Communications Manager and Unified CCE at each site (child).
A centralized Unified ICM Enterprise parent controls the child site for
enterprise-wide routing, reporting, and call control. This model is more tolerant of WAN outages, with each site continuing to operate during an outage. The following figure shows this model.
Figure 4. Multisite Deployment with Distributed Call Processing and
In this design, there is a parent Unified ICM Enterprise system deployed
with Unified CVP and its own Administration & Data server. Each
distributed child site is a complete Unified CCE deployment consisting of
Central Controller on one or more VMs. A local Administration
& Data Server for Unified CCE performs configuration, scripting, and
reporting tasks for that specific site. A Unified CCE Gateway PG connects Unified CCE to the Unified ICM parent and it is part of the Peripheral
Gateways deployed on the parent Unified ICM.
An optional deployment for the Unified CCE Gateway PG is to colocate it
with the Unified CCE System PG, under the following guidelines:
If the Unified CCE Gateway
PG and Unified CCE System PG Instance Numbers are the same, then use different PG numbers
for the PGs.
If the Unified CCE Gateway
PG and Unified CCE System PG Instance Numbers are different, then you can use the same PG number
for the PGs.
Do not add any other PGs (such as a
VRU PG or MR PG) to this VM.
In this design, the local Unified CCE deployments act as their own local
IP ACDs with no visibility to any of the other sites in the system. Agents 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 controls the
calls coming into the distributed sites. Unified CVP provides call queuing and
treatment in the VoiceXML Browser in the Voice Gateway (VG). Configure the
Unified CVP on the parent to use Unified CVP Router Requery to take control of
the call during a failure or answer timeout. The child Unified CCE
cannot terminate the ingress call to a child Unified CVP or a child Unified IP
IVR. The local Unified IP IVR servers only provide a local backup for the
connection from these VGs to the parent Unified CVP Call
Control server. The local Unified IP IVR also provides local queue treatment
for calls that the local agents do not answer (RONA) rather than sending
the call to the Unified CVP to be requeued.
The child 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 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 Communications Manager
Peripheral Gateways, the parent/child model provides for complete local
redundancy at the contact center site. The local Unified CCE takes over call
processing for inbound calls from the Unified CVP gateways and provides local
call queuing and treatment in the local Unified IP IVR. This configuration provides complete redundancy and 100% up-time
for contact centers that cannot be down because of a WAN failure.
For customers who have Unified ICM
already installed with their TDM ACD platforms, this approach can be useful when they want to do the following:
sites with Unified CCE
Convert an existing site to Unified CCE
The approach allows
the Unified ICM to continue performing enterprise-wide routing and reporting
across all the sites while inserting new Unified CCE technology on a
Unified CVP can be at both the parent and child. The call flows are similar for Unified CVP at the parent and IP IVR at the child. One key difference is that information about queued calls at the
child Unified CVP are not available at the parent (through the Unified CCE
Gateway PG). This difference means that you cannot use routing elements like the minimum expected
delay (MED) over services or CallsQNow in the parent.
Unified CVP provides a
virtual network queue across all the distributed sites controlled by the parent
Unified ICM. The parent Unified ICM has visibility into all the distributed
sites and sends the call to the next available agent from the virtual queue.
Each distributed site can
scale up to the maximum number of supported agents on a single Unified CCE
deployment. Multiple Unified CCE Central Controllers can be connected to a
single cluster to scale up to the maximum number of supported agents
per cluster. The Unified CCE Gateway PG on the parent connects the Unified CCE systems to the parent Unified ICM. The Unified CCE Gateway PG can scale up
to the maximum number of supported agents per parent Unified ICM Enterprise
All or most VoIP traffic
can be contained within the LAN of each site, if desired. The QoS WAN shown in
Figure 19 is required for voice calls to be transferred across sites. Use of a
PSTN transfer service (for example, Take Back and Transfer or Transfer Connect)
eliminates that need. If desired, a small portion of calls arriving at a
particular site can be queued for agent resources at other sites to improve
customer service levels.
Unified ICM pre-routing
can load-balance calls based on agent or Unified CVP session
availability. Unified ICM can also route calls to the best site to reduce WAN usage for VoIP
Failure at any one site
has no impact on operations at another site.
Each site can be sized
according to the requirements for that site
The parent Unified ICM
Central Controller provides centralized management for configuration of routing
for all calls within the enterprise.
The parent Unified ICM
Central Controller provides the capability to create a single enterprise-wide
The parent Unified ICM
Central Controller provides consolidated reporting for all sites.
parent/child model usually requires a higher number of VMs. The extra VMs are needed for the increased number of software
components (additional Unified CCE Gateway PGs required if colocating with
Unified CCE System PG is not an option, additional Central Controller for each
child, and so forth).
Colocate the Unified CCE
Gateway PG, Unified Communications Manager cluster, Unified IP IVR, and Unified CCE (if possible)
at the contact center site.
The communication link
from the parent Unified ICM Central Controller to the Unified CCE Gateway PG
must be sized properly and provisioned for bandwidth and QoS.
Gatekeeper-based or RSVP
agent-based call admission control is used to reroute calls between sites over
the PSTN when WAN bandwidth is not available. It is best to ensure that
adequate WAN bandwidth exists between sites for the maximum amount of calling
that can occur.
If the communication link
between the Unified CCE Gateway PG and the parent Unified ICM Central
Controller is lost, then all contact center routing for calls at that site is
put under control of the local Unified CCE. Unified CVP-controlled ingress
Voice Gateways have survivability TCL scripts to redirect inbound calls to
local Unified Communications Manager CTI route points and the local Unified IP IVR are used to
handle local queuing and treatment during the WAN outage. This feature of the parent/child model provides complete local survivability for
the call center.
While two intercluster
call legs for the same call do not cause unnecessary RTP streams, two separate
call signaling control paths remain intact between the two clusters (producing
logical hair-pinning and reducing the number of intercluster trunks by two).
Consider the percentage of intersite transfers when sizing intercluster
Latency between parent
Unified ICM Central Controllers and remote Unified CCE Gateway PGs must not
exceed 200 ms one way (400-ms round trip).
Geographically Redundant Child Data Centers (Using Unified IP IVR)
Globalization, security, and disaster recovery considerations are driving business to diversity locations across multiple regions. In addition, organizations want to distribute workloads between computers, share network resources effectively, and increase the availability of critical applications. Geographically redundant data centers split critical applications across two data centers. Enterprises deploy geographically redundant data centers to minimize planned or unplanned downtime and share data across regions.
Geographically redundant data centers have a minimum of two load balancers, one in each data center. You can use two load balancers for each data center for local redundancy.
Geographically Redundant Child Data Centers with CoW
The following figure shows geographically redundant Child data centers with clustering over the WAN (CoW) using Unified IP IVR.
Figure 5. Geographically Redundant Child Data Centers with Clustering over WAN (Using Unified IP IVR)
Geographically redundant data centers use clustering over the WAN, Unified Communications Manager clusters, and 1:1 redundancy for IP IVR, SIP proxy, voice gateways, and Cisco Unified Intelligence Center for example.
Latency requirements across the high-availability (HA) WAN must meet the current Cisco Unified Communications requirements for clustering over the WAN. Unified Communications Manager allows a maximum latency of 40 ms one way (80 ms for a round trip).
Certain fault tolerant networks can carry all your traffic on a single network, for example, Multiprotocol Label Switching (MPLS) or SONET. For such networks, keep the public and private traffic on separate routes within the network and respect standard latency and bandwidth.
In a balanced deployment, central site outages include loss of half of the ingress gateways. Scale gateways to handle the full load in both sites it one site fails.
Carrier call routing must be able to route calls to the alternate site during failures.
A single Unified CCE system peripheral controls all the Unified IP IVRs and the Unified Communications Manager. Unified IP IVR distributes the calls to the least loaded Unified IP IVR. A Unified IP IVR in data center B can treat calls coming into data center A. Both A- and B-sides of Unified CCE can identify all the Unified IP IVRs. PIM activation logic determines if the A- or B- side PIM connects to each of the Unified IP IVRs. This process means that the PG at data center A can connect to the Unified IP IVR at data center B. Make sure that you size the WAN appropriately.
To avoid the bandwidth overhead, consider using Unified CVP for clustering over the WAN deployments. Unified CVP allows higher scalability per cluster than Unified IP IVR.
Unified IP IVR-Based Child Data Centers with Distributed Unified Communications Manager
If you have remote offices with agents, gateways, and Unified Communications Manager clusters, the clusters at the data centers are typically independent.
The remote office has a WAN connection back to the data centers. Each cluster is independent, with its own agents and PG pairs. Each data center uses subscribers that are local to the data center because JTAPI is not supported over the WAN. For example, data center A cannot use the subscribers in data center B. The Unified CCE central controller, Unified Intelligence Center, load balancer, SIP proxy server, and Unified IP IVR are located in the data centers. TDM and VXML voice gateways are located at the remote office with local PSTN trunks.
In parent/child deployment, the Unified ICME acts as the parent controlling one or more Unified CCE child ACDs. The Unified ICME system is the network call routing engine for the contact centers. The network queuing uses the
Unified CVP and Unified CCE Gateway PGs to connect child Unified CCE systems. The child Unified CCE systems are individual ACD systems fully functional with local call processing in case they lose their WAN connection to the
parent system. This configuration provides a high level of redundancy and availability to the Unified CCE solution. These qualities allow sites to remain functional as Unified CCE sites even if they are cut off from centralized call processing resources.
In a typical inbound call flow from the PSTN, the carrier network directs calls to the contact center sites using a predefined percent allocation or automatic routing method. These calls terminate in the Unified CVP VGs (Voice Gateways) at the contact center locations under control of
Unified CVP on the Unified ICME parent .
The inbound call flow is as follows:
The call arrives on the Unified CVP VG at the Parent ICME Data Center.
The Unified CVP VG maps the call by dialed number to a particular Unified CVP Call Server at the parent site. The VG then sends a new call event to the Unified CVP Call Server.
The Unified CVP Call Server sends the new call event message to the Unified CVP VRU PG at the Unified ICME parent site.
The Unified CVP PG sends the new call message to the Unified ICME parent. The Unified ICME uses the inbound dialed number to qualify a routing script to determine the proper call treatment (messaging) or agent groups to consider for the call.
Unified ICME instructs Unified CVP to hold the call in the VG at the site. Unified CVP waits for an available agent while directing specific instructions to play .wav files for hold music to the caller.
When an agent becomes available, the Unified ICME instructs Unified CVP to transfer the call to the available agent by using a translation route. (The agent is not at the same physical site, but located across the WAN.) Any data collected about the call in the Unified ICME
parent Unified CVP is transferred to the remote PG (either a TDM, legacy PG, or one of the Unified CCE Gateway PGs for Unified CCE).
The call arrives at the targeted site on a specific translation route DNIS that the Unified ICME parent selected. The PG at the child site is expecting a call to arrive on this DNIS to match up with any pre-call CTI data associated with the call. The local ACD or Unified
CCE performs a post-route request to the PG (either TDM PG or Gateway PG depending on the target ACD) to request the CTI data as well as the final destination for the call (typically the lead number for the skill group of the available agent).
If the agent is no longer available, Unified CVP at the parent site uses the Router Requery function in the ICM Call Routing Script to select another target automatically.
Post-route Call Flow
You use post-routing for calls already at a peripheral ACD or VRU that you want to route to another agent or location intelligently. If an agent gets a call in the ACD or Unified CCE that must go to a different skill group or location, the agent can use the post-route
functionality to reroute the call.
The post-route call flow is as follows:
The agent transfers the call to the local CTI route point for reroute treatment using the CTI agent desktop.
The reroute application or script makes a post-route request to the Unified ICME parent by using the local Unified CCE Gateway PG connection.
The Unified ICME parent maps the CTI route point from Unified CCE as the dialed number and uses that number to select a routing script. This script returns a label or routing instruction that can move the call to another site, into a different skill group on the same site, or
to a Unified CVP node for queuing.
Unified CCE receives the post-route response from the Unified ICME parent system. Unified CCE then uses the returned routing label as a transfer number to send the call to the next destination.
Parent/Child Fault Tolerance
The parent/child model provides for fault tolerance to maintain a complete ACD with Unified CCE deployed at the site, with local IP-PBX and call treatment and queuing functionality.
Unified CCE Child Loses Connection to Unified ICME
A WAN failure between the child and the parent isolates the local Unified CCE system from the parent and the Unified CVP VG. Calls coming into the site no longer get treatment from the Unified CVP under control of the Unified ICME parent. Replicate the following functionality locally, depending on the configuration at the child site:
For Unified CCE child configurations using local IP IVR resources for queue and treatment:
The local VG must have dial peer statements to pass control of the calls to the local Unified CM cluster if the parent Unified CVP Call Server cannot be reached. The local Unified CM cluster must have CTI route points mapped to the inbound DNIS or dialed numbers that the local VG presents if the parent Unified CVP Call Server is not reached.
Configure the local IP IVR with appropriate audio files and applications that the child system can call locally to provide basic call treatment.
The child CCE Routing Script must handle queuing of calls for agents in local skill groups. The script must instruct the IP IVR to play the treatment in-queue while waiting for an agent.
To allow the agents full access to customer data for routing and screen pops, provision locally any data lookup or external CTI access that parent system normally provides.
Any post-routing transfer scripts fail during this outage, so configure Unified CCE to handle this outage or prevent the post-route scripts from being accessed.
For Unified CCE child configurations using local Unified CVP resources for queue and treatment:
The local VG must have dial peer statements to pass control of the calls to the local Unified CVP Call Server at the child site. To process these calls locally at the child site, configure in the child Unified CCE the inbound DNIS or dialed numbers that the local VG presents to the child Unified CVP.
Configure the local VXML Gateways and Unified CVP Call Servers with appropriate .wav files and applications that the child system can call locally to provide basic call treatment.
Replicate self-service or Unified CVP Studio VXML applications that the parent Unified ICME normally provides. Use the Unified CVP VXML Server (web application server) at the child site to generate the dynamic VXML for these applications.
The child Unified CCE Routing Script must handle queuing of calls for agents in local skill groups. The script must instruct the local Unified CVP at the child site to play the treatment in-queue while waiting for an agent.
To allow the agents full access to customer data for routing and screen pops, provision locally any data lookup or external CTI access that parent system normally provides.
Any post-routing transfer scripts fail during this outage, so configure Unified CCE to handle this outage or prevent the post-route scripts from being accessed.
Unified CCE Gateway PG Cannot Connect to Unified ICME
If the Unified CCE gateway PG fails or cannot communicate with the Unified ICME parent, the Unified ICM parent cannot detect the state of the agents at the child. But, in some cases, the Unified ICME parent Unified CVP can still control the inbound calls. In this case, the Unified ICME parent does not know if the remote Unified CCE gateway PG failed or if the actual Unified CCE ACD failed locally.
The Unified ICME at the parent location can automatically route around this site, considering it down until the PG comes back online and reports agent states again. Alternatively, the Unified ICME can also direct a percentage of calls as blind transfers to the site Unified CCE using the local inbound CTI route points on Unified CM. This method would present calls with no CTI data from Unified CVP, but it would allow the agents at the site to continue to get calls locally with their Unified CCE system.
If the local Unified CCE child system fails, the Unified CCE gateway PG cannot connect to it. The Unified ICME parent then considers all agents to be off-line and not available. If local cluster receives calls while the child Unified CCE system is down, the call-forward-on-failure processing takes over the call for the CTI route point. This method redirects the call to another site or an answering resource to play a message telling the caller there is a problem and to call again later.
Reporting and Configuration Impacts
If the Unified CCE child disconnects from the Unified ICME parent, the local ACD still collects reporting data and allows local administrators to change the child routing scripts and configuration. The Unified CCE gateway PG at the child site caches these objects and stores them to be sent when the Unified ICME parent is available. This functionality is available only if the Unified CCE gateway PG is colocated at the child Unified CCE site.
Other High Availability Considerations
You can install multichannel components, such as Cisco Unified Web and E-mail Interaction Manager and Cisco Outbound Option, only at the child Unified CCE level, not at the parent. They are treated as nodal implementations on a site-by-site basis.
Traditional ACD Integration
Enterprises that want to integrate traditional ACDs with their Unified CCE use a parent/child deployment. In these deployments, the Unified ICM and Unified CCE each have a Central Controller or a hybrid deployment where Unified Communications Manager PGs with TDM ACD PGs, Gateway PGs, or both use the same Central Controller. Several options exist within those categories depending on how the calls are routed within the deployment.
As an alternative to pre-routing calls from the PSTN, the PSTN can deliver calls to just one site or to split the calls across the two sites according to a set of static rules provisioned in the PSTN. When the call arrives at either site, either the traditional ACD or the Unified Communications Manager generates a route request to the hybrid Unified ICM/CCE to determine which site is best for this call. If the call is for an agent at the opposite site from where the call was originally routed, you require TDM circuits between sites. The determination of where calls are routed (and if and when they are transferred between sites) depends on the enterprise business environment, objectives, and cost components.
Hybrid Deployment with Unified CVP
Customers can choose to front end all calls with Unified CVP to provide initial call treatment and queuing across both the TDM ACD and Unified CCE agents.
In this design, all calls first come to the Voice Gateway (VG) controlled by Unified CVP. The Unified ICM/CCE Call Router then directs the calls. Unified ICM/CCE uses the PG connections to the TDM ACD and Unified CCE PG to monitor for available agents. Calls are queued in Unified CVP until
an agent becomes available in either environment. When a call transfers to the TDM ACD, the call comes into the VG 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 (known as "hairpining the call"). Most TDM ACDs cannot accept inbound calls in IP from the VG and require this physical T1 interface connection. Unified CCE agents receive their calls directly over the IP voice network.
ACD Integration and Parent/Child Deployments
The following figure illustrates the parent/child.
Figure 7. Parent/Child Integration of Traditional ACD with Unified CCE
In this model, the Unified ICM Enterprise parent has PGs connected to a Unified CCE System PG at one site and a Unified ICM TDM ACD PG at a second site. In this model, Unified ICM still provides virtual enterprise-wide routing,
call treatment, and queuing with the distributed Unified CVP Voice Gateways at the sites. Unified ICM also has full visibility to all the sites for agents and calls in progress. The difference in this model is that Unified CCE provides local survivability. If it loses connection to the Unified
ICM parent, the calls are still treated locally just as they are at the TDM ACD site.
Traditional VRU Integration
There are numerous ways to integrate traditional VRUs into a Unified CCE deployment. The following sections discuss the factors that can determine the best way. The primary consideration is determining how to eliminate or reduce VRU double trunking when transferring the call from the VRU.
Many call centers have existing traditional VRU applications that they are not prepared to rewrite. To preserve these VRU applications and integrate them into a Unified CCE environment, the VRU must have an interface to Unified CCE.
There are two versions of the VRU interface to Unified CCE. One is simply a post-routing interface (Call Routing Interface or CRI), which allows the VRU to send a post-route request with call data to Unified CCE. Unified CCE returns a route response instructing the VRU to transfer the
call elsewhere. In this scenario, the traditional VRU invokes a PBX transfer to release its port and transfer the call into the Unified CCE environment. Unified CCE passes any call data from the VRU to the agent desktop or Unified IP IVR.
The other VRU interface to Unified CCE is the Service Control Interface (SCI). The SCI enables the VRU to receive queuing instructions from Unified CCE. In the PBX model, the SCI is not required.
Even if the VRU has the SCI interface, deploy Unified CVP or Unified IP IVR for all call queuing. This method prevents any extra use of the traditional VRU ports. In addition, use of the Unified IP IVR for queuing provides a way to re-queue calls on subsequent
transfers or RONA treatment.
Figure 8. Traditional VRU 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 VRU, putting all VRU ports into the hunt group as agents in auto available mode. The PBX looks like the PSTN to
Unified CCE because it does not have a PG connected to the PBX. Unified CCE cannot track the call from the original delivery to the VRU. Unified CCE only has call data from the time the call arrived at the VRU and the VRU informed Unified CCE of the call.
When the caller opts out of the VRU application, the VRU sends a Post-Route to Unified CCE using the Call Routing Interface (CRI). Because this application does not require calls to queue in the VRU, the CRI is the preferred interface option. Unified CCE looks at the agent states across the
system. Unified CCE then selects the agent to send the call to or translation-routes the call to the Unified IP IVR for queuing.
When the call is sent to an agent or into the queue, the call comes into the PBX from the PSTN on a T1 trunk port and then goes out to a VG on a second T1 trunk port in the PBX. This connection is used for the life of the call.
If you want to track the call from its entry at the PBX or if you want to capture the caller ANI or original dialed number, you can install a PG on the PBX. The PBX can request (through a Post-Route to Unified CCE) which VRU 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 VRU. Unified CCE requires direct DNIS termination to ensure that the translation route maintains the call data collected in the PBX and makes it available to the VRU.
Integration Through PSTN Transfer
This model is similar to the PBX Transfer model. In this model, the VRU invokes a PSTN transfer (instead of a PBX transfer) to release the traditional VRU port. Again, the Unified IP IVR does all queuing to avoid any additional occupancy of the traditional VRU ports and any double trunking in the VRU. Unified CCE passes any call data collected by the traditional VRU application to the agent desktop or Unified IP IVR.
In this model, the TDM VRU is set up as a farm of VRU platforms that have direct PSTN connections for inbound calls. The VRU has a PG connection to Unified CCE which tracks all calls in the system. When a caller opts out of the VRU treatment, the VRU sends a post-route request to Unified CCE. Unified CCE returns a label that directs the call either to an agent or to the Unified IP IVR for queuing.
The label that is returned to the TDM VRU instructs it to send an in-band transfer command using transfer tones (*8 with a destination label in the carrier network). The VRU out-pulses these tones to the service provider with tone generation or plays the tones by using a recorded file.
Integration Through VRU Double Trunking
Some traditional VRU applications have a high success rate where most callers are completely self-served in the traditional VRU and only a small percentage of callers are transferred to an agent. For those cases, you can double-trunk the calls in the traditional
VRU for that small percentage of calls.
Unlike the previous model, if the traditional VRU has a Service Control Interface (SCI), then the initial call queuing is done on the traditional VRU. In this case, VRU double trunking does not use a second traditional VRU port to transfer the call to the
Unified IP IVR. When the traditional VRU does the initial queuing, only one traditional VRU port is used for the call. However, any subsequent queuing because of transfers or RONA treatment must be done on the Unified IP IVR to avoid any double trunking.
If the traditional VRU does not have an SCI interface, then the VRU generates a post-route request to Unified CCE to determine where the call is transferred. All queuing in that scenario happens on the Unified IP IVR.
Figure 9. Traditional VRU Integration Using VRU Double Trunking
In this model, the TDM VRU is set up as a farm of VRU platforms that have direct PSTN connections for inbound calls. The VRU has a PG connection to Unified CCE which tracks all calls in the system. When a caller opts out of the VRU treatment, the VRU sends a post-route request to Unified CCE. Unified CCE
returns a label that either directs the call to an agent or queues the call locally on the TDM VRU using the Service Control Interface (SCI). The TDM VRU does the transfer to the agent by selecting a second port to hairpin the call to the Voice Gateway and to the Unified CCE agent.
The hairpin connection takes up two ports for the time the call is at the agent.
Unified Communications Manager Transfer and VRU Double Trunking
Over time, you can migrate the traditional VRU applications to Unified CVP or Unified IP IVR. If a few traditional VRU applications still exist for specific scenarios, then the VRU can connect to a second Voice Gateway (VG).
The Unified Communications Manager routes calls arriving at the VG from the PSTN. Unified Communications Manager can route specific DNs to the traditional VRU or let Unified CCE, Unified CVP, or Unified IP IVR determine when to transfer calls to the traditional VRU. To transfer calls in the traditional VRU to a Unified CCE agent, use a second VRU port, trunk, and VG port during the call. Ensure that transfer scenarios cannot create multiple loops or voice quality suffers.
Figure 10. Unified Communications Manager Transfer and VRU Double Trunking
In this model, Unified CVP can front end the TDM VRU using the VG to determine where to provide call treatment. Alternately, you can use Unified IP IVR and Unified Communications Manager with Unified CCE for this purpose.
With Unified CVP, calls coming into the VG immediately start a routing dialog with Unified CCE using the Service Control Interface (SCI). Based on the initial dialed number or prompting in Unified CVP, Unified CCE decides to send the call to the TDM VRU or to Unified CVP for a specific
self-service application. If the call was sent to the TDM VRU, the TDM VRU sends a route request to Unified CCE when the caller opts out. The reply is not sent back to the TDM VRU but back to Unified CVP as the original routing
client. Unified CVP then takes the call leg away from the TDM VRU. Unified CVP then transfers the call to the Unified CCE agent over the VoIP network or holds the call in a queue locally in the VG.
With Unified Communications Manager, calls in the VG use a subscriber CTI route point to send a route request to Unified CCE for the proper call treatment device. If the CTI route point indicates an application that still is on the TDM VRU, Unified CCE
instructs the subscriber to transfer the call to the TDM VRU by hairpinning the call using a second T1 port on the VG. Unified CCE can also instruct the subscriber to translation-route the call to the Unified IP IVR for call processing or prompting. Unified CCE can then make a
subsequent transfer to the TDM VRU for further processing. When the caller opts out of the TDM VRU, it sends a post-route request to Unified CCE for a label to the TDM VRU. This label instructs the TDM VRU to transfer the call using a second T1 port on the VRU back to
the VG. The VG transfers the call over to the Unified CCE agent under the Unified Communications Manager dial plan.
In the model controlled by Unified Communications Manager, the VG initially receives calls and sends them to the TDM VRU on a second T1 port. When the VRU returns the call to the Unified CCE agent, it uses a second TDM VRU port and a third port on the VG. All three VG ports are
in use as long as the agent is talking with the caller. Both of the TDM VRU ports are used for the remainder of the call.