Compare commits

..

5 Commits

Author SHA1 Message Date
Shaun Ruffell
7659b102d4 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
2009-07-02 19:15:01 +00:00
Shaun Ruffell
b0180e3283 Update the .version file to 1.4.10.1
git-svn-id: https://origsvn.digium.com/svn/libpri/tags/1.4.10.1@935 2fbb986a-6c06-0410-b554-c9c1f0a7f128
2009-07-02 19:09:43 +00:00
Matthew Fredrickson
b6d92b91b4 git-svn-id: https://origsvn.digium.com/svn/libpri/tags/1.4.10.1@929 2fbb986a-6c06-0410-b554-c9c1f0a7f128 2009-06-30 15:43:39 +00:00
Matthew Fredrickson
fe23002233 ------------------------------------------------------------------------
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 #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.

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


git-svn-id: https://origsvn.digium.com/svn/libpri/tags/1.4.10.1@928 2fbb986a-6c06-0410-b554-c9c1f0a7f128
2009-06-30 15:37:25 +00:00
Matthew Fredrickson
09eb3b1453 git-svn-id: https://origsvn.digium.com/svn/libpri/tags/1.4.10.1@927 2fbb986a-6c06-0410-b554-c9c1f0a7f128 2009-06-30 15:34:46 +00:00
3 changed files with 37 additions and 5 deletions

View File

@@ -1 +1 @@
1.4.10
1.4.10.1

View File

@@ -1,3 +1,37 @@
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.

6
q921.c
View File

@@ -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) {