[asterisk-bugs] [LibPRI 0012153]: librpi: Data link layer does not re-establish connection as described in section 5.8.9 of Q.931

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12153 
====================================================================== 
Reported By:                alerios
Assigned To:                mattf
====================================================================== 
Project:                    LibPRI
Issue ID:                   12153
Category:                   General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 suspended
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-03-05 15:21 CST
Last Modified:              2008-09-15 10:58 CDT
====================================================================== 
Summary:                    librpi: Data link layer does not re-establish
connection as described in section 5.8.9 of Q.931
Description: 
I'm having incoming call drops in different systems, all with the same
pattern:   

The call is established normally, with STETUP, CALL_PROCEDING, CONNECT,
and CONNECT_ACK, but then after a random while we get a DISCONNECT (cause
27) from the Telco, followed by our RELEASE and RELEASE_COMPLETE.

According to section 5.8.9 of ITU-T Q.931 (05/98), the DISCONNECT message
with cause 27 (destination out of order) is sent by the Telco wen its
internal T309 timer expires after trying to re-establish layer 2
connection.  Looking at the Q921 supervisory messages, it seems that no
frame errors are detected by libpri, or at least they are not shown.

This may be a telco side-issue related to their t309 timer, but I still
believe asterisk+libpri have something to do with it because when using an
ISDN tester or a legacy PBX the calls don't get dropped.
====================================================================== 

---------------------------------------------------------------------- 
 (0092508) alerios (reporter) - 2008-09-15 10:58
 http://bugs.digium.com/view.php?id=12153#c92508 
---------------------------------------------------------------------- 
Hi.

After several months of tracking and debugin this issue with the Telco
side, we found out that the problem shows up when the broadband PSTN
carrier uses an interurban CO NEC Neax which doesn't handle the ISDN-to-SS7
translation in a propper manner:

- When we send CALL_PROCEEDING and then CONNECT, the NEC CO sends an SS7
ACM message to the other end and triggers a timer waiting for an ANM
message, hence making the call drop after 90 sec.

- When send CALL_PROCEEDING, followed by an ALERTING, and then CONNECT,
the call doesn't get dropped, and everything works fine.

(Also see recommendation Q.2650)


I'm attaching the patch where I forced the sending of ALERTING always
after CALL_PROCEEDING.  Its an awful hardcoded patch, but I hope someone
could adapt it to make it an option in zapata.conf in the future. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-15 10:58 alerios        Note Added: 0092508                          
======================================================================