[Freeswitch-users] echo cancellation on PRI cards

[Steve Underwood]

OK, one last go and I give up.

Lets look at the documentation for Dialogic springware. This is the DSP 
package that loads in their cards or runs on the host in HMP 
applications. It does things like DTMF generation and detection for all 
Dialogic cards except the DM3 series. The documentation says:

*PerfectDigit DTMF Signaling*

• DSP-based DTMF (touchtone) detection algorithm optimized for lowest 
talk-off and play-off susceptibility in the industry. The system will 
not easily be fooled by mistaking human speech for DTMF tones.

• Minimum tone duration and interdigit delay times accurately handle 
speed dialing typical of "power users"

• Utilizes echo cancellation which results in superior cut through for 
accurate DTMF tone interpretation during voice file playback within a 
broad range of network/switch environments

• DTMF outbound dialing generated by DSP for accuracy and flexibility 
(dialing levels are adjustable to meet a variety of global PTT requirements)


Detecting supervisory tones on phone lines is trivial. Not falsely 
detecting them is where things get interesting. The standard test for 
DTMF receivers is a set of cassette tapes from Bellcore containing about 
3 hours of snippets from real telephone calls in North America. Most 
DTMF receiver chips get a few hundred false DTMF hits in those 3 hours. 
Dialogic get 20 something. My DTMF receiver gets 19. The reason its hard 
to detect these things reliably is voice doesn't sit there nicely at one 
level. Its level and its spectrum bounce all over the place, and a real 
DTMF digit is only there for 40ms or so. I defy anyone to visually 
identify a 40ms DTMF digit amongst real dynamic speech if it isn't *way* 
above the voice in amplitude. This is why your phone has to mute your 
voice when you press a digit. The DTMF receiver has no chance of 
reliable detection with speech and digits mixed. In the few special 
cases where concurrent speech and signaling tone are present on the PSTN 
(e.g. 2280Hz signaling in .eu and 2600Hz in .us) the signaling sequence 
is very carefully constructed to avoid confusing the system. DTMF is 
never used in that way.

There is one obvious special case where all DTMF receivers need to 
tolerate spillback. They need to differentiate between dialing tone and 
DTMF on the first digit you dial. They do this very simply. Dialing tone 
was chosen to be pretty low frequencies - 350Hz + 440Hz, 425Hz + 475Hz 
and similar pairings. The lowest DTMF tone is well above this. An 
aggressive low pass filter in the DTMF receiver removes the dial tone 
spillback, while barely affecting the lowest DTMF tone. This was the 
original design of DTMF, but......

IVRs changed all that. Their DTMF receivers are expected to work amidst 
outgoing prompts, which may be going to phones with an awful match to 
the line. The spillback can be huge. The good IVR hardware suppliers, 
like Dialogic, very quickly added echo cancellation to their cards. I 
can say a lot of negative things about Dialogic, but one thing they did 
really well was their DTMF cut-through. When people get used to an IVR 
they expect to hammer in digit sequences as fast as they can, in the 
face of a machine desperately trying to play voice prompts to them. 
Dialogic cards do this really well, on lines of all types, and on 
networks of varying quality. This would be impossible without echo 
cancellation.

