[asterisk-dev] [Code Review]: dsp.c: dtmf_detect, Fix multiple issues when no-interdigit delay is present.

[Alec Davis]

> On Aug. 30, 2012, 4:05 p.m., rmudgett wrote:
> > trunk/main/dsp.c, line 750
> > <https://reviewboard.asterisk.org/r/2085/diff/2/?file=31096#file31096line750>
> >
> >     C should end here as there were two misses of C.
> 
> Alec Davis wrote:
>     IIRC the DTMF spec says '2' continuous hits of the same BEGIN digit or silence.
> 
> rmudgett wrote:
>     To which spec are you referring?
> 
> Alec Davis wrote:
>     ETSI ES 201 235-3 V1.3.1 (2006-03)
>     
>     4.2.2 Digit Recognition Condition (DRC) requirements
>     If a valid signal present at the DTMF receiver input fulfils the conditions set out in items a) and b) then the digit shall be
>     indicated as recognized:
>     a) the signal condition shall be preceded by the continuous absence of valid signal condition for more than 40 ms
>     or (optionally) by a recognized digit that is different to the current digit; and
>     b) the signal condition shall then exist continuously for more than 40 ms.
>     If a valid signal at the receiver input has been present for less than 20 ms, the digit shall not be indicated as recognized
> 
> rmudgett wrote:
>     This is just stating when a digit is considered recognized.  This passage would be for recognizing when D is started in the example.  It is not stating when C should stop being recognized.
> 
> Alec Davis wrote:
>     from page 10 of that spec, hopefully I've redrawn it correctly here.
>     
>     I interpret;
>      'When DRC' as begin we're in the middle of a current digit.
>      'When not DRC' as begin we've detected valid silence.
>     
>     As an aid to the understanding of clause 4.2.2, table 3 is given.
>         Table 3: Digit recognition condition requirements
>     
>     Character recognition: When not DRC * and then
>     	Shall exist VSC > 40 ms 
>     	May exist 20 ms . VSC . 40 ms
>     	Shall not exist VSC < 20 ms
>     
>     Character recognition: When DRC and then
>     	Shall cease Not VSC > 40 ms
>     	May cease 20 ms . Not VSC . 40 ms
>     	Shall not cease Not VSC < 20 ms
>     
>     * or optionally a different digit recognition condition
>     Legend: VSC The continuous existence of a valid signal condition.
>     	Not VSC The continuous non-existence of valid signal condition.
>     	DRC The existence of digit recognition condition.
>     	Not DRC The non-existence of digit recognition condition.
>

oops, 'as begin' should have been 'as being'


- Alec


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2085/#review6983
-----------------------------------------------------------


On Aug. 28, 2012, 5:47 p.m., Alec Davis wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2085/
> -----------------------------------------------------------
> 
> (Updated Aug. 28, 2012, 5:47 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Document DTMF events for different sequences.
> 
> * Fix extra hit required when new DIGIT is sent without any interdigit delay.
> * Fix when DTMF_HITS_TO_BEGIN = 2, and no interdigit gap, that BEGIN is posted. 
> * Fix situation where a flakey detect, would clear the current_hit (indicating an END), which may not have been the case.
> 
> 
> Diffs
> -----
> 
>   trunk/main/dsp.c 371689 
> 
> Diff: https://reviewboard.asterisk.org/r/2085/diff
> 
> 
> Testing
> -------
> 
> On production box for 24 hours. 888 digit's now received.
> 
> The change here doesn't affect normal tone on/tone off, it changes the case when no interdigit pause is received between 2 digits, now the 2 digit has the same detect time as if there had been an interdigit pause before hand.
> 
> 
> Thanks,
> 
> Alec
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120830/2d67e463/attachment.htm>