Live data from Hacker News

Why choose Tropo over Twilio

diggz.org

91–100 of 102 posts

Re: Why choose Tropo over Twilio

#91
post #23

"Twilio would never be able to keep up with Tropo on features" -Danielle Morrill, Twilio head marketing edit: to downvoter, i just wanna hear from danielle himself about this qoute, no harm mean

This quote is completely fabricated.

I was on the forum in October, representing Tropo, with Danielle at ITExpo West in LA moderated by Thomas Howe (http://thethomashowecompany.com/). Danielle did make the statement that Twilio could not, and would not, catch up with Tropo on features. Instead, Twilio would focus on simplicity for the broad web developer community.

I respect Danielle and Twilio for making this statement at the time. As it is clear today that Twilio has a wide gap with Tropo on features. Twilio's focus on their core strength, simplicity, was smart. 37Signals has pioneered the idea of less is more with great success (albeit with an eye to staying private without VC funding).

The issue is, I think Twilio has come to the realization that to compete in this space they need more depth of capability. Further, the ITExpo statement was made before Twilio received their latest round of funding. They may very well have changed strategy and now regret having made this statement.

It is much easier to close the gap on simplicity than it is a wide feature gap. We are working regularly to make Tropo simpler, while maintaining its deep feature set. We are built on a platform, PRISM, that allows us to focus on the platform features rather than internals allowing us to innovate rapidly.

A Twilio individual confirmed at CloudCamp QCon in San Francisco that they are working to replace Asterisk (http://asterisk.org) as their key telephony engine. Further evidence of this is that Twilio, for the first time, is working hard to hire telephony experts. Whereas previously they were proud that they did not have telephony experts in-house and would actually plug this as a benefit.

It will continue to be hard for Twilio to catch-up to Tropo, given that they are having to spend time replacing the core fabric that they built their platform on. I suspect that they are most likely targeting Freeswitch (http://freeswitch.org) since Asterisk SCF (http://www.asterisk.org/asterisk/scf) is still a nascent project. I wish them luck with that, as replacing your core telephony engine is no trivial task.

Re: Why choose Tropo over Twilio

#92

Earlier quoted context omitted.

NuGram (www.grammarserver.com) is a hosted platform used to host and share speech recognition grammars (both static and dynamic, i.e. grammar templates) for use by hosted IVR platforms (Tropo, Voxeo Prophecy, etc.) It's totally free, although it's not really meant for production use as of now. If you need it in production, please contact me at dominique DOT boucher AT nuecho DOT com. From it's companion site, nugram.…

Here is a blog post on Tropo's blog that explains how to use NuGram Server from Tropo. http://blog.tropo.com/2009/12/17/advanced-grammar-topics-for...

Yes, this is a great example of how we focus Tropo on making things easy. But then also let you do the complex things like advanced grammars for speech recognition when you need to. Simplicity mixed with depth of features.

Re: Why choose Tropo over Twilio

#93
post #66

Twilio uses Asterisk ? Is this true? If so my respect for both their technical chops and pain tolerance went up...

Yes, to date Twilio has used Asterisk along with OpenSER. Asterisk has its place, as I was personally involved in Adhearsion (http://adhearsion.com) and now Voxeo Labs sponsors the project. The place for Asterisk today is not for providing large scale distributed telephony services. Simply the wrong tool for that, which Twilio has learned the hard way.

This is why Digium has created a new project: Asterisk Scalable Communications Framework (SCF - http://www.asterisk.org/asterisk/scf). Although Asterisk SCF is still in prototype stage and 12-18 months from a fully baked alpha. An interesting approach, but not here yet.

Folks from Twilio have confirmed they are trying to move away from Asterisk, I suspect to Freeswitch. While Freeswitch has better scale, it suffers from some of the same fundamental architectural issues Asterisk has for large distributed telephony applications.

Full disclosure, I am the VP of Innovation at Voxeo Labs, the group responsible for Tropo. Further, I was invited by Digium and attended their closed discussion and launch of the Asterisk SCF platform in Huntsville last spring.

Re: Why choose Tropo over Twilio

#94
post #12
post #6

Earlier quoted context omitted.

I kind of agree. Although I think the underlying assumption is that it's an infrastructure as a service play, and so Twilio et al are creating value. Obviously their target market is the web app developer crowd. To do it yourself you need to line up your outbound SIP providers, inbound DID providers (not one and the same once you dig into the details), then you need to operate a bunch of Freeswitch / Asterisk / whate…

I get your point, but feel you are overplaying the difficulty. You can code in plain ol javascript on freeswitch to create complex inbound and outbound comms apps in a couple of hours. Plug it into a sip provider ( i use sipgate ) and there is nothing more complex to it. Far far cheaper too. You dont need a bunch of servers either. If you are doing more than 200 simultaneous calls ( freeswitch easily achieves this on…

One box? One box is never a good idea for an application that is relied upon. You need to have redundancy (geographic even better), load-balancing, etc.

Sure, you may roll your own anything, but you are better off outsourcing much of that to cloud providers today. Freeing you to focus on your application that provides value to your users, not worrying about how to properly architect and scale telephony solutions.

Re: Why choose Tropo over Twilio

#95
post #66

Twilio uses Asterisk ? Is this true? If so my respect for both their technical chops and pain tolerance went up...

Yes, to date Twilio has used Asterisk along with OpenSER. Asterisk has its place, as I was personally involved in Adhearsion ( http://adhearsion.com ) and now Voxeo Labs sponsors the project. The place for Asterisk today is not for providing large scale distributed telephony services. Simply the wrong tool for that, which Twilio has learned the hard way. This is why Digium has created a new project: Asterisk Scalable…

>Simply the wrong tool for that, which Twilio has learned the hard way.

Citation from something they said, or just deducting this the same way I did? (experience with Asterisk...)

>While Freeswitch has better scale, it suffers from some of the same fundamental architectural issues Asterisk has for large distributed telephony applications.

What are the same 'fundamental' architectural issues? They've seem to taken quite a different approach, or do you just feel C is the wrong way to go for a highly concurrent, scalable system?

Re: Why choose Tropo over Twilio

#96
post #95

Earlier quoted context omitted.

Yes, to date Twilio has used Asterisk along with OpenSER. Asterisk has its place, as I was personally involved in Adhearsion ( http://adhearsion.com ) and now Voxeo Labs sponsors the project. The place for Asterisk today is not for providing large scale distributed telephony services. Simply the wrong tool for that, which Twilio has learned the hard way. This is why Digium has created a new project: Asterisk Scalable…

>Simply the wrong tool for that, which Twilio has learned the hard way. Citation from something they said, or just deducting this the same way I did? (experience with Asterisk...) >While Freeswitch has better scale, it suffers from some of the same fundamental architectural issues Asterisk has for large distributed telephony applications. What are the same 'fundamental' architectural issues? They've seem to taken qui…

Well, I shared a taxi from Astricon to the airport in Phoenix in 2009 with two founders of Twilio. This was after their presentation on Asterisk at Astricon:

http://www.slideshare.net/twilio/reinventing-the-dialplan-sl...

Plus they have said publicly in other places that they built upon Asterisk.

As for Freeswitch. It is a great platform. Both Freeswitch and Asterisk may be made to scale, but it is not trivial and takes a fair amount of time and resources to do so and then to maintain over time. The issue for both of them is that the applications and media services tend to run in the same process. Digium's answer to this is SCF which is now under active development.

The approach we take (and others like Oracle, JBoss, Avaya, etc) is to deploy apps in SIP Servlet containers (Java) and your media in dedicated media servers (C/C++ for example). Employing a clear demarcation between application logic and media processing using MRCP (http://bit.ly/32Bnpu) between them.

Now, of course Freeswitch does have 'Mod unimrcp' (http://bit.ly/hmqvdq) which may be used to talk to our media servers (http://bit.ly/f9lUH3) and turn Freeswitch into an application platform. But when most people think of Freeswitch, they think of the equivalent of Asterisk and deploy that way.

Re: Why choose Tropo over Twilio

#97
post #95

Earlier quoted context omitted.

>Simply the wrong tool for that, which Twilio has learned the hard way. Citation from something they said, or just deducting this the same way I did? (experience with Asterisk...) >While Freeswitch has better scale, it suffers from some of the same fundamental architectural issues Asterisk has for large distributed telephony applications. What are the same 'fundamental' architectural issues? They've seem to taken qui…

Well, I shared a taxi from Astricon to the airport in Phoenix in 2009 with two founders of Twilio. This was after their presentation on Asterisk at Astricon: http://www.slideshare.net/twilio/reinventing-the-dialplan-sl... Plus they have said publicly in other places that they built upon Asterisk. As for Freeswitch. It is a great platform. Both Freeswitch and Asterisk may be made to scale, but it is not trivial and ta…

>The approach we take (and others like Oracle, JBoss, Avaya, etc) is to deploy apps in SIP Servlet containers (Java) and your media in dedicated media servers (C/C++ for example).

Which makes sense for IVR or other media heavy applications. However, Twilio seems to get a lot of people using it for call tracking and click to call...shouldn't touch a media server unless (and I have heard of people doing this) they use media to conference two people....

But, perhaps those aren't the kinds of applications leading to scaling problems...

Re: Why choose Tropo over Twilio

#98
post #97

Earlier quoted context omitted.

Well, I shared a taxi from Astricon to the airport in Phoenix in 2009 with two founders of Twilio. This was after their presentation on Asterisk at Astricon: http://www.slideshare.net/twilio/reinventing-the-dialplan-sl... Plus they have said publicly in other places that they built upon Asterisk. As for Freeswitch. It is a great platform. Both Freeswitch and Asterisk may be made to scale, but it is not trivial and ta…

>The approach we take (and others like Oracle, JBoss, Avaya, etc) is to deploy apps in SIP Servlet containers (Java) and your media in dedicated media servers (C/C++ for example). Which makes sense for IVR or other media heavy applications. However, Twilio seems to get a lot of people using it for call tracking and click to call...shouldn't touch a media server unless (and I have heard of people doing this) they use…

I can not speak to the use of conferencing for that scenario.

But, if you are allowing flow to happen after you have dialed a user in Asterisk ('g' option on the Dial command in Asterisk - http://bit.ly/575c6) and the dialed party hangs up, I believe you must be in the media stream.

Re: Why choose Tropo over Twilio

#99
post #31

I was looking at creating an IVR monitoring tool. I would like to 1-make a call every hour, 2-record the response, and ideally 3-verify the response matches the expected. Thoughts? It looks like twilio and tropi might be able to do this (although I wasn't sure they weren't more focused on inbound), but the 1 cent price is prohibitive for what people might pay per-month especially at higher monitoring frequencies. Any…

Disclaimer: I'm one of Nu echo's founders and lead architect for our IVR testing and monitoring tool suite (NuBot and Mirador). Our Mirador IVR application monitoring service is exactly what you are looking for. It is one thing to regularly call a given number - which can indeed be hacked quite easily using either Tropo, Asterisk, etc, it is another thing to send daily, weekly, monthly and yearly report to reflect th…

For those interested in IVR monitoring services, you should check my recent blog post where I describe what should be in a good monitoring report.

What’s in your IVR application monitoring report? http://blog.nuecho.com/2010/12/14/whats-in-your-ivr-applicat...

Enjoy!

Re: Why choose Tropo over Twilio

#100

Earlier quoted context omitted.

We've been experimenting with Twilio for the past few months, have some proofs of concepts up and running, but in the end it seems like we will launch with Tropo instead. We're based in Puerto Rico, which even though is technically in the US, we can't get local numbers through Twilio. It also helps that Tropo has TTS in spanish and other languages. Would really love to see Twilio match Tropo in these regards eventual…

Hey Hector, thanks for this feedback I'll check with the team on the status of Puerto Rico phone numbers. Regarding TTS, you might want to take a closer look at the Twilio verb, we actually support Spanish TTS... you just have to specify the language and you'll get the right accent, like this: Es un robot que hablan español! Also have French and Germain. Details here: http://www.twilio.com/docs/api/2010-04-01/twiml/s…

Thanks for the followup - I'll check this out. I'm not sure how Tropo got the PR numbers, as Google Voice and Skype have the same issue - something about the local telecoms.

If anyone at Twilio needs help when dealing with the PR numbers/needs telecom contact info/whatever, send me an email to anything @ my username dot com

Post reply on HN