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 <[email protected]> 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 > [email protected] > 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:[email protected] <msn%[email protected]> GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:[email protected] <sip%[email protected]> iax:[email protected]/888 googletalk:[email protected]<googletalk%3aconf%[email protected]> pstn:213-799-1400
_______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
