<div><div>Echo is generally one of the least understood problems in telephony, especially to those who are relatively new into the field. It is so because there is no one cut and dried answer to why echo happens- there are 3 major causes, and countless condititions and caveats to make our lives interesting. Since a great many people in this list come from an IT, and not audio or telephony engineering, it's a very difficult subject to explain, as we all lack a common dictionary to work from. But for those of you who are still reading at this point, and are not first thinking that I just insulted you (I haven't, and if you feel that way, my apologies- it is not my intent), let me try to break down some of the misconceptions.
<br><br>First, never say never. Echo is simply the reflection of sound- the sound is turned into electrical signal at the first microphone in the equation- off a device, causing the sound wave to be reproduced back to the speaker, with a significant enough time delay so as to be noticed. That relfecting device could be physical- in an ampitheater, it could be a wall or ceiling dome- or it could be electronic, such as the beloved 2 wire/4wire circuit. Generally speaking, echo is an audio issue, and gets masked by bad electronics- if your room has an echo, using a poor quality microphone will get rid of it, simply because the microphone doesn't 'hear' the reflected sound.
<br><br>The phone company measured, and eliminated, echo from analog calls long enough ago most of us weren't even born. They handle it via a number of coping mechanisms- up to and including echo cancellers, which literally look to see if the same waveform is repeated within a certain interval on the line. Digium has added some of this functionality in the new hardware echo cancellers- and software echo cancellation has been around for a while to do the same sorts of things. But there's nothing new- the causes are still mostly analog audio issues. The phone company figured out that, when an electric signal is put on a wire, and it's sent over a distance to a receiving device, sometimes, that device will put voltage on the line in the other direction, an 'echo' of the signal it just received. By using special circuitry, they could reduce or eliminate this reflection. The phone company also discovered something else- if they killed *ALL* echo, no one liked it. We've all talked on a phone and said- are you still there? because we heard perfect silence back on the wire. They discovered they had to add a slight echo back in- commonly called 'sidetone'- so that the speaker heard themselves speak. For users to be happy, the sidetone has to be delivered just slightly delayed from the speech- a few miliseconds at most. Any longer, they complain of 'echo', shorter, and they complain of 'dead lines'. The human ear is one incredible device- the brain it's attached to, sometimes less so.
<br><br>In a perfect digital world, if the sources were all perfect digital sources (no microphones involved, you'd be using a box that directly digitized your thoughts before they became voice), we would never have echo. Ever. Digital circuits, by their definition, do not 'hear' the reflected analog signal- you accept packets in one direction or another, a 'reflected' packet is discarded. (oh- you couldn't use speakers, either, since they're analog- the circuit would have to implant your thourghs into the other party's brain directly).
<br><br>We all love to think of VoIP is a perfect digital solution- and it is, from the analog to digital conversion circuit (ADC) through to the digital to analog conversion circuit (DAC) on the other end. But, outside those two circuits, anything can happen- and sometimes, depending on the path the digital data takes, what conversions it goes through, and any attempts to 'mix' it, echo can be generated within the digital stream itself. In a perfect world, VoIP would never introduce echo on it's own- but I've seen it happen. Take the case of a bad router, or a hub, or bad ethernet cards- even wiring problems.. if your network decides to resend a packet because it thinks it wasn't receivved properly, and your software decides that that packet should be 'played', and not ignored- you have echo. I liken VoIP to the best, and most expensive, hi-fi monoral sound system ever invented- and those of you who remember 'hi-fi' sets will know exactly what I mean.
<br><br>So now we have our causes of echo: Good microphones picking up reflected audio signals from the rooms their placed in, network quality issues, and electronic or software circuit failure. Solutions? They depend upon the problem- but the real trick is identifying the problem itself. In many cases, the problem is made up of multiple small failures. I've seen cases where it's obvious- poor speakerphones in small rooms, or softphones used without headsets, and laptops where the microphone and the speaker were only inches apart. I've also seen cases where echo is triggered by combinations of sidetone, poor analog to digital circuitry, and slow networks, where echo comes and goes by the call, by the minute, or by the user. I've seen cases where a user has their headset turned up so loud in their ear that the boom microphone picks up the earpiece. And, I've seen combination cases of all of them.
<br><br>So how do I approach echo? First, never say never. Just because the echo doesn't happen all the time, or because the signal path is 99% digital, doesn't mean the echo isn't real, or isn't being generated in the digital world. Just because one end hears it and the other doesn't doesn't mean it's not being generated at the end that's hearing it, or that it's not being generated at the remote end. Second, start with the analog audio. Adjust your microphones first- replace poor speakerphones, train users on how to use softphones, change out speakerphones in small rooms, and turn down your speakers or pass out headphones. Then, move to your gains- did you adjust the gains at all when you installed your PSTN circuit? Did you need to, and didn't? Has your wiring changed, requiring you to revisit it? Finally, examine your digital path closely. You want to keep your end-to-end (that's DAC to ADC end to end, not just server to server or client to server) network as smooth and as efficient as possible- the lower the latency of voice packets, the better your result will be. My rules are simple- if my end to end latency is above 100ms, I start worrying about the network path- at 200ms, the users will be complaining, and it doesn't take much of a network event to move the latency from 100ms to 200ms. QOS, even on the LAN, can make a big difference- but, as other posters here have said, it's not automatic, as it adds complexity. Simple ping tests can tell you a lot- detailed network analysis can tell you more. WAN links deserve extra scrutiny- be they cable modems, DSL lines, or OC48 fiber runs. Also, examine your servers closely- if your Asterisk box is chugging along at 90% utilized, chances are good it can't respond to all the packets in time.
<br><br>For those of you who aren't asleep, thanks. If you want to add to this, please do- perhaps at the end, I'll add it as an essay to the wiki.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Date: Fri, 03 Mar 2006 13:42:22 -0600<br>From: Michael Sampson <<a href="mailto:msampson@yourccsteam.com">msampson@yourccsteam.com</a>><br>Subject: Re: [Asterisk-Users] Echo Cancelation on TE110P<br>To: Asterisk Users Mailing List - Non-Commercial Discussion
<br> <<a href="mailto:asterisk-users@lists.digium.com">asterisk-users@lists.digium.com</a>><br>Message-ID: <<a href="mailto:44089C1E.2030700@yourccsteam.com">44089C1E.2030700@yourccsteam.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"
<br><br>It is my understanding that when you hear echo the problem is on the<br>other end. So if a caller complains they hear echo that is something you<br>should be dealing with, but if you hear echo that is the phone companies
<br>fault. Now with a normal phone, the phone company will only echo cancel<br>long distance calls. For local calls the latency is not high enough to<br>matter. But with VOIP the added latency creates echo even for local<br>
calls. I think the reason you hear it on some numbers and not others is<br>that the phone companies are doing echo cancel on some of those calls<br>and not on others.<br><br>Michael Sampson<br>Information Systems Manager
<br>Customer Contact Services<br><a href="mailto:msampson@yourccsteam.com">msampson@yourccsteam.com</a><br>952-936-4000<br><br><br><br>Kerry Garrison wrote:<br><br>> On a 55 station install onto a Cox PRI with a TE110P (Polycom 501
<br>> phones) a few users are complaiining about echo. According to the<br>> users, the echo seems to be phone number dependant. They claim that<br>> certain phone numbers have echo while others dont. Are there any
<br>> tuning parametes like there is for a TDM400 card?<br>><br>> Kerry Garrison<br>> Director of Technical Services<br>> **Tech Data Pros - Orange County's Mobile IT Service Provider<br>> **(949) 502-7819 x200 - //kerryg@
<a href="http://techdatapros.com//">techdatapros.com//</a><br>> <mailto:<a href="mailto:kerryg@techdatapros.com">kerryg@techdatapros.com</a>><br>> //http://www.techdatapros.com// <<a href="http://www.techdatapros.com/">
http://www.techdatapros.com/</a>><br>><br>><br>>------------------------------------------------------------------------<br>><br>>_______________________________________________<br>>--Bandwidth and Colocation provided by
<a href="http://Easynews.com">Easynews.com</a> --<br></blockquote></div><br>