[asterisk-dev] [Code Review]: Fix incorrect jitterbuffer overflow when timing source changes are indicated by control frames

[Mark Michelson]

> On March 13, 2012, 5:03 p.m., Mark Michelson wrote:
> > The problem I have with this change is that it is only useful for chan_iax2. Other channel types using a jitterbuffer will not get the benefit since they do not call the functions in include/jitterbuf.c directly. Most typical jitterbuffer usage goes through the interface in include/asterisk/abstract_jb.h. In main/abstract_jb.c, you can see that ast_jb_put() specifically filters out anything that is not a voice or DTMF frame. Once you change that, your changes to main/jitterbuf.c will be useful to all channel types. You'll also need to alter fixed_jb_put() in main/fixedjitterbuf.c so that it understands that it may receive frame types other than voice.
> > 
> > In Asterisk 10, you'll also find that you'll need to update func_jitterbuffer.c so that it will attempt to place non-voice frames into the jitterbuffer.
> 
> Matt Jordan wrote:
>     This change is limited to chan_iax2's usage of the jitter buffer, as only chan_iax2 uses the JB_TYPE_CONTROL frames.  If you look at the implementations of jb_put_adaptive, it makes the assumption that all data being put into the jitter buffer is of type JB_TYPE_VOICE - so other channel drivers would never run into this problem in the first place.  With respect to fixedjitterbuf... it is its own thing, so none of this applies.
>     
>     That aside, would other channel drivers ever need to pass data other then "voice" (let's call it "media") to a jitter buffer?  I don't know for sure, but I suspect not.  For example, why would SIP ever need to interleave some piece of signalling data with an associated RTP stream?  The only thing I could think of was DTMF over SIP INFO, but DTMF - over SIP INFO or embedded in the RTP stream - is already handled when the Asterisk frames are created and passed into the native bridge.
>     
>     In general, I think abstracting away the Jitter Buffer frame types from the things that use the Jitter Buffer was the correct decision.  If the abstract Jitter Buffer API ever has to be smart enough to make decisions on a wide variety of frame types, I would expect that to be a new feature and outside the scope of something that should go into 1.8.
>

Okay, this explanation satisfies me.


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1814/#review5802
-----------------------------------------------------------


On March 13, 2012, 5:45 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1814/
> -----------------------------------------------------------
> 
> (Updated March 13, 2012, 5:45 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> When a change in time occurs, such that the timestamps associated with frames being placed into an adaptive Jitter Buffer are significantly different then the previously inserted frames, the adaptive Jitter Buffer checks to see if it needs to be resynched to the new time frame (based on an initially configurable re-synchronization threshold).  If three consecutive packets break the threshold, the jitter buffer re-synchs itself to the new timestamps.  This currently only occurs when the history is calculated, and hence only on VOICE frames.
> 
> CONTROL frames, on the other hand, are never passed to the history calculations.  Because of this, if the jump in time is greater then the maximum allowed length of the Jitter Buffer, the CONTROL frames are dropped and no re-synchronization occurs.  Because the re-synch does not happen, subsequent VOICE frames are counted as overflow of the Jitter Buffer, and are also dropped.  In some scenarios, this can lead to 'stuttery' audio as some number of VOICE frames are dropped.
> 
> This patch allows CONTROL frames to re-synch the Jitter Buffer.  As CONTROL frames are very unlikely to occur in multiples, it performs the resynchornization on any CONTROL frame that breaks the re-synch threshold.
> 
> 
> This addresses bug ASTERISK-18964.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18964
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/main/jitterbuf.c 358724 
> 
> Diff: https://reviewboard.asterisk.org/r/1814/diff
> 
> 
> Testing
> -------
> 
> Testing was done by the initial issue reporter.  I've also verified that the patch does not adversely effect nominal operation of IAX2 channels with a forced jitter buffer.
> 
> Unit tests were written to cover this functionality and to verify that other behavior did not change with this patch (see review https://reviewboard.asterisk.org/r/1815/).  Since the unit tests are a new module, I put them under their own review against trunk.  Without this patch, the unit test jitterbuffer_resynch_control will fail, as the jitter buffer will not be resynced and will instead overflow.  The rest of the unit tests have the same result with and without this patch.
> 
> 
> Thanks,
> 
> Matt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120314/1ba1d80f/attachment.htm>