Welcome To FreeSWITCH
The World's First Cross-Platform Scalable FREE Multi-Protocol Soft Switch
FreeSWITCH is a scalable open source cross-platform telephony platform designed to route and interconnect popular communication protocols using audio, video, text or any other form of media. It was created in 2006 to fill the void left by proprietary commercial solutions. FreeSWITCH also provides a stable telephony platform on which many telephony applications can be developed using a wide range of free tools.
FreeSWITCH was originally designed and implemented by Anthony Minessale with the help of Brian West and Michael Jerris. All 3 are former developers of the popular Asterisk open source PBX. The project was initiated to focus on several design goals including modularity, cross-platform support, scalability and stability. Today, many more developers and users contribute to the project on a daily basis.
We support various communication technologies such as Skype, SIP, H.323 and GoogleTalk making it easy to interface with other open source PBX systems such as sipXecs, Call Weaver, Bayonne, YATE or Asterisk.
FreeSWITCH supports many advanced SIP features such as presence/BLF/SLA as well as TCP TLS and sRTP. It also can be used as a transparent proxy with and without media in the path to act as a SBC (session border controller) and proxy T.38 and other end to end protocols.
FreeSWITCH supports both wide and narrow band codecs making it an ideal solution to bridge legacy devices to the future. The voice channels and the conference bridge module all can operate at 8, 12, 16, 24, 32 or 48 kilohertz and can bridge channels of different rates. The G.729 codec is also available under a commercial license.
FreeSWITCH builds natively and runs standalone on several operating systems including Windows, Max OS X, Linux, BSD and Solaris on both 32 and 64 bit platforms.
FreeSWITCH supports FAX, both over audio and T.38, and can gateway between the two.
Our developers are heavily involved in open source and have donated code and other resources to other telephony projects including openSER, sipXecs, The Asterisk Open Source PBX and Call Weaver.
a Spec Sheet is available on our Wiki.
Kathleen King has been awesome enough to summarize our work on FreeSWITCH last week. Here's her report:
This week in the FreeSWITCH master branch we had 55 commits. Most of the commits this week were miscellaneous and several of those were related to promoting the speex codec to the core. We also got some new features, including additional options for voicemail storage organization. All in all, it was a good week and 18 Jira tickets were resolved.
The following bugs were squashed:
- fixed bug to allow for comma separation of email addresses in mod_voicemail
- fixed bug with AWS S3 URL validation in mod_http_cache
- fixed bug by removing a hard coded timezone in mod_xml_radius
- work around the Zoiper bug were all subscribes have an expires of 0
New features that were added:
- added a parameter vm-domain-storage-dir to mod_voicemail
- added a parameter storage-dir-shared to mod_voicemail
- added SIP dialing to just a domain
Improvements in cross platform build supports:
- fixed bug SRTP audio issue on Windows 7
- disabled the SRTP warning for Windows
- build fix for hostname lookups in mod_sofia and mod_command's gethost
- updated to OpenSSL 1.0.1f in Windows build
- fixed compiler issue on Windows with mod_managed
In terms of stability these were the use cases that were fixed:
- fixed segfault in mod_sofia related to SIP presence when the presence domain could not be found
- fixed segfault in sofia related to inbound SIP registrations
Kathleen King was kind enough to summarize the changes in FreeSWITCH this week from our git repository. Here's her state of the state of FS:
This past week was productive for the Freeswitch master branch with many new changes and bug fixes. On the packaging front, .zip joined tar.xz in the default source release archives. Located here: http://files.freeswitch.org/
In terms of stability there were several use cases that were fixed:
-- Fixed mod_lua crashes related to build symbols introduced during upgrade from lua 5.1 to lua 5.2
-- Fixed a crash in mod_conference related to whisper tones
-- Fixed a crash in mod_shell_stream
-- Fixed a crash involving T-38 in mod_sofia when the call in bridged between TDM and SIP
Several new features were added:
-- New command 'gethost' allows for a DNS lookup from the Freeswitch console
-- Added bypass-media-after-hold to complement the existing parameter resume-media-on-hold with more information located at:
-- Added capability to record conference with a single participant
-- Added support for Sofia to configure accepted TLS versions and enabled support for perfect forward secrecy.
-- Expanded Sofia profile status to include websockets
Improvements in cross platform build supports:
-- Spandsp improvements for BSD
-- Some initial build fixes for Ubuntu 14.04
-- Fixing some compiler optimization snafus
In the FreeSWITCH project we include many libraries in our own tree. Keeping these up to date can be a challenge. Let's look at one way that git makes this easier.
We'll use speex as an example. The last time we updated speex from upstream was back in 2009 when Mike Jerris merged Speex v1.2rc1. Since then we've made a number of changes ourselves to speex, almost exclusively relating to build issues. If we're going to pull in a new version of speex from upstream we don't want to lose these changes.
This can make updating difficult because we can't just copy over a more recent version. One solution is git cherry-picking. This lets us pull in upstream changes one patch at a time.
But how can we use cherry-picking when freeswitch and speex are two separate git repositories with non-overlapping histories? This is where git's subtree merge support comes in.
Let's start with a clean FS clone:
$ git clone git://git.freeswitch.org/freeswitch.git && cd freeswitch
Now let's add the speex repository as an additional remote:
$ git remote add speex http://git.xiph.org/speex.git/ && git fetch speex
Now we'll look at what's changed in speex since we last updated:
$ git log --reverse --stat Speex-1.2rc1..speex/master
Author: Jean-Marc Valin <jeval@station513.(none)>
Date: Mon Aug 4 18:21:40 2008 -0400
Sorting out #include "" from #include <> and using relative paths for including
configure.ac | 2 ++
include/speex/speex.h | 9 +++++++--
43 files changed, 107 insertions(+), 62 deletions(-)
Author: Jean-Marc Valin <jeval@station513.(none)>
Date: Tue Aug 5 12:00:05 2008 -0400
Narrowband state now contained in a single block
libspeex/modes.c | 14 +++++++-------
libspeex/nb_celp.c | 65 ++++++++++++-----------------------------------------------------
libspeex/nb_celp.h | 46 ++++++++++++++++++++++++++++------------------
3 files changed, 47 insertions(+), 78 deletions(-)
We'll skip the first commit for now because it conflicts with some build changes we've made. Let's pick the narrowband state change into our tree. Here's where the subtree merge comes in:
$ git cherry-pick --strategy=subtree -Xsubtree=libs/speex 8d225323179a4642c58df0466beb960b0b367f29
[master 2962cfb] Narrowband state now contained in a single block
Author: Jean-Marc Valin <jeval@station513.(none)>
3 files changed, 47 insertions(+), 78 deletions(-)
And that's it! That's all there is to it. We've now picked that commit into our tree, and it's ready to be pushed.
But instead, let's pull that commit out so we can try something else:
$ git reset --hard HEAD^
Let's say that we want to completely update speex and are willing to manually deal with any conflicts. We could run something like this:
$ cd libs/speex
$ git rev-list --reverse Speex-1.2rc1..speex/master | xargs git cherry-pick --strategy=subtree -Xsubtree=libs/speex
CONFLICT (modify/delete): libs/speex/libspeex/testresample.c deleted in 790c69cb48818e3f9d6feabed3a8840348d339b2 and modified in 785e61a593c61ebc0afee5d87eca9cc73e16d6a6. Version 785e61a593c61ebc0afee5d87eca9cc73e16d6a6 of libs/speex/libspeex/testresample.c left in tree.
CONFLICT (content): Merge conflict in libs/speex/libspeex/Makefile.am
CONFLICT (content): Merge conflict in libs/speex/configure.ac
error: could not apply 785e61a... Sorting out #include "" from #include <> and using relative paths for including
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
When we hit a conflict like this, we'll look at the output of git status and manually merge the conflicting files:
$ git status -s | grep 'UU\|DU'
$ emacs configure.ac libspeex/Makefile.am
Once we're sure everything is OK, we'll tell git by running:
$ git add -A .
Then we can continue our cherry-picking operation:
$ git cherry-pick --continue
Each time we hit a conflict, we repeat this process. The nice thing here is that we get to deal with the conflicts one at a time; we get to merge while looking at the context and intention of each patch rather than just having a lump of conflicts as we would trying to merge a more recent tarball. This often makes the process simpler.
If you'd like to learn more, join us on our weekly conference call and ask your questions.
Many people have asked over the years why FreeSWITCH bundles so many libraries. The core developers are certainly aware of the downsides of this approach. We know it makes it difficult to stay on top of updates to these libraries. We know well that it complicates inclusion of FreeSWITCH in the major distributions. And we certainly know that it makes a clean build of FreeSWITCH take a very long time with all modules enabled.
But in every case where we've bundled a library with FreeSWITCH, there was a reason. Here are some of the major ones:
* We've become the upstream for Sofia-SIP. The original developer has moved on, and we've taken over maintenance and improvements to the library.
* The author of Spandsp, the inimitable Steve Underwood, now commits updates to his library directly into the FS source tree, so ours is always the most recent version.
* SQLite breaks in the sort of highly-multithreaded model that we use in FS, and we were never able to get our patches included in upstream, so we've essentially forked (which is encouraged by the SQLite project). While FS can build with more recent upstream versions of SQLite, it is very unstable.
* Many libraries we need, such as the most recent one, libv8, have (or at one time had) obsolete versions packaged in the major distros. Debian, for example carries 3.14 and we need 3.24 to make mod_v8 work at all.
* At one time, CentOS had patched libraries such as curl in ways that just completely broke them in our use case (e.g. they linked against libraries such as NSPR unnecessarily), so even if an apparently suitable system library was there, we couldn't use it.
* For many years, distros packaged major libraries built without thread safety.
* Many libraries which may now have acceptable versions in most major distributions did not at one time, and someone would have to go through each major distribution and verify that the library there is now actually acceptable, perhaps updating FS to use a newer API, and test the feature under load.
* When two distributions carry incompatible versions of the same library, it becomes very difficult to support both when building against system libraries. For Debian alone, we currently support sid, jessie, wheezy, and squeeze, and library versions and availability vary greatly between those releases.
* Though strictly distinct from the issue of bundling, we believe in the merits of static linking certain libraries. We sympathize with many statements Rob Pike has made about this issue, and with a piece by Roman Shaposhnik you can read here:
...and comments on that piece by Anthony here:
* Building on BSD, OS X, and Windows are project goals, and they do not provide these libraries.
We're happy to accept patches that would make FreeSWITCH build optionally against system libraries. No one has yet(!) stepped up to do this work. And while it would be a very valuable contribution, it's just not a priority for the core developers who focus on other important work.
If you're interested in helping out here, we're interested in helping you. Get in touch with us.
We like to stay on the cutting edge, so the FreeSWITCH master branch has moved to Lua 5.2 for mod_lua. If you need to stay on Lua 5.1 for awhile, fear not, we've added a new folder, src/mod/legacy in which you'll find the old module. The FreeSWITCH 1.2 stable branch will also be keeping Lua 5.1 for its lifetime.
Be sure to send Peter your love, but more importantly, reports on how the new mod_v8 works for your scripts. We believe mod_v8 should be a drop-in replacement for mod_spidermonkey.
We'll be having Peter Olsson join us on today's conference call at 1800 UTC (which you can reach at sip:email@example.com or http://conference.freeswitch.org/). He'll be talking about his new module, mod_v8, which is intended to replace mod_spidermonkey.
Join us if you can to learn about this new addition to FreeSWITCH.
We're making some changes to the format of the conference call for 2014. We'll be starting the call on time, and trying to keep the length of the call to under one hour so more busy people can join in.
The question of why FreeSWITCH uses so many embedded libraries comes up all the time. We first addressed this back in 2007, and wow has time flown and FreeSWITCH grown up!
Many users and new faces question this practice on a regular basis, so I thought it might be time to revisit the reasons why. I thought about writting a whole new article on this subject, but having gone back and re-read the original articles, I think its best to just link them here.
For the original post on FreeSWITCH.org see http://www.freeswitch.org/node/56 and for an indepth explanation see Roman Shaposhnik's write up from when he was Sun Studio Linux Architect, Engineering Manager at https://blogs.oracle.com/rvs/entry/what_does_dynamic_linking_and
[This story was delayed from 10/24 to give a vendor time to respond. As it turned out, that vendor decided to take no action.]
Cal Leeming (foxx on IRC) was kind enough to join our weekly conference call to raise awareness about the importance of secure provisioning.
Many providers put configuration files for IP phones on publicly-accessible servers. Often these files are neither encrypted nor protected by any form of authentication. All you need to access these files is the URL scheme used by the provider and the MAC address of the phone. As we'll see in a moment, this is in fact essentially required for zero-touch provisioning to work as it does today.
Let's say you want the contents of one of these files. How might you find the URL scheme used by a provider? Previously if you couldn't find it by guessing, you would probably need to get a phone from that provider and then either extract the firmware or watch the traffic with Wireshark. Having to do that for many providers, while not infeasible at all, does present something of a barrier.
Fortunately (for the bad guys), phone manufacturers have decided to adopt a technique (I hesitate to say 'technology') called zero-touch provisioning or RPS (Redirection and Provisioning Service). The idea behind RPS is that providers can remotely provision new phones they've never physically handled at all.
After a phone is sold to a service provider (perhaps via a wholesaler), the service provider makes an API call that tells the manufacturer they now own a particular phone, identified by MAC address, and to where requests for the phone's configuration should be redirected.
Now when a request is made to the manufacturer's publicly accessible server for the phone's configuration, their server redirects the request to a file on the provider's configuration server. If an attacker simply knows the MAC address of a phone, she can make a request to the manufacturer's RPS server, which will redirect to the provider's server, which -- more likely than not -- will hand over the plaintext file containing the phone's configuration.
With this configuration file, the bad guys can impersonate the user. That would be bad enough, as it would likely give them access to the user's voicemail or other privileged services.
More likely, however, the bad guys will be interested in committing toll fraud. They'll use the stolen account to pump a large volume of calls to high cost foreign rate centers where -- through complicated business mechanisms -- they'll be able to collect a portion of the toll charges paid by the victim and the other intermediating carriers. The dollar amounts involved in this kind of fraud can be shockingly high.
But we're getting ahead of ourselves. How will the bad guys find a valid MAC address for a phone?
As it turns out, this isn't difficult, and RPS makes this much easier. MAC addresses are 48 bits long, so there are 2^48 of them. The first 3 bytes (24 bits) of the address compose the Organizationally Unique Identifier (OUI). One or more of these are assigned to organizations like Yealink or Snom. This leaves 24-bits for the manufacturer to assign unique addresses to their equipment. In practice, for a particular model of phone, a manufacturer might assign addresses out of a space as small as 16 bits, and they are likely to assign these nearly sequentially. Therefore, if you know the MAC address of just one phone, and search the surrounding 2^16 addresses, you're likely to find many valid phone MAC addresses.
In Cal's testing, he found he could make at least 1000 requests per second against manufacturers' RPS servers. It's likely that determined bad guys with a cluster of systems could do better.
1000 requests per second is about 2^10. So we can search a 2^16 space in only 2^(16-10) = 2^6 = 64 seconds. And because of RPS, we don't have to repeat this search against N different service providers. We simply target our search against the manufacturer's RPS server and they'll tell us who the service provider is and where we can find the provisioning file.
This really is as bad as it sounds. What's perhaps worse, however, is how little surprise there was on our call. This is not a disclosure in the common sense of the word. Everyone familiar with these systems already knows about this problem -- though there was some debate on our call about whether there really may exist people dull enough to both understand the system design and miss this problem (I doubt it). The mission instead is to remind people that this flaw, though widely accepted, is a recipe for failure that should not be tolerated. As soon as attackers organize around exploiting this weakness, the damage to the industry could be massive.
Problematically, there is no way for service providers -- without assistance from phone manufacturers -- to completely address this weakness without forfeiting the benefits of zero-touch provisioning. Providers can configure their provisioning servers to require a valid username and password, and then assign unique credentials to each phone. When the phone supports HTTPS provisioning, this would be reasonably secure as long as you could securely deliver the credentials.
(Some phone firmwares allow the service provider to encrypt the configuration file using a key the server shares with each phone. This is isomorphic, for the purposes of our discussion.)
But delivering the credentials securely is exactly the problem with zero-touch provisioning in its current form. The first time the phone connects to your servers (via an RPS redirect), it won't have any credentials. You'll have to decide whether to issue the phone the credentials it will use in the future. If you do so, you'll also need to never issue this phone credentials in plaintext again (otherwise you won't have improved security at all). But you have no way of knowing whether what's connecting to your servers is the phone you sold, or an attacker impersonating it. How can you decide whether to give it the credentials? If you make the wrong choice, you'll open yourself up to toll fraud, and you'll lock out the actual phone.
The obvious solution to this issue is for the manufacturer to include a unique private key with each phone (ideally via a TPM) such that the phone could securely authenticate itself to servers. Doing only this, however, would complicate the sale of phones through distribution as the public components of the keys would need to be distributed and managed.
A more sane solution would be to sign each phone's public certificate (which should contain the phone's MAC address) with the manufacture's private key. The phone could then provide its signed public component when authenticating to the service provider, and the provider could check the MAC address in the certificate and check the signature against the manufacturer's public key component. As long as the manufacturer securely created and managed their certificate authority, this would work fine.
There are other solutions that are somewhat less elegant, such as dispensing with "zero-touch" and forcing the entry of a PIN-like code on each phone.
It will be interesting to see how manufacturers respond to the increased attention being focused on this issue. Will they take down their RPS servers? Will they move to more secure provisioning models? Or will attackers need to inflict large financial damage to their customers before the manufacturers respond? Time will tell.
Cal Leeming (foxx on IRC) was kind enough to join our weekly conference call yesterday to discuss a very interesting issue that apparently has at least one phone manufacturer in a bit of a panic. We're withholding details for now to give that manufacturer time to react. Expect a more detailed story here in a couple of days.