I admit to really only very peripherally followed the growth of FreeSWITCH, so I was intrigued to attend the “FreeSWITCH Boot Camp” session this morning here at ETel. It was a tough call given that Stowe Boyd was also speaking, but I wanted to understand what FreeSwitch was all about. It was an interesting talk, although I’m left with the following observations:
- I’m still struggling to fully understand what problem the FreeSwitch community is trying to specifically solve versus what Asterisk, sipX, OpenSER, etc. are solving.
- The answer from the FreeSwitch developers was that it is really complementary to those other projects and focus on scalability and stability. It is NOT focused on the PBX space but really at the carrier space and looking at large-scale implementations. Several people also mentioned using it as a Session Border Controller (SBC).
- So is it an open source SBC?
- One carrier representative involved with the project indicated that in their testing they are getting 2,000 to 3,000 simultaneous calls up with media streaming… and at least 10,000 simultaneous calls with point-to-point media.
- Perhaps that is the focus… but I would say that the FreeSwitch folks need to refine that message bit so that it’s a bit easier to understand.
- Management is still pretty much all through config files. Web GUI is still “in the works”.
- Looks to have a pretty comprehensive list of protocols, codecs, application interfaces, etc.
- What was perhaps most interesting was their web-based interface to a conferencing system. Pretty nicely done.
Overall, my impression was that it’s an interesting toolkit to let folks play with telephony on potentially on a large scale. It will be quite interesting to see what evolves out of the FreeSwitch developer community. I’d be interested to know if anyone reading this is using FreeSwitch and what they are doing with.
I’d be happy to elaborate on your question on what problem we are trying to solve.
First of all I’d like to point out that on the list of applications you have above SER and sipX are different categories of software entirely so I’ll start with those because that will be easiest to answer.
SER is a sip proxy It’s purpose is simply to route sip traffic and potentially rewrite some of the packets to do magic things on the fly.
sipX is a pure SIP based PBX It was designed to use several SIP phones in an office.
An example of FreeSWITCH being used with SER and sipX would be a network where all inbound SIP traffic is passed to SER which would send the calls to multiple FreeSWITCH machines that would in turn be able to route the call to the proper destination as well as run IVR scripts etc.
If the call was destined for a phone hosted on a sipX instance then it could send the call there to be processed. If the call was destined for the pstn then it could send the call over it’s local PRI hardware or forward the call to another FreeSWITCH instance configured specifically for a PRI gateway. In turn if a local used on a SIP phone wants to make a call the sipX sends the traffic to FreeSWITCH who can decide if the call should go to the PSTN or over to SER who can send it out on the internet.
With this model one SER process can manage the traffic flow for many FreeSWITCH instances and give the appearance of a single SIP entity and sipX on the backend can manage clusters of SIP phones.
Now, for Asterisk….
Many of the same scenarios can be solved by even 1 asterisk machine doing all of the above because Asterisk’s namesake is, of course, * (the computer geek symbol for “everything”). Frankly, the aspects it does not try to tackle are stability and scalability nor does it aspire to run on many platforms beyond Linux and maybe BSD, on a good day.
I’ll begin with some background. I have been doing development on the Internet for several years and in the last few years my focus has shifted to telephony. We used Asterisk for several years and I personally contributed heavily to the project:
See http://www.cluecon.com/anthm.html or http://svn.digium.com/view/asterisk/trunk/CREDITS?rev=54838&view=markup
I have developed several systems based on Asterisk using hardware, software and everything in between and my final unfortunate conclusion was that Asterisk couldn’t solve every problem unless it’s redesigned. I personally can understand how hard this information would be to swallow from a 9-year-old project, which is why I understood when most of my suggestions fell on deaf ears during the weekly development meetings I had been hosting at the time.
Finally I just decided that if I wanted to get anywhere with my ideas I have no choice but to start my own project. Asterisk is still cool software and I am proud to have my name as the author of several files in the source code. I just simply see a niche between what Asterisk has to offer and what I need in a telephony application, which was my motivation to create FreeSWITCH.
I’d like to correct you, if I may, in regards to your comment about the management being through config files and the GUI “in the works”. FreeSWITCH has been open to the public for a year now and has emerged from an empty directory in less that a year and a half. My only focus at the moment is making the core application stable, flexible and to present the functionality necessary to do anything you want without editing the core code. There are several advanced capabilities that would allow FreeSWITCH to be managed entirely remotely including a socket based management interface and hooks to allow all requests for internal configuration to be fetched live from a remote location.
Remember, I helped add the database config leading to the realtime architecture in Asterisk after all.
In conclusion, I think there is a clear and absolute purpose for FreeSWITCH as both a core soft-switch and an IVR media gateway. I hope you find my explanation useful and I invite you to drop by our IRC channel on freenode or give our development conference a call sometime.
I think what they are trying to be is the “Apache” of voip, one single package that can scale from a soft-switch to a PBX, SBC, etc, etc, etc. using different modules for everything.
NO LIMITS.
FreeSWITCH rocks!
Comparing Freeswitch and Asterisk, it is clear that Freeswitch carries more weight in feature set and scalability. It will only be a matter of time for the adoption of Freeswitch to match and overtake that of Asterisk. However, there is need to note that while neither architecture has inbuilt support for all three implementations of T38 (pass-through, termination, and gateway) one of the main reasons Freeswitch will overtake Asterisk is because Asterisk lacks a lot of the features that a PBX needs and Freeswitch addresses this including scalability without the need for SER/OpenSER, etc and neither is Astersk and its author/parent company trying to address any of these or thye just do not know what to do about it or perhaps too reluctant to re-develop from scratch to add the required features.
Keep up the good work.