Capacity planning
Use Provision instances for the baseline vCPU/RAM of every service role and its linked service pages for storage/network requirements. Call volume primarily changes Voice fleet sizing, but API throughput, TelPro media/signaling, database I/O, provider quotas, and telemetry storage must also be validated.
Baseline and measured limits
| Item | Existing reference | Provisioning interpretation |
|---|---|---|
| Voice starting specification | 3 vCPU / 4 GB RAM; approximately 100 concurrent calls per instance in the provisioning guide. | Starting configuration, subject to workload validation; do not run continuously at the measured ceiling. |
| Original single-Voice test cell | 100 concurrent calls with exact three-turn accounting; operational band approximately 75–80. | Use the test conditions when deciding whether this cell represents your workload. |
| Doubled-resource test cell | 200 concurrent calls with exact accounting; operational band approximately 150. | The report describes a relative resource increase. Confirm actual VM/CPU/RAM details before translating this result into a cloud machine type. |
| TelPro starting specification | 3 vCPU / 4 GB RAM; approximately 1,000 concurrent calls noted in the provisioning guide. | Revalidate for the chosen RTP load, codecs, encryption, call rate, and network. This is not an unlimited fleet-level capacity guarantee. |
The recorded Voice campaign used deterministic PCMA / 8 kHz / 20 ms, Pythia STT/TTS and an integration-specific mock bot. Real provider latency, quotas, codec conversion, audio processing, recording, call duration, and dialogue length can change capacity. A successful SIP setup count alone does not prove successful conversations.
Calculate an initial Voice fleet
Let C be target simultaneous calls and K the measured operational calls per Voice node with headroom already applied. Provision ceil(C / K) serving nodes. To tolerate one unavailable Voice node during maintenance or failure, provision ceil(C / K) + 1, and verify calls can be admitted within the remaining capacity.
The examples below use K = 75 from the original test's operational band. They are planning calculations, not additional certified load tests:
| Target concurrent calls | Serving Voice nodes | Voice nodes with one spare |
|---|---|---|
| 100 | 2 | 3 |
| 200 | 3 | 4 |
| 500 | 7 | 8 |
| 1,000 | 14 | 15 |
Add the other service roles from the instance specification table. A spare Voice node does not provide high availability for a single TelPro, database, or other shared dependency. Configure admission limits in Server groups and confirm Scaler minimum/maximum fleet sizes allow the plan.
Worked example: 500 concurrent calls
With a verified operational allowance of 75 calls per Voice node, six nodes provide only 450 calls of planned capacity. Seven provide 525; adding one spare gives eight provisioned Voice nodes. With one node unavailable, seven remain to serve the target 500 calls.
If the 3 vCPU / 4 GB RAM baseline is the machine configuration being validated, eight nodes total 24 vCPU and 32 GB RAM for Voice only. Budget the other service roles and persistent storage separately. Do not apply a 25% headroom reduction to 75 again: this example's operational allowance already includes headroom relative to the measured ceiling.
For an approximately steady workload, average concurrency can be estimated as calls started per second × average call duration in seconds. For example, 2 calls/s held for 180 seconds gives approximately 360 simultaneous calls on average. Bursts, longer calls and peak arrival rates can make the actual peak higher; provision and test against the expected peak, not only that average.
Capacity review worksheet
| Input | Example / what to supply |
|---|---|
| Traffic | Peak concurrent calls, peak calls/s, average and maximum duration, and busy-hour profile. |
| Conversation | Expected turns, audio-in/out duty cycle, STT/TTS/LLM or bot providers, and latency targets. |
| Media | Codec/sample rate, transcoding, audio processing, recording and transfer behavior. |
| Voice machine | Actual provider machine type, CPU architecture, vCPU/RAM, disk and network allowance. |
| Operational node limit | Sustainable measured limit with headroom; keep the workload and release evidence. |
| Fleet | Serving nodes, spare nodes, minimum ready capacity, maximum allowed nodes, and drain/startup time. |
| Shared bottlenecks | TelPro RTP/signaling, TelAPI callbacks, database/Redis, media storage, egress and provider quotas. |
| Acceptance | Completed conversations/turns, latency and failure thresholds, and behavior with one node unavailable. |
Scaling policies must make capacity available before traffic needs it. If node provisioning takes longer than a traffic surge, keep sufficient ready capacity for that interval; a larger maximum fleet setting alone does not cover it.
Validate before provisioning sign-off
- Record target concurrency, calls per second, duration, dialogue turns, codec, provider/model, recording and audio-processing settings, and failure/maintenance capacity.
- Record the actual instance type, CPU architecture, vCPU, RAM, disk/IOPS, network limits, image/config versions, and provider quotas.
- Run a representative workload at expected peak and through a node drain. Check completed bot/audio turns, latency, call rejection, CPU/RAM, RTP loss, queue depth, and database/API health.
- Choose the sustainable per-node admission limit below the failure point and retain the evidence. Re-run after changes that affect the workload or service resources.