[VoIP] Zaptel.c patch?

Tue Oct 23 11:36:32 CDT 2007

Max,

Thanks! I wondered about the purpose of the SF patch.
So, SF is being filtered and sent via robbed-bit
signalling over A T1 channel? I remember years ago
connecting ITT channel banks to my company's early
celular switches. While monitoring the digital stream,
I recall audio being passed back from FXS cards on our
test phones, although they were on-hook. We leveraged
this "feature" for some testing. I'd forgotten that.

I have a Berry 314A test set than can do 2600 SF dial
pulses. I'll have to fool around with John N's switch.
Sound cool!

Obviously, I need the SF modifications for ProjectMF
intact. I wonder if the unmute parts of the patch
would work to allow the user to hear forward MF on my
TDMOE fake T1 trunk arrangement? I suspect that thi
smay not work, as the MF is in the forward direction.
If the reverse path is unmuted, I'm hoping some
reflection of the MF may be audible to the user during
the MF outpulsing over the trunk during initial call
setup, before and blue box intervention. Any
suggestions how to modify the patch to remove the SF
signalling parts, while leaving the essential unmuting
code intact?

Thanks for the very concise reply!

Best,

Don

--- ikjtel <ikj1234i at yahoo.com> wrote:

> 
> Hi Don
> 
> I've been following with great interest your MF and
> 2600 project, delighted to hear from you.  If
> there's
> anything I might do to help, let me know.
> 
> There are actually two separate things going on in
> the
> patch, perhaps should have been separated, but...
> 
> The 2600 additions were to enable SF-to-DC
> conversion
> for incoming VOIP audio (assuming an FXO leg) for
> application to an incoming selector in a SxS office.
> 
> The intent was to allow distant callers (who must be
> equipped for SF outpulsing) directly to dial through
> the switches in remote EM offices *and* to hear the
> switches operating in real time.
> 
> The X100P (junk) cards won't do it, but most channel
> bank FXO's will also pass audio back to the remote
> caller EVEN WHEN ONHOOK.  On John Novack's W.E. SxS
> machine you used to be able to hear the dialtone
> motor/generator set winding down like an old record
> player turntable by blasting 2600 at the 1st
> selector
> and listening as the FXO line goes onhook....
> 
> I believe Mr. Ratguy (Jayson Smith) also has
> successfully SF'ed into offices equipped with some
> versions of this patch.
> 
> As for the code itself, the bulk of the zaptel
> changes
> were simply to move the existing sf_detect()
> function
> upwards in the file so its fn definition is defined
> at
> an earlier point.  There is code added to invoke
> sf_detect for audio received via the WAN.  This is
> the
> actual SF-to-DC conversion.  It implements a digital
> LPF to try to cover up IP packet loss/latency; the
> resulting filtered DC signal is used to toggle the
> FXO's transmitted hook state.  If I recall
> correctly,
> there's code to notch out any 2600 that might appear
> in frames of audio that are flying by (in that same
> direction of flow), although in this particular case
> it's sort of moot because by definition the very
> next
> link in the chain is in the onhook state (where no
> audio is presumed to be proceeding to whatever
> follows
> next ;)
> 
> Also, note that it's NOT true that you only need to
> defeat the built-in audio muting just in zaptel
> (unless you're using zaptel by itself without
> asterisk, which most people don't do, although
> perhaps
> you are)...  In addition to commenting out the
> section
> of zaptel code you mentioned (below), there's also
> some "undesirable" muting code in asterisk
> (chan_zap.c) that you need to defeat.  Also, for my
> application it seemed that native bridging needed to
> go (an interesting feature, an optimization, not
> strictly essential).
> 
> Here are the current links if I recall correctly
> http://www.lightlink.com/mhp/sf/sf2.patch
> http://www.lightlink.com/mhp/sf/sf-0.2.tar.gz
> 
> Best
> 
> Max
> 
> --- Donald Froula <dfroula at sbcglobal.net> wrote:
> 
> > Max, I'm a CNET member on extension 1-762.
> > 
> > On my Asterisk box, I'm running some Zaptel
> patches
> > that correctly enable 2600 SF/MF signalling,like
> > that
> > of the old blue box days. I have this working over
> a
> > TDMOE 24 member trunk-group using two extra looped
> > Ethernet cards.
> > 
> > All works very well, except the MF outpulsing over
> > the
> > trunks can not be heard when a call is set up. I
> was
> > hoping your patch on the CNET web site might help
> > here.
> > 
> > However, the patch seems to fool with the SF notch
> > filter, which I am using for the trunks.
> > 
> > I seems the only thing needed to unmute Zaptel on
> > call
> > setup is to comment out the following block of
> code,
> > which your patch does:
> > 
> > if 0
> > 
> >      if (ms->dialing) ms->afterdialingtimer = 50;
> >         else if (ms->afterdialingtimer)
> > ms->afterdialingtimer--;
> >         if (ms->afterdialingtimer && (!(ms->flags
> &
> > ZT_FLAG_PSEUDO))) {
> >                 /* Be careful since memset is
> likely
> > a
> > macro */
> >                 rxb[0] = ZT_LIN2X(0, ms);
> >                 memset(&rxb[1], rxb[0],
> ZT_CHUNKSIZE
> > -
> > 1);  /* receive as silence if dialing */
> >         }
> > 
> > #endif
> > 
> > Could you explain a bit how the patch works,
> > especially th part that affects the notch filter?
> > 
> > Best,
> > 
> > Don Froula
> > 
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> http://mail.yahoo.com 
> 