Hello everyone. I have an issue that I've been trying to resolve since we upgraded from CallManager 7.1.5 to 126.96.36.19900-11. I am able to forward my desk phone to my mobile phone, but when I call my desk phone, I get an immediate fast busy. I've been scouring the Internet for similar issues, but I cannot find a resolution to my issue.
Here's a little bit of info:
2 Voice Gateways
3 Local PRI's.
What I've done:
1) I logged into each server and verified that database replication was happy using the utils dbreplication runtimestat command.
2) I checked the codec from desk phone to desk phone, from desk phone to mobile phone, and mobile phone to desk phone, all at G.711ulaw.
3) Verified that the Clusterwide Parameters (Feature - Forward) options were the same as version 7.1.5, which they are. The CFA CSS Activation policy is set to "With Activating Device/Line CSS (although the recommended setting is With Configured CSS).
4) Checked my device line configs. The Calling Search Space Activation Policy is set to Use System Default, and the Forward All is set to the local CFW search space, same as the old system. I also checked the CSS to ensure that a partition wasn't left out or removed after the upgrade, and everything is the same.
5) Debug the local PRI. logged on to the Voice Gateway handling our two local PRI's and turned on ISDN Q931 debugging. The output is below:
This is a call from my desk phone to my cell phone
Aug 7 15:12:29.256: ISDN Se0/1/0:23 Q931: TX -> SETUP pd = 8 callref = 0x153B Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Display i = 'John Doe' Calling Party Number i = 0x2181, '2605551212' Plan:ISDN, Type:National Called Party Number i = 0xA1, '2605551313' Plan:ISDN, Type:National Aug 7 15:12:29.296: ISDN Se0/1/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x9 53B Channel ID i = 0xA98397 Exclusive, Channel 23 Aug 7 15:12:31.236: ISDN Se0/1/0:23 Q931: RX <- PROGRESS pd = 8 callref = 0x95 3B Progress Ind i = 0x8188 - In-band info or appropriate now available Aug 7 15:12:31.616: ISDN Se0/1/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x 153B Cause i = 0x8090 - Normal call clearing Aug 7 15:12:31.624: ISDN Se0/1/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x953 B Aug 7 15:12:31.652: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref =
This is a call from an internal extension calling my desk phone, which is forwarded to my mobile
Aug 7 18:22:53.163: ISDN Se0/1/0:23 Q931: TX -> SETUP pd = 8 callref = 0x1578 Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Display i = 'Joel Fox' Calling Party Number i = 0x2181, '2605551212' Plan:ISDN, Type:National Called Party Number i = 0xA1, '2605551313' Plan:ISDN, Type:National Redirecting Number i = 0x00008F, '1234' Plan:Unknown, Type:Unknown Aug 7 18:22:53.203: ISDN Se0/1/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x9 578 Channel ID i = 0xA98397 Exclusive, Channel 23 Aug 7 18:22:53.303: ISDN Se0/1/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x 9578 Cause i = 0x82AF - Resource unavailable, unspecified Aug 7 18:22:53.331: ISDN Se0/1/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x157 8 Aug 7 18:22:53.339: ISDN Se0/1/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x9578u all
I just have no idea why it is being dropped... Looking up the cause, others had issues with codec mismatch, which is why I checked that in the first place...
Thank you - That worked! Honestly I overlooked that completey thinking it was something much more complex since we just went through an upgrade. Of course I was rushing through things and should have caught that...
I rated this but for some reason it's not letting me mark it as a correct answer...
"Cause i = 0x82AF - Resource unavailable, unspecified".
Your SP was not taking your call request and rejected it. The Types and Plans of the calling/called parties are the same in the two calls, so the only information might break it is the redirecting number. It seems your SP doesn't like it. Uncheck "Redirecting Number IE delivery - outbound" and capture another ISDN Q.931 output.
Thank you Gary - minkdennis suggested the same resolution. As I told him, I overlooked that completely expecting a complex issue. It's odd that it worked prior to the upgrade, but it's working now so I'll let it ride :)
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
[toc:faq]CUCM Database Replication is an area in which Cisco customers
and partners have asked for more in-depth training in being able to
properly assess a replication problem and potentially resolve an issue
without involving TAC. This document discusse...