Voxeo’s Tropo – Following the footsteps of VoicePHP

Following the footsteps of TringMe’s VoicePHP, Voxeo announced Tropo – a platform to allow developers to write telephony applications in PHP, Ruby, Javascript and Python. Way to go Voxeo!!!  

This was expected – take a step back and think about it& a few points are obvious:

VoicePHP has created tremendous buzz in developer community. Developers and enterprises like it alike due to simplicity and natural way of programming. As I predicted earlier, companies will come to this kind of platforms rather than staying with messy VoiceXML.  

Although, companies like Voxeo resisted VoicePHP approach earlier (see Jonathan’s comment on GigaOM’s coverage about VoicePHP being non-standard, REST etc), at the same time they found worthy competitor in VoicePHP and they realized that they need to leave the dying ship and move onto something that is truly a technology that developers will use. VoiceXML companies have no option but to create platforms similar to VoicePHP to stay in the game.

What does this mean when such a big VoiceXML companies are following the approach proposed by VoicePHP ? – Simply that VoiceXML is indeed dying if not dead already! Voxeo just endorsed this fact by launching Tropo.

It certainly is a welcome addition for developers.


RoyJuly 27th, 2009 at 11:04 pm

I was playing around with the voicePHP and look at the developer API section. That’s very cool stuff. But, is there anyway to change the speed??

Kris subramanianJanuary 15th, 2010 at 12:00 pm


I have been following TringMe for some time and have even followed your work on VoicePHP. Now Voxeo is following suit to build a development platform using conventional programming languages. But what does this mean to speech platform nuetrality ? The point of coming up with VoiceXML standards was to make sure one can change vendors without changing the application.

Now, my company HummingBytes does exactly what you are doing. Development platform for writing voice applications in C# and other microsoft languages. But at the same time we provide a VXML gateway !!! This is taking a 2-faced approach to the VXML or non-VXML issue. Keeping both parties happy, I guess.

Anyway, my take on VXML is it is way too complex and most of the time developers use some higher level language to generate the VXML payloads. So rather than making VXML more complex and adding more standards, it would be better the put the logic in higher level languages. But coming up with a PHP development platform or the Tropo platform …. I am not so sure there where we are going with that one ….


Leave a comment

Your comment