[asterisk-dev] [Code Review]: A Jitter Buffer for out of order RFC2833 DTMF handling
Matt Jordan
reviewboard at asterisk.org
Sat Jul 7 17:15:43 CDT 2012
> 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?
>
> Matt Jordan wrote:
> 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.
So. About that.
After I wrote this I went back to work on finishing up my functional tests. Unfortunately, one of the functional tests I wrote pretty much shot my theory full of holes.
For certain sequences of DTMF digits, you *have* to ensure that all of the END frames have a timestamp that is greater then the BEGIN frames. END and BEGIN frames can collide with frames of the same type - but if an END frame and a BEGIN frame collides, you will end up with duplicated digits if you have the following sequence:
BEGIN
END
BEGIN
END
END
This is because as it turns out, for a given DTMF digit, all BEGIN/END packets tend to have the same timestamp. When they're put into a jitter buffer, depending on the type, the jitter buffer either "drops" the frame since its a collision, or appends the frame to the last received frame. Either way, it creates a confusing situation and does not properly re-order the frames. Since we need - at a minimum - for all of the BEGINs to have the same timestamp; the ENDs to have the same timestamp; and all END frames to have a timestamp greater then the BEGINs, there's three candidate fields that could be used to nudge the END frame's timestamps:
* sequence number - not a good candidate, however, since its a monotonically increasing number and doesn't convey time information.
* Raw DTMF duration - not a good candidate either - for the reason I outlined in my original comment. It almost guarantees that subsequent DTMF digits will overlap in time, leading to all sorts of confusion. Emulating the actual duration is better handled by the Asterisk core.
* Length of frame in ms - about the best candidate we have. Its highly unlikely that another DTMF frame would ever overlap, as the values are typically around 90ms.
So, this has now been modified to add the f->len value to f->ts, if the frame type is END. The tests that exposed this will be posted shortly.
- 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/518474c9/attachment.htm>
More information about the asterisk-dev
mailing list