David Knell wrote:
> Steve Underwood wrote:
>> David Knell wrote:
>>   
>>> Steve Underwood wrote:
>>>     
>>>> [whopping big snip]
>>>>   
>>>>       
>>>>> The first bit of that's a tad patronising, isn't it,
>>>>>     
>>>>>         
>>>> You are the one who started out being offensive.
>>>>   
>>>>       
>>> I'm sorry if you find disagreement offensive; you might not wish to 
>>> read beyond this
>>> point if so.
>>>     
>>>>> and, in the case of the decade-old Aculab
>>>>> cards which which I'm most familiar, is also untrue.
>>>>>     
>>>>>         
>>>> I can't find too much about the old cards on the web now, but I found 
>>>> http://www.amdevcomm.com/voice-mail-products/voice-mail-components/dialogic/dti_sc.html 
>>>> which is pretty much a copy and paste from the old Dialogic web pages, 
>>>> and you'll see it says "Cut through : Local echo cancellation permits 
>>>> 100% detection with a >4.5 dB return loss line". The Aculabs did the 
>>>> same thing for sure. They just couldn't work without cancellation. There 
>>>> were some very early Dialogic cards, using DTMF receiver chips and OKI 
>>>> ADPCM chips, and had no general purpose DSPs. They performed really 
>>>> badly because of the lack of cancellation, and were quickly replaced 
>>>> with cards that put the OKI ADPCM, DTMF anf echo cancellation algorithms 
>>>> into a Motorola 56k DSP chips.
>>>>   
>>>>       
>>> The same document, under the bit which you've quoted, says:
>>> "(E-1) Digital trunks use separate transmit and receive paths to network.
>>> Performance dependent on far end handset's match to local analog loop."
>>> - i.e. the card does no echo cancellation. 
>>>     
>> Your messages are starting to looked deranged. Why would they only apply 
>> echo cancellation to T1s? Its a bizarre idea, and you must realise its 
>> wrong. Are you so desperate to support a wrong answer you'll clutch at 
>> straws? :-\
>>   
> More insults. Answer me this: if there were echo cancellation in use, 
> why would
> DTMF detection performance depend on the far-end handset's match to 
> the loop?
>
> And the follow-up question (which you've already pretty much asked) - 
> if the
> card doesn't echo cancel for E1s, why would it for T1s?
>
> As an aside, I'm not convinced that the document's not talking about 
> return loss
> on the T1 line itself, the implication being that the T1 is being 
> carried on a single
> pair, which makes the first sentence about E1s make a bit more sense. 
> But that's
> just a guess.
>>> Aculab didn't even offer echo cancellation on Prosody for years and, 
>>> when they did, it
>>> consumed prodigious amounts of DSP.  Nonetheless, the DTMF detection 
>>> worked
>>> perfectly well, even across 120 channels per 40MHz SHARC - there's 
>>> just no way
>>> that those DSPs had enough horsepower to do echo cancellation across 
>>> that manychannels.
>>>     
>> This page 
>> http://www.aculab.com/support/pdf_documents/v6_solaris/ting/pubdoc/an-dtmf-det-issues.html 
>> seems to support what you say. It also implies DTMF detection sucks 
>> unless you echo cancel. The statement "If the outgoing signal is a tone 
>> of some sort (e.g. a 'beep'), ensure that its frequency is below 600Hz" 
>> is telling you to keep your outgoing signal in the same frequency range 
>> as dial-tone where the dial-tone filter on the DTMF receiver will 
>> obviate the need for an echo canceller. They are freely admitting 
>> exactly what I have said. If you want a normal IVR with cut-through to 
>> work you better turn that echo canceller on.
>>
>> My only experience with Aculab was fitting a box designed by other 
>> people into a system. That one definitely echo cancelled, as it worked 
>> as well as the Dialogic based boxes we developed ourselves.
>>   
> That only holds true if your premise - that you need echo cancellation 
> for good
> DTMF detection - is correct, which I don't believe it is.
>>> An Asterisk box with an el-cheapo quad E1 card in that I use for 
>>> TDM-SIP gatewaying
>>> detects DTMF perfectly well with no echo cancellation.
>>>     
>> You must have very low standards for "works well".
>>   
> Nothing like a good old ad hominem attack. Beats reasoned argument any 
> day.
>>> You just don't need echo cancellation to achieve perfectly acceptable 
>>> DTMF detection.
>>>     
>> Well, not if you expect people to wait for silence before entering DTMF, 
>> but who would tolerate that these days? Cut through has been de rigeur 
>> since the late 80s.
>>   
> Oh, for pity's sake, you get perfectly good cut through without echo 
> cancellation.
> Humour me and draw a quick mental picture of the spectrum of a random 
> bit of
> speech at -20dBm; now add tones at -10dBm and -7dBm. They stick out like
> a pair of sore thumbs.
>
> I'm sure it's quite possible to come up with a pathological case - 
> e.g. cut-through
> against a 1kHz milliwatt tone, but that sort of thing just doesn't 
> happen in real-
> life IVR applications.
>>> ASR - yes, maybe, but surely only in the case where the application 
>>> requires barge-in;
>>> even then, I'd be interested to see some test results, particuarly 
>>> where the outbound prompt
>>> is killed the moment the ASR reports start of speech.
>>>     
>> Doesn't any sane system expect barge in to be nearly as reliable as 
>> waiting for silence? Who would tolerate something that doesn't? It has 
>> been a standard expectation of any decent IVR since they began.
>>   
> Sorry - ASR with barge-in has been a standard expectation since the 
> first IVRs?
>>> I'm afraid that your original bald claim - that "IVRs badly need echo 
>>> cancellation" is simply
>>> wrong, misleading and irresponsible: those believing it will end up 
>>> spending large sums
>>> of money on technology which they probably do not need.
>>>     
>> You must have very low standards for what works well. If you suggest 
>> people leave out echo cancellation you are just asking for customer 
>> service issues down the line. That whole Aculab page is a clear response 
>> to just such issues they had, which forced them to add the necessary 
>> improvements.
>>   
> Repeating you ad-hominem really doesn't make it any stronger, I'm 
> afraid. And
> the Aculab page you refer to offers four solutions for problems caused 
> by far-
> end echo, of which cancellation is just one; not playing a stationary 
> tone above 600Hz
> is another.
Doesn't "don't use frequencies above 600Hz" mean they won't work very 
well with voice present? Their "solutions" are use echo cancellation or 
don't create cut-through situations. That whole Aculab page is skirting 
around making a direct statement that reliable cut-through demands echo 
cancellation.
>
> Do you have any real-world samples of DTMF+echo which give your DTMF
> detection code trouble?

Any analogue line with substantial spillback. Huge numbers of lines have 
spillback gain only a few dB below the true receive gain. You don't 
normally notice this, as with a short delay its just a bit of pleasant 
reverb. Its becomes a problem with high latency VoIP paths stretch that 
delay. Its also a problem for any equipment which needs a clean signal 
from the far end. A modem for example, or an IVR. Echo cancellation is 
the only practical solution.

Regards,
Steve