Over the past several months I have been heavily involved in implementing FreeSWITCH (which just celebrated its first 1.0 release) as an Asterisk replacement. I come from a solid Asterisk production background with several hundred implementations in the field so I would classify my knowledge of Asterisk as fairly good. I must say though that I am very impressed with FreeSWITCH, particularly in the area of performance and flexibility. Given the strengths, I wouldn't be surprised to see FreeSWITCH migration announcements coming out of major Asterisk based PBX vendors within the next year.

Running Asterisk in production with standard hardware, I'm not able to reliably handle over 250 concurrent calls. But with the same hardware, I have tested to 1,000 concurrent calls using FreeSWITCH without any issues. Evidence from others on the FreeSWITCH mailing list claim 3,000 concurrent calls without issues which would seem to approach wire speed! Anecdotally, the first limit you reach with FreeSWITCH might not be with the CPU!

So is FreeSWITCH a drop-in replacement for Asterisk? Not quite, but it is headed somewhat in that direction. Let's look at what it can do versus Asterisk and how it is configured.

The first thing you are likely to notice when configuring FreeSWITCH is the decision to do all configuration in XML files. Personally I think the project would be much better off using standard text configuration files instead because XML files are too free-form. This leads to confusion like "Where should I configure such-and-such?" questions. Usually the answer to this question is "anywhere" but people want to configure things in the "right place" and move on. The free-form nature of XML makes things ambiguous at best because one setting can be contradicted somewhere else in some other XML file. Most people configure things with text editors anyway so XML just ends up being more typing while settings become less clear, even if code coloring is turned on. An XML editor might help here but who has an XML editor on a text mode system? For performance reasons, none of the machines I have ever deployed have had a windowing system so frankly an XML editor isn't realistic. However, I would say nearly every Unix based system in the world has a text editor.

FreeSWITCH succeeds on so many other levels that I am willing to forgive this minor blemish. For example, just the idea that you can use regular expressions in the dialplan is freeing. And you aren't limited to matching only on the destination number. You can take other things into account such as the source extension so for example you could send someone to listen to their voicemail if they call their own number while sending everyone else to the front door to leave a message. FreeSWITCH makes good use of SQL for storing things like session data and registration data. This can be migrated off-box via UnixODBC so operating a cluster of FreeSWITCH instances on one central set of data becomes and exciting prospect. This also leaves the door wide open for writing interesting web front-ends and exposing call state to various widgets.

But probably the most interesting feature of FreeSWITCH is the fact that you can jump out of the confines of the traditional dialplan / module jail and take over call control using a variety of languages. I was able to write a full featured database driven IVR system (with schema) in a matter of days with this. (including the learning curve!) Rather than reinvent the wheel, FreeSWITCH just leveraged existing languages with all of their diverse libraries by adding in a few call control methods. This simple move breaks open the VoIP application programming landscape giving a tool set to developers outside of the normal C programming confines. Suddenly a web developer versed in JavaScript can write a VoIP application!

For example, picking up a call and playing a message with JavaScript becomes as easy as:

session.answer( );
session.streamFile( "message.wav" );

So why does FreeSWITCH perform so much better than Asterisk? It largely comes down to the way FreeSWITCH remembers what is up with each channel at any given time. Because FreeSWITCH uses one thread per channel to maintain channel state, the complexities of locking and unlocking a linked-list of open channels in the Asterisk model are avoided. This more segmented design leads to fewer deadlocks and virtually eliminates channel state corruption issues. It is hard to imagine that this design alone garners a 10x performance boost but it looks like that just might be the case.

FreeSWITCH leverages a number of already existing libraries to support a wide variety of technologies. For example, FreeSWITCH uses the Sofia SIP stack instead of reinventing a new version of SIP. This saves a great deal of time and complexity for the FreeSWITCH developers while opening up the capabilities of the project. FreeSWITCH has been extended in this way to also communicate with H.323, IAX2 and XMPP (GoogleTalk) services among others.

FreeSWITCH is compelling, but compared to a very mature Asterisk, it obviously still has some distance to cover. The question is whether or not the remaining differences matter enough to be a reason not to switch. It is early in the game, but I would say for most projects the issues probably aren't that significant. The upside of a far more configurable and efficient platform is usually too much to ignore. For very specific applications like conferencing and media serving, FreeSWITCH is the clear winner. If you need a business PBX with a pretty web based front-end, you still might use Asterisk because no option exists yet for FreeSWITCH, but that should change in time.

If you have already made the switch from Asterisk to FreeSWITCH, leave a comment with your experiences. If you are considering making the jump but haven't yet, what are your concerns? Is something significant holding you back?