We currently have two 2821 gateways connected together with ISDN the one connects to CUCM with a SIP trunk and the other connects to the telephony provider also with SIP.
When we make a outbound call and the person on the other end drops the call we recieve a FAST BUSY tone which causes an error on CTIOS and CAD.
Please can someone advise if there is any thing we need to add on an ISDN level to sort this out?
Is the second router connecting to the ITSB is owned/managed by them?
The first thing I would check is to see what, if any, Q931 events are received at hangup. If you do, what is the cause code on the IE?
Yes the router is owned and managed by the service provider. We have another provider that we connect directly on ISDN and I added the voice call disc-pi-off command to and that worked but we are still having the issue with the other service provider.
I will see if I can get them to give me the Q.931 debugs. Is there anything we can do on our end to force the disconnects?
Run the Q.931 debug on YOUR router. If you do not see a disconnect IE when the call should end the problem is on their end. I expect they are either a) not telling you the call is ending and just playing busy inband instead; or, b) sending you a disconnect with the wrong cause code. It's really easy to throw this one over the wall at the provider.
Thanks for the reply
Please see the debug below.
Nov 1 13:58:24.610: %ISDN-6-DISCONNECT: Interface Serial0/0/1:1 disconnected from 0833257389 , call lasted 51 seconds
Nov 1 13:58:24.614: ISDN Se0/0/1:15 Q931: TX -> RELEASE pd = 8 callref = 0x6D28
Nov 1 13:58:24.622: ISDN Se0/0/1:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0xED28
Nov 1 13:58:24.886: ISDN Se0/0/1:15 Q931: RX <- DISCONNECT pd = 8 callref = 0xED20
Cause i = 0x82A2 - No circuit/channel available
Im not too sure what I should be looking for?
That can't be the whole thing. You missed the Q.931 DISCONNECT IE for that call. Be careful to look at the callref value. It is a hex value starting with 0x0 or 0x8; the rest of it must match or it's a different call.
Here's an example incoming call from the PSTN. Take note of the parts in red. RX means the router received the IE; TX means the router is sending that IE. In this first example, the IP Phone ended the call.
039600: Nov 1 10:00:41.129 CDT: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x0613
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA18397
Preferred, Channel 23
Facility i = 0x9F8B0100A117020101020100800F534348554C454E42455247204A4F4E
Protocol Profile = Networking Extensions
Component = Invoke component
Invoke Id = 1
Operation = CallingName
Name Presentation Allowed Extended
Name = SCHULENBERG JON
Calling Party Number i = 0x2183, '6085550100'
Called Party Number i = 0x80, '6082462651'
039601: Nov 1 10:00:41.129 CDT: ISDN Se0/0/0:23 Q931: Received SETUP callref = 0x8613 callID = 0x04FF switch = primary-ni interface = User
039602: Nov 1 10:00:41.141 CDT: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x8613
Channel ID i = 0xA98397
Exclusive, Channel 23
039609: Nov 1 10:00:41.213 CDT: ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8 callref = 0x8613
039622: Nov 1 10:00:45.829 CDT: ISDN Se0/0/0:23 Q931: TX -> CONNECT pd = 8 callref = 0x8613
039623: Nov 1 10:00:45.889 CDT: ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x0613
039626: Nov 1 10:00:49.125 CDT: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x8613
Cause i = 0x8090 - Normal call clearing
039627: Nov 1 10:00:49.173 CDT: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x0613
039628: Nov 1 10:00:49.173 CDT: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x8613
Here's the same call but with the calling party on the PSTN hanging up instead.
039644: Nov 1 10:05:56.243 CDT: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x0614
Cause i = 0x8490 - Normal call clearing
039646: Nov 1 10:05:56.247 CDT: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x8614
039647: Nov 1 10:05:56.263 CDT: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x0614
Your partial logging output shows only the RELEASE, not the DISCONNECT for this call.
The behavior you are seeing is normal as telco is most likely
sending a q931 DISCONNECT msg with PI (progress indicator)
IE (Information Element) Most likely PI is set to 8.
This causes the GW/IOS to cut audio back to listen to any tone
or msg being played by telco.
So pl. run deb isdn q931 and check if you are getting a DISC
with PI. If yes then go ahead and configure voice call disc-pi-off
in global config so that IOS treats Disc w/PI as a regular DISC
and drops the call without keeping the leg up to listen to any
call progress tone.
Is there a command that I can get the Telco to put on his gateway so that when the call ends he sends me the DISC with PI?
It is very difficult to pin point the call in the debug as we have around 40 calls going through the Gateways at any given time as they are used on outbound campaigns.
Thanks again for the assistance.
Collect the debugs as follows, and it should make it easier to collect the debug for the issue:
Router(config)# service sequence
Router(config)# service timestamps debug datetime msec
Router(config)# logging buffered 20000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog
Router# debug voip ccapi inout
Router# debug isdn q931
Router# term len 0
Router# sh logg
Note the calling/called number and time of the call.
It would be premature to look for workarounds before you identify exactly how the provider is disconnecting these calls, in my opinion. If you want to be conclusive, though, have the provider run a q931 trap on the trunk at the same time you enable these debugs. Then when you find the call, you can tell them the call reference number for the call with the issue and thet will have the apropriate traces from their side to investigate with, as well.