[Asterisk-Users] Anyone using * in a live production environment?

[Stephen R. Besch]

Gavin Hamill wrote:

>Hullo again, all :)
>
>If you're using * to run telephony in a real business environment, can I
>trouble you to write a short paragraph about the setup, and how you've
>found the migration / daily use?
>  
>
Well, it's not technically a business, but we are running "*" for our 
research lab with the following hardware:

    4 analog POTS lines
    ADTRAN TSU-600
    FXO and FXS Plugins
    20 GS budgetone 100, 2 Analog phones
    Asus A7V, 900MHz Athalon, 256 MB Ram, 60GB hard disk
    100BaseT Ethernet environment using BayStack 450 switches
    Digium T100P
    RH9
    APC Smart-Ups 700

Notes: The choice of the channel bank was based on the possibility of 
future expansion for handling several other labs (and the fact that I 
got is and 6-V.35 cards, which I', not using) for $99 on e-bay). The 
installed infrastructure for the phone system at our University dictated 
our choice of POTS lines. We were also not given any choice about the 
Baystack switches . The Budgetone phones are probably not the ideal 
solution for a larger installation (yet), but met our needs perfectly, 
perform very well and are easy to set up and install.  The analog phones 
are to provide emergency service during power failures.  The UPS is 
sized small because we have emergency power failover after about 30 
seconds. The CPU and MOBO choices were based on experience with the 
products. A word of warning: Echo WILL be a potential problem on any 
system that has a transition point from POTS 2-wire lines to a  TDM 
environment (see my previous posting).  Here are some suggestions about 
dealing with it:

    1) Use the highest possible CPU speed.
             Why: The single greatest problem with software echo 
cancellation is the computational intensity of the autocorrelation 
needed to determine the amount of echo at each discrete delay time.  If 
the CPU is slow, the canceller will not be able to keep up with the real 
time nature of the computations.

    2) Enable MMX options (assuming that you have a CPU which supports it).
             Why: Same as in item 1.  In my case, this provided the 
single greatest improvement.

    3) Lower the number of taps in the echo canceller.
             Why: While this may seem counter intuitive, since the 
number of taps determines the amount of delay the canceller can deal 
with, most of the time the delay you hear is much longer than the delay 
seen by the echo canceller.  Decreasing the number of taps reduces the 
size of the autocorrelation and reduces the comptational load.  This 
allows the canceller to learn faster and keep up more easily.

    4) Turn off the KDE, etc.
        Why:  Saves computation cycles for the echo cancellation.  This 
is no joke, you can get on the phone, start up the desktop and hear the 
echo return.

    5) Attempt to balance the hybrid at the 2-line to 4 line interface.
            Why:  99% of the time, this is where the echo originates and 
this is where is should be fixed.  Unfortunately, this is not for the 
faint of heart, but if your line card has a hybrid balance adjustment 
(many don't), use it.  Also, with multiple simultaneous calls, this may 
be the only real solution.  Part of the problem arises from the use of 
lower impedance telephone wiring nowdays. The typical characteristic 
impedance of Cat5 twisted pair is about 100 ohms and many line cards are 
optimized for a 600 ohm line. This is made worse if the DC resistance of 
the wiring to the CO switch is relatively low.  I haven't tried this 
myself, but you might try something as simple as a 500 ohm variable 
resistor in series with the ring line and adjust for minimum echo.  If 
it gets worse, you haven't lost anything, just take the resistor out of 
the line. If it works, measure the value of the resistor when set for 
minimum echo and replace it with a fixed value resistor.

    6) Try messing with Tx and Rx gains.
          Why: This is a reincarnation of the technique used to cancel 
echo on long lines in the early part of the 20th century. The idea is 
that the perception of echo gets worse as echo volume increases and as 
delay increases.  You can sometimes reduce echo to an "acceptable" level 
if you attenuate it enough, especially if the echo canceller takes care 
of part of it.  The problem is that you will likely run into 
unacceptably low volume levels.  That's why this technique was abandoned 
by the PSTN: You've all seen the movies of people in the 1920's yelling 
into phones on long distance calls!

Finally, while I had to do some head scratching and a lot of reading to 
get the system set up, I would have to say that the installation went 
without any major problems.  Once configured, it runs flawlessly and 
requires very little maintainence.

Steve Besch