Fast busy on outbound calls

[umeshplamthottam]

Hello Everyone,

Today I am going through an issue, I have never experienced.

We have a CUCM and a 3rd party PBX, we have connected  both the PBXs over a SIP trunk.

I have created an Extension 2045 in the 3rd Party PBX and created a route pattern with the same pattern 2045 and choose the trunk in the Gateway/Route list.

When ever I am dialling the digit(2045) immediately I am getting the fast busy tone.

I have checked in SDL logs also but no traces found.

Also calls to my existing all other patterns are working

Kindly help me on this.

[Nithin Eluvathingal]

If you don't see traces of these calls in the logs, then the calls are not processed.
Did you check all the configurations, not just the Route Pattern and SIP trunk configuration? Are they fully operational? Have you looked at the Route Group and Route List if you are using them?
Also, on some PBXs, you need to add the route, otherwise, calls from CUCM will be rejected on the PBX side. I've encountered this often with PBX vendors. They claim it's a CUCM issue that calls from PBX to CUCM work, while calls from CUCM to PBX fail. Later, when they add the routes, incoming calls from CUCM to PBX work. So, ensure you have completed the necessary configurations on the PBX side for receiving calls from CUCM.

[umeshplamthottam]

Hi Nithin,

SIP trunk is in full service, Initially they haven't added inbound route but Now they setup the routes. 

As you mentioned here also they can make calls to CUCM, Vice versa  not so everyone is suspecting issue occurring at CUCM end.

I tried configuring route pattern with RG&RL as well.

[Maren Mahoney]

If the SDL traces are configured correctly, the call attempt should be captured even if the call is unsuccessful. What is the Level for your traces? Older versions of CUCM have "Error" as the level by default which only capture CUCM errors and not full SDL information.

The other thing to double-check is that the Partition for the Route Pattern is in the Calling Search Space of the device or line making the call. Is the call failing after the first digit is dialed or after all four digits are dialed?

Maren

[umeshplamthottam]

When I am checking with DNA It's shows that call will route through the same SIP trunk.

So I don't think there is some issue with CSS & Partition

[Nithin Eluvathingal]

On RTMT, you can view the calls and the SIP messages as well.
The logs will provide answers regarding what is happening with that call.
There is no conflict number configured locally on CUCM, right?

[Maren Mahoney]

Okay, if DNA says the call is routing the next thing would be to look at the traces to see what's failing. I'd look at RTMT Real Time data to view the ladder diagram to see if that shows what the issue is.

Maren

[ryabenne]

When you are dialing, do you go off hook and dial each number individually or do you dial them as a speed dial / Enbloc (all at once)?

This sounds a little like you are having some sort of CSS / Partition issue if you aren't able to find them in the SDL traces. 

I have seen it where customers need to stop / start their traces and make sure everything is set to default on the trace levels to be sure we are capturing the right data set for them, so you might want to try that as well. 

[umeshplamthottam · Accepted solution]

Hi everyone,

Thank you all for your responses and suggestions in helping troubleshoot the issue.

The root cause turned out to be a misconfiguration on the third-party PBX.

Our cluster consists of one Publisher and one Subscriber. Initially, the trunk from the third-party PBX was configured to the Publisher, while the test phone was registered to the Subscriber. Since there was no trunk connection between the third-party PBX and the Subscriber, the calls were failing.

After re-registering the device to the Publisher, the calls went through successfully. We have now also established a trunk to the Subscriber, and everything is working as expected.
Once again thanks for your support.