08-10-2010 10:54 AM - edited 03-16-2019 12:10 AM
Hi VoIP Guru's,
Could someone help me translate further the result I got after I run "debug voice ccapi inout", the user experiencing a fast busy after dialling number.
I attached the result of debug. and one thing, from the debug i just noticed a cause code value of 34 = "No circuit/channel is available. No B-channels are available to make the selected call". Can you give me idea how to deal with this cause code value.
Appreacite much all the help.
Thank you.
08-10-2010 12:19 PM
First, this document explains how to read a CCAPI debug, somewhat:
http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/voice_troubleshooting/old/vts_book.pdf
Now specifically for your issue:
Aug 10 09:47:51: //95569/80178000E003/CCAPI/cc_api_call_disconnected:
Cause Value=34, Interface=0x710C11BC, Call Id=95569
The first occurrence of the disconnect occurs on leg 95569, which is the inbound leg. That's matching dial-peer 0.
Where is this call coming from? That is the leg that is throwing the disconnect, and you need to run the specific protocl debugs for that corresponding leg to see which side (the other side or this router) is originating a no-channel disconnect, and why.
Based on the formatting of the number, it looks like that the voip leg? If so, run either debug h225 asn1 and debug h245 asn1, or debug ccsip mess. You'll first want to create an inbound dial-peer so that you don't match dial-peer 0, though:
http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010fed1.shtml
-Steve
08-10-2010 12:57 PM
08-10-2010 01:13 PM
First configure this so that you match an h323 dial-peer inbound:
dial-peer voice 2 voip
incoming called-number .
The PRI you are going out is up, as per 'sh isdn st', right?
Then, run these debugs if you still have failure:
debug voip ccapi inout
debug h225 asn1
debug h245 asn1
debug isdn q931
H323 debugs are verbose, so collect the debugs with this method:
Router(config)# service sequence
Router(config)# service timestamps debug datetime msec
Router(config)# logging buffered 10000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog
Router# term len 0
Router# sh logg
-Steve
08-10-2010 02:29 PM
If this is occurring outbound to the PSTN (do 'debug isdn q931' to see if circuit unavailable is returned after an outbound/TX SETUP message) then it may be that you have a fractional ISDN and have configured it for the full 30(E1) or 24(T1) channels.
Regards
Aaron
Please rate helpful posts...
08-10-2010 03:48 PM
Hi Steve,
I have dial peer 1, isn't that my inbound dial peer?
My PRI interface are up.
Thanks.
08-11-2010 06:05 AM
Jhun,
Dial-peer 1 is a POTS dial-peer. This call is coming in from VoIP, so your inbound dial-peer is going to be a VoIP dial-peer. You can see from the CCAPI output that you are not matching a dial-peer on the inbound leg. Please make that change and see what occurrs, and collect those debugs if the issue still persists to see what is going on at the call signaling level.
Aaron: the cause value is being thrown on the VoIP leg, not the POTS leg, so I don't think it's an issue of a channel not being available in this scenario.
-Steve
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