The following sections describe the components used in Unified ICM (parent) and Unified CCE (child) deployments.

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

You can deploy parent/child systems on the same AD Domain or Forest, and 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 main site. 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.

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.

The Parent/Child deployment 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 deployment is more tolerant of WAN outages, with each site continuing to operate during an outage. The following figure shows this deployment.

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 deployment. 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 VXML 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 deployments with distributed Unified Communications Manager Peripheral Gateways, the parent/child deployment 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:

• Add new 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 site-by-site basis.

Note

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.

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 sites split critical applications across two sites. Enterprises deploy geographically redundant sites to minimize planned or unplanned downtime and share data across regions.

Geographically redundant sites have a minimum of two load balancers, one in each site. You can use two load balancers for each site for local redundancy.

In a parent/child deployment, the Unified ICM acts as the parent controlling one or more Unified CCE child ACDs. The Unified ICM 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.

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.

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.

Unified ICM perceives calls that need IVR treatment as having two portions: the Switch leg and the VRU leg. The Switch is the entity that first receives the call from the network or caller. The VRU is the entity that plays audio and preforms prompt-and-collect functions. If you use Unified ICM, Unified CVP can participate in the Switch role or the VRU role, or both. In a network deployment, multiple Unified CVP devices provide the Switch and VRU portions independently.

The call delivery to VRU can be based on either a Correlation ID or a translation route ID function, depending on the network capability to pass the call reference identification to the VRU. Call reference identification is needed because Unified ICM has to correlate the two legs of the same call in order to provide instructions for completing the call. In the Unified ICM application, the VRU supplies this call reference ID to Unified ICM when the VRU asks for instructions on how to process the incoming call that it receives from the switch. This method enables Unified ICM to retrieve the appropriate call context for this same call, which at this stage is to proceed to the IVR portion of the call.

• Correlation ID—This method is used if the network can pass the call reference ID to the VRU when the VRU is located in the network with the switch and the call signaling can carry this information (for example, the Correlation ID information is appended to the dialed digits when Unified ICM is used). This function usually applies to calls being transferred within the VoIP network.

• Translation Route ID—This method is used when the VRU is reachable across the PSTN (for example, the VRU is at the customer premise) and the network cannot carry the call reference ID information in delivering the call to the VRU. You must configure a temporary directory number (known as a translation route label) in Unified ICM to reach the VRU, and the network routes the call normally to the VRU as with other directory number routing in the PSTN. When the VRU requests instructions from Unified ICM , the VRU supplies this label (which can be a subset of the received digits), and Unified ICM can correlate the two portions of the same call. Generally, the PSTN carrier contains a set of translation route labels to be used for this purpose.

Note

The deployed VRU can be located in the network (Network VRU) or at the customer premises. At the customer premises, a Network Applications Manager (NAM) is deployed in the network and a Customer ICM (CICM) is deployed at the customer premises. The corresponding Correlation ID or Translation Route ID is used, depending on the location of the VRU.

Unified CVP Type10 VRU simplifies the configuration requirements in Unified CVP Comprehensive Model deployments. Use the Type 10 VRU for new installations except for the VRU-only deployments. In deployments that need to use ICM Customers, you cannot initiate a two-step transfer from the UnifiedCVP VRU switch leg to a completely separate UnifiedCVP (for example, a two-step CVP-to-CVP transfer using SendToVRU). You are require to use a translation route for these two-step transfers to work.

Type 10 Network VRU operates as follows:

• Transferred routing client responsibilities are handed off to the Unified CVP switch leg.

• An automatic transfer to the Unified CVP VRU leg occurs resulting in a second transfer when calls are originated by the VRU, ACD, or Cisco Unified Communications Manager (UnifiedCM).

• For calls originated by Unified CM, the Correlation ID transfer mechanism is used. The Correlation ID is automatically added to the end of the transfer label defined in the Type 10 Network VRU configuration.

• The final transfer to the Unified CVP VRU leg is similar to a Type 7 transfer, which includes a RELEASE message to be sent to the VRU prior to any transfer.

