ISDN disconnect to release timer

Unanswered Question
Oct 22nd, 2009

Hey everyone,

I searched the forum, and asked google, but I didn't find a solution yet, so here is my setup:

Cisco 2811 router as H323 Gatway (ISDN BRI) used by a Communications Manager 6.1.

ISDN port configuration:

interface BRI0/2/0

no ip address

no ip mroute-cache

isdn switch-type basic-net3

isdn overlap-receiving T302 4000

isdn point-to-point-setup

isdn incoming-voice voice

isdn send-alerting

isdn sending-complete

isdn outgoing-voice info-transfer-capability 3.1kHz-audio

isdn static-tei 0

Following tests:

Call from the IP phone to my cell. Phone rings, call established. Then I disconnect the call on the IP phone - call is disconnected immidiately:

159518: Oct 22 14:28:05 MESZ: %ISDN-6-DISCONNECT: Interface BRI0/2/0:1 disconnected from unknown , call lasted 7 seconds

159519: Oct 22 14:28:05 MESZ: ISDN BR0/2/0 Q931: TX -> DISCONNECT pd = 8 callref = 0x0B

Cause i = 0x8090 - Normal call clearing

159520: Oct 22 14:28:05 MESZ: ISDN BR0/2/0 Q931: RX <- RELEASE pd = 8 callref = 0x8B

159521: Oct 22 14:28:05 MESZ: ISDN BR0/2/0 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0B

Now I make exactly the same but this time I disconnect the call on my cell phone. Now I hear the buzzing sound on the IP phone for exactly 30 seconds. Debug on the router looks like this:

159389: Oct 22 13:55:07 MESZ: %ISDN-6-CONNECT: Interface BRI0/2/0:1 is now connected to N/A N/A

159390: Oct 22 13:55:08 MESZ: ISDN BR0/2/0 Q931: RX <- DISCONNECT pd = 8 callref = 0x85

Cause i = 0x8090 - Normal call clearing

Progress Ind i = 0x8288 - In-band info or appropriate now available

159391: Oct 22 13:55:08 MESZ: %ISDN-6-DISCONNECT: Interface BRI0/2/0:1 disconnected from unknown , call lasted 6 seconds

159392: Oct 22 13:55:38 MESZ: ISDN BR0/2/0 Q931: RX <- RELEASE pd = 8 callref = 0x85

Cause i = 0x8090 - Normal call clearing

159393: Oct 22 13:55:38 MESZ: ISDN BR0/2/0 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x05

Takes 30 seconds from disconnect to release.

Why is this? Which timer is responsible? How can I fix this, so that the call gets instant disconnected (released)?

Thanks in advance!

Kind regards, Dave

I have this problem too.
2 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.3 (3 ratings)
Loading.
Paolo Bevilacqua Thu, 10/22/2009 - 05:19

Hi, this is normal and there are no settinga that you can or should configure.

In the disconnect you have:

Progress Ind i = 0x8288 - In-band info or appropriate now available

This means you have the in-band tones to advise user that party has disconnected.

During this time, on the IP phone you are free to hang-up, as any person would likely do.

Since this does not happen, after 30 seconds, CO sends release and at this point the call is completely torn down.

David Schwarzhans Thu, 10/22/2009 - 05:29

Hi,

yes, human would do and here we come to the problem: they do!

Now the point where this comes to a problem is this: Mobility

I get a call on my IP Phone. I take the call, and then I decide to transfer it to my mobile. So I press the mobility softkey, transfer it and now I have the call on my mobile. Works without a problem and without any noticable interruption for the caller. Now I want to transfer the call back to my IP phone. To do that I have to simply hang up on my mobile. And now the caller hears the exact same buzzing tone described before for the next 30 seconds. After this 30 seconds I can take the call on the Ip phone again (press the resume button).

