Summary:	ASTERISK-09350: improve jitterbuffer (jbtargetextra/minjitterbuffer)
Reporter:	pj (pj)	Labels:
Date Opened:	2007-04-29 06:32:14	Date Closed:	2011-06-07 14:07:49
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_iax2
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I discovered, that jittertargetextra option works maybe not good as it can, eg. if I have jitter spike (rtt 5ms to 100ms) and jittertargetextra set to 150ms, so that total jb size (155ms) can compensate this (95ms) jitter change, but nagative aspect of how jittertargetextra is now implemented is, that it _immediatelly_ extend jitterbuffer from 155ms to 250ms! so it have all negative consequenses to voice quality as "primary" jitter spike. this can be improved by growing jitterbuffer size _gently_ and not make jb size jumps. I think also, that it will be really usefull to add similar concept like maxjitterbuffer, to be able to specify also _minimum_ jb size, that jb size shouldn't never drop below lower limit, regardless of actual measured jitter.
Comments:	By: Joshua C. Colp (jcolp) 2007-05-14 14:07:11 Do you have a patch to go with this? Traditionally for feature requests like this we like to see them. By: pj (pj) 2007-05-14 15:52:12 it's related to 0007978: introduce jittertargetextra option to jitter buffer via iax.conf I think that improving behaviour of jbextra (or even add jbmin option) should be relatively easy for original author of this patch. I haven't knowledge of asterisk internals, I can't supply patch alone, but can help with testing or discuss some ideas to improve asterisk:) By: pj (pj) 2007-05-28 11:57:57 is possible to reopen bugreport http://bugs.digium.com/view.php?id=7978 that introduces jittertargetextra option, so I can consult/ask to original contributor if he can to do some improvements in his work or contribute patch for minjitterbuffer? By: Steve Davies . (stevedavies) 2007-07-19 11:15:14 Please don't apply this one without discussing with Steve Kann and me. A jitter spike *should* result in audio being lost.  That's presuming its really a spike.  If we confuse ourselves into thinking that the jitter buffer is there to prevent all audio disruption, we'll end up with huge jitter buffers and associated long delay.  dejittering is a balancing act - if jitter on a call is usually say 20msec and we have say 1 1-second dropout per minute then the jitter buffer should be set to handle the 20msec jitter and the 1 second dropouts should result in audio dropouts.  Otherwise we have to run a 1000msec jitter buffer all the time which will be much much worse than the single dropout. Steve By: pj (pj) 2007-07-19 12:19:35 I agree, that consequence of jitter spike is legitimate audio dropout, but my suggestion is to eliminate fast jitterbuffer groving (not to eliminate dropouts at any time), that you alone said, is negative. Imagine current situation with jbtargetextra, if it doesn't have some sliding mechanizm, jitterbuffer is groving immediatelly and that spike is propagated to end device, that react also with groving own's internal jitterbuffer, so we even evoke two groving jitterbuffers in sequence - in asterisk and in end device. I also think, that _configurable_ minimum jitterbuffer threshhold should help in some situations to eliminate negative consequences of frequent jitterbuffer changes, that happened in some situations. By: Joshua C. Colp (jcolp) 2007-12-17 11:50:09.000-0600 It's been quite some time since any further discussion has happened on this and no patch has been supplied. I would suggest bringing it up on the -dev list so both Steves can discuss.