[asterisk-bugs] [LibPRI 0018255]: SABME flood on backup D-channel in NFAS configuration

[Asterisk Bug Tracker]

The following issue has been RESOLVED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18255 
====================================================================== 
Reported By:                bklang
Assigned To:                rmudgett
====================================================================== 
Project:                    LibPRI
Issue ID:                   18255
Category:                   General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     resolved
Asterisk Version:           1.8.0 
JIRA:                       SWP-2508 
libpri Version:             SVN 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!): 2093 
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2010-11-04 15:29 CDT
Last Modified:              2010-11-10 18:30 CST
====================================================================== 
Summary:                    SABME flood on backup D-channel in NFAS
configuration
Description: 
I have a group of 6 spans configured in an NFAS configuration.  Primary
D-channel is on span 1, channel 24; secondary is on span 2, channel 24.  In
libpri 1.4.10 and earlier the secondary D-channel remains disconnected as
long as the primary D-channel is connected.  About once a second the
secondary D-channel sends a SABME to bring up the connection, to which it
receives a DM indicating the connection is down.

Starting in 1.4.11 (and still true as of SVN rev 2093) the secondary
D-channel sends SABMEs as quickly as it receives DMs.  On my machine I saw
38 SABME/DMs every second on the secondary (down) D-channel.  At a minimum
this makes for VERY noisy debug logs, so noisy as to be almost useless.

I've been reading Q.921 to determine the appropriate timeout.  While I
can't point to a specific timeout, I can see that upon receiving a DM the
CPE should reset T200.  T200 is recommended to be a minimum of 1 second.  I
believe this means another SABME should not be sent until T200 expires, but
I may be wrong.

I have Asterisk console output and ISDN pcap displaying the condition I am
describing.  I can attach either to this ticket if requested.
====================================================================== 

---------------------------------------------------------------------- 
 (0128766) svnbot (reporter) - 2010-11-10 18:30
 https://issues.asterisk.org/view.php?id=18255#c128766 
---------------------------------------------------------------------- 
Repository: libpri
Revision: 2111

U   branches/1.4/pri_internal.h
U   branches/1.4/q921.c

------------------------------------------------------------------------
r2111 | rmudgett | 2010-11-10 18:30:33 -0600 (Wed, 10 Nov 2010) | 15 lines

SABME flood on backup D-channel in NFAS configuration.

Made delay restarting the PTP layer 2 link by the T200 time instead of
immediately.  Q.921 does not specify any particular time to restart the
layer 2 link.  Q.921 leaves it up to the upper layers to decide when or if
another attempt to bring layer 2 up is made.  Earlier versions of libpri
used the T200 time to restart the link.

This is a reimplementaion of -r1878.

(closes issue https://issues.asterisk.org/view.php?id=18255)
Reported by: bklang

JIRA SWP-2508

------------------------------------------------------------------------

http://svn.digium.com/view/libpri?view=rev&revision=2111 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-11-10 18:30 svnbot         Checkin                                      
2010-11-10 18:30 svnbot         Note Added: 0128766                          
2010-11-10 18:30 svnbot         Status                   assigned => resolved
2010-11-10 18:30 svnbot         Resolution               open => fixed       
======================================================================