How Many Calls Can One FreeSWITCH Server Handle Before I Need Another Server?
Estimate capacity from signaling, transcoding, recording, conferencing, AI streaming, CPU, memory and network measurements instead of relying on a universal calls-per-server number.
FreeSWITCH learning series · Part 27 of 30
Estimate capacity from signaling, transcoding, recording, conferencing, AI streaming, CPU, memory and network measurements instead of relying on a universal calls-per-server number.
What this question really means in a working FreeSWITCH system
There is no honest single ‘calls per server’ figure because a pass-through G.711 call, a transcoded call, a conference leg, a recording and an AI-streamed call consume very different resources. Build a workload model, then load-test that model while collecting CPU, memory, packet loss, scheduling delay and media latency. Capacity planning is an evidence exercise, not a brand comparison.
Start with the mental model
Capacity is a workload equation, not a brand number. A signaling-only bridge using a common codec is very different from a call that transcodes, records, mixes conference audio and streams PCM to an AI service.
| Feature | Typical resource pressure | What to measure |
|---|---|---|
| SIP signaling | CPU/sockets | setup rate, response latency |
| Transcoding | CPU | per-call CPU, saturation |
| Recording | Disk I/O/storage | write latency, growth |
| Conference/mixing | CPU | mix latency |
| AI streaming | CPU+network+external latency | PCM bandwidth, bridge queues, model RTT |
Work through it from zero
List codecs, media anchoring, transcoding, recording, IVR/ASR/TTS, events and external integrations.
Capture CPU, memory, network, disk write, file descriptors and latency during steady state.
Use controlled load tests and watch for nonlinear behaviour such as scheduler pressure or disk saturation.
Busy-hour calls may include recording + transcode + AI, not the minimal lab call.
Production capacity should leave room for bursts, failover and maintenance.
When one node nears operational limits, adding cores may be simpler than distribution—or not, depending on state/media architecture.
What beginners usually confuse
- Publishing an unsourced “calls per server” figure.
- Testing only idle connected calls.
- Ignoring failover capacity.
- Load-testing production trunks without provider approval.
How to know you are actually finished
- Document the exact hardware/software/test profile with every benchmark.
- Define saturation thresholds before testing.
- Retest after major codec/module/version changes.
How to use this in a real implementation
For this FreeSWITCH task, use a bounded test built around this objective: estimate capacity from signaling, transcoding, recording, conferencing, ai streaming, cpu, memory and network me…. Observe one state change at a time, save the evidence, and only then move to the next layer.
- Capture the exact runtime evidence related to Describe one representative call before changing the next layer.
- Keep a known-good test number/endpoint and repeat the same call after each configuration change.
- Record SIP response codes, context/destination decisions and media observations separately; they answer different questions.
- If you cannot explain which file/module owns the behavior, stop and locate that ownership before editing more configuration.
Continue from here
After this article: use the next link that matches the unresolved part of estimate capacity from signaling, transcoding, recording, conferencing, ai streaming, cpu, memory and network me…. Start the FreeSWITCH learning series · Use the SIP → dialplan → RTP troubleshooting ladder · Continue into real-time AI media streaming
Questions a careful reader usually asks next
Should I change several FreeSWITCH files at once?
Not while learning or troubleshooting. Prove describe one representative call first, then change one layer and repeat the same test so you know what caused the new behavior.
Is a successful CLI command enough proof?
No. For estimate capacity from signaling, transcoding, recording, conferencing, ai streaming, cpu, memory and network me…, confirm the live SIP, dialplan or media behavior that the command was intended to affect. A parser or CLI success only proves the command was accepted, not that the call path now behaves correctly.
Where should business logic live?
For estimate capacity from signaling, transcoding, recording, conferencing, ai streaming, cpu, memory and network me…, keep low-level signaling/media truth in FreeSWITCH, while customer, campaign and business state stays in the application layer unless the telephony engine genuinely needs it for call execution.
References and further reading
Protocol and configuration facts for How Many Calls Can One FreeSWITCH Server Handle Before I Need Another Server are grounded in the current FreeSWITCH Users Manual and, where Asterisk is compared, Asterisk's official documentation. Community tutorials are included only as credited learning aids.
- FreeSWITCH Users Manual — authoritative project documentation for the FreeSWITCH behavior/configuration referenced above.
- FreeSWITCH Getting Started — authoritative project documentation for the FreeSWITCH behavior/configuration referenced above.
- FreeSWITCH — CLI and API command reference — additional primary/official reference for context and verification.
Want to see API-driven CRM + Telecom workflows in action? Try the WhatsApp bot or explore the demos.
Comments (0)
Be the first to comment.