Long Distance Disconnects Immediately on Some Numbers

[JaxIsland75]

We are located in the Eastern US. I have phones all part of the same CSS. Some numbers can dial my 3 test long distance numbers 2 continental and one in Hawaii. Some phones can only call the continental and not Hawaii. When we dial the Hawaii number it immediately says "Good bye" and we get a fast busy signal. I have not been able to track down why this is happening. I take an extension that cannot call Hawaii and put it on my phone and it does not work. I take my number and put it on a phone that cannot call Hawaii and it works. It seems like the ability to call Hawaii is attached to the extension number and not the device. I have been away from CUCM for years so I will do my best to follow any advice given. I could use the help to try and get through this.

Thank you.

[Jaime Valencia]

Take a debug from a failed and from a successful call and compare the settings you're sending to your telco and what the disconnect cause is.

[Priyam Acharya]

Hi,

1) To check how is the call routed to provider from CUCM for a working and non working extension, you can use

https://<CUCM IP>/dna/showHome.do  

Analysis >> Phones >> Select the line >> Enter Hawaii number as dialed digits and then you can compare the output.

2) You can collect debugs from the gateway sending the call to service provider. For reference to which debugs based on the protocol of your gateway should be collected you can review this link below:

https://supportforums.cisco.com/t5/collaboration-voice-and-video/how-to-properly-and-safely-collect-debugs-on-an-ios-router/ta-p/3114693#collect  

3) Along with this you can collect Cisco CallManager traces from RTMT for the same call too.

Thanks,

Priyam

[JustAGuyWithAQuestion]

#1 and #3 look identical between a working and non-working DN. I am reading about #2 but I have never done a debug before. Any guidance as to how to do that would be appreciated.

Thank you.

[JustAGuyWithAQuestion]

This is what I found in the debug that differed from the working call:
335971: Jun 18 08:33:59.328: //1756544/DE73DB000001/CCAPI/cc_api_voice_mode_event:
Call Id=1756544
335972: Jun 18 08:33:59.328: //1756544/DE73DB000001/CCAPI/cc_api_voice_mode_event:
Call Entry(Context=0x7F5991426790)
335973: Jun 18 08:34:00.918: ISDN Se0/3/3:23 Q931: RX <- DISCONNECT pd = 8 callref = 0xC394
Cause i = 0x8AFF - Interworking error; unspecified

[R0g22]

Share the complete log. From that snippet, your Telco is sending the disconnect. It's CV=102. Could be a timeout issue or something that your Telco box does not like.

[JustAGuyWithAQuestion]

Complete log attached.

[R0g22]

Talk to your Telco. The call gets connected briefly and then following is received -

335973: Jun 18 08:34:00.918: ISDN Se0/3/3:23 Q931: RX <- DISCONNECT pd = 8 callref = 0xC394
Cause i = 0x8AFF - Interworking error; unspecified

[Aeby Vinod]

To add onto what Nipun said, I bet if you change the EPNM of the non-working Phones DN to '5183934304' you would be able to make calls, but that's just a temporary fix. The Telco here might be controlling your calling privileges based on the calling number, there are instances when Telco's block calling privileges to avoid toll fraud and you have to make them release it for you.

HTH,
Aeby

[JustAGuyWithAQuestion]

I have been working with our provider today to continue to troubleshoot. Basically what we found is that when we dial that outgoing number they do not see the call on their network. Something internally is disconnecting the call before it gets out to the telco. So back to troubleshooting, I will take any ideas.

Aeby, I am not sure how I would configure it to do that, although it seems like a valid test.

Thank you.

[Ratheesh Kumar]

Can you run Dial Number Analyser and see how the calls are routing. Any firewall in place


Hope this Helps
Cheers
Rath!

***Please rate helpful posts***

[R0g22]

Escalate to your Telco L3. There is nothing INTERNAL disconnecting these calls. Here is the ISDN SETUP being extended to your Telco -

335900: Jun 18 08:33:59.196: ISDN Se0/3/3:23 Q931: TX -> SETUP pd = 8 callref = 0x4394
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98395
Exclusive, Channel 21
Calling Party Number i = 0x2181, '5183934304'
Plan:ISDN, Type:National
Called Party Number i = 0x80, '18083354363'
Plan:Unknown, Type:Unknown

Post this nothing is under CE control. Here are rest of the logs for that one call -

335903: Jun 18 08:33:59.238: ISDN Se0/3/3:23 Q931: RX <- CALL_PROC pd = 8 callref = 0xC394
Channel ID i = 0xA98395
Exclusive, Channel 21

335905: Jun 18 08:33:59.240: ISDN Se0/3/3:23 Q931: RX <- PROGRESS pd = 8 callref = 0xC394
Progress Ind i = 0x8281 - Call not end-to-end ISDN, may have in-band info


335939: Jun 18 08:33:59.312: ISDN Se0/3/3:23 Q931: RX <- CONNECT pd = 8 callref = 0xC394
335940: Jun 18 12:33:59.313: %ISDN-6-CONNECT: Interface Serial0/3/3:20 is now connected to 18083354363 N/A
335941: Jun 18 08:33:59.313: ISDN Se0/3/3:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x4394

335973: Jun 18 08:34:00.918: ISDN Se0/3/3:23 Q931: RX <- DISCONNECT pd = 8 callref = 0xC394
Cause i = 0x8AFF - Interworking error; unspecified

Everything has been received (Rx) from your Telco.

[JustAGuyWithAQuestion]

I have re-opened the case with the telco. I will update once I hear anything. Thank you again for the assistance.

[JustAGuyWithAQuestion]

After battling the telco it appears that they maintain an international database. 2 of our 3 numbers were not part of that database which means they did not have permission to call internationally. Even though Hawaii and we found out Alaska as well use +1 for the country code, the telco treats them as international numbers. We have submitted an authorization form to add those numbers to that database and that should resolve the issue. Thank you for the help with debugging and reviewing the logs. Once I had that evidence to show them they actually worked on the issue and found the problem.

Cheers!

[R0g22]

Bingo! I believe ISP's train their engineers to just blame it on Cisco all the time and as a first line of defense. You should have asked the engineer how they can see the call now when previously they could even find the call.