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

[noreply at bugs.digium.com]

The following issue has been ASSIGNED. 
====================================================================== 
http://bugs.digium.com/view.php?id=11911 
====================================================================== 
Reported By:                edgreenberg
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   11911
Category:                   Core/Channels
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
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:              03-03-2008 09:25 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. 

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

---------------------------------------------------------------------- 
 svnbot - 03-03-08 09:25  
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 105560

U   branches/1.4/main/channel.c

------------------------------------------------------------------------
r105560 | file | 2008-03-03 09:25:09 -0600 (Mon, 03 Mar 2008) | 7 lines

It is possible for no audio to pass between the current digit and next
digit so expand logic that clears emulation to AST_FRAME_NULL.
(closes issue http://bugs.digium.com/view.php?id=11911)
Reported by: edgreenberg
Patches:
      v1-11911.patch uploaded by dimas (license 88)
Tested by: tbsky

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=105560 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-03-08 09:25  svnbot         Note Added: 0083261                          
03-03-08 09:25  svnbot         Status                   feedback => assigned
03-03-08 09:25  svnbot         Assigned To               => file            
======================================================================