Asterisk vs. FreeSWITCH

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?

Tags

Asterisk vs FreeSWITCH

Trackbacks

Chose Freeswitch over Asterisk

Our PBX/IVR web-based generator Telfa has been moved from Asterisk to Freeswitch. Why?
Asterisk just seems to come from a different world than what I am used to. Inflexible and problematic. Very long configuration files with ancient syntax. Now I... read more...

To send a trackback, use the URL of this story appending ?page=tb at the end.

Comments (33)

FuriousGeorge from Newark

The only thinking stopping me is FUD. I would hate to spend all that time learning a new paradigm, only to find that in terms of reliability / stability / predictability I have the same old problems.

Anthony Minessale from Milwaukee / WI / USA

Hi,
I'm Anthony Minessale, Author of FreeSWITCH.

I just wanted to take the time to defend our use of XML if I can. =D

Originally, FreeSWITCH used the same .ini format that Asterisk uses in all of it's config. Actually the interface to parse .ini still exists and a module writer is able to use it if he pleases. The reasoning for XMLizing what we chose to XMLize becomes more clear when you begin to scale the system. FreeSWITCH parses it's XML registry when it first starts and keeps it in memory. This is one big entity that can be navigated similar to a file system. There are top level major sections: configuration, dialplan, directory and phrases. All of the bits and pieces of these sections are exploded out onto the disk in the default arrangement so you can edit the portion of the document you need and it also allows you to insert small XML representations of a single entity such as a SIP UA, a user on the system, the configuration for what modules you want to load. All of these files will be concatenated in the end into 1 big XML document that the entire core and its modules can access with a common API that gives you the entities as a tangible object that can be extended without more code. Now for the interesting part. It's possible to bind callback functions to certain sections of the XML registry so that when code tries to access a particular section your handler can conjure the XML on-demand any way it wants and deliver it back in place of whatever is in the default document. For instance, you can bind your dialplan and user directory sections to mod_xml_curl, A callback that translates XML lookups to and from a nearby HTTP server. When the call hits the XML dialplan the cURL handler kicks in and posts a request to a custom CGI. The CGI gets post data that is identical to a web form being posted with a few dozen facts about the channel that you can use to determine where the call was intended to go and who's calling etc. The CGI then creates a small snippet of XML that will satisfy the request and returns it to FreeSWITCH who will parse it as if it was part of the static config. The same can be done when someone registers to SIP or tries to check their voicemail or when the config is called up during load.

Trust me. I am far from XML's biggest fan, but I do feel it's actual uses are lost in a sea of contrived forced solutions that give it a bad name. To serialize complex objects to and from a text format and to make markup that is easily parsed and generated are the real strengths of XML. The best used XML is XML nobody ever realizes is even there. Certainly that is not true completely with FreeSWITCH today but as we scale and more GUI's and config apps are made, the curve will be in our favor and most people besides only the truly advanced users will ever have to see the XML again.

Caveat: We do have mod_dialplan_asterisk in tree that will allow your dialplan to look and feel more like the asterisk extensions.conf (using .ini) for a sort of cross-over feel.

Anders from RTP

FuriousGeorge: That's a good point. Clearly you will be trading one set of problems for another in some way. I guess nothing but time with FreeSWITCH in your environment will clear that up though. There seems to be a bit of anecdotal evidence suggesting that FreeSWITCH vastly outperforms Asterisk but that usually comes from stripped down test data - like 3,000 concurrent channels doing what? Playing hold music? Presumably acting more like a real PBX those numbers wouldn't be so high. That said though, I would still argue that it vastly outperforms the 250 concurrent channels I get with Asterisk playing hold music. Give it a try in your environment and let us know what your experiences are.

Thanks for the comment.

Irshad from India

I am also a newbie to XML. I really felt in the same lines seeing at the free-form nature of XML at first. But when complex applications surface in future, most of the applications would have web GUIs or so where user needn't bother about the complexities involved at the back end.

I can say XML is a more beautiful tradeoff than any other formats.

Anders from RTP

Anthony: Thanks for the explanation. The XML decision does make sense for the internals of FreeSWITCH. I guess my gripe with it centers around how easy FreeSWITCH is to get going for the first-time implementers. Maybe this could be solved with a simpler XML example but a pile of XML files that can be named just about anything seems daunting at the outset. Sort of adds potential confusion for first-time users.

That said though, this is a tiny gripe in the face of the overwhelmingly positive experience I've had with FreeSWITCH. Thanks for putting together a stellar project.

Abdoulaye Siby from Ottawa / Ontario / Canada

I have done a lot of PHP programming for Asterisk AGI applications. When I first looked at the embedded programming languages, I am admit that I have been particularly seduced by the SpiderMonkey Javascript. However, is there a way of calling external application built with other non-embedded programming languages like PHP, C++, Ruby, etc. or even a binary application?

I am also curious about the embedded javascript. Usually, javascript is seen as a client-side script and its speed and performance basically come down to the processing power of the client's computer and the browser used. This is the very first time that I even think about creating or adapting a VoIP application with an `embedded` javascript. Also, I have no reference point whatsoever about its execution speed compared to other languages like PHP or Perl for instance. Does the use of the freeswitch embedded javascript for huge applications affect in any way the performance?

