Translation Route from CVP to SIP-based IVR

Unanswered Question
Jan 10th, 2008
User Badges:

We are installing CVP 4.0(2) and ICM 7.2(2) to replace a TDM ACD. Part of this project involves transferring calls from CVP to a existing SIP-based IVR, which supports a Service Control Interface (we've already got it talking to ICM). This makes this a "Comprehensive" deployment, with some elements of a "Call Director" deployment (which we have been told is supported).


We can make calls into CVP, and hear the correct prompting (under ICM control). We can also make calls into the other IVR (not under ICM control).


We are in the process of trying to set up the transfer from CVP to this other IVR - and therein lies the problem. While we can send the call by label, we really want to be able to send the call while maintaining call context. Obviously this requires either a Translation Route or a Send to VRU (with Correlation Id). Based on the information we have, we are opting to do a Translation Route.


We've done all the configuration to support the Translation Route. When we run the TR Wizard, we are selecting Single Peripheral, Single Routing Client, followed by the Target Peripheral (other IVR) and Service (TR Service). We also have a new Network Trunk Group & Trunk Group waiting to be used for the TR config.


However a problem arises when we come to the Routing Client (CVP) step, because the dialled number list is greyed out, preventing the selection of a dialled number to go with the Routing Client. Even if we choose the "Disable dialled number selection" option, we are unable to select a Routing Client.


As I noted, we have a correctly configured CVP call flow, and we have the other IVR setup to accept the Translation Routed calls on a range of 10 SIP 4 digit DNIS numbers (this is the trigger for the Translation Route after Transfer).


At first I thought the problem might be because we had CVP and the other IVR setup as two PIMS under the one PG, so I've split them onto 2 PGs. We've also checked and rechecked all the other config, and I'm unable to find anything that may prevent it working.


We have CVP registered as a Type 10 VRU, and the other one registered as a Type 2 VRU (as per it's requirements). We have configured the Routing Clients on both PG/PIMs to prefer network tranfer, and both support post routing.


Does anyone have any thoughts as to where we should target our investigations, because I've exhausted all the paths I can think of.


C.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Riccardo Bua Fri, 01/11/2008 - 05:18
User Badges:
  • Cisco Employee,

Hi C.,


I would try with the post route scenario using correlation, t-route should not be needed in the type 10 scenario as far as I understand it.


Regards,


Riccardo

cvenour Sun, 01/13/2008 - 16:08
User Badges:

Thanks for the info Riccardo, but I'm still concerned.


Just to reiterate, calls come in to CVP (Type 10), where they receive some treatment, before being transferred to the other IVR (Type 2).


My understanding was that the Type 10 VRU type was created to consolidate CVP down from a Type 5 & a Type 7, to a single type. This means that the move from the Switch Leg to the VRU Leg of the CVP call flow can now be done with a single VRU type (and hence a single PG), using correlation IDs and the Send to VRU mechanism.


My further understanding is that this is governed by the default Network VRU configured in either the customer instance or system information pages.


But for the subsequent call leg, we are going FROM a Type 10 (CVP) TO a Type 2 (the other IVR). The other IVR apparently only operates in Type 2 mode, and Type 2 IVRs have traditionally required a TR to get calls to them.


If there is a way to use correlation ids to send calls to the other IVR (Type 2) from CVP (Type 10), then the follow-up question becomes how do we know which VRU the call is going to when a Send to VRU node is used?


C.

Riccardo Bua Mon, 01/14/2008 - 02:58
User Badges:
  • Cisco Employee,

Thanks for the clarification I was understanding the transfer would be under the control of the Type 10 VRU, hence the requirement for a T-Route not to be needed like if you were going from the Type 10 to an ACD like you are saying.


I had to go back to the docs.


Type 10 was designed to simplify the configuration requirements in CVP

Comprehensive Model deployments. It can be used for:

- calls which originate from a TDM VRU or ACD and need to be

transferred to CVP for self service or queuing; and

- calls which originate from an IPCC Call Manager and need to be

transferred to CVP for self service or queuing.

Type 10 NetworkVRU has the following behaviors:

- There is a Handoff of routing client responsibilities to the CVP

switch leg;

- There is an automatic transfer to the CVP VRU leg, making for a

second transfer in the case of VRU, ACD or Call Manager originated

calls;

- For Call Manager originated calls, 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 NetworkVRU configuration;

- The final transfer to the CVP VRU leg is similar to a Type 7

transfer, in that a RELEASE message will be sent to the VRU prior to

any subsequent transfer.

In CVP implementations, a single Type 10 NetworkVRU should be defined,

and all CVP Micro-application scripts should be associated with it. It

requires one label for the CVP Switch leg routing client, which will

transfer the call to the CVP VRU leg. If calls will be transferred to

CVP from Call Manager, it also needs another label for the Call Manager

routing client. That label will transfer the call to the CVP Switch

leg. The ICM Router will send that label to Call Manager with a

correlation-id concatenated to it. Call Manager must be configured to

tolerate these arbitrary extra digits.

The CVP Switch leg peripheral should be configured to point to the same

Type 10 NetworkVRU. Also, all incoming dialed numbers for calls which

are to be transferred to CVP should be associated with a Customer

Instance which points to the same Type 10 NetworkVRU.

For calls which originate at a Call Routing Interface VRU or at a TDM

ACD, a TranslationRouteToVRU node should be used to transfer the call

to CVPs Switch leg peripheral. For all other calls, a SendToVRU node

should be used, or a node which contains automatic SendToVRU behavior,

such as the queuing nodes, or RunExternalScript.


The feature selection document attached would point to the fact, that first

you have only the option of using a correlation id with you clear call see diagram 4.


By the way I checked also the overall deployment guide and type 2 is as

I recalled at the beginning of the call and eventually transferring to another

type and not viceversa, see the VRU Deployment Guide doc, for those scenarios

other types should be used, the doc was not updated for type 10 and I did not run enough tests with it.


End of part 1 as the "official" answer see part 2.


Regards,


Riccardo


PS. Please remember to rate useful posts.



Riccardo Bua Mon, 01/14/2008 - 02:59
User Badges:
  • Cisco Employee,

Part 2


You could try to trick it, but I never tried something similar as said and specially

with a type 10 and use as said using the correlation id, you might see the scenario below

depicted for a Warm Consultative Transfer with a Type 10 and a UCM PG as a possible guidance.


- Make sure NetworkTransferPreferred is unchecked in the CCM and CVP

routing clients in PG Explorer under the Routing Client tabs

- Under Network VRU Explorer, for your type 10 VRU, make sure theres a

label defined for the CCM routing client as well as the CVP routing

client and they are associated with a customer instance (e.g. cvp4)


- Under the PG Explorer, Call Manager peripheral, Advanced tab, make

sure you have NOT configured a NetworkVRU

- The DNs for the incoming call as well as the transfer DN should both

be associated with the same customer instance (e.g. cvp4)

- Now when the 2nd call is placed for the warm xfer and no agent is

available, the label defined on the CCM RC plus correlation id will be

sent back via EAPIM/JGW to CCM (assume label is something like

7777777777 and with a correlation id it will be something like

777777777712345) since the call originated from the CCM RC and since

NetworkTransferPreferred is not checked.

- A route pattern needs to be defined in CCM to handle this label plus

corelation id to route the call to CVP via either the SIP trunk if

youre doing SIP or via a GK controlled trunk with MTP enabled in the

H.323 case (e.g. 777! where ! allows label plus arbitrary length

correlation id)

- When CVP sees this call, it will see it as a pre-routed call with

correlation id and send it back to ICM to continue the script

- ICM will send a temp connect back to CVP which will queue the agent call while the caller should here MoH from CCM.


Regards,


Riccardo


PS. Please remember to rate useful posts.

cvenour Mon, 01/14/2008 - 15:38
User Badges:

I agree with you RE: CVP and Type 10 - that's all good. The problem is the second IVR.


We have 3 peripherals, and therefore three routing clients:


1. CVP (IVR A)

2. Other SIP IVR (IVR B)

3. Call Manager (Agent PG)


The normal inbound call flow is as follows:


1. Call arrives from SIP Carrier to Ingress GW as a SIP call.


2. Ingress GW dial peer is configured to contact internal SIP Proxy (CUPS) by SIP messaging.


3. CUPS static route forwards the SIP request to the CVP Call Server.


4. CVP Call Server invokes ICM routing script for incoming dialled number (this is the Switch Leg).


5. ICM routing script then invokes Send to VRU (VRU Leg), which results in call being transferred from the Ingress GW to the VXML GW using a correlation ID.


6. ICM instructs CVP to play basic messaging.


7. Call then needs to be transferred to IVR B, maintaining call context.


8. Under Service Control, the IVR B will play VRU scripts for self-service.


9. Upon completion of self-service, it is possible for the caller to request an agent resource. So call needs to be transferred from IVR B back to CVP for queuing to agent (Agent PG is Call Manager). A2Q instructions are that this transfer cannot be SIP Refer Xfer, and must be ICM Transfer.


10. When agent is available, call is transferred from CVP to agent.


After investigating the requirements around step 7, we opted to configure the IVR B as a Type 2 VRU, because we need to maintain call context throughout the entire call flow.


So, we went down the path of configuring the Translation Route. This is reinforced by the GED 125 implementation on the other IVR, which utilises a DNIS pool for correlating the call with the call context.


Using correlation Ids and the Send to VRU method involves changing ICM customer instances mid routing script, otherwise there is no context for ICM to determine which IVR the call should be sent to when we use Send to VRU.


The problem is that when we try to configure a Translation Route, using the ICM Translation Route Wizard, we encounter a bug in ICM 7.2(x), wherein it is not possible to select a routing client within the TR wizard.


This has been tested on 7.2(2) and 7.2(3), and the problem exists on both.


Basically, when you get to the Routing client selection step in the TR Wizard, you can select any routing client, but clicking the "Add" button does nothing. This means the TR Wizard cannot complete.


C.

Actions

This Discussion