Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
FreeSWITCH 1.2

You're reading from   FreeSWITCH 1.2 Whether you're an IT pro or an enthusiast, setting up your own fully-featured telephony system is an exciting challenge, made all the more realistic for beginners by this brilliant book on FreeSWITCH. A 100% practical tutorial.

Arrow left icon
Product type Paperback
Published in May 2013
Publisher Packt
ISBN-13 9781782161004
Length 428 pages
Edition 2nd Edition
Concepts
Arrow right icon
Toc

Table of Contents (24) Chapters Close

FreeSWITCH 1.2
Credits
About the Authors
About the Reviewers
www.PacktPub.com
Preface
1. Architecture of FreeSWITCH 2. Building and Installation FREE CHAPTER 3. Test Driving the Example Configuration 4. SIP and the User Directory 5. Understanding the XML Dialplan 6. Using XML IVRs and Phrase Macros 7. Dialplan Scripting with Lua 8. Advanced Dialplan Concepts 9. Moving Beyond the Static XML Configuration 10. Controlling FreeSWITCH Externally 11. Web-based Call Control with mod_httapi 12. Handling NAT 13. VoIP Security 14. Advanced Features and Further Reading The FreeSWITCH Online Community Migrating from Asterisk to FreeSWITCH The History of FreeSWITCH 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.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image