[VoIP] More ProjectMF Improvements

[Donald Froula]

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
> >>>       
> >> or
> >>     
> >>> through a local extension through my ATA.
> >>>
> >>> A nice side effect is the ability to do repeated
> >>> seizures of the trunk (with proper kerchunks)
> >>>       
> >> while
> >>     
> >>> sitting on the idle trunk.
> >>>
> >>> It much more like the old network.
> >>>
> >>>
> >>> Don
> >>>   
> >>>       
> >> _______________________________________________
> >> VoIP mailing list
> >> VoIP at ckts.info
> >> http://lists.ckts.info/mailman/listinfo/voip
> >> Project Web Page: http://www.ckts.info/
> >>
> >>     
> >
> > _______________________________________________
> > VoIP mailing list
> > VoIP at ckts.info
> > http://lists.ckts.info/mailman/listinfo/voip
> > Project Web Page: http://www.ckts.info/
> >
> >   
> _______________________________________________
> VoIP mailing list
> VoIP at ckts.info
> http://lists.ckts.info/mailman/listinfo/voip
> Project Web Page: http://www.ckts.info/
>