Asterisk echo cancellation

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.

Too much of a good thing

Make sure only one unit in the chain is doing echo cancellation. For example, a Linksys PAP2T comes configured by default to do its own echo cancellation. If you use one of these to connect a handset to an Asterisk server whicn in turn is configured to do its own echo cancellation on outgoing analog or ISDN lines via zapata.conf or chan_dahdi.conf, then the two echo-cancellation systems will step on each other's toes, with effects like speech cutting in and out in both directions, or even worse echo. I recommend you make sure echo cancellation is turned off in your SIP client hardware/software, and turned on only in Asterisk.

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.


  • 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.

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, 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.


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 :)

Echo and VoIP

Echo cancellation over IP is almost always a failure. Echo cancellation
is an adaptive process. It continually tunes a model of the
system which is echoing. If that modelling is to have any chance of
success, the system it is modelling must be stable and linear.

The key stability issue with a VoIP channel is jitter buffering. Any
jitter buffer in the path between you and the place causing the echo is
likely to adjust the timing in a dynamic way. This means the echo timing
will dynamically change. Every time it changes the echo canceller
training is going to blow up. Not just go a little off tune, but really
blow up. If your echo canceller isn't good at catching this kind of
thing you might well get howling. You have little or no control over
these jitter buffers. You might have control over your local link, but
links further downstream are very rarely under your control. The other
stability issue related to packet loss. When something is used to fill
in for a lost packet it will not carry the normal echo signal. When the
echo canceller removes the predicted echo a nasty noise will usually
result - i.e. packet loss, however well concealed by clever PLC
algorithms (see: codec ilbc), will result in awful noises.

The key linearity issue is lossy compressing codecs. The PSTN uses lossy
compression - A-law or u-law - but the lossiness there is not severe.
Still, its enough to cause trouble with echo cancellers. Look at the
spec for a line echo canceller and you'll see terms like NLP (non-lnear
processing) and CNG (comfort noise generation). These are fudges used to
tolerate the lossiness of A-law and u-law. If the codec compresses any
more lossily there is no chance an echo canceller will work. You might
be able to control your local link, and ensure it always uses A-law or
u-law, but you have no control over what happens downstream.

Now, some will point out that it is perfectly normal to encounter
similar conditions in normal PSTN use - calling a cell phone can give
you some funky delays and a low bit rate codec. If you look at the
design of any cellular network you will find echo cancellation is
strictly applied, to ensure the characteristics of the cellular network
do not mess up the PSTN itself. The same has to happen when the PSTN
meets VoIP.

Some people are puzzled how well an echo canceller like OSLEC works, as
it only cancels up to 32ms. Most line echo cancellers for use in the
PSTN cancel up to 128ms or more. The reason 32ms works so well is
Asterisk boxes are seldom *in* the PSTN network. They sit on the
periphery, like any consumer phone line. When you call across town
between PSTN phones you get maybe 10 or 20ms of echo. This is perceived
as reverberation, and you aren't troubled by it. The network has no
reason to cancel that echo for you, and they don't. When you call
another country you might get a 100ms of echo delay, and it could sound
horrible. Therefore, the network applies echo cancellation for you. So,
your VoIP box on a consumer phone line needs to cancel short echoes from
local calls, but the network will deal with long echoes on your behalf.
Its only when you have lines where you are treated like a telco (e.g.
SS7 links) that you are presented with long echoes.

Steve Underwood

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

Asterisk | Tips & Tricks | FAQ
Created by: oej, Last modification: Wed 18 of Oct, 2017 (16:18) by admin
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+