FreeSWITCH: New Release For The New Year



Welcome to 2009! With the new year comes a brand new release of FreeSWITCH. We are pleased to announce that version 1.0.2 is now available. It has been more than five months since the last official release, but the development team and community have been very busy during that time. We’ll first look at the new offerings in 1.0.2 and then we’ll break out the sunglasses and look at the bright future of FreeSWITCH.

New Features
The development team has packed many new features into FreeSWITCH. Among the most exciting are those that push the envelope of what is possible with VoIP. By teaming with Polycom, the FreeSWITCH team has made it extremely simple for users to have access to Polycom’s wideband (WB) and ultra-wideband (UWB) Siren(tm) family of codecs. Another exciting development is the addition of the 100% open-source CELT codec. CELT supports sampling rates as high as 48kHz, which is actually higher than the 44.1kHz rate used by traditional CDs. (As a proof-of-concept, Anthony and Brian ran FreeSWITCH on their Macs and Anthony played a guitar solo over a 48kHz session. Brian summed it up in one word: AWESOME.) These codecs are zero-cost alternatives to other patent-encumbered technologies, like G.729. As networking infrastructure improves, both in private networks and the public Internet, the use of WB, UWB, and HD telephony will become increasingly common.

Users will appreciate the advent of two oft-requested features: fax capability and a FreeSWITCH remote client. The FreeSWITCH community was largely responsible for adding mod_fax. In particular we are indebted to Steve Underwood for his fantastic spandsp library, without which the fax module would be all but impossible. The dialplan now can be used to route inbound or outbound fax calls. The FreeSWITCH client, fs_cli, is added along with a new general purpose C-language event socket library (esl). The client program is capable of connecting to local or remote instances of FreeSWITCH. An INI-style configuration file allows for multiple profiles. This handy tool makes it possible for an administrator to connect to multiple FreeSWITCH systems from a single terminal.

Windows developers will want to give a special thank you to FreeSWITCH community member Michael Giangnocavo, whose hard work has yielded the new mod_managed language module. In addition to supporting Mono, the new mod_managed also natively supports Windows .NET run-time libraries. It is now possible to build FreeSWITCH applications with Visual Studio languages like VB.Net and C#.

Other community members have been busy as well. Eric des Courtis has submitted a pair of modules: mod_http and mod_vmd. The mod_http module allows programmers to submit HTTP requests and retrieve the results using an API command. The mod_vmd module does voice-mail "beep" detection, which is useful for leaving answering machine messages "after the beep." This is much preferred over waiting for silence.

A number of enhancements to the dialplan have been made. In particular, call groups have been added as a convenient way to call multiple phones simultaneously. This has always been possible using pipes and commas in the bridge syntax, however this new method allows extensions to be put into various call groups. Creating groups of ringing phones is now easier, and the dialplan is much cleaner.

Many more enhancements and bug fixes have been added. In fact, the changelog has nearly 290 items. Here is a sampling of some of the other additions:

  • Can send HUP signal from command line, which rotates logs
  • New fsctl shutdown options: elegant, enhanced, asap, cancel
  • Outbound FIFO queues
  • New loopback extension (mod_loopback)
  • Can have FreeSWITCH be an Erlang node (mod_erlang_event, by Andrew Thompson)

Of course, new features are great, but what happens when you put FreeSWITCH into production?

Interoperability – FreeSWITCH in the Real World
Today’s world of VoIP is a hodgepodge of equipment vendors and service providers, all of whom follow the various VoIP-related RFCs to some varying degree. Since the RFCs are not binding – they are Requests For Comments after all – each vendor is free to interpret (or flatly ignore) these "standards" as they see fit. The inevitable result of this arrangement is the Vendor Blame Game when equipment and services fail to interoperate properly. The FreeSWITCH developers prefer to avoid this scenario by adhering closely to the RFCs. This can be a challenge because theory in RFCs does not always translate well into actual real-world application. Consider the IETF mantra: Be strict in what you send, liberal in what you accept. An experience in December 2008 demonstrates why this philosophy can be dangerous.

Teliax, a VoIP provider, migrated several servers from Asterisk to FreeSWITCH in December. All of their testing yielded no discernible issues, yet a number of customers quickly reported that DTMF tones were not working. After a lot of searching it was determined that any Teliax customer who had an upstream provider who used Sonus equipment was having DTMF trouble. The net result was that many Teliax customers had the initial perception that "it worked fine until you switched your servers to FreeSWITCH, therefore FreeSWITCH broke it." Of course, things are rarely so simple. After some brilliant detective work by Anthony Minessale (FreeSWITCH lead developer) it was discovered that Sonus equipment had always been mishandling RFC 2833 DTMF packets. Rather than FreeSWITCH being the culprit, it actually was the catalyst for uncovering a latent bug. (Anthony gives an eloquent explanation of the situation here.) FreeSWITCH was following the rule about "being strict in what you send" – in this case how it sends RFC2833 DTMF packets. The Sonus equipment, however, was not being liberal in return. Instead, it was discarding many DTMF packets that were perfectly compliant because the Sonus equipment had an incorrect assumption about what was valid and invalid! Thereafter, the FreeSWITCH team added a Sonus compatibility mode whereby FreeSWITCH will break the RFC for the sake of interoperability.

FreeSWITCH has other interoperability features as well. For example, some Snom hard phones have programmable soft keys. The modular nature of FreeSWITCH means that those with Snom phones can load mod_snom to take advantage of this feature. Those without Snom phones can save system resources by not loading this vendor specifc module.

FreeSWITCH: 2009 and Beyond
The FreeSWITCH development team will by no means be idle in 2009. In addition to handling more feature requests and bug reports from the growing community there are a number of things in the works, such as improving the documentation, adding T.38 support to the fax module, and expanding TDM support with the OpenZAP library. Another important aspect in 2009 is growing the proverbial FreeSWITCH ecosystem.

There are two specific projects that are a part of the ecosystem to keep an eye on. The first is TCAPI – an ambitious project that aims to provide a comprehensive Web-based front-end to FreeSWITCH. The second is pfSense. The pfSense project has incorporated FreeSWITCH as an optional package. This allows pfSense users to set up an appliance that can be a PBX or soft-switch. pfSense and FreeSWITCH user Mark Crane has also added a simple GUI to the pfSense/FreeSWITCH package. Look for more interesting things to come from both of these projects.

2009 looks to be a very interesting, very busy year for the FreeSWITCH team. A special thank you goes out to all of those who have helped with the project. Please keep up the good work, and spread the word about what a great project we have in FreeSWITCH.

Pin It

Leave a Reply