FreeSWITCH in Production: Architecture & Real-Time AI

By Stan Reshetnyk, CTO, Trembit — protocol-level WebRTC, SIP, and media-server engineering · Last updated 3 August 2026

FreeSWITCH is an open-source, cross-platform softswitch: a programmable telephony and media engine that handles SIP signaling, call routing, conferencing, and media processing, and can run as a PBX, a class 4/5 carrier softswitch, a SIP-to-WebRTC gateway, or the telephony backend behind a voice AI agent. One engine, several roles, selected through configuration and modules rather than separate products. Most FreeSWITCH content stops at “install it and place your first call.” This guide is about the questions that come after that: does it scale, does it hold up under security and compliance scrutiny, and can it carry a real-time AI voice pipeline.

Key takeaways
– FreeSWITCH is an open-source telephony and media-server platform licensed under MPL 1.1 and maintained by SignalWire, the company founded by FreeSWITCH’s original creators. “
– It runs as a PBX, a carrier-grade softswitch, a conferencing server, a SIP-to-WebRTC gateway, or the telephony layer behind a voice AI agent. The role is a configuration and module choice, not a different product.
– The core is written in C for performance and is driven externally through the Event Socket Layer (ESL), which lets an outside application (including an AI or LLM pipeline) control calls without sitting in the media path.
– Production FreeSWITCH is a different discipline from tutorial FreeSWITCH. Clustering and high availability, security hardening, and regulatory compliance (HIPAA/GDPR) are where most public guides stop short.
– Nearly every fresh 2026 FreeSWITCH article is about wiring it to an LLM for a voice bot. The scaling, security, and compliance layer underneath that build is the part almost no one writes about, because most teams haven’t run it.
– Trembit runs FreeSWITCH in production today as a SIP proxy and PSTN bridge inside a HIPAA/GDPR-compliant healthcare video platform, connecting WebRTC clients to phone users and to hospital SIP infrastructure. Details in the callout below.

If you own the build-versus-buy decision rather than the code, the two sections worth your time are how FreeSWITCH compares to the alternatives and when to choose it. If you’re already committed to FreeSWITCH and researching production realities, read straight through.

What is FreeSWITCH, and what is it used for?

FreeSWITCH is a software softswitch. It sits between callers and networks, decides how calls are set up and routed, and processes the media (audio and video) in between. Because behavior is defined by modules and a dialplan rather than baked into a fixed product, the same binary covers a wide range of real deployments:

• Business telephony / PBX — extensions, voicemail, call queues, IVR menus, hunt groups.
• Carrier-grade softswitch — class 4 (transit/trunking between carriers) and class 5 (subscriber-facing) call handling at volume.
• Audio and video conferencing — multi-party rooms via mod_conference.
• IVR and call automation — menu trees, prompts, and call flows driven by the dialplan or an external application.
• SIP trunking and PSTN connectivity — bridging voice-over-IP infrastructure to the traditional phone network.
• WebRTC gateway — connecting browsers and mobile apps to SIP endpoints, via mod_verto or SIP-over-WebSocket.
• Telephony backend for AI voice agents — the media and call-control layer that a speech-to-text, LLM, and text-to-speech pipeline plugs into.

That range is the reason FreeSWITCH keeps showing up in “FreeSWITCH software” and “FreeSWITCH PBX” searches even though it isn’t a packaged PBX product the way FreePBX is. It’s a toolkit for building the telephony system you actually need, which is its strength for teams that want control and its cost for teams that just want a working phone system fast.

How is FreeSWITCH built, and what’s inside it?

FreeSWITCH is a small C core surrounded by a large set of loadable modules. The core handles the state machine of a call (setup, media negotiation, teardown) and the threading and scheduling that keep audio flowing. Almost everything a deployment actually does lives in modules:

• mod_sofia — the SIP stack. It registers endpoints, handles SIP signaling, and terminates SIP trunks. This is the module that talks to phones, carriers, and other SIP systems. “
• mod_conference — the conferencing engine that mixes multiple participants into a room.
• mod_verto — FreeSWITCH’s native WebRTC signaling, so browsers can connect without a separate gateway.
• Codec modules — Opus, G.711, and others, negotiated per call.
• The dialplan — the routing logic that decides what happens to each call. It’s written in XML by default, and can call out to Lua, JavaScript, or Python for anything the static XML can’t express cleanly.

