[asterisk-dev] DTMF end accepted without begin

[Dmitry Andrianov]

>> Based upon my own research and that of somebody else (sorry can't remember name) that did some major fixing up of code in the dsp.c DTMF detection code recently,

I believe you are talking about Tony Mountifield  (the "DTMF detection in dsp.c intolerant?" thread on asterisk-dev). This finally turned to a patch http://bugs.digium.com/view.php?id=10535 However this patch is already part of Asterisk.

To John: the DTMF detection for Zap channels is done in Asterisk (main/dsp.c)
Can you give me a few sample wav files of calls where DTMF detection is unreliable. (Please do not mix/join channel's in and out)


Regards,
Dmitry Andrianov

From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Daniel Hazelbaker
Sent: Monday, December 03, 2007 9:31 PM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] DTMF end accepted without begin

Have you tried setting the relaxdtmf setting in /etc/asterisk/zapata.conf?  You also have to turn on "Relax DTMF for Radio Applications" (even though it has nothing to do with radio communications).  That might solve the completely missing tones.

Based upon my own research and that of somebody else (sorry can't remember name) that did some major fixing up of code in the dsp.c DTMF detection code recently, dsp.c does the actual DTMF detection.  Zaptel doesn't seem to do squat when it comes to DTMF detection.

You can play around in dsp.c near line 165.  Play with those DTMF_ defines (make sure you are in the right #ifdef) and you might be able to tweak some stuff to better detect in your situation.  Personally I found that when I turned on the relaxdtmf option people's voices were being detected as tones, but you might be able to get a more precise "relaxed" mode.

Also, my patch stemmed from the following logging information.  You might be able to turn it on and see exactly what is happening when tones are missed.  (Warning: this will spit out a TON of logging information).

This is from 1.4.12, line 591 and surrounding:

                            && goertzel_result(&s->row_out2nd[best_row])*DTMF_2ND_HARMONIC_ROW < row_energy[best_row]) {
#else
                        /* ... and fraction of total energy test */
ADD->            ast_log(LOG_NOTICE, "dtmf_detect row_energy=%f, col_energy=%f, total=%f > %f (%f + %f)", row_energy[best_row], col_energy[best_col],
ADD->                                      (row_energy[best_row] + col_energy[best_col]), (DTMF_TO_TOTAL_ENERGY * s->energy), DTMF_TO_TOTAL_ENERGY, s->energy);
                        if (i >= 4 &&
                            (row_energy[best_row] + col_energy[best_col]) > DTMF_TO_TOTAL_ENERGY*s->energy) {
#endif
                                /* Got a hit */

It is a bit messy, but it might help track down exactly what "energy" values you would need to catch those false negatives.

Daniel

On Dec 3, 2007, at 9:55 AM, John Aughey wrote:


We actually get both the "wobble" detection (multiple tones detected with one button press) and missing detection (press 201 and it detects 01 missing the 2).  The suggestions on voip-info have not yet helped and the lack of DTMF_BEGIN events concern me.  It's also not clear right now where the dtmf detection is done, if it's in the zaptel-1.4.6 code base or within asterisk-1.4.14/main/dsp.c.  They both seem to do tone detection.

John
On Dec 3, 2007 10:31 AM, Daniel Hazelbaker < daniel at highdesertchurch.com<mailto:daniel at highdesertchurch.com>> wrote:
On Dec 2, 2007, at 5:35 PM, John Aughey wrote:

> The begin frames (and associated end frames) are helpful to filter
> out short dtmf reads.  There's even a #define which specifies the
> minimum length of a dtmf tone.  One problem we're having is multiple
> dtmf detections on a noisy cell phone connection, which should be
> mostly filtered by knowing the begin and end time so that the length
> can be properly measured and filtered if needed.
>
> John
If you are running 1.4.15 (it should apply down to .12 as well I
believe) then you can try this patch.  We have a similar problem at
our site, except it is due to a junky NEC that is currently the front-
end to the Telco.  Tones would have a drop-out in the middle of them
so Asterisk was detected double digits.  i.e. they dial 235 and it
reads 2335.  With this patch the "wobble" tones are almost never an
issue anymore.

<http://www.blueboxmoon.com/bitweaver/blogs/view_post.php?post_id=10>

Daniel

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20071203/f010f3b6/attachment-0001.htm