What Causes VoIP Echo?
- Historic Design of 2-wire Analog Telephones
- Desirable Echo: Sidetone
- Undesirable Echo: Remote Echo
- Echo Cancellation
Echo should be reserved for canyons and tunnels, not phone calls. Echo can be caused by a number of different elements in a phone system but before we dig into the specifics, a bit of background is needed.
Historic Design of 2-wire Analog Telephones
Back when phones were originally developed with 2-wire analog technology, echo was an anomaly of the design, as all microphones would have their input played back on all speakers throughout the system. This allowed for multiple phones to be connected to a single circuit and everyone could hear every one else on the line.
This design resulted in desirable and undesirable characteristics.
Desirable Echo: Sidetone
Sidetone (1) provides feedback to a speaker as to how they were being heard by the receiver. This feedback, from the local microphone to the local speaker, would instantly reveal how loudly or softly you are speaking into the phone.
|Interesting Fact: The lack of side-tone in cell phones is why people end up yelling into their phones when they have problems hearing the other party – they might be heard just fine by the other side but they think the other person can’t hear them because they can’t hear the other person. If cell phones provided sidetone, nobody would ever yell into a cell phone.|
Undesirable Echo: Remote Echo
The 2-wire analog design (2) has an undesirable effect when the speaker’s voice makes a complete round trip to the remote end and back. If the call is local (cross-town), the latency/delay might be 1-2ms. This delay would be imperceptible from the sidetone so no echo would be detected.
If the call is long-distance (bouncing off a satellite), the latency/delay might be 200ms or more. Having your voice delayed by that amount would immediately be noticeable as an echo.
When VoIP was introduced, additional latency was created due to intermediary routers and switches processing packetized data, and non-direct routing. To deal with this additional latency, Acoustic Echo Suppression (AES) circuitry was created. VoIP phones and gateways employ Digital Signal Processors (DSPs: 3) to do the echo cancellation (4).
The echo cancellation mechanism attempts to match an inbound voice signal with an offset inbound voice stream that might be delayed by either a few milliseconds or a few hundred milliseconds. In addition, voice signals are attempted to be matched with different amplitudes to cancel quieter echoes, since most echoes lose some amplitude along the path.
The hard part is doing this matching on the fly for different latency offsets and with different amplitudes as it requires a lot of horsepower. As a result, there is only so much that a DSP can accomplish. If latency is too high, or the DSP is older and does not have the memory or CPU to accommodate searching all amplitude levels, echo may be passed through to the receiver.
Solving Echo Problems
Sometimes echo can be eliminated by hanging up and re-establishing the call. The newly-established call may have lower latency with more optimal routing through the network, or use a different lower-latency codec, thus allowing the DSPs to work within their normal operating capability.
Echo can be caused by older VoIP phones and ATAs that have more limited DSPs when making longer distance calls. If newer VoIP phones are employed in the call, and less analog to digital transitions are employed, latency should be reduced and echo cancellation should work better.
On conference calls, if everything is going smoothly until one last user joins the call and echo is heard, it may be that the last user who was added has older or inefficient echo cancellation capabilities, or the last user is on a high-latency line and some other user has insufficient echo cancellation capabilities. To address the problem, the last user should be muted, or disconnected from the conference.
In general, latency is the biggest cause of echo but if it can be reduced, the DSPs should be able to fix the problem. To reduce latency, try the following:
- Optimize routes and call paths for RTP packets.
- Remove intermediary devices that may slow packet flow like firewalls or older routers.
- Ensure that QoS is properly configured on congested LAN and WAN links
- Choose low-latency codecs that use smaller packet sizes
PathSolutions TotalView includes a number of features that can help identify and reduce latency in a network environment.
Click here to view a PDF version of this Fact Sheet.
Interested in learning more?