[VoIP] Seize zap channel without dialing

[Donald Froula]

I hit upon an approach to try this trunk stacking
thing through my TDM-Over-Ethernet SF/MF trunks. I set
up two extensions to go to DISA over the trunks. What
I do is dial the extension that goes over the trunks
(similar to my 1-762-2601 number), but instead of
programming the number that gives ringback in the Dial
command, I call another extension with the DISA
application that returns a dial tone.

2602 => 1,Dial(ZAP/g1/9999)

9999 => 1,DISA(password|from-internal)

I then dial the same number again (2602), which seizes
the next line and gives a DISA dial tone again. This
is all via DTMF, so, yes, I am cheating. However, the
call setup on each loop through the trunk group is via
2600 and MF.

I saturated all 24 lines of the trunk group this way,
dialing one of my Evan Doorbell recordings on the last
trunk. The audio was looping through all 24
SF-controlled trunks. Both sides of the connection
being on the same switch, I only noticed slight
degradation in the audio. I blew off the call with a
chirp of 2600. This sounded exactly like blowing off a
call on a single trunk, except for the 24 disconnect
mrssages that flew by on the Asterisk console.

Now, if the looping could be done through another
ProjectMF switch, it might sound interesting.

Don

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

> 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
> 
=== message truncated ===