Seriously, how about you show us how to register an Android phone with your SIP service?
Docs and download are here - http://www.twilio.com/docs/client/android
SIP From Twilio is all we have to report right now.
Android has a native SIP client (so do Nokia phones), which makes me wonder what purpose the Twilio Android SDK serves.
And holy mackerel, 0.5c/minute for inbound. If I were running my own SIP enabled PBX I'd rather use Voxbone.com or one of their resellers. They have unlimited incoming minutes, charged per channel (concurrent calls).
Edit: added bit about SIP trunking
Twilio could theoretically handle these things for you, but they're typically handled in a PBX.
You guys only support termination through SIP, not origination, so the dialling mechanism doesn't matter. And if you did want to do origination, the ATA just has to understand pulse dialling.
Not that this isn't cool, I just don't understand what benefit you get from having Twilio connected here. It seems like if you want to make a physical phone ring you could take a time machine back to 2004 and achieve the same thing using Asterisk, no?
Can you explain the benefit of integrating with Twilio instead of using just plain ol' Asterisk?
Disclaimer: I work at 2600hz, the open-source cloud telecom company.
We think if the code that makes your customers happy and the code that makes your phones ring can finally live in the same place, some pretty magical stuff can happen.
I think the part that made me scratch my head was the line where Jon said "It was so satisfying to make a physical phone ring!" which is funny when you take it out of context for a multitude of reasons. I hope you appreciated my quip about time travel ;).
Having the logic separate from the delivery may make sense for some applications and might not for others. We wrestle with clients all the time that want various elements of the platform either directly under their control or as far away as humanly possible. There's usually little rhyme or reason to understanding which components are supposed to go where or for what reason, but that's Telecom in a nutshell. When dealing with large carriers, the question of what goes in the firewall, and what stays out, is a complete mystery until right before you ink the contract.
To be fair, your point about siloed telephony and business software does ring a tad hollow when you talk about Twilio which is essentially a silo for business logic of a different color, right?
Once again, I do really enjoy these chats :D. I also admire the hard work your team does writing these blogs which I point to as a great example of developer evangelism. Your team does a great job of getting out there and showing off the tech. I especially like the edge case stuff, like jamming Asterisk onto a Raspberry pi and connecting it to an obihai ;).
Re: silos - You know, when it comes to all this cloud buzzword stuff, it definitely can feel like a shell game. Like you are moving a headache from one area to another for the sake of staying technologically trendy. But, I think a lot like you in the sense that the technical details matter.
In the case of an API play like Twilio, your logic stays in your app and that logic instructs how the call or SMS through a very simple interface. We don't host or hold anything for you - we just make the process of you telling us what to do as easy as we possibly can using the tools you already have.
APIs that are thoughtfully designed and carefully crafted are silobusters - they erase the painful demarcation lines of our software making the limits on what is possible less about how one piece of code talks to another, but why.
You just need an ATA and a sip account like callcentric.
"SECURITY WARNING: Please treat the URL above as you would your password and do not share it with anyone."
I dial into a lot of conference calls and this would be an awesome setup. Just wondering if anyone else has tackled such a config yet?
What a waste of time with this Twilio garbage.