You need to define a single Type 10 Network VRU in Unified CVP implementations without the ICM Customers feature (that is, in UnifiedCVP implementations with a single Network VRU), and associate all UnifiedICM VRU scripts. One label for the UnifiedCVP Switch leg routing client, transfers the call to the Unified CVP VRU leg. If calls are transferred to Unified CVP from Unified CM, another label for the UnifiedCM routing client, and this label should be different from the label used for the CVP Routing Client. This label transfers the call to the Unified CVP Switch leg. The Unified ICM Router sends this label to UnifiedCM with a Correlation ID concatenated to it. You must configure Unified CM to handle these arbitrary extra digits.

Configure the Unified CVP Switch leg peripheral to point to the same Type 10 Network VRU. Also, associate all incoming dialed numbers for calls that are to be transferred to Unified CVP with a Customer Instance that points to the same Type 10 Network VRU.

For calls that originate at a Call Routing Interface VRU or at a TDM ACD, a TranslationRouteToVRU node is required to transfer the call to a Unified CVP’s Switch leg peripheral. For all other calls, use either a SendToVRU node, a node that contains automatic SendToVRU function (such as the queuing nodes), or a RunExternalScript.

Note	Type 5 and Type 2 VRU types are not supported. Instead of these VRU types, use Type 10 VRU.

When the VRU functions as an IVR with the Correlation ID function, Unified ICM uses Type3 and Type7 to designate suboperations of the VRU with the Peripheral Gateway in the Correlation ID scheme. Both Type3 and Type7 VRUs can be reached with the Correlation ID function, and a Peripheral Gateway is needed to control the VRU. However, the difference between these two types is in how they release the VRU leg and how they connect the call to the final destination.

In Type 3, the switch that delivers the call to the VRU can take the call from the VRU and connect it to a destination (or agent).

In Type 7, the switch cannot take the call away from the VRU. When the IVR treatment is complete, Unified ICM must disconnect or release the VRU leg before the final connect message can be sent to the Switch leg to instruct the switch to connect the call to the destination.

When used as an Intelligent Peripheral IVR, Unified CVP supports only Type 7 because it gets a positive indication from Unified ICM when its VRU leg is no longer needed (as opposed to waiting for the Voice Browser to inform it that the call has been pulled away). Type 3 is deprecated.

A call has two legs: the Switch leg and the VRU leg. Different Unified CVP hardware can be used for each leg. A service node along with a Unified CVP for VRU leg with Peripheral Gateway acting as VRU Type 7 can be used to complete the IVR application (for example, self service and queuing).

Note	Use Type 10 VRU for all new implementations of Unified CVP using Unified ICM 7.1 or greater, except as VRU Only.

For configuration examples of the Unified CVP application with VRU Type 7, see the Configuration Guide for Cisco Unified Customer Voice Portalat http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html.

When the VRU functions as an IVR with the Translation Route ID function, Unified ICM uses Type8 or Type10 to designate suboperations of the VRU through the Peripheral Gateway in the translation route scheme. Both Type8 and Type10 VRUs can be reached through the Translation Route ID mechanism, and Peripheral Gateway is needed to control the VRU. However, they differ in how they connect the call to the final destination.

In Type 8, the switch that delivers the call to the VRU can take the call from the VRU and connect it to a destination or agent.

When the switch cannot take the call away from the VRU to deliver it to an agent, use Type 10. In that case, when the IVR treatment is complete, Unified ICM sends the final connect message to the VRU (rather than to the original switch) to connect the call to the destination. The VRU assumes control of the switching responsibilities when it receives the call. This process is known as handoff.

Similar to the Correlation ID, there are two legs of the call: the Switch leg and the VRU leg. Use Unified CVP for either the Switch leg or the VRU leg. For example, when Network Interface Controller (NIC), NAM, or CICM is taken, configure Unified CVP as Type8 or Type10 in the VRU leg.

Note	Use Type 10 VRU for new implementations of Unified CVP using Unified ICM 7.1 or greater, except as VRU Only.

For configuration examples of the Unified CVP application with VRU Type 8 or Type 10, see Configuration Guide for Cisco Unified Customer Voice Portal at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html.

Standalone Self-Service usually does not communicate with Unified ICM VRU scripts, so a Network VRU setting is not required. Standalone Self-Service with Unified ICM Label Lookup does not use the VRU scripts in Unified ICM. It issues a Route Request to the VRU Peripheral Gateway (PG) Routing Client, which does not require this Network VRU.

