Home > Articles > Networking > Voice/IP Communications

This chapter is from the book

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

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

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

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020