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.
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:
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
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.
Please rate helpful posts...
Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!
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.
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...