Unified CCE and Unified CVP are responsible for call switching only. It does not provide queuing or self-service, so there is no VRU leg. A Network VRU setting is not required.

In VRU-Only, the call arrives at Unified ICM through an ICM-NIC interface. Initially, Unified CVP is not responsible for the Switch leg; its only purpose is as a VRU. However, depending on the type of NIC used, it may be required to take over the Switch leg after it receives the call.

The following sections descibe the VRU-Only types.

Unified CVP in a Unified ICM Hosted environment is a self-service or queuing platform on the NAM in the service provider's main site. With CVP, a service provider can:

• Route calls to the appropriate customer-owned ACDs.

• Retain control of calls that are queued for those ACDs.

• Provide either basic prompt-and-collect capability or full-featured self-service applications to their customers.

The last case typically incorporates VXML Servers into the network. You can host the VXML Servers or your customer can host them. Either you or your customers can write and own the self-service applications. Allowing your customer to own or host the VXML Servers is a convenient solution for self-service applications that reference back-end services. This solution allows your customer to retain control of that interaction within its own enterprise network. Your customer only transmits VXML over HTTP to your VXML Gateway.

In many ICM Hosted environments, when the service provider is a PSTN carrier, all of the actual call routing occurs through an ICM NIC. The same situation applies when a PG routes calls using (typically) the ICM NIC. However, the service provider might not have a NIC interface at all. Then, all calls arrive through TDM interfaces, such as T3 or E3. In those cases, CVP handles the Switch and the VRU legs.

In the Unified ICM Hosted environment, CVP connects at the NAM in a valid Network VRU. Some deployments might also require a CVP at the CICM level, instead of or in addition to the NAM level. Consider these guidelines on where to place Unified CVP components:

• When a CVP at the NAM handles both the Switch and VRU legs, use the Correlation ID transfer function. Either the NAM or the CICM routing script can execute the SendToVRU node. (Place the RunExternalScript nodes in the same script that executes the SendToVRU.)

• If a CVP at the NAM handles the VRU leg and a NIC handles the Switch leg, you can use either the Correlation ID or the Translation Route transfer functions. This depends on the capabilities of the NIC. These guidelines also apply:

  • If you use Correlation ID transfer, place the SendToVRU node in either the NAM or the CICM routing script. (Place the RunExternalScript nodes in the same script that executes the SendToVRU.)

  • If you use Translation Route transfer, place the TranslationRouteToVRU node and all RunExternalScript nodes in the NAM routing script. The call is queued (or treated with prompt-and-collect) before selecting a particular CICM. This configuration does not facilitate queuing. However, this configuration enables service providers to offer initial prompt-and-collect before delegating control to the CICM.

• If a CVP at the CICM handles the VRU leg and a NIC handles the Switch leg, you can only use the Translation Route transfer method. Place the TranslationRouteToVRU node and all RunExternalScript nodes in the CICM routing script.

Adding calls initiated by Unified CM or an ACD creates additional constraints. Both of these devices are considered ACDs from the ICM perspective and they connect at the CICM level. For new calls, rather than transfers, the route request comes from the ACD and the resulting label returns to the ACD. Unified CM or an ACD cannot send a Correlation ID upon transfer. You can only use the Translation Route transfer method. This limitation means that the transfer destination connects at the CICM level, and not the NAM level.

For transfers, your customers might want either blind network transfers or warm consultative transfers. The following guidelines apply to these transfers:

• Blind network transfers—If the original call comes to the NAM through a NIC or a CVP Switch leg, the CICM passes the transfer label to the NAM to the original Switch leg device. Blind network transfers have two subcases:

  • If the Switch leg device is CVP or a NIC that can handle Correlation ID, use the Correlation ID transfer function. Place the SendToVRU node and all RunExternalScript nodes in the CICM routing script. Connect the CVP VRU leg to the NAM. This combination of blind transfer with Correlation ID transfer is suitable for CVP.

  • If the Switch leg device is a NIC that cannot handle Correlation ID, use the Translation Route transfer method. Connect the CVP VRU leg device to the CICM.

    Note	In this situation, you need extra dedicated CVP Call Servers at the CICM level because you cannot use the NAM-level CVP Call Servers.

