[svn-commits] sruffell: tag 1.4.10.1 r936 - /tags/1.4.10.1/ChangeLog

[SVN commits to the Digium repositories]

Author: sruffell
Date: Thu Jul  2 14:15:01 2009
New Revision: 936

URL: http://svn.asterisk.org/svn-view/libpri?view=rev&rev=936
Log:
Limiting last entry to 80 columns

Modified:
    tags/1.4.10.1/ChangeLog

Modified: tags/1.4.10.1/ChangeLog
URL: http://svn.asterisk.org/svn-view/libpri/tags/1.4.10.1/ChangeLog?view=diff&rev=936&r1=935&r2=936
==============================================================================
--- tags/1.4.10.1/ChangeLog (original)
+++ tags/1.4.10.1/ChangeLog Thu Jul  2 14:15:01 2009
@@ -1,27 +1,36 @@
 2009-04-18 Matthew Fredrickson <creslin at digium.com>
 
 	* 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:
-
-	* 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.
-
-	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 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.
+
+	  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).
+
+	  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 <creslin at digium.com>