Comment by josh2600
13 years ago
Not to be pedantic, but what does Twilio help here? Aren't you kind of just Jerryrigging Twilio onto an Asterisk install?
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.
Great question Josh. Big benefit here is being able to keep your voice application logic in your own code instead of in Asterisk. Often we find in business telephony applications, the really important information you want to get to and from the user isn't in the phone server, but in the CRM app or help desk app or support app that the phone server is trying to get to and from the user. The closer data like account numbers or service tags or support tickets is to the logic that directs your IVR tree or call queue, the easier it is to build experiences that delight users. Siloed telephony and business software manifest themselves in ugly ways like having to repeat information to multiple agents or waiting on hold while your account information is retrieved.
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.
As always Rob, great answer :).
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 ;).
I'm not sure the answers I have are always great, but really appreciate your praise of the devangel crew at Twilio. I'm very lucky to work with them.
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.