Troubleshooting Translation Routes to VRU

Question

I've got a problem at the Customer's IPCC Enterprise 7.2.
About 2,5% of calls in the welcome script fail at the Translation Route to VRU step (basically one of the first steps in the script) and a translation route time-out event is shown in Router window. CCM is the routing client and there are 2 IP-IVRs which are configured for load-balancing.
Any tips for troubleshooting the problem? The thing is I can't even identify the failing calls to look them up in the PG's opc process output and check what they might have in common.
Mike

Answer 1

You need to tie together the request from the CUCM for the trans route to what happens in the Call Router and what happens on the VRU. The key to this is the Dialog ID. This is a bit hard to explain and I may not have this exactly correct - but the advice is free. ;-)
Use rttrace to turn up tracing modules on the Call Router - route requests, trans routes, queuing - the usual suspects. Turn up trace on the OPC process(es) on the CUCM PG and the IPIVR PG. I can't remember the exact settings.
What you need to see on the OPC is the request for the trans route and the Dialog ID and the response on the other OPC. Then you match the Dialog ID to the Dialog ID in the Call Router and look at what happens. If you see the request, and the dialog ID, and about 10 seconds later the same dialog ID time out and the pending trans route removed, you have found a cuplrit.
Now you need to think about how this works.
The CUCM PG wants to do the trans route so it asks (through the Router) the destination PG to supply a number it can call (one of the trans route DNIS in the pool). Once it gets this, the destination PG is told to expect a call on that number and when it gets it, here is the associated data. A timer is set. The transfer has to occur within this time.
If there is a hold up on the CUCM side and the timer goes off, the call is lost. This is unlikely though, but I've seen it happen from VRU peripherals.
Do you have enough DNIS (route points) in the pool. There are many guidelines on this, but what I do is make as many RPs as I have CTI ports for the trans route final destination. Then you can be guaranteed you will never get into trouble. When a DNIS is used for the trans route it is normally held up for half a second or so. If a trans route times out, that DNIS is held up for 10 seconds - and this may snowball if the pool is too small.
Tracing trans route errors is one of the hardest things to do.
Regards,
Geoff