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

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?

regards

Wayne

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.

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.

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.

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.