The piece that matters most for modern builds is the Event Socket Layer (ESL). ESL is a TCP control interface that lets an external application connect to FreeSWITCH, subscribe to call events, and issue commands — originate a call, play a prompt, bridge two legs, hang up. The important architectural property: your application controls the call from the outside without living inside the media path. For an AI voice agent, that separation is what keeps model-inference latency from blocking the audio threads that have to run in real time. We’ll come back to it in the AI section. Deep ESL and dialplan patterns are their own subject, so this is the orientation, not the field guide.

How does FreeSWITCH compare to Asterisk, Kamailio, and hosted alternatives?

At a decision level, the question is rarely “FreeSWITCH or nothing.” It’s FreeSWITCH versus the other open-source telephony projects and versus a hosted CPaaS that removes the infrastructure entirely. The honest summary is below. The full FreeSWITCH-versus-Asterisk engineering comparison is its own piece, so this table stays at summary depth.

The one distinction worth pulling out here, because it’s the most common architectural confusion: Kamailio and OpenSIPS are not alternatives to FreeSWITCH — they’re companions to it. They route and balance SIP signaling; FreeSWITCH processes media. High-volume systems frequently run a SIP proxy in front of a cluster of FreeSWITCH media nodes. Choosing between them is the wrong framing; choosing how they sit together is the right one.

Read next: FreeSWITCH vs Asterisk (vs Kamailio, vs FreePBX): An Honest Engineering Comparison (link at publish — same wave)

Can FreeSWITCH scale to production call volumes?

Yes, and the scaling pattern is well established, but it’s an architecture decision rather than a single tuning flag. A single FreeSWITCH node scales vertically to a point; past that, production systems scale horizontally by putting a SIP proxy (typically Kamailio or OpenSIPS) in front of a pool of FreeSWITCH media nodes. The proxy handles registration and call distribution; the media nodes do the heavy per-call work. Containerization (Docker, and orchestration with Kubernetes) makes those media nodes reproducible and lets you add or drain capacity, and failover is designed at the cluster level so a lost node doesn’t take active infrastructure down with it.

Two honest caveats belong here. First, concurrency figures depend entirely on the work each call does — a bridged audio leg, a conference mix, transcoding between codecs, and a call feeding an AI pipeline have very different per-session costs, so a single “FreeSWITCH handles N calls” number is close to meaningless without the workload attached to it. Second, the hard part of production scale is rarely raw throughput; it’s failover, session recovery, and observability across a fleet you can no longer watch one call at a time. That’s the layer most tutorials skip.

Is FreeSWITCH secure and compliant enough for regulated industries?

FreeSWITCH can anchor a HIPAA- or GDPR-compliant voice system, but compliance is a property of how you deploy and operate it, not something the software grants on its own. The same principle holds for WebRTC media servers generally, and it’s the one teams most often get wrong.

On the security side, an internet-facing SIP service is a standing target. The baseline hardening is well understood: terminate SIP over TLS and media over SRTP, restrict the SIP attack surface (registration abuse, toll fraud, and brute-force registration attempts are the common vectors), rate-limit and use fail2ban-style protections, and keep the media path encrypted end to end where your regime requires it rather than only to the server edge. None of this is exotic, but all of it is the operator’s responsibility, and skipping it is how open SIP ports become fraud bills.

On the compliance side, the questions are the familiar ones for regulated voice: where does voice data physically reside, who can access it, is there an audit trail, and does every third party that touches protected data have a signed agreement to do so. A 2026 pattern worth naming is the push toward keeping voice data (and increasingly the AI processing of it) inside the firewall rather than routing it through a third-party cloud, which is exactly where a self-hosted media server like FreeSWITCH has an advantage over a hosted CPaaS you can’t fully control. This is territory we work in directly: Trembit’s healthcare practice includes KBV-certified psychotherapy telemedicine (a rare credential among WebRTC teams) and HIPAA/GDPR-compliant real-time media, and the same discipline that keeps an SFU compliant applies to a softswitch. For the deeper media-server-and-compliance treatment, our SFU comparison for telemedicine platforms walks through the controls a regulated build actually needs.

Can FreeSWITCH power a real-time AI voice agent?

