In a previous tip I explained that the first thing to understand about echo is that if you hear it, the problem is on the far end. Much like shouting in a canyon, your voice bounces off various points in the path and returns to you. If the canyon wall is close, the sound returns fast enough that your brain ignores it. Similarly, devices a few milliseconds away (e.g. local routers and gateways) may be echoing your voice back to you, but you won't hear it.
So for example, let's say your company has a typical toll-bypass VOIP circuit that connects via a gateway to a local and remote PBX, and you hear an echo. What should you do? Many probably realize the typical answer is "configure an echo canceller" and your local and remote voice gateways probably have that feature, but which one would you change?
The trick to understanding this is to realize that most "echo cancellers" are unidirectional. That is, they face a particular direction, known as an "analog tail circuit". The reason for this is that the digital side of the circuit (i.e. the VoIP part) isn't really susceptible to echo. That is, routers and switches just pass packets; they can't generate voice echo (unless they also have voice interfaces). Thus, the cancellation only affects sound passing from the analog tail circuit to the digital circuit.
As you may have noticed, in your vendor's equipment, the commands to configure the echo cancellers are usually applied to a specific interface,
Requires Free Membership to View
SearchUnifiedCommunications.com members gain immediate and unlimited access breaking industry news, expert advice on UC, technical guides, and more -- all at no cost. Join me on SearchUnifiedCommunications.com today!
Kate Gerwig, Editorial Director
and not the entire box. So in the above scenario, when you hear echo locally, the interface you need to tweak is the analog interface on the remote gateway.
You may have also noticed that many vendors' echo-canceller settings have a maximum setting of 32 ms or so, while the ITU recommended maximum end-to-end delay is 150 ms. Obviously, 32 ms of echo coverage can't fix delay between 33 and 150 ms, but the above explanation should help you understand why that's not a problem.
The echo canceller doesn't know or care about the VOIP side. The delay from one end of the tail circuit to the other and back is generally only a few milliseconds. So if the source of echo is at the farthest point from the gateway, e.g. a cheap conference phone, the time it takes for your voice to go from the VOIP gateway through the remote PBX, to the conference phone (where the echo begins) and back should be quite small.
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.
This was first published in November 2003