<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Steve Underwood wrote:
<blockquote cite="mid:49C03F5D.9050904@coppice.org" type="cite">
<pre wrap="">David Knell wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Steve Underwood wrote:
</pre>
<blockquote type="cite">
<pre wrap="">[whopping big snip]
</pre>
<blockquote type="cite">
<pre wrap="">The first bit of that's a tad patronising, isn't it,
</pre>
</blockquote>
<pre wrap="">You are the one who started out being offensive.
</pre>
</blockquote>
<pre wrap="">I'm sorry if you find disagreement offensive; you might not wish to
read beyond this
point if so.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">and, in the case of the decade-old Aculab
cards which which I'm most familiar, is also untrue.
</pre>
</blockquote>
<pre wrap="">I can't find too much about the old cards on the web now, but I found
<a class="moz-txt-link-freetext" href="http://www.amdevcomm.com/voice-mail-products/voice-mail-components/dialogic/dti_sc.html">http://www.amdevcomm.com/voice-mail-products/voice-mail-components/dialogic/dti_sc.html</a>
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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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? :-\
</pre>
</blockquote>
More insults. Answer me this: if there were echo cancellation in use,
why would <br>
DTMF detection performance depend on the far-end handset's match to the
loop?<br>
<br>
And the follow-up question (which you've already pretty much asked) -
if the<br>
card doesn't echo cancel for E1s, why would it for T1s?<br>
<br>
As an aside, I'm not convinced that the document's not talking about
return loss<br>
on the T1 line itself, the implication being that the T1 is being
carried on a single<br>
pair, which makes the first sentence about E1s make a bit more sense.
But that's<br>
just a guess.<br>
<blockquote cite="mid:49C03F5D.9050904@coppice.org" type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->This page
<a class="moz-txt-link-freetext" href="http://www.aculab.com/support/pdf_documents/v6_solaris/ting/pubdoc/an-dtmf-det-issues.html">http://www.aculab.com/support/pdf_documents/v6_solaris/ting/pubdoc/an-dtmf-det-issues.html</a>
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.
</pre>
</blockquote>
That only holds true if your premise - that you need echo cancellation
for good <br>
DTMF detection - is correct, which I don't believe it is.<br>
<blockquote cite="mid:49C03F5D.9050904@coppice.org" type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->You must have very low standards for "works well".
</pre>
</blockquote>
Nothing like a good old ad hominem attack. Beats reasoned argument any
day.<br>
<blockquote cite="mid:49C03F5D.9050904@coppice.org" type="cite">
<blockquote type="cite">
<pre wrap="">You just don't need echo cancellation to achieve perfectly acceptable
DTMF detection.
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
</blockquote>
Oh, for pity's sake, you get perfectly good cut through without echo
cancellation.<br>
Humour me and draw a quick mental picture of the spectrum of a random
bit of<br>
speech at -20dBm; now add tones at -10dBm and -7dBm. They stick out
like<br>
a pair of sore thumbs.<br>
<br>
I'm sure it's quite possible to come up with a pathological case - e.g.
cut-through<br>
against a 1kHz milliwatt tone, but that sort of thing just doesn't
happen in real-<br>
life IVR applications.<br>
<blockquote cite="mid:49C03F5D.9050904@coppice.org" type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
</blockquote>
Sorry - ASR with barge-in has been a standard expectation since the
first IVRs?<br>
<blockquote cite="mid:49C03F5D.9050904@coppice.org" type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
</blockquote>
Repeating you ad-hominem really doesn't make it any stronger, I'm
afraid. And <br>
the Aculab page you refer to offers four solutions for problems caused
by far-<br>
end echo, of which cancellation is just one; not playing a stationary
tone above 600Hz<br>
is another.<br>
<br>
Do you have any real-world samples of DTMF+echo which give your DTMF<br>
detection code trouble?<br>
<br>
--Dave<br>
</body>
</html>