[asterisk-dev] DTMF end accepted without begin

Mon Dec 3 16:08:03 CST 2007

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 
> ] 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 
> > 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
>
> _______________________________________________
> --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/0a3b2349/attachment-0001.htm 