CVP to CVP Translation Route

RAJESH ASOK · ‎02-05-2016

Does anyone know if it is possible Translation route from one set of CVP Servers to another set of CVP Servers that are connected to the same ICM with different PGs? Basically our setup has two separate sets of CVP Call Servers (used for difference business segments) with their own PG instances. Each of the business segments have their own Ingress SBCs that bring the call in. we have a requirement to route calls from one business segment to another. During the call transition, we need to move the call from the Ingress SBC to the other. So I am trying to setup a translation route on CVP/PG1 instance, with the CVP/PG2 instance as a routing client.

1. Call comes into SBC2 --> CVP/PG2 Instance --> Received CVP Micro app/VXML Treatment.

2. ICM decides the call needs to route to an Avaya PBX connected to SBC1.

3. ICM Script has the Trans route to VRU, returns the label to CVP/PG2 with the label that would transfer the call SBC1.

4. SBC1 should receive the call, sends the request to CVP/PG1.

5. CVP/PG1 should close the translation route

6. ICM then chooses a route select that has a label for CVP/PG1.

7. CVP sends the label to the SIP Proxy/SBC1 which then sends the call to the Avaya PBX.

In theory this should work. But what is happening is when ICM encounters the Trans Route VRU step, it doesn't seem to send the label for SBC1 to CVP/PG2. Instead, just allows the call down the success path of the Trans Route VRU and to the Route Select. Once it hits the route select for the Avaya PBX, the route select doesn't have a label configured for CVP/PG2 (on top of the fact that SBC2 cannot terminate calls to the Avaya PBX directly) and hence the call doesn't reach the Avaya.

Is it by design that ICM wouldn't process the trans route from CVP to another CVP, if both CVP/PGs are connected to the same ICM Central Controller?

If it is by design, I guess my only option is to find a way to build the routes from SBC2 to the Avaya PBX and just send the label for the Avaya PBX directly from CVP/PG2. (that adds a layer of complexity between the two business segments).

Has anyone encountered such an issue or have any suggestions?

Thanks,

Rajesh.

Amer rajai Sha'er · ‎02-09-2016

Hello,

I like this, as you said in theory it should work, i have only done this one time to send from CVP to another but that was with a different ICM.

I have never encountered this but let me ask you, why you are using translation route and not just a label.

i might be missing something, but you can create a new label and send the call to the label, the label will be configured on the CVP to be routed to the other ingress gateway, the ingress gateway will process this call as a new call and route it to CVP as it is a new call.

This method can only work in case that you dont need any variables be routed, if you need variables to be routed as well, i am not sure if CVP warm transfer can work, search for CVP Warm transfer, it might give you a couple of hints for this.

I would love to know how things work out for you.

Amer

RAJESH ASOK · ‎05-05-2016

The reason I wanted to use Trans route to VRU was to ensure I could pass data from one set of CVPs to the other and then eventually to the agent. Since the trans route to VRU didn't work, I kind of had to built my own version of translation routing. Basically built a table with a pool of numbers that will terminate into the other CVP. Anytime I needed to route from one CVP Instance to the other, I would retrieve the number from that table, update the table with Var1 through 10 and a flag to indicate that TFN is in use, and then instruct CVP to transfer to that number (TFN/DID/DNIS). then when the call reached the other CVP on that expected DNIS, I did a DB lookup based on the DNIS and retrieved the data, and updated the table to clear Var1 through 10 and the flag to 'Free' then routed to my agent pool. this way, depending on the traffic, all I had to do was assign more TFN/DNIs to that table and got my data transfer. I would have to get a little innovative when I reach a stage where i would need to pass ECC Variables.

It is kind of painful to do this, since I had to write an small VXML app that can write and update the records in the Database. (other option would have been to use Application gateway, but I didn't have the time to get the developers to write an ApplicationGateway app to accomplish that). I wish the TransRouteToVRU would work.

Chintan Gajjar · ‎07-01-2016

Hello There,

If someone happens to come here to find an answer for CVP to CVP Trans routing.

First of all its possible.

The procedure is as below:

1. identify the source CVPs and Routing clients and destination CVPs and Routing clients.

2. Define two type 10 network VRUs one for Source (A) and one for Destination CVPs (B)

3. on the source CVP network VRU(A) configure VRU label for Source as well as destination CVPs

and on Destination CVP network VRU (B) configure label for only destination CVPs

4. Assign the net VRU A to Source CVP RCs, and Assign Net VRU B to Destination CVP RCs.

5. now the call coming into system has to at least identify the VRU which it belong to, so to do this make sure below:

A. you can have ICM DN for which call is coming in assigned to customer and that customer instance is configured to use source Net VRU (A)

B. optionally you can configure default network VRU in System options.

The essential part here is to make sure the call in one logical network VRU and when you do translation routing the destination peripheral should be on other network VRU.

6. Configure the Service, Network Trunk group on destination CVP RC and peripheral.

7. configure translation routing on destination CVP Peripheral.

let's say you pick 6000 as one of DNIS, the 6000 should be configured as DNIS on destination CVP NTG and as a label to be sent to source CVP RCs.

8. configure source CVPs number plan to send out TR label 6000 to either CUSP if you are using sip proxy or to any sip enabled device which can route the label back to destination CVPs. this can be done any sip routing, the essential part here is that the source CVP servers should be able to route the TR label to destination CVP servers.

9. configure destination CVP call servers ICM subsystem to handle 6000 as Translation route DNIS, and do save and deploy.

That's it, you can make some test call and if everything is setup correctly you will see the magic happening.

you can also use send to VRU on source and destination CVP to use there on VXML gateway,

once the call is translation routed to dest CVPs you have to do send to VRU to send call again to VXML gateway for the destination CVP.

you can also use sip refer transfer labels in translation routing to cleat the call leg completely from source CVP servers.

regards

Chintan