I'm looking into ways of sending a voicemail message (ideally as an audio file) to a number of mobiles/landlines in the UK (anywhere up to 300 people, but we can do them in batches if necessary).
Has anyone had any experience trying to do this?
Asterisk can certainly make calls, not just recieve them.
We use Asterisk, a VOIP provider, and a cepstral voice to send alarm calls. If no one answers, it leaves a message.
It can be a bit fiddly getting it to detect the answerphone correctly, but we've got it working with most of the ones we've come across so far.
Asterisk and probably other softswitches like (Freeswitch) could do that for you. The Asterisk voicemail config file, voicemail.conf, allows you to specify a command to run whenever a new voicemail is left in a user's mailbox. You could create a custom script or application that would do the forwarding for you.
Alternatively you could do it without any programming at all by creating an email alias for the 300 people and then assign that email address to a particular Asterisk mailbox. Asterisk supports voicemail to email by default so there wouldn't be any special configuration provided.
And you could probably also avoid setting up Asterisk by finding a VoIP provider that supports voicemail to email, which most of the Asterisk based ones do, and forwarding the voicemails to your own email alias address. In this case you'd just want to be careful about who could leave messages!
I would recommend Katalina 'VoiceGuide' - a windows-based CTI, IVR and dialler system at a reasonable price, supporting both tradtional POTS/ISDN telephony cards and VoIP. see: www.voiceguide.com
Related
I'd like to integrate some phone status information into our crm system (calling, on the hook, busy etc). I would prefer not to build and maintain a fully functioning SIP server because i only need very basic information. Also, our VOIP provider already maintains a fully functioning SIP server, and they are way better at it. Basically, I would my crm sever to be kept up to date on anything the phone does? Would it be possible for our crm server to receive any SIP messages the phones send to our VOIP provider.
Can I tell a sip phone to do that?
Is such a feature supported by many phones?
Am i looking at this in the wrong way? I'm completely new to SIP and phone integration so there is a good chance there is an easier or better way to do this.
Thank you for your help!
You might use phone feature called Action URL. It is generating HTTP GET requests on events like on hook / off hook, these request can be used to pass events to CRM.
I am creating a PHP system that will forward emails, (ie. someone#emailforprofession.com to someone#gmail.com) without using an SMTP server which is faster and more stable? PEAR::Mail or PHP: Mail? (or another one entirely)
I would be using extra headers and attachments but mainly trying to keep it looking and acting the same. (if anyone has an example for forwarding with attachments PLEASE provide it!)
And not exactly on the side but is there a way for people to be able to send email from they're someone#emailforprofession.com email address without having a complete inbox etc?
It would probably be better for me to use a real email provider but these are supposed to be free email addresses so paying by the email address is not an option, if anyone knows of a service that: charges by the month or year, has an API that email addresses can be created from and that can set up email forwards via the API that would be most appreciated.
I currently have a partial system together but would like to know which way I should go first.
Thank you all.
The PEAR class supports multiple mailer backends, which allows you to
switch whenever needed and you'll be able to perform some benchmarks
and see which backend suits you best. The native mail function on the
other hand is much less advanced and will show a clear difference in
performance, especially for that amount of mails.
I also suggest you have a look at PEAR's mail queue class:
http://pear.php.net/package/Mail_Queue
This is much more recommended for larger projects such as yours,
you'll also be able to implement a cron like feature which will send a
certain amount of mail per period you choose.
Here
we've got different processes that send mails in case of issues encountered (e.g. not enough permissions to perform an operation on a certain order item). This works fine to the point that sometimes identical messages are sent every 5 minutes. In our environment it is very difficult to synchronize the email sending on application layer (actually there are different applications sending out email, so we'd have to touch every application if we were to implement this inside application layer).
It would seem logical for me that filtering out mails (by duplicate subjects) is best done within the email layer, e.g. the application receiving the SMTP requests.
Yet we'd also prefer not to go down to SMTP layer by ourselves, rather use an existing service/application.
Is anybody aware of a web mailer (like googlemail) which does this kind of filtering? it would be ok for us the pay for such a service, so being "free as in beer" would be nice, but being not free is not a showstopper.
Thanks in advance
Holger
I find the idea of filtering duplicate e-mail message by the Subject: header quite worrisome. If they are produced by multiple applications, how can you be certain that the content of the messages is duplicated and that you are not unwittingly dropping important notifications?
The only unique feature of a message that can be used to filter out duplicates is its Message-ID: header. If that header is the same for two messages, then it's usually reasonable to assume that they are copies of the same original message - e.g. one received directly and one that was CC'ed to a mailing list.
That said, you can do pretty much anything you want on most SMTP servers - at least those that are based on a Unix-like OS. For example, Postfix can use custom shell scripts for filtering.
You can, for example, use formail to extract the body of each message and produce its
MD5 hash. Comparing the message body hashes along with the Date:, Subject:, From:, To: and Cc: headers at the same time is a good start to detect real duplicates.
What's the easiest way to process incoming email? Our objective is to get email into a Resque queue. We've explored and integrated a lot of options, like piping email through Postfix into Ruby (which turned out to be unreliable), piping email through Google App Engine back to our server (which turned out to be shaky), and using Sendgrid (which is expensive.)
I'm trying to explore other ways to get email processed. Any ideas?
If the email is received and hosted by an IMAP-capable server (Gmail is good enough), then the messages can be retrieved and processed once and again from almost any programming language using standard libraries.
I know this is a subject that has been well covered here and throughout the web, so I am not asking for a list of carrier emails, however my question is how to send a text without knowing the users carrier and preferably without going through a third party.
The only solution that I thought of would be send out to all carriers. I would only be sending to US carriers, however would a large number of failed emails slow the mail server at all or cause any other problems?
Any advice on this solution or thoughts of others would be great.
If you keep sending messages to a carrier to numbers that don't exist, you'll start to get blocked as a spammer. Probably best to either ask your users for which carrier they use or use a gateway like Twilio (where I work) or the various others out there.
I would recommend using CloudVox's digits API. The carrier's aren't always up to date, from what I can tell it basically relies on the original carrier you got your phone number from. i.e. You had verizon but switched to AT&T to get an iPhone and kept the same phone number, CloudVox API would likely tell you the number is still a verizon number. However, I used this for my existing user's and then exposed a select box for them to choose their provider.
http://digits.cloudvox.com/
If you have a reason to consider using a third-party API provider, I'd recommend Plivo (I work here), among many other providers, to bypass the carrier lookup issue and have more flexibility.
It will require some extra legwork than sending to carrier emails, but you will less likely to fret over the deliverability. For example, check out the email and sms gateway built using Plivo and Mailgun API.