Echo cancellation in Asterisk

Before you proceed down this path, make sure you have read the notes in Causes of Echo on tracing, and attempting to eliminate, the source of any echo. It should be possible to eliminate any residual echo with the zaptel echo canceller, but it won't be able to cope with line faults; and in any case, you'll get better results if you do all you can to eliminate echo at source.

How does echo cancellation work?

Almost all (if not all) echo cancelling algorithms operate by generating multiple copies of the received signal, each delayed by some small time increment In digital terms, this is the equivalent of a shift register and each delayed signal appears at its own unique "tap". The number of taps determines the size of the echo delay that can be cancelled. These delayed copies are then scaled (or weighted) and subtracted from the original received signal. The trick is scaling the the delayed signals to exactly the extent needed to remove the echo and nothing else. The methods used in determining the tap weights (scaling factors) is what distinguishes one algorithm from another.

Don't trust your ears...

The echo canceller must "train" itself by computing the weights when it first sees a signal at the input. The training time depends upon the algorithm used and the number of taps. For optimal training, the number of taps should be as small as possible, while still adequately cancelling the echo. For the typical scenario being experienced by most of us, the signal delay should be relatively short. Don't let your ears be the guide here! The echo you hear has a lot of additional delay added between the location of the echo canceller and your phone. The real delay you are interested in is the delay from the echo canceller, out through the Digium card, through the network to the source of the echo (see Causes of Echo), and back again, to the echo canceller. This delay is relatively short, probably less than 20-30 ms. Simplistically, you'd need a "tail circuit" (the distance between your echo canceller and the source of the echo) of over 2500 miles to acheive an echo path of 30ms (though the digium card and driver probably add a few ms of latency in each direction, so that may be an exaggeration).

Each tap represents 1 sample, so at 8kHz (which is what all of Asterisk's echo cancellers assume), each tap represents 0.125ms. Asterisk's default of 128taps will therefore handle echo paths of up to 16ms, and is therefore probably good for most things.

The take home, however, is that you may get better performance with fewer taps because the training time is shorter and the canceller will adapt faster. Conversely, if you're having problems with echo on long-distance phone calls, you may need to up this to 256 taps.

Beware that Asterisk only lets you set 32, 64, 128 or 256 taps (this is because the algorithms assume the number of taps will be a power of two). Attempting to use a different number of taps will cause Asterisk to fall back to 128 taps without warning.

Algorithmic echo cancellers will never give performance equal to that obtained by balancing the hybrid. This is due to several reasons, not the least of which is that the expansion/compaction must be undone before cancellation, introducing noise and decreasing accuracy of cancellation, and that the delay characteristics and amplitude characteristics of the echo are never as well defined as they are at the point of origin of the echo (the hybrid). This is really too bad, since we don't get to do anything about the hybrid imbalance.

You should also note that you'll only be able to successfully cancel echo if your echo canceller is on the same side of any VoIP links as the source of the echo - the latency introduced by a VoIP system will be too great for any normal echo canceller to cope with.

Also (and this may be obvious!) your echo canceller needs to be pointing in the right direction! Asterisk's echo cancellers will cancel echo arriving from the PSTN via a digium card, before sending the signal up to Asterisk itself. It will not cancel echo arriving over a VoIP channel (which should have been dealt with at the other end, for the reason noted above).

Gain configuration

Before an echo canceller can work, you need to make sure that the levels of the signals it receives are about right. See Asterisk zapata gain adjustment for how to do this.

Terminology

• Near-end signal - the received signal, to which we need to apply echo cancellation. Note that, (somewhat confusingly) in the context of an Asterisk setup, this will typically be physically further away than the far-end signal - however, in terms of signal latency, the near-end signal (coming from the PSTN) is "closer" than the far-end signal (coming via a VoIP link).

• Reference signal - the signal we're about to transmit over the PSTN - that is to say, the far-end signal.

• Tail circuit - the potential distance between the echo canceller and the source of any echo.

• Doubletalk - the problem the echocanceller encounters when someone at the near end (them) is talking at the same time as the speaker at the far end (you).

Echo cancellation in Asterisk

The first thing to check if you experience echo cancellation with analogue (eg TDM400) cards is that the PSTN loadzone is set correctly. For instance if running in (default) FCC mode, and you are connected to a UK PSTN line, then you *will* observe harsh echo. You will need to change to using UK mode (see TDM400P) in this instance.

The zaptel drivers provide five echo cancellers (seven in zaptel 1.2)--you can configure which is used in zconfig.h. Unfortunately, there's not much documentation available on how to choose between them, or even how to configure them. I'm going to collect the information I've managed to glean on them on the pages below - however, I'm really not an expert in this field, and it really would be nice if the original authors gave some better documentation ;). Proper selection of an echo canceller is dependent upon knowing the algorithm. You need to know what the training performance, tail length, weighting mechanism, etc. If they were identified, at least one could consult the literature for information about the conditions for which the algorithm is ideal: is it best for room echo associated with speaker phones, is it best for cancelling echo from hybrid imbalance, etc.

