Automatic/Predictive Dialer for MTE recomendation?

Hi;

For what it's worth, I did a fairly intensive study of what was on the market about 9-12 months ago and quite honestly, the stuff was either priced through the roof (many thousands of dollars) or the product was complete crap (or both). Most companies that claimed superior answering machine detection were lying through their teeth to begin with. What I ended up doing was just writing it myself and my customer has been very happy with it. I created a web page that let the user upload a .csv file of phone numbers that needed to be called, let the user pick a few parameters such as the day to make the calls along with the range of hours that the calls could be made. It even created a voice recording based on the parameters so each caller would get a custom message played. Then I created a .call file for each call. The whole thing start to finish was only a couple hundred lines of PERL at most.

Even with my crappy (at best) PERL skills, what I ended up with was better than most. OH, and before I forget, when I upgraded Asterisk to 1.4.22, the upgrade broke CDR logging from .call files so I had to downgrade to 1.4.20.1. The bug was recently reported. I just went through that last week. The other big lesson I learned is that some dialers make back to back calls much too quickly and sometimes Asterisk got a bit overwhelmed so what I did was simply spread the .call files out every 2 minutes. It does not have to be that far apart though. The .call files I create are labeled as such: HHMM.MMDDYYYY.call and are placed in a special directory. A CRON job runs every minute to see if the time matches, and the .call file is then moved to the outgoing directory.

An autodial solution that works well is a valuable product, so it may be in your best interest to put some time into developing your own solution. That was my original intention, but the 500 other projects on my desk have forced that project aside for quite awhile. I would give you my PERL code, but I am afraid that if my crappy code was ever released into the wild, that civilization itself could be endangered.

Regards;

Frank

that would be a pretty big security risk, not to mention put yourself in a position where one company can mess up service for all your other tenants. Its not a good idea to let one tenant directly originate calls via the AMI when that server is shared with other tenants. Nothing safeguards your other tenants from errors. I would strongly suggest having them get a single-tenant box if they are running an outbound call center.

sineapps used to have predictive dialer, they got bought by venturevoip. I would check there.

I don't use the MTE version, so I may be missing something here. Exactly what is the security risk? Creating and managing the .call files? How does a call file mess up service for other tenants? How is that different from the tenant making those calls directly? What errors? If the .call file does not go through, it simply waits a few minutes and tries the call again up to "MaxRetries". I don't see how this is much different than multiple tenants making normal phone calls.

Regards;

FSD

in single tenant, if the customer screws the dialer (picks wrong contexts or floods the server with originations) that customer is the only one to suffer the consequences. In MTE, when the customer goes in alters the data, lets say he fat fingers something or gets ambitious and totally flubbs the call rate, he can really mess things up for everyone else. Even though every tenant is a seperate context, its still the same asterisk pbx engine running. Its never a good idea to give one customer the keys to the box when its a shared resource with other customers (just like its not a good idea to let customers on a mass hosted website create executable cgi without auditing code).

Frank

I am interested in your dialer app. Would you contact me at mgreco at fusethree dot com

Thank you

Michael