akalsey

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.

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.

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.

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.

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.

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.

Jeff,

His name's David Wilkie (not betraying any confidence - he lists his name in those email threads he posted).

I don't know him personally, but he's been a regular in our IRC channel over the last couple of months. I believe he's a web developer living in Vietnam. Why do you ask?

There's lots of do it yourself ways to do SMS. You can also grow all your own food, but grocery stores tend to be the more popular option.

Companies choose to work with an SMS provider because they don't want to have to solve uptime, scale, and service issues themselves.

When you're small, running your company on a web server under your desk connected to your cable modem probably works just fine. Doing the equivalent with SMS might make sense at that stage, too. As you grow, your needs change.

One thing to note is that in the US, "unlimited" plans aren't actually unlimited. Read the fine print on your contracts. Carriers define a limit to the number of messages they consider to be reasonable use. It's a soft limit, so they don't immediately block or ban you for going over once in a while. But if you do it consistently, they'll start to charge for the overage.

I'm Tropo's product manager. We've got quite a few companies using Tropo in significant capacity. In fact, because of our ability to scale and telephony expertise (Tropo's a product from Voxeo, the largest worldwide voice application host), we regularly see customers switch from other providers to Tropo.

>> one end of the phone connection could be hosting in a web app via flash/silverlight.

Have you seen Phono? http://phono.com/ - It does exactly what you're describing. Phone in the browser, talking to a SIP backend.

Or maybe you'd like to build the next Skype?

For now, Phono works with a Voxeo backend (either the enterprise stuff or Tropo, the cloud telephony API). The intent is to allow a developer to create their own backend platform that works with Phono. We'll release the spec for that once the API has settled in and we're sure there's no significant changes needed.

Tropo's pricing is at http://tropo.com/pricing/ and start at 3 cents per minute. Voxeo's other products are based on amount and type of usage and you'd want to contact our sales guys to get a quote. sales@voxeo.com should work for that.

Any implementation right now would be pretty early. The live media capture parts of HTML5 aren't fully-speced out yet.

http://dev.w3.org/2009/dap/camera/

With any luck, some browsers will form a defacto standard that solves the outstanding questions long before the HTML5 group finishes.

Among other things, it doesn't yet define what codecs would be used in the audio capture. There's also a lot of comments in the draft that amount to "we'll figure out how this part would work later."

http://dev.w3.org/2009/dap/camera/ is probably a better link if you're interested in this stuff.

Phono is intended to be a unified jQuery API for real time communications (audio, video, chat, screen sharing). The Flash movie is an implementation detail -- the API is intended to be implementable with other media capture methods when they're available, including HTML5.

Java's security model is meaning a HUGE Java applet to do this. And a custom plugin requires that you get people to install it. Works if you're Google (that's how they do Voice in Gmail), but probably not if you're Joe's Bait Shop wanting to add a click to call application.

We use a tiny Flash movie to capture the microphone, since Javascript can't do that part. We'll be adding an option for a Java applet later, and once HTML5 has microphone support, we'll get that in there, too.

Thanks! Let us know if you use Phono for anything. Would love to see what you come up with.

We fixed an issue this morning where sometimes the Flash microphone permission window wasn't showing up. Try it again and it should work for you.

Javascript can't capture the user's microphone directly. So Phono uses a tiny Flash or Java widget to do that part. The rest is all JS.

We're heading an HTML 5 working group on voice in the browser, and once HTML5 has mic support, Phono will use it.

Are you calling a US number? The site says that free calls are only supported to US numbers.

I'd love to hear what it is you don't like about Tropo's API.

Also, what IM issues did you have? IMified's tech is what's driving the Tropo IM integration, and I'm one of the IMified founders, so I can probably help you with you with that.

Total time to create the app itself was about 6 hours. We spent more time on the web site and the video than we did the app. :)

Key quote from the article... "their strategy seems to have revolved around buying second-tier applications and frittering away those startups’ talent and userbases."

Yes, Tropo does international voice and SMS. We've got numbers in 36 countries and speech recognition in 9 langauges.

If you buy a number from us outside the US, we can't do SMS on that yet, but we're working on it. In the meantime, feel free to send texts to and from anywhere from your US number. We won't even charge you any extra for the international sending.

Teleku is now owned by Tropo and as such can do international SMS as well. CloudVox doesn't do SMS worldwide, but I was talking to one of their founders recently and he mentioned they're working on it.

One thing that's always frustrated me about these sort of apps is that I don't actually want every business card I pick up at a conference to become a contact. I want to collect the information electronically, but I don't want to stuff my contacts with people I'm not regularly contacting.

Also see Unbounce. (Not connected with the company, just a customer of theirs).

http://unbounce.com/

Patents are largely useless if you're small. They're very expensive to get, and once you have them even more expensive to defend. Moreover, a defensible patent is so narrow in scope that it provides very little protection by itself. Someone makes a small change to your idea and bypasses the patent entirely.

If your idea is good and you execute well, you have little to fear from large competitors. The larger the company, the harder it is for them to innovate. They're protecting their revenue streams and have less appetite for risk.

They'll wait for your idea to be proven before they consider implementing it, letting you absorb the risk. When it comes time for them to implement, you may have a large enough market share that it doesn't matter what they do. Or you may have made enough progress that it's easier for them to acquire you than it is to build it themselves.

One thing that does concern me in your description is it sounds like your idea is simply a feature, not a viable business or even a useful product. The fact that you're concerned with your idea being easily tacked onto an existing social site leads me to believe that it's really just an improvement on things that are already out there.

Features don't really stand alone by themselves. You need a compelling product and a decent revenue plan to turn it into a business.

How about something substantive? WHY is it superior? Or are you just trolling?

There's an effort going on to get Adhearsion running on FreeSwitch anyway.

Tropo uses Phonetag.com and Simulscribe to provide the actual transcription, and we've built a custom engine to handle the delivery and management of the transcriptions on the back-end.

To play an audio file in Tropo, just use the URL inside of your say() command. We'll recognize it automatically and do the right thing.

And you can store the recordings on Tropo -- your Tropo app space has FTP and WebDAV credentials, so you can tell your app to FTP it to Tropo's webhosting. We don't want to store your recording forever, but fell free to use it for short-term recordings.