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

Matt Jordan reviewboard at asterisk.org
Fri Jul 6 19:48:31 CDT 2012 


> On July 6, 2012, 1:32 p.m., Mark Michelson wrote:
> > /trunk/funcs/func_jitterbuffer.c, lines 67-68
> > <https://reviewboard.asterisk.org/r/2010/diff/1/?file=29618#file29618line67>
> >
> >     This says that default is audio, but then gives valid values as "voice" and "dtmf". Change the wording so that the default is "voice"

Changed


> On July 6, 2012, 1:32 p.m., Mark Michelson wrote:
> > /trunk/funcs/func_jitterbuffer.c, line 561
> > <https://reviewboard.asterisk.org/r/2010/diff/1/?file=29618#file29618line561>
> >
> >     Minor, but why are you duplicating the string? You don't make any changes to it.

Its not; fixed


> On July 6, 2012, 1:32 p.m., Mark Michelson wrote:
> > /trunk/res/res_rtp_asterisk.c, line 2286
> > <https://reviewboard.asterisk.org/r/2010/diff/1/?file=29629#file29629line2286>
> >
> >     Does this comment indicate there's more to be done here?

Nope, that leaked through from testing.  Adding timestamps to the DTMF frames is new with this patch, and - initially - it seemed like it would be worth trying to add the specified DTMF duration to the timestamp on each frame.

As it turns out, this is a bad idea.  When I treated the specified duration of a DTMF digit as an actual time delta between BEGIN and END frames, multiple DTMF digits would inevitably overlap - UAs tend to send the packets specifying the DTMF much faster then what the durations imply.  This meant the jitter buffer - which was trusting the timestamps it was given - would end up passing out multiple BEGIN frames for different digits before properly ENDing the digits.  Hilarity ensued in the bridging layer.

So... yeah.  Removed.


> On July 6, 2012, 1:32 p.m., Mark Michelson wrote:
> > /trunk/funcs/func_jitterbuffer.c, lines 624-633
> > <https://reviewboard.asterisk.org/r/2010/diff/1/?file=29618#file29618line624>
> >
> >     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.

Ooo... that is wrong.  Fixed.


- Matt


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


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/20120707/2536f590/attachment-0001.htm>

More information about the asterisk-dev mailing list