git-svn-id: https://origsvn.digium.com/svn/libpri/tags/1.4.10.2@1165 2fbb986a-6c06-0410-b554-c9c1f0a7f128

git-svn-id: https://origsvn.digium.com/svn/libpri/tags/1.4.10.2@1164 2fbb986a-6c06-0410-b554-c9c1f0a7f128

.version

@@ -1 +1 @@
-1.4.10
+1.4.10.2

ChangeLog

@@ -1,3 +1,45 @@
+2009-10-08 Matthew Fredrickson <creslin@digium.com>
+
+	* libpri 1.4.10.2 released.  A bug was found which was introduced
+	  during the PTMP rewrite, which causes timers to not be cleared
+	  before being set in certain situations.  This can cause the
+	  scheduler to be completely filled, as well as improper Q.921 link
+	  operation.
+
+2009-04-18 Matthew Fredrickson <creslin@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.
+
 2009-04-18 Matthew Fredrickson <creslin@digium.com>
 
 	* libpri 1.4.10 released.

pri.c

@@ -280,7 +280,7 @@ int pri_restart(struct pri *pri)
 {
 	/* Restart Q.921 layer */
 	if (pri) {
-		q921_reset(pri);
+		q921_reset(pri, 1);
 		q921_start(pri, pri->localtype == PRI_CPE);	
 	}
 	return 0;

pri_q921.h

@@ -186,7 +186,7 @@ extern void q921_dump(struct pri *pri, q921_h *h, int len, int showraw, int txrx
 /* Bring up the D-channel */
 extern void q921_start(struct pri *pri, int now);
 
-extern void q921_reset(struct pri *pri);
+extern void q921_reset(struct pri *pri, int reset_iqueue);
 
 extern pri_event *q921_receive(struct pri *pri, q921_h *h, int len);
 

q921.c

@@ -523,9 +523,7 @@ int q921_transmit_iframe(struct pri *pri, void *buf, int len, int cr)
 		   size is too big */
 		if ((pri->q921_state == Q921_LINK_CONNECTION_ESTABLISHED) && (!pri->retrans && !pri->busy)) {
 			if (pri->windowlen < pri->window) {
-				pri->windowlen++;
-				q921_transmit(pri, (q921_h *)(&f->h), f->len);
-				f->transmitted++;
+				q921_send_queued_iframes(pri);
 			} else {
 				if (pri->debug & PRI_DEBUG_Q921_DUMP)
 					pri_message(pri, "Delaying transmission of %d, window is %d/%d long\n", 
@@ -583,7 +581,7 @@ static pri_event *q921_handle_iframe(struct pri *pri, q921_i *i, int len)
 		Q921_INC(pri->v_r);
 		/* Handle their ACK */
 		pri->sentrej = 0;
-		ev = q921_ack_rx(pri, i->n_r, 0);
+		ev = q921_ack_rx(pri, i->n_r, 1);
 		if (ev)
 			return ev;
 		if (i->p_f) {
@@ -787,6 +785,12 @@ void q921_dump(struct pri *pri, q921_h *h, int len, int showraw, int txrx)
 
 static pri_event *q921_dchannel_up(struct pri *pri)
 {
+	if (pri->tei == Q921_TEI_PRI) {
+		q921_reset(pri, 1);
+	} else {
+		q921_reset(pri, 0);
+	}
+
 	/* Stop any SABME retransmissions */
 	if (pri->sabme_timer) {
 		pri_schedule_del(pri, pri->sabme_timer);
@@ -817,7 +821,7 @@ static pri_event *q921_dchannel_up(struct pri *pri)
 static pri_event *q921_dchannel_down(struct pri *pri)
 {
 	/* Reset counters, reset sabme timer etc */
-	q921_reset(pri);
+	q921_reset(pri, 1);
 	
 	/* Notify Layer 3 */
 	q931_dl_indication(pri, PRI_EVENT_DCHAN_DOWN);
@@ -827,10 +831,12 @@ static pri_event *q921_dchannel_down(struct pri *pri)
 	return &pri->ev;
 }
 
-void q921_reset(struct pri *pri)
+void q921_reset(struct pri *pri, int reset_iqueue)
 {
 	/* Having gotten a SABME we MUST reset our entire state */
-	pri->v_s = 0;
+	if (reset_iqueue)
+		pri->v_s = 0;
+
 	pri->v_a = 0;
 	pri->v_r = 0;
 	pri->v_na = 0;
@@ -855,7 +861,8 @@ void q921_reset(struct pri *pri)
 	pri->sentrej = 0;
 	
 	/* Discard anything waiting to go out */
-	q921_discard_retransmissions(pri);
+	if (reset_iqueue)
+		q921_discard_retransmissions(pri);
 }
 
 static void q921_tei_release_and_reacquire(struct pri *master)
@@ -1258,14 +1265,14 @@ static void q921_restart(struct pri *pri, int now)
 		return;
 	}
 	/* Reset our interface */
-	q921_reset(pri);
+	q921_reset(pri, 1);
 	/* Do the SABME XXX Maybe we should implement T_WAIT? XXX */
 	q921_send_sabme(pri, now);
 }
 
 void q921_start(struct pri *pri, int isCPE)
 {
-	q921_reset(pri);
+	q921_reset(pri, 1);
 	if ((pri->sapi == Q921_SAPI_LAYER2_MANAGEMENT) && (pri->tei == Q921_TEI_GROUP)) {
 		pri->q921_state = Q921_DOWN;
 		if (isCPE)