[asterisk-dev] [Code Review] Fixes for processing RFC 2833 DTMF

Tue Mar 16 16:17:12 CDT 2010

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


/trunk/res/res_rtp_asterisk.c
<https://reviewboard.asterisk.org/r/558/#comment3766>

    May be send_dtmf is just not the best name from what this function does. I know it is not you who named it but the fact is that it is a bit misleading - this is how I overlooked that this force-end case is noop. From the "send" part of "send_dtmf" it looked like I really end digit here :)
    
    Maybe make_dtmf or something like that can be a better name?...


- dimas


On 2010-03-16 15:47:25, Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/558/
> -----------------------------------------------------------
> 
> (Updated 2010-03-16 15:47:25)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This change to res_rtp_asterisk fixes several problems regarding DTMF detection, mostly dealing with corner cases we may hit.
> 
> Fix 1. The first change in place is to fix Mantis issue 15811, which deals with a situation where Asterisk will incorrectly interpret out of order RFC2833 frames as duplicate DTMF digits. For instance, we would receive a sequence like:
> 
> seqno 1: DTMF 1
> seqno 2: DTMF 1
> seqno 3: DTMF 1
> seqno 4: DTMF 1
> seqno 6: DTMF 1 (end)
> seqno 5: DTMF 1
> seqno 7: DTMF 1 (end)
> seqno 8: DTMF 1 (end)
> 
> Prior to this patch when we received the frame with seqno 5, we would interpret this as a new DTMF 1. With this patch, we will check the seqno of the incoming digit and not process the frame if the seqno is lower than the last recorded seqno. Note that we do not record the seqno of the dropped DTMF frame for future processing. While the above situation is what was designed to be fixed, the patch is written in such a way that the following would also be fixed too:
> 
> seqno  9: DTMF 1
> seqno 10: DTMF 1 (end)
> seqno 11: DTMF 1 (end)
> seqno 13: DTMF 2
> seqno 12: DTMF 1 (end)
> seqno 14: DTMF 2
> seqno 15: DTMF 2 (end)
> seqno 16: DTMF 2 (end)
> seqno 17: DTMF 2 (end)
> 
> In this second situation, the beginning of the DTMF 2 arrives before the final end frame of the DTMF 1. With the patch, seqno 12 is no processed and thus we properly interpret the DTMF.
> 
> Fix 2. The second change in place is to fix an issue like the following:
> 
> seqno 1: DTMF 1
> seqno 2: DTMF 1
> seqno 3: DTMF 1 (end) *packet lost*
> seqno 4: DTMF 1 (end) *packet lost*
> seqno 5: DTMF 1 (end) *packet lost*
> seqno 6: DTMF 2
> 
> When we receive seqno 6, we had code in place that was supposed to properly end the previously unended DTMF 1. The problem was that the code was essentially a no-op. The code would set up an end frame for the DTMF 1 but would immediately overwrite the frame with the begin for DTMF 2. I changed process_dtmf_rfc2833() so that instead of returning a single frame, it is given as an output parameter a list of frames. Each frame that needs to be returned is appended to this list.
> 
> Fix 3. The final change is a minor one where an AST_CONTROL_SRCCHANGE frame could get lost. If we process a cisco DTMF or an RFC 3389 frame and no frame was returned, then we would return &ast_null_frame. The problem is that earlier in the function, we may have generated an AST_CONTROL_SRCCHANGE frame and put it in the list of frames we wish to return. This frame would be lost in such a case. The patch fixes this problem.
> 
> 
> Note that this patch is against trunk as that is what the external test I've written runs against. However, the same fixes apply to all branches of Asterisk.
> 
> 
> This addresses bug 15811.
>     https://issues.asterisk.org/view.php?id=15811
> 
> 
> Diffs
> -----
> 
>   /trunk/res/res_rtp_asterisk.c 252530 
> 
> Diff: https://reviewboard.asterisk.org/r/558/diff
> 
> 
> Testing
> -------
> 
> I have written sipp tests to deal with Fixes 1 and 2. They will be posted on reviewboard in the near future. Right now, though, the post-review script is not working properly when I try to post my test.
> 
> 
> Thanks,
> 
> Mark
> 
>