jsgoecke

Something not covered here?

http://www.diggz.org/index.php/about/

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.

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.

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.

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.

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.

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 agree. Bundler is a gem that has changed the way I work.

Give http://tropo.com a try. It also does voice, IM and Twitter along with SMS.