Interacting with ICM
This chapter discusses ICM from the perspective of its relationship with CVP. In some cases, the choice of deployment model has implications for ICM, and in other cases, certain choices about the ICM configuration carry implications for the CVP deployment.
This chapter covers the following topics:
•NetworkVRU Types and CVP Deployment Models
•Cisco CallManager and ACD Originated Calls - Deployment Models and Sizing Implications
•Using Third Party VRUs
This section first discusses Network VRU Types for ICM in general; then it discusses them as they relate to CVP deployments in particular.
This section covers the following topics:
•About ICM NetworkVRUs
•CVP as Service Node IVR to ICM (Type 5)
•CVP as Intelligent Peripheral IVR to ICM based on Correlation ID mechanism (Type 3,7)
•CVP as Intelligent Peripheral IVR to ICM based on Translation Route ID mechanism (Type 8,2)
•NetworkVRU Types and CVP Deployment Models
Note In this document, the words VRU and IVR are used interchangeably.
About ICM NetworkVRUs
This section describes ICM VRU Type Usage for CVP application. ICM perceives calls that need to have IVR session as having two portions: the Switch and the VRU legs. The Switch is the entity that first receives the call from the network/caller. The VRU is the entity to play audio, prompt and collect. CVP can participate either in the Switch role or the VRU role or both from the ICM perspective. In a network deployment, multiple CVP devices can also be deployed to provide the Switch and VRU portion each independently.
ICM classifies the VRU system in the network that handles the interactions with the caller in two categories:
The VRU operates as an Intelligent Peripheral IVR where the call will be delivered to the VRU for caller interaction, and then the call will be taken away from the VRU by a call control entity. (This is similar to the switch or SSP operation in a legacy PSTN intelligent network. SSP upon receiving instruction from a service control entity temporarily interacts with an intelligent peripheral for media resource invocation, and then resume the call processing toward completion.)
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. This is needed since the ICM has to correlate the two legs of the same call together in order to continue to provide instructions to complete the call. In the ICM application, the VRU needs to supply this call reference ID to ICM when the VRU asks for instructions on how to process the incoming call that it receives from the switch. This allows 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. Details of these two correlation mechanisms are described below.
Correlation ID is used if the network can pass the call reference ID to the VRU. This usually happens when the VRU is located in the network with the switch and the call signaling can carry this information (e.g., Correlation ID information is appended to the dialed digits in the ICM use case). This is usually the case for calls being transferred within the VoIP network.
Translation Route ID is used when the VRU is reachable across the PSTN (e.g., 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 ICM to reach the VRU and the network will route the call normally to the VRU as other directory number routing in the PSTN. When the VRU asks for instructions from ICM, VRU supplies this label (could be a subset of the received digits) and 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.
In many cases, CVP acts as a Service Node IVR where the call is delivered to the VRU for caller interaction, but the VRU is the call control entity to switch and delivers the call to the final destination once the IVR session is completed. Thus, CVP can manage both legs of the call.
Note The location of the deployed VRU as an intelligent peripheral IVR can be in the network (N-VRU) or at the customer premises (as such NAM in the network and CICM at the customer premise will also be deployed in this scenario). The corresponding correlation or translation route ID should be used accordingly, as described earlier, depending on the location of the VRU.
CVP as Service Node IVR to ICM (Type 5)
For VRU functions as a Service Node IVR in the network, ICM uses type 5 and type 6 to designate sub-behaviors of the VRU in the service node mode. They are described below.
Type 5 and type 6 are similar in the sense that the VRU entity functions both as a switch (call control) and the VRU (IVR). However, they differ on how to connect to the VRU.
In Type 6, the Switch and the VRU is the same device. Hence, the call is already at the VRU. No `Connect/Request Instructions' message sequence is needed from the ICM point of view.
On the other hand, in Type 5, the Switch and the VRU are different devices although in the same service node viewpoint from the ICM, even though they both interact with ICM through the same PG interface. Therefore, ICM uses a `Connect/Request Instructions' sequence to complete the IVR call.
Note In a CVP application, there are two legs of the call: the Switch leg and the VRU leg as perceived by ICM. In the CVP as service node application (i.e., CVP receives the call from the network directly; not pre-routing), CVP will appear to ICM as type 5 since the call control (the CVP) and the VRU device are different. Hence, CVP needs to be configured as VRU type 5 in the ICM/NAM configuration for the Switch leg. The VRU leg requires a different setup depending on the deployment model (e.g., the VRU leg could be type 7 in the comprehensive ICM enterprise deployment model). Refer to CVP 3.1 Configuration and Administration Guide for examples of configuration of CVP as type 5: http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.html
Neither Correlation ID nor translation route is needed when CVP acts as type 5 VRU to ICM/NAM. However, a dummy label is sometimes required.
CVP as Intelligent Peripheral IVR to ICM based on Correlation ID mechanism (Type 3,7)
When the VRU functions as an Intelligent Peripheral IVR with Correlation ID mechanism, ICM uses type 3 and type 7 to designate sub-behaviors of the VRU via the PG in the Correlation ID scheme. They are described below.
Both type 3 and type 7 VRU are reachable via Correlation ID mechanism. A PG is needed to control the VRU. However, the difference between these two types is on how to release the VRU leg and how to 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/agent.
In Type 7, the switch cannot take the call away from the VRU. When the IVR treatment is complete, ICM needs to disconnect/release the VRU leg first before the final connect can be sent to the switch leg to instruct the switch to connect the call to the destination.
CVP when used as an Intelligent Peripheral IVR can function with either Type 3 or 7, but it is somewhat more efficient under type 7 since its gets a positive indication from ICM when its VRU leg is no longer needed (as opposed to waiting for the VXML gateway to inform it that the call has been pulled away).
Remember that there are two legs of the call: the Switch leg and the VRU leg. Different CVP hardware can be used for each leg, but functionality-wise from the ICM perspective, there will be a CVP via PG acting as VRU type 5 (i.e., service node) along with a potential different CVP via another PG acting as VRU type 7 to complete the IVR application (self service, queuing, etc.)
Refer to CVP 3.1 Configuration and Administration Guide for examples of CVP application with VRU Type 3 or Type 7 configuration:
CVP as Intelligent Peripheral IVR to ICM based on Translation Route ID mechanism (Type 8,2)
When the VRU functions as an Intelligent Peripheral IVR with Translation Route mechanism, ICM uses type 8 and type 2 to designate sub-behaviors of the VRU via the PG in the translation route scheme. They are described below.
Both type 2 and type 8 VRU are reachable via the Translation Route mechanism. A PG is needed to control the VRU. However, the difference is how to 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, ICM sends final connect 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 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. CVP can be used for the switch leg or the VRU leg (e.g., when NIC and NAM/CICM is involved, CVP will be configured as type 2 or type 8 in the VRU leg). Refer to CVP 3.1 Configuration and Administration Guide for examples of CVP application with VRU Type 8 or Type 2 configuration:
NetworkVRU Types and CVP Deployment Models
This section describes how NetworkVRU Types relate to the CVP Deployment Models described elsewhere in this document (see "Deployment Models"). This section covers the following topics:
•Model #1. Standalone Self-Service
•Model #2. CVP with ICM-Controlled Switching
•Model #3a. DTMF Menu, Prompt and Collect
•Model #3b. ASR/TTS and/or complex IVR application
•Model #4. IVR/Queuing via ICM with NIC-controlled routing
•Model #4a. IVR/Queuing via ICM with NIC-controlled routing
•Model #4b. IVR/Queuing via ICM with NIC-controlled pre-routing
In ICM, NetworkVRU is a configuration database entity. It is accessed using the Network VRU Explorer. A NetworkVRU entry has two pieces of information:
•Type - this is a number from 2 to 8, and corresponds to the types described above
•Labels - this is a list of labels which the ICM can use to transfer a call to the particular NetworkVRU being configured. These labels are only relevant for NetworkVRU's of Types 3 and 7 (i.e., those that use the Correlation ID mechanism to transfer calls), and they are required but never used in the case of Type 5. Each label is made up of two parts:
–A digit string, which becomes a DNIS that can be understood by the gatekeeper or by gateway dial-peers; and
–A routing client, A.K.A. switch leg peripheral. In other words, each peripheral device which can act as a switch leg must have its own label, even though the digit strings will likely be the same in all cases.
NetworkVRU configuration entries themselves have no value until they are associated with active calls. There are three places in ICM where this association is made:
•Advanced tab for a given peripheral in the PG Explorer tool
•Customer Instance configuration in the ICM Instance Explorer tool
•On every VRU Script configuration in the VRU Script List tool
Depending on the protocol level call flow, the ICM looks at either the peripheral or the customer instance to determine how to transfer a call to a VRU. Generally speaking, the ICM examines the NetworkVRU which is associated with the switch leg peripheral when the call first arrives on a switch leg, and the NetworkVRU which is associated with the VRU leg peripheral when the call is being transferred to VRU using the Translation Route mechanism. It examines the NetworkVRU which is associated with the Customer Instance when the call is being transferred to the VRU using the Correlation ID mechanism.
ICM also examines the NetworkVRU which is associated with the VRU Script every time it encounters a RunExternalScript node in its routing script. If the ICM does not believe the call is currently connected to the designated NetworkVRU, it will not execute the VRU Script.
We will now see how this plays out under the various CVP deployment models. Note that much of the discussion which follows is heavily dependent on capabilities which were introduced in ICM/IPCC version 7.0(0).
If you are using an older version of ICM, please reference the CVP 3.1 Configuration and Administration Guide:
Model #1. Standalone Self-Service
The Standalone Self-Service model does not connect to ICM at all. Since ICM is not involved, the entire concept of NetworkVRU is irrelevant.
Model #2. CVP with ICM-Controlled Switching
In this model, ICM (and therefore CVP) is responsible for call switching only. It does not provide queuing or self service, and therefore there not a VRU leg. A NetworkVRU setting is not required.
Model #3a. DTMF Menu, Prompt and Collect
In this model, 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, accepting user input) can take place. Associate all CVP peripherals with a Type 2 NetworkVRU.
Note prior to ICM 7.0(0) a Type 5 was recommended here. That will still work properly, but new implementations should use Type 2
Associate all incoming Dialed Numbers with a Customer Instance which is associated with a Type 7 NetworkVRU. (This is sometimes known as a Type 2/7 Configuration.) Finally, all the VRU Scripts that will be executed by this call need to be associated with the same Type 7 NetworkVRU. Though it is not always necessary, as a best practice the ICM routing script should always execute a SendToVRU node prior to the first RunExternalScript node.
Model #3b. ASR/TTS and/or complex IVR application
From a call routing and NetworkVRU perspective, this model is identical to Model #3a (see Model #3a, CVP Call Control with Queue and Collect).
Model #4. IVR/Queuing via ICM with NIC-controlled routing
In this model, the call first arrives at ICM through an ICM NIC interface, not through CVP. At least initially, CVP is not responsible for the switch leg; its only purpose is as a VRU. However, depending on which kind of NIC is being used, it might be required to take over the switch leg once it receives the call. This model actually has two submodels, which we will deal with separately.
Model #4a. IVR/Queuing via ICM with NIC-controlled routing
This submodel assumes a fully functional NIC. That is, the NIC is capable of delivering the call temporarily to a NetworkVRU (i.e., to 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.
We must now consider two variants of this submodel, which dictate 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 ICM in order to make the Correlation ID transfer mechanism function properly. For most NIC's, therefore, the Translation Route mechanism has to be used. There are a few exceptions to this rule, however, in which case the CorrelationID mechanism can be used.
The NICs which are capable of transmitting Correlation ID include: CRSP, SS7IN, and TIM. However, as this also depends on the PSTN devices which connect behind the NIC, check with the PSTN carrier whether the Correlation ID can be passed through to the destination.
If the NIC is capable of transmitting Correlation ID, the incoming Dialed Numbers must all be associated with a Customer Instance which is associated with a Type 7 NetworkVRU. The Type 7 NetworkVRU must contain labels which are associated to the NIC routing client, and all the VRU Scripts must also be associated with that same Type 7 NetworkVRU. The peripherals need not be associated with any NetworkVRU. Though it is not always necessary, as a best practice the ICM routing script should always execute a SendToVRU node prior to the first RunExternalScript node.
If the NIC is not capable of transmitting Correlation ID (the usual and safe case), then the incoming Dialed Numbers must all be associated with a Customer Instance which is not associated with any NetworkVRU. The CVP peripherals must, however, be associated with a NetworkVRU of Type 8, and all the VRU Scripts must also be associated with that same Type 8 NetworkVRU. 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 CVP can be avoided when the requested agent is already available.
Model #4b. IVR/Queuing via ICM with NIC-controlled pre-routing
This submodel assumes a less capable NIC. That is, the NIC is capable of delivering the call only once, whether to a VRU or to an agent, but once the call is there the NIC cannot be instructed to retrieve the call and re-deliver it somewhere else. In these cases, CVP can take control of the switching responsibilities for the call. From the ICM perspective, this process is known as a handoff.
Calls which 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, the incoming Dialed Numbers must all be associated with a Customer Instance which is associated with a Type 7 NetworkVRU. The VRU's labels are associated with the CVP routing client (not the NIC!). The CVP peripherals must be associated with a NetworkVRU of Type 2, but all the VRU Scripts must be associated with the Type 7 NetworkVRU. In this case, it is always necessary to insert a TranslationRouteToVRU node in the routing script, followed by 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 CVP can be avoided if the requested agent is already available.
Note Notice the two different VRU transfer nodes that are required. The first one transfers the call away from the NIC with a handoff and establishes 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 VXML gateway and establishes CVP as the call's VRU device as well.
This section covers the following topics:
•About Hosted Implementations
•How CVP Fits Into Hosted Environments
•CVP Placement and Call Routing in a Hosted environment
•NetworkVRU Type in a Hosted environment
About Hosted Implementations
Hosted implementations refer to those implementations which incorporate a two-level hierarchy of ICM systems. At the top level sits the Network Application Manager (NAM), and below it sits one or more Customer ICMs (CICMs). Both NAM and CICM are really complete ICM's in and of themselves, with a communication link between them known as INCRP. Each CICM acts in an isolated fashion (i.e., it is not aware of either the other CICM's, nor is it aware that the NAM is itself another ICM). It has no connection to the other CICM's, 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 their own premise-based PGs, which are connected to their assigned service-provider-based CICM's. 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 located at the customer's premise next to his ACD's. The service provider itself does not necessarily operate any ACDs of its own, but it could; those PGs could be connected to a CICM which 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, whose primary responsibility would be to identify the appropriate target customer. The script then delegates control to a routing script which is running on that customer's CICM. The CICM-based routing script could then select the appropriate ACD to which to deliver the call, and return the necessary translation route label to the NAM. The NAM would then instruct its routing client to deliver the call to the designated target ACD. If the CICM routing script determined that no ACD could currently take the call, or that it could not yet identify which ACD should take the call, it could ask the NAM to place the call into queue at a Service Control VRU. The CICM routing script could then issue NetworkVRU Script requests via the NAM to that VRU until a routing decision could be made.
In practice, however, the NAM/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 CICM's 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 physically located quite far away from the NAM. Also, the NAM/CICM architecture was designed at a time when all contact centers ran on TDM-based ACDs. The addition of VoIP routing and Cisco CallManager-based ACDs (i.e., IPCC) with direct agent routing made matters considerably more complicated.
How CVP Fits Into Hosted Environments
When 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 ACD's, but also to retain control of calls which are queued for those ACD's, and to provide either basic prompt and collect capability or full-blown self service applications to its customers. The latter case typically incorporates CVP VoiceXML Servers into the network. Depending on the customer's needs, the service provider might host the VoiceXML 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 VoiceXML 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 his own enterprise network, while transmitting only VoiceXML over HTTP to the service provider's VXML 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 Deployment Model #4, IVR/Queuing via ICM with NIC-controlled 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, CVP is used as the switch leg as well as the VRU leg. This situation is similar to Model #3a, DTMF Menu, Prompt and Collect, or to Model #3b, ASR/TTS and/or complex IVR application.
CVP Placement and Call Routing in a Hosted environment
As described above, if CVP is used in its traditional way - as a true Network VRU, it is usually connected at the NAM. However, various requirements might cause CVP to be placed at the CICM level instead - or in addition. In considering where to place CVP components, the following constraints are involved:
•If CVP is placed at the NAM and CVP handles both the switch leg and the VRU leg, the Correlation ID transfer mechanism can be used. The SendToVRU node might be executed by either the NAM or the CICM routing script (the RunExternalScript nodes should also be in the same script which executed the SendToVRU).
•If CVP is placed at the NAM and a NIC handles the switch leg while CVP handles the VRU leg, either the Correlation ID transfer mechanism or the Translation Route transfer mechanism can be used, depending on the capabilities of the NIC (see "Model #4a. IVR/Queuing via ICM with NIC-controlled routing," above).
–If Correlation ID transfers are used, then the SendToVRU node might be contained in either the NAM or the CICM routing script (the RunExternalScript nodes should also be in the same script which 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 CVP is placed at the CICM and a NIC handles the switch leg while 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 Cisco CallManager Originated Calls or ACD Initiated Calls to the mix brings additional constraints. Both of these devices are considered ACDs from the ICM's perspective, and 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 Cisco CallManager nor any ACD is capable of transmitting Correlation ID upon transfer; only the Translation Route transfer method can be used. This further implies that the transfer destination (e.g., CVP) must also be connected at the CICM level, not the NAM level.
Now consider what happens if these calls are not new, but continuations of existing calls. In other words, these calls are attempts to transfer an existing inbound caller from one agent to another agent. Some customers will want such transfers to be blind network transfers (i.e., the first agent drops off and the caller is delivered to a second agent, or queued for a second agent), or warm consultative transfers (i.e., 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).
•Blind network transfers. Whether or not the original call was introduced to the NAM via a NIC or CVP switch leg, the transfer label will be passed from the CICM to the NAM to the original switch leg device. We consider two sub-cases.
–If the switch leg device is CVP or a NIC which can handle Correlation ID, the Correlation ID transfer mechanism can be used. The SendToVRU node and all RunExternalScript nodes will be incorporated in the CICM routing script. The CVP VRU leg can be connected to the NAM. This combination - blind transfer with Correlation ID transfer - is ideal for CVP and should be employed if at all possible.
–If the switch leg device is a NIC which cannot handle Correlation ID, then the Translation Route transfer method must be used, which further implies that the CVP VRU leg device must be connected to the CICM. This is very important: in these cases, the customer might have to deploy additional dedicated CVP Call Servers at the CICM level, since the NAM-level CVP Call Servers cannot be used.
•Warm consultative transfers. Note that CVP only helps with warm consultative transfers in the case of IPCC agents transferring the call to other IPCC agents where CVP owns the initial switch leg for the inbound call. For TDM agents, the ACD's own mechanisms are used and does involve CVP. For IPCC Enterprise agents where the incoming call arrived through a NIC, ICM's Network Consultative Transfer facility might be used; that also would not involve CVP.
In that one supported case, where CVP owns the initial switch leg and the transfer is among IPCC agents, the Translation Route transfer method must be used, since the Cisco CallManager cannot handle Correlation ID transfers. This means again, that the CVP VRU leg device must be connected to the CICM.
This is very important: in these cases, the customer might have to deploy additional dedicated CVP Call Servers at the CICM level, since the NAM-level CVP Call Servers cannot be used.
NetworkVRU Type in a Hosted environment
In Hosted environments, one must always consider two ICM systems: the NAM and the CICM in question. NetworkVRU Types will be configured differently in the NAM than in the CICM.
The NAM, as described earlier, sees new calls arrive either from a NIC or from CVP, and is aware of the CVP VRU leg device. The NAM's NetworkVRU 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 effectively ignored for the purposes of configuring NetworkVRU Types.
The CICM, on the other hand, sees new calls arrive from a NIC - the INCRP NIC to be specific. All the Dialed Numbers that can arrive from the NAM need to be associated with a Customer Instance which is associated with a Type 7 NetworkVRU. Associate that NetworkVRU with all VRU Scripts, and provide the same label as you need in the NAM's NetworkVRU definition, but with the INCRP NIC as its routing client. Other than that, no peripherals have NetworkVRUs configured.
Cisco CallManager and ACD Originated Calls - Deployment Models and Sizing Implications
The following discussion applies to all ACDs, as well as to all Cisco CallManager integrations which use CVP rather than IP-IVR for queuing.
As far as 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
•Though they can be switch leg devices, they cannot handle more than one transfer and they cannot handle CorrelationID
There are several reasons why a Cisco CallManager or ACD user would issue a Route Request:
•To be connected to another agent in a particular skill group
•To reach a self service application
•To blind-transfer a call which the user had previously received to one of the above
In addition, a Cisco CallManager user in particular might be issuing a Route Request in order to:
•Deliver a successful outbound call from the ICM Outbound dialer to a CVP-based self service application
•Warm-transfer a call which the user had previously received to either a particular skill group or a self service application
Each of the above calls invokes an 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, it 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 CVP's VRU leg device, there is a second transfer to deliver it to a VXML gateway. To ensure that these events take place, the following ICM configuration elements are required:
For new calls from the ACD, or warm transfers of existing calls:
–The CVP peripheral must be configured to be associated with a Type 2 NetworkVRU
–The dialed number which the ACD dialed must be associated with a Customer Instance which is associated with a Type 7 NetworkVRU
–The routing script which was invoked by the ACD's dialed number must contain a TranslationRouteToVRU node to get the call to CVP's switch leg, followed by a SendToVRU node to get the call to the VXML gateway and CVP's VRU leg
–All the VRU Scripts which are executed by that routing script must be associated with the Type 7 NetworkVRU
For blind transfers of existing calls:
–It does not matter to which NetworkVRU the CVP peripheral is associated
–The dialed number which the ACD dialed must be associated with a Customer Instance which is associated with a Type 7 NetworkVRU
–The routing script which was invoked by the ACD's dialed number must contain a SendToVRU node to get the call to the VXML gateway and CVP's VRU leg
–All the VRU Scripts which are executed by that routing script must be associated with the Type 7 NetworkVRU
When ICM chooses an agent or ACD destination label for a call, it tries to find one which lists a routing client which can accept that label. For ACD or Cisco CallManager originated calls which are not blind transfers of existing calls, the only possible routing client is the ACD or Cisco CallManager. Once the call has been transferred to CVP, because of the handoff operation, the only possible routing client is the CVP switch leg. But in the case of blind transfers of existing calls, two routing clients are possible: the ACD or Cisco CallManager, or the switch leg device which delivered the original call. For calls which originate through CVP, you can prioritize CVP labels above ACD or Cisco CallManager labels by checking the box called Network Transfer Preferred in the ICM Setup screen for the CVP peripheral.
Using Third Party VRUs
A third party TDM VRUs can be used in any of three 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 Cisco CallManager and ACD Originated Calls - Deployment Models and Sizing Implications. Like an ACD, it can be a destination for calls which 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, it can issue its own Route Requests, and invoke routing scripts to transfer the call to subsequent destinations or even to 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 CVP's switch leg or CVP's VRU leg, or it can even take the place of CVP entirely. Such deployments are beyond the scope of this document.