• Warm consultative transfers—CVP supports warm consultative transfers only for Unified CCE agents transferring calls to other Unified CCE agents. For such calls, CVP owns the initial Switch leg for the inbound call. Use the Translation Route transfer method because Unified CM cannot handle Correlation ID transfers. Connect the CVP VRU leg device to the CICM.

  For TDM agents, you use the ACD functions instead of CVP. When the incoming calls to Unified CCE agents arrive through a NIC, use the Unified ICM Network Consultative Transfer facility instead of CVP.

  Note	In this situation, you need extra dedicated CVP Call Servers at the CICM level because you cannot use the NAM-level CVP Call Servers.

In an ICM Hosted environment, there are two types of ICM systems, the NAM and the CICM. You configure Network VRU types differently in the NAM and CICM.

The NAM gets incoming calls either from the NIC or from Unified CVP, and is aware of the Unified CVP VRU leg device. Configure the NAM Network VRU types exactly as an independent ICM, operating with those devices. You can ignore that the transfer labels sometimes come from CICM when configuring Network VRU types. The CICM sees incoming calls that arrive from the Intelligent Network Call Routing Protocol (INCRP) NIC.

Associate the dialed numbers that arrive from the NAM with a Customer Instance for the corresponding Network VRU on a CICM. Associate that Network VRU with all VRU scripts. Provide the same label that you need in the NAM Network VRU definition, but with the INCRP NIC as its routing client. No peripherals have Network VRUs configured.

For more information on Network VRU Type support, see the Configuration Guide for Cisco Unified Customer Voice Portal at http://www.cisco.com/c/en/us/support/customer-collaboration/unified-customer-voice-portal/products-installation-and-configuration-guides-list.html.

Takeback-and-Transfer (TNT), also known as Transfer Connect, is a transfer method where dual tone multifrequency (DTMF) tones are outpulsed to the PSTN by Unified CVP. TNT outpulses DTMF tones to the PSTN. A typical DTMF sequence is *8xxxx, where xxxx represents a new routing label for the PSTN. Upon detection of a TNT DTMF sequence, the PSTN drops the call leg to the Ingress Gateway port, and then reroutes the caller to a new PSTN location, such as a TDM ACD location. This method is offered by a few PSTN service providers.

Customers can use TNT, if they have an existing ACD site but no IVR and want to use Unified CVP as an IVR. Over time, customers may need to transition agents from the TDM ACD to Unified CCE and use Unified CVP as an IVR, queueing point, and transfer pivot point. Using Unified CVP as more than just an IVR eliminates the need for TNT services.

In Unified CVP deployments with Unified ICM, the DTMF routing label that is outpulsed can be a Unified ICM translation routing label to enable passing of call data to another Unified ICM peripheral, such as a TDM ACD. In this scenario, Unified CVP views the call as completed, and Unified CVP call control is ended. With TNT, if the transfer to the termination point fails, Unified CVP cannot reroute the call. Using some TNT services, you can reroute the callback to Unified CVP. However, Unified CVP treats this call as a new call.

Two B Channel Transfer (TBCT) is an Integrated Services Digital Network (ISDN)-based release trunk signaling function that is offered by some public switched telephone network (PSTN) service providers. When a TBCT is invoked, the Ingress Gateway places the initial inbound call on hold briefly while a second call leg (ISDN B Channel) is used to call the termination point. When the termination point answers the call, the gateway sends ISDN signaling to the PSTN switch to request to complete the transfer, bridge the call through the PSTN switch, and remove the call from the Ingress Gateway. As with a TNT transfer, the termination point might be a TDM PBX or ACD connected to the PSTN.

This process may be necessary for a customer with an existing ACD site but no IVR, who wants to use Unified CVP initially as just an IVR. Over time, the customer might want to transition agents from the TDM ACD to Cisco Unified CCE and use Unified CVP as an IVR, queueing point, and transfer pivot point (which eliminates the need for TBCT services and using Unified CVP to perform reroute on transfer failure).

Standalone Self-Service does not involve Unified ICM. It is implemented when a UnifiedCM user dials a directory number that connects to a VXML Gateway and invokes a Unified CVP VXMLServer application. The VXML Gateway is configured in UnifiedCM as a SIP trunk. The call flow is as follows:

