Summary:ASTERISK-11168: Low trunk frequency + jitter buffer = broken audio, weird netstats
Reporter:nermal0 (nermal0)Labels:
Date Opened:2008-01-07 03:15:56.000-0600Date Closed:2011-06-07 14:02:59
Versions:Frequency of
Description:I'm using the latest Asterisk 1.4 SVN 96775 and speex 1.2beta3. Multiple speex calls are routed over an IAX2 link between two Asterisks. Trunking is enabled, with a trunk frequency of 60ms (default: 20ms). (NB: trunk "frequency" is misleading here as it really defines the time distance between two packets and not how many packets are sent per second). In codecs.conf, I've set:

preprocess => true
pp_vad => true

Now as soon as I enable the jitter buffer (and add forcejitterbuffer=yes as I'm on a jitter-free LAN for testing, but will move to a high delay link later) frames get lost and the audio is broken. "iax2 show netstat" shows:

machine1*CLI> iax2 show netstats
                               -------- LOCAL ---------------------  -------- REMOTE --------------------
Channel                    RTT  Jit  Del  Lost   %  Drop  OOO  Kpkts  Jit  Del  Lost   %  Drop  OOO  Kpkts
IAX2/loadtest14-2            1  121  161  -179  26     0    0      0  122  162 16777163  18     0    0      0
1 active IAX channel

note the "-179" lost packets on the local side and the "16777163" lost ones on the remote side (integer overflow?).

In Asterisk 1.2, the very same setup produces fine audio quality and no dropouts. I believe there is something seriously broken in the jitter buffer implementation of 1.4.

Thanks for any pointers on how to fix this!
Comments:By: Jared Smith (jsmith) 2008-01-07 14:30:09.000-0600

If I remember correctly, there are some jitterbuffer debugging tools you can enable from the Asterisk CLI.  Have you tried turning them on, to see if that helps debug the problem?

By: nermal0 (nermal0) 2008-01-09 19:09:10.000-0600

On the asterisk console I get a lot of these during the call:

[Jan 10 12:07:50] WARNING[398]: translate.c:156 framein: no samples for speextolin
[Jan 10 12:07:50] WARNING[398]: translate.c:192 framein: speextolin did not update samples 0

Enabling "iax2 set debug jb" only provides output like:


Enabling "iax2 set debug" gives me a lot of reports like:

Rx-Frame Retry[ No] -- OSeqno: 049 ISeqno: 047 Type: IAX     Subclass: PING  
  Timestamp: 1890500ms  SCall: 00002  DCall: 16385 []
Tx-Frame Retry[000] -- OSeqno: 047 ISeqno: 050 Type: IAX     Subclass: PONG  
  Timestamp: 1890500ms  SCall: 16385  DCall: 00002 []
  RR_JITTER       : 8
  RR_LOSS         : 436198044
  RR_PKTS         : 33626
  RR_DELAY        : 48
  RR_DROPPED      : 0

Rx-Frame Retry[ No] -- OSeqno: 050 ISeqno: 048 Type: IAX     Subclass: ACK    
  Timestamp: 1890500ms  SCall: 00002  DCall: 16385 []
Rx-Frame Retry[ No] -- OSeqno: 050 ISeqno: 048 Type: IAX     Subclass: LAGRQ  
  Timestamp: 1890672ms  SCall: 00002  DCall: 16385 []
Tx-Frame Retry[000] -- OSeqno: 048 ISeqno: 051 Type: IAX     Subclass: LAGRP  
  Timestamp: 1890672ms  SCall: 16385  DCall: 00002 []
Rx-Frame Retry[ No] -- OSeqno: 051 ISeqno: 049 Type: IAX     Subclass: ACK    
  Timestamp: 1890672ms  SCall: 00002  DCall: 16385 []

I hope this helps, please let me know if you need anything else to fix this bug.

By: nermal0 (nermal0) 2008-04-10 01:18:42

I've just checked out SVN 113597 to check whether the problem still exists. The good news is that I don't get any more weird numbers for the lost packet count of "iax2 show netstats".

The audio is still breaking up badly, it's impossible to understand a single word.

By: P. Christeas (xrg) 2008-04-10 02:44:20

Can you monitor the CPU usage when that happens?

By: nermal0 (nermal0) 2008-04-10 03:04:42

Asterisk incurs around 1-2% CPU load on a Dual Xeon 3.2GHz during a choppy call. There are occasional spikes to 10%. Load average is <0.1.

Packet loss as reported by "iax2 show netstats" is around 30-40%. Both asterisk servers are on the same 100MBit switch. The packet loss is not caused by the network, but probably by the jitter buffer implementation.

By: Leif Madsen (lmadsen) 2008-10-07 13:25:58

Since this bug has been sitting here for a while, I thought I'd check to see if the original poster still has these issues in the latest 1.4 version of Asterisk. 1.4.22 and 1.6.0 are now released. Any chances of trying your tests again?

By: Leif Madsen (lmadsen) 2009-01-09 13:22:32.000-0600

Suspended due to lack of activity. Please request a bug marshall on #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional issue requested. Thanks!