[asterisk-bugs] [LibPRI 0013052]: Asterisk do not RELEASE a pri channel after receiving a DISCONNECT in certain conditions

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13052 
====================================================================== 
Reported By:                fst-onge
Assigned To:                mattf
====================================================================== 
Project:                    LibPRI
Issue ID:                   13052
Category:                   General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.21 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             07-10-2008 09:46 CDT
Last Modified:              07-10-2008 09:49 CDT
====================================================================== 
Summary:                    Asterisk do not RELEASE a pri channel after
receiving a DISCONNECT in certain conditions
Description: 
Hello we did a major upgrade of one of our server to help solve some issues
but we are now having a new problem that is really major for our client.
The issue is related to PRI hangup or progress code.
 

Our old setup was :

Asterisk 1.2.24

Zaptel 1.2.21

Libpri 1.2.6

 

Our new setup :

Asterisk 1.4.21.1


Zaptel 1.4.10.1

Libpri 1.4.4

 
 

Our client has a PRI with Telus and they are using a pin number to
authenticate for long distance calls. Since our upgrade, it would seems
that when they call to some place that the line is busy the caller is
routed to somewhere else randomly instead of hearing congestion. Sometimes
they are routed to an existing calls and they are like in spying mode
meaning they call hear both parties without being heard. Telus are sure
something is wrong on our end. We tend to agree with them as before the
upgrade. If we disable the pin on the lines for doing long distance calls
the problem is not present. It would seems for wathever reason that our
system isn’t capable of detecting the HANGUPCAUSE correctly. Here is our
actual configs :

Zapata.conf :

 

 

[channels]

language=fr

usecallerid=yes

faxdetect=incoming

relaxdtmf=yes

callgroup=1

pickupgroup=1

group=1

context=from-pstn

rxgain=0

txgain=0

switchtype=dms100

priindication=outofband

pridialplan=unknown

prilocaldialplan=local

usecallingpres=yes

echocancel=no

signalling=pri_cpe

channel=>1-23

 

 

echocancel=128

echocancelwhenbridged=yes

echotraining=no

context=backdoor

group=2

signalling=fxs_ks

channel=>25-31

====================================================================== 

---------------------------------------------------------------------- 
 fst-onge - 07-10-08 09:49  
---------------------------------------------------------------------- 
our asterisk code that do the dial command :

 

exten =>
s,n(dial-number),Dial(${ARG1}/${ARG2}${ARG3},,gWM(setmusiconhold,default))

exten => s,n,NoOp(${HANGUPCAUSE})

exten => s,n,GotoIf($[${HANGUPCAUSE} = 17]?congestion)

exten => s,n,Hangup

 

exten => s,n(congestion),Playtones(congestion)

exten => s,n,Congestion

exten => s,n,Hangup

 

 

We used to trap HANGUPCAUSE 17 and play congestion. That was necessary for
systems which required a pin for long distance on our old setup.

 

At this point, we have no clue were the source of the problem is. Some new
Zapata.conf options? A bug in Libpri 1.4.4? We tried downgrading to libpri
1.4.3 but the issue is still there. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-10-08 09:49  fst-onge       Note Added: 0090010                          
======================================================================