UCCE- CUCM Based Agent transfer to use local VXML GW

[Mark Applebee]

I have UCCE,CVP,CUCM setup with Combo GWs(incoming + Vxml) in 5 sites. I am using send to orginator to send the call back to the orginating gw to handle vxml application.  Can someone explain me how can I achieve CUCM orginated call(agent transfer to skillgroup) to use their local vxml gw for vxml application?

[Chad Stachowicz]

I will look for my old post, but the only way to do it is do away with send to originator and implement significant digits.  From here you can make significant digits for each VXML GW from CUCM and get whatever treatment you want.  Let me come back with the post.

[Mark Applebee]

If I use Significant Digit, I believe I have to add the one specific significant digits on the sip trunk to CVP from CUCM. The vxml gw  used by the call will be based on this significant digit. In this way I don't think I can  use 5 diffeent options, looks like the effect will be same as "send to orginator" way. Please correct me if I am wrong?

[Chad Stachowicz]

You got it buddy, then when you send in the call from CUCM you can also prepend a significant digit, which will give you the ability to select whatever VXML you want.

Cheers,

Chad

[Mark Applebee]

You are right!. If I want agents in 5 sites to use their local gw for vxml, I don't think it is still not possible. It is always going to use one vxml gw based on the significant digit prepended on CUCM trunk..right?

Otherwise I have to use 5 same route patterns on 5 different partition and each site to use a different partition and prepend the digit on routepattern rather than on Trunk. But I don't think ICM label from ICM to CUCM can differentiate through partititon. hope this make sense?

[Chad Stachowicz]

what do you mean?  You would need to build 5 different route patterns with 5 different significant digits to emulate this....

IE agent 1 dials (5)4565 and the vru label returned from ICM to CUCM is (5)999999999999

Agent 2 dials (6)4565 and the vru returned from ICM to CUCM is (6)999999999999

that label gets sent back to CVP, who strips that 5 or 6 and once again will reappended in its network transfer out to the proper VXML gateway.

Cheers,

Chad

[Mark Applebee]

I was trying to do this through CTI RP registered with pguser.

So you mean not to use the CTI RP for agent transfer and send the call straight to CVP through route patterns?

[Chad Stachowicz]

You are correct, to get local VXML treatment through this method you need to use a route pattern back into CVP.  Thinking about it a little differently, one more trick that may or may not work for you depending on your reporting requirements.  you could turn up new customers on ICM, give them different network VRU labels, and then give the transfer scripts from CTI RP with PG User, these different customers, to get different treatment...

Cheers,

Chad

[sidney.orret]

For better understanding, please clarify.  Do you have 1 or several CUCM clusters?

If all agents are part of the same cluster is going to be problematic, but I will develop the idea later.

If agents are part of different clusters then all what you need to do is configure a different Network VRU Label for each CUCM cluster and let CVP route to the local VXML GW based on the label.

For one CUCM cluster, the only way I can think and I don't recommend it is configuring 5 PIMs on the CUCM PG and use five different CTI Users on CUCM. Then each CUCM PIM will have a different Network VRU label and you can route based on that.  The point is this is going to be very cumbersome and difficult to configure/maintain as it have serious implications for device association, CAD, etc. No a good idea in my opinion but an idea noneless.

Now a comment. Based on my experience usually the need for agents to call a VRU application is because they are transferring a caller back to a self service or a different queue. Unless 100% of the calls that the agents answer came through the local voice gateway using agent's local VXML GW doesn't really makes a difference. Once the transfer is completed the connection will be between the voice GW handling the incoming call and the VXML GW that handled the agent's transferred call.

I would say that putting all vxml gw in a pool and not worrying to pick a specific one for these calls will work just fine for agent's originated calls, assuming that the number of these calls is not that high. And if is very high, I would say that the routing strategies should be reviewed.

Just two cents.

[Mark Applebee]

@Sidney I have only one CUCM cluster. I understand the option you were saying. But looks like it is going to be too complicated. I will try to convience the customer to use a single vxml gw for all internal calls. I hope the calls will stay within their bandwidth limitations between sites.

@Chad- The configuration looks too complicated and I believe it cause some problem with my reporting.

There must be a best practice everyone should follow, right. I don't think I will be the first one facing this problem. Hope someone will come up with a less complicated configuration to do this. Otherwise I think I will stick with configuring only one vxml gw for internal calls.