Cisco Unified Customer Voice Portal (CVP) 7.x Solution Reference Network Design (SRND)
Interactions with Cisco Unified ICM
Downloads: This chapterpdf (PDF - 454.0KB) The complete bookPDF (PDF - 3.14MB) | Feedback

Interactions with Cisco Unified ICM

Table Of Contents

Interactions with Cisco Unified ICM

What's New in This Chapter

Network VRU Types

Overview of Unified ICM Network VRUs

Unified CVP as a Type 10 VRU

Unified CVP as Type 5 VRU

Unified CVP as Type 3 or 7 VRU (Correlation ID Mechanism)

Unified CVP as Type 8 or 2 VRU (Translation Route ID Mechanism)

Network VRU Types and Unified CVP Deployment Models

Model #1: Standalone Self-Service

Model #2: Call Director

Model #3a: Comprehensive Using ICM Micro-Apps

Model #3b: Comprehensive Using Unified CVP VXML Server

Model #4: VRU Only

Model #4a: VRU Only with NIC Controlled Routing

Model #4b: VRU Only with NIC Controlled Pre-Routing

Hosted Implementations

Overview of Hosted Implementations

Using Unified CVP in Hosted Environments

Unified CVP Placement and Call Routing in a Hosted Environment

Network VRU Type in a Hosted Environment

Deployment Models and Sizing Implications for Calls Originated by Cisco Unified Communications Manager and ACDs

Using Third-Party VRUs


Interactions with Cisco Unified ICM


Last revised on: April 22, 2009

 

This chapter discusses Cisco Unified Intelligent Contact Management (ICM) from the perspective of its relationship with Unified CVP. In some cases, the choice of deployment model has implications for Unified ICM; and in other cases, certain choices about the Unified ICM configuration carry implications for the Unified CVP deployment.

This chapter covers the following topics:

Network VRU Types

Network VRU Types and Unified CVP Deployment Models

Hosted Implementations

Deployment Models and Sizing Implications for Calls Originated by Cisco Unified Communications Manager and ACDs

Using Third-Party VRUs

What's New in This Chapter

Table 5-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.

 

Table 5-1 New or Changed Information Since the Previous Release of This Document 

New or Revised Topic
Described in:

Type 10 VRU

Unified CVP as a Type 10 VRU


Network VRU Types

This section first discusses Network VRU types for Unified ICM in general, then it discusses them as they relate to Unified CVP deployments in particular.

This section covers the following topics:

Overview of Unified ICM Network VRUs

Unified CVP as a Type 10 VRU

Unified CVP as Type 5 VRU

Unified CVP as Type 3 or 7 VRU (Correlation ID Mechanism)

Unified CVP as Type 8 or 2 VRU (Translation Route ID Mechanism)

In this document, the terms voice response unit (VRU) and interactive voice response (IVR) are used interchangeably.

Overview of Unified ICM Network VRUs

This section describes the types of Unified ICM VRUs used for Unified CVP applications. 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. Unified CVP can participate in the Switch role or the VRU role, or both, from the perspective of Unified ICM. In a network deployment, multiple Unified CVP devices can also be deployed to provide the Switch and VRU portions independently.

The call delivery to VRU can be based on either a Correlation ID or a translation route mechanism, 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 has to supply 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 mechanism 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. These two correlation mechanisms operate as follows:

Correlation ID

This mechanism is used if the network can pass the call reference ID to the VRU, which is usually the case 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 mechanism usually applies to calls being transferred within the VoIP network.

Translation Route ID

This mechanism 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. A temporary directory number (known as a translation route label) has to be configured 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 asks for instructions from Unified ICM, the VRU supplies this label (which could be a subset of the received digits) and Unified ICM can correlate the two portions of the same call. Normally the PSTN carrier will provision 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. In the latter scenario, a Network Applications Manager (NAM) would be deployed in the network and a Customer ICM (CICM) would be deployed at the customer premises. The corresponding Correlation ID or Translation Route ID should be used accordingly, as described earlier, depending on the location of the VRU.


Unified CVP as a Type 10 VRU

Type 10 was designed to simplify the configuration requirements in Unified CVP Comprehensive Model deployments. The Type 10 VRU is the preferred VRU Type for all new installations, but it requires Cisco Unified ICM 7.1 or later releases. Unified ICM 7.0 deployments should use the VRU types outlined in subsequent sections of this chapter. Prior to Unified ICM 7.5(3), the Type 10 VRU did not support ICM Customers, which is a Unified ICM feature that allows you to have multiple Network VRUs and is typically used in Hosted deployments. Deployments that need to use ICM Customers can use the other VRU types outlined below, or they can use Unified ICM 7.5(3) or later releases. Although ICM Customers are now supported, one cannot initiate a two-step transfer from the Unified CVP VRU switch leg to a completely separate Unified CVP (for example, a two-steps CVP-to-CVP transfer using SendToVRU). A translation route would have to be used in order for such a two-step transfers to work.

