Awful echo problem - came up suddenly

[phinphan]

I have experienced terrible echo on my two zap lines. This came up this weekend and is probably related to something I did while futzing around with my fxs ports. I have tried to put everything back together without success. The computer is the Everex gPC. Here is my system:

PBX in a Flash Version 1.3 Daemon Status
* Running Asterisk Version : Asterisk 1.4.21.2
* Asterisk Source Version : 1.4.21.2
* Zaptel Source Version : 1.4.12.1
* Libpri Source Version : 1.4.8
* Addons Source Version : 1.4.7

CentOS release 5.2 (Final) :32 Bit Kernel: 2.6.18-92.1.22.el5

I have a Digium TDM400 series board with 2 fxo and 2 fxs. I have two brother fax machines hooked up to the 2 fxs ports. The 2 fxo are hooked up to AT&T landlines. Sip Phones in the office are all GXP2000's which we have had for about 2 years and work fine. No recent firmware upgrades to the phone and the echo is on all phones on both land lines and is absent on all calls placed through vitelity or les.net.

When I was working on my fax lines, I adjusted the echo settings on the fxs ports without editing zapata.conf. Zapata.conf is exactly the way it was before. I ran fxotune and here is its output:
3=9,254,251,255,2,0,1,0,0
4=5,3,251,251,2,253,255,255,255

I tried using ztmonitor and followed the steps on the page tshif linked in his post in the hylafax thread. However, I came across a real oddity in that I needed something like 22.5 rxgain/txgain and that seems odd. The former settings were 2.0/2.0 and worked just fine. The massive adjustments to gain did nothing to fix the echo.

Out of desparation/stupidity last night I installed oslec without success.

I have run update-scripts and update-fixes.

Since zap is so bad, I forwarded my incoming landlines to my backup voip lines so I can run my business but this is weird. Unless someone has a great idea I think I will reinstall the system and rebuild everything from scratch. Anyone have any ideas that will save me the trouble of reinstalling and more importantly, help me understand what I did so that I won't do it again.

Update:

ran cat /proc/interrupts and got this:
root@pbx:/etc $ cat /proc/interrupts
CPU0
0: 61496567 IO-APIC-edge timer
1: 9 IO-APIC-edge i8042
6: 2 IO-APIC-edge floppy
7: 0 IO-APIC-edge parport0
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 115 IO-APIC-edge i8042
14: 550296 IO-APIC-edge ide0
169: 65339 IO-APIC-level sata_via
177: 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, uhci_hcd:usb5
185: 62918465 IO-APIC-level wctdm, eth0
193: 0 IO-APIC-level VIA8237
NMI: 0
LOC: 61505983
ERR: 0
MIS: 0

Looks like my ethernet card and my tdm card are sharing an interrupt. I will see about fixing that later today. Although this setup has been running fine for weeks.

Zaptel Tool (C)2002 Linux Support Services, Inc.

zttool shows:
â
âââââââââââââââââââââ⤠Zapata Telephony Interfaces âââââââââââââââââââââââ
â â
â Alarms Span â
â OK Wildcard TDM400P REV I Board 1 â â
â â® â
â â â
â â â
â â â
â â â
â â â
â â â
â â® â
â â â
â â
â â
â ââââââââââ ââââââââ â
â â Select â â Quit â â
â ââââââââââ ââââââââ â
â â
ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ

and
Zaptel Tool (C)2002 Linux Support Services, Inc.
ââââââââââââââ⤠Wildcard TDM400P REV I Board 1 âââââââââââââââ
âââââââ â ââââââ
â â â â
â â Current Alarms: No alarms. â â
â â Sync Source: Internally clocked â â â
â â IRQ Misses: 0 â â® â
â â Bipolar Viol: 0 â â â
â â Tx/Rx Levels: 0/ 0 â â â
â â Total/Conf/Act: 4/ 4/ 2 â â â
â â ââââââââ â â â
â â 1234 â Back â â â â
â â TxA ---- ââââââââ â â â
â â TxB ---- â â® â
â â TxC ---- â â â
â â TxD ---- â â
â â ââââââââ â â
â â RxA ---- â Loop â â â
â â RxB ---- ââââââââ â â
â â RxC ---- â â
â â RxD ---- â â
âââââââ â âââââ
ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
Wildcard TDM400P REV I Board 1 F10=Back

zttest shows:

--- Results after 111 passes ---
Best: 99.998 -- Worst: 93.550 -- Average: 99.919649, Difference: 99.937201

that was with one incoming phone call on a zap line while I ran the test.

 

[phinphan]

I adjusted all the irq conflicts and now the tdm board has its own interrupt. That did not solve the problem. Next I adjusted the txgain to -15.0 and that solved the problem. What I can't figure out is how it changed from +2.0 to -15.0 in a weekend. I am not a telephone engineer but could some device on the tdm card be causing too much transmit power?

The next step will be to remove the fax machines from the system and see what effect that has.

 

[jehowe]

That is weird. I would also wonder if AT&T did something on their end. Even though you solved it, you may want to zero the txgain and run fxotune to see if it helps.

http://kb.digium.com/entry/2/134/

 

[phinphan]

thanks for the suggestion. I will give it another try and see what happens.

 

[phinphan]

Problem Fixed but not Solved

Well I keep answering my own questions, but it might help someone else. I removed my tdm card and placed it in my old server with a fresh install of PBXiaF 1.3. A quick genzaptelconf/fxotune and then I created a trunk and an extension. Zap calls worked fine. No echo at all. I was satisfied that I did not have a tdm card issue. I reinstalled the card in my new server and did a config restore from 6 weeks ago and was able to make calls without echo. All echo settings are the same as the config files that did not work. I don't understand why the problem is solved but there must be some setting somewhere that I missed.

I will do a clean install of the system this weekend and manually recreate the trunks/extensions and other parts of the system and see what happens.

One additional fact that I didn't think about before was that my system started as a Trixbox 1.1 system before I went to PBXiaF. Perhaps there is a some conflict in settings from the old TB config files and the PBXiaF files. I don't know.

The moral of the story is have good backups and don't play with your system.

Thanks to all who helped, especially Tony (TSHIF) who offered to log in and take a look and everyone else for their posts on related issues.