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

Alec Davis (JIRA) noreply at issues.asterisk.org
Tue Aug 14 22:43:07 CDT 2012


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

Alec Davis edited comment on ASTERISK-19610 at 8/14/12 10:41 PM:
-----------------------------------------------------------------

referring to http://www.itu.int/rec/T-REC-Q.24-198811-I/en

'On duration' should be 30ms or 40ms, interdigit pause 30ms.

Without removing the refactoring that was done, the easiest fix may just be to change number of HITS and MISSES to 3.
Specifically MISSES_TO_END being 40ms may be 1 too high.

 /* How many successive hits needed to consider begin of a digit */
-#define DTMF_HITS_TO_BEGIN     4
+#define DTMF_HITS_TO_BEGIN     3
 /* How many successive misses needed to consider end of a digit */
-#define DTMF_MISSES_TO_END     4
+#define DTMF_MISSES_TO_END     3

Changing logger.conf time format to, we get uSecond resolution
[general]
dateformat=%F %T.%6q

and with 3 extra debug prints.

However with HITS=4 and MISSES=3:
</code>
[2012-08-15 15:29:06.679634] DEBUG[27728] dsp.c: DTMF EDGE
[2012-08-15 15:29:06.719632] DEBUG[27728] dsp.c: DTMF BEGIN
[2012-08-15 15:29:06.719670] DEBUG[27728] chan_dahdi.c: Begin DTMF digit: 0x31 '1' on DAHDI/i1/21XXXXXXX-4
[2012-08-15 15:29:07.039630] DEBUG[27728] dsp.c: DTMF EDGE
[2012-08-15 15:29:07.059635] DEBUG[27728] dsp.c: DTMF END
[2012-08-15 15:29:07.059693] DEBUG[27728] chan_dahdi.c: End DTMF digit: 0x31 '1' on DAHDI/i1/21XXXXXXX-4

[2012-08-15 15:29:07.259627] DEBUG[27728] dsp.c: DTMF EDGE
[2012-08-15 15:29:07.279621] DEBUG[27728] dsp.c: DTMF EDGE   << this noise didn't get sent up to dahdi (refactoring AST-17493 fixed this )
[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
[2012-08-15 15:29:07.439672] DEBUG[27728] chan_dahdi.c: Begin DTMF digit: 0x32 '2' on DAHDI/i1/21XXXXXXX-4
[2012-08-15 15:29:07.739624] DEBUG[27728] dsp.c: DTMF EDGE
[2012-08-15 15:29:07.759636] DEBUG[27728] dsp.c: DTMF END
[2012-08-15 15:29:07.759674] DEBUG[27728] chan_dahdi.c: End DTMF digit: 0x32 '2' on DAHDI/i1/21XXXXXXX-4

</code>


      was (Author: alecdavis):
    referring to http://www.itu.int/rec/T-REC-Q.24-198811-I/en

'On duration' should be 30ms or 40ms, interdigit pause 30ms.

Without removing the refactoring that was done, the easiest fix may just be to change number of HITS and MISSES to 3.
Specifically MISSES_TO_END being 40ms may be 1 too high.

 /* How many successive hits needed to consider begin of a digit */
-#define DTMF_HITS_TO_BEGIN     4
+#define DTMF_HITS_TO_BEGIN     3
 /* How many successive misses needed to consider end of a digit */
-#define DTMF_MISSES_TO_END     4
+#define DTMF_MISSES_TO_END     3

Changing logger.conf time format to, we get uSecond resolution
[general]
dateformat=%F %T.%6q

and with 3 extra debug prints.

However with HITS=4 and MISSES=3:
<code>
[2012-08-15 15:29:06.679634] DEBUG[27728] dsp.c: DTMF EDGE
[2012-08-15 15:29:06.719632] DEBUG[27728] dsp.c: DTMF BEGIN
[2012-08-15 15:29:06.719670] DEBUG[27728] chan_dahdi.c: Begin DTMF digit: 0x31 '1' on DAHDI/i1/21XXXXXXX-4
[2012-08-15 15:29:07.039630] DEBUG[27728] dsp.c: DTMF EDGE
[2012-08-15 15:29:07.059635] DEBUG[27728] dsp.c: DTMF END
[2012-08-15 15:29:07.059693] DEBUG[27728] chan_dahdi.c: End DTMF digit: 0x31 '1' on DAHDI/i1/21XXXXXXX-4

[2012-08-15 15:29:07.259627] DEBUG[27728] dsp.c: DTMF EDGE
[2012-08-15 15:29:07.279621] DEBUG[27728] dsp.c: DTMF EDGE   << this noise didn't get sent up to dahdi (refactoring AST-17493 fixed this )
[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
[2012-08-15 15:29:07.439672] DEBUG[27728] chan_dahdi.c: Begin DTMF digit: 0x32 '2' on DAHDI/i1/21XXXXXXX-4
[2012-08-15 15:29:07.739624] DEBUG[27728] dsp.c: DTMF EDGE
[2012-08-15 15:29:07.759636] DEBUG[27728] dsp.c: DTMF END
[2012-08-15 15:29:07.759674] DEBUG[27728] chan_dahdi.c: End DTMF digit: 0x32 '2' on DAHDI/i1/21XXXXXXX-4

<code>

  
> 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, 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



More information about the asterisk-bugs mailing list