[VoIP] More ProjectMF Improvements

[Donald Froula]

Well, the low-level SF detect routine returns 3 values
to the on-hook processing logic:

0 = Nothing detected
1 = Tone detected
2 = No tone detected

Trying to figure the difference between 0 and 1. I
think 1 may indicate a transition fron tone to no
tone.

It sounds that the hard work may be done. I just need
to change the logic to compare counts of 1 and 2.

Don

--- Steph Kerman <stfkerman at jps.net> wrote:

> Don,
> 
> I think that's why it's having such a hard time. IMO
> it needs an 
> independent counter for Sig Pres and Sig Abs.
> 
> Steph
> 
> Donald Froula wrote:
> > Steph,
> >
> > You are exactly right on how the algorithm works.
> >
> > It seems that when 2600 is detected, the code
> > initializes a timer counter to, say, 250. While
> 2600
> > is present, the code executes a loop once per
> > millisecond, decrementing a counter each time.
> When
> > the counter hits zero, an "on-hook" event is
> > generated. Any brief interruption will reset the
> > counter back to 250. This is the counter I now
> > initialize to 75. There's also some other stuff in
> the
> > loop, but that's basically how it works.
> >
> > I like your idea of accumulating "hits". Maybe a
> > leaky-bucket approach would work well.
> >
> > Don
> >
> > --- Steph Kerman <stfkerman at jps.net> wrote:
> >
> >   
> >> Generally, for any signal detection function,
> >> whether MF, DTMF or SF, 
> >> there is a specified minimum signal presence time
> >> before recognition and 
> >> a minimum signal absence time before absence is
> >> recognized.  This is 
> >> necessary to bridge clicks and other noise
> bursts. 
> >>
> >> Perhaps these methods need to be dealt with in a
> >> slightly different way 
> >> to cope with the impairments in a Voip
> environment
> >> to deal better with 
> >> the noise hits, such as comparing the number of
> >> short intervals during 
> >> which tone was present over a longer interval
> with
> >> the number during 
> >> which it was absent over a longer interval rather
> >> than simply resetting 
> >> the timing counter to zero each time a noise hit
> >> makes the signal seem 
> >> to be absent (if that is what they are doing, an
> >> assumption on my part).
> >>
> >> Another methodology might involve distinguishing
> 3
> >> signal conditions: 
> >> signal, noise and silence as a specific 3rd
> >> condition rather than simply 
> >> considering noise and silence to be equivalent
> >> non-signal conditions. 
> >>
> >> Also, how is buffer underflow handled?  I assume
> >> that happens sometimes 
> >> due to the need to minimize latency.  The shorter
> >> the buffer is made to 
> >> minimize latency, the higher the rate of
> underflow
> >> ought to be.  Seems 
> >> to me that the signal timing counter should stop
> >> whenever there is an 
> >> underflow so this case does not invalidate signal
> >> presence and absence 
> >> timing.
> >>
> >> Steph
> >>
> >> Donald Froula wrote:
> >>     
> >>> I think you're on to something with the
> hysteresis
> >>> idea.
> >>>
> >>> This could explain why, before the timing
> changes,
> >>>       
> >> it
> >>     
> >>> was much easier to seize an unsupervised trunk
> >>>       
> >> than
> >>     
> >>> one where the call was in-progress or had gone
> >>> through.
> >>>
> >>> A better solution might be to play with the
> >>>       
> >> hysteresis
> >>     
> >>> algorithm. I'll look over the code.
> >>>
> >>> Don
> >>>
> >>>
> >>>
> >>> --- Steph Kerman <stfkerman at jps.net> wrote:
> >>>
> >>>   
> >>>       
> >>>> Thanks Don.
> >>>>
> >>>> As I think about it further, a real SF unit has
> >>>> hysteresis.  The initial 
> >>>> burst of on-hook 2600 Hz tone is at elevated
> >>>>         
> >> level. 
> >>     
> >>>> After a brief 
> >>>> interval, perhaps 500-1000 mS it drops to a
> lower
> >>>> level.  Does the * 
> >>>> implementation have a higher detect and lower
> >>>>         
> >> hold
> >>     
> >>>> level?
> >>>>
> >>>> Steph
> >>>>
> >>>> Donald Froula wrote:
> >>>>     
> >>>>         
> >>>>> A very good question.
> >>>>>
> >>>>> Yes, I believe the SF detector works this way
> >>>>>           
> >> (BP
> >>     
> >>>>>       
> >>>>>           
> >>>> and
> >>>>     
> >>>>         
> >>>>> notch combined), so there is a guard band
> >>>>>       
> >>>>>           
> >>>> function. I
> >>>>     
> >>>>         
> >>>>> think, looking at the code.
> >>>>>
> >>>>> The 75ms duration test is applied after it
> >>>>>           
> >> passes
> >>     
> >>>>>       
> >>>>>           
> >>>> the
> >>>>     
> >>>>         
> >>>>> BP/notch test for a minimum number of samples.
> I
> >>>>> played with the sample count in the DSP
> routines
> >>>>>       
> >>>>>           
> >>>> and
> >>>>     
> >>>>         
> >>>>> wound up with a very talkoff-prone connection.
> >>>>> Decreasing the timing requirement from 250 ms.
> >>>>>           
> >> to
> >>     
> >>>>>       
> >>>>>           
> >>>> 75
> >>>>     
> >>>>         
> >>>>> ms does not increase talkoff or affect normal
> >>>>>           
> >> call
> >>     
> >>>>> completion, verified by watching debug
> messages
> >>>>>           
> >> on
> >>     
> >>>>>       
> >>>>>           
> >>>> the
> >>>>     
> >>>>         
> >>>>> console.
> >>>>>
> 
=== message truncated ===