VoIP Mailing List Archives

[fh at danovation.dk]

scenario is incoming calls on ZAP (TE410p euro isdn) to SIP (or any
other channel) and call is answered.

When I hangup on the ISDN side on the 1.2 then the SIP hangs up to
immidiatly so everything is fine (se short pri debug below).

When I do the same on 1.4.20 then it take more than 30 seconds to
disconnect when the ISDN calling party hangs up

I have tried to use the use the 1.4 zaptel with the 1.2 installation,
that works perfect to so to me it looks like a libpri or chan_zap problem.
I do hope though that some has a hint to where I scre... up.

Freddi
OK trace from 1.2

< Protocol Discriminator: Q.931 ( len=13
< Call Ref: len= 2 (reference 7603/0x1DB3) (Originator)
< Message type: DISCONNECT (69)
< [08 02 80 90]
< Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0
Location: User (0)
< Ext: 1 Cause: Normal Clearing (16), class = Normal
Event (1) ]
< [1e 02 82 88]
< Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0)
0: 0 Location: Public network serving the local user (2)
< Ext: 1 Progress Description: Inband
information or appropriate pattern now available. ( ]
-- Processing IE 8 (cs0, Cause)
-- Processing IE 30 (cs0, Progress Indicator)
-- Channel 0/14, span 1 got hangup request
== Spawn extension (Pstn-incoming-fwd, 77348855, 2) exited non-zero on
'Zap/14-1'
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication,
peerstate Disconnect Request

[fh at danovation.dk]

Hi I better answer my own post.

I went to the code and the issue is in q931.c

/* wait for a RELEASE so that sufficient time has passed
for the inband audio to be heard */

if (c->progressmask & PRI_PROG_INBAND_AVAILABLE)
break;

Changing this line to a comment makes the 1.4 work exactly as 1.2 for
this issue.
I think that this line should only be executed on 'outbound' pri calls,
not on inbound.

Freddi