[asterisk-users] SIP / Echo Cancellation

[Steve Underwood]

On 03/05/2010 02:45 PM, Vineet Bhojnagarwala wrote:
> Very informative post Vinícius !
>
> 2010/3/5 Vinícius Fontes <vinicius at canall.com.br 
> <mailto:vinicius at canall.com.br>>
>
>     ----- "Chandrakant Solanki" <solanki.chandrakant at gmail.com
>     <mailto:solanki.chandrakant at gmail.com>> escreveu:
>
>     > Hello
>     >
>     > I have successfully compiled OSLEC for echo cancellation for DAHDI
>     > channel.
>     >
>     > Is there any way to do echo cancellation for SIP Channel.
>     >
>     > Is any, please suggest me.??
>     >
>     > Thanks in advance..
>     >
>     > --
>     > Regards,
>     >
>     > Chandrakant Solanki
>
>     Short answer: Maybe. Depends on the SIP device you're using.
>
>     Long answer:
>     *takes a deep breath*
>
>     First you gotta understand why echo occurs. Every single call
>     you've ever made on your life has echo. You can hear yourself when
>     you're speaking. If that was not the case, it would feel like
>     talking on a push-to-talk system. So echo is a natural and even
>     desirable phenomenom. What makes echo unconfortable is when the
>     echo is *delayed* too much.
>
>     There's a number of causes for this to happen. First and foremost,
>     sometimes a part of the signal you're transmitting is reflected
>     back to you. That usually happens on the analog part of the system
>     (analog phones as a whole, the handset of an IP phone, the headset
>     connected to your computer's sound card, etc). When we're talking
>     about VoIP, the latencies involved are much higher than a
>     completely TDM system. There's the encoding latency, easily
>     understood as the time the device takes to convert the analog
>     signal (your voice) in RTP packets, then there's the transmission
>     latency, inherent to any network, and so on. All those latencies
>     add up to each other, making the total latency go skyhigh and
>     making you hear your own voice delayed by some milisseconds - the
>     infamous echo.
>
>     Asterisk cannot cancel echo when the call is entirely IP, from an
>     IP phone to another, for example. There's simply no need for that.
>     That's because it's the device's job to cancel the echo caused by
>     its own TX reflections or analog/digital conversions. On the other
>     hand, Asterisk can and will cancel echo if you have a hardware
>     echo canceller or a software based one, like OSLEC -- which is by
>     far the best software echo canceller I've ever seen.
>
>     Finally, in order to solve your problem, you'll need to check a
>     few things. If the call is entirely VoIP, from one end to other,
>     then the IP phones, ATAs, gateways, softphones, whatever, are the
>     sole responsibles on cancelling the echo. You'll need to turn on
>     echo cancelling on this devices or tweak its parameters. Also,
>     don't forget that latency makes echo much worse. If you control
>     the entire network between the two phones, you MUST set up a QoS
>     policy in order to minimize the latency as much as possible. I've
>     solved many echo problems by just implementing end-to-end QoS on
>     the network.
>
>     Lastly (I swear I'm finishing this essay right here :), if that's
>     not your case and you're having echo issues calling from a SIP
>     phone to an external number, double check if OSLEC is indeed set
>     as the echo canceller on /etc/dahdi/system.conf and enabled with
>     echocancel=yes on your chan_dahdi.conf. You can always check if
>     the echo canceller is active on a certain DAHDI channel by issuing
>     the command "dahdi show channel XX" on Asterisk CLI, where XX of
>     course is the said DAHDI channel.
>
That covers the nature of the echo problem well, but it doesn't actually 
explain why 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, 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