Why choose Tropo over Twilio
diggz.org
diggz.org
Effective at getting me to open the email, but I always feel deceived when I open it up to see the cookie-cutter mail that they've sent me.
That said, I've been working with Twilio on and off for 2 years and have never received an email like this from them.
Sorry about that, it's an easy fix to remove the RE:
I believe Twilio integrates directly with a single carrier (Level3). Last I checked they use/resell bandwidth.com for most of their calls.
-Jonathan (Voxeo CEO)
Voxeo also works with Bandwidth.com. "Bandwidth.com shares Voxeo's 'All-IP' worldview and as a result is an important voice network partner for us." --Jonathan Taylor, Voxeo CEO
1. having the voice scripts written in Ruby and hosted by Tropo was easier than building a web service to control every mundane aspect
2. Tropo would supply non-U.S. numbers if I needed them
3. Tropo made it easy to do the voice recording and POST it as an MP3
4. Tropo worked out cheaper for my little test service
Some or all of these may now have changed but i'd still give Tropo first choice in any future projects
-Jonathan (CEO, Voxeo)
It's a shame, because it is pretty great. I think the word is finally getting out now, though.
FWIW we're not totally over the moon with Twilio, and I've since discovered freeswitch, which is much more developer friendly and scalable than asterisk.
It's all but persuaded me to roll our own telco connectivity.
Would really love to see Twilio match Tropo in these regards eventually!
<Response> <Say language="es">Es un robot que hablan español!</Say> </Response>
Also have French and Germain. Details here: http://www.twilio.com/docs/api/2010-04-01/twiml/say
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
If you like Freeswitch, you'd probably like Tropo. Tropo lets you program directly in Javscript and other languages, just like Freeswitch.
Tropo also lets you roll your own. You can download Prism, which include the Tropo engine, here:
I've been in the telephony for 15 years now. If I can help with your explorations at all, feel free to email me: jtaylor at voxeo dot com
-Jonathan (Voxeo/Tropo CEO)
1. Cheaper
2. Multiple voices and accents (UK British Male & Female)
3. Use any number as caller ID.
4. Calls during development are free.
5. Recordings are a breeze
6. Voice recognition from a set of options instead of pressing digits (eg. "Say yes, no or repeat").
On the downside, I've found their system wasn't quite as easy to get going with as Twilio, but it is much more powerful.
Twilio have been more visible and active - Tropo seem slightly behind in evangelism and generally pimping their product.
Also not sure if you've seen this, but you can pick from English, French, German, and Spanish accents here: http://www.twilio.com/say
1) I wouldn't say "slightly". 2) Twilio's great at it because Danielle was employee #1 at Twilio. Marketing and evangelism are in Twilio's DNA.
Twilio is great at marketing and evangelism. Twilio is way ahead on that front. That's their DNA.
Voxeo is great at feature innovation and platform implementation. Voxeo is way ahead on that front. That's Voxeo's DNA.
I agree with point "3" though. I use Twilio for an app which sends voice call reminders to other people. But when automatic reminder call goes to these people, it goes from a 1-877 number and many people don't pick up the phone thinking that it's a spam number. Instead if I could call from the number of an original user who sets the reminder, that would be really great.
Point "6" also seem to be great, and I'm sure Twilio will add that.
But somehow, the article coming from Tropo's evangelist is not strong enough or convincing to make a switch from Twilio to Tropo. In fact you did a good job in highlighting some of the technical differences. I think the post lacks these kinds of specifics.
There is a validation that has to be done with the number to make sure you own it, but you should be able to use it as much as you want after that first validation.
Also, I wanted to make sure I understand, what kind of specifics did you feel are lacking in Diggz post? We love to learn how to improve our product and our communication about it. If you are up for discussing it we will give you $100 on Amazon or Paypal for your time. Just email me at jtaylor at voxeo dot com.
-Jonathan (CEO Voxeo)
You said you inquired about Voxeo/Tropo but the pricing you mention above has absolutely nothing to do with Tropo.
Tropo is 100% free for development use - always.
Production Tropo pricing starts at 3 cents per minute with free second-leg (connected) calls, free voice recognition, free high-quality speech synthesis, free 24x7 support, no minimum, and no port limitations.
Prophecy IVR is a completely different service. It's intended for a different customer set, and those customers love the product.
We've got a big release coming that makes Tropo much easier to use. Entirely new documentation, sanded off some of the rough edges on features, added new ones to make some use cases simpler.
I'd love to hear about the specific road bumps that made it harder for you, it would really help us improve our simplicity. We will give you $100 on Amazon or Paypal for your time. If you're interested email jtaylor at voxeo dot com.
edit: to downvoter, i just wanna hear from danielle himself about this qoute, no harm mean
First - Danielle I have the utmost respect for you and the marketing momentum you've been able to build around Twilio. However, saying the "quote is completely fabricated" is itself is fabricated ;) It's not a quote - it's a reference to something you said at ITExpo west this year. Diggz wasn't there, but he (and I) were told by multiple people that you said it.
Voxeo is an extremely open and honest company. I mean extremely. I seriously doubt any single Voxeon would make this up, never-mind multiple Voxeons. It's personally important to me to resolve this because I feel the honor and honesty of Voxeo is being challenged when you say it's "completely fabricated". Are you claiming you said nothing at all like that?
Second, wether you now acknowledge saying it or not… to be frank, in my (and many other web-powered telephony industry vets) opinion it happens to be pretty darn true. Twilio has done a great job focusing on simplicity. Twilio is many great things - but Twilio is not innovative. I'm not trying to be a competitor or a jerk when I say that… I honestly have not seen a single technology innovation delivered by Twlio. If you disagree, please suggest a few and so I and others who have been doing this for ten years can openly and fairly respond.
I'll give you some examples of what I mean - compared to Voxeo. But I want to make it clear that this is not all about Voxeo. You could also make comparisons to TelMe, Bevocal, Telera, Motorola and several others who were around ten years ago. Voxeo is far from being the only company that invented and innovated the web telephony industry ten years ago:
1. Voxeo created and patented most of the technology and concepts Twilio uses today . in 2000, as shown here:
2. Like Voxeo, Twilio makes it easy for any web developer to create telephony applications, with a focus on lower cost and ease of use. Voxeo has done that for ten years, as shown from the archived Voxeo developer web site on August 19, 2000:
Sound like a familiar message?
3. Their are slides in Twilio's 2008-2009 investor presentation which are nearly an exact duplicate of Voxeo's 1999-2000 investor presentation. To be clear, I don't know if Twilio's founders saw our presentation but the business plan concepts are so similar that slides were nearly exactly duplicated. Down to the words and diagrams used.
4. Twilio leveraged "super angels" to help build marketing momentum. Although the term didn't exist back then, Voxeo's angel investors in 2000 included Eric Schmidt (now CEO of Google), Dale Fuller (then CEO of Borland), and David Orfao (then CEO of Allaire) ... they helped us build significant marketing momentum.
5. This is the first Voxeo example app in our docs, circa 2000:
<callxml> <text>Hello World</text> </callxml>
This is the first Twilio example in your docs, ten years later:
<Response> <Say>Hello Monkey</say> </Response>
All marketing BS and propaganda aside: Voxeo and Tropo.com are just way ahead of Twilio when it comes to innovation and features. Everything Twilio has today Voxeo had ten years ago. And Voxeo/Tropo have many features Twilio doesn't: voice recognition, open SIP access, Skype integration, universal API for voice / SMS / IM / Twitter / etc, open source web client access (phono.com), direct Ruby/PHP/Phython/Groovy script language support (no need to force everything into XML and back to get things done)… there is no way Twilio could keep up match Voxeo / Tropo innovation and features, because Twilio is ten years behind from the get-go. And Voxeo is investing more in new innovation and features today than ever.
I and the rest of Voxeo have always tipped our hats to Twilio when it comes to your marketing, modern web developer outreach, refocusing on simplicity, pricing models, etc. Seriously, hats off.
However, the singular thing that bugs me (and other industry vets) about Twilio is how Twilio pretends they invented all these features and is a really innovative company. I thought your comments and "tip of the hat" to Voxeo and Tropo on innovative features at ITExpo west was the first time Twilio has publicly been a bit honest about this. I'm honestly disappointed to see you may be returning to Twilio the party line. I hope that's not the case.
-Jonathan (CEO, Voxeo)
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.
That is very different from saying, as you did above, that "This quote is completely fabricated." (it also wasn't a quote).
I'm not trying to start a flame war here. I like you (and the rest of Twilio) quite a bit. I admired what you said and the goal it represented: Focus on and attack a different market from a different angle than we are. Build on your strengths and acknowledge your weaknesses. I wish more companies would do that. No company can be good at everything.
You did say something very similar to what Diggz referenced (not "quoted"). Then you accused him of outright lying. That's just not cool at all.
1. Fault tolerant: Including the ability to do state-full failover of applications from one PRISM server instance to another.
2. Scalable: Proven ability to scale to over 25,000 calls per server.
3. High performance: Proven ability to scale to over 800 call setups (new calls) per second per server.
4. Standards-based: PRISM implements the Java SIP servlet standards (JSR-289) and Java Media Control standard (JSR-309). PRISM applications can run unmodified on similar platforms from Oracle, IBM, and Redhat - and vice versa.
5. Support: PRISM is backed by a company with guaranteed 24x7 support, under 20 minute response times, over 150 employees, world-wide offices, financial stability, and 10 years of experience.
On top of that, yes, PRISM is often used in the enterprise and by service providers. :)
PRISM is also used for everything we do at Voxeo. All of our products and services, including Tropo, are built on top of PRISM.
PRISM is a highly scalable, reliable, and extensible communications application server. It's a very proven platform and is used by several of the largest consumer and commercial VoIP providers. It's also used in Microsoft's Tellme service and is the foundation of all of Voxeo's products and services.
Asterisk can be painful, but they have a new ground-up project in very-early (pre-beta) stage called Asterisk SCF that is designed to achieve PRISM-like capabilities.
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.
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?
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.
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...
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.
So what's new Twilio can offer here? I have no idea why USV invested in them...
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 / whatever SIP servers, and learn how to program them, and learn how keep them running smooth (Not particularly difficult, but in terms of learning requirements - it's akin to meeting a database + web server for the first time).
Due to the real-time nature of telcos (and I mean that in the traditional clock-synch'd sense of the word) there are additional complications if you want to use a virtualised OS.
You dont need a bunch of servers either. If you are doing more than 200 simultaneous calls ( freeswitch easily achieves this on 1 box ) you shouldnt be looking at these entry level systems; Voxeo, Tropo's parent company has an incredibly powerful platform.
Apache's free and hardware's cheap. Yet Rackspace still manages to run a huge web hosting business.
For some people and some uses, building a web server and hosting it on your home or office network is acceptable. But those that don't count "web hosting" as their core business and want the reliability, security, and stability that comes from having a professional do it tend to hire a company to do it for them.
Like most other things in technology, it's a simple build-vs-buy question. Is it more cost effective and better suited to my needs to build it myself or to buy from someone who's an expert?
Freeswitch and Asterisk are great. I was the emcee at the Freeswitch developer conference last year and we financially support Adhearsion, an Asterisk development framwork. They fill a great niche for DIY telephony. For everyone else, there's hosted services.
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.
Twilio lets a modestly competent web developer program a telecommunications company from their kitchen table in about, oh, six weeks or so. Alternatively, Twlio lets a modestly competent web developer take an existing app and add voice/SMS features to it in about a day. (Have a social site? Want to do SMS notifications when something important happens? You can implement that in four hours.)
--
[1] infrastructure jockey != web developer.
message "something important happened", {:to => '14155551212', :network => 'SMS'}
And then one line of code to hit our session API over http and run the code.
I think what patio11 is referring to is the amount of time it would take for a new developer who's never seen the Twilio API before to get up and running. This includes things like the time to understand the API and documentation. The actual writing of the code is always the easiest part of implementing something.
It takes some time to learn how to use a platform.
It takes some time to code on a platform.
The actual writing of code is easiest when you are doing small applications. However, when you are writing larger applications the coding becomes the larger portion of time.
Today it's easier to learn Twilio than Tropo - largely because Tropo needs better documentation (that's coming very soon). However, I will contend that once you know the platform, Tropo is easier - and much more powerful.
I think that's what others are saying in this thread. We've also heard that from customers who have switched from Twilio to Tropo.
None of this should be surprising to anyone. Voxeo has been doing developer-centric telephony for ten years. Voxeo knows all the little problems and challenges that can come up over time and we've built a platform to address them.
Twilio is new to the industry, they came at things with a fresh set of eyes and were able to "re-factor" the simplicity and usability yet again with that fresh perspective.
I say "re-factor" because it's exactly what we did at Voxeo when we started in 1999. The experience reminds me of Battlestar Galactica: All this has happened before, and all this will happen again.
Our goal is to get a developer who knows nothing about telephony from signup to making their first phone calls and text messages in under 5 minutes.
Thanks for the summary of what Twilio makes possible.
What nivertech (who you responded to) knows and was trying to say is this:
With Voxeo (and others) a competent web developer has been able to create a telecom company in six weeks - or add voice features in less than a day - for ten years now. Voxeo delivered and has grown a completely free web-based telephony developer program since 2000.
And since 2000 over 200,000 developers have used Voxeo to do just that.
This is the Voxeo developer site in the wayback machine archive from August 19, 2000:
Quoting that site:
"our mission at voxeo community is to make it as easy as possible for web developers, service providers, and enterprises to create and deploy applications for an existing market of 1.5 billion telephone users.
existing web developers & services use technologies like Perl, PHP, Cold Fusion, Microsoft ASP and Java Servlets to create web applications for traditional web browsers via HTML. we make it just as easy to use those technologies to create web applications for telephones, using phone markup languages such as VoiceXML, Microsoft WTE, and CallXML."
Here's the juicy part:
"if you have experience creating web applications, this site will help you create and test your first phone application in less than an hour -- without any new hardware or software."
Sound familiar? :)
What Twilio has done that's new is use marketing and hype to convince developers they invented something that was invented by others and available for a decade now. The power of hype never ceases to amaze me.
To be fair, Twilio also did a great job creating more modern developer documentation and refocusing on simplicity. These are things Voxeo had drifted away from as we grew into "the man". In short, we got distracted by million dollar deals with enterprises and carriers. We've continued to invest in our developer community but things got increasingly complex as we added more and more features and options over time.
Our new Voxeo Labs group - and it's Tropo.com service - was created to fix that. We're behind on the evangelism but way ahead on the technology. And I dare say we're getting better at evangelism every week. ;)
-Jonathan
Show me pricing lists and contracts from 10 years ago indicating it was cheap as Twilio was 2 years ago. I can't see anything at http://web.archive.org/web/*/http://voxeo.com :(
I suspect the infrastructure was there for the 'big boys' and that indie devs and 2-3 man shops who wanted this sort of functionality were ignored in favor of 'enterprise' development shops and projects.
OK - rereading your post here - yes, you got 'distracted' by big deals. But it's the focus on getting the basic fundamentals as easy for people to use as possible which has created the Twilio loyalty and fandom they have relative to voxeo/tropo.
Twilio has (imo) about a year to add some more features that people are asking for before people jump ship. They should not waste that goodwill and rest on their laurels. But it's going to be easier for them to grow their success with smaller shops and indies in to something larger as those smaller shops and projects grow to larger needs than it is for 'enterprise'-focused groups to prove to the smaller players that they 'get' the independent developer market.
You can suggest that this is 'just' marketing/evangelism. I suspect it's a bit more - a focused simplicity on getting a few core things down first rather than trying to offer multiple services on day one. That doesn't appeal to everyone, but I think it's helped more than hurt in Twilio's case. Simply by having more options up front you're forcing people to have to learn a lot more about stuff on your terms when making an evaluation. For example, Tropo's APIs - 'webapi' vs 'scripting'. Huh? What are the differences? I don't find an adequate explanation of the strengths/weaknesses of each model.
Both services have their place, but developing a rabid fanbase will serve Twilio better longer term as opposed to pure technical superiority.
I can speak fairly knowledgeably as I headed up all of Voxeo's developer community and support in the early part of this decade (and as employee #1 and co-founder Voxeo). In a pre-social media world, marketing involved a lot of face-to-face contact, primarily at conferences for developers: Cold Fusion, PHP, ASP etc. We held app contests, live coding demos making people's phones ring, sponsored meetups and conference after parties. (sound familiar?) We were out there...just apparently not at the same ones you were at (sorry).
>> Show me pricing lists and contracts from 10 years ago indicating it was cheap as Twilio was 2 years ago.
I honestly don't think any exist...not because they were lost, but because we never charged anything back then..nor have we ever charged developers. For production apps, there's no doubt that the cost of transporting data has dropped dramatically in the past 10 years. What we can do for pennies now, cost dimes 10 years ago. Of course, we also had to walk 10 miles to school, in the snow, uphill, both ways ;-)
>> But it's the focus on getting the basic fundamentals as easy for people to use as possible which has created the Twilio loyalty and fandom they have relative to voxeo/tropo.
You are absolutely correct. There are some things about Tropo that are still overly complex. We're working on that. Fortunately it's easier to simplify features than to add new ones.
>> Twilio has (imo) about a year to add some more features that people are asking for before people jump ship.
I'd tend to agree. By my estimation (based on how long it took them to burn through their first round of financing) That should be right about the same time their latest round of funding runs out. No time for resting on laurels. :-)
Whether you charged developers or not, at some point you charged someone for something.
While free dev accounts are great, I'm still not going to learn a tool and recommend it to clients without knowing if it's something that they can actually afford. Twilio has made it known from day 1 what the pricing is - whether people liked it or not is a different matter! :)
<i>Fortunately it's easier to simplify features than to add new ones.</i>
Possibly in tropo's case it may be. That's not always the case - I would say not even usually the case with software. Witness MSOffice - much easier to add new features than to simplify the interface. The 'ribbon' effort pissed off as many people as it helped. :) Don't give us a tropo 'ribbon' equivalent please!
I am writing this to provide context, not to disagree with you...
Relatively speaking, Voxeo was as cheap 10 years ago as Twilio and Tropo are today.
Everything about this business was more expensive 10 years ago though. The cost of bulk long distance was 8x higher, server costs were about 10x more, bandwidth cost about 10x, server hosting (nothing like EC2 existed) was about 3x more... all costs were much higher then they are today. However, Voxeo's pricing 10 years ago was much lower than every other option available. It was very disruptive.
We did market to reach people like you, that's why we have over 200,000 members in the Voxeo developer community today. And that community is growing faster than it ever has. We clearly didn't reach everyone though.
We have many customers with 100+ employees that started off as 2-3 guys and an idea 10 years ago. The developer focus worked and is the cornerstone of our business. It's how we became the largest platform in the world for telephony apps.
In short the service absolutely was for indie devs, 2-3 man shops and start ups. We had no idea how to sell to large enterprises and service providers back then. It wasn't our DNA. We are developers. I'm a developer. We built it for developers. It was entirely about developers ;)
We took a different approach though. We focused on making standards. We hate lock-in. We hate proprietary. That's why Tropo is an open-source platform. We hate the country-club mentality that you find from legacy vendors like Avaya and Alcatel.
So we lead both the W3C VoiceXML and CCXML standards. Along the way those standards got massive adoption in the enterprise and service provider markets, and the resulting large opportunities pulled us in that direction. We continued to focus on developers, just not at the 100% level we used to.
We created Voxeo Labs to have a new team that focuses 100% on developers. Not to try to "create" a developer focus, but to refine the focus we have always had. That effort is working out great. Like some of the posts here point out, we have our own rabid developers. And we're very quickly getting better at building the fanbase you mention.
Our biggest challenge when it comes to focused simplicity is what we know. We've lived through all the little features and gotchas that need to be addressed as developers scale from the small projects to the larger needs you mention.
When we built Tropo, we included things in it to address those needs and get past those gotchas. We couldn't help ourselves :) The problem is we're solving problems developers don't even know they'll have yet. The end result looks more complex... until it's exactly what you need.
To wrap up, I've never suggested it's just marketing/evangelism. It is also, as you point out, a focused simplicity. We've got some great improvements coming to improve our simplicity while we also continue to provide answers to the feature requirements and challenges we know developers will hit as they scale.
Btw I also hate the webapi vs scripting issue, and I let the Voxeo Labs team know that almost every week ;)
So what else can we do to improve our developer focus and bild that fanbase? How can we get better?
The founder of Zappos is actually Nick Swinmurn even though many people still think it was Tony. Tony probably owns a lot more of Zappos than Nick, but neither of them had anything to do with Tellme.
Mike McCue was the founder of Tellme who most recently departed from Microsoft, and before Tellme he worked at Netscape.
Just to summarize the facts, and in general there is a consensus here:
1.Twilio is easier to get started
2.Tropo has more features
3.Both end up costing around the same.
So I would say, as a developer, just try both the platforms or atleast read through the features and make an informed decision about which platform to go with for your customers as ultimately they are the ones we are trying to service.
edit: If I did run adhearsion/asterisk, what do I just have to connect it to a phone line? Vague on the setup needed to do this...
If you run an asterisk server the easiest way to get it hooked up to the phone network is by setting up a SIP account for it.
How is the pricing on NuGram? Is this it? http://www.grammarserver.com/welcome
I'm finding their descriptions a bit opaque. Do you remember the product name off hand? Do they host it, or do I need to look into learning what an SIP is? :-)
NuBot is the IVR testing product http://www.nuecho.com/content/view/28/147
I'm not sure of the cloud per minute pricing, but they'll likely be pretty responsive on email. They're a good group of people.
Thanks Adam,
That is surely yet another point in favor of Tropo. They test. Using our NuBot Platform, we have load test their infrastructure with several concurrent calls. A few issues came up and Voxeo promptly fixed the issues. Case closed. Tremendous support.
I don't know about Twilio in such regard. A few months back, I have offered Twilio our load testing services but I haven't heard of them so far. Danielle, Jeff, if you read this, drop me a note (pdeschen @ nuecho dot com) and we'll be pleased to load test your infra! :-)
Pascal
From it's companion site, nugram.nuecho.com, you can also download a complete Eclipse-based grammar development environment (NuGram IDE) from which you can upload your grammars to NuGram Server.
Regarding the opacity of the site, maybe we could work on that... We are very open to constructive comments!
--Dominique (Nu Echo's CTO)
http://blog.tropo.com/2009/12/17/advanced-grammar-topics-for...
We don't provide a complete self-service setup process yet We are working on that. Just apply for the free trial and we'll help you bootstrap the whole thing.
--Dominique (Nu Echo's CTO)
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 the actual state of the IVR application over time. Call setup time? Greeting time? Transaction failure? Call setup failure? Moreover, you probably want to get an email or SMS notification whenever a defect occurs (otherwise, what's the point of monitoring?) Plus, you probably also happen to want to get a notification for the alarm restore right? While we are at it, I am sure you want those reports available online in a secure location or as a PDF document.
You get all this with Mirador!
I have received your request this morning through our website and you should have received my reply by now ;-)
What’s in your IVR application monitoring report? http://blog.nuecho.com/2010/12/14/whats-in-your-ivr-applicat...
Enjoy!
The best thing, this is done remotely like a real customer calling in taking into account outside influences you cannot test from the inside only.
1 to hundreds of calls are placed that exercise the system as many times per hour that is needed, and each call is being checked for and reported back on call quality, availability, times at each step, proper greeting and what the customer feels is important to know.
They offer a trial as well if interested. http://www.iq-services.com/heartbeat.asp
I didn't know who the author was prior to this post but from his about page he's the co-founder of Voxeo so this post is hardly impartial. He can write whatever he wants on his blog obviously, but keep that in mind. Comments on the site were also moderated preventing responses from some people.
It is not true that we only work with one carrier. We work with a variety of carriers to maximize our capabilities, geographic reach and redundancy. Twilio works with most of the same carriers as Google Voice.
In regards to prank calling, every phone service is used for pranks, Tropo included. In our case, it's a byproduct of making it easy for any web developer to get started in minutes. However, we've put in place safeguards (most notably validating outgoing caller IDs before they can be used) to minimize these types of activities.
We pride ourselves on support. We monitor Twitter constantly, we have people in IRC all the time (set office hours is just a focused discussion topic), and we try to respond to emails and forum posts as fast as possible. We have a team of people scouring Stack Overflow, Hacker News and events all over the country helping developers with their questions, related to Twilio OR NOT. Go find any blog post written about Twilio and see how quickly we responded. We answer the phones when you call, though we have some area to improve in that regard. We're actively working on it.
We support developers like nobody else. We feature them on our site in our Gallery http://www.twilio.com/gallery, we tweet about them, we blog regularly about what our customers build, we have a weekly developer contest to reward cool new apps and we generally go to great lengths to help promote what developers and startups are building using Twilio. We exist to empower you. We'd much rather talk about the cool problems real working developers solving then toot our own horn.
Everyone here knows how good EC2 is, I don't think I need to defend that issue. It's working wonderfully for us. We don't have any capacity or other issues related to our infrastructure. On a more general capacity note, we have yet to hit a limit of what we can handle, and we've worked on some huge projects. Go look at our customer list. These companies would not work with us if we couldn't handle their demands: http://www.twilio.com/gallery/customers These are just scratching the surface. There's another class of customer that's even bigger but doesn't like being talked about publicly.
We're hyper-focused on web developers. We (I'm a web dev myself) don't care about complicated telephony issues. We're too busy solving problems. Twilio works the way we work. Before I worked at Twilio I struggled trying to implement features that took me minutes once I discovered the Twilio API. It already spoke what I knew already and that's just simply HTTP.
We are not the right solution for every single developer; nothing is. But we have a rock solid solution that's working for over 20,000 developers and growing rapidly. If you're conflicted, try both services out for yourself. Don't listen to either company, just see for yourself which you like better. And if we can help in any way, we're listening.
If you have any questions or concerns, feel free to email me directly at jsheehan@twilio.com
(a) Speed of SMS deliverability (# of SMS that can be delivered per minute)
(b) Confirmation of SMS (i.e. can we be sure that the SMS was indeed delivered)
(c) Availability of phone numbers in different area codes
From a shortcode, there's no limit. And Tropo's connected directly to the SMS carriers, so you can deliver at a significant rate.
We don't provide delivery confirmation of SMS today. That's coming soon however. One thing to keep in mind, though, is that delivery can only be confirmed to the carrier. Handset delivery receipts are flaky at best. Not all handsets support sending delivery receipts, those that do often allow the user to disable it, and some carriers will block the receipt.
We have phone numbers in about 280 area codes and 41 countries. Not all of the area codes are available in the UI yet, so if you need one and don't see it, send an email to support and we'll hook you up.