Cheers

Anders from RTP

Abdoulaye: Yes, you can call arbitrary executables though you wouldn't have any call control. The best you could do would be to control FreeSwitch through the event socket on port 8021. (not very interesting)

It does add overhead to be using JavaScript on every call though you get the interpreter in memory already so you don't have executable startup time. I'm in the middle of testing this out but clearly the more JavaScript there is to precompile, the more processing has to be done with each call. As far as I know, there is no way to precompile the JavaScript though I'm sure someone will add that eventually.

Abdoulaye Siby from Ottawa / Ontario / Canada

Thank you for answering so quickly.

Rest assured that I will never use the event socket. I don't even like the Asterisk's AMI. I prefer to have a direct control over things instead of using a socket connection unless absolutely necessary.

About the overhead, I know that there is going to be one when using any programming language. And even though PHP is most of the time interpreted instead of being precompile, it seemed not bad at all for AGI applications.

I am thinking about building a billing/routing software for Freeswitch. I am currently using A2Billing and it is pretty good, but not compatible with freeswitch. And considering the higher performance of Freeswitch, I am willing to loose some asterisk features.

I would like to know in which order would you classify the following embedded languages when it comes to the overhead that they add: Javascript, Python, Perl, Lua.

Cheers

Anders from RTP

Abdoulaye: I don't have a good feel for that yet. I have fairly good experience with JavaScript and will be running some heavy load testing this week so I might have some real figures as far as JavaScript is concerned but nothing in relation to the other languages. The FreeSWITCH guys like LUA which is easily the lightest interpreter of the ones you mention but you are still stuck with the time taken interpreting the script.<br />
<br />
Another option would be to use Mono or Java. Both can be pre-compiled and will stay resident in a VM even when no call is processing. There are also ways to use Mono to run precompiled JavaScript and other languages. As always, your mileage will vary but if you are interested in a performant option, a higher level language that runs in a virtual machine might be the way to go.

Michael Giagnocavo from Denver CO

LUA has the lowest overhead of any scripting language -- something like 250K or so?

However, there is mod_mono, which will use the Mono runtime, allowing you to use any number of languages (over 20, maybe as many as 50?).

mod_mono also allows near full access to the entire FS C API, so you can do more than just use the simple App API (although, that's there too).

Mono will JIT your code, so raw performance is excellent. The memory footprint is a big bigger (mod_mono and mod_mono_managed are around 800K) because almost every function is wrapped (so we need an interop function in native code, plus the prototype/interop in managed code).

If you can take the memory hit, I'd be surprised if anything comes close to it in performance. (In fact, with a bit of work, I'd be willing to bet you can get performance nearing a native C app.)

Diego Viola from Asuncion, Paraguay

FreeSWITCH rocks, can't wait to switch from Asterisk.

voip from kelowna/Canada

http://www.cliconnect.com/ is installing FreeSwitch in a couple of servers to check its performance. We'll post the results in our Blog

Diego Viola from

There is YAML support now on FreeSWITCH trough mod_yaml.

So, for those who don't like XML that much, you can write dialplans in a more friendly way, like this:

In XML:
<open source="AmazingTeam" on="FreeSwitch">
<projectowner>Anthony</projectowner>
<development>Mike</development>
<qa>Brian</qa>
</open>

In YAML:

AmazingTeam:
project : FreeSwitch
projectowner: Anthony
projectlead: Mike
qa: Brian

Diego Viola from

Read more about YAML here:

http://en.wikipedia.org/wiki/YAML

Ron from Amsterdam, The Netherlands

Well,

what's holding me back is lack of G.729 support...

Ron

Anders from RTP

Ron: G.729 carries licensing issues. G.729 can be passed through so technically you can use it. The code it out there so it could be incorporated in FreeSWITCH although it hasn't yet because of the licensing nightmare.

Wasim from Lahore, Punjab, Pakistan

I've personally experienced a 10x increase in the call throughput capacity between asterisk and freeswitch, same hardware, same application, SIP, media handling, call routing.

Ron, I've heard G729 is in the works, so wait for good news soon ...

I concur on the XML, hideous to work with on a text browser, and you get lost in a flurry of < /> but I do see why anthm chose it and as more and more configurators (gui, web based or otherwise) get built, the choice is becoming more and obvious, a painful but wise decision.

The only reason I'm stuck with tens of asterisk installations are due to the lack of SS7 support on fs, otherwise, most everything else has been shifted, and much more happily so ...

SwK from Huntsville, AL

Anders: I'm actually one of the guys doing the 3000 calls routinely on FreeSwitch... While we arent doing PBX functionality, we are doing Extensive Least Cost Routing with some pretty cool features that have allowed us to reduce our over all termination costs and maintenance costs by going with FS... One thing I dont miss is screwing with openser config files... another thing I dont miss is only being able to run about 250 calls on a single box...

