Why choose Tropo over Twilio(diggz.org)
diggz.org
Why choose Tropo over Twilio
http://www.diggz.org/index.php/2010/12/01/why-choose-tropo-over-twili/
11 comments
If Tropo can do anything to help you in China please let us know. Asia is a key market for Voxeo/Tropo. We have two data centers there (Singapore and Hong Kong), as well as an R&D, support, and sales team with about a dozen people in Beijing. Feel free to email me at jtaylor at voxeo dot com.
hey curious to know what you mean about "Chinese service sucking" since we're not international yet... are you referring to outbound calls to Chinese numbers, or something else?
Outbound calls to a Chinese number had a failure rate of about 50% (failed with a couple of different error messages, can't quite remember what exactly they were anymore, although I remember thinking they didn't seem particularly relevant... like claiming the number dialed was busy even when it definitely wasn't, etc). Also sometimes the calls would go through but then disconnect immediately after I picked up and I would get billed for them. Basically, my experience calling China was that the service was totally unreliable and a bit expensive (by expensive I mean I was unhappy being billed for dropped calls).
Thanks, there are different challenges with international routing by country and by receiving carrier. I'll definitely pass this information along, and if you have specific calls (I'd need your Twilio account ID to look at them, better sent via email) that will help a lot, too. We know international support is important to developers everywhere, and we're definitely working on it.
International is hard. I know from experience. That's where Tropo has one clear advantage over Twilio. Tropo is built on the Voxeo network, which has ten years of international experience, is deployed world-wide (seven data centers), and integrates directly with most of the carriers around the world.
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)
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)
To correct a misconception, Twilio works with a variety of carriers, including Level3 and Bandwidth.com. Much like Google Voice, we work with a plurality of vendors for redundancy, geographic coverage, etc..
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
http://bandwidth.com/about/read/flexNetwork.html
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
http://bandwidth.com/about/read/flexNetwork.html
So is the alternative/your expectation that they send each developer a custom email? If Twilio was to do that, that doesn't sound practical, scalable or smart.
The alternative would be to not include "RE:" in the subject, which makes it looks like a reply to an earlier thread. The subject is subject enough already. Don't manipulate it with a "RE:" to imply something more.
That said, I've been working with Twilio on and off for 2 years and have never received an email like this from them.
That said, I've been working with Twilio on and off for 2 years and have never received an email like this from them.
Looks like this is a bit of email usability fail on our part. When you first sign up for Twilio, you receive an email with the subject line "Welcome to Twilio... Learn to Build Your First Phone App in Less than 5 Minutes" and then 7 days later we send you an email introducing our CEO that says "RE: Welcome to Twilio..." in the subject line. The goal was that these would get threaded together, but they don't since the from is "Twilio" in the first and we use real names in the other emails (the one from Jeff says his name, the one from me says my name, etc.)
Sorry about that, it's an easy fix to remove the RE:
Sorry about that, it's an easy fix to remove the RE:
Thanks for addressing that.
Fair enough. The use of Re: is def a bit manipulative/not truly representative.
Interesting, maybe it's something they rolled out more recently for their newer members. I only started with them a couple months ago.
My more pragmatic reasons for choosing Tropi over Twilio:
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
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
Thank you for a great summary of Tropo advantages!
-Jonathan (CEO, Voxeo)
-Jonathan (CEO, Voxeo)
Do you guys consider giving sms bulk discount? Like a tiered pricing?
We're already priced below the bulk price of most other vendors. What sort of volume do you have? Feel free to drop me an email at [email protected]
Every time I ask, "Why don't you use Tropo?" I invariably hear "What's Tropo?"
It's a shame, because it is pretty great. I think the word is finally getting out now, though.
It's a shame, because it is pretty great. I think the word is finally getting out now, though.
We use Twilio, and I hadn't heard of Tropo.
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.
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.
Freeswitch rocks. Great stuff, from a great team too.
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:
http://www.voxeo.com/prism/
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
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:
http://www.voxeo.com/prism/
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
If there's anything we can do to make your Twilio experience better, I hope you'll email me, I'm [email protected]
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 eventually!
Would really love to see Twilio match Tropo in these regards eventually!
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 <Say> verb, we actually support Spanish TTS... you just have to specify the language and you'll get the right accent, like this:
<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
<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
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
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
Thank you! We are working our actual and virtual asses of to make Tropo the best developer platform for all communications applications (not just voice and sms: also IM, Twitter, telephony-in-web-clients, etc). We are also working hard to get the word out!
-Jonathan (Voxeo/Tropo CEO)
-Jonathan (Voxeo/Tropo CEO)
Absolutely agree that Tropo is better than Twilio. Here are my reasons:
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.
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.
Twilio have been more visible and active - Tropo seem slightly behind in evangelism and generally pimping their product.
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.
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.
Absolutely agree.
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.
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.
Hey Alex, not sure if you've logged into your Twilio account lately, but we reduced prices a couple months back so inbound calls are now $0.01/min, SMS is $0.02/msg, and phone numbers are $1/domestic or $2/toll free. We've yet to see someone actually blow through the whole $30 in trial credit, but if you run out and need more just let us know at [email protected]
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
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
I'm not sure why you're saying it's cheaper. As Danielle mentioned, the prices are actually very less. And as a developer, every penny difference counts. Also they give $30 credit, which is more than enough to "try and play" and release your app to production.
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.
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.
On point #3, you can set the outgoing caller id to the user's phone number after you verify it by posting to the OutgoingCallerIds List Resource: http://www.twilio.com/docs/api/2010-04-01/rest/outgoing-call...
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.
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.
Hi - Tropo should cost about the same as Twilio depending on your use case, but Tropo does alot more than Twilio for a roughly equivalent price. For example. Twilio just does SMS, Tropo does SMS and IM. Tropo adds speech recognition and higher quality speech synthesis, etc.
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)
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)
[Edit: my info here was incorrect as it was based on a completely different platform. Removing this to prevent confusion.]
Woah there, your post is misleading and I want to make sure no one is confused as a result.
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.
http://tropo.com
Prophecy IVR is a completely different service. It's intended for a different customer set, and those customers love the product.
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.
http://tropo.com
Prophecy IVR is a completely different service. It's intended for a different customer set, and those customers love the product.
Thanks for the info. Looks like I should re-evaluate things as at the time Tropo seemed to be a coming-soon/developer-only service that didn't have details around production pricing nailed down. The Prophecy IVR info scared me into thinking that Tropo might have similar limitations.
That's a great summary. A good analogy is that Tropo is 30% harder to learn than Twilio... but it can do 300% more than Twilio.
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.
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.
"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
edit: to downvoter, i just wanna hear from danielle himself about this qoute, no harm mean
Danielle said this during the API panel moderated by Thomas Howe at ITExpo West in October this year. When asked of the differences, she said that Twilio was focused on growing the market and making it easy for web devs instead of trying to keep up with Tropo on features. Many itexpo sessions are recorded. There may be audio or video of this somewhere.
That is very different from saying we'd never be able to keep up on features.
It's stretched?
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.
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.
I don't know how saying "Danielle Morrill said" is not a quote. But let the audience here, and the future, judge whether or not we "keep up". I think time will tell.
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.
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.
I'm Voxeo's CEO.
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:
http://bit.ly/voxeo-patent
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:
http://bit.ly/voxeo-dev-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)
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:
http://bit.ly/voxeo-patent
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:
http://bit.ly/voxeo-dev-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)
Source? That sounds unlikely.
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.
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.
>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?
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?
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.
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.
>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...
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...
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.
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.
This is absolutely true. I think Tropo does as well.
No, Tropo uses Prism, Voxeo's enterprise grade SIP application server: http://www.voxeo.com/prism/. Tropo's application layer is also open source and will run on any SIP servelet server.
Is 'enterprise grade' referring to a specific technical claim made by Voxeo or more of just a substitute for 'often used in the enterprise'?
Thank you for asking. "Enterprise grade" can be a vague marketing term. This is what Voxeo means when we say PRISM is "enterprise grade":
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.
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.
as akalsey said, Tropo is built on PRISM.
http://www.voxeo.com/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.
http://www.voxeo.com/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.
Twilio always seems like a hack to me. Once VoiceXML/CCML was hot market with many startups competing, with biggest exit being Tellme acquired by Microsoft for $800M (same people who founded Zappos).
So what's new Twilio can offer here? I have no idea why USV invested in them...
So what's new Twilio can offer here? I have no idea why USV invested in them...
So what's new Twilio can offer here?
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.)
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.)
I implemented "text me when someone orders" in about 25 minutes of time, from clicking "sign up" to "cap deploy." Super awesome.
I am far from being modestly competent as a web developer[1] and I was able to hack a voice menu in 30 minutes, in Lisp, before I knew XML.
--
[1] infrastructure jockey != web developer.
--
[1] infrastructure jockey != web developer.
With Tropo, you can implement that in less than four minutes - it's two lines of code.
Ruby:
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.
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.
This is pretty disingenuous. It's the same exact two lines of code to do this in Twilio. Yes if you know ahead of time what those two lines are then you can type them in less than four minutes. Same goes for Twilio.
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.
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.
You make a great point, but it's also somewhat disingenuous ;)
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.
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.
Fair enough. But if it takes 4 hours to figure out how to write these two lines of code, something's wrong. Documentation, complicated and confusing API, hard onramp to get started...
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.
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.
I'm Voxeo's CEO.
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:
http://bit.ly/voxeo-dev-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
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:
http://bit.ly/voxeo-dev-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
If it was really that easy a decade ago why was there no marketing done to reach people like me?
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.
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.
>> If it was really that easy a decade ago why was there no marketing done to reach people like me?
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. :-)
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. :-)
Thanks for the reply :)
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!
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!
As Voxeo's CEO, I guarantee there will be no Tropo Ribbons ;)
Hi - and thank you sincerely for the points you made.
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?
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?
FYI, the people who founded Zappos did not create Tellme. You're probably thinking of Alfred Lin who actually joined Zappos as the CFO much later (after Tony), and happened to be a VP at Tellme. At least according to Tony's book, he was a PhD student before he joined Zappos.
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.
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.
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 / 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.
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.
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 1 box ) you shouldnt be looking at these entry level systems; Voxeo, Tropo's parent company has an incredibly powerful platform.
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.
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.
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.
Unfortunately, you can't get SMS when you do it yourself using SIP/FreeSwitch. These companies have made the deals with the individual telecom providers to do that for each of their DID numbers.
Well, you could it's just not easy. A GSM modem attached to the server would do the trick.
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.
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.
What I meant is that both Tellme and Zappos got investments from Venture Frogs
http://www.vfrogs.com/investments.html
http://www.vfrogs.com/investments.html
I think the comments are becoming a little personal in this post. Thats in one way good as that shows there is a developer attachment(fanboyism :)) to both the platforms.But the fact of the matter is that both Twilio and Tropo are trying to solve the same problem along with many other web to telephone companies.Also,I think Teleku, acquired by Voxeo takes a Twilio kind of approach.
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.
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.
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. Anyone have other solutions that are reasonably simple?
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...
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...
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 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 ;-)
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 ;-)
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!
What’s in your IVR application monitoring report? http://blog.nuecho.com/2010/12/14/whats-in-your-ivr-applicat...
Enjoy!
Check out IQ Services out of Minneapolis, Minnesota provides a 100% service model with no hardware or software to purchase or the need to train your employees. This service comes with 24/7 notifications and a online portal where you can listen to all monitoring and notification calls that have been placed.
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
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
NuGram makes a product designed for just that. You could certainly build something yourself using either a hosted service like Tropo or using Asterisk, but using something purpose built may work better. We use NuGram to test things.
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.
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.
[deleted]
Thanks for the recommendations!
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? :-)
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? :-)
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.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)
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)
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...
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.
Grammar Server is a product they make for building and managing speech recognition grammars. It's pretty awesome, too, and any recognition grammars you create can be used with Tropo.
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.
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.
Disclaimer: I'm one of Nu echo's founders and lead architect for our IVR testing and monitoring tool suite (NuBot and Mirador).
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
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
The product you are looking for is Mirador, from Nu Echo: http://www.nuecho.com/mirador
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)
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)
I work at Twilio and I wanted to clear up a couple misconceptions here for the record.
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 [email protected]
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 [email protected]
Has anyone compared Tropo and Twilio in these 3 areas:
(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
(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
SMS delivery from regular phone numbers is rate limited by the carriers. Tropo throttles you to 10 messages per minute to keep inside carrier guidelines.
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.
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.
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.