I have several SPA3102s in my enviroment that I am using to connect legacy PSTN lines to the VoIP network. Calls come in on the PSTN lines and are routed to our Asterisk server by the gateways. The Asterisk server connects the calls to the correct IP phone extensions. When calls come in this way (or go out using the same line) the inside party hears an echo of themselves. During an individual call, quality fluctuates but the echo is present during every call. Calls between IP extensions have no echo. Calls connected to the PSTN network through a different gateway from the same IP extension have no echo.
So far I have upgraded all gateways to the current firmware and followed the troubleshooting steps outlined here; http://www.cisco.com/en/US/products/ps10024/products_qanda_item09186a0080a359cc.shtml
with no luck. Turning off the built in echo reducing features makes the calls consistent, with bad echo constant throughout all PSTN calls but none of the other steps reduce the echo as much as the built in features. I have searched the forums and not found anyone else have this problem with just the PSTN port. Does anyone have any ideas?
I have exactly the same problem with my PSTN line in belgium. The echo makes the conversation impossible.
I also try the resolution topics but without succes.
I read here (http://forum.voxilla.com/voip-wiki/impedence-setting-should-choose-my-spa3102-fxo-port-24391.html) that impedence of the FXO port could be the solution but the recommended empedence for belgium (150+830//72nF) is not vissible into the list with my SPA3102.
I use firmware 5.1.7(GW)
Thansk for help
Hey guys, have you tried the following to reduce echo on the SPA3102.
A. Experiencing echoes in the PSTN line is a common problem. This is because the SPA3102 passes calls from the PSTN to LINE1 by converting it to VoIP internally then converts it back to analog. This process does not produce any echo, however, it c...
- Make sure you are running the latest firmware. Everything should be set to factory defaults, or at least undo all the previous tweaking.
- Disable all the echo cancellation functions of your SPA3102. These settings can be found on line 1 and PSTN line tabs of your SPA3102.
- Remove devices connected to your phone line except the SPA3000. This includes all the extension cables and splitters. These can cause impedance problems which lead to echoes.
- Set the FXO port Impedance on the PSTN tab to 220+820||120nF, and set FXS Port Impedance to 220+820||115nF as a starting point.
- Look for Network Jitter Level on the PSTN Line tab and set it to low. Then, look for Jitter Buffer Adjustment and set it to disable. This reduces the delay across your SPA3000.
Note: If you are using a poor quality VoIP service, go to the Line 1 tab and look for Network Jitter Level. Set it to low and set the Jitter Buffer Adjustment from up to down. However, if you are using a poor quality PSTN, set the Network Jitter L...
- Go to the PSTN Line under Audio Configuration. Look for Preferred Codec and set it to your preferred settings, then lock it in by setting the Use Pref Codec Only to yes. Adjust these settings if you are accessing your PSTN line via VoIP from a re...
- Power cycle the SPA3000 by powering down the device. This sometimes fixes the problem especially after changing the physical phone wiring.
- Make some test calls and observe if you can hear an echo. If yes, the problem might be that you are sending too much power down the line and it gets reflected back somewhere as an echo. Even if you have good wiring but you are too close to the mou...
- Make a test call to someone with a phone that works via the SPA's PSTN line, or call in to the PSTN line. If the remote party is hearing an echo, your phone might be loud and is experiencing feedback in the microphone. Lower the PSTN to SPA Gain u...
- After lowering the echo to a tolerable level, go back to the PSTN tab and enable Echo Can Enable by selecting Yes, OK. Check if the echo has improved. If the echo is tolerable at this level, leave the adaptive echo canceller off. You should have t...
I try all the sugestion of this article.
The only thing i doubt is the impedance that could be different for belgium.
Thanks for help
Hello! I've the pproblem, that is discribed in this topic https://supportforums.cisco.com/message/3223798#3223798
I have an Asterisk PBX server.
I hear myself, when I try to use either softphone, or hardpfone. Spa-pstn, pstn-spa gains do nothing! The included echo cancel and adaptive could make the picture better!
I've already done everything, that documents suggest me to do!
The author of yhis topic didn't finaly talk, if he solve this issue... and the main idea "HOW?"
Waiting for the help,
I've found echo with the 3102 to be a real issue for a long time and appears it could be an Inherent issue with the SPA-3102.
It's all very well to try altering this setting and that settings but end of the day, the echo is still there!
My findings show that altering things like gain, impedance, volume levels, jitter buffers, leads etc. all seem to have an effect to some degree, yet you'll never get rid of the echo entirelly.
So I go thinking... I have a IP-PBX(gw) with FXS/FXO ports, and thought about testing this unit up against the 3102.
Simplly swapping the 3102 for the IP-PBX in the exact same environment, then making a call, there was absolutelly no echo, incomming or outgoing.
This included many hours of testing through voip and PSTN - absolutelly no echo!
I then swapped the 3102 back, made a PSTN call and echo stright away..
Conclusion - it's the 3102 unit itself, I dont think you'll ever get rid of the inherent echo problem, unless Cisco engineer the problem out...
I think I may have found the reason why echo is so prevalent in these units.
The IP-PBX I was testing has a 128ms 'echo tail', whereas the 3102 units ONLY has an 8ms 'echo tail'.
It would seem the 3102 is not capable of elliminating ALL echo due to this short tail length, i.e it's not absorbing the echo entirelly.
I'd like to hear from others out there who are using PSTN gateways, such as an IP-PBX I was testing and whether you experience echo from it, if not clarification on the echo tail length of the unit might shed some light on the 3102 echo issue?
Sure you are right! The SPA-3102 is a real makeshift device that should be re-engineered top to bottom. Echo cancelling is so tricky that nobody has solved it yet as far as I know. Going through trial and error tweaking on so many points (I have been trying all along April) may be a real maddening task. Giving up.
I have a Linksys spa3102 (with latest firmware v5.2.13) i use it (FXO port) with a freepbx distro asterisk voip ippbx and i had the same problem! Unfortunately the problem seems to be a bug of the echo cancellation at the PSTN Line tab. After a log log time of tests and calls I discovered that when i set the “Echo Canc Adapt Enable = Yes”, “Echo Canc Enable = Yes”, “Echo Supp Enable = Yes” and from Regional tab the “More Echo Suppression = Yes” make a call and then change the “Echo Canc Adapt Enable = No” i have no echo at all. But when i change something else and i press the “Submit All Changes” button the echo comes back again!!! I have to enable “Echo Canc Adapt Enable = Yes” make a call and then disable “Echo Canc Adapt Enable = No” to disappear the echo!!! very odd but works for me if i don't power of the ATA or change settings i can make calls without echo.......... please if anyone can confirm this (or not) would be great.
I am using an spa-8800 (4 FXO/4FXS but still in the spa family) and experienced the exact same thing that you reported.
I have countless hours into trying to solve the echo issue, tweaking parameters every possible way and discovered that IF I set the 'Echo Canc Adapt Enable' to No after the gateway has been powered up and taking calls, the echo completely goes away until the spa unit is power cycled, once it is powered back up the echo will resurface immediately, really bad if they are dialing DTMF digits from the FXS side out the PSTN side, the DTMF's will echo.
I can produce this 100% of the time and am actually having them connect the unit to a battery backup in an attempt to keep it powered up for as long as possible.
I have over 80 of these spa devices in the field and very worried, we need to get this on Cisco engineering's radar ASAP...
It look like a firmware bug. You can report it to SMB support. But don't put so much hope they will solve it either in reasonable time or at all.