I'm thinking about doing a project that would use FreeSWITCH as an IVR, with callers being routed in by both ISDN PRI, and also SIP trunks, with occasional bridge calls between callers. I'm wondering in what use cases hardware echo cancellation on the PRI cards is needed. And does hardware echo cancellation work with OpenZap/FreeSWITCH? It looks like all the major cards (Sangoma, Digium, etc..) use Octasic Echo cancellation add-on cards. Is there any difference between brands? Any recommendations on PRI boards and whether I need to pay for echo cancellation are appreciated Thanks. Tony
The cards that feature Hardware Echo Can¹s work on hardware/driver level and are supported... From: Anthony Knight <tntknight@gmail.com> Reply-To: <freeswitch-users@lists.freeswitch.org> Date: Tue, 17 Mar 2009 00:55:35 -0400 To: <freeswitch-users@lists.freeswitch.org> Subject: [Freeswitch-users] echo cancellation on PRI cards I'm thinking about doing a project that would use FreeSWITCH as an IVR, with callers being routed in by both ISDN PRI, and also SIP trunks, with occasional bridge calls between callers. I'm wondering in what use cases hardware echo cancellation on the PRI cards is needed. And does hardware echo cancellation work with OpenZap/FreeSWITCH? It looks like all the major cards (Sangoma, Digium, etc..) use Octasic Echo cancellation add-on cards. Is there any difference between brands? Any recommendations on PRI boards and whether I need to pay for echo cancellation are appreciated Thanks. Tony _______________________________________________ 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
2009/3/17 Anthony Knight <tntknight@gmail.com> I'm thinking about doing a project that would use FreeSWITCH as an IVR, with
callers being routed in by both ISDN PRI, and also SIP trunks, with occasional bridge calls between callers.
I'm wondering in what use cases hardware echo cancellation on the PRI cards is needed.
When there is Echo being generated from the far end, usually in a bridged call. If you application is just an IVR, with no far end connectivity, then you shouldn't need an echo can. If you are bridging calls, then at some point you may need it, depending on what else is in the loop.
And does hardware echo cancellation work with OpenZap/FreeSWITCH?
Yes, it really has nothing to do with the software then, its handled by the card and its hardware driver. In Sangoma's case, by Wanpipe.
It looks like all the major cards (Sangoma, Digium, etc..) use Octasic Echo cancellation add-on cards. Is there any difference between brands?
Sangoma has 1024 tap Octasic Echo Cans. Very nice they are indeed.
Any recommendations on PRI boards and whether I need to pay for echo cancellation are appreciated
Unashamedly, Sangoma's. 100% of the cases where our customers have used Sangoma A10Xd vs A10X, they've been much happier with the quality on the line. Its a tad bit more $, but well worth it (especially in places with bad copper). -- wasim h. baig | principal consultant | convergence pk | +92 300 8508070 | peace be upon you ...
Wasim Baig wrote:
2009/3/17 Anthony Knight <tntknight@gmail.com <mailto:tntknight@gmail.com>>
I'm thinking about doing a project that would use FreeSWITCH as an IVR, with callers being routed in by both ISDN PRI, and also SIP trunks, with occasional bridge calls between callers.
I'm wondering in what use cases hardware echo cancellation on the PRI cards is needed.
When there is Echo being generated from the far end, usually in a bridged call. If you application is just an IVR, with no far end connectivity, then you shouldn't need an echo can. If you are bridging calls, then at some point you may need it, depending on what else is in the loop. This is VERY VERY WRONG. IVRs badly need echo cancellation. Without it they give very poor reliability detecting DTMF while the prompts are playing. If the system uses voice recognition, its reliability will be even worse. And does hardware echo cancellation work with OpenZap/FreeSWITCH?
Yes, it really has nothing to do with the software then, its handled by the card and its hardware driver. In Sangoma's case, by Wanpipe.
It looks like all the major cards (Sangoma, Digium, etc..) use Octasic Echo cancellation add-on cards. Is there any difference between brands?
Sangoma has 1024 tap Octasic Echo Cans. Very nice they are indeed.
Any recommendations on PRI boards and whether I need to pay for echo cancellation are appreciated
Unashamedly, Sangoma's. 100% of the cases where our customers have used Sangoma A10Xd vs A10X, they've been much happier with the quality on the line. Its a tad bit more $, but well worth it (especially in places with bad copper).
If you use Sangoma make sure everything is up to date. People have had a lot of DTMF detection trouble with some revisions of the driver, or on board firmware, or possibly both. Clearly DTMF trouble would be pretty bad for an IVR. I didn't manage to trace which were the offending versions, but the current stuff is apparently OK. Steve
Steve Underwood wrote:
When there is Echo being generated from the far end, usually in a bridged call. If you application is just an IVR, with no far end connectivity, then you shouldn't need an echo can. If you are bridging calls, then at some point you may need it, depending on what else is in the loop.
This is VERY VERY WRONG. IVRs badly need echo cancellation. Without it they give very poor reliability detecting DTMF while the prompts are playing. If the system uses voice recognition, its reliability will be even worse.
With respect, this is at best half true. DTMF detection has always worked just fine without echo cancellation - the Dialogic, Aculab and Rhetorex cards which I used in the late 1990s managed it perfectly well; if the DTMF detection code in * and FS can't, then maybe that's something for its author to look at ;-) ASR - yes, maybe, but L&H's ASR1500 used to work perfectly well on the same hardware above back in the day. I'd be interested to see results of testing an ASR engine in with echo; unfortunately, most vendors appear to prohibit the publication of test results in their licensing. --Dave
David Knell wrote:
Steve Underwood wrote:
When there is Echo being generated from the far end, usually in a bridged call. If you application is just an IVR, with no far end connectivity, then you shouldn't need an echo can. If you are bridging calls, then at some point you may need it, depending on what else is in the loop.
This is VERY VERY WRONG. IVRs badly need echo cancellation. Without it they give very poor reliability detecting DTMF while the prompts are playing. If the system uses voice recognition, its reliability will be even worse.
With respect, this is at best half true. DTMF detection has always worked just fine without echo cancellation - the Dialogic, Aculab and Rhetorex cards which I used in the late 1990s managed it perfectly well; if the DTMF detection code in * and FS can't, then maybe that's something for its author to look at ;-) Try reading the Dialogic and Aculab documentation. Those cards used quite a bit of their DSP capability to remove the spillback of outgoing voice into their DTMF receivers. You'll find the DTMF detector in spandsp (not necessarily the ones in * or FS, which have been altered a bit) is superior to either Dialogic or Aculab's. ASR - yes, maybe, but L&H's ASR1500 used to work perfectly well on the same hardware above back in the day. I'd be interested to see results of testing an ASR engine in with echo; unfortunately, most vendors appear to prohibit the publication of test results in their licensing. L&H used to work fine with the J series Dialogic cards. The Dialogic documents go into considerable details about the echo cancellation arrangements to make that happen.
Regards, Steve
Thanks for the feedback. I have plenty of experience with IVRs and Dialogic cards (starting with D121/LSI120s and SS96s under DOS in the 90's all the way up to Intel's DM/Vs) and didn't ever have a problem with DTMF collection with ISDN PRI lines except occasionally with wireless and cell phones (Bad line quality). These new cards are so much cheaper than the Dialogic cards were, I should just buy the version with the cancellers. Tony On Tue, Mar 17, 2009 at 11:36 AM, Steve Underwood <steveu@coppice.org>wrote:
David Knell wrote:
Steve Underwood wrote:
When there is Echo being generated from the far end, usually in a bridged call. If you application is just an IVR, with no far end connectivity, then you shouldn't need an echo can. If you are bridging calls, then at some point you may need it, depending on what else is in the loop.
This is VERY VERY WRONG. IVRs badly need echo cancellation. Without it they give very poor reliability detecting DTMF while the prompts are playing. If the system uses voice recognition, its reliability will be even worse.
With respect, this is at best half true. DTMF detection has always worked just fine without echo cancellation - the Dialogic, Aculab and Rhetorex cards which I used in the late 1990s managed it perfectly well; if the DTMF detection code in * and FS can't, then maybe that's something for its author to look at ;-) Try reading the Dialogic and Aculab documentation. Those cards used quite a bit of their DSP capability to remove the spillback of outgoing voice into their DTMF receivers. You'll find the DTMF detector in spandsp (not necessarily the ones in * or FS, which have been altered a bit) is superior to either Dialogic or Aculab's. ASR - yes, maybe, but L&H's ASR1500 used to work perfectly well on the same hardware above back in the day. I'd be interested to see results of testing an ASR engine in with echo; unfortunately, most vendors appear to prohibit the publication of test results in their licensing. L&H used to work fine with the J series Dialogic cards. The Dialogic documents go into considerable details about the echo cancellation arrangements to make that happen.
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
Anthony Knight wrote:
Thanks for the feedback.
I have plenty of experience with IVRs and Dialogic cards (starting with D121/LSI120s and SS96s under DOS in the 90's all the way up to Intel's DM/Vs) and didn't ever have a problem with DTMF collection with ISDN PRI lines except occasionally with wireless and cell phones (Bad line quality). You have my deepest sympathy. :-)
Steve
Steve Underwood wrote:
David Knell wrote:
Steve Underwood wrote:
When there is Echo being generated from the far end, usually in a bridged call. If you application is just an IVR, with no far end connectivity, then you shouldn't need an echo can. If you are bridging calls, then at some point you may need it, depending on what else is in the loop.
This is VERY VERY WRONG. IVRs badly need echo cancellation. Without it they give very poor reliability detecting DTMF while the prompts are playing. If the system uses voice recognition, its reliability will be even worse.
With respect, this is at best half true. DTMF detection has always worked just fine without echo cancellation - the Dialogic, Aculab and Rhetorex cards which I used in the late 1990s managed it perfectly well; if the DTMF detection code in * and FS can't, then maybe that's something for its author to look at ;-)
Try reading the Dialogic and Aculab documentation. Those cards used quite a bit of their DSP capability to remove the spillback of outgoing voice into their DTMF receivers. You'll find the DTMF detector in spandsp (not necessarily the ones in * or FS, which have been altered a bit) is superior to either Dialogic or Aculab's.
The first bit of that's a tad patronising, isn't it, and, in the case of the decade-old Aculab cards which which I'm most familiar, is also untrue. As for the second, do you have any test results to back that up? I'm more curious than setting out for an argument..
ASR - yes, maybe, but L&H's ASR1500 used to work perfectly well on the same hardware above back in the day. I'd be interested to see results of testing an ASR engine in with echo; unfortunately, most vendors appear to prohibit the publication of test results in their licensing.
L&H used to work fine with the J series Dialogic cards. The Dialogic documents go into considerable details about the echo cancellation arrangements to make that happen.
You've missed the point I was trying to make. It used to work fine with no echo cancellation at all. --Dave
David Knell wrote:
Steve Underwood wrote:
David Knell wrote:
Steve Underwood wrote:
When there is Echo being generated from the far end, usually in a bridged call. If you application is just an IVR, with no far end connectivity, then you shouldn't need an echo can. If you are bridging calls, then at some point you may need it, depending on what else is in the loop.
This is VERY VERY WRONG. IVRs badly need echo cancellation. Without it they give very poor reliability detecting DTMF while the prompts are playing. If the system uses voice recognition, its reliability will be even worse.
With respect, this is at best half true. DTMF detection has always worked just fine without echo cancellation - the Dialogic, Aculab and Rhetorex cards which I used in the late 1990s managed it perfectly well; if the DTMF detection code in * and FS can't, then maybe that's something for its author to look at ;-)
Try reading the Dialogic and Aculab documentation. Those cards used quite a bit of their DSP capability to remove the spillback of outgoing voice into their DTMF receivers. You'll find the DTMF detector in spandsp (not necessarily the ones in * or FS, which have been altered a bit) is superior to either Dialogic or Aculab's.
The first bit of that's a tad patronising, isn't it, You are the one who started out being offensive. 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/... 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.
As for the second, do you have any test results to back that up? I'm more curious than setting out for an argument..
ASR - yes, maybe, but L&H's ASR1500 used to work perfectly well on the same hardware above back in the day. I'd be interested to see results of testing an ASR engine in with echo; unfortunately, most vendors appear to prohibit the publication of test results in their licensing.
L&H used to work fine with the J series Dialogic cards. The Dialogic documents go into considerable details about the echo cancellation arrangements to make that happen.
You've missed the point I was trying to make. It used to work fine with no echo cancellation at all. I think you've missed the point. These things don't work by pixey dust. They work by engineering. If you have any old J or JCT cards around record the signal from the far end. You'll find only the tiniest trace of the outgoing signal mixed in with it. How do you think that happens?
Steve
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/... 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. 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 many channels. 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 just don't need echo cancellation to achieve perfectly acceptable DTMF detection. 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. 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. --Dave
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.
Anybody with years, perhaps decades, of DSP programming experience plus testing in the real world - and all over the world - has my vote of confidence. Furthermore, when this person writes spandsp, makes it open source, and freely answers questions about it on public fora, I am inclined not only to believe him but to trust his judgment. Bottom line: thousands of people have chosen to heed Steve's advice. He is well-respected in many technical communities. His reputation is as solid as it gets. "Do what Steve says" is about the safest bet you will ever make in this business. -MC
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/... 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? :-\
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 many channels.
This page http://www.aculab.com/support/pdf_documents/v6_solaris/ting/pubdoc/an-dtmf-d... 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.
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".
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.
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.
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. Regards, Steve
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/... 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-d... 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. Do you have any real-world samples of DTMF+echo which give your DTMF detection code trouble? --Dave
Sharing my humble experience: in Brazil we usually need echo cancellation to have reliable DTMF detection _and_ voice quality over E1 lines (be it on MFC/R2 - r2d - or ISDN PRI lines), either for sip/tdm gateway devices or IVR applications. Usually there's no need for echo cancellation on links from some Telcos, in some specific places. But we need it in the majority of cases, even when my box is just a gateway between legacy pbxes. This represents just a subset of the available E1s in the world and it's just a practical experience, but it's a fact for me. If I don't have a card with echo cancellation, I don't offer reliability to my customer; I've done that in the past and didn't work out. I'm not theoretically discussing anything, just sharing what I've been through in the last 4 or 5 years. 2009/3/17 David Knell <dave@3c.co.uk>
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/... 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-d... 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.
Do you have any real-world samples of DTMF+echo which give your DTMF detection code trouble?
--Dave
_______________________________________________ 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
-- Arnaldo M Pereira
Hi Arnaldo, That's interesting - Brasil was my first proper IVR installation: one with Embratel in Sao Paulo, and then a couple with TeleRJ. I remember landing at Sao Paulo airport for the first time at 7 a.m. with instructions to "meet a fat man called Ferrari" unsure as to whether I was in some sort of elaborate hoax (I wasn't, and he was), and learning my first three words of Portuguese as we left the car park: filho da puta, of course. Those had no EC. DTMF detection worked fine, and the audio quality of the IVR recordings was perfect, which is what you'd expect: EC doesn't alter the IVR->caller audio at all. A TDM->SIP->TDM type application is a different animal: you've got the added latency of packetisation/jitter buffering/etc. which pretty much makes echo cancellation a must. --Dave
Sharing my humble experience: in Brazil we usually need echo cancellation to have reliable DTMF detection _and_ voice quality over E1 lines (be it on MFC/R2 - r2d - or ISDN PRI lines), either for sip/tdm gateway devices or IVR applications.
Usually there's no need for echo cancellation on links from some Telcos, in some specific places. But we need it in the majority of cases, even when my box is just a gateway between legacy pbxes.
This represents just a subset of the available E1s in the world and it's just a practical experience, but it's a fact for me. If I don't have a card with echo cancellation, I don't offer reliability to my customer; I've done that in the past and didn't work out.
I'm not theoretically discussing anything, just sharing what I've been through in the last 4 or 5 years.
David Knell wrote:
Hi Arnaldo,
That's interesting - Brasil was my first proper IVR installation: one with Embratel in Sao Paulo, and then a couple with TeleRJ. I remember landing at Sao Paulo airport for the first time at 7 a.m. with instructions to "meet a fat man called Ferrari" unsure as to whether I was in some sort of elaborate hoax (I wasn't, and he was), and learning my first three words of Portuguese as we left the car park: filho da puta, of course.
What's interesting to me is.... everyone on this thread except you has said that in real-world scenarios, they need the EC for reliability. One of which, does signal processing programming professionally. It seems to me that if you "build a better mouse trap" you must know what's involved in making it work properly. I'm not sure what your background really is, but you'd be hard pressed to match up to Steve's reputation and/or experience. That said, it might be a good idea to just agree to disagree as this is starting to sound like the faxing over IP talks I hear a lot. (i.e. "faxing over g.711u with no t.38 works fine for me") Where it might work for some people by some mysterious phenomena, it won't work for the general public. And telling people that they don't need EC, where so many have already said that they obviously do, is just as irresponsible, IMHO, as you claiming Steve was for telling them that they don't need it. </my2cents> -Ray
Raymond Chandler wrote:
What's interesting to me is.... everyone on this thread except you has said that in real-world scenarios, they need the EC for reliability. One of which, does signal processing programming professionally. It seems to me that if you "build a better mouse trap" you must know what's involved in making it work properly. I'm not sure what your background really is, but you'd be hard pressed to match up to Steve's reputation and/or experience.
Public willy-waving is undignified but, in brief, I've built and sold IVRs since 1997, wrote a CAPI-based soft IVR in 1999 (which required software for, inter alia, DTMF detection), developed a software fax modem (V.29, V.27ter, T.30, etc.) which I sold to a CTI card vendor and so on. I've collected some data, of which it is commonly said that the plural of anecdote - which is what we've had so far - is not. The IVR collects a 16 digit DTMF string, terminated by #. TDM->IP conversion was performed by an Asterisk box with an el-cheapo quad E1 card (no EC) for half the calls, and an AS5400 (with EC) for the other half. The proportion of entries missing one or more digit was 3.1% (Asterisk) and 3.3% (AS5400); this is not a statistically significant difference given the sample size. The reason for looking at this criterion is (a) that it's easy to measure, and (b) the most likely way that a DTMF detector will fail in the presence of excess noise, which includes echo, would be to miss a digit. This error rate is the sum of human error + detector error, and I've no measurements to show how this might be split; I would expect it's almost all human. Note that this is a digit error rate of about 1 in 500. This is, of course, only data from one site, but it's a start; it's only by collecting data such as this that one can understand how well one's mouse trap works and whether it needs improvement or not.
That said, it might be a good idea to just agree to disagree as this is starting to sound like the faxing over IP talks I hear a lot. (i.e. "faxing over g.711u with no t.38 works fine for me") Where it might work for some people by some mysterious phenomena, it won't work for the general public. And telling people that they don't need EC, where so many have already said that they obviously do, is just as irresponsible, IMHO, as you claiming Steve was for telling them that they don't need it.
That's a simplification. Simple IVR (record, replay, collect DTMF) probably doesn't need EC; if you're trying to do ASR with barge-in, bridge callers to other callers or operators, etc., then you probably do. I am interested that the recommended solution is 'buy Sangoma' - expensive and proprietary - when Oslec, a FOSS echo cancellers which, by all accounts, works extremely well, is out there and has been for some time. --Dave
Well,
From my experience, an AS5300 thinks nearly *anthing* is dtmf. The one I have as a PSTN onramp to our conference bridge drives me bonkers with false positives since every key on the pad means something in our default conference.
Jim Dixon designed the el-cheapo (tormenta 2) to put as many resources on the host as possible, that was the goal behind the initiative. The driver for this card was the template on which the entire Zaptel (now Dahdi) was based. What's interesting is that early zapata library (a user space abstraction lib) was completely consumed by chan_zap and from there may of the featues were gravitated towards the linux kernel then eventually into the hardware as new cards were developed. The typical reason for this kind of evolution is customers. When there was no TDM to be had at all, el-cheapo and software was the bees knees. As they started getting more greedy and anxious for higher quality, they started asking for improvements that lead to more stuff onboard in the new cards. I am guessing this will continue until the cards are too expensive and we will go full circle back to all-on-host just in time for the 16 core CPU box being standard issue. It all depends on the strategy employed, if you want to use a tor2 and oslec, (a software echo canceller that, in fact has none other than Steve Underwood from this thread as a collaberator) then do it. If it ain't broke, don't fix it.....If you prefer to have hardware EC, then buy a card that supports it. ------ see http://www.rowetel.com/ucasterisk/oslec.html Background and Credits Oslec started life as a prototype echo canceller and G168 test framework from Steve Underwood's Spandsp <http://www.soft-switch.org/> library. Steve wrote much of the DSP code used in Asterisk, and the Zaptel echo cancellation code is heavily based on his work. ------ Bottom line: There is no real correct answer because it depends on what your goals are and what you personally prefer. I personally have used both, I am annoyed with hardware EC because it breaks software dtmf but now the sangoma drivers have hardware dtmf to use together with hardware EC so that solves the problem. I would prefer not to take any sides in this debate since everyone on this thread has contributed greatly to our project and I respect them all. I would, however, like to ask that maybe we can channel all of this intelligence into some common goal and do somethng great rather than spend our energy doing the techno-geek version of m&m freestyle rapping. On Sat, Mar 28, 2009 at 8:44 AM, David Knell <dave@3c.co.uk> wrote:
Raymond Chandler wrote:
What's interesting to me is.... everyone on this thread except you has said that in real-world scenarios, they need the EC for reliability. One of which, does signal processing programming professionally. It seems to me that if you "build a better mouse trap" you must know what's involved in making it work properly. I'm not sure what your background really is, but you'd be hard pressed to match up to Steve's reputation and/or experience.
Public willy-waving is undignified but, in brief, I've built and sold IVRs since 1997, wrote a CAPI-based soft IVR in 1999 (which required software for, inter alia, DTMF detection), developed a software fax modem (V.29, V.27ter, T.30, etc.) which I sold to a CTI card vendor and so on.
I've collected some data, of which it is commonly said that the plural of anecdote - which is what we've had so far - is not. The IVR collects a 16 digit DTMF string, terminated by #. TDM->IP conversion was performed by an Asterisk box with an el-cheapo quad E1 card (no EC) for half the calls, and an AS5400 (with EC) for the other half.
The proportion of entries missing one or more digit was 3.1% (Asterisk) and 3.3% (AS5400); this is not a statistically significant difference given the sample size. The reason for looking at this criterion is (a) that it's easy to measure, and (b) the most likely way that a DTMF detector will fail in the presence of excess noise, which includes echo, would be to miss a digit. This error rate is the sum of human error + detector error, and I've no measurements to show how this might be split; I would expect it's almost all human. Note that this is a digit error rate of about 1 in 500.
This is, of course, only data from one site, but it's a start; it's only by collecting data such as this that one can understand how well one's mouse trap works and whether it needs improvement or not.
That said, it might be a good idea to just agree to disagree as this is starting to sound like the faxing over IP talks I hear a lot. (i.e. "faxing over g.711u with no t.38 works fine for me") Where it might work for some people by some mysterious phenomena, it won't work for the general public. And telling people that they don't need EC, where so many have already said that they obviously do, is just as irresponsible, IMHO, as you claiming Steve was for telling them that they don't need it.
That's a simplification. Simple IVR (record, replay, collect DTMF) probably doesn't need EC; if you're trying to do ASR with barge-in, bridge callers to other callers or operators, etc., then you probably do.
I am interested that the recommended solution is 'buy Sangoma' - expensive and proprietary - when Oslec, a FOSS echo cancellers which, by all accounts, works extremely well, is out there and has been for some time.
--Dave
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
That's a simplification. Simple IVR (record, replay, collect DTMF) probably doesn't need EC;
Dave Collect DTMF does not need EC. I take out your word "probably" because no need for any dilemma. Interaction between DTMF detector an EC *when EC exist * is different question and deserve separate thread. Although I am confirming your statement,** I can not say "I am voting for you", simple because this is not political forum to express believing to one or other leader or authority. With respect koliqi
Fadil Berisha wrote:
That's a simplification. Simple IVR (record, replay, collect DTMF) probably doesn't need EC;
Dave
Collect DTMF does not need EC. I take out your word "probably" because no need for any dilemma. Interaction between DTMF detector an EC *when EC exist* is different question and deserve separate thread. Although I am confirming your statement,// I can not say "I am voting for you", simple because this is not political forum to express believing to one or other leader or authority.
Receiving DTMF reliably needs a signal to noise ratio of about 10dB if the noise is Gaussian. The statistics of voice mean you need the DTMF to be more like 15dB above voice. Most hybrids are only required to have a return loss of better than 12dB. They can be *much* better, but don't count on it, especially at the phone's hybrid. You have multiple hybrids in the path (usually 2 or 4). Let's take the better case with only 2 sitting between the outgoing exchange card and the far end phone. Put 10km of copper between the exchange the phone (typical copper planning limit) and you probably have 15dB of attenuation on the line. Now your DTMF is actually below the level of the voice prompt for much of the time. Think that will work with an echo canceller? Sure you can get reliable DTMF detection on 70%-80% of call paths with no echo cancellation, but if you want reliability with close to 100% of phone lines, you need echo cancellation to remove the voice prompt from the signal received at the IVR. Dialogic, NMS, and the others didn't put EC on their cards for nothing. The only reason the normal connection of a phone to a line card gets reliable detection of the first dialed digit in the presence of a dialing tone is that the DTMF detector heavily filters that dialing tone. Forget the political forum crap. If you want to refute what I just said, try to back up your argument with some actual engineering. Regards, Steve
Sure you can get reliable DTMF detection on 70%-80% of call paths with no echo cancellation,
Fair enough. You say "sure you can get reliable DTMF detection on 70%-80% of call paths with no echo cancellation". OK, you forgot to mention that this is achievable with text-book algorithms and that exist advanced algorithms with reliability close to 100%. From my point of view , no need further arguing this issue and this thread for me is closed. With respect koliqi
Fadil Berisha wrote:
Sure you can get reliable DTMF detection on 70%-80% of call paths with no echo cancellation,
Fair enough. You say "sure you can get reliable DTMF detection on 70%-80% of call paths with no echo cancellation". OK, you forgot to mention that this is achievable with text-book algorithms and that exist advanced algorithms with reliability close to 100%. From my point of view , no need further arguing this issue and this thread for me is closed.
Could you enlighten us as to these advanced algorithms that beat conventional statistics? You keep referring to mystical adaptive algorithms on the OSLEC mailing list, but you never give any details there, either. Steve
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/... 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-d... 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
To share my experience: I had issues with echo with many E1 trunks in Serbia, especially when voice in between telco's network went to well known bad analog lines. I used OSLEC and I was fortunate to have Steve to complain to, he helped patching it further after my beta testing. Not many people would do that imho. I now switched to Sangoma cards with Octasic chips and occasionally would still hear certain echo. My view is that here some echo cancelling solution is very necessary, otherwise whole VoIP business comes up to bad reputation People would just not listen to themselves speaking, even using $400 phone. Regards, Ognjen 2009/3/18 David Knell <dave@3c.co.uk>
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/... 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.
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 many channels.
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 just don't need echo cancellation to achieve perfectly acceptable DTMF detection.
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.
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.
--Dave
_______________________________________________ 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
participants (11)
-
Anthony Knight
-
Anthony Minessale
-
Arnaldo de Moraes Pereira
-
David Knell
-
Fadil Berisha
-
Ken Rice
-
Michael Collins
-
Ognjen Seslija
-
Raymond Chandler
-
Steve Underwood
-
Wasim Baig