----- "Steve Underwood" <[email protected]> escreveu: > 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
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! -- _____________________________________________________________________ -- 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
