×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Fast Busy Signal after Hang Up

Unanswered Question
Nov 1st, 2010
User Badges:

Hi


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?


Wayne

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jonathan Schulenberg Mon, 11/01/2010 - 06:27
User Badges:
  • Super Bronze, 10000 points or more
  • Cisco Designated VIP,

    2017 IP Telephony

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?

wayne.aitken Mon, 11/01/2010 - 06:38
User Badges:

Hi Jonathan


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?


Regards


Wayne

Jonathan Schulenberg Mon, 11/01/2010 - 06:53
User Badges:
  • Super Bronze, 10000 points or more
  • Cisco Designated VIP,

    2017 IP Telephony

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.

wayne.aitken Mon, 11/01/2010 - 07:01
User Badges:

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?


regards


Wayne

Jonathan Schulenberg Mon, 11/01/2010 - 08:12
User Badges:
  • Super Bronze, 10000 points or more
  • Cisco Designated VIP,

    2017 IP Telephony

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

                0xA117020101020100800F534348554C454E42455247204A4F4E

                Component = Invoke component

                        Invoke Id = 1

                        Operation = CallingName

                                Name Presentation Allowed Extended

                                Name = SCHULENBERG JON

        Calling Party Number i = 0x2183, '6085550100'

                Plan:ISDN, Type:National

        Called Party Number i = 0x80, '6082462651'

                Plan:Unknown, Type:Unknown

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.

dksingh Mon, 11/01/2010 - 10:10
User Badges:
  • Cisco Employee,

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.

wayne.aitken Tue, 11/02/2010 - 00:07
User Badges:

Hi


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.

Steven Holl Tue, 11/02/2010 - 06:58
User Badges:
  • Cisco Employee,

Wayne,


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.

Actions

This Discussion