[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:                russell
====================================================================== 
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:              02-19-2008 00:49 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-19-08 00:49  
---------------------------------------------------------------------- 
Guys, could you please test v1-11911.patch .
It requires "svn revert main/channel.c" first unless you have other
changes applied.

The patch just makes handling of NULL frames much like handling of VOICE
ones (which is known to work). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-19-08 00:49  dimas          Note Added: 0082545                          
======================================================================