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 _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org