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

[noreply at bugs.digium.com]

The following issue has been RESOLVED. 
====================================================================== 
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:                     resolved
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:              
Resolution:                 duplicate
Duplicate:                  13042
Fixed in Version:           
====================================================================== 
Date Submitted:             07-10-2008 09:46 CDT
Last Modified:              07-10-2008 09:53 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

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
duplicate of        0013042 Patch for 10552 changes behavior people...
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 07-10-08 09:53  
---------------------------------------------------------------------- 
This is a duplicate of issue 13042, so I am closing this. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-10-08 09:53  putnopvut      Status                   assigned => resolved
07-10-08 09:53  putnopvut      Resolution               open => duplicate   
07-10-08 09:53  putnopvut      Note Added: 0090011                          
======================================================================