[asterisk-bugs] [Asterisk 0016749]: [patch] DSP progress detection unable to detect SIT

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16749 
====================================================================== 
Reported By:                dant
Assigned To:                tilghman
====================================================================== 
Project:                    Asterisk
Issue ID:                   16749
Category:                   Core/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Target Version:             1.6.2.9
Asterisk Version:           SVN 
JIRA:                       SWP-837 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-02-02 00:34 CST
Last Modified:              2010-05-18 18:27 CDT
====================================================================== 
Summary:                    [patch] DSP progress detection unable to detect SIT
Description: 
The DSP should be able to detect the SIT. The existing code checks for the
first tone followed by the second tone, followed by the third tone in
sequence and on detection of the third tone allows firing a CONGESTION
control frame.

This unfortunately doesn't work due to the fact that entire SIT is about 1
second long, the DSP is working with smaller samples and the code will not
stay in a second or third tone state beyond one pass.

This issue is being raised against trunk, but, the problem appears to be
present even in 1.2.
====================================================================== 

---------------------------------------------------------------------- 
 (0122107) dant (reporter) - 2010-05-18 18:27
 https://issues.asterisk.org/view.php?id=16749#c122107 
---------------------------------------------------------------------- 
tilghman, 
Are you really sure that that is the case? This was the only change to
dsp.c...

Looking at the code again, this appears to be called for each frame, 20ms
long... An SIT, as you know, is made up of approx 330ms of 950hz, followed
by approx 330ms of 1400hz, followed by approx 300ms of 1800hz... So, for
the first frame of SIT, 950hz would be detected and newstate would be set
to 5 (DSP_TONE_STATE_SPECIAL1), for the subsequent 15 frames of 950hz
newstate would continue to be set to 5, on line 1023 newstate would be
compared to the current state (dsp->tstate) and if it was the same,
dsp->tcount would be incremented, so, reaching 15... for the first frame
that 1400hz is detected, the current state would be first checked to make
sure it was 5, if it was, newstate would be set to 6
(DSP_TONE_STATE_SPECIAL2), for the second frame that 1400hz was detected
the current state would be 6, so the check to make sure it was 5 would
fail, and newstate would not be set. At line 1023 dsp->tstate would not
equal newstate as newstate would still have it's initialised value of 0
(DSP_TONE_STATE_SILENCE) due to the fact that while 1400hz was found, the
current state was not 5, as such, at line 1071 the debug messages above
would be output and the current state would be set to newstate, in this
case 0. There could never be a way for the switch statement on line 1028 to
ever match on a current state of 7 even if the SIT was 3 frames long...

The patch does change this behavior, on the second frame of 1400hz being
detected the enclosed if statement would evaluate true as the current state
of 6 does match 5 || 6... as a result, at line 1023 it would find that the
state hadn't changed, it wouldn't reset the state to 0 as line 1071 would
never by hit and for all subsequent instances of 1400hz newstate would
continue to be set to 6 allowing for an eventual setting of newstate to 7
(DSP_TONE_STATE_SPECIAL3) when the first 1800hz frame was detected such
that on the second frame the switch statement on line 1028 would match a
current state of 7, and on the 4th frame of that the threshold would be
reached and res would be set to AST_CONTROL_CONGESTION...
To me, that does indeed seem to resolve the logic problem with the current
code... 

Thanks... 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-18 18:27 dant           Note Added: 0122107                          
======================================================================