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.
I haver checked the route points configurations and pg user association and everything is configured properly.
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.
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.
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)
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...