And a human would hang up during this 30 seconds... :-(

Is there any way how I could reduce (or better eliminate) this timeout or is this up to the telecom service provider?

Thanks in advance!!

Paolo Bevilacqua Thu, 10/22/2009 - 05:34

I'm not sure how mobility works, but from your description it doesn't work very well. Perhaps you should talk to the TAC to check on things.

The telco side is fine and you cannot ask anything neither they can do.

David Schwarzhans Thu, 10/22/2009 - 05:41

Ok, thank you, you helped me a lot. I will keep this open a while, maybe a Mobility Expert is around...

David Schwarzhans Tue, 10/27/2009 - 00:34

Hi folks,

I did some more research and I'm pretty sure it has nothing to do with mobility, but see for yourself.

Here is a quote from the official Q931 protocol description document:

########################################

When in-band tones/announcements are provided (see 5.4), the DISCONNECT message contains

progress indicator No. 8, in-band information or appropriate pattern is now available. The network

shall: start timer T306 and enter the Disconnect Indication state.

On receipt of the DISCONNECT message with progress indicator No. 8, the user may connect (if not

already connected) to the B-channel to receive the in-band tone/announcement; and enter the

disconnect indication state. Alternatively, to continue clearing without connecting to the in-band

tone/announcement, the user shall disconnect the B-channel; send a RELEASE message, start timer

T308 and enter the Release Request state.

If the user connects to the provided in-band tone/announcement, the user may subsequently continue

clearing (before the receipt of a RELEASE from the network) by disconnecting from the B-channel,

sending a RELEASE message, starting timer T308 and entering the Release Request state.

On receipt of the RELEASE message, the network shall stop timer T306; disconnect and release

the B-channel; send a RELEASE COMPLETE message; release the call reference and return to the

Null state.

If timer T306 expires, the network shall continue clearing by disconnecting the B-channel, sending a

RELEASE message with the cause number originally contained in the DISCONNECT message,

starting timer T308 and entering the Release Request state.

########################################

If you look now at the debug information (where the disconnect fails) from my first post:

Network sends the disconnect and in-band info is now available. The router now doesn't connect to the B-channel to receive this information and doesn't enter the disconnect indication state. It neither doesn't continue clearing with sending a release message to the network.

So to solve this, I see two solutions:

1. Get the router to listen to the In-band info

2. Get the router to send a release message to the network when it receives a disconnect message.

Has anyone of you an idea how to do that?

Edit:

Here is my dial-peer configuration:

dial-peer voice 20 pots

description *** outbound dialpeer to PSTN ***

preference 1

destination-pattern 0T

progress_ind setup enable 3

progress_ind alert enable 8

progress_ind progress enable 8

progress_ind disconnect enable 8

port 0/2/0

Regards, Dave

Paolo Bevilacqua Wed, 10/28/2009 - 07:18

the user may connect (if not already connected) to the B-channel to receive the in-band tone/announcement

This is the case, router is already connected to B-channel, and does not need to do anything.

Then, for the router to send release on disconnect for purpose of mobility (not always, for the reasons explained before) you need to complain to Cisco, none of the progress_ind commands is effective in that.

David Schwarzhans Thu, 10/29/2009 - 10:05

Finally solved this (with a little help) :-)

As I said, this has nothing to do with mobility. I got this explaination: Because the router gets this tone frome the telecom it doesn't send a release command to the network. Therefore the T306 timer on the telco side expires and then I receive the release.

now add this global configuration command: voice call disc-pi-off

and now it works exactly as it should.

new debug output looks like this:

VoIP2811#

003524: Oct 29 17:51:09 UTC: ISDN BR0/2/0 Q931: RX <- DISCONNECT pd = 8 callref = 0x9F

Cause i = 0x8090 - Normal call clearing

Progress Ind i = 0x8288 - In-band info or appropriate now available

003525: Oct 29 17:51:09 UTC: %ISDN-6-DISCONNECT: Interface BRI0/2/0:1 disconnected from unknown , call lasted 8 seconds

003526: Oct 29 17:51:09 UTC: ISDN BR0/2/0 Q931: TX -> RELEASE pd = 8 callref = 0x1F

003527: Oct 29 17:51:09 UTC: ISDN BR0/2/0 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x9F

VoIP2811#

Perfect. Unfortunately I cannot mark this thread as solved so anyone who is interested should read to the end ;-)

Regards, Dave

Paolo Bevilacqua Thu, 10/29/2009 - 10:26

Very good, there are a lot of obscure commands around and one never knows what and where they are before finding..

msbadaga Thu, 11/28/2013 - 20:47

vtg-bgl12-00a-vg2#config t

Enter configuration commands, one per line.  End with CNTL/Z.

vtg-bgl12-00a-vg2(config)#voice call disc-pi-off

vtg-bgl12-00a-vg2(config)#exit

vtg-bgl12-00a-vg2#

still I am getting 22 sec delay in disconnecting the call

Actions

This Discussion