[asterisk-bugs] [Asterisk 0012575]: IAX forcejitterbuffer + maxjitterbuffer

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12575 
====================================================================== 
Reported By:                nvrpunk
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12575
Category:                   Core/Jitterbuffer
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.19 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-02-2008 14:36 CDT
Last Modified:              07-01-2008 09:53 CDT
====================================================================== 
Summary:                    IAX forcejitterbuffer + maxjitterbuffer
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.
====================================================================== 

---------------------------------------------------------------------- 
 stevedavies - 07-01-08 09:53  
---------------------------------------------------------------------- 
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 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-01-08 09:53  stevedavies    Note Added: 0089512                          
======================================================================