[Asterisk-Users] Re: Incoming echo cancel

[Kris Boutilier]

> -----Original Message-----
> From: Eric Wieling [mailto:eric at fnords.org]
> Sent: Friday, March 11, 2005 1:52 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [Asterisk-Users] Re: Incoming echo cancel
> 
> 
> Nenad Radosavljevic wrote:
> 
{clip}
> > 
> > Anyone have an idea, why this type of echo happens ? As far as I have 
> > read on the lists this type of echo should not occur at all, but it 
> > simply does !
> 
> I consider all this MMX stuff to be voodoo for echo problems.
> 
> If you have a PRI and SIP phones then the echo occurs on the far end 
> analog phone.
> 
{clip}

I concur. The echo cancellation code is syncronised to the stream of samples going to/from the T1 card so if it takes longer to process then it simply takes longer to deliver the audio, much like the transcoding times of GSM vs Speex (2ms vs ~30ms). I can only think of a few possible reasons the echo cancellation code may not work as expected:

 - A echo signal too complex for the style of filter
 - Continuous variations in the 'length' of the echo tail on the _incoming_side_ of the T1 causing the filters to continuously adapt (perhaps caused by 'slips' in the interface/timing system onboard the card?)
 - Coding errors in the MMX vs. non-MMX routines
 - Fundemental differences between the audio signals being passed to the customers depending on the service providers facilities (eg. variations in level padding: http://yarchive.net/phone/digital_pads.html)

Of all of these, I remain convinced that in most cases the real issue is something like the last. Namely that subtle differences between facilities are interfering with the assumptions the mathmatics in mec2 use - it's a very rigid model and makes use a number of fixed assumptions about average signal levels, offsets and so on.

Kris Boutilier
Information Systems Coordinator
Sunshine Coast Regional District