FreeSWITCH: a software defined telecom stack you build from source

What FreeSWITCH is for, and who ends up using it

FreeSWITCH describes itself as a Software Defined Telecom Stack, replacing proprietary telecom switches with a software implementation that runs on commodity hardware. The README states it runs from a Raspberry Pi to a multi-core server, which sets the intended range: the same codebase is meant for a small embedded endpoint and for a machine terminating many concurrent calls. The topics attached to the repository are sip, voip, webrtc, telephony and iot, so the project positions itself across classic SIP trunking, browser-based calling and device connectivity rather than in one narrow niche.

The audience is engineers, not administrators. The README's Getting Started section says FreeSWITCH is available on GitHub in source code format and that you can check out the development branch and build for Linux, Windows, MacOSX and BSD. There is a Windows installer listed under Downloads, and package tutorials for Debian, Raspberry Pi and CentOS 7, but the primary distribution is the source tree. If your team has never compiled a C project with autotools or CMake, the first day will be spent on the toolchain, not on telephony.

FreeSWITCH is not a hosted service. The README is explicit that SignalWire is the primary sponsor and was founded by the original developers, and that mod_signalwire, distributed in this codebase, lets you pair a FreeSWITCH instance with SignalWire. That module is the bridge to a commercial platform; everything else in the tree runs on your own hardware.

How the stack is put together in the repository

The top-level layout tells you the architecture before you read any documentation. There is src/ for the core, libs/ for dependencies, conf/ for the default configuration, modules are built from the source tree, and clients/ holds client-side code. The build system appears twice: configure.ac and Makefile.am for the autotools path, and cmake_modules/ alongside Freeswitch.2017.sln for the Visual Studio path on Windows. bootstrap.sh and devel-bootstrap.sh prepare the autotools environment, which is the usual first step before configure runs.

The design is modular. Functionality arrives as modules loaded by the core, and the README names one of them directly: mod_signalwire, distributed in the codebase, pairs an instance with SignalWire. The dtd/ directory holds document type definitions, which is consistent with a system configured through XML files rather than a database-backed admin UI. Configuration lives under conf/, and the presence of a dedicated conf tree at the top level rather than inside src/ signals that the running system reads external files you are expected to edit.

Signalling and media are separated in the usual way for this class of software: SIP handles session setup, and the media path carries audio and video, with WebRTC listed among the topics. The README does not document the internal call state machine or the media handling details, so treat the repository layout and the linked documentation index as your sources rather than expecting the README to explain the core. For a project of this size, that gap is normal, but it means the README alone will not get you to a working dialplan.

Installing FreeSWITCH: packages, source and a first call

The README gives two install routes. The package route points at scripts/packaging and labels FSGET as recommended, with per-platform tutorials for Debian, Raspberry Pi and CentOS 7. The source route points at docker/examples for Dockerfiles that build FreeSWITCH and its dependencies, and at per-platform build tutorials, with the Debian build-from-source page marked recommended. For Debian packages built from source, the README points at scripts/packaging/build.

The repository's own bootstrap step is the one command you can trace to a file in the tree. Running it prepares the autotools build files before configuration:

./bootstrap.sh

After that, the README defers to the Debian build-from-source tutorial rather than printing the configure and make invocations, so the exact flags are not in the README. Do not guess them; follow the linked page. If you prefer a container, the README points at the Dockerfiles under docker/examples, which build FreeSWITCH and its dependencies from source:

git clone https://github.com/signalwire/freeswitch.git
cd freeswitch/docker/examples

From there the example Dockerfiles are the build recipe. On Windows, the README lists a Windows Installer under Downloads, and the repository carries Freeswitch.2017.sln and msbuild.cmd for the Visual Studio build, so the Windows path is a solution file rather than a shell script.

For a first real use, the README does not walk through placing a call. It directs you to the FreeSWITCH-Explained documentation site for more detailed instructions and to the Confluence index for documentation generally. A first call therefore depends on configuration under conf/ that the README does not describe. Budget time for that documentation, because nothing in the repository README substitutes for it.

Where FreeSWITCH gets in your way

