Summary:	ASTERISK-04209: [patch] new jb - patch to support resyncing the jb on dratic delay changes
Reporter:	grolloj (grolloj)	Labels:
Date Opened:	2005-05-17 16:28:48	Date Closed:	2011-06-07 14:10:38
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_iax2
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) jb_resync.patch.txt
Description:	The new jb behaves poorly when the calculated voice frame delays exhibit big discontinuities. A drastic change in delay may be caused by: 1) A change in the frames' timestamps. Frames are coming in 20, 40, 60, 80, and then jump to 5000, 5020, 5040, 5060. The jb sees this as a sudden increase in delay and tries to grow to dejitter the network delay. 2) Change in the 'now' parameter to jb_put. In other words, if the received time suddenly shows a big jump, frames will begin to appear very early or very late. There is currently a resyncing mechanism done in chan_iax2, based on TS_GAP_FOR_JB_RESYNC. That method can fail with the new jitter buffer. One late packet causes last to be reset to the time of the current packet. If the 16-bit timestamps are close to a roll over, this can cause unwrap_timestamp to fail to recognize the roll over (since the reset ts may be within 50000 of the correctly rolled over ts) and the delay will send the jb packing. In order to fix this, the patch does the following: * A resyncthreshold setting is available in iax.conf. To disable the new jb's resyncing, this can be set to -1. Otherwise, it's used in the threshold caculation for determining "drastic" delay changes. * The TS_GAP_FOR_JB_RESYNC code is only used for the old jitterbuffer. It doesn't play well with the new jb. * When a voice frame is added to the jitterbuffer, a delay is calculated for the frame. This had been the difference of now and the frame's ts. The last delay seen is tracked. * If, relative to the last seen delay, the current delay has jumped over a threshold value, the ts is seen as discontinuous. * The threshold value is calculate as (2 * jitter + resyncthreshold). This allows some configuration control as well as some adaptation to measured jitter. * Frames showing big discontinuities are dropped without being added to the jb. Their delay is not tracked. * If more than 3 frames in a row show a similar discontinuity, the jitterbuffer will reset it's stored jitter calculations and "resync" to the new delay offset. * The stored resync offset will be used to adjust future delay and will be taken into account when things are pulled out of the internal queue. In testing, the patch has worked well. 2 * jitter + rsyncthreshold seems like a safe heuristic. I've defaulted resyncthreshold to 1000. I also made a small change to the maxjitterbuffer setting in iax.conf.sample. Although set to 500 in the sample file, the parameter in chan_iax2 defaults to 1000. I changed the sample file to match this default.
Comments:	By: Mark Spencer (markster) 2005-05-18 20:33:39 Added to CVS By: Digium Subversion (svnbot) 2008-01-15 15:35:21.000-0600 Repository: asterisk Revision: 5719 U   trunk/channels/chan_iax2.c U   trunk/configs/iax.conf.sample U   trunk/jitterbuf.c U   trunk/jitterbuf.h ------------------------------------------------------------------------ r5719 | markster | 2008-01-15 15:35:21 -0600 (Tue, 15 Jan 2008) | 2 lines More jitter buffer fixes for large resync (bug ASTERISK-4209) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5719