[asterisk-bugs] [Asterisk 0010535]: [patch] DTMF detect debouncing logic can miss whole digits (dsp.c)

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10535 
====================================================================== 
Reported By:                softins
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10535
Category:                   Core-General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.2  
SVN Revision (number only!): 80452 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-23-2007 08:51 CDT
Last Modified:              08-24-2007 11:20 CDT
====================================================================== 
Summary:                    [patch] DTMF detect debouncing logic can miss whole
digits (dsp.c)
Description: 
As reported on asterisk-dev at
http://lists.digium.com/pipermail/asterisk-dev/2007-August/029149.html,
inband DTMF detection is unreliable when the tones are not perfect.

Having investigated the issue using a test harness around dsp.c, using
audio files of varying quality captured directly from the Zaptel data
before the dsp processing, I believe I have found the issue.

It turns out that the problem with missing digits is in the debouncing,
for which I think the logic is wrong.

The debouncing of hits within dtmf_detect() is currently as follows:

if (hit) {
        if (hit == s->hits[2]  &&  hit != s->hits[1]  &&  hit !=
s->hits[0]) {
                // we register that we really have a digit
        }
}
s->hits[0] = s->hits[1];
s->hits[1] = s->hits[2];
s->hits[2] = hit;

So hits[] is a shift register of old hits/non-hits.

If we get a clean start of digit (say, 0), the sequence is as follows:

(- - -) 0
(- - 0) 0 : register that we have a digit (leading edge)
(- 0 0) 0
(0 0 0) 0

However, if we get a bounce at the start, the whole digit can get missed:

(- - -) 0
(- - 0) -
(- 0 -) 0
(0 - 0) 0
(- 0 0) 0
(0 0 0) 0

None of the above sequences triggers the leading-edge detector, which is
looking for a match in the previous hit, preceded by two non-matches.
Consequently the whole digit is missed.

What should really happen is that the previous hit should match the
current hit, and they should be different from the PREVIOUS DEBOUNCED HIT.
It also appears that there is currently no debouncing of the trailing edge;
the first non-hit terminates the digit.

I have reworked the debouncing logic as follows:

a) Debouncing is now done on both leading and trailing edges.

b) The dtmf_detect() function now returns the debounced value (mhit).

c) The behaviour if OLD_DSP_ROUTINES is defined has been left unchanged.

With the change, all my test files had their DTMF detected reliably, where
some of them previously had several digits missed. I will shortly be
applying it to a live 1.2 system that has been having chronic DTMF issues
in some calls. I will post the results here.

The same technique should probably be applied to MF detection too, but I
have not done so.

I have attached patches for 1.2, 1.4 and trunk. This really ought to be
fixed in 1.2, but if policy dictates otherwise, then at least the patch
here can be fetched and applied by people who need it.
====================================================================== 

---------------------------------------------------------------------- 
 softins - 08-24-07 11:20  
---------------------------------------------------------------------- 
I can confirm that after a day or two operation with the new code, the live
system has been working fine, and does not appear to randomly drop incoming
digits any more. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-24-07 11:20  softins        Note Added: 0069372                          
======================================================================