[asterisk-bugs] [LibPRI 0016950]: PRI i-frames sent out of order, causing REJ supervisory frame

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16950 
====================================================================== 
Reported By:                alecdavis
Assigned To:                mattf
====================================================================== 
Project:                    LibPRI
Issue ID:                   16950
Category:                   General
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
JIRA:                        
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 250260 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2010-03-03 02:04 CST
Last Modified:              2010-03-03 18:00 CST
====================================================================== 
Summary:                    PRI i-frames sent out of order, causing REJ
supervisory frame
Description: 
Capturing both sides of a couple of calls reveals asterisk sends frames out
of order, with the wrong n(s) value.

The result is a REJ Supervisory frame from the switch, and then asterisk
does the retransmisson.

Happens when processing more than 2 calls are concurrently being
setup/torn down.


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

---------------------------------------------------------------------- 
 (0118922) mattf (administrator) - 2010-03-03 18:00
 https://issues.asterisk.org/view.php?id=16950#c118922 
---------------------------------------------------------------------- 
It would appear that this issue is caused by a normal layer 1 frame
drop/loss condition.  The layer 2 trace pretty clearly shows that the frame
was dropped and not received by the JTEC, but the subsequent frames were
received.  The REJ frame was transmitted because of the frame sequence
error (due to the lost REL COMPL I-frame), and the frames were
retransmitted.

This means that the Q.931 debug that the switch gives though looks like
the switch either has a bug in its Q.921<->Q.931 boundary layer (since the
Q.931 trace originally given from the JTEC makes it look like the out of
order frames received were passed up to Q.931 when they shouldn't have
been, due to the N(S) sequence error caused by the lost frame), or a bug in
its Q.931 dumping code, in that it shouldn't be dumping those frames
because they shouldn't be passed up to Q.931 anyways, until the lost frame
is retransmitted. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-03-03 18:00 mattf          Note Added: 0118922                          
======================================================================