Well,<br><br>From my experience, an AS5300 thinks nearly *anthing* is dtmf.<br>The one I have as a PSTN onramp to our conference bridge drives me bonkers with false positives <br>since every key on the pad means something in our default conference.<br>
<br>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.<br>The driver for this card was the template on which the entire Zaptel (now Dahdi) was based.<br>
<br>What's interesting is that early zapata library (a user space abstraction lib) was completely consumed by chan_zap and from there <br>may of the featues were gravitated towards the linux kernel then eventually into the hardware as new cards were developed.<br>
<br>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.<br>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.<br>
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.<br><br>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.<br>
<br>------<br>see <a href="http://www.rowetel.com/ucasterisk/oslec.html">http://www.rowetel.com/ucasterisk/oslec.html</a><br><h2>Background and Credits</h2>
<div class="sectionbody">
<p>Oslec started life as a prototype echo canceller and G168 test
framework from Steve Underwood's <a href="http://www.soft-switch.org/">Spandsp</a>
library. Steve wrote much of the DSP code used in Asterisk, and the
Zaptel echo cancellation code is heavily based on his work.</p></div>------<br><br>Bottom line: There is no real correct answer because it depends on what your goals are and what you personally prefer.<br><br>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. <br>
<br>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.<br>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<br>
spend our energy doing the techno-geek version of m&m freestyle rapping.<br><br><br><br><div class="gmail_quote">On Sat, Mar 28, 2009 at 8:44 AM, David Knell <span dir="ltr"><<a href="mailto:dave@3c.co.uk">dave@3c.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Raymond Chandler wrote:<br>
> What's interesting to me is.... everyone on this thread except you has<br>
> said that in real-world scenarios, they need the EC for reliability.<br>
> One of which, does signal processing programming professionally. It<br>
> seems to me that if you "build a better mouse trap" you must know what's<br>
> involved in making it work properly. I'm not sure what your background<br>
> really is, but you'd be hard pressed to match up to Steve's reputation<br>
> and/or experience.<br>
><br>
Public willy-waving is undignified but, in brief, I've built and sold<br>
IVRs since<br>
1997, wrote a CAPI-based soft IVR in 1999 (which required software for,<br>
inter<br>
alia, DTMF detection), developed a software fax modem (V.29, V.27ter, T.30,<br>
etc.) which I sold to a CTI card vendor and so on.<br>
<br>
I've collected some data, of which it is commonly said that the plural<br>
of anecdote -<br>
which is what we've had so far - is not. The IVR collects a 16 digit<br>
DTMF string,<br>
terminated by #. TDM->IP conversion was performed by an Asterisk box with<br>
an el-cheapo quad E1 card (no EC) for half the calls, and an AS5400<br>
(with EC)<br>
for the other half.<br>
<br>
The proportion of entries missing one or more digit was 3.1% (Asterisk)<br>
and 3.3%<br>
(AS5400); this is not a statistically significant difference given the<br>
sample size.<br>
The reason for looking at this criterion is (a) that it's easy to<br>
measure, and (b) the<br>
most likely way that a DTMF detector will fail in the presence of excess<br>
noise,<br>
which includes echo, would be to miss a digit. This error rate is the<br>
sum of<br>
human error + detector error, and I've no measurements to show how this<br>
might<br>
be split; I would expect it's almost all human. Note that this is a<br>
digit error rate of<br>
about 1 in 500.<br>
<br>
This is, of course, only data from one site, but it's a start; it's only<br>
by collecting<br>
data such as this that one can understand how well one's mouse trap works<br>
and whether it needs improvement or not.<br>
> That said, it might be a good idea to just agree to disagree as this is<br>
> starting to sound like the faxing over IP talks I hear a lot. (i.e.<br>
> "faxing over g.711u with no t.38 works fine for me") Where it might work<br>
> for some people by some mysterious phenomena, it won't work for the<br>
> general public. And telling people that they don't need EC, where so<br>
> many have already said that they obviously do, is just as irresponsible,<br>
> IMHO, as you claiming Steve was for telling them that they don't need it.<br>
><br>
That's a simplification. Simple IVR (record, replay, collect DTMF) probably<br>
doesn't need EC; if you're trying to do ASR with barge-in, bridge callers to<br>
other callers or operators, etc., then you probably do.<br>
<br>
I am interested that the recommended solution is 'buy Sangoma' - expensive<br>
and proprietary - when Oslec, a FOSS echo cancellers which, by all accounts,<br>
works extremely well, is out there and has been for some time.<br>
<br>
--Dave<br>
<br>
<br>
<br>
_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400<br>