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.
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 ;).
It's cool to see Rpi in the mix but you could get the same feeling of using old fashioned phone ringing without the land line using magic jack. So what's the recurring cost with the above solution?
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 ;).
1 reply →
It's cool to see Rpi in the mix but you could get the same feeling of using old fashioned phone ringing without the land line using magic jack. So what's the recurring cost with the above solution?