How to Check IPCC Translation Route Status?

Unanswered Question
Apr 16th, 2008

I have the following setup:

1. ICM 7.1(5)

2. CallManager 5.1(3)

Also we have 30 Route Points configured on the CallManager for the Translation Route purpose in Pre-Route Scenario.

Everything was working fine until recently we have intermittent issue where the agent couldn't receive the call. What happened is that the Agent was reserved by the ICM but the call could reach the agent.

I have checked the router log viewer and also run the sgl query and found out that the ICM has returned the label for the call however was unable to successfully conect the voice path to the agent.

I suspect that there are a few 'faulty' translation route ports out of the 30 we configured but I couldn't tell which ones are the faulty ones. I could actually make 30 consecutive calls to find out the faulty ports but I was wondering if there

are other quicker ways to do it.

Any thoughts?

I haver checked the route points configurations and pg user association and everything is configured properly.



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Abdulbaseer Mohammed Wed, 04/16/2008 - 21:30

Hello Erwin,

Making 30 calls probably is more faster :)

Most likely issue is on the CM side but if not try resync all your ICM data and then ensure you have your translations and labels are right.

Hope that helps.


erwin.stevanus Wed, 04/16/2008 - 22:19

Hi Baseer,

Thank you for your reply. I was hoping there is some tools in ICM to check the status of each Translation Route port so we can easily find out the the faulty ports.

I have double check the translation route labels configuration and confident that they are configured correctly.

By the way, how do you resync all the ICM data?



rbua Wed, 04/16/2008 - 23:01

Hi Erwin,

there are several things to do on this one, let me start from the beginning.

You need to have enough t-routes defined to handle your calls, you should use Erlang to calculate the IVR ports and then the t-route calculator to do so and the description on how the procedure for the IVR ports is in the SRND.

Ports are picked up in a round robin fashion, so let's say 5001, 5002, 5003, 5004, they get used one at a time, first 5001 then 5002 and so on.

Ports are released after the call completed, but it is taking a couple of seconds before they are available, so it might be a peak of calls would get some ports to be blocked.

In the IPCC troubleshooting guide there is a script sample on how to check for a port availability before routing a call with a custom formula in your ICM script, basically you define a network trunk group, this matches your IVR port number and if the port is not available you could decide what to do with the call, usually do a graceful disconnect asking for a later call.

You could check you trunks reports if you have configured the NTG to see any specific failure rate or use router log viewer for the specific DN which will be your T-route the call failed at or to be even more granular you could collect the Route Call Detail and Termination Call Detail, filter them just to the T-Route DNIS pool and check on the last number when the call failed, last but not least you might try to make a custom formula and populate one of your Call Variables with the NTG info the call is routed to so that you could spot any port issue.



erwin.stevanus Wed, 04/16/2008 - 23:36

Hi Riccardo,

Thanks for your reply. However in our setup, the Translation Route is used for the Pre-Routed Calls to the IPCC Agents and not for the IP IVR.

Hence, I believe that we don't have NTG setup for this purpose.

I can probably try the termination call detail and route call detail query to find out the failed call. But then it will be really complicated as the call center is very big and we have several sites with 30 Trans Route ports for each sites and it will be very time consuming to analyse the records.



rbua Wed, 04/16/2008 - 23:48

Check on the peripheral call variable option, that would give you an easy way to tackle the failed calls.



rbua Thu, 04/17/2008 - 00:25

Another option I just thought of might be to define a call type for each troute and monitor webview on those call types.




(Depending on the NIC based on Prerouting there is also the possibility of using the Network Event Related Tables to check for specific failures reported from the IN when handling some calls, but I suspect the call type approach is lot easier and granular)

erwin.stevanus Thu, 04/17/2008 - 15:53

Hi Riccardo,

Thank you for your help, i really appreciate that.

I will analyse the options and we will try the one that's more practical to do.

Thanks again.


jpsweeney77 Sun, 04/20/2008 - 10:27

Setup a SQL query that hits Termination Call Detail and perform a grouping and count on DNIS. Be sure to filter on the IVR/Qmanager peripheral.


This Discussion