[asterisk-bugs] [Asterisk 0011911]: [patch] DTMF digits duplicated

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11911 
====================================================================== 
Reported By:                edgreenberg
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11911
Category:                   Core/Channels
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 101373 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             02-02-2008 19:26 CST
Last Modified:              02-04-2008 09:08 CST
====================================================================== 
Summary:                    [patch] DTMF digits duplicated
Description: 
In a seemingly random fashion, DTMF digits, received in RFC2833, are
doubled.  This takes place in channel.c. All the action is in __ast_read().
When digits are too short, they are emulated to a suitable length. When
sufficient time elapses, they are removed from emulation and passed to
__ast_read()'s caller.

There are three places where digits can be "de-emulated." Once, early in
the function (about 40 lines in). Secondly, in the large switch statement,
under AST_FRAME_NULL. Finally, in the switch statement under
AST_FRAME_VOICE. 

I determined that if the order of packets ending the DTMF is
"end-voice-end-end", the problem occurs. On the other hand, if the order is
"end-end-voice-end", or "end-end-end", the problem does not occur. 

In the first case, end-voice-end-end, the initial end packet is processed,
and __ast_read() enqueues the digit so it can get to be long enough (80
ms). Then a voice frame arrives, and the packet is long enough. The code
under case AST_FRAME_VOICE is executed which removes the digit from the
queue and sends it up to the caller, but does not turn off the
AST_FRAME_EMULATE_DTMF flag. On the next pass, in case AST_FRAME_NULL, the
digit is dequeued again, doubling it. 

Note that at the very top of case AST_FRAME_VOICE, there is code to clear
the flag, but this code is not executed under the conditions that I was
experiencing.

This exists in the 1.4 branch as well as in trunk and applying the fix
resolved it there as well.

Attached is a patch to resolve this. 

====================================================================== 

---------------------------------------------------------------------- 
 dimas - 02-04-08 09:08  
---------------------------------------------------------------------- 
Well, according to comments, the AST_FLAG_EMULATE_DTMF flag is not reset
intentionally when processing FRAME_VOICE. The emulate_dtmf_duration is set
to zero instead and on the next voice frame the following code is
executed:
                case AST_FRAME_VOICE:
                        /* The EMULATE_DTMF flag must be cleared here as
opposed to when the duration
                         * is reached , because we want to make sure we
pass at least one
                         * voice frame through before starting the next
digit, to ensure a gap
                         * between DTMF digits. */
                        if (ast_test_flag(chan, AST_FLAG_EMULATE_DTMF) &&
!chan->emulate_dtmf_duration) {
                                ast_clear_flag(chan,
AST_FLAG_EMULATE_DTMF);
                                chan->emulate_dtmf_digit = 0;
                        }

So the question is: isn't it a more proper approach to copy the same code
at the beginning of case AST_FRAME_NULL ? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-04-08 09:08  dimas          Note Added: 0081656                          
======================================================================