[asterisk-bugs] [Asterisk 0017235]: [patch] asterisk dsp always reports detected DTMF length to be 0ms

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17235 
====================================================================== 
Reported By:                frawd
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17235
Category:                   Core/General
Reproducibility:            always
Severity:                   trivial
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           1.6.2.7-rc2 
JIRA:                       SWP-1337 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-04-23 10:21 CDT
Last Modified:              2010-04-28 05:54 CDT
====================================================================== 
Summary:                    [patch] asterisk dsp always reports detected DTMF
length to be 0ms
Description: 
The attached patch makes the DSP report the correct length for DTMF
detected in the audio.

Tested with DAHDI channels (FXS, FXO, ISDN PRI) and SIP channels
configured as "inband".
====================================================================== 

---------------------------------------------------------------------- 
 (0121061) frawd (reporter) - 2010-04-28 05:54
 https://issues.asterisk.org/view.php?id=17235#c121061 
---------------------------------------------------------------------- 
The initial issue happened when a device sending a series of short (~80ms)
DTMF and hanging up immediately after the last digit. The last 2 or 3
digits were all detected correctly but never forwarded to the other
channel. 

The sequence of digits being detected as 0ms were all emulated, the next
one being queued in ast_read. The hangup apparently forgets that queue with
the last digit in.

I started reducing a bit the AST_MIN_DTMF_DURATION with no success, I also
remove all inline features (xfer, ...) that were making things worse when
setting some strange DEFER_DTMF flag (might also be an issue). While it
made things better, the last DTMF was still stuck in that read queue on
hangup and never forwarded.

I figured that the easiest way to prevent this would be if the dsp
reported the digits length, to make ast_read pass it through and avoid
queueing.

I agree it is an incorrect approach to calculate the digit's length, but
the strange thing is that it looks like it works quite well in reporting
the digit's length, probably because frame length is usually quite short
and what you describe might not happen that often (not sure). But it
actually resolves my issue (the last digit is now forwarded).

I will look into maybe counting the "hits" which apparently have a fixed
size of 102 samples (DTMF_GSIZE). Would this be a correct approach or am I
loosing my time?

Thanks again for your time and interest in that issue, sorry if I might
have tried to push it too much. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-28 05:54 frawd          Note Added: 0121061                          
======================================================================