[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:              06-26-2008 08:15 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 - 06-26-08 08:15  
---------------------------------------------------------------------- 
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 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-26-08 08:15  stevedavies    Note Added: 0089277                          
======================================================================