1. A caller dials a route pattern.

2. UnifiedCM directs the call to the VXML Gateway.

3. The VXML Gateway invokes a voice browser session based on the configured Unified CVP self-service application.

4. The Unified CVP self-service application makes an HTTP request to the UnifiedCVP VXMLServer.

5. The UnifiedCVP VXMLServer starts a self-service application.

6. The UnifiedCVP VXMLServer and VXML Gateway exchange HTTP requests and VXML responses.

7. The caller hangs up.

Call Director has only switching and has no VRU leg. Calls originated by UnifiedCM are always delivered directly to their targets or rejected. No queuing or self-service is involved.

Call Director assumes that the call is truly originating from UnifiedCM. It excludes calls that originally arrived through a Ingress VXML Gateway and were transferred to UnifiedCM, and are now transferred again. These situations are rare because UnifiedCM can usually handle those transfers itself. There are exceptions, however, such as when the target is an ACD other than UnifiedCM.

Call Director requires the following items are configured:

• UnifiedCM route point that invokes a Unified CCE script

• Unified CVP configured as a Type 10 NetworkVRU

• VRU translation routes to Unified CVP

• Translation route Dialed Number Identification Service (DNIS) numbers configured in the Unified CVP Call Server

• UnifiedCM configured with a SIP trunk

• UnifiedCM route patterns for Translation Route DNIS

The call flow is as follows:

1. A caller dials a route point.

2. Unified ICM invokes a routing script.

3. The routing script encounters a TranslationRouteToVRU node to transfer the call to Unified CVP. (Unified CVP is configured as a Type 10 NetworkVRU.)

4. Unified ICM returns the translation route label to UnifiedCM.

5. UnifiedCM consults the SIP Proxy to locate the Unified CVP Call Server.

6. UnifiedCM connects the call to the Unified CVP Call Server.

7. The routing script encounters a Select or Label node, and it selects a target label.

8. Unified ICM returns the target label to the Unified CVP Call Server (not to the device that issued the route request).

9. The Unified CVP Call Server consults the SIP Proxy to locate the destination device.

10. The Unified CVP Call Server communicates through SIP with the target device and instructs UnifiedCM to establish a media stream to it.

    If the target device issues another route request to Unified ICM. This part of the call flow is not possible without the initial TranslationRouteToVRU mentioned in Step3.

11. Unified ICM invokes a new routing script.

12. The routing script encounters a Select or Label node, and it selects a target label.

13. Unified ICM returns the target label to the Unified CVP Call Server (not to the device that issued the route request).

14. The Unified CVP Call Server consults the SIP Proxy to locate the destination device.

15. The Unified CVP Call Server communicates using SIP with the target device and instructs UnifiedCM to establish a media stream to the device.

The VXML Server (standalone) functional deployment provides organizations with a standalone IVR solution for automated self-service. Callers can access Unified CVP from a local, long-distance, or toll-free numbers that terminate at Unified CVP Ingress Voice Gateways. Callers can also access Unified CVP from VoIP endpoints number that terminates at Unified CVP Ingress Voice Gateways. Callers can also access Unified CVP from VoIP endpoints. The following figure illustrates this deployment.

This deployment includes the following components:

• Ingress Voice Gateway

• Virtualized Voice Browser/VXML Gateway

• VXML Server

• Unified Call Studio

• Operations Console Server

Following are the optional components of this deployment:

• Automatic Speech Recognition/Text-to-Speech (ASR/TTS) Server

• Third-Party Media Server

• Egress Voice Gateway

• Reporting Server

• CVP Call Server

• ICM

• Cisco Unified Communications Manager

The Call Director deployment provides an organization with a method to route and transfer calls across a VoIP network. For example, organizations can use this deployment with multiple TDM ACD and TDM IVR locations that are integrated with Unified ICM through an ACD or IVR Peripheral Gateway. The organization wants to use the Cisco Unified Intelligent Contact Management (Unified ICM) to route and transfer calls intelligently across these locations without using PSTN prerouting or Release Trunk Transfer services. In this deployment, Unified CVP and Unified ICM can also pass call data between these ACD and IVR locations. Unified ICM can also provide beginning-to-end reporting for all calls.

