Tropo My VoiceModel
I recently became interested in Tropo to easily develop applications that support voice and SMS. Tropo is another service provided by Voxeo. Voxeo also has the Prophecy platform which allows you to develop voice applications using VoiceXML that can be deployed in the cloud or as an on-premise solution. The VoiceModel framework lets you easily develop VoiceXML applications using ASP.NET MVC and C# and it has been extensively tested on Prophecy. So why the interest in Tropo? How does it differ from VoiceXML development?
Tropo is interesting to me because of its pricing structure for putting applications into production in the cloud. With many VoiceXML platforms, like Prophecy, there are some up front costs to deploy your app and the pricing structure depends on the amount of minutes you intend to use. You often have to agree to some minimum minutes that you will use per month. With Tropo it is a simple pricing model. There are no up front costs for going into production, there is just one pricing structure for per minute costs, and there is no minimum usage required . This is especially attractive for putting out voice applications that may have a short life. An example of this might be a survey that you want to provide to customers but you do not intend to run it for any length of time. There are trade-offs. With Tropo you do not get to tailor which speech recognition engine or TTS engine you want to use and it is not as feature rich. But for many apps it serves the purpose well. The other downside is that you use a proprietary API to develop your applications instead of an open standard like VoiceXML.
That last issue of getting locked into a vendor because of proprietary API's got me thinking that VoiceModel could solve that problem. What if the application you developed in VoiceModel could run both on Tropo and any VoiceXML platform. That would be a very powerful feature for developing applications in VoiceModel. To see how this might be accomplished lets take a look at how Tropo works.
Tropo has two methods of developing applications called Scripting and WebAPI. As the name implies, Scripting is a scripting language that works within other scripting languages such as JavaScript, PHP, Ruby, Python, or Groovy. The WebAPI is a RESTful API that exchanges JSON to let the IVR platform know what to do next and for it to return results. I choose to use the WebAPI as the method for integrating VoiceModel to Tropo. When a call comes into the Tropo platform for applications using the WebAPI the system makes a POST request to a URL you configure for your application. In the initial POST request is some JSON that has some session information on the call. The voice application then responds to the POST request with JSON that indicates what to do next. For example, play a prompt to the user. When Tropo completes this request it sends another POST with any results as JSON, and the cycle continues until the application has completed by sending a hangup request. This seems like the perfect scenario for using ASP.NET MVC to implement this protocol and therefore perfect for VoiceModel.
I did a prototype to see if VoiceModel would work by first just implementing the say object, which plays a prompt to a caller. First I added a new action in VoiceController called Tropo that accepts an [HttpPost] request. When you are configuring your application on the Tropo platform you will specify the URL in the format http://{Server]/{Application}/{Controller}/Tropo. This action performs the same function as the StateMachine action used for VoiceXML applications, except that it returns JSON in the Tropo format instead of VoiceXML. I tried out the "Hello World" example in VoiceModel on Tropo and it worked perfectly.
With the success of this simple prototype I now have the confidence that this concept will work. I just need to complete the remaining Tropo objects in the WebAPI. Once this is completed you will be able to take your VoiceModel applications and run them either on Tropo or a VoiceXML platform by just specifying the correct starting URL. I think this will be a very useful new feature for VoiceModel. Watch this blog and the VoiceModel Project for progress on this feature.
Another popular telephony platform is Twilio. I believe I could easily extend the VoiceModel framework to support this platform as well. It is my opinion that Tropo is a better platform than Twilio. Twilio just does a better job of marketing. You can read a lively discussion comparing Tropo versus Twilio in the blog post "Tropo vs Twilio – AKA a little more noise for Dave Mcclure". Are you using Twilio? Would supporting Twilio in VoiceModel be a useful feature for you? Let me know your thoughts by commenting in this blog or on the VoiceModel Project.
Tropo is interesting to me because of its pricing structure for putting applications into production in the cloud. With many VoiceXML platforms, like Prophecy, there are some up front costs to deploy your app and the pricing structure depends on the amount of minutes you intend to use. You often have to agree to some minimum minutes that you will use per month. With Tropo it is a simple pricing model. There are no up front costs for going into production, there is just one pricing structure for per minute costs, and there is no minimum usage required . This is especially attractive for putting out voice applications that may have a short life. An example of this might be a survey that you want to provide to customers but you do not intend to run it for any length of time. There are trade-offs. With Tropo you do not get to tailor which speech recognition engine or TTS engine you want to use and it is not as feature rich. But for many apps it serves the purpose well. The other downside is that you use a proprietary API to develop your applications instead of an open standard like VoiceXML.
That last issue of getting locked into a vendor because of proprietary API's got me thinking that VoiceModel could solve that problem. What if the application you developed in VoiceModel could run both on Tropo and any VoiceXML platform. That would be a very powerful feature for developing applications in VoiceModel. To see how this might be accomplished lets take a look at how Tropo works.
Tropo has two methods of developing applications called Scripting and WebAPI. As the name implies, Scripting is a scripting language that works within other scripting languages such as JavaScript, PHP, Ruby, Python, or Groovy. The WebAPI is a RESTful API that exchanges JSON to let the IVR platform know what to do next and for it to return results. I choose to use the WebAPI as the method for integrating VoiceModel to Tropo. When a call comes into the Tropo platform for applications using the WebAPI the system makes a POST request to a URL you configure for your application. In the initial POST request is some JSON that has some session information on the call. The voice application then responds to the POST request with JSON that indicates what to do next. For example, play a prompt to the user. When Tropo completes this request it sends another POST with any results as JSON, and the cycle continues until the application has completed by sending a hangup request. This seems like the perfect scenario for using ASP.NET MVC to implement this protocol and therefore perfect for VoiceModel.
I did a prototype to see if VoiceModel would work by first just implementing the say object, which plays a prompt to a caller. First I added a new action in VoiceController called Tropo that accepts an [HttpPost] request. When you are configuring your application on the Tropo platform you will specify the URL in the format http://{Server]/{Application}/{Controller}/Tropo. This action performs the same function as the StateMachine action used for VoiceXML applications, except that it returns JSON in the Tropo format instead of VoiceXML. I tried out the "Hello World" example in VoiceModel on Tropo and it worked perfectly.
With the success of this simple prototype I now have the confidence that this concept will work. I just need to complete the remaining Tropo objects in the WebAPI. Once this is completed you will be able to take your VoiceModel applications and run them either on Tropo or a VoiceXML platform by just specifying the correct starting URL. I think this will be a very useful new feature for VoiceModel. Watch this blog and the VoiceModel Project for progress on this feature.
Another popular telephony platform is Twilio. I believe I could easily extend the VoiceModel framework to support this platform as well. It is my opinion that Tropo is a better platform than Twilio. Twilio just does a better job of marketing. You can read a lively discussion comparing Tropo versus Twilio in the blog post "Tropo vs Twilio – AKA a little more noise for Dave Mcclure". Are you using Twilio? Would supporting Twilio in VoiceModel be a useful feature for you? Let me know your thoughts by commenting in this blog or on the VoiceModel Project.
Comments
Post a Comment