- Phone menu, where Twilio handles the call and listens to DTMF tones and/or voice input, then sends the request to my web server, which then responds with text, audio clips, or prompts for further input.
- Voicemail transcription, where I initiate a call to my voicemail box through Twilio, and then use their text-to-speech conversion to transcribe my voicemails.
... and more. What would you do with an API that replaces PBX programming with XML exchanges over HTTP?
The best idea I have at the moment is for an online store, where a customer could enter the number and click to complete their order over the phone. When they submit their number, the web server records their order number and contents to pass on to a call center representative.
We're using Twilio at the moment to provide our paying customers a way of tracking incoming calls from their customers as part of our analytics package, and it's working really well for that. It's a neat system, and it's easy to work with.
I don't want to sound negative but this is getting ridiculous. The article is about an allegedly easily configurable conference call product, but the title imples some sort of cool, smart code that programmers would be interested in. Surely, the code backing the application is not three lines long but more like measured in tens of thousands.
This is not very different from posting an article with the title "How to solve the halting problem in one line of code" and then have
SuperLibrary.SolveHaltingProblem()
as the code. Don't get me wrong, I'm sure Twilio is a great product and that it is very easily configurable or usable, but I think the title is simply misleading. Sorry for the rant but this is getting more and more epidemic on HN.
Cool, working with a company now who is going to use Twilio for some SMS stuff; the API seems very simple and straight forward. But please fix your copy:
They run on Amazon EC2 with instances that have Asterisk; Digium is one provider of hardware for these situations but I don't know how that's incorporated into their architecture
They use some Asterisk. There is also a significant (and well-known) commercial component proprietary to the enhanced voice application services industry, although there are various reasons for which I cannot disclose what it is.
We're slowly migrating most of our PBX/IVR apps from Asterisk to FreeSWITCH. I agree FreeSWITCH is higher quality code, but unfortunately there is a much smaller developer/support/hardware ecosystem with FreeSWITCH right now.
http://www.twilio.com/docs/howto/
- Phone menu, where Twilio handles the call and listens to DTMF tones and/or voice input, then sends the request to my web server, which then responds with text, audio clips, or prompts for further input.
- Voicemail transcription, where I initiate a call to my voicemail box through Twilio, and then use their text-to-speech conversion to transcribe my voicemails.
... and more. What would you do with an API that replaces PBX programming with XML exchanges over HTTP?
The best idea I have at the moment is for an online store, where a customer could enter the number and click to complete their order over the phone. When they submit their number, the web server records their order number and contents to pass on to a call center representative.