Network VRU Types
This section examines the different Network VRU types defined within Unified ICM and how they each relate to Unified CVP deployments. It begins with an overview of Unified VRU Types and then details how Unified CVP operates as a Type 10, 5, 3 and 7, or 8 and 2. The terms Voice Response Unit (VRU) and Interactive Voice Response (IVR) are used interchangeably in the following sections.
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 performs 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 independently provide the Switch and VRU portions.
The call delivery to a 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 must correlate the two legs (Switch and VRU) of the same call to provide instructions for completing the call. In the Unified ICM application, the VRU must 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. This 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) must be configured in Unified ICM to reach the VRU. 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.
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.5
Unified CVP as a Type 10 VRU
Figure 3-30 shows the relationship between the switch and VRU leg of a call when using a Type 10 VRU.
)
Figure 3-30 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. Unified ICM 7.0 deployments should use the VRU types outlined in subsequent sections of this chapter.
- 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.
- For calls originated by Cisco Unified Communications Manager, 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, 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 transfers the call to the Unified CVP VRU leg. If calls will be transferred to Unified CVP from CUCM, it also needs another label for the CUCM routing client. That label transfers the call to the Unified CVP Switch leg. The Unified ICM Router sends that label to CUCM with a Correlation ID concatenated to it. CUCM 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 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.6
Unified CVP as Type 5 VRU
Types 5 and 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 they connect to the VRU. In Type 6, the Switch and the VRU are the same device; therefore, the call is already at the VRU. There is no need for a Connect and Request message sequence from Unified ICM’s perspective. Figure 3-31 illustrates a Type 5 VRU with a Type 7.
)
Figure 3-31 Unified CVP as a Type 5 VRU6
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. 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.
Neither Correlation ID nor Translation Route ID is needed when Unified CVP acts as a Type 5 VRU to Unified ICM and the NAM.7
Unified CVP as Type 3 or 7 VRU (Correlation ID Mechanism)
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. 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)8
For configuration examples of the Unified CVP application with VRU Type 3 or Type 7, refer to the latest version of the Cisco Unified CVP Configuration and Administration Guide, available at Cisco.com.
Unified CVP as Type 8 or 2 VRU (Translation Route ID Mechanism)
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 capability 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.9
For configuration examples of the Unified CVP application with VRU Type 8 or Type 2, refer to the latest version of the Cisco Unified CVP Configuration and Administration Guide, available at Cisco.com.
Network VRU Types and Unified CVP Call Flow Models
In Unified ICM, Network VRU is a configuration database entity. It is accessed using the ICM Configuration Manager’s Network VRU Explorer tool. A Network VRU entry has two pieces of information:
Type: This is a number from 2 to 10 and corresponds to the types previously described.
Labels: This is a list of labels, which Unified ICM can use to transfer a call to the particular Network VRU that is being configured. These labels are only relevant for Network VRUs of Types 3, 7, and 10 (that is, those that use the Correlation ID mechanism to transfer calls). They are also required but never used in the case of Type 5. (Labels for Types 8 and 2 are defined in the ICM Configuration Manager’s Translation Route Explorer tool and invoked via a Translation RouteToVRU node.) Each label is made up of two parts:
- A digit string, which becomes a DNIS that can be understood by the gatekeeper (when using H.323), by a SIP Proxy Server or static route table (when using SIP without a Proxy Server), SIP, or by gateway dial-peers.
- A routing client (also known as a switch leg peripheral). In other words, each peripheral device that can act as a switch leg must have its own label, even if the digit strings are the same in all cases.
As noted earlier, Unified ICM Release 7.1(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 Types 2, 3, 5, 7, or 8 Network VRUs, which were associated with the Customer Instance and the Switch and VRU leg peripherals. The VRU-Only call flow models still require Type 8. However, in one specific case Types 3 or 7 is still required.
Network VRU configuration entries 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 ICM Configuration Manager’s PG Explorer tool
- In the customer Instance configuration in the ICM Configuration Manager’s ICM Instance Explorer tool
- In every VRU Script configuration in the ICM Configuration Manager’s Network VRU Script List tool
Depending on the call flow model, Unified ICM looks at either the peripheral or the customer instance to determine how to transfer a call to a VRU. Generally speaking, Unified ICM examines the Network VRU, which is associated with the switch leg peripheral when the call first arrives on a switch leg, and the Network VRU, which is associated with the VRU leg peripheral when the call is transferred to VRU using the Translation Route mechanism. It examines the Network VRU, which is associated with the Customer Instance or the default Network VRU from the System Information tool, when the call is transferred to the VRU using the Correlation ID mechanism.
Unified ICM also examines the Network VRU 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 does not execute the VRU Script.10
To examine how these VRU types interact with the previously defined Unified CVP Functional Deployment models, it is necessary to define the different variances of these models as such:
Model #1: Standalone Self-Service
Model #2: Call Director
Model #3a: Comprehensive Using ICM Micro-Applications
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
Model #1: Standalone Self-Service
As mentioned earlier in this chapter, this model does not interact with Unified ICM VRU scripts, so a Network VRU setting is not relevant. Even in the hybrid case in which the Standalone Self-Service model used Unified ICM for a label lookup, a VRU script is not invoked, only a simple Route Request to the VRU PG Routing Client. Therefore a Network VRU is not needed.
Model #2: Call Director
An earlier discussion pertaining to the Call Director model explained that Unified ICM (via Unified CVP) is responsible for call switching only. Because this model does not provide queuing or self-service, there is no VRU leg. Therefore, a Network VRU setting is not required.
Model #3a: Comprehensive Using Micro-Apps
In this model however, Unified CVP devices act as both the Switch and VRU leg, but interestingly enough, the call does not need to be transferred from the switch leg to the VRU leg before a call treatment can occur. Because this is the classic example of a Type 10 VRU, one should be associated to all the Unified CVP peripherals.
In addition, all incoming dialed numbers should be associated to Customer Instance associated with a Type 10 Network VRU. All the VRU Scripts that will be executed by the incoming call must be associated with the same Type 10 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. This enables a VRU label to be generated and verify that the VoiceXML router can kick off and start the VRU leg of a call. By using this node in the routing script, an incremental step is provided testing the viability of the VRU components of the solution.11
Model #3b: Comprehensive Using Unified CVP VXML Server
From a call routing and Network VRU perspective, this model is identical to Model #3a previously described.
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 when it receives the call. This model actually has two submodels, which are described separately in the following sections.
Model #4a: VRU-Only with NIC Controlled Routing
This submodel assumes a fully functional NIC 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 requesting that the call be retransferred to another agent or back into queue or self-service, the NIC can retrieve the call from the agent and redeliver 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) cannot transfer a call to a particular destination directory number and carry an arbitrary Correlation ID along with it, which the destination device can pass back to Unified ICM to make the Correlation ID transfer mechanism properly function. For most NICs, therefore, the Translation Route mechanism must be used. There are a few exceptions to this rule, in which case the Correlation ID mechanism can be used.
The NICs that can transmit 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 can transmit the Correlation ID, the incoming dialed numbers must all be associated with a Customer Instance associated with a Type 7 Network VRU. The Type 7 Network VRU must contain labels 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 cannot transmit a Correlation ID (the usual and safe case), the incoming dialed numbers must all be associated with a Customer Instance 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.12
Model #4b: VRU-Only with NIC Controlled Prerouting
This submodel assumes a less capable NIC that can deliver the call only once, whether to a VRU or to an agent. When the call is delivered, the NIC cannot be instructed to retrieve the call and redeliver 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 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 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.13