No subject

int q921_transmit_iframe(struct pri *pri, void *buf, int len, int cr)
{
...
        f->h.n_s = pri->v_s;
        f->h.n_r = pri->v_r;
-->     pri->v_s++; /* not incremented at the end of transmission, but probably okay? */
        pri->v_na = pri->v_r;
        f->h.p_f = 0;
        f->h.ft = 0;
...
  if (!pri->retrans && !pri->busy) {
            if (pri->windowlen < pri->window) {
                pri->windowlen++;
                q921_transmit(pri, (q921_h *)(&f->h), f->len); /* send it */
                f->transmitted++;
            } else {
                /* frame not transmitted here, yet v_s has already been incremented */

Libpri may be handling things differently than I think or perhaps I am misreading the code/spec. Since I know very little about PRI and ISDN in general, it would help me greatly if I could get help verifying that the Q.921 implementation is working properly. It's quite possible though that libpri is functioning perfectly and chan_dahdi needs fixing, in which case I suspect some type of locking problem is responsible. Sometimes the core show locks output shows the lock info for the dahdi_hangup lock is corrupted with high correlation (but not high enough to be sure) to rejected frames occurring. It might be worthwhile for me to investigate the lock timings using murf's mtxprof branch, but that code is based on 1.6.

And if all of that is too specific are others at least also seeing the rejected frames occurring?