The Call Director is often the first step in the migration from a TDM-based contact center to a VoIP-based contact center. When an organization is ready to implement CVP-based IVR services and Cisco Unified Contact Center Enterprise (Unified CCE), the organization can migrate their Unified CVP deployment to the Comprehensive functional deployment.

Callers can access Unified CVP from local, long-distance, or toll-free numbers that terminate at Unified CVP Ingress Voice Gateways. Callers can also access Unified CVP from VoIP endpoints.

Following are the required components of this Call Director deployment:

• Ingress Voice Gateway

• Egress Voice Gateway

• CVPServer

• Operations Console Server

• Cisco Unified ICM Enterprise

• SIP Proxy Server (for SIP deployments)

The reporting server is an optional component of this model because there is very little call information stored in the UnifiedCVP reporting database.

The VRU-Only functional deployment provides self-service applications and queueing treatment for organizations that use advanced PSTN switching services that are controlled using a Cisco Unified ICM PSTN Network Interface Controller (NIC). Two Unified ICM PSTN NICs allow subsequent call control of calls in the PSTN: the NIC and the Carrier Routing Service Protocol (CRSP) NIC. These NICs allow Unified ICM to route calls intelligently to Unified ICM peripherals, such as ACDs and IVRs. They also allow Unified ICM to invoke mid-call transfers in the PSTN. The following figure illustrates this model.

In the VRU-Only functional deployment:

• Unified ICM routes a call before it is routed to another calls to Ingress Voice Gateway for call treatment and queuing. When an agent becomes available, Unified ICM instructs the PSTN to transfer the call to that agent. The agents can be Cisco Unified Contact Center Enterprise agents, Cisco Unified Contact Center Express agents, or ACD agents. If necessary, Unified ICM can request the PSTN (using the NIC) to transfer the call, just as Unified ICM can request Unified CVP to transfer the call.

• Ingress Voice Gateway is a Unified ICM-managed PSTN termination point that provides VRU services using a VXML Gateway, the VXML server, the ICM Service, and Unified ICM.

• The SIP Service is not used for call control. All call control and switching is controlled by Unified ICM and the PSTN.

• Unified ICM can pass call data between these termination points (for a pop-up window or other intelligent treatment) and provide reporting for all calls.

Following are the required components of this deployment:

• Ingress Voice Gateway

• VXML Gateway

• CVP Server

• Unified Call Studio

• Cisco Unified ICM Enterprise and NIC (CRSP)

Following are the optional components of this deployment:

• ASR/TTS Server

• Third-Party Media Server

• SIP Proxy Server (for SIP deployments)

• Reporting Server

Each Agent PG can support only one CTI Manager connection. While each subscriber has a CTI Manager, only two subscribers normally connect to the Agent PGs. You would have to add another pair of Agent PGs to enable all subscribers in a four-subscriber cluster to connect directly to an Agent PG.

The following figure shows the failure of a CTI Manager with a connection to the Agent PG. Only subscribers C and D are configured to connect to the Agent PGs.

The following conditions apply to this scenario:

• For redundancy, all phones and gateways that are registered with subscriber A use subscriber B as their backup server.

• The CTI Managers on subscribers C and D provide JTAPI services for the Agent PGs.

Unlike Unified CVP, Unified IP IVR depends on the CTI Manager for call control. In Unified IP IVR deployments, failure of a CTI Manager with an Agent PG connection causes the Unified IP IVR JTAPI subsystem to shut down. This shutdown causes the Unified IP IVR server to drop all voice calls that the server is processing.

Then, the JTAPI subsystem restarts and connects to the CTI Manager on the backup subscriber. The Unified IP IVR reregisters all the CTI ports that are associated with the Unified IP IVR JTAPI user. After all the Unified CM devices are successfully registered, the server resumes its VRU functions and handles new calls.

Cisco Unified IP IVR can establish JTAPI connections with two CTI Managers on different subscribers in the Unified Communications Manager cluster. This feature enables Unified IP IVR redundancy at the CTI Manager level. You can gain more redundancy by deploying multiple Unified IP IVR servers. Multiple Unified IP IVR servers enable call routing scripts to load balance calls between the available IP IVR resources.

