Book Image

FreeSWITCH 1.2 - Second Edition

Book Image

FreeSWITCH 1.2 - Second Edition

Overview of this book

FreeSWITCH is an open source telephony platform designed to facilitate the creation of voice and chat-driven products, scaling from a soft-phone to a PBX and even up to an enterprise-class soft-switch. It is always exciting to design and build your own telephony system to suit your needs, but the task is time-consuming and involves a lot of technical skill."FreeSWITCH 1.2" comes to your rescue to help you set up a telephony system quickly and securely using FreeSWITCH. It is rich with practical examples and will give you all of the information and skills needed to implement your own PBX system.You will start with a detailed description of the FreeSWITCH system architecture. Thereafter you will receive step-by-step instructions on how to set up basic and advanced features for your telephony platform.The book begins by introducing the architecture and workings of FreeSWITCH before detailing how to plan a telephone system and then moves on to the installation, configuration, and management of a feature-packed PBX. You will learn about maintaining a user directory, XML dial plan, and advanced dial plan concepts, call routing, and the extremely powerful Event Socket. You will finally learn about the online community and history of FreeSWITCH."FreeSWITCH 1.2" is an indispensable tool for novice and expert alike.
Table of Contents (24 chapters)
FreeSWITCH 1.2
Credits
About the Authors
About the Reviewers
www.PacktPub.com
Preface
Index

New ideas and a new project


At this point I had accumulated several new ideas: some tested, some not, some that were going to require some major changes to Asterisk. My team—Brian West, Michael Jerris, and I—were donating a lot of time to the Asterisk project. We helped maintain the issue tracker. We fixed bugs and helped out every week by hosting a developer’s conference call. We even hosted a mirror of the code on our site. We were very involved yet some of our new ideas were causing some political turmoil in the Asterisk community, as there was an unnecessary competition among the various developers. Every contributor to Asterisk must sign a form stating that all the code you write that may be included in the Asterisk code base will automatically have a royalty-free license for Digium, the owner of Asterisk, to do what it pleases with your code. This was so they could sell the unrestricted licensing to would-be buyers for a high price. Not exactly the spirit of open source but that’s another story. I think this alienation caused some strife between the volunteer developers like myself and the developers who were hired outright by Digium to work on Asterisk.

Even with the tension, we were dedicated to the project and really wanted to see it succeed. We were having those regular weekly conference calls, and they were really starting to help get the developers motivated. We decided that we should have a live in-person meeting so we could all share our knowledge of telephony and hang out for a few days. We had no idea what we were doing, but we decided to do it anyway and call it ClueCon. Having a clue meant you knew what you were doing, so ClueCon was a conference to help everyone to "get a clue". I do acknowledge, I just said we did not know what we were doing either, so there was a bit of irony that people with no clue would start a clue con. However, that turned out to be more of a blessing than a problem, and the clue we were referring to was in regards to telephony, not to running conferences.

Therefore, with several months until the first ClueCon, in the spring of 2005, we had one of our usual weekly conference calls and began talking particularly in detail about several shortcomings of Asterisk. This is not uncommon, because our primary goal was to identify the problems and convert them into solutions. There was, at the time, a fairly large unruly crowd who was tired of the endless problems they were experiencing with Asterisk. Many of them joined this weekly call, hoping to persuade us to look at one of their issues. The more I thought about it, the bigger the task seemed to unravel some of the big architectural problems that were plaguing us. Many concepts were monolithic in nature and would not scale. Many features had several users dependent on them, and changing them with a goal of improvement could lead to regressions in functionality. It just seemed like some of the problems could only be solved with a sledgehammer, yanking out some older code and doing some serious rewrites to some of the deeper recesses of the core code. This did not seem very viable since it would render Asterisk unusable for months if not a year or more. That’s when I had the idea: let’s make a 2.0!

It was not the worst idea; I knew it would be challenging but, hey, I thought we could start a new code base alongside the old one, so we could tear out the parts of the code that caused the most problems and replace them while still maintaining the original code for the users who depended on something that worked. I was pretty excited about the idea and equally shocked when the project leader reacted to my suggestion of the idea, and he appeared equally shocked that I would even suggest such a thing, so, in short, we did not make an Asterisk 2.0. Here I was, with a ton of ideas and a clear mind on exactly what I did and did not like about Asterisk with nowhere to write them down.

I gazed at that empty text-editor buffer open in an empty directory for an hour. I knew what I wanted to do, but it was hard to bring it to words. I never could find the words until I added in several oddly arranged punctuation around them. Those were not your everyday words; they were symbol names and variable declarations. I was writing C code. In a few days, I drafted up a basic application in C, tying together some of my favorite tools from my past experience in programming. I had the Apache Portable Runtime or APR library, the Perl language, and a few other packages. I built a core and a loadable module structure, a few helper functions to use memory pools, and I had a simple command-line prompt that would allow you to type help if you wanted to see a sarcastic comment about there being no help for you, and exit to shut the application down. I made a sample module that would let you telnet to a specific TCP port and have it echo back everything you typed and a very basic state machine. I called it Choir. I thought of my idea as a series of parts working together to make one unified voice like a choir. After that initial coding session, I put it down for a while. ClueCon was coming and I did not want to rush things as I still thought that there was much to consider.