The licence is the first thing to check. The repository reports NOASSERTION for the licence field, and a LICENSE file exists at the top level. That means GitHub could not classify it automatically, so you have to read the file yourself before shipping a product on top of it. This article cannot tell you what the terms are; the file can.

The second limitation is the documentation split. The README is a signpost, not a manual. It links to freeswitch.org/confluence for the documentation index and to developer.signalwire.com for detailed instructions, and it lists release notes on Confluence rather than in the repository. Nothing in the README documents rollback, upgrade procedures or how configuration changes migrate between versions, so an upgrade plan has to come from those external pages or from your own testing.

The third is the support model. The README offers [email protected] for assistance or a commercially supported build, which is a clear signal that the free path assumes you can debug a C telephony stack. Community help is on Slack at signalwire.community, and the mailing list is marked ARCHIVED in the README, so the older mailing list route is closed. If your team needs a vendor to answer the phone at 3am, this is the wrong tool unless you take the commercial build.

Finally, the platform tutorials skew old. The README lists CentOS 7 and Debian tutorials, and CentOS 7 is long past its support window. The package instructions may still work, but you should expect to adapt them.

FreeSWITCH versus Asterisk: different shapes of the same job

The comparison people search for is FreeSWITCH against Asterisk, and the difference is architectural rather than cosmetic. Asterisk grew out of the PBX tradition, where the dialplan is the centre of the system and the configuration model is oriented toward extension logic. FreeSWITCH is presented in its own README as a software defined telecom stack, and the repository layout reflects that: a core with loadable modules, XML configuration under conf/, and DTD files describing the configuration documents. The emphasis is on the stack as a programmable platform rather than on a PBX application.

That difference shows up in how you extend each system. FreeSWITCH ships mod_signalwire in the codebase and pairs with a hosted platform, so the intended path for scaling beyond your own hardware is a commercial interconnect. Asterisk's ecosystem is oriented differently, with its own module set and a long history of distributions that wrap it into a finished PBX. If what you actually want is a PBX with an admin interface, neither project's README is a substitute for a distribution built on top of it.

The practical test is what you are building. If you are writing an application that controls call setup and media programmatically, FreeSWITCH's module and XML model is the closer fit. If you are replacing an office phone system and want extensions, voicemail and a web UI on day one, you are choosing between distributions, not between these two cores. This article does not benchmark either one, and the README contains no performance numbers, so treat any throughput comparison you read elsewhere as unverified.

Maintenance, releases and what an upgrade costs you

The repository is not archived, and the last push was on 2026-09-22, one day before this article's reference point, so the project is being worked on now. Recent releases are v1.11.1 on 2026-05-26, v1.11.2 on 2026-08-09 and v1.11.3 on 2026-08-28. That cadence, roughly a minor release every few months through 2026, matters for planning: you are tracking a moving target, and the README points to Confluence for release notes rather than keeping them in the tree.

The upgrade cost is not the build. It is the configuration under conf/ and the XML documents the DTDs describe. Because the README does not document rollback or a configuration migration path, the safe approach is to keep your configuration in version control separately from the source tree and to test a new release against a copy of it before touching production. The repository gives you a tests/ directory and a ci.sh script, which tells you the project maintains its own test and continuous integration setup; whether those tests cover your configuration is a different question.

On licensing, the repository reports NOASSERTION and ships a LICENSE file. Read that file and have your own counsel assess it if you are embedding FreeSWITCH in a product. Nothing here is legal advice, and the licence identifier alone does not tell you the obligations.

The Windows path has its own maintenance burden. Freeswitch.2017.sln and msbuild.cmd are named for a Visual Studio generation that is several releases old, so expect to retarget the solution if you build on Windows.

Editorial conclusion

Adopt FreeSWITCH if you need a programmable SIP and media core that runs on commodity hardware from a Raspberry Pi up to a multi-core server, and you have someone comfortable building C projects and reading configuration XML. Do not adopt it if you want a packaged PBX with a browser admin panel and a support contract out of the box; the README points to [email protected] for commercially supported builds, which tells you the free path is self-supported. Verify first that you can complete a build on your target platform and that your required modules are present in the source tree, because the repository ships the stack, not a turnkey appliance.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. signalwire/freeswitch on GitHub