From 7659b102d45ea08d8ed69f9bf733bec2d0102430 Mon Sep 17 00:00:00 2001 From: Shaun Ruffell Date: Thu, 2 Jul 2009 19:15:01 +0000 Subject: [PATCH] Limiting last entry to 80 columns git-svn-id: https://origsvn.digium.com/svn/libpri/tags/1.4.10.1@936 2fbb986a-6c06-0410-b554-c9c1f0a7f128 --- ChangeLog | 43 ++++++++++++++++++++++++++----------------- 1 file changed, 26 insertions(+), 17 deletions(-) diff --git a/ChangeLog b/ChangeLog index 1fcdff7..a161ee3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,27 +1,36 @@ 2009-04-18 Matthew Fredrickson * libpri 1.4.10.1 released. Includes a fix for a regression found in - the last few revisions of libpri, but fixed in revision 859 of - branches/1.4. The summary is as follows: + the last few revisions of libpri, but fixed in revision 859 of + branches/1.4. The summary is as follows: - * q921.c: There are two changes in this commit that are bug fixes for various Q.921 issues found in internal testing. + * q921.c: 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 #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. + Both were exposed/introduced by the TBR4 compliance patch for bug + #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). + 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. + 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. 2009-04-18 Matthew Fredrickson