In order to offer more insight into the origin story of the FreeSWITCH project we interviewed the Founder and Lead Developer of FreeSWITCH, Anthony Minessale. Here is what he had to say.
What is it exactly that you do in the FreeSWITCH project?
I run the FreeSWITCH open source project. I work on the architecture of the software as a whole, I do development on new features, I maintain the existing code and fix bugs etc.
I also started the ClueCon conference held every summer in Chicago. Thats where we usually present on the current state of FreeSWITCH.
When did you start working in communications?
I worked on Internet related technology in general since the mid 90's. I specifically started working on VoIP etc. about the turn of the century.
What was your first job in this industry?
My first job related to telecom was a company where we did outsourced tech support and toll-free call termination.
What was your level of education before starting in this industry?
I made it half-way through my Bachelor's in computer science and left school because I was gaining more experience being involved in the current explosion of communications technology.
How did you get involved with FreeSWITCH?
I was working at the tech support / provider company and I was having trouble finding a solution to moving dense call traffic. Many existing solutions were more focused on PBX functionality at the time. So I decided to create FreeSWITCH to fill the void where expensive soft-switches were holding everyone hostage. I spent about 6 months developing the base core of the software and the module interfaces. Then got it working on UNIX and Windows. Then in 2006 we opened our public code repository for the first time.
What made you write FreeSWITCH over other similar software?
I had tried some other software but I had a lot of trouble getting it to behave the way I wanted. I even contributed to some of them trying to add some functionality. It was unfair to constantly try to force behavior changes and functional changes on the other software when it was not part of their goals. So I decided to start my own project with like-minded people.
What are your thoughts on the concept of open-source software?
Open-Source software has upsides and downsides like all things. Having it open makes it much easier to develop faster from all the constant feedback. Sometimes not having a single commercial goal can also dilute the speed of development. Our project tries to tow this line by concentrating on the industry and where its going.
What would you consider the greatest resources for someone trying to learn FreeSWITCH and the communication industry?
The best way is different for everyone. If you are a visual learner, downloading our code repo and browsing the code and examples may be a big help. We also have a large WIKI and several books that try to illustrate the most important concepts. We will also be offering some training classes. First at ClueCon then possibly at other locations down the road.
What is your favorite aspect of FreeSWITCH? Are there any particular features of which you are most proud?
My favorite aspect is the flexibility. My design goal has always been rooted in the UNIX mindset of making things separate but connected. There are countless ways to deploy and configure FreeSWITCH that are completely different. You could make one instance handle SIP traffic then another just for VoiceMail and another for Conferences and another for PBX-type functionality.
What is the most important thing you think people need to learn in order to succeed with FreeSWITCH and in this industry as a whole?
The most important thing would be to learn to focus on solving the problem the most efficient way that is required to satisfy the use case. Learning to identify the problem and understand the situation and find a stable and scalable solution.
What is your favorite part of working in this industry?
My favorite part is that it seems to be constantly evolving and never dull. Sometimes it’s actually comic relief to see some of the crazy things that land on our plate.
Can you share the FreeSWITCH origin story from your point of view?
In 2005, Brian West, Mike Jerris and I were working together as Bug marshals for Asterisk. We used to talk over IRC and work on various bugs for the community as well as our own modifications we were making to the project and trying to get them working well. When my experimentation became too outside-the-box for the general public, I started playing around with some of my own modifications. I sometimes needed to get a new low-level core feature into Asterisk to get my custom modules to work so we would submit those separately. We would submit most of my modules as well but not all of them were desirable to the core team of Asterisk, which was understandable. So we would just post them on or website instead.
One of the problems I was trying to tackle back then (circa asterisk 1.2) was scalability and dynamic configuration. I started a module to load some of the configuration from the database on demand called res_config, which was partially adopted as part of the realtime stuff that Asterisk has today.
At the same time, I was working on a software audio conferencing module called app_confcall. The goal of the module was to not depend on hardware for conferencing of audio and to add some features like playing audio files. We started using the app_confcall to run a weekly bug marshal's meeting that turned into a daily chat session with many members of the community. This was a great way to ponder the future and share some of my ideas with the other developers and users.
I had been developing other features to try to do things like transfer channels on demand back to the dial-plan and was hitting some issues because of the threading model. At the time, Asterisk had only one thread per call even when 2 legs were involved so if you wanted to transfer one of the legs to some other extension it was very difficult programmatically and was prone to bugs. Its probably detailed in Asterisk lore as the dreaded “Channel Masquerade”.
I also had some trouble with limitations in how the dial-plan worked. I developed function variables as a concept and shared the patch with the community and it was taken and modified into what it is today. Combining this with the realtime work, we began trying to develop a queue system with a web-based control panel using some of the on-demand functionality to manage the system.
We ran into a lot of problems because we were trying to force Asterisk into doing some of these things it was not intended for. We spent a lot of time trying to come up with ways to improve how things worked.
After fighting with the default Asterisk queue system and trying to make it dynamic against its will, we started to give up. As a new plan, a few community members and I decided to try to create a new queue system for Asterisk called ICD. ICD stood for Intelligent Call Distribution. The idea was to try to move the complexity of the changes into this module to avoid messing with the core code too much. It was usable but some of the same problems still surfaced because the same threading model was still employed underneath.
At some point, while discussing the state of affairs, talk of a “rewrite” began to surface. It was a crazy idea. Take all the knowledge from the problems we encountered trying to shoehorn Asterisk into what we needed to do and start over. We envisioned it as “Asterisk 2.0”. We did some brainstorming and played around with the idea and chatted about how it might work. We had a few of the other developers entertaining the idea too but ultimately, Digium was not interested in the idea which is understandable since they were already supporting a large user-base on the existing version and the idea of starting over was ludicrous.
Screen Shot of early FreeSWITCH running IAX in Windows (circa 2005)
At the same time, some disgruntled Asterisk users decided they wanted to fork the project into their own project known as OpenPBX. The goals of OpenPBX were to speed up the adoption of features and acceptance of patches and to get native fax support into the application. Some of these people were colleagues of mine and I offered them any of the random Asterisk-compatible code I had lying around if they were interested. I still chose to use Asterisk at the time but I was not against the idea of someone exploring ways to improve the code. Any time I was involved in a discussion about how to improve some of the things related to performance or the threading model I would offer my 2 cents from the things I learned. The problem was almost every time I would factor my thoughts down to the fact that if these goals are to be easily reached it might require a complete rewrite. I really felt that this lent no assistance to the OpenPBX team since they too were interested in molding a working codebase into something better while still using it and supporting a user base. OpenPBX went on to be known as CallWeaver.
One day in the spring of 2005, I decided maybe instead of rewriting the Asterisk PBX or any of its offspring, I should just take the things I really wanted to happen and make a new application that was focused on abstraction, scalability, and portability. I reluctantly typed “mkdir choir”, my original name, followed by “emacs choir.c”. I just riffed out a core application with a dso module interface and a single module that answered tcp connections and echoed any data that it received. I shared the code in a tarball with all of the developers I respected. As engineer developer types do, they all ignored me, never looked at it and said “yeah, sure. its ok”. Lucky for me, that was more than enough inspiration! I took a break from coding to host the first annual ClueCon developer’s conference, which still happens every year to this day. At the conference, we talked for hours about all the possibilities of cool things we could achieve if we tried to develop it. I spent the next month or two discussing how some of those ideas could apply to a new application in conjunction with all the thoughts already in my head with my Choir code.   [Check out the original Choir files here]
Finally in the fall of 2005, I felt I had enough direction to make some more changes to my code. I sketched out the model for channels in a state machine and endpoints that could move audio. Inspired by all of the things I had tried to do in the past with ICD and my other asterisk modules, I tried to plan ahead for things like different sample rates, stereo audio and video. I built a threading model that was concise and gave call legs each their own thread with a well-defined lifecycle. By Jan 2006, I had a working application that ran on Linux and Windows that could handle SIP, Woomera (a front-end to openh323) and TDM calls with a regular-expression driven dial-plan engine. The final name for the application was FreeSWITCH, an open-source Soft-Switch. Unlike a PBX that was centric to local extensions and placing calls between local phones and few TDM trunks, a Soft-Switch takes a step back from a PBX and concentrates more on the idea of routing calls and terminating calls to voice applications like IVR etc.
For the decade that followed we have continued to refine FreeSWITCH and add functionality that is relevant to the changing times in the communications industry. We now have a functional WebRTC media stack that can communicate audio and video with a Browser as well and audio and video over other protocols such as SIP. We have countless features ranging from SMS powered applications to carrier phone traffic to a web-based MCU. FreeSWITCH is used by many companies all over the world for a multitude of commercial services. It’s hard to imagine even today that at one point it was an empty folder and today it has 794 files with over half a million lines of code.