[asterisk-dev] DTMF end accepted without begin

Mon Dec 3 16:38:45 CST 2007

Well, speaking about "in practice" - I have a dozen of analog phones which generate so short inter-digit interval that even Asterisk's dsp.c without any modifications is unable to catch double digits properly. I haven't measured actual interval yet (will do tomorrow) but from the way how dsp.c works, I would guess interval is something about 20 ms. Which obviously violates the spec but who cares - I have to do something about it.

Anyway, my personal opinion regarding all that tuning is: "compile time options suck". First, they affect all usages of DSP even on channels where no problems exist and second, a few options interleaving the code can easily make it unreadable. I would prefer making DSP code tunable using some API so code always remain the same but channels may configure DSP per their needs. (Eventually taking DTMF options from channel configuration files). But it is work for future...

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: Tuesday, December 04, 2007 1:08 AM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] DTMF end accepted without begin

On Dec 3, 2007, at 1:24 PM, Dmitry Andrianov wrote:

Regarding the <http://www.blueboxmoon.com/bitweaver/blogs/view_post.php?post_id=10> patch - as I understand you allow up to 4 successive misses inside a digit to still consider it a single digit. With block size of 102 samples (12.75 ms @ 8 KHz sampling) it means about 50 ms. However, 50 ms is valid inter-digit interval (matching minimum interval duration requirements) .

In terms of spec (which is what I believe you are referring to), yes.  In practice, pressing the buttons just as fast as I possibly can (i.e. sitting there and pressing the number 2 over and over again) the smallest interval I saw was 7 (or about 90ms).  I tested a number of different automated dialers (phone speed dials, computer modem dials, flash transfer dials, etc) and all of those were also above 90ms...

Which means your patch is not for "general public" because it will almost certainly be eliminating double-digits even where they are should remain.

... so it should be relatively safe, but I do agree whole heartedly.  I wouldn't ever recommend this patch to trunk (which is why I have never posted it to mantis) except *possibly* as a compile time option, kind of like the RELAX_RADIO option as it's only purpose is to help with noisy lines, or other related issues.  And especially with a lot of areas beginning to go digital we should hopefully have less and less need for things like this.  I'm not a big fan of breaking specs, but being able to do this solved a 2 year old problem of people complaining about dialing one extension and getting another.

Daniel

From: asterisk-dev-bounces at lists.digium.com<mailto: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-- <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

_______________________________________________
--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/20071204/2df50251/attachment-0001.htm 