[VoIP] Tandem Stacking over Asterisk

[Donald Froula]

I changed the setting of "toneduration" in
/etc/zapata.conf from 68 ms. to 100ms. This increases
the duration of the MF tones on the SF trunk group
during call setup, but also increases the length of
regenerated DTMF tones sent down the line. This
enhances the "flash forward" effect on a tandem stack
by extending the propagation time through each link.

The reason one gets a hook-flash effect when dialing
DTMF through the stack is that The ATA receives the
DTMF digit, converts it to a SIP message, Zaptel
converts back to audio on the first SF trunk link,
Zaptel converts back to an internal message on the
receiving end, then back to analog DTMF on the next
link and so on. This adds a 100 ms. delay for each
link on each flash of a DTMF digit down the stack.

Don

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

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