Yes, and this is the demand driving most of the current interest in FreeSWITCH. The architecture is clean, but it splits into two distinct channels that are easy to conflate. FreeSWITCH is the telephony and media layer that answers the call, bridges the audio, and connects to the phone network or the browser. ESL (the Event Socket Layer) is the outbound control and event channel your AI application uses to drive the call — originate, answer, bridge, play a prompt, hang up. ESL does not carry the call audio. The audio reaches your speech-to-text and AI pipeline through a separate media-fork module — mod_audio_stream in current builds (the older mod_audio_fork is deprecated) — which streams the live RTP audio out to your service over a WebSocket. Behind that fork, an STT → LLM → TTS pipeline (or a native speech-to-speech model) turns caller audio into a response. Keeping the two channels straight — control on ESL, audio on the media fork — is the reason model inference can run outside the media path: a slow LLM turn stalls the response but doesn’t disrupt the real-time audio threads FreeSWITCH is running.

What does not change when the call arrives over SIP instead of WebRTC is the transport-layer discipline. Jitter buffering, duplex audio, echo handling, and latency budgeting behave the same way whether the audio came from a phone through FreeSWITCH or from a browser over WebRTC — and getting that layer wrong is the difference between a demo that works on your laptop and an agent that talks over callers in production. We’ve written that transport-layer material in depth for WebRTC, and it transfers directly: see the production mechanics of voice AI agents on WebRTC for latency, barge-in, and turn-taking, rather than re-deriving it here.

The build itself is where the depth lives, and where the honest tradeoffs (classic STT→LLM→TTS latency versus a native realtime model, on-prem versus cloud inference, barge-in handling) deserve their own treatment.

Read next: How to Build a Voice AI Agent on FreeSWITCH (Real-Time STT→LLM→TTS) (link at publish — same wave)

This is also the intersection where we do most of our work: building AI into the live media path, not bolting a model onto a pipeline someone else designed, and building voice AI assistants for production rather than for a demo. For AI work that sits outside the real-time media path (document processing, orchestration, agents), that’s the broader AI development practice alongside it.

A note from a team that runs FreeSWITCH in production

Trembit runs FreeSWITCH in production today as a SIP proxy and PSTN bridge inside a HIPAA/GDPR-compliant healthcare communications platform. It’s the same platform behind that case study, with the work cleanly split by subsystem: FreeSWITCH runs the SIP-proxy and PSTN telephony layer, while the real-time translation the case study details runs on a separate Mediasoup SFU — two engines, two jobs, one platform. In its telephony role, FreeSWITCH connects the platform’s web and mobile WebRTC clients with two worlds that don’t speak WebRTC: ordinary phone users on the PSTN, and hospitals’ existing corporate SIP conferencing infrastructure. That’s the unglamorous, high-value job a softswitch does well — being the reliable seam between browser real-time media, the phone network, and enterprise telephony that has to keep working.

One honest scoping note, because the distinction matters: we run FreeSWITCH as production telephony and media infrastructure. Voice AI agents on FreeSWITCH are, for us, prototype and demo work today, not a production claim. When we say something runs in production, we mean it — which is exactly why we separate the two.

Does FreeSWITCH work with WebRTC?

Yes. FreeSWITCH speaks WebRTC natively through mod_verto (its own WebSocket-based signaling protocol with browser and mobile client libraries) and also supports SIP-over-WebSocket, so a browser can register as a SIP endpoint. Either path lets a web or mobile app place and receive calls that terminate on the same FreeSWITCH that handles your SIP trunks and phone endpoints, which is why it’s a natural bridge between browser real-time media and the phone network.

One distinction worth stating plainly, because it’s a frequent mix-up: FreeSWITCH is a softswitch and conferencing mixer, not an SFU. If your product is a browser-to-browser video app with many participants, the right tool is a Selective Forwarding Unit (mediasoup, LiveKit, Janus), which routes each participant’s stream without re-mixing — see our LiveKit vs mediasoup comparison for that decision. FreeSWITCH earns its place when SIP, the PSTN, or telephony-style call control is in scope, not as a replacement for an SFU. Plenty of real systems run both: an SFU for the browser video mesh and FreeSWITCH for the telephony and PSTN seam, which is close to the shape of our own production deployment above.

When should you choose FreeSWITCH over the alternatives?

A short, honest decision framework rather than a verdict, because the right answer depends on your team as much as your requirements:

• Choose FreeSWITCH when you need protocol-level control across some mix of PBX, conferencing, WebRTC gateway, PSTN bridging, and an AI-voice backend in one engine, and you have (or can build) the operational capacity to run it. Its reward is control; its price is ownership.
• Choose a packaged PBX (FreePBX / Asterisk distribution) when you want a working phone system quickly and value speed over deep customization.
• Choose a hosted CPaaS (Twilio, Vonage) when you don’t want to run telephony infrastructure at all and per-minute, API-first pricing fits your model, and you can accept less control over data residency and cost at scale.
• Add Kamailio or OpenSIPS alongside FreeSWITCH, not instead of it, when SIP routing and load-balancing at volume is the bottleneck. They handle signaling scale; FreeSWITCH handles media.

The through-line: FreeSWITCH is the right call when control and consolidation across telephony roles matter more than time-to-first-call, and the wrong call when you’d rather inherit an opinionated system than operate a flexible one.

Frequently asked questions about FreeSWITCH

Is FreeSWITCH free to use?
Yes. FreeSWITCH is open-source under the Mozilla Public License 1.1 (MPL 1.1). You can download, modify, and run it in production at no license cost. “ The cost is operational: you run and maintain the infrastructure yourself, or bring in a team that does.

Is FreeSWITCH better than Asterisk?
Neither is universally “better” — they’re both mature open-source softswitches with overlapping capabilities. FreeSWITCH is often preferred for programmable, multi-role deployments and heavier media/conferencing work; Asterisk has an enormous ecosystem and community, and packaged distributions like FreePBX built on it. The right choice depends on your team’s existing experience and what you’re building. The full engineering comparison is its own piece (linked above).

Can FreeSWITCH handle WebRTC calls natively?
Yes, through mod_verto (its native WebSocket signaling) and SIP-over-WebSocket. A browser or mobile client can connect to FreeSWITCH and reach the same endpoints and trunks as any SIP phone, which makes FreeSWITCH a common bridge between browser real-time media and the phone network.

Do I need FreeSWITCH if I’m only building a browser-based video app?
Probably not. Multi-party browser video is an SFU’s job (mediasoup, LiveKit, Janus), which routes streams without re-mixing them. FreeSWITCH earns its place when SIP telephony, PSTN connectivity, or telephony-style call control is also in scope — a video app that also needs to dial or receive phone calls, for example.

Can FreeSWITCH connect to an LLM or voice AI pipeline?
Yes. FreeSWITCH handles the call and media, while an external application drives the call over the Event Socket Layer (ESL) — a control and event channel, not an audio channel. The call audio reaches your STT → LLM → TTS (or native speech-to-speech) pipeline through a separate media-fork module (mod_audio_stream in current builds; the older mod_audio_fork is deprecated), which streams the RTP audio out to your service. Because that pipeline runs outside the media path, model latency doesn’t disrupt the real-time audio. The end-to-end build is covered in a dedicated guide (linked above).

Is FreeSWITCH suitable for HIPAA-regulated voice data?
It can be, when deployed and operated correctly: TLS/SRTP encryption, access control, audit logging, data-residency control, and signed agreements with any third party that touches protected data. Compliance is a property of the whole deployment, not of the software. Self-hosting FreeSWITCH can actually simplify the data-residency story compared with a hosted CPaaS, because the voice data stays on infrastructure you control.

Whether you’re evaluating FreeSWITCH against the alternatives or already running it and hitting the production questions — scale, failover, security, compliance, or wiring in real-time AI — the useful next step is an architecture conversation, not a sales call. Trembit builds and operates real-time media infrastructure at the protocol level (SDP, ICE, DTLS-SRTP, SIP, and SFU and softswitch architecture) across 50+ video and voice implementations, including FreeSWITCH in production as a SIP proxy and PSTN bridge inside a compliant healthcare platform. We also inherit and rescue broken FreeSWITCH and real-time telephony deployments — the systems where another vendor stalled, the fleet won’t stay up, or the calls stopped connecting, and someone needs to take over a codebase and make it reliable. If you want to pressure-test an architecture decision — a topology, a scaling plan, a compliance gap, or whether FreeSWITCH is even the right tool for what you’re building — bring the specific decision to a free 30-minute call with an engineer and we’ll work through it. No deck, no pitch. Start with our real-time AI and WebRTC engineering work, or our WebRTC development and rescue practice.

More in this FreeSWITCH series: FreeSWITCH vs Asterisk: an honest engineering comparison and how to build a voice AI agent on FreeSWITCH. Still in progress: scaling and clustering in production, HIPAA/GDPR-compliant and on-prem voice, SIP-to-browser WebRTC bridging, and ESL and dialplan patterns.