[asterisk-bugs] [LibPRI 0012861]: [patch] TBR4 conformance

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=12861 
====================================================================== 
Reported By:                tzafrir
Assigned To:                mattf
====================================================================== 
Project:                    LibPRI
Issue ID:                   12861
Category:                   General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 571 
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-06-14 16:31 CDT
Last Modified:              2009-06-30 10:37 CDT
====================================================================== 
Summary:                    [patch] TBR4 conformance
Description: 
We needed the following changes in order to pass a TBR4 conformance test.

Several issues we encountered:

1. Handling of received REJ frames is completely incorrect.
2. In some cases the C/R and P/F bits are not set correctly.
3. When the last I-frame retransmission is required the first frame in
the
queue was retransmitted. But if there are several not yet acknowledged
frames
in the queue then such behavior is not correct because the last
transmitted
frame is not at the queue head.
4. N(R) from received RNR was not considered as acknowledge for
outstanding
I-frames.
5. Frames retransmission was performed N200-1 times instead of N200
times.
6. Timers T200 and T203 sometimes were not restarted. (Timer was not
reset
if it was started before).

Traces that demonstrate those issues are included in the attached file 
First-L2test-results.txt .
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0012153 [patch] librpi: Data link layer does no...
====================================================================== 

---------------------------------------------------------------------- 
 (0107238) svnbot (reporter) - 2009-06-30 10:37
 https://issues.asterisk.org/view.php?id=12861#c107238 
---------------------------------------------------------------------- 
Repository: libpri
Revision: 928

U   tags/1.4.10.1/q921.c

------------------------------------------------------------------------
r928 | mattf | 2009-06-30 10:37:25 -0500 (Tue, 30 Jun 2009) | 24 lines

------------------------------------------------------------------------
r859 | mattf | 2009-06-09 14:47:05 -0500 (Tue, 09 Jun 2009) | 19 lines

There are two changes in this commit that are bug fixes for various Q.921
issues found in internal testing.

Both were exposed/introduced by the TBR4 compliance patch for bug
https://issues.asterisk.org/view.php?id=12861,
in changing how retransmissions and in how
the transmission queue was maintained.  TX-RX message flow and
acknowledgement was severely restricted,
since the patch changed the behavior so that pending untransmitted frames
would not actually be send until
the next RR was received in normal circumstances, or REJ when a reject
frame was received.  On busy links,
this can severly limit the amount of useful traffic that is sent, and can
slow down message transmission.

Until someone can point out where in Q.921 it is mandated for us to wait
for RR frames to start sending
untransmitted messages, the first change is to allow us to send
untransmitted frames when we receive new
I frames as well, with updated N(R).

The other bug fixed is a situation caused by the restricted traffic flow,
if an outside process tries to send
an I-frame asynchronous to an RR frame, when the transmit window was
previously closed and then opened up but 
an RR has not been received yet.  A bug was found with the integration of
the old transmit code with the new reject 
handling code which caused the new frame to be sent immediately,
regardless if there were any pending untransmitted 
I-frames in the queue to be sent and causing an out of order I-frame to be
sent to the other side.  This bug is 
also fixed in this patch.

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

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-30 10:37 svnbot         Note Added: 0107238                          
======================================================================