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

noreply at bugs.digium.com noreply at bugs.digium.com
Thu Jul 10 09:46:41 CDT 2008


The following issue has been SUBMITTED. 
====================================================================== 
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:46 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

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

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-10-08 09:46  fst-onge       Asterisk Version          => 1.4.21          
07-10-08 09:46  fst-onge       SVN Branch (only for SVN checkou => N/A          
  
======================================================================




More information about the asterisk-bugs mailing list