| 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:53 | Date Closed: | 2011-06-07 14:10:00 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | iax2 show channels Peer Username ID (Lo/Rem) Seq (Tx/Rx) Lag Jitter JitBuf Format 192.168.2.1 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. bkw 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 bkw 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) bkw | ||