[asterisk-users] SIP / Echo Cancellation

[Vinícius Fontes]

----- "Steve Underwood" <steveu at coppice.org> escreveu:

> 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

Steve you should definitely write a book with a title like "The Guts of Telephony: everything you wanted to know but was afraid to ask". I would be the first one to buy!