Summary:ASTERISK-02206: negative lag causes jitter buffer to grow larger than maxexcessjitter setting
Reporter:Andrew Kohlsmith (akohlsmith)Labels:
Date Opened:2004-08-09 09:44:53Date Closed:2011-06-07 14:10:00
Versions:Frequency of
Description:iax2 show channels
Peer             Username    ID (Lo/Rem)  Seq (Tx/Rx)  Lag      Jitter  JitBuf  Format      benphone    16386/16388  00202/00199  -00001ms  0001ms  0101ms  GSM
1 active IAX channel(s)

Now mathematically this is correct but the jitter code should check for sane lag and act accordingly.  :-)

How am I getting -ve lag anyway?
Comments:By: Olle Johansson (oej) 2004-08-09 10:41:16

Please report according to instructions.
- What version of asterisk are you using?
- On which o/s?
- Which client on the other end?

By: Andrew Kohlsmith (akohlsmith) 2004-08-09 10:51:15

ugh I am sorry, I helped jerjer track down a bug in iax+jitter+native bridge and had that in my head.

CVS HEAD 20040807
Linux 2.4.25 (Slackware 9.1)

connecting to either my office * box (identical hardware and software) or Nufone (who uses RC1 IIRC).  The -ve lag is usually (but not always) when talking to my office * box which is one hop away -- both office* and colo* machines have dual Intel 82546EB ethernet (lspci reports Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 01)) -- eth1 on each machine connects to the other over a Pairgain SDSL modem synced at 2048kbps.  

Wiring setup:

T100P - office* - eth1 - SDSL - eth1 - colo* + TE405P - Bell Canada PRI
                                            + eth0 - fw - ADSL - nufone

everything going over ethernet is IAX2.  GSM codec.

By: Brian West (bkw918) 2004-08-10 12:43:27

try turning off the jitter buffer... It might be whats causing the problem.  If you have Point A B and C...

Call goes from A -> C -> B   C should not have a jitter buffer AT ALL.

By: zoa (zoa) 2004-08-10 14:08:32

The problem with the current jitter buffer implementation is, that when you do Lan -> Lan -> internet

You cannot do a Lan -> internet jitter buffer without having a lan -> lan jitter buffer (at least a one way one).

By: Andrew Kohlsmith (akohlsmith) 2004-08-10 14:12:12

I believe you're incorrect, Brian...

> Call goes from A -> C -> B C should not have a jitter buffer AT ALL.

A is Nufone, C and B are one hop from each other (C is colo, B is business)

B never sees more than 2-6ms lag and no jitter.  Jitter buffering there helps nothing, as all the jitter is seen in the A -> C leg.

By: twisted (twisted) 2004-08-20 00:42:24

akohlsmith, bkw was suggesting turning the buffer off, not turning it on, or up.

By: Mark Spencer (markster) 2004-08-30 00:58:31

What's the story right now on this one?

By: zoa (zoa) 2004-08-30 06:35:05

i think this is one for steve daviesfan :)

By: Brian West (bkw918) 2004-09-13 17:50:26

No you shouldn't have a jitter buffer in the middle at all.. You think of it like a bucket.. if voice packets have to fill every bucket (jitter buffer) along the way then you have a chance to starve the jitter buffer at one end or even both in that case.  Thats fine if you think i'm incorrect i'm just saying jitter buffer in the middle is bad.  I speak from experience.

By: Brian West (bkw918) 2004-09-13 17:51:09

Also just an fyi when you have a jitter buffer in the middle you'll cause lag jump up higher.

By: Brian West (bkw918) 2004-09-14 12:08:58

We had this hit us HARD today.. any way to fix it yet?

x.x.x.x      ulaw        00008/00009  00030/00161  240451604ms  0001ms  0000ms  ULAW
x.x.x.x      ulaw        00010/00012  00002/00002  00000ms  0000ms  0000ms  ULAW
x.x.x.x      ulaw        00011/00010  00125/00049  -1297154045ms  0001ms  0000ms  ULAW
x.x.x.x      ulaw        00015/00013  00036/00035  00003ms  0000ms  0000ms  ULAW
x.x.x.x    ulaw        00017/00006  00047/00045  00027ms  0003ms  0000ms  ULAW
x.x.x.x      ulaw        00018/00003  00091/00091  00006ms  0001ms  0000ms  ULAW
x.x.x.x      ulaw        00020/00004  00087/00086  00003ms  0001ms  0000ms  ULAW
x.x.x.x      box    00022/00003  00167/00165  00040ms  0005ms  0000ms  ULAW
x.x.x.x      ulaw        00025/00011  00008/00008  00005ms  0001ms  0000ms  ULAW
x.x.x.x       box  00028/21459  00039/00003  01477ms  0018ms  0000ms  GSM
x.x.x.x      ulaw        00037/00016  00126/00091  831127572ms  0001ms  0000ms  ULAW
x.x.x.x    ulaw        00047/00004  00122/00119  00029ms  0003ms  0000ms  ULAW
x.x.x.x      ulaw        00048/00008  00076/00072  00004ms  0000ms  0000ms  ULAW
x.x.x.x      ulaw        00049/00018  00072/00071  00006ms  0004ms  0000ms  ULAW
x.x.x.x    ulaw        00052/00008  00036/00035  00029ms  0004ms  0000ms  ULAW
x.x.x.x      ulaw        00054/00002  00016/00016  65542ms  0000ms  0000ms  ULAW
x.x.x.x     bkw         00059/00007  00112/00108  00060ms  0005ms  0000ms  G726
x.x.x.x      ulaw        00073/00007  00191/00011  -171638781ms  0001ms  0000ms  ULAW
x.x.x.x   user-gsm  16384/16385  00040/00059  00220ms  6291456ms  0000ms  GSM
x.x.x.x   user-gsm  16385/16384  00240/00249  00230ms  6291456ms  0000ms  GSM
x.x.x.x   user-gsm  16386/16386  00018/00027  00244ms  6291457ms  0000ms  GSM
x.x.x.x       ast1      16387/16385  00010/00019  02046ms  0003ms  0000ms  GSM
x.x.x.x   user-gsm  16389/16388  00128/00137  00231ms  6291456ms  0000ms  GSM
x.x.x.x   user-gsm  16391/16391  00024/00043  00240ms  750304151ms  0000ms  GSM
x.x.x.x       ast1      16392/16387  00160/00180  00040ms  0002ms  0000ms  GSM
x.x.x.x   user-gsm  16394/16389  00156/00165  00240ms  6291456ms  0000ms  GSM
x.x.x.x   user-gsm  16395/16392  00200/00209  -134938404ms  6291456ms  0000ms  GSM


By: Mark Spencer (markster) 2004-10-01 23:20:36

Is this still an issue with 1.0 or later?  If so, please get steven davies involved!

By: twisted (twisted) 2004-10-27 16:22:53

Another request for update post-1.0, since this appears to be a valid bug.

By: Russell Bryant (russell) 2004-11-07 19:52:55.000-0600

Hello?  Anyone?  Is this still an issue?

-- Housekeeping

By: Brian West (bkw918) 2004-11-08 09:27:26.000-0600

I haven't seen this as of late.  I suspect that a make clean wasn't done and the struct was out of whack.  (we all know how this can cause asterisk to act funny)