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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12575 
====================================================================== 
Reported By:                nvrpunk
Assigned To:                mnicholson
====================================================================== 
Project:                    Asterisk
Issue ID:                   12575
Category:                   Core/Jitterbuffer
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
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:             2008-05-02 14:36 CDT
Last Modified:              2008-11-25 17:29 CST
====================================================================== 
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0095523) mnicholson (administrator) - 2008-11-25 17:29
 http://bugs.digium.com/view.php?id=12575#c95523 
---------------------------------------------------------------------- 
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). 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-11-25 17:29 mnicholson     Note Added: 0095523                          
======================================================================