[asterisk-dev] [Code Review] A Jitter Buffer for out of order RFC2833 DTMF handling

[Mark Michelson]

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



/trunk/funcs/func_jitterbuffer.c
<https://reviewboard.asterisk.org/r/2010/#comment12586>

    This says that default is audio, but then gives valid values as "voice" and "dtmf". Change the wording so that the default is "voice"



/trunk/funcs/func_jitterbuffer.c
<https://reviewboard.asterisk.org/r/2010/#comment12588>

    Minor, but why are you duplicating the string? You don't make any changes to it.



/trunk/funcs/func_jitterbuffer.c
<https://reviewboard.asterisk.org/r/2010/#comment12584>

    Your change to make the framehook interface file-scoped instead of channel-scoped feels wrong. Specifically, this manipulation of interface.data is dangerous. If multiple channels are using func_jitterbuffer, then the wrong data could end up being manipulated. Plus, it's easy to leak memory or end up double-freeing memory in the case that multiple channels are using func_jitterbuffer.



/trunk/res/res_rtp_asterisk.c
<https://reviewboard.asterisk.org/r/2010/#comment12583>

    Does this comment indicate there's more to be done here?


- Mark


On July 5, 2012, 11:43 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2010/
> -----------------------------------------------------------
> 
> (Updated July 5, 2012, 11:43 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> The current RTP stack in Asterisk does not have any inbound buffering capabilities.  For RFC 2833 DTMF packets that arrive out of order, the RTP layer does the best it can, and - if it detects packets that have arrived out of order, or, in general, don't make "sense" (packets marked as an 'end' when no 'begin' occurred, etc.) - it attempts to prevent duplicate DTMF or other weird scenarios.  This may include dropping the packets.  Unfortunately, this means that - in some situations - some DTMF digits may have very odd durations or may not occur at all, if a sufficient number of packets arrive out of order.
> 
> Providing buffering in the RTP layer isn't really the correct answer here - putting a buffer on the receiving side of the RTP stack would have some fairly large ramifications on channel read operations.  Since we already have the capability to put a jitter buffer on the read side of a channel in Asterisk 10/11, this patch expands the capabilities of these jitter buffers to 'understand' DTMF.
> 
> This works in the following way:
> 1. If no Jitter Buffer exists on the channel that owns the RTP instance, the behavior of the RTP instance is unchanged (it will drop out of order RFC 2833 DTMF)
> 2. When a Jitter Buffer is placed on a channel using func_jitterbuffer, a new control frame is sent to the channel.  The channel, if it supports RTP, lets its RTP instance know that a jitter buffer it cares about may be in existance.
> 3. The RTP instance queries the frame hooks to see if a jitter buffer capable of handling DTMF exists.  If it does, it sets a flag to allow out of order DTMF packets to flow up into the channel technology (and from there, into the bridging core)
> 4. The abstract jitter buffer code now handles the DTMF that flows in and out of it.  This includes handling multiple END frames, handling BEGIN frames without END frames - the usual stuff that the RTP layer would have taken care of for us.
> 
> 
> This addresses bug ASTERISK-18404.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18404
> 
> 
> Diffs
> -----
> 
>   /trunk/addons/chan_ooh323.c 369624 
>   /trunk/channels/chan_alsa.c 369624 
>   /trunk/channels/chan_console.c 369624 
>   /trunk/channels/chan_dahdi.c 369624 
>   /trunk/channels/chan_gtalk.c 369624 
>   /trunk/channels/chan_h323.c 369624 
>   /trunk/channels/chan_jingle.c 369624 
>   /trunk/channels/chan_local.c 369624 
>   /trunk/channels/chan_mgcp.c 369624 
>   /trunk/channels/chan_oss.c 369624 
>   /trunk/channels/chan_sip.c 369624 
>   /trunk/channels/chan_skinny.c 369624 
>   /trunk/channels/chan_unistim.c 369624 
>   /trunk/channels/misdn_config.c 369624 
>   /trunk/funcs/func_frame_trace.c 369624 
>   /trunk/funcs/func_jitterbuffer.c 369624 
>   /trunk/include/asterisk/abstract_jb.h 369624 
>   /trunk/include/asterisk/frame.h 369624 
>   /trunk/include/asterisk/framehook.h 369624 
>   /trunk/include/asterisk/rtp_engine.h 369624 
>   /trunk/tests/test_abstract_jb.c PRE-CREATION 
>   /trunk/res/res_rtp_asterisk.c 369624 
>   /trunk/main/rtp_engine.c 369624 
>   /trunk/main/jitterbuf.c 369624 
>   /trunk/main/framehook.c 369624 
>   /trunk/main/abstract_jb.c 369624 
>   /trunk/main/channel.c 369624 
>   /trunk/main/file.c 369624 
> 
> Diff: https://reviewboard.asterisk.org/r/2010/diff
> 
> 
> Testing
> -------
> 
> Unit testing: This patch includes a new abstract_jb test.  This checks the following:
>  1. Nominal creation of fixed/adaptive voice/dtmf jitter buffers
>  2. Nominal putting/retrieval of frames from fixed/adaptive voice/dtmf jitter buffers
>  3. Overflow in said jitter buffers
>  4. Out of order handling in said jitter buffers
>  5. Multiple DTMF END packets in DTMF jitter buffers
> 
> Functional testing in the Asterisk Test Suite: A new func_jitterbuffer test was written.  RFC2833_dtmf_detect passed with no modifications, showing that the RTP layer - without a DTMF jitter buffer - worked the same.  A new test, RFC2833_dtmf_jitterbuffer, was written that also successfully re-ordered the out of order DTMF.  These tests will be put up on a separate review. 
> 
> System testing: lots of smashing on IVRs with a DTMF jitter buffer.  Successfully handled lots of short DTMF durations, long DTMF durations, etc.
> 
> 
> Thanks,
> 
> Matt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120706/8f5bcb74/attachment-0001.htm>