[Home]

Summary:ASTERISK-11963: IAX forcejitterbuffer + maxjitterbuffer
Reporter:Tim Nelson (nvrpunk)Labels:
Date Opened:2008-05-02 14:36:28Date Closed:2009-02-06 12:55:34.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/Jitterbuffer
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When creating a jitterbuffer via IAX not trunked or trunked and then force jitterbuffer, the maxjitterbuffer size does not seem to actually *stick* as core debug messages state it is attempting to exceed the max time slots of 600 even though maxjitterbuffer is set to 400 with a maxexcess of 80.  

At some point this will either disconnect the call or the audio will stop.  It varies on length of time but as the call duration lengthens the more often it seems to happen until the buffer seems to just overflow and stop the call.

****** ADDITIONAL INFORMATION ******

High latency wireless network in Iraq, path is as follows.

Iraq via Satellite -> Teleport via Fibre -> USA.  Asterisk boxes between Iraq and Teleport.  Teleport has a receive buffer for the IAX path so technically our outgoing traffic is buffered due to the latency on the link.  It then flows out via SIP to the PSTN Gateway at Vitelity.
Comments:By: Tim Nelson (nvrpunk) 2008-05-02 17:36:33

Exact message:

[May  3 02:24:28] DEBUG[18750]: jitterbuf.c:535 jb_put: Attempting to exceed Jitterbuf max 600 timeslots
[May  3 02:24:29] DEBUG[18746]: jitterbuf.c:535 jb_put: Attempting to exceed Jitterbuf max 600 timeslots

iax2 show netstats:

                               -------- LOCAL ---------------------  -------- REMOTE --------------------
Channel                    RTT  Jit  Del  Lost   %  Drop  OOO  Kpkts  Jit  Del  Lost   %  Drop  OOO  Kpkts
IAX2/jackalteleport-11169  579  126  181   234   0    57  503     24    0   40     0   0     0    0      0
1 active IAX channel
By: Steve Davies . (stevedavies) 2008-06-26 07:29:25

Hi,

We are seeing this message too, with a customer complaining that his calls go to "one way audio".
At this stage I'm not sure whether the message is a symptom of underlying IP issues or a symptom of some bug.

Looking at it now to see what I can find.  I'm running SVN branch 1.4 rev 121599

Steve
By: Steve Davies . (stevedavies) 2008-06-26 08:15:32

Hi,

My gut says that this is some regression introduced in these two commits (but could the issue have been there so long?):

------------------------------------------------------------------------
r52506 | russell | 2007-01-29 18:54:27 +0200 (Mon, 29 Jan 2007) | 5 lines

Clean up a few things in the last commit to the adaptive jitterbuffer code.
- Specifically indicate to the compiler that the "dropem" variable only
  needs one but.
- Change formatting to conform to coding guidelines.

------------------------------------------------------------------------
r52494 | jdixon | 2007-01-29 06:18:36 +0200 (Mon, 29 Jan 2007) | 4 lines

Fixed problem with jitterbuf, whereas it would not complain about, and
would allow itself to be overfilled (per the max_jitterbuf parameter). Now
it rejects any data over and above that size, and complains about it.


Here's the diff:

svn diff -r52265 jitterbuf.c
Index: jitterbuf.c
===================================================================
--- jitterbuf.c (revision 52265)
+++ jitterbuf.c (working copy)
@@ -512,17 +512,31 @@

