I am using a digium tdm2403e card
My configuration is
PSTN -> tdm24xxp->asterisk->linksys(pap/2)->analog phones
I am receiving tremendous echo on my analog phones that receive the calls from the pstn.
My configuration files for zapata.conf is attached for reference.
I have tried various changes in zapata.conf to attain echo cancellation but to no avail.
when i check zap show channels during a call it shows
Echo Cancellation 128 taps currently on
I have also tried the mark2 aggressive suppression echo cancellor configurable in ztconfig.h
I have checked the linksys fxs which also show all echo cancellation parameters as enabled.
I am using
Please reply at the earliest
My zapata.conf reads as follows
rxgain = 8.0
txgain = 0.0
channel => 13-24
Have you used ztmonitor to check if your rxgain and txgain are not set to high? This can cause alot of echo if the volumes are set too high…
Also try and set echotraining=800…
Hope some of this information helps…
I tried making echo training = 800 and it is not helping. .
Actually i will try using ztmonitor and will come back with the feedback . Actually the site is at a remote place and its a little difficult to monitor.
Will get back when i do.
if you have onboard echo can, the software routines should never be used. have you tried a later version of Zaptel ? 1.2.3 is getting on a bit now, and there have been a number of improvements since that was released.
Is there a specific reason that you have rxgain set so high with txgain set to 0.
Try a much lower value in rxgain and then reboot, I would imagine that this is what is causing the echo.
Let us know how you get on?
I am using the onboard echo cancellation card.
I am unable to try the newer releases of zaptel because my kernel is 2.4 as i am using fedora core 2.
Since this is at a remote place i am very skeptical of updating my kernel.
I tried lower values of rxgain and txgain before making it 8.0
i had default values of zero for both
Should i try like negative values or something else with rxgain txgain
let me just back to the basics.
how do i make sure that the card is actually doing the hardware based echo can that it is supposed to do?
i have a 2.4 linux kernel with a fedore core 2 distro, asterisk 1.2.8 and zaptel 1.2.3.
i read up somewhere that for the card we are using - a tdm2403e (with octasic echo-cancellation), a minimum of linux 2.6 is required. if that is so, then i am currently barking up the entirely wrong tree
IME, Zaptel performance is better with 2.6 kernels. and it also seems to improve with Zaptel releases … well … most of them, there is the odd glitch.
You should be able to use the latest Zaptel release with your 1.4 kernel just fine. If you haven’t disabled the on board echo canceller, then any changes to the software echo canceller in zapata.conf will have no affect at all.
To clarify things for you, if you have the onboard echo canceling hardware, you do not want to enable echo canceling or echo training in your zapata.conf file. The drivers will automatically detect the onboard canceling hardware and use it. You can see it is active when the four leds on the board are pulsing in sequence.
Personally, I have had horrible results with the hardware echo canceler for pots lines. In fact, I have ripped it off and use 128 pings software canceling and get better results.
Finally, I strongly (very strongly) suggest you set your gains to 0 and run the fxotune utility against the lines. This will test your phone line echo, and its electronic makeup from the pop to you. It does take some time and you will need to run it once every other month. I have a cron job setup to do this. You will also need to have the fxo tune be added to your zaptel rc script so that the values are loaded into the zaptel drivers. After doing your first fxotune, then tweak your gains as needed. I normally never go over 4db TX and 8 db RX.
Side note on fxotune… there have been lots of bugs around this utility over the past year. Make sure you read all the docs and posts on voip-info.org about it. To make sure it is behaving properly, use a butset on your pair keeping it onhook and issue a test on one line. Make sure you hear the utility dial a digit (usually 5) before sending tones otherwise it will fight the dialtone and give you bogus characteristics.