[VoIP] Seize zap channel without dialing

[Donald Froula]

This actually sound pretty amazing while listening on
the far end, if one dial an extension on the last
loop. When the originating end goes on-hook, you can
hear the string of kercheeps as the call disconnects,
one for each link. If the originating end taps a touch
tone digit, you can hear a series of clicks as the
tone propagates down the stack. Sounds pretty much
like the Classic Stacking recording!

If you want to try, here's how:

- Dial my ProjectMF trunk on 1-762-2601 (or
1-762-2602, skipping the net two steps, for those
without a blue box)
- Blow off the ringing with 2600
- After the wink, dial KP-2602-ST
- Wait for the dial tone
- Dial 2602 with the DTMF pad of the phone
- Wait for another dial tone
- Dial 2602 with the DTMF pad
- (Repeat X times, up to 23 times, as desired)
- On the last dial tone, dial a number on CNET with
011+CC_Number, again with the DTMF pad
- Answer the ringing phone. You are now talking to
yourself over X number of SF trunk links
- Hit a touch tone digit onthe originating phone.
Listen to it flash down the stack.
- Hang up. Hear the stack disconnect with a cheep of
2600 for each link

Notice how the connection takes longer to return the
dial tone on each loop through the stack, as the audio
delay on the forward MF (which you can't hear) gets
longer and longer.

Regardless of how you come in. you can blow the call
off in the forward direction with 2600 and hear the
stack disconnect on the far side.

Much fun!

Don

PS - For those without MF and 2600, I set up direct
access to the SF/DISA arrangement on 1-762-2602

Note, if others are trying this, your available trunk
pool may be less than 24.

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

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