The following figure shows two Unified IP IVR servers set up redundantly with a cluster. Set up the Unified IP IVR group with each server connected to the CTI Manager on a different Unified Communications Manager subscriber. Then, add a second CTI Manager as a backup to each Unified IP IVR server. If the primary CTI Manager fails, the Unified IP IVR server fails over to the backup CTI Manager.

When you use Unified IP IVR with Outbound Option, front-end all calls through Unified CM. This deployment results in a higher call load on the subscribers. Because the subscriber supports only five calls per second, distribute calls that are transferred to agents and the VRU across multiple subscribers with a Unified SIP Proxy server.

For some deployments, if the outbound call center is in one country (for example, India) and the customers are in another country (for example, US), then consider the WAN network structure. When using Unified IP IVR deployments for transfer to a VRU campaign, and the Unified IP IVR is separated from the Outbound Option Dialer servers by a WAN. Provide Unified IP IVR with its own Unified CM cluster to reduce the WAN traffic.

Distributed Deployment of Outbound Option for Transfer to VRU Campaign

This figure shows a distributed deployment for a transfer-to-VRU campaign with Unified IP IVR.

In the solution in this figure, note these points:

• The Voice Gateway and Router/Logger A servers are distributed between two sites (Site 1 and 3) in the United States.

• The Unified CM cluster is located at Site 3 (United States) along with the VRU PG.

• The redundant VRU PGs are at Site 3 (United States).

• IP IVR is included at Site 3 (United States).

• The redundant MRPG/Dialer and redundant Agent PGs are installed on the same VM at Site 2.

• The SIP Dialer uses the Voice Gateways located at Site 3 (United States).

• The Voice Gateways are included in the diagram with CT3 interface at Site 3 (United States). These routers will provide 1:1 redundancy for Dialer calls.

• The redundant Unified SIP Proxy servers are at Site 2 to avoid the WAN SIP signaling traffic to transfer live outbound calls.

• Each SIP Dialer connects to its own Unified SIP Proxy server at Site 2. Each Unified SIP Proxy server controls the set of Voice Gateways at Site 3 (United States).

• The Unified SIP Proxy servers provide (N+1) redundancy.

If you enable recording at the SIP Dialer, the WAN bandwidth requirements are:

• Bandwidth for each answered outbound call:

  • G.711 Codec calls require a WAN bandwidth of 80 kbps for the Call Progress Analysis time period.

  • G.729 Codec calls require a WAN bandwidth of 26 kbps for the Call Progress Analysis time period.

• Bandwidth for each alerting outbound calls:

  • G.711 Codec calls require a WAN bandwidth of 80 kbps

  • G.729 Codec calls require a WAN bandwidth of 26 kbps

• Outbound calls being queued for self-serviced at Unified IP IVR do not require WAN bandwidth.

• With Cisco Unified ICM7.0, to perform subsequent call control through Unified CVP, always use translation route to route the call to Unified CVP as a Type 2 NetworkVRU before delivering the call to its next destination. This practice passes the control to Unified CVP as an charge of subsequent call transfers because UnifiedCM cannot receive any further labels.

• To perform any queuing treatment, prompt and collect, or self-service applications, always follow translation route with a SendToVRU node. SendToVRU can sometimes be invoked implicitly by a Queue node or a RunExternalScript node, but you should not rely on that method. Always include an actual SendToVRU node.

• With Cisco Unified ICM7.1, to perform subsequent call control through Unified CVP, a translation route is not necessary if you use a Type 10 NetworkVRU. The Type 10 VRU uses the Correlation ID method to perform a transfer from UnifiedCM to Unified CVP using a SendToVRU node. When the SendToVRU node is used with a Type 10 VRU, an initial transfer to Unified CVP hands off call control to Unified CVP, and then an automatic second transfer to the VRU leg is performed to deliver the call to a Voice Browser for VRU treatment.

  Note	This call flow and all others in this document assume that you are using Cisco Unified ICM7.0(0) or later.

• When the SendToVRU node is used with a Type 10 VRU, an initial transfer to Unified CVP hands off call control to Unified CVP, and then an automatic second transfer to the VRU leg is performed to deliver the call to a Voice Browser for VRU treatment.