Type 10 Network VRU has the following behavior:

There is a Handoff of routing client responsibilities to the Unified CVP switch leg.

There is an automatic transfer to the Unified CVP VRU leg, resulting in a second transfer in the case of calls originated by the VRU, ACD, or Cisco Unified Communications Manager (Unified CM).

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, in that a RELEASE message is sent to the VRU prior to any transfer.

In Unified CVP implementations without the ICM Customers feature (that is, in Unified CVP implementations with a single Network VRU), a single Type 10 Network VRU should be defined, and all Unified ICM VRU scripts should be associated with it. It requires one label for the Unified CVP Switch leg routing client, which will transfer the call to the Unified CVP VRU leg. If calls will be transferred to Unified CVP from Unified CM, it also needs another label for the Unified CM routing client, and this label should be different from the label used for the CVP Routing Client. This label will transfer the call to the Unified CVP Switch leg. The Unified ICM Router will send this label to Unified CM with a Correlation ID concatenated to it. Unified CM must be configured to handle these arbitrary extra digits.

The Unified CVP Switch leg peripheral should be configured to point to the same Type 10 Network VRU. Also, all incoming dialed numbers for calls that are to be transferred to Unified CVP should be associated 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 should be used to transfer the call to Unified CVP's Switch leg peripheral. For all other calls, use either a SendToVRU node, a node that contains automatic SendToVRU behavior (such as the queuing nodes), or a RunExternalScript.

Unified CVP as Type 5 VRU


Note Cisco Unified ICM 7.1 introduces the Type10 Network VRU. This VRU should be used for all new implementations of Unified CVP using Unified ICM 7.1 or greater. The Type5 VRU can still be used for existing customer deployments that have upgraded or for deployments that are not running Unified ICM 7.1 or later.


Type 5 and Type 6 are similar in the sense that the VRU entity functions both as a switch (call control) and as the VRU (IVR). However, they differ on how to connect to the VRU.

In Type 6, the Switch and the VRU are the same device, therefore the call is already at the VRU. No Connect and Request Instructions message sequence is needed from the point of view of Unified ICM.

On the other hand, in Type 5, the Switch and the VRU are different devices even though they are in the same service node from the viewpoint of Unified ICM (that is, they both interact with Unified ICM through the same PG interface). Therefore, Unified ICM uses a Connect and Request Instructions sequence to complete the IVR call.


Note In a Unified CVP application, there are two legs of the call as perceived by Unified ICM: the Switch leg and the VRU leg. In the case where Unified CVP acts as the service node application (that is, when Unified CVP receives the call from the network directly and not via pre-routing), Unified CVP will appear to Unified ICM as Type 5 because the call control (Unified CVP) and the VRU device are different. Hence, Unified CVP must be configured as VRU Type 5 in the Unified ICM and NAM configuration for the Switch leg. The VRU leg requires a different setup, depending on the deployment model (for example, the VRU leg could be Type 7 in the Comprehensive Unified ICM enterprise deployment model). For examples of configuring Unified CVP as Type 5, refer to the latest version of the Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP), available at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html.


Neither Correlation ID nor Translation Route ID is needed when Unified CVP acts as a Type 5 VRU to Unified ICM and the NAM. However, a dummy label is sometimes required.

Unified CVP as Type 3 or 7 VRU (Correlation ID Mechanism)


Note Cisco Unified ICM 7.1 introduces the Type10 Network VRU. This VRU should be used for all new implementations of Unified CVP using Unified ICM 7.1 or greater, except as VRU Only (Model #4a, described below). The Type 3 or 7 VRU can still be used for existing customer deployments that have upgraded or for deployments that are not running Unified ICM 7.1 or later.


When the VRU functions as an IVR with the Correlation ID mechanism, Unified ICM uses Type 3 and Type 7 to designate sub-behaviors of the VRU via the PG in the Correlation ID scheme. Both Type 3 and Type 7 VRUs can be reached via the Correlation ID mechanism, and a PG 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 can function with either Type 3 or 7, but it is somewhat more efficient under 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 VoiceXML gateway to inform it that the call has been pulled away).

