FreeSWITCH: The Story Behind The Software

I’ve been working on FreeSWITCH for nearly 2 years and on the dawn of our first release I wanted to take some time to share the story behind the software project and provide a glimpse of what’s to come. This story will also appear in the first issue of OST Magazine so get a copy, it’s FREE!  

The idea to write FreeSWITCH was first conceived in the spring of 2005 during a weekly Asterisk developer conference call. At the time, I was heavily contributing code and features to the pending 1.2 release of Asterisk and we were brainstorming on what to do for the future. We all agreed that there were serious limitations with the current Asterisk code base and we had to face the issue that fixing some of the problems would sacrifice existing features and may take a great deal of time. One idea was to branch the code so there was a gutted version of the code alongside the one everybody was used to. This new branch could be worked on without the pressure of disrupting the vast Asterisk user base. The problem was that the developers did not want to split their efforts on two versions of the same code and have to move bug fixes and tweaks back and forth between the two branches. My suggestion was to start “Asterisk 2.0” from scratch in a separate repository and spring it on the public when it was ready. I think that idea intrigued some of the developers, but ultimately the reality set in of taking that much time to start over and they eventually lost interest. I, however, did not.

It was apparent that I was the only one who was serious about this idea and I spent the next several days daydreaming about how I could design a new telephony application. After a few days, I could no longer resist the urge to make a new directory on my PC and start editing a blank choir.c. Yes, Choir! That was the first name I chose because I envisioned the various communication components working together in unison like a choir singing in perfect harmony. I spent the next 5 days taking any ideas that came to mind and organizing them into a handful of files. That first effort hardly resembled a telephone switch. I knew that I needed to create a stable core that I wanted it to be cross-platform so it was easy to come up with a basic subsystem based on Apache’s APR library that could load shared modules and sit idly on the screen waiting for the shutdown command. This was the way the code would stay for the next 6 months.

The lesson I learned over those 5 days was that it’s not exactly easy to write an application of this scale. My original goal was to pick up where Asterisk left off and improve upon the idea, but the more I thought about it, the more I realized that what I wanted to improve were pure fundamentals in design and functionality. I came to the conclusion that Asterisk simply was not meant to do some of the things that I wanted it to do because it was not the right type of software for my demands. This is when I knew that I was not going to write another PBX. I was in fact going to write an entirely different class of application. I spent the next several months leading up to the first annual ClueCon conference debating how to design Choir properly. I wanted to make sure that I had the right plan before I started writing any more code. At this point I was still doing a fair share of Asterisk development and I put some of my ideas to the test with some of my 3rd party modules. I also asked many of my collogues for input and spent countless hours debating how to do things “right” which is often in the Telephony world, a matter of perspective.

At ClueCon that year, I had a chance to meet some of the most influential developers in the Telephony industry and I returned home with a great deal of inspiration. At the same time, tension was breaking out in the Asterisk camp because several of the developers had decided to fork the project. This new project dubbed OpenPBX (now Call Weaver) caused somewhat of a rift in the Asterisk community. Initially OpenPBX adopted many of my 3rd party Asterisk modules into their new code base and consulted me for tips on what to change to improve stability. At one point they even approached me to see how I was doing with my new project with the idea that maybe we could rekindle the old plan of a side-by-side rewrite. That idea didn’t pan out but I think the monumental moment came when someone asked me “How long would it take to get it making calls?” I didn’t know, so I decided to find out. The short answer was “1 week”.

Making a call was a small victory in comparison to what I needed to accomplish. There was a lot to be done and my unimpressive feat was hardly enough to attract much attention. The good news was that the project was finally underway! I worked on the code in solitude for 3 straight months trying to get something presentable for the public eye. During that time the name changed to Pandora and eventually to its ultimate name, FreeSWITCH. In January of 2006 we were open for business with a public SVN repository and a mailing list. At that time we had a hand full of modules and a very small feature list but we had a working core that compiled and ran on several UNIX varieties including Mac OS X, Linux and BSD it also worked on Microsoft Windows as a console application.

As time progressed we picked up some momentum, taking a break or two along the way to make a few mistakes and start over on a few modules. In all we had started four different SIP endpoint modules before finally deciding on Sofia SIP. We had an alarming five different RTP stacks before finally writing our own. In that time I also developed mod_dingaling to interface with GoogleTalk, a feature-rich conference bridge module. For the first year I mainly focused on making the core as stable as possible, providing several external interfaces to facilitate development such as embedded javascript for IVR, an XML-RPC interface and a TCP based socket interface for remote control and event monitoring.

At the second annual ClueCon, on a day that seemed like an eternity from my daydreaming days, I presented FreeSWITCH to my fellow developers for the first time. Nearly nine months after that presentation, 2 years since that first idea, and a month before the 3rd annual ClueCon, we are at a BETA phase of development and soon will be releasing FreeSWITCH 1.0. We have attracted some brave developers along the way who are already using it in production and providing us with the critical feedback we need to make our first release a success.

The final piece of the puzzle before the release is an interface to my new open source TDM abstraction library called OpenZAP. The new mod_openzap, driven by this BSD licensed code, will replace the current Sangoma specific mod_wanpipe and provide support for Sangoma cards as well as several other varieties of TDM hardware as new modules are developed. OpenZAP will also provide a simple interface to analog and ISDN signaling. The Idea behind OpenZAP is that it will be possible for applications to use a single API interface to control any TDM hardware supported by the library. OpenZAP provides a way to normalize all the various features so if one card lacks a particular feature, it can be implemented in software either within the main OpenZAP library or within the vendor-specific interface between the library and the native hardware API.

It almost seems impossible that we managed to accomplish so much in such a short time, but I think in the end, the old adage rings true “Necessity is the mother of invention”. There is still a long way to go but I would like to take this opportunity along the way to thank all of the people who helped get us this far. Below is a list of all of the people currently in our growing AUTHORS file.

Anthony Minessale II (That’s me!)
Michael Jerris (Our Invaluable build master and cross-platformologist.
[Yeah, I made that word up])
Brian K. West (Our devoted MAC guru. We would be nowhere without his help.)
Joshua Colp (Helped make the first SIP module which is now on the cutting room floor.)
Michal “cypromis” Bielicki (He’s been around since day 1. Thanks for believing!)
James Martelletti (He integrated mono into FreeSWITCH.)
Johny Kadarisman (Helped us get the python module working.)
Yossi Neiman (Wrote mod_cdr to gather call details.)
Stefan Knoblich (Helped us with our journey through SIP.)
Justin Unger (Found a good many bugs we didn’t want to have.)
Paul D. Tinsley (SIP presence and other great ideas.)
Ken Rice (How did his name get here?, JK A huge help with testing and patches.)
Neal Horman (A humongous help with the conference module.)
Michael Murdock (Our friend from CopperCom with tons of feedback and patches.)
Matt Klein (Tons of SIP help and help making sure we work on FreeBSD.)
Justin Cassidy (The techie behind the curtain making sure stuff works.)
Bret McDanel (The bravest of them all trying most things before anyone else and finding
all the hidden bugs, I mean easter eggs!)

Pin It

Leave a Reply