• Asterisk mark echo canceller (mec)
• Asterisk mark2 echo canceller (mec2)
• Asterisk mark3 echo canceller (mec3)
• Asterisk steve echo canceller (sec)
• Asterisk steve2 echo canceller (sec2)
• Asterisk kb1 echo canceller (kb1ec)
• Asterisk mg2 echo canceller (mg2ec)

zaptel 1.0.x offers only the first five of the algorithms listed above. The default echo canceller used by later versions of 1.0.x (eg, 1.0.9.2) is mark2. The default echo canceller used by zaptel 1.2 (up to 1.2.5, at least) is kb1. None of these algorithms has changed since zaptel version 1.2.1(?) 2005-11-30.

fxotune

The FXO module typically has quite a few tunable parameters that affect the electronical characteristics of the device. When tuned right, the device will generate less echo. Those parameters also tend to be quite country-dependent, and hence the first approximation would be to set opermode. See below.

This will work with basically all analog FXO cards (with recent drivers), except the X100P, whose hardware does not have such tuning (anybody tried it with Sangoma A200 cards?)

Basically fxotune pretunes the FXO Module on a TDM400 to deal with the line quality reducing convergence and decreasing the ammount of echo generated in the first place. Hence the echo canceller will have much less echo to cancel later on.

See the Asterisk fxotune page for more info :)

Fax-tone detection

The zaptel drivers provide code which listens for a fax tone (a 2100Hz monotone), and automatically disable the echo cancellers if such a tone is heard in either direction.

This functionality can't be switched off at runtime (though it can be disabled at compile time by setting NO_ECHOCAN_DISABLE)

Stephen R. Besch, November 2003
Updates (with apologies) — Richard van der Hoff, July 2005

See Also

• SoftEcho (commercial) is an Echo Cancellation (EC) software plug-in for Asterisk up to 16 channels, ensuring excellent sound quality in all audio environments, even those with disruptive background noise. Softecho mISDN compilation
• SoliCall (commercial) which offers the PBXMate for high performance Echo Cancellation & Noise Reduction for any IP PBX. In addition the PBXMate monitors the QoS in the network.
• OSLEC is a free high quality echo canceller. It works well on lines where the built-in Zaptel echo canceller fails. No tweaks like rxgain/txgain or fxotrain are required. Oslec is supplied as GPL licensed C source code and is free as in speech.
• Echo Analysis for Voice over IP - a Cisco white paper discussing various aspects of echo in detail
• Causes of Echo
• Asterisk Echo Avoidance
• Asterisk Echo Cancellation: FXO and FXS lines
• Echo Cancellation on the Wildcard X100P
• Zap Channel Module Configuration: Audio Quality Tuning Options
• Digital Voice Echo Canceller with a TMS32020 - a TI Application note describing the implementation of an echo canceller, as well as many of the issues causing echo.
• Introduction to digital filters with audio applications
• Tellabs Hardware Echo Cancellers
• Linux Journal on VoIP and Echo
• Network Echo Cancellers: Requirements, Applications and Solutions, Motorola Inc.
• OctWare Offers Echo Cancellation for Asterisk IP PBX - article about "SoftEcho", claimed to work better than other solutions, sells for $10 per channel.
• On board echo cancellation on all Rhino Equipment analog cards

---

Asterisk | Tips & Tricks | FAQ