I like Twilio. They’ve made programming voice fun, something it certainly wasn’t when Dialogic boards were the platform of choice. I’m using Twilio for a new service I’m working on. More on this in another post.
When you start playing with Twilio, a few common needs arise. For me, the first two were:
- Forward a Twilio phone number to another phone number. In testing, I have to switch between lots of different numbers. Twilio uses Web hooks, i.e., maps phone and SMS events to HTTP requests. I found myself tweaking scripts a few times per day.
- Registering a Twilio phone number for CallerID. Twilio wants to validate that you control the number you want to register for CallerID. Therefore, they give you a call and ask you to enter a random PIN. That’s not easy to do when the verification call to the Twilio number will result in an HTTP request to some app.
It was the problem of registering a CallerID for a Twilio number that led me to a simple hack that solved both problems. My idea was to forward the Twilio number to my cell phone and enter the PIN validation when I got the verification call. To make things a little easier, I made the forwarding endpoint accept the forwarding number as a parameter.
You use it like this:
The link is live so feel free to point your Twilio numbers to it. Remember to enter the phone number with the country code.
The code is trivial:
<?php header("content-type: text/xml"); echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"; if(!$to = $_REQUEST['to']) $to = "18005551212"; ?> <Response> <Dial>+<?php echo $to ?></Dial> <Say>The call failed or the remote party hung up. Goodbye.</Say> </Response>
One of the Twilio numbers I set up for CallerID is going to be used for outbound calls only. What was going to happen when someone called it directly? That led to another quick Twilio hack–email me instead–which will greet callers and tell them to email you at a given address.
Side note: when doing speech to text, you have to write the text in a way that helps the speech engine pronounce it correctly. Note the commas I added to insert short pauses and the mis-spelling of Inc as ink, which I found made the “k” sound a little stronger.
Go ahead, try this by calling (917) 300-0268.
Another “twivial” code snippet:
<?php header("content-type: text/xml"); echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"; if(!$name = $_REQUEST['name']) $name = ""; if(!$email = $_REQUEST['email']) $email = "the feedback address on our site"; ?> <Response> <Say voice="woman">Thank you for calling <?php echo $name ?>.</Say> <Pause length="1"/> <Say voice="woman">Please, email us at <?php echo $email ?>.</Say> <Pause length="2"/> <Say voice="woman">Goodbye.</Say> </Response>
I wish Twilio did three things:
- Allow for static TwiML to be associated with a phone number. I’d love to just be able to enter some markup in a text box to handle simple cases like the ones above without having to deploy any server-side code.
- Automatically allowed us to set up CallerID on Twilio numbers we own. That’s just common sense.
- Allowed localhost targets using some type of automatic gateway software (in-page applet or browser plugin or Adobe AIR app). This will make testing so much easier.
Other than that, thanks, guys!
I like your hacks!
For #1 I usually just tell people to put the XML in a file in S3 and point Twilio at that 🙂
Right. It shouldn’t be that complicated.
You should check out “Twimlets”. http://labs.twilio.com/twimlets/
For example, to forward a call, …
1. Twimlets are not static TwiML, but they are hosted on their servers, so you don’t need to worry about them.
2. Twilio phone numbers in your account are automatically validated to be used as Caller IDs for your apps.
3. You *can* host your app on localhost for development.
Making a local web server public with localtunnel
— David Jones
David, thanks. You comment echoes Josh’s below.
The simple forwarding app you wrote is similar to our Forward Twimlet: http://labs.twilio.com/twimlets/forward We have a few other small, pre-built apps that are configurable from just the URL: http://labs.twilio.com/twimlets/
For 1, another easy way is to get a free Dropbox account and put the static XML files in the Public folder, then right click on them, Get Public Link, and use that as the URL. Just make sure to use GET instead of POST when using static resources.
For 2, I’m a little confused. Numbers you verify through the dashboard can be used as outgoing caller IDs. The verification process does not make any HTTP requests to any of your URLs. Once verified, you can use them as the ‘From’ number. You can also use any purchased Twilio number as the ‘From’ number as they’re automatically validated.
For 3, check out localtunnel which was written by a Twilio employee: https://github.com/progrium/localtunnel/ We have a blog post in the works on using this. It’s free!
Let me know if you have any other questions!
John, thanks for jumping in. Twimlets are indeed cool.
Re: Dropbox, hmm, do you think that static TwiML is such an infrequently-used pattern that your users should go to S3 or Dropbox for the solution? How hard is it for Twilio to do this and what might the reason be for not doing it?
Re: callerID verification, what you say is good to hear. Unfortunately, it is not at all clear in the UE nor was it handled on the feedback forums (see http://getsatisfaction.com/twilio/topics/using_twilio_numbers_for_caller_id). What is also not clear is what description would show with the CallerID.
Localtunnel is cool. What I was talking about is something that is even simpler to use and tied into your authentication system by default.
The wording around caller IDs definitely needs to be cleared up. Thanks for the feedback.
Every feature has a cost. There’s an engineering cost, a support cost, and a “focus” cost. We’ve prioritized our features around things that don’t exist elsewhere, but we we’re always working to make Twilio more accessible so it may be something we support in the future. We hear your feedback!
Can you tell me more about how you’d like to see local access work?
Whether implemented as a FireBug extension or a standalone Adobe AIR app, here is the experience I’d like to have…
I enter my Twilio credentials in the app. While it is running on my machine, all localhost endpoints hit my machine. In addition, I get the ability to log requests and responses locally, search the logs, modify + resend any request from Twilio to my app and any response from my app to Twilio (both from the log and in real-time, meaning with buffering). The app should do TwiML validation locally. It should also allow for breakpoints based on TwiML commands + regular expression patterns for their contents.
These use cases for making developers productive are nothing new–Web services developers have used HTTP tunneling + debug proxies for more than a decade. However, most developers are unaware of how to combine the various tools and the inter-tool workflow leaves a lot to be desired. Since TwiML over HTTP is such a limited protocol, it’s much easier to create a seamless development/debugging experience. This should increase development velocity in the Twilio ecosystem.
We can chat more offline if you are interested in this area.
Thanks for the feedback! Feel free to email me at email@example.com if you want to discuss further.
Hey John and Simeonov, I think I ran into a similar problem with the Twilio-purchased Numbers today.
I have a purchased number and I could use it for outgoing calls, but it didn’t show up in my account’s “Outgoing CallerId Numbers” or in the REST response from “…/OutgoingCallerIds”.
So I basically did the same thing as Simeonov by temporarily forwarding the purchased number to my real phone, clicking “Add Caller Id”, and verifying the code via my real phone. After that, it showed up in my “Outoing CallerId Numbers” and in the REST response of all my Outgoing CallerId Numbers.
It worked, but like Simeonov mentions it might be more user-friendly to auto-add numbers to that list so it’s extra obvious that they can be used (and so you can also update the “FriendlyName” of those purchased numbers via the REST api).
While the numbers you purchase from US are automatically validated for use as outgoing caller IDs, they don’t show up in the Outgoing Caller ID list. That’s only for the numbers you already own that go through the verification process. We are working on ways to make this more clear, thanks for the feedback!
Hope this helps,
Thanks John; in my case I just needed that Twilio-purchased number in the “OutgoingCallerIds” REST api response, which was only possible by explicitly re-validating it.
We’d love to send you a tshirt for putting this together. If you’re interested, email me with your size and address.
Weird… did you ever get that tshirt?
Were you able to get callerID working with text indicating the business name? I’m using a verified google number that works when I use google voice to call, but calling from twilio still only shows the digits only.