As stated previously, there are two legs of the call: the Switch leg and the VRU leg. Different Unified CVP hardware can be used for each leg, but from the perspective of Unified ICM functionality, there will be a Unified CVP via PG acting as VRU Type 5 (that is, a service node) along with potentially a different Unified CVP via another PG acting as VRU Type 7 to complete the IVR application (self service, queuing, and so forth).

For configuration examples of the Unified CVP application with VRU Type 3 or Type 7, refer to the latest version of the Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP), available at

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

Unified CVP as Type 8 or 2 VRU (Translation Route ID Mechanism)


Note Cisco Unified ICM 7.1 introduces the Type10 Network VRU. This VRU should be used for all new implementations of Unified CVP using Unified ICM 7.1 or greater, except as VRU Only (Model #4a, described below). The Type 8 or 2 VRU can still be used for existing customer deployments that have upgraded or for deployments that are not running Unified ICM 7.1 or later.


When the VRU functions as an IVR with the Translation Route ID mechanism, Unified ICM uses Type 8 or Type 2 to designate sub-behaviors of the VRU via the PG in the translation route scheme. Both Type 2 and Type 8 VRUs can be reached via the Translation Route mechanism, and PG 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/agent.

Type 2 is used when the switch does not have the ability to take the call away from the VRU to deliver it to an agent. 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 effectively assumes control of the switching responsibilities when it receives the call. This process is known as a handoff.

Similarly to the Correlation ID case, there are two legs of the call: the Switch leg and the VRU leg. Unified CVP can be used for either the Switch leg or the VRU leg. For example, when a Network Interface Controller (NIC), NAM, or CICM is involved, Unified CVP should be configured as Type 2 or Type 8 in the VRU leg.

For configuration examples of the Unified CVP application with VRU Type 8 or Type 2, refer to the latest version of the Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP), available at

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

Network VRU Types and Unified CVP Deployment Models

This section describes how Network VRU types relate to the Unified CVP deployment models described the chapter on Functional Deployment Models, page 2-1. This section covers the following topics:

Model #1: Standalone Self-Service

Model #2: Call Director

Model #3a: Comprehensive Using ICM Micro-Apps

Model #3b: Comprehensive Using Unified CVP VXML Server

Model #4: VRU Only

Model #4a: VRU Only with NIC Controlled Routing

Model #4b: VRU Only with NIC Controlled Pre-Routing

In Unified ICM, a Network VRU is a configuration database entity. It is accessed using the Network VRU Explorer. A Network VRU entry contains the following pieces of information:

Type — A number from 2 to 10, which corresponds to one of the types described previously.

Labels — A list of labels that Unified ICM can use to transfer a call to the particular Network VRU being configured. These labels are relevant only for Network VRUs of Type 3, 7, or 10 (that is, those VRU types that use the Correlation ID mechanism to transfer calls), and they are required but never used in the case of Type 5. Each label consists of two parts:

A digit string, which becomes a DNIS that can be understood by the gatekeeper (when H.323 is used), by a SIP Proxy Server or a static route table (when SIP is used), or by gateway dial peers.

A routing client, or switch leg peripheral. In other words, each peripheral device that can act as a Switch leg must have its own label, even though the digit strings will likely be the same in all cases.

Network VRU configuration entries themselves have no value until they are associated with active calls. There are three places in Unified ICM where this association is made:

Under the Advanced tab for a given peripheral in the PG Explorer tool

In the Customer Instance configuration in the Unified ICM Instance Explorer tool

In every VRU Script configuration in the VRU Script List tool

Depending on the protocol-level call flow, Unified ICM Enterprise looks at either the peripheral or the Customer Instance to determine how to transfer a call to a VRU. Generally speaking, Unified ICM Enterprise examines the Network VRU that is associated with the Switch leg peripheral when the call first arrives on a Switch leg, and the Network VRU that is associated with the VRU leg peripheral when the call is being transferred to the VRU using the Translation Route mechanism. It examines the Network VRU that is associated with the Customer Instance when the call is being transferred to the VRU using the Correlation ID mechanism.

Unified ICM Enterprise also examines the Network VRU that is associated with the VRU Script every time it encounters a RunExternalScript node in its routing script. If Unified ICM does not believe the call is currently connected to the designated Network VRU, it will not execute the VRU Script.