enum jb_return_code jb_put(jitterbuf *jb, void *data, const enum jb_frame_type type, long ms, long ts, long now)
{
+ long numts;
+
jb_dbg2("jb_put(%x,%x,%ld,%ld,%ld)\n", jb, data, ms, ts, now);

jb->info.frames_in++;

+ if (jb->frames && jb->dropem)
+ return JB_DROP;
+ jb->dropem = 0;
+
if (type == JB_TYPE_VOICE) {
/* presently, I'm only adding VOICE frames to history and drift calculations; mostly because with the
* IAX integrations, I'm sending retransmitted control frames with their awkward timestamps through */
if (history_put(jb,ts,now,ms))
return JB_DROP;
}
-
+ numts = 0;
+ if (jb->frames)
+ numts = jb->frames->prev->ts - jb->frames->ts;
+ if (numts >= jb->info.conf.max_jitterbuf) {
+ ast_log(LOG_DEBUG, "Attempting to exceed Jitterbuf max %ld timeslots\n",
+ jb->info.conf.max_jitterbuf);
+ jb->dropem = 1;
+ return JB_DROP;
+ }
/* if put into head of queue, caller needs to reschedule */
if (queue_put(jb,data,type,ms,ts)) {
return JB_SCHED;


My theory is that jb->dropem somehow ends up "stuck" true.  Some flaw with the logic in there which is waiting for the jb to completely empty.

Steve
By: Steve Davies . (stevedavies) 2008-07-01 09:53:30

Hi,

I've been doing extensive testing looking at the behaviour of this patch.

Firstly: my theory that "dropem" gets stuck true was wrong.  Or, at least, I haven't been able to make it get stuck true.  

The behaviour that I see with this code is: dropem gets set to true when the jitter buffer tries to get bigger than the maxjitterbuffer.  Then is stays true (and all audio gets dropped) until such time as the jitter buffer is completely empty.

But that creates a big blank space in the call.  And if the measured jitter stays higher than max jitter buffer, I can imagine that the behaviour will be very unsatisfactory (not that a call with 100s of milliseconds of jitter is going to sound good).

The jitter buffer already had logic to limit the maximum jitter buffer size.  You see it in action when you see this in the log: "clamping target from 244 to 150"  244 is the actual jitter measured, 150 is the maximum jitter buffer size configured.

So I still don't see what jdixon's change is trying to do and I think it makes things worse when there is lots of jitter.

My next test will be to revert this change and see if the jitter buffer really gets bigger than the configured maximum.

Steve
By: Steve Davies . (stevedavies) 2008-07-01 10:25:09

OK -

I disabled the "dropem" logic and retested.

My conclusion is that the existing code (which "clamps" the jitter buffer size to the max_jitterbuf figure) works fine except that the jitterbuffer can briefly grow larger than the max size.

I set a very small max_jitterbuffer and saw lots of "clamping" messages and audio evidence of the missing packets (that arrived too late for the configured jitter buffer size), but there were no big blank spots, just jittery audio.  I much prefer that is users will understand that as network issues, but a big blank spot sounds like a system problem.

My conclusion is that the jitterbuffer.c code works better as Steve Kann originally wrote it and without this change from jdixon and I'd recommend that the change be reverted.

Regards,
Steve
By: Leif Madsen (lmadsen) 2008-11-24 13:54:29.000-0600

I'm acknowledging this issue, and going to assign to mnicholson for now, however he may not be the best person to actually look into this issue.

Please reassign this issue as appropriate.
By: Matthew Nicholson (mnicholson) 2008-11-25 17:29:17.000-0600

Steve,

Your analysis of the behavior of the dropem flag appears correct.  Once it is set, the buffer will not accept any new frames until it is empty.  I am not sure if this was the intended behavior or not.  I do believe that the problem the dropem patch is desgined to solve may be a real problem, I will have to study the code further to determine if that is the case or not.

As far as the original bug report, I have not looked into that yet, and will probably have more information on Monday (2008-12-01).
By: Andrey Sofronov (andrey sofronov) 2008-12-08 05:28:50.000-0600

I have a similar issue - sometimes I get "one-way audio" on IAX2 trunks that use jitterbuffer. The calling party can hear the remote party, but the remote party hears silence. The only way that helps is "unload module chan_iax2.so && load module chan_iax2.so". Also disabling jitterbuffer and iax2 reload helps, but I can't use WAN trunks without jb.

Removing dropem logic does not help me.
By: Matthew Nicholson (mnicholson) 2008-12-08 09:06:54.000-0600

Andrey,

You should file a separate bug report for that issue.
By: Matthew Nicholson (mnicholson) 2008-12-09 12:13:39.000-0600

I don't see how the original issue where maxjitterbuf is not honored can occur.  The default value is 1000, so if you are seeing 600 in your logs, it must be getting set to 600 somewhere.
By: Matthew Nicholson (mnicholson) 2008-12-09 12:17:49.000-0600

Please see bug 14044 (http://bugs.digium.com/view.php?id=14044) for a patch for the dropem issue.


By: Matthew Nicholson (mnicholson) 2008-12-09 12:18:42.000-0600

I need more information from the original poster to determine if the original issue is actually a bug in asterisk.
By: Anton Vazir (vazir) 2009-01-24 04:24:35.000-0600

Confirming the issue in 1.4.21.2 - switched off JB for a time being.
By: Anton Vazir (vazir) 2009-01-24 04:25:44.000-0600

Addition - I use low latency 100mb LAN - and issue exists with complaint of 1000 ts.
By: Tim Nelson (nvrpunk) 2009-01-24 05:06:00.000-0600

mnicholson,

What additional information do you need from me?  Please be specific in your needs.  We are still having the issue, it drops audio from time to time.  Overall things seem to work but there is definitely still an issue with Jitterbuffer on our IAX trunk.  It's not an issue with our link and we have done thorough troubleshooting to ensure.
By: Matthew Nicholson (mnicholson) 2009-01-26 09:14:47.000-0600

nvrpunk,

Well the original issue you posted about says that the maxjitterbuffer setting does not work.  Additional posters identified another issue which I addressed in bug 14044.  I need more information about the maxjitterbuffer setting not working, as I did not see how that would be possible after looking at the code.


By: Matthew Nicholson (mnicholson) 2009-02-06 12:55:34.000-0600

I am closing this bug, as I am unable to reproduce it.