[VoIP] Seize zap channel without dialing

[Donald Froula]

Mark, you asked about whether or not a 2600 audio blip
might get propagated through the system for 2600
flashes less than rxwink in length. Actually, they
would. The 2600 notch filter DSP code takes a
millisecond or so to kick in and out, creating an
audible "blip" both on 2600 application and removal.
Although this has no effect on supervision, being
purely an audio effect, it might provided something
like the old sound with the latency delay through
VOIP.

Don

--- Donald Froula <dfroula at sbcglobal.net> wrote:

> Hi, Mark. Good to hear from you "down under",
> 
> I corrected the trunk-hang problem by a patch I
> added
> to Asterisk that restored 2600 supervision based
> upon
> steady-state 2600. It sounds odd, but seizure of the
> trunk with the original set of patches was based on
> REMOVAL of steady 2600. Applying steady 2600 after
> seizure did not disconnect the call. This was to
> allow
> the user to 'box another call after the previous far
> end call disconnected. Evan Doorbell calls this a
> "goody" trunk in his recordings. I accomplished the
> "goody" arrangement after my patch by changing some
> settings in /etc/zaptel.conf. Short answer: The
> trunks
> now disconnect correctly from stacking attempts.
> 
> It is true that the timing of the minimum 2600 tone
> duration to seize and also the length of the reverse
> wink can both be set by configuration settings in
> /etc/asterisk/zapata.conf. I have mine set to
> rxwink=50 (requires a minumum 50 ms. of 2600 to
> seize,
> for talkoff protection) and wink=250 (sets
> acknowledgement wink to 250 ms.). The "wink=250"
> setting is purely cosmetic, as the near-end trunks
> are
> using immediate dialing, and is just for realism and
> an indication to the 'box user that the MF receiver
> has been successfully attached to the far end.
> 
> What you are asking is whether or not 2600 bursts
> shorter than the setting of rxwink will cause a
> momentary application of supervision that will not
> disconnect the call. This was called "ring forward"
> or
> "operator flash" in the old days. Unfortunately,
> ProjectMF completely ignores any forward application
> of 2600 that is less than rxwink in duration.
> Reverse
> 2600 is completely ignored. In the forward
> direction,
> anything greater than 50 ms. simply hangs up the
> call.
> There is no intermediate state to allow the
> wonderful
> sound of all those relays clattering you can hear in
> the "classic tandem stacking" recording on
> Phonetrips.
> In the reverse direction, the notch filters are
> still
> operative, but I have 2600 supervision disabled by
> the
> settings in /etc/zaptel.conf to "goody" the call.
> 
> If I can figure out how to dump into a seized trunk
> without dialing anything, allowing the 'boxer to MF
> without the 2600, stacking should be possible. The
> accumulated echo might be interesting. It would
> probably drive the Zaptel echo cancellers nuts!
> Right
> now, the 'boxer needs to blow 2600 on each
> successive
> link to restart the MF receiver, but this
> disconnects
> back to the first link. Maybe some kind of "guard
> banding" would work to blow off the last link while
> leaving the rest of the stack untouched, but I doubt
> it.
> 
> Your trunk simulator sounds very interesting. I
> wonder
> if it can be integrated with ProjectMF very easily.
> I
> received a very nice note from Evan Doorbell
> regarding
> my system. He found it interesting, but, without the
> complexity of the old system, of limited interest.
> Still, I think it's pretty cool to be able to blue
> box
> at all. I guess that thrill has gotten hard-wired
> into
> my brain somehow! I've borrowed lots of ringback
> sounds from Evan's "long distance ambrosia" tape of
> high-quality long distance call completion sounds.
> 
> Try the system, if you haven't recently. It's
> working
> very well, now on a new dedicated server with proper
> power backups and auto-boot recovery capability.
> 
> Best,
> 
> Don
> 
> --- Mad Mark <madmanmarkau at hotmail.com> wrote:
> 
> > 
> > Hey Don. I've been lurking for a while but had to
> > post when I saw this.
> > 
> > I remember we discussed this a while back over
> > E-Mail. You had tried stacking by dialing out of
> > your system and dialing back in, trying to stack
> the
> > call. You said it caused the system not release
> the
> > trunks further down the line when the call hung
> up,
> > and the system needed restarting to rectify the
> > problem. Are you still having this problem, or was
> > it sorted?
> > 
> > Now, if you're able to stack on a ProjectMF
> system,
> > from what I've been able to discern flashing the
> > hook-switch won't work, correct? I've been wrong
> on
> > many an occasion before, and am just starting to
> > learn the quirks of ProjectMF.
> > 
> > I think I've got this right. Tell me if I'm wrong.
> > As long as the 2600 supervision "flash" you send
> is
> > not longer than x milliseconds set in the config
> > files, ProjectMF shouldn't disconnect the call.
> > HOWEVER, even on short flashes, will you still get
> > the "bip-bip-bip-BIP-BIP-BIP-BIP" effect (the 2600
> > flash traveling from exchange to exchange) on a
> > ProjectMF system? I'm thinking you won't without
> > more "cosmetic" coding.
> > 
> > Work on the exchange emulator is progressing much
> > slower than I anticipated, mainly due to lack of
> > time (and motivation) to work on it. I have,
> > however, almost completed a wire-carrier trunk
> DSP.
> > 
> > For those that don't know, I'm slowly writing an
> > actual phone network emulator to run on your local
> > machine, able to simulate many different exchange
> > types/configurations and trunk types, all with the
> > old sounds (panel-pulses, SxS noise, XBT sounds,
> > carrier noise...).
> > 
> > The only part I have completed so far is audio I/O
> > and one trunk type, as well as miscellaneous other
> > items. The trunk has programmable dynamics, having
> > adjustable frequency response, looping wave file
> for
> > carrier noise, and new as of last night, the
> > "singing wires" effect (which I'll complete and
> test
> > tonight.)
> > 
> > Sorry about the long message, but I tend to
> rant...
> > 
> > 
> > >From: dfroula at sbcglobal.net
> > >To: voip at ckts.info
> > >Date: Thu, 27 Sep 2007 08:25:56 -0700
> > >Subject: [VoIP] Seize zap channel without dialing
> > >I wonder if anyone knows how to do accomplish the
> > >following.
> > > 
> > >I want to be able to seize one of my SF/MF Zaptel
> > >trunks without dialing any digits.
> > > 
> > >I normally route a call through my
> T1-Over-Ethernet
> > >trunks with a simple dial command like:
> > > 
> > >exten => 2600,1,Dial(ZAP/g1/999)
> > >exten => 2600,2,HangUp
> > > 
> > >This dials extensions "999" through the SF/MF
> > trunks,
> > >and allows the blue box user to seize the ringing
> > 999
> > >extension with 2600.
> > > 
> > >I want to be able to simply seize the line
> without
> > >dialing anything, allowing the user to "stack"
> > calls
> > >without having to blow 2600 and release the
> entire
> > >stack. Just seizing the trunk on connecting would
> > >allow the blue box user to simply outpulse the MF
> > >digits within the trunk timeout window (5 seconds
> > or
> > >so), similar to the Phonetrips "classic tandem
> > >stacking" recording.
> > > 
> > >I tried omitting the extension:
> > > 
> > >exten => 2600,1,Dial(ZAP/g1/)
> > >exten => 2600,2,HangUp
> 
=== message truncated ===