On 03/05/2010 02:45 PM, Vineet Bhojnagarwala wrote: > Very informative post Vinícius ! > > 2010/3/5 Vinícius Fontes <[email protected] > <mailto:[email protected]>> > > ----- "Chandrakant Solanki" <[email protected] > <mailto:[email protected]>> 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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
