| Summary: | ASTERISK-20442: dtmf callerid regression | ||||||
| Reporter: | tbsky (tbsky) | Labels: | |||||
| Date Opened: | 2012-09-19 07:17:33 | Date Closed: | 2012-10-03 23:46:27 | ||||
| Priority: | Minor | Regression? | Yes | ||||
| Status: | Closed/Complete | Components: | Channels/chan_dahdi | ||||
| Versions: | 1.8.16.0 | Frequency of Occurrence | Constant | ||||
| Related Issues: |
| ||||||
| Environment: | with TDM400P FXO card | Attachments: | ( 0) dtmf-configure-1.8.diff.txt | ||||
| Description: | hi: when I use asterisk 1.8.9. the DTMF CallerID works 90% correct. (sometime it will drop 1 or 2 digits). but when I upgrade to 1.8.10 or 1.8.16, it can only detect 1 or 2 digits for every call (so drop 7 or 8 digits for every call). I think there are something change between 1.8.9 and 1.8.10 but I don't know what. can you tell me what to test or provide what information to fix the bug? | ||||||
| Comments: | By: Matt Jordan (mjordan) 2012-09-19 08:10:09.320-0500 This was most likely caused by ASTERISK-17493, and fixed in ASTERISK-19610. You can try the patch 'review2085.diff3.txt' on that issue - the fix should be available in 1.8.17.0. By: tbsky (tbsky) 2012-09-19 22:05:05.100-0500 hi: thanks a lot for your information.I found that patch already include in 1.8.17-rc1, so I tried that and the situation now is like 1.8.9. I got 90% success of callerid. I also found interesting comments about the patch so I goto edit dsp.c, try to change "DTMF_HITS_TO_BEGIN" and "DTMF_MISSES_TO_END" and see the result. but the success rate still about 90%. it will drop 1 digit every two or three calls. are there possibilities to increase the success rate? with hardware phone attached to the line I can get 100% correct callerid, but I can never tweak asterisk to get the same result. By: Alec Davis (alecdavis) 2012-09-20 03:00:15.967-0500 The patch committed to 1.8 and upwards, uploaded to ASTERISK-19610 uploaded as 'review2085.diff3.txt' . By: Alec Davis (alecdavis) 2012-09-20 03:27:11.810-0500 With an FXS not FXO, while testing the dsp changes for ASTERISK-19610, I also had issues with an FXS line detecting digits reliably when dialling out (using a hardphone sitting on PC speaker using a PC based DTMF encoder), but when dialled into voicemail using the same phone on PC speaker, then every digit was recognised, at upto DTMF on/off rate of 40ms/40ms. The above tests with PC DTMF encoder required removing the REVERSE_TWIST and NORMAL_TWIST tests from dtmf_detect() {code} col_energy[best_col] < row_energy[best_row] * DTMF_REVERSE_TWIST && col_energy[best_col] * DTMF_NORMAL_TWIST > row_energy[best_row]) { {code} Removing these may assist with your detection. They check that the power levels between the high side tones and the low side are within tolerance. Interesting though, when dialed out through FXS->FXO to our telco, using the same PC Speaker DTMF encoder every digit was recognised by our telco, without the removal of the TWIST tests. By: tbsky (tbsky) 2012-09-21 08:32:03.453-0500 hi Alec: your information is great! I patch my asterisk with your suggestion and the detect rate seems go up from 90% to 100%. I don't known what "REVERSER_TWIST" or "NORMAL_TWIST" do. what impact will be without these testing? anyway I like the behavior of my asterisk for now :) thanks a lot!! By: Alec Davis (alecdavis) 2012-09-21 14:00:08.625-0500 Twist is caused by a non-uniform power loss across the frequency spectrum. Normal twist is when low frequency power is greater than high frequency. Reverse twist is obviously the reverse condition. The detector must be reject 8db and 4db for normal and reverse twist respectively. Also found this describing a similar issue with REVERSE TWIST. https://issues.asterisk.org/jira/browse/ZAP-181 ZAP-181 Some DTMF tones not detected at blind-transfer prompt dialtone By: Alec Davis (alecdavis) 2012-09-21 14:17:14.826-0500 tbsky: in chan_dahdi.conf the 'relaxdtmf' parameter may have been enough to get better detection. ; If you are having trouble with DTMF detection, you can relax the DTMF ; detection parameters. Relaxing them may make the DTMF detector more likely ; to have "talkoff" where DTMF is detected when it shouldn't be. ; ;relaxdtmf=yes By: tbsky (tbsky) 2012-09-23 22:08:24.581-0500 hi Alec: I had compiled/used relaxdtmf for years. but it didn't help me on DTMF callerID. (maybe some help, so I could get 90% success rate.) By: Alec Davis (alecdavis) 2012-09-24 00:23:07.830-0500 It's been a few days since you removed the REVERSE_TWIST and NORMAL_TWIST. Are you still getting 100% success rate with callerid? Are there any noticable issues, talkoff is what I'm concerned with, which as I understand it is where normal speech can trigger the DTMF detector. But I'm not sure what that would cause. By: tbsky (tbsky) 2012-09-25 05:48:04.784-0500 Yes. I check the log and check the callerID. every number seems fine and there are no lost digits! By: Rusty Newton (rnewton) 2012-09-28 18:33:48.778-0500 Alec, could you make a patch to have this solution configurable? By: Alec Davis (alecdavis) 2012-09-29 18:07:50.411-0500 in 'make menuselect' if RADIO_RELAX is enabled and if 'relaxdtmf=yes' in chan_dadhi.conf, then REVERSE_TWIST is made even wider. This may be enough to get 100% DTMF callerid recognition. see values below for different settings already available: DTMF_NORMAL_TWIST is always 6.3 with; RADIO_RELAX disabled in make menuselect relaxdtmf=no in chan_dahdi.conf REVERSE_TWIST = 2.5 relaxdtmf=yes in chan_dahdi.conf REVERSE_TWIST = 4.0 RADIO_RELAX enabled in make menuselect relaxdtmf=no in chan_dahdi.conf REVERSE_TWIST = 2.5 relaxdtmf=yes in chan_dahdi.conf REVERSE_TWIST = 6.5 When disabling the TWIST tests altogether as I suggested as a test to see if it helped, I got false positvies DTMF on the inbound speech, and asterisk sends me a DTMF digit during speech, a bit annoying. tbsky hasn't reported this yet. So the TWIST tests need to stay there, but just a wider tolerance. As to making this a configuration option, would we want a compile option in menuselect, a config option in chan_dahdi.conf, or some other method? By: Alec Davis (alecdavis) 2012-09-29 18:49:29.685-0500 referring to http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.24-198811-I!!PDF-E&type=items Power level difference between frequencies for different Administrations/RPOAs NTT = Max. 5 dB AT&T = +4 dB to -8 dB Danish = Max. 6 dB Australian = Max. 10 dB Brazilian = Max. 9 dB Also from ETSI ES 201 235-3 V1.3.1 (2006-03) Max. 6 dB Asterisk curernt is using the tightest, AT&T specification. So either we just widen the power level tests (TWIST) to the Widest stated, The Australian Standard, or complicate things and have a configuration option for the various administrations. By: Matt Jordan (mjordan) 2012-10-01 17:16:31.026-0500 My thoughts on this: It feels like 'relaxdtmf' was the wrong approach. This doesn't seem to be a 'yes/no' option. It feels like these values could be tweaked in chan_dahdi - and that while we should sanitize inputs to make sure they don't exceed potential values, we should probably expose that at some level. (With a caveat in the .conf file that if you don't know what these things are, you shouldn't tweak them) I'm not normally an advocate for having more config options, but in this case, that feels appropriate. When you have different devices, different locales, all demanding different things - config options are the way to go. By: Alec Davis (alecdavis) 2012-10-02 18:43:21.336-0500 Now up for review at https://reviewboard.asterisk.org/r/2141/ By: Alec Davis (alecdavis) 2012-10-03 01:35:46.706-0500 uploaded dtmf-configure-1.8.diff.txt for 1.8 SVN see configs/dsp.conf.sample for details on setting the following 4 variables ;dtmfnormaltwist=6.31 ;dtmfreversetwist=2.51 ;relaxdtmfnormaltwist=6.31 ;relaxdtmfreversetwist=3.98 The values shouldn't be < 2 or more > 100, which equate in dB to < 3.0dB and >20dB. The version up for review checks thense ranges. By: Alec Davis (alecdavis) 2012-10-03 23:54:36.109-0500 Commits applied to 1.8 SVN and up. URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=374365 URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=374384 | ||||||