This is the fourth and last post of my Asterisk + Twilio series:
- Asterisk + Twilio: Motivation (Part I)
- Asterisk + Twilio: The hardware, Cisco SPA3102 and the FXO vs FXS ports (Part II)
- Asterisk + Twilio: Making calls from home to twilio (Part III)
- Asterisk + Twilio: Receiving calls from twilio (Part IV)
Aaaand now to the most interesting (and challenging) part of the journey… receiving calls from twilio to my Asterisk.
I have a twilio US number, and wand to forward incoming calls to my mobile phone. As I said on the first post of the Asterisk + Twilio series, that works just fine on twilio, but it’s a little too expensive (38 cents per minute).
So, I wanted twilio to forward the call to Asterisk so that it calls me from my landline (which takes the cost down to about 15 cents + 0.25 cents per minute of the SIP call) taking the cost to less than a half.
I carefully read twilio’s SIP reference, and set up a device on
sip.conf this way
Then, I had my number set up to point to a url that returned this xml
As the username and password would travel here, I bought an SSL from Comodo (at $7 per year) and used twilio’s signature in the message to validate the request… this way, I’d only reply to genuine requests and my replies would be encrypted by SSL. According to what I understood, twilio would send an INVITE using
mypass as password and that would do the trick… but my Asterisk just returned
and when I inspected the SIP packages (by downloading the PCap Log from twilio… you gotta love their debug tools) I saw this
which definitely made it look like the username I chose wasn’t being sent (at least, not in the
From, which is where Asterisk expects it for devices with type=user).
Then, I checked the ip twilio contacted me from and changed the device to
To my surprise… it worked! so, it looked like I had to use type = peer and create a device per ip… but they’re 23! and every device needs a different name, so I should know which IP twilio is going to use to choose the username matching the device… nope, that wouldn’t fly. Then, I realized I could do this
and even if doing
allowguest=yes may feel insecure, you’re identifying the peer by its ip… so an attacker should connect from one of those (and if the attacker had access to twilio’s infrastructure… well, they could certainly make a request and get my user/pass from the original xml).
Then, after that, my xml turned into this
which also feels safer (and those U$S 7 spent on the certificate a little less worthy). And set up the extension for it on my
to handle twilio’s calls to that extension. This works like a charm… but I’m an absolute noobie on Asterisk, so maybe
allowguest=yes is a vulnerability after all?
Well, and this is how I’m finishing this set of posts about Asterisk + Twilio, an experience that was extremely fun for me and I wanted to share. After this was working fine, I tweaked my logic to receive calls, so that if my Asterisk is down for whatever reason, I route the call through twilio as I used to… so the number points to an xml like this one
and the action that handles the call termination looks like this
PS: I wish I had a cool number like the one in the examples
PS2: Inspired by my question and answer at Stack Overflow