Unified ICM Enterprise Release 7.1 introduced Network VRU Type 10, which simplifies the configuration of Network VRUs for Unified CVP. For most call flow models, a single Type 10 Network VRU can take the place of the Type 2, 3, 7, or 8 Network VRUs that were associated with the Customer Instance and/or the switch and VRU leg peripherals. The only major call flow model that still requires Type 7 or 8 is VRU Only (Model #4a, described below).

Note that the previously recommended VRU types still work as before, even in Unified ICM Enterprise 7.1. New installations should use Type 10 if possible, and existing installations may optionally switch to Type 10.

Model #1: Standalone Self-Service

The Standalone Self-Service model typically does not interface with Unified ICM VRU scripts, so a Network VRU setting is not relevant. The Standalone Self-Service model with Unified ICM Label Lookup does not use the VRU scripts in Unified ICM; it simply issues a Route Request to the VRU PG Routing Client, therefore a Network VRU is not needed.

Model #2: Call Director

In this model, Unified ICM (and therefore Unified CVP) is responsible for call switching only. It does not provide queuing or self-service, so there is no VRU leg. Therefore, a Network VRU setting is not required in this case.

Model #3a: Comprehensive Using ICM Micro-Apps

In this model, Unified CVP devices act as both the Switch and the VRU leg, but the call does need to be transferred from the Switch leg to the VRU leg before any call treatment (playing .wav files or accepting user input) can take place. Associate all Unified CVP peripherals with a Type 10 Network VRU in this case.


Note Type10 is available only in Unified ICM 7.1 and later, and new implementations should use this configuration. For Unified ICM 7.0, a Type 2 Network VRU should be used in this case.


Associate all incoming dialed numbers with a Customer Instance that is associated with a Type 10 Network VRU. All the VRU Scripts that will be executed by this call must be associated with the same Type 10 Network VRU. Although it is not always necessary, the best practice is for the Unified ICM routing script to execute a SendToVRU node prior to the first RunExternalScript node.


Note Type10 is available only in Unified ICM 7.1 and later, and new implementations should use this configuration. For Unified ICM 7.0, a Type 7 should be used in this case.


Model #3b: Comprehensive Using Unified CVP VXML Server

From the perspective of call routing and the Network VRU, this model is identical to Model #3a, described above.

Model #4: VRU Only

In this model, the call first arrives at Unified ICM through an ICM-NIC interface, not through Unified CVP. At least initially, Unified CVP is not responsible for the Switch leg; its only purpose is as a VRU. However, depending on which kind of NIC is used, it might be required to take over the Switch leg once it receives the call. This model actually has two submodels, which we are described separately in the following sections.

Model #4a: VRU Only with NIC Controlled Routing

This submodel assumes a fully functional NIC that is capable of delivering the call temporarily to a Network VRU (that is, to Unified CVP's VRU leg) and then retrieving the call and delivering it to an agent when that agent is available. It further assumes that, if the agent is capable of requesting that the call be re-transferred to another agent or back into queue or self-service, the NIC is capable of retrieving the call from the agent and re-delivering it as requested.

There are two variants of this submodel, depending on whether the Correlation ID or the Translation Route mechanism is used to transfer calls to the VRU. Most NICs (actually, most PSTN networks) are not capable of transferring a call to a particular destination directory number and carrying an arbitrary Correlation ID along with it, which the destination device can pass back to Unified ICM in order to make the Correlation ID transfer mechanism function properly. For most NICs, therefore, the Translation Route mechanism must be used.

There are a few exceptions to this rule, however, in which case the Correlation ID mechanism can be used. The NICs that are capable of transmitting a Correlation ID include Call Routing Service Protocol (CRSP), SS7 Intelligent Network (SS7IN), and Telecom Italia Mobile (TIM). However, because this capability also depends on the PSTN devices that connect behind the NIC, check with your PSTN carrier to determine whether the Correlation ID can be passed through to the destination.

If the NIC is capable of transmitting the Correlation ID, the incoming dialed numbers must all be associated with a Customer Instance that is associated with a Type 7 Network VRU. The Type 7 Network VRU must contain labels that are associated to the NIC routing client, and all the VRU Scripts must also be associated with that same Type 7 Network VRU. The peripherals need not be associated with any Network VRU. Although it is not always necessary, the best practice is for the Unified ICM routing script to execute a SendToVRU node prior to the first RunExternalScript node.

If the NIC is not capable of transmitting a Correlation ID (the usual and safe case), then the incoming dialed numbers must all be associated with a Customer Instance that is not associated with any Network VRU. The Unified CVP peripherals must, however, be associated with a Network VRU of Type 8, and all the VRU Scripts must also be associated with that same Type 8 Network VRU. In this case it is always necessary to insert a TranslationRouteToVRU node in the routing script prior to the first RunExternalScript node. If the call is going to the VRU leg because it is being queued, generally the TranslationRouteToVRU node should appear after the Queue node. In that way, an unnecessary delivery and removal from Unified CVP can be avoided when the requested agent is already available.

Model #4b: VRU Only with NIC Controlled Pre-Routing

This submodel assumes a less capable NIC that can deliver the call only once, whether to a VRU or to an agent. Once the call is delivered, the NIC cannot be instructed to retrieve the call and re-deliver it somewhere else. In these cases, Unified CVP can take control of the switching responsibilities for the call. From the perspective of Unified ICM, this process is known as a handoff.

Calls that fit this particular submodel must use the Translation Route mechanism to transfer calls to the VRU. There is no way to implement a handoff using the Correlation ID mechanism.

To implement this model with Unified ICM 7.1, the incoming dialed numbers must all be associated with a Customer Instance that is associated with a Type 10 Network VRU. The VRU labels are associated with the Unified CVP routing client, not the NIC. The Unified CVP peripherals and VRU Scripts must be associated with the Type 10 Network VRU. In this case, it is always necessary to insert a TranslationRouteToVRU node in the routing script, followed by a SendToVRU node, prior to the first RunExternalScript node. If the call is going to the VRU leg because it is being queued, generally these two nodes should appear after the Queue node. In that way, an unnecessary delivery and removal from Unified CVP can be avoided if the requested agent is already available.

To implement this model with Unified ICM 7.0, the incoming dialed numbers must all be associated with a Customer Instance that is associated with a Type 7 Network VRU. The VRU labels are associated with the Unified CVP routing client, not the NIC. The Unified CVP peripherals must be associated with a Network VRU of Type 2, but all the VRU Scripts must be associated with the Type 7 Network VRU. In this case, it is always necessary to insert a TranslationRouteToVRU node in the routing script, followed by a SendToVRU node, prior to the first RunExternalScript node. If the call is going to the VRU leg because it is being queued, generally these two nodes should appear after the Queue node. In that way, an unnecessary delivery and removal from Unified CVP can be avoided if the requested agent is already available.


Note Two different VRU transfer nodes are required. The first one transfers the call away from the NIC with a handoff, and it establishes Unified CVP as a Switch leg device for this call. Physically the call is delivered to an ingress gateway. The second transfer delivers the call to the VoiceXML gateway and establishes Unified CVP as the call's VRU device as well.


Hosted Implementations

This section covers the following topics:

Overview of Hosted Implementations

Using Unified CVP in Hosted Environments

Unified CVP Placement and Call Routing in a Hosted Environment

Network VRU Type in a Hosted Environment

Overview of Hosted Implementations

Hosted implementations incorporate a two-level hierarchy of Unified ICM systems. The Network Application Manager (NAM) sits at the top level, and one or more Customer ICMs (CICMs) sit below it. Both the NAM and CICM are really complete ICMs in and of themselves, with a communication link between them known as Intelligent Network Call Routing Protocol (INCRP). Each CICM acts in an isolated fashion; it is not aware of the other CICMs, nor is it aware that the NAM is itself another ICM. It has no connection to the other CICMs, but its connection to the NAM is through a NIC - specifically, the INCRP NIC.

Traditionally, customers implement Hosted setups because they are service providers. They want to provide ICM contact center services to multiple customers of their own. Each customer is hosted on its own CICM, and the NAM is responsible for routing calls, which are delivered to the service provider, to the appropriate customer's CICM. The individual customers run their own contact centers with their own ACDs connected to PGs at their own premises. The PGs, in turn, are connected to their assigned CICMs at the service provider. Thus, the service provider owns and hosts the NAM and all the CICMs, but all the ACDs are owned and hosted by the individual customers. The PGs for those ACDs are owned by the service provider but are located at the customer's premises, next to the ACDs. The service provider itself does not necessarily operate any ACDs of its own, but it could; those PGs could be connected to a CICM that is assigned to the service provider, or they could actually be connected to the NAM itself.

In terms of ICM scripting, all incoming calls initially invoke an appropriate NAM routing script that has the primary responsibility of identifying the appropriate target customer. The script then delegates control to a routing script that is running on that customer's CICM. The CICM-based routing script can then select the appropriate ACD to which to deliver the call, and it can return the necessary translation route label to the NAM. The NAM can then instruct its routing client to deliver the call to the designated target ACD. If the CICM routing script determines that no ACD can currently take the call or that it cannot yet identify which ACD should take the call, it can ask the NAM to place the call into queue at a Service Control VRU. The CICM routing script can then issue Network VRU Script requests via the NAM to that VRU until a routing decision is made.

In practice, however, the NAM and CICM architecture is flexible enough to enable a number of other possibilities. Many Hosted customers use this topology simply as a way to get more calls or more PGs through their ICM setup. Others use CICMs, not for customer contact centers, but for outsourcers. In such cases, the NAM handles perhaps the same number of calls as the CICM, and the CICM machines themselves might be located quite far away from the NAM. Also, the NAM and CICM architecture was designed at a time when all contact centers ran on TDM-based ACDs. The addition of VoIP routing and ACDs based on Unified CM (that is, Unified CCE) with direct agent routing made matters considerably more complicated.

Using Unified CVP in Hosted Environments

When Unified CVP is involved, it is usually used as a self-service and/or queuing platform connected to the NAM and physically located within the service provider's data center. Thus, it enables the traditional service provider not only to route calls to the appropriate customer-owned ACDs but also to retain control of calls that are queued for those ACDs and to provide either basic prompt-and-collect capability or full-featured self-service applications to its customers. The latter case typically incorporates Unified CVP VXML Servers into the network. Depending on the customer's needs, the service provider might host the Unified CVP VXML Servers or the customer might host them. Additionally, the service provider might write and own the self-service application, or the customer might write and own them. Allowing the customer to own or host the Unified CVP VXML Servers is a convenient solution when the self-service application needs to reference back-end services. It allows the customer to keep control of that interaction within its own enterprise network, while transmitting only VoiceXML over HTTP to the service provider's VoiceXML gateway.

In many Hosted environments, particularly when the service provider is itself a PSTN carrier, all the actual call routing occurs via an ICM NIC. In that sense, these deployments are very much like Model #4b: VRU Only with NIC Controlled Pre-Routing. The same situation applies if a PGW is being used to route calls using (typically) the ICM SS7 NIC. However, quite often the service provider does not have a NIC interface at all, and all calls arrive via TDM interfaces such as T3 or E3. In those cases, Unified CVP is used as the Switch leg as well as the VRU leg. This situation is similar to Model #3a: Comprehensive Using ICM Micro-Apps, or Model #3b: Comprehensive Using Unified CVP VXML Server.

Unified CVP Placement and Call Routing in a Hosted Environment

As described previously, if Unified CVP is used in its traditional way as a true Network VRU, it is usually connected at the NAM. However, various requirements might cause Unified CVP to be placed at the CICM level instead, or in addition. The following guidelines apply when considering where to place Unified CVP components:

If Unified CVP is placed at the NAM and Unified CVP handles both the Switch leg and the VRU leg, use the Correlation ID transfer mechanism. The SendToVRU node may be executed by either the NAM or the CICM routing script. (The RunExternalScript nodes should also be in the same script that executed the SendToVRU.)

If Unified CVP is placed at the NAM and a NIC handles the Switch leg while Unified CVP handles the VRU leg, either the Correlation ID transfer mechanism or the Translation Route transfer mechanism may be used, depending on the capabilities of the NIC. (See Model #4a: VRU Only with NIC Controlled Routing.) In this case, the following guidelines also apply:

If Correlation ID transfers are used, then the SendToVRU node may be contained in either the NAM or the CICM routing script. (The RunExternalScript nodes should also be in the same script that executed the SendToVRU.)

If Translation Route transfers are used, then the TranslationRouteToVRU node, together with all RunExternalScript nodes, must be in the NAM routing script. The implication here is that the call is queued (or treated with prompt-and-collect) before the particular CICM is selected. This configuration does not make much sense for queuing, but it could be useful for service providers who want to offer initial prompt-and-collect before delegating control to the CICM.

If Unified CVP is placed at the CICM and a NIC handles the Switch leg while Unified CVP handles the VRU leg, only the Translation Route transfer method can be used. The TranslationRouteToVRU node, together with all RunExternalScript nodes, must be in the CICM routing script.

Adding calls initiated by Unified CM or an ACD brings additional constraints. Both of these devices are considered ACDs from the ICM's perspective, and they most likely are connected at the CICM level. Assuming these are new calls (as opposed to continuations of existing calls), the route request will come from the ACD and the resulting label will be returned to the ACD. Neither Unified CM nor any ACD is capable of transmitting a Correlation ID upon transfer; only the Translation Route transfer method can be used. This limitation further implies that the transfer destination (for example, Unified CVP) must also be connected at the CICM level, not the NAM level.

If the calls are not new but continuations of existing calls, then they are attempts to transfer an existing inbound caller from one agent to another agent. Customers might want these transfers to be either blind network transfers (that is, the first agent drops off and the caller is delivered to a second agent or queued for a second agent) or warm consultative transfers (that is, the caller goes on hold while the first agent speaks to a second agent or waits in queue for a second agent and eventually hangs up, leaving the caller talking to the second agent). The following guidelines apply to such transfers:

Blind network transfers

Whether or not the original call was introduced to the NAM via a NIC or Unified CVP Switch leg, the transfer label will be passed from the CICM to the NAM to the original Switch leg device. There are two sub-cases of blind network transfers:

If the Switch leg device is Unified CVP or a NIC that can handle Correlation ID, the Correlation ID transfer mechanism can be used. The SendToVRU node and all RunExternalScript nodes must be incorporated in the CICM routing script. The Unified CVP VRU leg can be connected to the NAM. This combination of blind transfer with Correlation ID transfer is ideal for Unified CVP and should be employed if at all possible.

If the Switch leg device is a NIC that cannot handle Correlation ID, then the Translation Route transfer method must be used, which further implies that the Unified CVP VRU leg device must be connected to the CICM.


Note In this case, the customer might have to deploy additional dedicated Unified CVP Call Servers at the CICM level because the NAM-level Unified CVP Call Servers cannot be used.


Warm consultative transfers

Unified CVP provides warm consultative transfers only in the case of Unified CCE agents transferring calls to other Unified CCE agents, where Unified CVP owns the initial Switch leg for the inbound call. For TDM agents, the ACD's own mechanisms are used and Unified CVP is not involved. In the case where the incoming calls to Unified CCE agents arrive through a NIC, Unified ICM's Network Consultative Transfer facility can be used, and it also would not involve Unified CVP.

In the one supported case where Unified CVP owns the initial Switch leg and the transfer is among Unified CCE agents, the Translation Route transfer method must be used because Unified CM cannot handle Correlation ID transfers. Again, this means that the Unified CVP VRU leg device must be connected to the CICM.


Note In this case, the customer might have to deploy additional dedicated Unified CVP Call Servers at the CICM level because the NAM-level Unified CVP Call Servers cannot be used.


Network VRU Type in a Hosted Environment

In Hosted environments, there are always two ICM systems to consider: the NAM and the CICM in question. Network VRU Types are configured differently in the NAM than in the CICM.

The NAM, as described earlier, sees new calls arrive either from a NIC or from Unified CVP, and it is aware of the Unified CVP VRU leg device. The NAM's Network VRU Types must be configured exactly as if it were an independent ICM operating with those devices. The fact that transfer labels sometimes come from a CICM can be ignored for the purposes of configuring Network VRU Types.

The CICM, on the other hand, sees new calls arrive from a NIC - the Intelligent Network Call Routing Protocol (INCRP) NIC, to be specific. All the dialed numbers that can arrive from the NAM must be associated with a Customer Instance that is associated with a Type 7 Network VRU. Associate that Network VRU with all VRU Scripts, and provide the same label as you need in the NAM's Network VRU definition, but with the INCRP NIC as its routing client. Other than that, no peripherals have Network VRUs configured.

Deployment Models and Sizing Implications for Calls Originated by Cisco Unified Communications Manager and ACDs

The information in this section applies to all ACDs as well as to all Cisco Unified Communications Manager (Unified CM) integrations that use Unified CVP rather than Cisco IP IVR for queuing. As far as Unified CVP is concerned, these devices share the following characteristics:

They manage agents and can therefore be destinations for transfers.

They can issue Route Requests and can therefore be Switch leg devices.

Although they can be Switch leg devices, they cannot handle more than one transfer and they might not be able to handle the Correlation ID.

A Unified CM or ACD user would typically issue a Route Request for one of the following reasons:

To be connected to another agent in a particular skill group

To reach a self-service application

To blind-transfer a previously received call to one of the above entities

In addition, a Unified CM user in particular might issue a Route Request for one of the following reasons:

To deliver a successful outbound call from the Unified ICM Outbound dialer to a self-service application based on Unified CVP

To warm-transfer a call that the user had previously received to either a particular skill group or a self-service application

Each of the above calls invokes an Unified ICM routing script. The script might or might not search for an available destination agent or service. If it finds an appropriate destination, it sends the corresponding label either back to the ACD or, if blind-transferring an existing call, to the original caller's Switch leg device. If it needs to queue the call or if the ultimate destination is intended to be a self-service application rather than an agent or service, the script sends a VRU translation route label either back to the ACD or, if blind-transferring an existing call, to the original caller's Switch leg device.

If the above sequence results in transferring the call to Unified CVP's VRU leg device, there is a second transfer to deliver it to a VoiceXML gateway. To ensure that these events take place, the following Unified ICM configuration elements are required:

For new calls from the ACD or warm transfers of existing calls:

The Unified CVP peripheral must be configured to be associated with a Type 10 Network VRU (Type 2 if Unified ICM 7.0 is used).

The dialed number that the ACD dialed must be associated with a Customer Instance that is associated with a Type 10 Network VRU (Type 7 if Unified ICM 7.0 is used).

With Unified ICM 7.0, or with a Unified ICM 7.1 and an ACD that is not Unified CM, the routing script that was invoked by the ACD's dialed number must contain a TranslationRouteToVRU node to get the call to Unified CVP's Switch leg, followed by a SendToVRU node to get the call to the VoiceXML gateway and Unified CVP's VRU leg.

With Unified ICM 7.1 and Unified CM, the routing script that was invoked by Unified CM should use a SendToVRU node to send the call to Unified CVP using the Correlation ID. The Type10 VRU will perform an automatic second transfer to the VoiceXML gateway VRU leg.

All the VRU scripts that are executed by that routing script must be associated with the Type 10 Network VRU (Type 7 if Unified ICM 7.0 is used).

For blind transfers of existing calls:

It does not matter to which Network VRU the Unified CVP peripheral is associated.

The dialed number that the ACD dialed must be associated with a Customer Instance that is associated with a Type 10 Network VRU (Type 7 if Unified ICM 7.0 is used).

The routing script that was invoked by the ACD's dialed number must contain a SendToVRU node to get the call to the VoiceXML gateway and Unified CVP's VRU leg.

All the VRU scripts that are executed by that routing script must be associated with the Type 10 Network VRU (Type 7 if Unified ICM 7.0 is used).

When Unified ICM chooses an agent or ACD destination label for a call, it tries to find one that lists a routing client that can accept that label. For calls originated by an ACD or Unified CM which are not blind transfers of existing calls, the only possible routing client is the ACD or Unified CM. Once the call has been transferred to Unified CVP, because of the handoff operation, the only possible routing client is the Unified CVP Switch leg. But in the case of blind transfers of existing calls, two routing clients are possible: (1) the Unified CVP Call Server switch leg that delivered the original call, or (2) the ACD or Unified CM. For calls that originate through Unified CVP, you can prioritize Unified CVP labels above ACD or Unified CM labels by checking the Network Transfer Preferred box in the Unified ICM Setup screen for the Unified CVP peripheral.

When using Unified CVP to do network transfers, an agent blind-transfers the caller to a new destination and the Network Transfer Preferred option is used. In this scenario, the agent should use the CTI Agent Desktop (and not the phone itself) to invoke the transfers. In addition to the CTI Agent Desktop, the Unified ICM Dialed Number Plan should be used. If configured with the same DN as the CTI Route Point, the Unified ICM Dialed Number Plan causes Unified ICM to intercept the transfer and run the Unified ICM routing script without sending the transfer commands to Unified CM through JTAPI. When the Unified ICM script returns a label, that label will be returned to the Network routing client (Unified CVP), and the caller is sent directly to the new destination. This configuration avoids a timing problem that can occur if an agent uses Unified CM CTI Route Points to initiate a network transfer.

Using Third-Party VRUs

A third-party TDM VRU can be used in any of the following ways:

As the initial routing client (using the GED-125 Call Routing Interface)

As a traditional VRU (using the GED-125 Call Routing Interface)

As a Service Control VRU (using the GED-125 Service Control Interface)

In the first and second cases, the VRU acts exactly like an ACD, as described in the section on Deployment Models and Sizing Implications for Calls Originated by Cisco Unified Communications Manager and ACDs. Like an ACD, the VRU can be a destination for calls that arrive from another source. Calls can even be translation-routed to such devices in order to carry call context information. (This operation is known as a traditional translation route, not a TranslationRouteToVRU.) Also like an ACD, the VRU can issue its own Route Requests and invoke routing scripts to transfer the call to subsequent destinations or even to Unified CVP for self-service operations. Such transfers almost always use the Translation Route transfer mechanism.

In the third case, the VRU takes the place of either Unified CVP's Switch leg or Unified CVP's VRU leg, or it can even take the place of Unified CVP entirely. Such deployments are beyond the scope of this document.