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-0600 | Date Closed: | 2011-06-07 14:02:59 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_iax2 |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
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: LVllLVllLVllLVllLVllLVllLVllLVllLVllLVllLVllLVllLV llLVllLVllLVlLVllLVllLVllLVlLVlLVllLVllLVllLVllLVl 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 [10.10.2.250:4569] Tx-Frame Retry[000] -- OSeqno: 047 ISeqno: 050 Type: IAX Subclass: PONG Timestamp: 1890500ms SCall: 16385 DCall: 00002 [10.10.2.250:4569] RR_JITTER : 8 RR_LOSS : 436198044 RR_PKTS : 33626 RR_DELAY : 48 RR_DROPPED : 0 RR_OUTOFORDER : 0 Rx-Frame Retry[ No] -- OSeqno: 050 ISeqno: 048 Type: IAX Subclass: ACK Timestamp: 1890500ms SCall: 00002 DCall: 16385 [10.10.2.250:4569] Rx-Frame Retry[ No] -- OSeqno: 050 ISeqno: 048 Type: IAX Subclass: LAGRQ Timestamp: 1890672ms SCall: 00002 DCall: 16385 [10.10.2.250:4569] Tx-Frame Retry[000] -- OSeqno: 048 ISeqno: 051 Type: IAX Subclass: LAGRP Timestamp: 1890672ms SCall: 16385 DCall: 00002 [10.10.2.250:4569] Rx-Frame Retry[ No] -- OSeqno: 051 ISeqno: 049 Type: IAX Subclass: ACK Timestamp: 1890672ms SCall: 00002 DCall: 16385 [10.10.2.250:4569] 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! |