SIP Trunk Capacity Planning: Calls, Codecs and Bandwidth

SIP trunk sizing is often reduced to one question: “How many channels do we need?” That question matters, but it is only part of the design.

A usable capacity plan must account for simultaneous calls, traffic peaks, codec bandwidth, call direction, carrier limits, application resources, recording, network quality, and failure scenarios.

This guide provides a practical planning method for a PBX or contact center project.

What is a concurrent call?

A concurrent call is an active call occupying capacity at the same time as other calls. Depending on the provider and architecture, capacity may be described as channels, sessions, call paths, or concurrent calls.

Do not confuse concurrency with:

• total calls per day;
• monthly minutes;
• registered extensions;
• total agents;
• contacts in an outbound campaign.

A business can handle thousands of calls per day while requiring only tens of simultaneous sessions—or experience a short peak that exceeds a seemingly generous monthly plan.

Start with call-direction scenarios

Separate the main traffic types:

1. inbound calls from a carrier to IVRs, queues, agents, or external destinations;
2. outbound calls from users or campaigns to the public telephone network;
3. internal calls between extensions;
4. transferred calls that may create an additional external leg;
5. conference calls with several active legs;
6. calls bridged to AI, speech, or external application services.

A transferred call can consume more capacity than expected. For example, an inbound carrier leg bridged to an external mobile number may keep the original inbound session while creating a second outbound session.

Document call legs, not just user-visible conversations.

Estimate peak concurrency

Historical carrier and PBX data are the best starting point. Use the busiest representative periods rather than daily averages.

Capture:

• peak simultaneous calls;
• busiest-hour call attempts;
• average call duration;
• inbound versus outbound mix;
• queue wait and hold time;
• campaign pacing;
• seasonal or event-driven peaks;
• growth expected during the planning period.

If no reliable history exists, build a range rather than a single number.

For a simple agent-based estimate:

[ ext{Expected active agent calls} = ext{staffed agents} imes ext{occupancy} ]

If 60 agents are staffed and the expected occupancy is 65%, the estimate is:

[ 60 imes 0.65 = 39 ]

That is not the final channel count. Add IVR callers, queued callers, outbound automation, transfers, supervisors, test traffic, and headroom.

Add headroom deliberately

Capacity should not be designed to operate continuously at the observed maximum. Headroom absorbs forecasting error, bursts, retries, maintenance, and growth.

The appropriate margin depends on traffic variability and the consequences of rejection. A stable internal office PBX and a time-sensitive notification campaign may require different planning assumptions.

Document why the margin was chosen. Avoid an unexplained “double everything” rule, but also avoid sizing exactly to yesterday’s peak.

Understand codec bandwidth

Codec bitrate is only one part of the network load. IP, UDP, and RTP headers add overhead, and packetization affects packets per second.

A planning estimate can be expressed as:

[ ext{Total voice bandwidth} = ext{simultaneous RTP streams} imes ext{estimated bandwidth per stream} ]

The exact per-call figure depends on codec, packet interval, IP version, encapsulation, and network design. Bidirectional audio also means traffic flows both into and out of the network.

For planning:

• confirm which codecs the carrier and endpoints support;
• identify whether transcoding is required;
• include protocol overhead;
• include signaling, monitoring, and other application traffic;
• evaluate both upload and download capacity;
• avoid using the theoretical circuit speed as the usable voice budget.

Measure packet loss, jitter, latency, and reordering as well as bandwidth. A fast but unstable link can produce poor audio.

Account for transcoding

Transcoding occurs when two call legs use different codecs and the platform converts between them. It can increase CPU demand and introduce another processing step.

Record:

• codecs offered by each carrier;
• codecs used by phones and softphones;
• codecs required by recording or external media services;
• whether the platform passes media directly or anchors it;
• the expected number of simultaneous transcodes.

Test the exact codec combinations that will run in production. A successful same-codec test does not validate a transcoding-heavy workload.

Include application and storage capacity

The carrier channel limit is not automatically the platform limit. Application sizing may also depend on:

• simultaneous signaling sessions;
• media processing;
• transcoding;
• call recording;
• queue and campaign activity;
• database writes;
• reporting events;
• API and webhook traffic;
• AI or speech provider connections.

Recording adds storage growth and read/write load. Estimate retention using representative recordings instead of assuming a universal size per minute, because codec and file format affect the result.

Plan outbound campaign pacing

An outbound campaign can create a rapid burst of call attempts even when few calls are eventually answered.

Define:

• maximum simultaneous attempts;
• call-start interval;
• carrier call-per-second limits;
• retry count and delay;
• answer handling destination;
• available agents;
• quiet hours and timezone rules;
• consent and opt-out policy.

Coordinate pacing with both trunk capacity and staffing. A campaign that connects more calls than agents can handle creates a customer-experience problem even if the infrastructure remains healthy.

See the NextGenSwitch campaign workflow and campaign documentation for the application-side configuration context.

Design carrier and network failure paths

Capacity planning should include degraded operation.

Ask:

• Is there a secondary trunk or route?
• Which numbers can fail over?
• Can outbound traffic use an alternate provider?
• What happens if one site loses internet connectivity?
• Are DNS, certificates, and firewall changes included in recovery procedures?
• How will the team detect partial call failure?
• Who owns escalation to the carrier?

A second provider adds value only when routing, caller identity, interoperability, monitoring, and operating procedures have been tested.

Create explicit capacity alerts

Monitor the signals that indicate approaching limits:

• active carrier sessions;
• rejected or failed call attempts;
• SIP response codes;
• call setup time;
• packet loss, jitter, and latency;
• CPU, memory, disk, and network utilization;
• transcoding load;
• recording failures;
• queue growth;
• campaign attempts and connects.

Alert before the absolute limit. An alert at 100% concurrency only confirms that callers may already be affected.

Validate with staged load testing

A useful test plan increases load in controlled steps and checks more than call establishment.

At each level, validate:

• two-way audio;
• call setup and teardown;
• DTMF;
• routing and transfers;
• queue behavior;
• recording;
• reporting;
• API events;
• server and network metrics;
• carrier rejection rates;
• recovery after the test.

Use approved test destinations and coordinate high-volume testing with providers. Do not generate unsolicited calls.

Capacity-planning worksheet

Bring these figures into a design review:

Input	Planned value
Staffed agents by shift
Peak active agent calls
Peak IVR and queued callers
Outbound campaign concurrency
Transfer or conference call legs
Codec and packet interval
Transcoding concurrency
Carrier channel and CPS limits
Network voice budget
Headroom assumption
Failover capacity
Recording retention

Connect capacity to the platform design

Capacity is a shared result of telecom, network, infrastructure, application, and operating choices. Confirm each layer instead of relying on a single “supported calls” number.

Review the Virtual PBX deployment model, the contact center solution, and the Why NextGenSwitch evaluation guide. For a scoped assessment, share your traffic and carrier requirements.