FreeSWITCH is free to download but carries real engineering costs: weeks of setup time, a steep XML dialplan learning curve, a low-level programmatic control interface called ESL, complex NAT traversal, active security threats from SIP scanning, and supporting infrastructure requirements. For carriers and teams building at telephony scale, that investment is worth it. For teams primarily trying to ship a voice product, SignalWire — built by the same team on the same engine — provides the power of FreeSWITCH without the infrastructure overhead.
FreeSWITCH doesn't cost money to download. But getting a working system costs weeks of engineering time, and keeping it running costs more than that.
That distinction matters. Teams sometimes discover it too late, after they've already committed the time and found themselves deeper in the stack than expected. This post is an attempt to surface those costs before you start, so you can make the right call for your situation.
If you already work in FreeSWITCH, this post isn't for you. Engineers who know the system, know the dialplan, and have operated it in production understand exactly what they're signing up for.
FreeSWITCH is exceptional software. It powers the voice infrastructure of some of the largest telecommunications operations in the world, and the teams running it at scale have earned that reliability through real investment. This post is for developers who are encountering it for the first time and trying to figure out whether to go deep.
The license is free. The infrastructure isn't.
FreeSWITCH is an open-source communications engine. It handles SIP, WebRTC, codec negotiation, media processing, and call routing at genuine carrier scale. You can download it right now at no cost.
What you get is the engine. There is no admin interface, no provisioning system, no dashboards, no billing, no call analytics, and no installer that leaves you with something working. Building something real on top of FreeSWITCH requires real work: network configuration, carrier connections, routing logic, monitoring, and the operational discipline to keep it stable under load.
The license being free does not change any of that.
The first cost: Time
Most developers with no prior FreeSWITCH experience spend weeks getting comfortable with the basics before touching anything close to production-ready.
Getting started involves installing and compiling the software, configuring SIP profiles, connecting endpoints or carriers, and working through early call flows. None of this is unusual for infrastructure software. What is unusual is how much depth each of those pieces has. What looks like a weekend project regularly becomes a multi-week effort.
The time cost is real before you write a single line of application code.
The second cost: The XML dialplan
FreeSWITCH defines how calls are handled through a system called the XML dialplan. It is powerful, expressive, and unlike anything most developers have encountered.
The dialplan uses a context and condition model. You are not writing a script that says "if the caller presses 1, do this." You are writing declarative XML that matches against channel variables, evaluates conditions in a specific order, and executes actions and anti-actions based on what matches. The mental model is its own thing, and it takes real time to internalize.
Most newcomers spend a meaningful chunk of their early weeks on dialplan logic alone, before approaching SIP trunk configuration, media handling, or anything more advanced.
The third cost: Learning to control FreeSWITCH programmatically
Once you understand how calls are routed, you'll want to control FreeSWITCH from application code. That happens through the Event Socket Library, or ESL.
ESL is not a REST API. There are no webhooks. The pattern is a persistent TCP socket with a plain-text protocol, and your application handles event streams directly. ESL runs in two modes: inbound, where your app connects to FreeSWITCH, and outbound, where FreeSWITCH connects to your app. Getting the direction wrong for a given use case produces baffling behavior that doesn't fail loudly.
Developers accustomed to programmable communications APIs will find this a significant adjustment. It is not a worse system, it is a lower-level one, and operating at that level takes time to learn.
The fourth cost: Networking and NAT
Networking is where most newcomers lose days.
SIP signaling and RTP audio travel differently across networks. A call can connect successfully at the signaling level while audio flows only one direction, or not at all. The symptom is that everything appears to work until someone picks up the phone. The root cause is NAT traversal, and it is almost never explained clearly in getting-started guides.
This is a property of how real-time media moves across networks. Understanding it is a prerequisite for a working deployment, and the learning curve is steep.
The fifth cost: Security
An exposed FreeSWITCH instance will start receiving SIP scanning traffic within hours of going online.
Attackers continuously probe for open SIP ports. If authentication is misconfigured, they can register endpoints or place outbound calls that bill to your carrier account. Toll fraud is a routine consequence of deploying FreeSWITCH without hardening it first.
Securing a FreeSWITCH deployment involves firewall rules, SIP authentication configuration, rate limiting, and log monitoring for anomalous call patterns. None of this is optional, but it also isn't front-and-center in the default getting-started experience.
The sixth cost: Infrastructure
Even early experimentation requires more than a single server.
You need a FreeSWITCH instance, SIP endpoints or softphones, carrier or SIP trunk connections, and some form of logging. Production deployments add load balancing, redundancy, and scaling on top of that.
SIP trunks are not plug-and-play. SIP is a standard, but carriers implement it differently. Getting a trunk connected reliably usually involves a debugging process that takes longer than expected. Every carrier adds its own variations, and working through them is part of the job.
When FreeSWITCH is the right choice
FreeSWITCH makes sense for specific situations:
Carriers building their own switching infrastructure.
Companies that need media processing at a scale no API platform will sell them.
Teams that already have FreeSWITCH engineers and are extending an existing deployment.
Organizations where owning the full telephony stack is a business requirement, not just a preference.
For those teams, the investment described above is worth making. FreeSWITCH is one of the most capable communications engines available, and the flexibility it provides at the infrastructure layer is not replicable through any managed platform.
For teams who are primarily trying to ship a voice product, and don't need or want to run a telephony stack alongside it, the calculus is different.
Why the people who built FreeSWITCH also built SignalWire
SignalWire was built by the same team that created FreeSWITCH. FreeSWITCH is the engine underneath everything we do. We know it as well as anyone, which is exactly why we built an abstraction layer on top of it.
The goal wasn't to replace FreeSWITCH. It was to make the power of FreeSWITCH available without requiring every developer to absorb 20 years of telephony infrastructure knowledge first. With SignalWire, you can make and receive calls, build AI voice agents, handle conferencing, and configure call routing without managing SIP profiles, dialplans, or carrier connections directly.
If you want to experiment with voice before committing to the infrastructure overhead, that's what SignalWire is for. Sign up for a free account and join our developer community on Discord.
Get started with SignalWire
Make and receive your first phone calls.
Configure your number and begin calling.
Forward calls to a personal number.
Use a SignalWire phone number to forward incoming calls to your personal phone and keep your personal number private.
Build Your First AI Voice Agent
Create your first AI voice agent. Build in SWML or Python.
Explore First Steps with Video
Build a fully customizable video application with the Browser SDK.
Frequently asked questions
What is the FreeSWITCH XML dialplan?
The XML dialplan is how FreeSWITCH defines call handling, routing, and processing logic. It uses a context and condition model that evaluates channel variables and executes actions in a specific order. It is not the same as scripting a call flow in application code.
What is the Event Socket Library (ESL)?
ESL is the interface for controlling FreeSWITCH programmatically. It uses a persistent TCP connection and a plain-text event protocol, with inbound and outbound connection modes. There is no REST API or webhook system.
What infrastructure do I need to run FreeSWITCH?
Even for early experimentation: a FreeSWITCH server, SIP endpoints or softphones, carrier or SIP trunk connections, and networking configuration. Production deployments require load balancing, monitoring, redundancy, and scaling strategies in addition.
What is toll fraud, and why does it matter for FreeSWITCH?
Toll fraud occurs when attackers exploit a misconfigured SIP deployment to place calls that bill to your carrier account. Exposed FreeSWITCH instances are actively scanned for this. Hardening your setup from the start is not optional.
What is SignalWire, and how does it relate to FreeSWITCH?
SignalWire was built by the team that created FreeSWITCH. It runs on FreeSWITCH infrastructure and provides an abstraction layer on top of it, so developers can build voice applications without managing SIP, dialplans, or carrier connections directly.