Not to put a quantitative number on the things Using off the Shelf Dell 1950 with Dual 2Ghz Quad Core CPUs, 4G Ram and whatever they have on the low end for HDDs using a custom written C module that replaces the dial plan (yes you can do this and its quite easy... for a good example of how to do this look at mod_enum) the application uses all the information available to you same as the stock xml dialplan and fires queries off to a PostgreSQL Cluster for doing route lookups and costing. this information is then returned to FreeSwith and freeswitch uses it and other state information from the cluster to determine which is the best and most cost effective carrier to send the call to. It also does things like determine if (based on customer profile) there is the possiblity of NAT so we'll proxy the media. (If we know there is no nat in the loop between the last media proxy and the termination media gateways we dont even have to bring the media to FreeSwitch it bypasses quite nicely reducing media processing overhead on the box (and quite nicely reducing network load)

Bipin from UAE

i was waiting for something like freeswitch from quiet some time but XML confuses me as i have no past experience in it and secondly i was wondering if there was a good frontend for it but aimed totally towards a softswitch similar to voipswitch etc which has features lke calling card config rather than extensions, IVR specific for calling card purpose etc etc with CDR and tarrif config

Michael S. Collins from Fresno, CA

Anders: Nice article and thanks for following up on the various issues and questions that the commenters have posted here. My only request would be a follow up article from you since it has been over 2 months since the original article was written. Anthony Minessale is pretty talented and in 2 months he and Mike Jerris have add LOTS to FS. Ask Diego Viola about what led up to Anthony creating mod_yaml in just 3 hours! It's quite a story and it is proof not only that FS is incredibly flexible but that the devs and community are top notch. FS will continue to make inroads into the telecom arena and not just at the expense of Asterisk. It will start displacing carrier class switches once it gets some traction. Exciting times are on the horizon!
-MC

Diego Viola from

I didn't liked the idea of XML at first, but once I tried I found that it was very easy and I actually like it now.

You only have to use XML for the SIP profiles, for the users profiles, and for the dialplan, it's plain simple. It's just parameters/variables and values, with a <> on it.

You can use any other language you want for loading them in the dialplan as your IVR, etc. It's really simple and very useful/powerful.

If you don't like the idea of XML, I think you can use YAML too for the dialplan, there is a mod_yaml already.

Diego Viola from

@Michael S. Collins:

Indeed, anthm == best programmer ever =D

Olavo from Canada

There is a gui development tool. http://wikipbx.org/

Diego Viola from

Some things that FreeSWITCH lacks/needs:

1- a "-r" option in the freeswitch binary, to re-connect to the freeswitch socket. I know there is fs.pl, but it would be nicer if FS has an -r option in the binary itself, more handy, practical and useful, it doesn't make it less simple, it makes it functional.

2- an easy way to dial out from conferences, from ANY phone.

3- the ability to set timeout per-bridge/leg, along with global timeout.

4- Complete IAX stack that supports registration, trunking and everything.

5- "sip show peer <peer>" replacement, to see the user's settings from the console.

Diego Viola from

Forget about what I said in the first option of adding the -r parameter. FreeSWITCH is nicer the way it is now as a server only and the functionality is already in mod_event_socket.

fs.pl is good enough for me =D

dimas from world

Just curious if FS has anything like Asterisk's DUNDi. We have multiple sites, users registers with (both SIP and IAX) as well as some services provided by each site. And the lookup (to which PBX particular request should be routed to) is done using DUNDi. There is no single point of failure - each site can live even loosing connectivity to others (providing dialing to local users and local services). Can I do the same with FS?

Anders from RTP

Dimas: No there isn't DUNDi support in FreeSWITCH though you could do the same thing by backing all of your FreeSWITCH instances with a distributed database. FreeSWITCH can use external SQL databases to store registrations as well as other data so you could even register with one server and send a call (which requires registration) to another server. You could do a DNS based load balancing with SRV records with this as well, increasing redundancy.

Diego Viola from

Yeah why use DUNDi when you can use standards in FS that works much better =D

Simon Shaw from

Hi, SwK from Huntsville were you using OpenSER or Asterisk before you moved to FS?

Anders from RTP

SwK: I have both OpenSER and Asterisk currently in production. However, while I use Asterisk as a media server and a VoIP to TDM gateway, I'll be using FreeSWITCH more like a PBX.

Undrhil from Alabama

Hey. What codecs are supported in FreeSwitch? Is there support for Speex? While g.729 is a nice one, the licensing is a pain. Speex is a little more *beta-y* but the amount of bandwidth used is phenomenal.

Anders from RTP

Undrhil: FreeSWITCH supports Speex as well as a number of other codecs. Here's the list as of the current version: (v1.0.1)

* G.711u/G.711a
* G.722
* G.723.1 (passthrough)
* G.726
* G.729 (passthrough now - full support soon)
* GSM 6.10 FR
* amr (only for license holders - full support soon)
* H26X signed linear
* ILBC
* L.16 (slinear) - raw audio
* lpc 10
* Speex

I spoke with Anthony at ClueCON about G.729 support. They are working on a deal that would supply G.729 support similar to the way it is supplied with Asterisk.

Diego Viola from

Here is an article I have written for the company where I work. It's about my experience with Asterisk and FreeSWITCH. I though you might find it interesting.