01-05-2011 10:24 AM - edited 03-16-2019 02:42 AM
I'm having issues dialing a single number.
9, 1-714-901-XXXX
Now I can dial this number no problem from a cell phone or another phone system.
I can dial other 714-901 numbers just fine from my system. Just not this one number.
I did a dialed number analysis and t looks good. Its matching my 9.1[2-9]XX[2-9]XXXXXX patern Its directing to a correct route list and route group. It looks like any other call I make to 714-901-XXXX.
Most of the time I just get an imidate disconnect. No rings, no nothing. Just dial, a pause for a second or so and then disconnect.
I don't see these calls show up on my CDR at all. My T1 provider does not see the call show up on their end at all. It just dies. It seems to be long intermitant. It was present for a while, then went away for a while now its back.
I'm a Communications Manager Newbie and have no Idea how to begin to troubleshoot this further.
System Details:
CM Version 7.1.5
Using a 7945 Cisco IPPhone Running SCCP 45.8-5-2S
I have two Cisco 2911 voice gateways with two PRIs each.
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.0(1)M3, RELEASE SOFTWARE (fc2)
ROM: System Bootstrap, Version 15.0(1r)M6, RELEASE SOFTWARE (fc1)
Any help that gets me going in the right direction would be greatly apreciated.
Solved! Go to Solution.
01-06-2011 05:31 PM
You're getting output form the debug, so it's making it to the GW.
But telco is dropping the call
*Jan 6 16:29:53.812: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0 x9B5A
Cause i = 0x8090 - Normal call clearing
TX = transmit
RX = receive
HTH
java
If this helps, please rate
www.cisco.com/go/pdihelpdesk
01-06-2011 11:42 PM
Hi Josh,
Seems like the telco is dropping the call. You said that you dial any other 714-901 numbers just fine. So try making a call to some other 714-901 number and post the output of debug isdn q931 so that we can check what the telco does with that call.
HTH
Regards
Nitesh
01-05-2011 12:01 PM
Start by doing a debug isdn q931 and/or a debug voip ccapi inout to make sure the call gets to the GW and then see what happens.
HTH
java
If this helps, please rate
www.cisco.com/go/pdihelpdesk
01-05-2011 01:03 PM
The gateways are running MGCP.
This was the only thing I understood (somewhat) from the debug output. And the only thing I knew was from my call.
(I Masked the full numbers with XXXX below)
*Jan 5 20:39:35.625: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x1A11
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0x0081, '480656XXXX'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '1714901XXXX'
Plan:Unknown, Type:Unknown
Below is the full debug for 20:39:35 and 20:39:36. Not sure how much is relevent so I'm just going to include whatever happend during thoes two seconds. If you would like more I would be happy to provide.
*Jan 5 20:39:35.613: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:
Interface=0x2A175320, Interface Type=6, Destination=, Mode=0x9,
Call Params(Calling Number=,(Calling Name=)(TON=Unknown, NPI=Unknown, Screeni ng=Not Screened, Presentation=Allowed),
Called Number=(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
Subscriber Type Str=, FinalDestinationFlag=FALSE, Outgoing Dial-peer=0, Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Appl ication Call Id=D000000002306504000000F500001a11)
*Jan 5 20:39:35.613: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
*Jan 5 20:39:35.613: :cc_get_feature_vsa malloc success
*Jan 5 20:39:35.613: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
*Jan 5 20:39:35.613: cc_get_feature_vsa count is 17
*Jan 5 20:39:35.613: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
*Jan 5 20:39:35.613: :FEATURE_VSA attributes are: feature_name:0,feature_time:8 06113304,feature_id:36041
*Jan 5 20:39:35.613: //36041/BE06C8FF8666/CCAPI/ccIFCallSetupRequestPrivate:
SPI Call Setup Request Is Success; Interface Type=6, FlowMode=1
*Jan 5 20:39:35.617: //36041/BE06C8FF8666/CCAPI/ccCallSetContext:
Context=0x31BAD9D0
*Jan 5 20:39:35.617: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:
Interface=0x31470CA8, Interface Type=9, Destination=0.0.0.0, Mode=0x9,
Call Params(Calling Number=,(Calling Name=)(TON=Unknown, NPI=Unknown, Screeni ng=Not Screened, Presentation=Allowed),
Called Number=(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
Subscriber Type Str=, FinalDestinationFlag=FALSE, Outgoing Dial-peer=0, Call Count On=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Appl ication Call Id=D000000002306504000000F500001a11)
*Jan 5 20:39:35.617: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
*Jan 5 20:39:35.617: :cc_get_feature_vsa malloc success
*Jan 5 20:39:35.617: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
*Jan 5 20:39:35.617: cc_get_feature_vsa count is 18
*Jan 5 20:39:35.617: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
*Jan 5 20:39:35.617: :FEATURE_VSA attributes are: feature_name:0,feature_time:8 06113080,feature_id:36042
*Jan 5 20:39:35.617: //36042/BE06C8FF8666/CCAPI/ccIFCallSetupRequestPrivate:
SPI Call Setup Request Is Success; Interface Type=9, FlowMode=1
*Jan 5 20:39:35.617: //36042/BE06C8FF8666/CCAPI/ccCallSetContext:
Context=0x31BAC950
*Jan 5 20:39:35.617: //36042/BE06C8FF8666/CCAPI/cc_api_call_connected:
Interface=0x31470CA8, Data Bitmask=0x0, Progress Indication=NULL(0),
Connection Handle=0
*Jan 5 20:39:35.617: //36042/BE06C8FF8666/CCAPI/cc_api_call_connected:
Call Entry(Connected=TRUE, Responsed=TRUE, Retry Count=0)
*Jan 5 20:39:35.617: //36041/BE06C8FF8666/CCAPI/cc_api_call_proceeding:
Interface=0x2A175320, Progress Indication=NULL(0)
*Jan 5 20:39:35.617: //36041/BE06C8FF8666/CCAPI/cc_api_call_connected:
Interface=0x2A175320, Data Bitmask=0x1, Progress Indication=DESTINATION IS NO N ISDN(2),
Connection Handle=0
*Jan 5 20:39:35.617: //36041/BE06C8FF8666/CCAPI/cc_api_call_connected:
Call Entry(Connected=TRUE, Responsed=TRUE, Retry Count=0)
*Jan 5 20:39:35.617: //36041/BE06C8FF8666/CCAPI/ccCallModify:
Nominator=0x1000, Params=0x2A279090, Call Id=36041
*Jan 5 20:39:35.617: //36041/xxxxxxxxxxxx/CCAPI/ccCallReportDigits:
(callID=0x8CC9, digit_event=0x1, enable=TRUE, consume=FALSE)
*Jan 5 20:39:35.617: //36041/BE06C8FF8666/CCAPI/ccCallReportDigits:
Enabled=TRUE, Call Id=36041
*Jan 5 20:39:35.617: //36041/xxxxxxxxxxxx/CCAPI/cc_api_call_report_digits_done:
(vdbPtr=0x2A175320, callID=0x8CC9, disp=0, digit_event=0x1, enable=TRUE, cons ume=FALSE)
*Jan 5 20:39:35.617: //36041/BE06C8FF8666/CCAPI/cc_api_call_report_digits_done:
Enabled=TRUE, Disposition=0x0, Interface=0x2A175320, Call Id=36041
*Jan 5 20:39:35.617: //36041/BE06C8FF8666/CCAPI/cc_api_call_report_digits_done:
Call Entry(Initial Digit Timeout=15000(ms), Inter Digit Timeout=10000(ms))
*Jan 5 20:39:35.617: //36041/xxxxxxxxxxxx/CCAPI/ccConferenceCreate:
(confID=0x2A2792A4, callID1=0x8CC9, callID2=0x8CCA, tag=0x0)
*Jan 5 20:39:35.617: //36041/xxxxxxxxxxxx/CCAPI/ccConferenceCreate:
(confID=0x2A2792A4, callID1=0x8CC9, gcid=0-0-0-0, tag=0x0)
*Jan 5 20:39:35.617: //36042/xxxxxxxxxxxx/CCAPI/ccConferenceCreate:
(confID=0x2A2792A4, callID2=0x8CCA, gcid=0-0-0-0, tag=0x0)
*Jan 5 20:39:35.617: //36041/BE06C8FF8666/CCAPI/ccConferenceCreate:
Conference Id=0x2A2792A4, Call Id1=36041, Call Id2=36042, Tag=0x0
*Jan 5 20:39:35.617: //36041/xxxxxxxxxxxx/CCAPI/cc_api_bridge_done:
Conference Id=0x4665, Source Interface=0x2A175320, Source Call Id=36041,
Destination Call Id=36042, Disposition=0x0, Tag=0xFFFFFFFF
*Jan 5 20:39:35.617: //36042/xxxxxxxxxxxx/CCAPI/cc_api_bridge_done:
Conference Id=0x4665, Source Interface=0x31470CA8, Source Call Id=36042,
Destination Call Id=36041, Disposition=0x0, Tag=0x0
*Jan 5 20:39:35.617: //36041/BE06C8FF8666/CCAPI/cc_generic_bridge_done:
Conference Id=0x4665, Source Interface=0x31470CA8, Source Call Id=36042,
Destination Call Id=36041, Disposition=0x0, Tag=0x0
*Jan 5 20:39:35.617: //36041/BE06C8FF8666/CCAPI/ccConferenceCreate:
Call Entry(Conference Id=0x4665, Destination Call Id=36042)
*Jan 5 20:39:35.617: //36042/BE06C8FF8666/CCAPI/ccConferenceCreate:
Call Entry(Conference Id=0x4665, Destination Call Id=36041)
*Jan 5 20:39:35.617: //36041/BE06C8FF8666/CCAPI/cc_api_caps_ind:
Destination Interface=0x31470CA8, Destination Call Id=36042, Source Call Id=3 6041,
Caps(Codec=0x1, Fax Rate=0x1, Vad=0x1,
Modem=0x2, Codec Bytes=20, Signal Type=3)
*Jan 5 20:39:35.617: //36041/BE06C8FF8666/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 5 20:39:35.617: //36042/BE06C8FF8666/CCAPI/cc_api_caps_ind:
Destination Interface=0x2A175320, Destination Call Id=36041, Source Call Id=3 6042,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x1,
Modem=0x2, Codec Bytes=160, Signal Type=2)
*Jan 5 20:39:35.617: //36042/BE06C8FF8666/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 5 20:39:35.621: //36042/BE06C8FF8666/CCAPI/cc_api_caps_ack:
Destination Interface=0x2A175320, Destination Call Id=36041, Source Call Id=3 6042,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_VOICE(0x2), Vad=OFF(0x1),
Modem=ON(0x2), Codec Bytes=160, Signal Type=2, Seq Num Start=1922)
*Jan 5 20:39:35.621: //36041/BE06C8FF8666/CCAPI/cc_api_caps_ack:
Destination Interface=0x31470CA8, Destination Call Id=36042, Source Call Id=3 6041,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_VOICE(0x2), Vad=OFF(0x1),
Modem=ON(0x2), Codec Bytes=160, Signal Type=2, Seq Num Start=1922)
*Jan 5 20:39:35.621: //36041/BE06C8FF8666/CCAPI/cc_api_call_modify_done:
Result=0, Interface=0x2A175320, Call Id=36041
*Jan 5 20:39:35.621: //36041/BE06C8FF8666/CCAPI/cc_api_voice_mode_event:
Call Id=36041
*Jan 5 20:39:35.621: //36041/BE06C8FF8666/CCAPI/cc_api_voice_mode_event:
Call Entry(Context=0x31BAD9D0)
*Jan 5 20:39:35.621: //36041/BE06C8FF8666/CCAPI/cc_process_notify_bridge_done:
Conference Id=0x4665, Call Id1=36041, Call Id2=36042
*Jan 5 20:39:35.621: //36041/BE06C8FF8666/CCAPI/ccSetDigitTimeouts:
Initial Digit Timeout=4000(ms), Inter Digit Timeout=4000(ms)
*Jan 5 20:39:35.621: //36041/BE06C8FF8666/CCAPI/ccSetDigitTimeouts:
Call Entry(Inter Digit Timeout=4000(ms), Initial Digit Timeout=4000(ms))
*Jan 5 20:39:35.621: //36041/BE06C8FF8666/CCAPI/ccRestartDigitTimeoutMsec:
Digit Timeout=0, Call Id=36041
*Jan 5 20:39:35.621: //36041/xxxxxxxxxxxx/CCAPI/ccCallReportDigits:
(callID=0x8CC9, digit_event=0x1, enable=TRUE, consume=FALSE)
*Jan 5 20:39:35.621: //36041/BE06C8FF8666/CCAPI/ccCallReportDigits:
Enabled=TRUE, Call Id=36041
*Jan 5 20:39:35.621: //36041/xxxxxxxxxxxx/CCAPI/cc_api_call_report_digits_done:
(vdbPtr=0x2A175320, callID=0x8CC9, disp=0, digit_event=0x1, enable=TRUE, cons ume=FALSE)
*Jan 5 20:39:35.621: //36041/BE06C8FF8666/CCAPI/cc_api_call_report_digits_done:
Enabled=TRUE, Disposition=0x0, Interface=0x2A175320, Call Id=36041
*Jan 5 20:39:35.621: //36041/BE06C8FF8666/CCAPI/cc_api_call_report_digits_done:
Call Entry(Initial Digit Timeout=4000(ms), Inter Digit Timeout=4000(ms))
*Jan 5 20:39:35.625: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x1A11
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0x0081, '480656XXXX'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '1714901XXXX'
Plan:Unknown, Type:Unknown
*Jan 5 20:39:35.717: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x 9A11
Channel ID i = 0xA98397
Exclusive, Channel 23
*Jan 5 20:39:36.433: //36041/BE06C8FF8666/CCAPI/ccCallModifyExtended:
Nominator=0x2A278FC0, Params=0x2A278208, Call Id=36041
*Jan 5 20:39:36.433: //36042/BE06C8FF8666/CCAPI/ccCallModify:
Nominator=0x18E30, Params=0x2A278408, Call Id=36042
*Jan 5 20:39:36.433: //36041/BE06C8FF8666/CCAPI/cc_api_call_modify_done:
Result=0, Interface=0x2A175320, Call Id=36041
*Jan 5 20:39:36.433: //36042/BE06C8FF8666/CCAPI/cc_api_call_modify_done:
Result=0, Interface=0x31470CA8, Call Id=36042
*Jan 5 20:39:36.449: //36039/BC1DE55D8665/CCAPI/cc_handle_inter_digit_timer:
Generate inter-digit timeout CC_EV_CALL_DIGIT_END event
01-05-2011 06:33 PM
That's all you get from the call???
I don't even see a disconnect reason there.
HTH
java
If this helps, please rate
www.cisco.com/go/pdihelpdesk
01-06-2011 08:30 AM
I don't think I showed enough of the debug. I did another debug with onlydebug isdn q931. Here are two calls I made below. Both did not ring and disconnected right away.
*Jan 6 16:29:51.992: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x1B5A
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98396
Exclusive, Channel 22
Calling Party Number i = 0x0081, '480656XXXX'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '1714901XXXX'
Plan:Unknown, Type:Unknown
*Jan 6 16:29:52.076: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x 9B5A
Channel ID i = 0xA98396
Exclusive, Channel 22
*Jan 6 16:29:53.812: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0 x9B5A
Cause i = 0x8090 - Normal call clearing
*Jan 6 16:29:53.844: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x1B 5A
*Jan 6 16:29:53.852: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x9B5A
*Jan 6 16:30:07.940: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x1B5B
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98396
Exclusive, Channel 22
Calling Party Number i = 0x0081, '480656XXXX'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '1714901XXXX'
Plan:Unknown, Type:Unknown
*Jan 6 16:30:08.032: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x9B5B
Channel ID i = 0xA98396
Exclusive, Channel 22
*Jan 6 16:30:09.328: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x9B5B
Cause i = 0x8090 - Normal call clearing
*Jan 6 16:30:09.360: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x1B5B
*Jan 6 16:30:09.388: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x9B5B
01-05-2011 12:45 PM
Hi Josh,
I completely agree with java. You need to check whether the call dies at the CUCM or is it even hitting the gateway. What protocol is running between the 2 Gateways and the CUCM? Run the debugs suggested by java and post the output. If you do not see the call hitting the gateway take CUCM traces for a non-working call and post it here.
HTH
Regards
Nitesh
PS: Pl rate helpful posts
01-06-2011 02:55 PM
Can anyone tell me if this call is making it out of the gateway? Or how to tell?
01-06-2011 05:31 PM
You're getting output form the debug, so it's making it to the GW.
But telco is dropping the call
*Jan 6 16:29:53.812: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0 x9B5A
Cause i = 0x8090 - Normal call clearing
TX = transmit
RX = receive
HTH
java
If this helps, please rate
www.cisco.com/go/pdihelpdesk
01-06-2011 11:42 PM
Hi Josh,
Seems like the telco is dropping the call. You said that you dial any other 714-901 numbers just fine. So try making a call to some other 714-901 number and post the output of debug isdn q931 so that we can check what the telco does with that call.
HTH
Regards
Nitesh
01-07-2011 08:27 AM
I picked another 714-901 number. This number is out of service and I get an out of service recording. But it does ring and I do hear the message. Here is the output from that call.
*Jan 7 16:25:19.535: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x1D7A
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98391
Exclusive, Channel 17
Calling Party Number i = 0x0081, '480656XXXX'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '1714901XXXX'
Plan:Unknown, Type:Unknown
*Jan 7 16:25:19.647: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x9D7A
Channel ID i = 0xA98391
Exclusive, Channel 17
*Jan 7 16:25:21.947: ISDN Se0/0/0:23 Q931: RX <- PROGRESS pd = 8 callref = 0x9D7A
Progress Ind i = 0x8288 - In-band info or appropriate now available
*Jan 7 16:25:29.503: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x1D7A
Cause i = 0x8090 - Normal call clearing
*Jan 7 16:25:29.543: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x9D7A
*Jan 7 16:25:29.567: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x1D7A
I see exactly what you are seeing now. In the case of my failed call I see a disconect message recived. As In:
*Jan 7 16:22:29.171: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x9D75
But in the case of the sucessfull call I see a disconnect message sent by me when I hung up during the recording.
*Jan 7 16:25:29.503: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x1D7A
Cause i = 0x8090 - Normal call clearing
I'm also seeing a progress message send to me during the sucessfull call:
*Jan 7 16:25:21.947: ISDN Se0/0/0:23 Q931: RX <- PROGRESS pd = 8 callref = 0x9D7A
Progress Ind i = 0x8288 - In-band info or appropriate now available
that I never see during my failed calls. I will re-open my ticket with the phone company. Thank you both so much for the help.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide