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

[noreply at bugs.digium.com]

The following issue has been set as RELATED TO issue 0012658. 
====================================================================== 
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:                     closed
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:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             02-02-2008 19:26 CST
Last Modified:              03-04-2008 12:51 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. 

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0012658 [patch] DTMF issues on Zap
====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-21-08 09:50  murf           Relationship added       related to 0012658  
======================================================================