[asterisk-bugs] [JIRA] Issue Comment Edited: (ASTERISK-19610) dsp.c can no longer detect a quick DTMF sequence

[Alec Davis (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-19610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=196019#comment-196019 ] 

Alec Davis edited comment on ASTERISK-19610 at 8/26/12 3:37 AM:
----------------------------------------------------------------

Richard:
  My assumption that each DTMF goertzel period was 10ms, if I'm not mistaken it's 12.75ms,
arrived at '#define DTMF_GSIZE 102', with 102 being the number of sample periods at sample rate of 8000Hz.
Which at dtmf_hits_to_begin @ 4 = 51ms, (not including the fact that the DTMF could start anyhwere through a goertzel period).

I believe DTMF_GSIZE should be 80, to reduce each DTMF goertzel sample to 10ms. then 'begin=4' and 'end=3' should work, for 50ms/50ms.

What was confusing is the debug capture, only 20ms between EDGE and BEGIN, which should have been 51ms, DAHDI packetisation?
[2012-08-15 15:29:07.419621] DEBUG[27728] dsp.c: DTMF EDGE
[2012-08-15 15:29:07.439637] DEBUG[27728] dsp.c: DTMF BEGIN

Re: A config option, not yet, until we've exhausted if there's a better way. 

But, I need a reliable DTMF tester to inject 40ms/30ms into a call.

Alec

edit: Workable solution, but unable to test with 50/50ms ON/OFF
 #define DTMF_TO_TOTAL_ENERGY 32.9 /* for DTMF_GSIZE 80, or 10ms sample period*/
 #define DTMF_HITS_TO_BEGIN 4 /* 40 ms on */
 #define DTMF_MISSES_TO_END 3 /* 30 ms off */
 #define DTMF_GSIZE 80


      was (Author: alecdavis):
    Richard:
  My assumption that each DTMF goertzel period was 10ms, if I'm not mistaken it's 12.75ms,
arrived at '#define DTMF_GSIZE 102', with 102 being the number of sample periods at sample rate of 8000Hz.
Which at dtmf_hits_to_begin @ 4 = 51ms, (not including the fact that the DTMF could start anyhwere through a goertzel period).

I believe DTMF_GSIZE should be 80, to reduce each DTMF goertzel sample to 10ms. then 'begin=4' and 'end=3' should work, for 50ms/50ms.

What was confusing is the debug capture, only 20ms between EDGE and BEGIN, which should have been 51ms, DAHDI packetisation?
[2012-08-15 15:29:07.419621] DEBUG[27728] dsp.c: DTMF EDGE
[2012-08-15 15:29:07.439637] DEBUG[27728] dsp.c: DTMF BEGIN

Re: A config option, not yet, until we've exhausted if there's a better way. 

But, I need a reliable DTMF tester to inject 40ms/30ms into a call.


Alec
  
> dsp.c can no longer detect a quick DTMF sequence
> ------------------------------------------------
>
>                 Key: ASTERISK-19610
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19610
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Channels
>    Affects Versions: 1.8.10.1, 1.8.11.0, 10.2.1, 10.3.0
>            Reporter: Jean-Philippe Lord
>              Labels: Regression
>         Attachments: 1332984810-SIP-2299-00000018-in.wav, ast-19610.diff2.txt, ast-19610.diff.txt, dsp_fastdtmf.patch
>
>
> dsp.c stopped being able to decode a quick DTMF sequence starting in 1.8.10rc1. 50ms tone, 50ms silence does not work anymore. This isssue is major since asterisk used to be extremely good at detecting fast DTMF and it no longer is. I have removed the below change and issue got resolved. 
> From the ChangeLog:
> 2012-01-05 21:46 +0000 [r349672-349728]  Jonathan Rose <jrose at digium.com>
>         * main/dsp.c: Fix an issue where dsp.c would interpret multiple
>           dtmf events from a single key press. When receiving calls from a
>           mobile phone into a DISA system on a connection with significant
>           interference, the reporter's Asterisk system would interpret DTMF
>           incorrectly and replicate digits received. This patch resolves
>           that by increasing the number of frames a mismatch has to be
>           detected before assuming the DTMF is over by 1 frame and adjusts
>           dtmf_detect function to reset hits and misses only when an edge
>           is detected. (closes issue ASTERISK-17493) Reported by: Alec
>           Davis Patches: bug18904-refactor.diff.txt uploaded by Alec Davis
>           (license 5546) Review: https://reviewboard.asterisk.org/r/1130/

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira