I recently participated at a Hackathon at my alma mater, UPR Mayagüez. I wanted to play round with a telephony API and see what I could come up with. My first idea was short lived. It was too complex for the limited time and I also realized that Plivo, the cloud API provider I was using, doesn’t support SMS for virtual numbers in other countries- which I planned to use (there seems to be a beta program, but I found out too late)- so I went with plan B. I’ve had this idea for a while, so I worked on a solution to my problem.
Here’s my idea and some background
I’ve had the same cell phone number for close to 15 years now. It’s also attached to more web services than I care to count for. The telephone industry has also changed a lot in the last 20 years, and many of the long distance imaginary barriers inside the US don’t exist any more. Except for Puerto Rico (and possibly other US territories). Puerto Rico phone numbers don’t work with many US services, including Google Voice, Uber, several phone conferencing services, Square, and many others I’m sure. I haven’t been able to find any logical reason for this, so I’m attributing this to the creaky backends of the telephone systems. It’s been a while since cell phone providers have considered Puerto Rico as a national number for phone calls. If you are a telephony guru and know why this is, feel free to chime in!
One of the things I’m planning to do at some point is get a new phone number from the continental US. I don’t want to lose my old phone number, but I wouldn’t like to pay two phone bills just for this. Enter MPhone. My plan is to port my old phone number to the cloud, and I’ll pay a fraction of what an extra phone bill would cost. I can then forward phone calls and SMS to my new phone number.
Building the backend for MPhone was fairly simple. I did spend a lot of time trying to debug why the caller ID was not showing correctly. After a lot of testing, it turned out to be on issue on Plivo’s side (already contacted them, waiting for a response). I used PHP for this because it was the lowest friction for me and time was limited (I have my eye on you Node.js and Heroku!). All I needed to do was to assign a script to each action (e.g. incoming call, incoming SMS) and dynamically generate an XML file with all the required attributes (e.g. incoming phone number, outgoing phone number). I got it all working the way I wanted, but I think I’ll add some new features in the following days.
Twilio seems to be what all the cool kids are talking about. Why did I go with Plivo instead? Pricing. Twilio charges 8X for a Puerto Rico phone number compared to a US phone number, while Plivo “only” charges 4.4X what they charge for a US phone number. Plivo turns out to be 45% cheaper (that’s only for renting the phone number, but phone call costs and SMS were also marginally less expensive). Twilio seems to have more features (Plivo doesn’t currently support MMS, Twilio does), so I might also give it a try at some point.
Turns out my plan was flawed all along. I did all my testing using a virtual US phone number (a price consideration, since I was using a test account with only $5 credit), and while writing this post I went back to check pricing at Plivo, and they don’t fully support SMS for Puerto Rico phone numbers. All is not lost however, I can still do the inverse of my original plan. I can get a US phone number in the cloud and forward it to my Puerto Rico number. I already contacted Plivo to see if there’s any possibility of fully supporting SMS for Puerto Rico phone numbers in the future, but I’m not holding my breath. In the mean time, I’ll probably add a few extra features (I’m working on adding a database backend) and I’ll also research other possible providers.
Code coming soon, will update the post when it’s ready!