[VoIP] More ProjectMF Improvements

[Donald Froula]

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.
> >>>
> >>> Don
> >>>
> >>> --- Steph Kerman <stfkerman at jps.net> wrote:
> >>>
> >>>   
> >>>       
> >>>> Don,
> >>>>
> >>>> I'd have thought that in the actual network,
> >>>>         
> >> 200mS
> >>     
> >>>> or more would have 
> >>>> been required, in other words, a normal on-hook
> >>>> duration.  The SF after 
> >>>> all, makes the incoming trunk at the far
> >>>> (terminating) end think that it 
> >>>> received a release forward signal from the near
> >>>> (originating) end.
> >>>>
> >>>> I understand the difficulty of achieving the
> >>>>         
> >> 250mS
> >>     
> >>>> duration but I think 
> >>>> that was actually realistic.  Recognizing a
> 75mS
> >>>> duration might make it 
> >>>> susceptible to talk-off.
> >>>>
> >>>> Does the SF detection function in * contain
> both
> >>>>         
> >> a
> >>     
> >>>> signal (2600 Hz BP) 
> >>>> and guard (2600 Hz notch) channel whose output
> >>>> energy levels are 
> >>>> compared to determine whether SF tone is
> present,
> >>>> the way a real SF 
> >>>> signaling unit does?
> >>>>
> >>>> Steph
> >>>>
> >>>> Donald Froula wrote:
> >>>>     
> >>>>         
> >>>>> After comments on the difficulty of seizing a
> >>>>> trunk on my box when coming in on the PSTN, I
> >>>>>       
> >>>>>           
> >>>> decided
> >>>>     
> >>>>         
> >>>>> to investigate further. I found that code that
> >>>>>       
> >>>>>           
> >>>> called
> >>>>     
> >>>>         
> >>>>> the SF detector required 250 ms of continuous
> SF
> >>>>>       
> >>>>>           
> >>>> to
> >>>>     
> >>>>         
> >>>>> declare an "on-hook". Because of noise,
> vocoder
> >>>>> issues, etc., this was really hard to achieve.
> I
> >>>>> shortened that time to 75 ms. It works MUCH
> >>>>>           
> >> better
> >>     
> >>>>> when coming in over the PSTN, even better on
> >>>>>           
> >> CNET
> >>     
> 
=== message truncated ===