FreeSWITCH hands you four install routes and keeps its documentation elsewhere

There is no install command anywhere, only four routes

Read the README's Getting Started section twice and you notice what is missing: no command, no package name, no configuration file. It says FreeSWITCH is available as source code on GitHub, that you can check out the development branch and build for Linux, Windows, MacOSX, and BSD, and that detailed instructions live at developer.signalwire.com under FreeSWITCH Explained.

What it does give is a routing table. For installing from packages, the FSGET script is marked Recommended, with tutorials for Debian, Raspberry Pi, and CentOS 7. For building from source, there are example Dockerfiles under `docker/examples` in the repository, plus Debian build-from-source tutorials marked Recommended, Raspberry Pi, and CentOS 7. Building Debian packages has its own script, FSDEB, documented at `/scripts/packaging/build` in the repository.

Then the downloads, which are the only concrete artifacts named:

https://files.freeswitch.org/releases/freeswitch/
http://files.freeswitch.org/windows/installer/x64/
https://github.com/freeswitch/freeswitch-sounds/releases

Note what is missing from that list: no package version. Pinning a FreeSWITCH release means choosing a tarball directory, not writing a version string.

Four cluecon templates pick your configuration format

The root of the repository carries four `.tmpl` files whose names begin with `cluecon`:

cluecon.tmpl
cluecon2.tmpl
cluecon_small.tmpl
cluecon2_small.tmpl

Nothing in the README explains what these files contain or how the `2` and `small` variants differ, so their role is settled by reading the files.

The root also has `conf/`, `dtd/`, `htdocs/`, `web/`, and `fonts/` directories.

Three build systems share one tree, and one of them says 2017

The build story is the widest gap between what the README promises and what the repository contains. The promise is Linux, Windows, MacOSX, and BSD. The tree delivers that through three separate toolchains:

configure.ac
Makefile.am
acinclude.m4
bootstrap.sh
devel-bootstrap.sh
ci.sh
cc.sh

Autotools is the main path, with `configure.ac`, `Makefile.am`, `acinclude.m4`, `bootstrap.sh` for a fresh checkout, and `devel-bootstrap.sh` for setting up a development machine. Windows has its own: `Freeswitch.2017.sln`, a `.sln.bat` wrapper, `msbuild.cmd`, and a `w32/` directory. A `cmake_modules/` directory sits alongside for CMake based builds. Packaging has a third axis, with `debian/` and `yum/` directories and a `freeswitch.spec` for RPM builds.

Read the solution file name as information, not trivia. A Visual Studio solution named 2017 tells you what a Windows contributor is expected to have, and it is the kind of detail that quietly ends platform support for newer toolchains. Two more root files matter for contributors: `.clang-format` defines the C style, and `swig_common.i` is the SWIG interface that language bindings are generated from.

Voice prompts ship as eight separate sound packages

FreeSWITCH treats voice prompts as separate downloadable artifacts. The repository root holds one spec for the project itself and eight for sound packs, named by locale and voice:

`freeswitch-sounds-en-us-callie`, `freeswitch-sounds-en-us-allison`, `freeswitch-sounds-en-ca-june`, `freeswitch-sounds-fr-ca-june`, `freeswitch-sounds-pt-BR-karina`, `freeswitch-sounds-ru-RU-elena`, `freeswitch-sounds-sv-se-jakob`, and `freeswitch-sounds-music`.

Windows is handled differently again, with a Windows Installer for x64 in the downloads list and Windows Sound Packages hosted in a separate repository, `freeswitch/freeswitch-sounds`, rather than in this tree.

The practical consequence for an installer is that the base package and the audio are two decisions, and the second one is easy to leave for later. The RPM spec files sitting in the repository root are the reason this is visible from a clone at all: they show that the sound packs are packaged, versioned, and separable from the switch itself.

The sponsor's cloud module ships inside the code base

FreeSWITCH is sponsored by SignalWire, which the README says was founded by the original developers of the project and is the primary sponsor. That relationship is not only financial. The README names the services SignalWire provides, SMS, SIP, serverless application hosting, and programmable telecom, and then points at a specific module: `mod_signalwire` is distributed in this code base and allows you to pair with SignalWire and extend your FreeSWITCH.

Read that as an architectural fact rather than a sponsorship note. The integration path to the vendor's cloud is distributed in the same code base, so evaluating a FreeSWITCH deployment means deciding whether that module stays enabled, and the README gives you no configuration guidance for turning it off.

Commercial support is handled separately and separately paid for. The Additional Help section says that if you need assistance, or have an interest in using a commercially supported build, you can contact [email protected] to learn about professional services. That address is the only support route the README names, and there is no statement about response times, coverage, or what a supported build changes.

Release notes and manuals live on a wiki, and the mailing list is archived

Nothing in the repository tells you what changed in a release. The README points to a Confluence space at freeswitch.org/confluence/ as the main documentation index, and to a separate Release Notes page inside it. Everything else follows the same pattern: the install tutorials for Debian, Raspberry Pi, and CentOS 7 are wiki pages, the API and explanation pages are on developer.signalwire.com, and the FSGET and FSDEB scripts are documented as pages under `/scripts/packaging` rather than as a man page you can read offline.

That has a cost when something breaks at 2am. You are reading a wiki page to find out which behavior a build introduced, and wiki pages change without a commit, so the text you followed in March may not describe the same steps in October. A git checkout of the wiki is not something the README offers.

Community channels show the same migration. Slack is described as the chat system where the developers, the team, and the most active users are present, hosted at signalwire.community, and the old mailing list is explicitly labeled ARCHIVED at lists.freeswitch.org. Contributions go through GitHub pull requests, which the README calls the recommended way, with an issue tracker alongside. Security reports have their own file, `SECURITY.md`, at the root.

The 1.11 line is moving, and the release page is the only changelog

Maintenance signals are straightforward. The three releases listed are v1.11.1 on 2026-05-26, v1.11.2 on 2026-08-09, and v1.11.3 on 2026-08-28, all titled as FreeSWITCH releases, and the last push to the default `master` branch was on 2026-10-28. That is an active cadence on a project whose primary language is C, and a patch level series that has stayed inside 1.11.

What the numbers do not give you is the content. There is no CHANGELOG file at the root, so the diff between 1.11.2 and 1.11.3 is only on the wiki page the README links. For a stack that other people's calls depend on, that is an uncomfortable gap: you can see that a version exists, and you have to trust a web page to learn what it changed.

Licensing is similarly thin here. A `LICENSE` file sits at the root, and the README says nothing about what it grants or requires, so an organization that needs to know the terms has to read that file rather than this document. The rest of the root is infrastructure: `src/` and `libs/` for the code, `tests/` for the suite, `docs/`, `fscomm/`, `support-d/`, and `scripts/` for the packaging tooling the install routes depend on.

Editorial conclusion

Adopt FreeSWITCH if you are replacing a proprietary switch with a software stack and you have someone who can hold autotools, MSBuild, and RPM packaging in their head at once, because that is what the repository asks of a contributor. Step back if you wanted a self contained install guide, since the README routes every step to a wiki page or a vendor site and ships no install command you can paste. Before you plan the rollout, check two things: which of the eight sound packages your call flows need, and whether `mod_signalwire` staying in the code base is acceptable for your deployment.

Frequently asked questions

Official sources

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