FreeSWITCH is an open-source soft switch and media server – a telephony platform that routes calls, processes media, and handles SIP signaling. Unlike proprietary phone systems, FreeSWITCH gives you complete control over the source code, so you can customize every aspect of call processing.

ECG has deployed FreeSWITCH for service providers building carrier-grade platforms, enterprises building custom voice applications, and companies integrating voice into AI workflows. 

Both are open-source VoIP platforms, but they're architected differently. Asterisk is older and has a larger ecosystem of add-on modules, but it's more monolithic. FreeSWITCH has a cleaner modular architecture where you can plug in different signaling layers (drachtio), media proxies (RTPengine), or custom handlers.

Asterisk vs FreeSWITCH comes down to use case: Asterisk works well for straightforward PBX and IVR deployments, while FreeSWITCH is better when you need to build something custom or non-standard. At ECG, we've worked with both and will recommend whichever fits your requirements. 

FreeSWITCH is a full-featured media server with its own dialplan scripting (XML, Lua) and event socket interface. drachtio is a SIP proxy/signaling framework controlled via Node.js, typically used for signaling control while delegating media to either FreeSWITCH or RTPengine.

They are often used together: drachtio handles SIP signaling logic in JavaScript, FreeSWITCH provides media processing, and RTPengine handles high-efficiency media proxying.

Use FreeSWITCH directly if you need one-box simplicity. Use drachtio + FreeSWITCH if you're building a multi-component platform where signaling and media are handled by separate systems.

RTPengine is a high-performance media proxy developed by Sipwise, designed to handle millions of concurrent RTP streams efficiently using Linux kernel-level packet processing. In a FreeSWITCH or drachtio deployment, it's controlled via the ng protocol over UDP. drachtio sends "offer," "answer," and "delete" commands to RTPengine to set up and tear down media flows.

RTPengine handles codec transcoding, SRTP/SRTCP encryption, and call recording (producing pcap files). It removes FreeSWITCH from the media path for sessions that require no media processing, dramatically reducing CPU load and improving scalability. 

There are several:

• SIP signaling is source-IP-sensitive, so pod IP instability breaks registrations. You need stable endpoints, typically via NodePort or a dedicated SBC in front.

• RTP requires large UDP port ranges that most Kubernetes container networking interfaces don't handle cleanly out of the box.

• FreeSWITCH clustering requires inter-node communication (often via Kafka or a configuration server) to share dialplan state and call routing.

• Auto-scaling based on CPU percentage is the wrong metric; you need concurrency-aware scaling based on call count.

• Kubernetes upgrades (e.g., EKS 1.30 → 1.35) require upgrading nodes and add-ons in sequence, with careful validation of SIP registration and media behavior after each step.

At ECG, we've built and operated FreeSWITCH on EKS using CloudFormation/CDK, and we know where each of these issues appears. 

FreePBX is a web-based configuration layer on top of Asterisk. It makes Asterisk easier to manage for traditional PBX use cases (desk phones, queues, voicemail). FreeSWITCH is a lower-level platform that requires more programming but offers more control.

Use FreePBX if you're building a traditional on-premises PBX. Use FreeSWITCH if you need custom call control logic, SIP trunking gateways, voice APIs, or integration with AI/ASR pipelines. The decision of FreeSWITCH vs FreePBX usually comes down to how much customization you need versus how much you want out-of-the-box PBX features. 

Redis serves as the low-latency in-memory state layer for decisions that must be made during a call – too slow to go to PostgreSQL. In practice this includes:

• SIP registration lookups (is this user registered and where?)

• In-call routing decisions (LCR, fraud scoring, number blacklists)

• Call-leg correlation for SIPREC deduplication (using Redis locks keyed on caller + callee + timestamp window)

• Pub/sub event streaming between components.

Production deployments using FreeSWITCH exclusively use Redis for in-call routing decisions precisely because it delivers sub-millisecond lookup times at scale. ECG has implemented Redis-backed deduplication, routing, and pub/sub layers in both our own products and client systems. 

 Yes, and we do it regularly. We read existing codebases – FreeSWITCH XML dialplans, custom C modules, drachtio Node.js applications, Redis schemas, Kubernetes manifests – reconstruct what the system is doing, identify what's broken or incomplete, and pick up development from there.

We've migrated FreeSWITCH customer configurations to BroadWorks, extended drachtio SIPREC recording servers with custom Redis deduplication logic, and taken over stalled Kubernetes VoIP deployments. The starting point doesn't have to be clean for us to be useful. 

ECG's engineers can support your team through FreeSWITCH architecture design, custom module development in C, dialplan optimization, Kubernetes deployment planning, security and compliance review, and mid-project rescue.

We can also help you evaluate whether FreeSWITCH is the right platform for your use case, or whether Asterisk, a proprietary platform, or a combination approach makes more sense.