Asterisk setup research lab

Asterisk Setup for a research lab

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


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:

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.
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.
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.
Turn off the KDE, Gnome, X-windows 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.
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.
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

Created by: oej, Last modification: Tue 04 of Nov, 2003 (21:21 UTC)
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+