The short answer

Concurrency is the real capacity limit on a voice deployment, and it is not the same as call volume. Ten thousand calls a day is easy; two hundred at the same second is a capacity question that touches the trunk, the media servers, the speech providers and your own rate limits. Exceeding it produces failed calls, not slow ones.

In detail

The distinction from throughput is the part teams get wrong. Concurrency is a level — calls in progress right now — while volume is a count over a period. Average call duration links them: a campaign dialling steadily needs concurrency roughly equal to calls per second multiplied by average duration in seconds, so longer conversations consume capacity disproportionately.

Limits stack, and the effective ceiling is the lowest one in the chain. The SIP trunk enforces a concurrent-call cap. Media infrastructure has a finite number of sessions it can mix. Speech and language providers apply their own concurrency quotas. A deployment sized against only one of these will hit a different limit first, and usually discovers which one during its largest campaign.

Because breaching a limit produces rejections rather than queuing, pacing has to happen before dispatch. A dialer that tracks in-flight calls and holds back new ones stays inside the ceiling; one that fires on a fixed schedule generates a burst of carrier-level failures that look like a platform outage and are recorded against the calling number’s reputation.

How Rexa handles it

Rexa exposes concurrency as a first-class API resource. A workspace has a plan entitlement, concurrency_max, and can set its own lower self-imposed cap; the endpoint returns both and the resulting effective limit. The self-imposed value is reduce-only — it can throttle a workspace below its plan but never above it — and reading it requires the concurrency:read scope.

Calls API

Back to the glossary

All 53 glossary terms