VoIP Trunk Capacity: What You Can Actually Verify

Shared capacity is how almost every network service is built. ISPs do not provision every subscriber's advertised speed simultaneously. Airlines and hotels sell against expected no-shows. The underlying principle is statistical multiplexing: when you can characterize aggregate demand, you can serve it with less capacity than the sum of the individual maximums, and everyone pays less as a result.

VoIP trunk providers work the same way, and there is nothing improper about it; it is ordinary traffic engineering, formalized in standards like ITU-T E.600. What matters is not whether capacity is shared but what the provider has committed to deliver when demand peaks, and what you can actually verify from outside their network.

The honest answer to that second part is: less than you would like. This article covers how the capacity is structured, what peak-hour symptoms do and do not establish, and which contract terms are worth pinning down, because those terms, not inference from symptoms, are what you can hold a provider to.

How trunk capacity is structured

A SIP trunk provider has a finite amount of infrastructure: session border controllers (SBCs) that handle signaling and media, bandwidth at peering points where their network connects to upstream carriers, and capacity on those upstream carriers for terminating calls to the PSTN.

When a provider sells you 50 concurrent call channels, they are making a commitment that your system can have up to 50 simultaneous calls transiting their network. The question is whether they have provisioned enough infrastructure to honor that commitment to every customer at the same time.

As an illustration of the arithmetic: a provider with 1,000 customers who each bought 50 channels has sold 50,000 channels of concurrent entitlement. Building for 50,000 simultaneous calls would be enormously expensive and the pricing would reflect it. Instead the provider characterizes its aggregate traffic (suppose the observed peak across all customers is nearer 15,000 concurrent calls) and engineers to that observed demand plus headroom, against whatever blocking objective it has set itself.

The relationship between sold entitlement and engineered capacity is sometimes described as an overbooking ratio, and it is worth being clear about what you can know here: you cannot. Providers do not publish these figures, you cannot derive one from symptoms on your own trunks, and you cannot infer one from price or from how many channels a provider is willing to sell you. Any specific ratio you see quoted (including in this article, where the numbers above exist only to show the shape of the calculation) is illustrative rather than measured industry data. The only sources for a real figure are a contractual commitment, the provider's own disclosure, or a measurement set someone will stand behind.

What price differences actually reflect

Per-channel pricing between providers can vary by 3x or more for what looks like the same service, and it is tempting to read that gap as a proxy for engineering headroom. It is not a reliable one.

Price reflects termination costs and which interconnects a provider has, the product tier you are being quoted, the support model, contract length and volume commitments, how much of the stack the provider owns versus resells, and the margin and market position it has chosen. Engineering headroom is one input among many, and it is not separable from the others when all you can see is a number on a quote.

There are real differences between providers in how much they invest per customer: direct interconnects with major carriers instead of routing through aggregators, redundant SBCs, staff to notice a capacity problem before customers do. Those differences tend to cost money, so they push price up. But the inference does not run backwards: a cheaper quote does not establish thinner engineering, and a more expensive one does not establish the opposite. What you can do is make the provider state its commitments, which is what the questions later in this article are for.

How it works at a technical level

Capacity is finite at every layer of the provider's infrastructure, and a constraint at any one of them can surface as a quality problem on your calls.

SBC session limits. The SBC is the front door. It handles SIP signaling (call setup, teardown, authentication) and often proxies or relays media. Each SBC has a maximum number of concurrent sessions it can handle, determined by CPU, memory, and licensing. When an SBC hits its session limit, new calls get rejected, typically with a SIP 503 (Service Unavailable) response. Be careful reading that code in the other direction, though: RFC 3261 defines 503 only as the server being temporarily unable to process the request, and maintenance windows, routing policy, and upstream carrier failures produce exactly the same response. A 503 is consistent with overload; it is not proof of overbooking. A well-run provider distributes load across multiple SBCs, but the aggregate capacity of their SBC farm is still finite.

Media processing. If the provider performs any media manipulation (transcoding between codecs, recording, SRTP-to-RTP conversion), that consumes CPU. Media processing is far more resource-intensive than signaling. A system that can handle 10,000 signaling sessions might only be able to transcode 2,000 simultaneous calls.

Bandwidth at peering points. Where the provider's network connects to other networks (upstream carriers, internet exchanges, other providers), there is a fixed amount of bandwidth. Each G.711 call consumes 80 kbps in each direction at the IP layer, or 87.2 kbps once Ethernet framing is counted at 20 ms packetization; for trunk and peering sizing the IP figure is the relevant one. At 10,000 concurrent calls, that is around 800 Mbps of media traffic in each direction. If the peering link is saturated, packets queue up and get delayed or dropped. The symptoms are jitter and packet loss: the classic markers of degraded call quality.

Upstream carrier capacity. The trunk provider is often not the one actually connecting your call to the PSTN. They buy termination from upstream carriers, who have their own capacity limits and their own engineering assumptions, invisible to both you and, beyond contractual commitments, often to your provider as well. A call that traverses two or three constrained networks can accumulate degradation at each hop, which is also why localizing a problem to one operator is genuinely hard rather than merely inconvenient.

What happens when a capacity limit is reached

The failure modes depend on which resource is exhausted first.

Failed call setups. When SBC capacity or upstream carrier capacity is exhausted, new calls simply fail. Your PBX sends an INVITE and receives a 503 response, or worse, the INVITE times out with no response at all. The user hears silence, then eventually a fast busy or an error tone. If your PBX is configured with failover to a secondary trunk, it may retry on another provider, adding several seconds of post-dial delay but eventually completing the call.

Increased latency. When bandwidth at peering points is saturated, packets queue in buffers before being forwarded. This adds latency to every call transiting that link. Once one-way delay pushes past roughly 150 ms (the commonly cited transmission-planning boundary from ITU-T G.114, not a cliff where audio fails), conversation starts to feel awkward, with the actual effect depending on total mouth-to-ear delay and echo control. G.114 treats the whole 150 to 400 ms band as acceptable so long as planners understand the impact, and puts 400 ms as the ceiling for general network planning. Past that, holding a natural conversation becomes actively difficult because both parties talk over each other.

Jitter. Congestion does not add a constant amount of latency. It adds variable latency: some packets get through quickly, others wait in queues. This variation is jitter. The receiving end has a jitter buffer that absorbs some variation, but when jitter exceeds the buffer's capacity, packets arrive too late to be played and are effectively lost. The result is choppy, broken audio.

Packet loss. When buffers overflow, packets get dropped. How audible a given loss rate is depends on the codec, its concealment, and whether losses are random or come in bursts; congestion loss tends to be bursty, which conceals worse. As rough working figures for a narrowband codec without FEC: even 1-2% packet loss is audible as clicks, gaps, or robotic-sounding audio; at 5%, conversation becomes difficult; at 10%, the call is essentially unusable. The MOS score drops rapidly with even small amounts of packet loss.

Quality degradation without total failure. This is the insidious case. The provider is not so overloaded that calls fail outright, but overloaded enough that every call is slightly worse than it should be. Estimated MOS drops from, say, 4.2 to 3.5. Users do not report it as a problem; they just perceive the phone system as "okay" rather than "good." Over time, this becomes the new normal, and nobody realizes the system should sound better than it does.

Reading a peak-correlated pattern

The useful signal is predictability: problems that track someone else's aggregate traffic rather than your own. That is worth recognizing, so long as you are precise about the conclusion it supports.

Degradation correlated with business-hours peaks is evidence of a time-correlated constraint somewhere on the path. It does not identify which operator, and it does not establish that capacity was oversold rather than, say, a peak-hour routing change, an upstream carrier's congestion, a saturated peering link neither party owns, or a software limit that only bites under load. Overbooking is one hypothesis on that list. Confirming it takes provider-side utilization, admission-control and interconnect telemetry, which is a request you make, not a measurement you can take.

With that established, the patterns worth looking for:

Time-of-day patterns. Quality degrades during peak business hours, typically 9 AM to 12 PM and 1 PM to 4 PM in the provider's primary time zone. If you are in a different time zone than most of the provider's customer base, you might experience peak congestion at unusual times relative to your own business hours. Calls at 7 AM or after 6 PM sound noticeably better.

Day-of-week patterns. Weekdays are worse than weekends. Monday mornings and Friday afternoons may be particularly bad because of higher-than-average call volumes across the provider's customer base.

Monthly patterns. Some businesses see spikes at month-end (collections, billing, sales closing). If your provider serves a lot of customers in industries with month-end surges, you might see degradation during the last few days of every month even if your own volume is flat.

The on-net vs off-net test. This is the most diagnostic check you can run, as long as you read it for what it actually shows. During a period when you suspect quality degradation, make an on-net call (internal extension to extension, not traversing the trunk) and an off-net call (through the trunk to the PSTN) at the same time. If on-net sounds perfect and off-net sounds degraded, the problem is not your local network. What the test does not do is pinpoint who: beyond your PBX, the path includes your ISP, intermediate peering, the trunk provider, its upstream carriers, the PSTN interconnect, and the far end's network. It moves the fault boundary outside your building; what starts to implicate the trunk provider specifically is degradation that correlates with aggregate business-hours peaks rather than with your own traffic or your ISP's known congestion.

Intermittent problems the provider cannot reproduce. You open a ticket. The provider investigates during off-peak hours, finds nothing wrong, and closes it. You experience the problem again the next morning. This cycle repeats. If the provider's investigation never happens during the exact times you experience the issue, they will never see the congestion because it only exists during peak load.

Concurrent call limits: contract vs reality

Your contract might say 50 concurrent channels. But that number can mean different things depending on how the provider structures their service.

Hard limits. Some providers enforce a strict session limit at the SBC. Call 51 gets rejected. You always get your 50, and the 503 is your signal to add capacity. This is clean and predictable.

Soft limits. Other providers allow bursting above your contracted limit. You bought 50 channels but can actually use 60 or 70 during a burst. This sounds generous until you realize the burst capacity is shared. When the provider's overall network is not busy, everyone can burst. When the network is congested, burst capacity disappears and you are back to your contracted limit, or worse, you cannot even reach your contracted limit because the shared infrastructure is overwhelmed.

Committed vs burst capacity. Some providers make this explicit. They sell "up to 100 channels" with a "committed" rate of 50. The committed rate is what they guarantee; the burst rate is best-effort. During off-peak you may get all 100. During peak you should expect the committed 50, and the question worth asking before you sign is what happens if even that is not available, because that is precisely what the blocking objective and the SLA remedy are for.

Read the contract carefully. "Up to" is doing a lot of work in "up to 100 concurrent calls."

Quality tiers and route selection

Not all calls follow the same path. Many providers maintain multiple route categories.

Direct routes. The provider has a direct interconnect with the terminating carrier. The call goes from your provider to the destination carrier with no intermediaries. Fewest hops, lowest latency, most predictable quality.

Standard routes. The call goes through one or two intermediate carriers. Quality is generally acceptable but less consistent than direct routes.

Least-cost routes. The provider uses a least-cost routing (LCR) engine that sends the call through whichever upstream carrier is cheapest at that moment. The path changes call by call. Quality varies because the cheapest route is not always the best route. Some LCR providers dynamically reroute calls through lower-quality carriers during peak periods because the higher-quality carriers are full or more expensive at that time.

Some providers sell these as explicit tiers. A "premium" trunk product uses direct routes and a "standard" product uses LCR. The premium product costs more but delivers consistently better quality. Others do not tell you which routing they use; they just sell you trunks and route your calls however is most profitable for them at that moment.

If your provider offers quality tiers, consider putting your highest-value traffic on the premium tier and your less critical traffic on standard. A sales floor where every call is a revenue opportunity warrants premium routing. An internal dial tone for a warehouse where people check voicemail twice a day does not.

What to ask a prospective trunk provider

Before signing a trunk contract, ask these questions. The answers, and how the provider responds to being asked, tell you a lot.

"How do you engineer capacity against sold entitlement, and what is your blocking objective at peak?" Most providers will not give you a ratio, and that is fine; the ratio was never the useful artifact. What you are listening for is whether they can articulate a capacity management approach at all. "We monitor aggregate utilization and add capacity at 70% of observed peak, and we engineer to a stated blocking target" tells you something real about their operations. "We provision 100% of sold capacity at all times" is either a very expensive product or not accurate.

"What is my concurrent call limit, and is it hard or soft?" You need to know whether your limit is enforced at the SBC or is a contractual number that depends on shared infrastructure.

"What routes will my calls take?" Ask specifically about PSTN termination. Do they have direct interconnects with major carriers? Do they use LCR? Do they offer different quality tiers? A provider that cannot or will not describe their routing is a red flag.

"Can you provide quality metrics for my calls?" Providers who monitor quality and make metrics available to customers are more likely to be managing their network proactively. Providers who have no quality reporting are flying blind, or they have the data and do not want you to see it.

"What happens during peak periods?" Ask about their busiest times and what capacity management looks like during those periods. Ask for historical uptime and quality statistics if available.

The terms to get in writing. Everything above is conversation; these are what you can actually enforce. Committed concurrent sessions, as distinct from any "up to" figure. The blocking target at peak. How burst capacity is treated when the network is busy. What the SLA measures, where it measures it, and what remedy it provides when the measurement is missed. A provider that commits to these in writing has given you something to hold them to regardless of how they engineer behind it.

Red flags: Reluctance to discuss capacity or routing at all. No quality reporting or monitoring tools. Support reachable only by email. Contract terms that disclaim quality obligations entirely, or that quote only an "up to" channel count with no committed figure behind it.

When a budget provider is a reasonable choice

Not every business needs a premium trunk. What matters is your call volume relative to the provider's peak load, and how much a bad hour costs you.

A five-person office making 20 calls a day, with maybe two or three calls concurrent at peak, is statistically invisible on the provider's network. They will almost never be the ones who get a 503 because they are using so little capacity. For this office, a budget provider is a rational choice. The savings are real and the risk is low.

A 100-seat call center running 60-80 concurrent calls during business hours is a completely different situation. They are a meaningful share of the provider's peak load. They will feel every capacity constraint. They need a provider whose infrastructure can handle their peak demand reliably, which means paying for that infrastructure. For this operation, saving $2 per channel per month by using a budget provider is a false economy when one bad hour costs more in lost productivity and lost deals than a year of the price difference.

The middle ground (a 20-50 person office with moderate call volume) is where the decision gets interesting. If the business is not particularly sensitive to voice quality (internal calls, low-stakes conversations), a mid-tier provider is fine. If voice is revenue-critical (sales teams, customer support, professional services where client perception matters), pay for quality.

Businesses in the middle ground are the ones most likely to suffer quietly, because they have enough volume to feel a constraint but not enough visibility into their own quality metrics to characterize it when it happens. They just know that "the phones sound bad sometimes" and attribute it to their internet connection or their PBX.

Measure it, then ask

You cannot see inside a provider's network, but you can establish that a problem is real, when it happens, and that it is not yours, which is what turns a support ticket from an anecdote into something actionable.

Track MOS scores over time. Compare peak against off-peak. Run a VoIP quality test during both to quantify the difference, and use the bandwidth calculator to confirm your own connection has headroom for your concurrent call volume. Run the on-net vs off-net comparison during a suspect period to move the fault boundary outside your building.

What that gives you is a documented, time-correlated pattern with your own network ruled out. The next step is not a conclusion but a request: ask the provider for utilization and admission-control data covering the windows you measured, and for the interconnect the affected calls traversed. How they respond to a specific, evidenced request, and whether the terms you signed give you any remedy if the answer is unsatisfactory, is usually more informative than the data itself.

For more context on related topics, see our posts on SIP trunking fundamentals, why call quality degrades in the afternoon, capacity planning for MSPs, and working effectively with trunk providers. If you are evaluating a new provider, our guide to trunk configuration covers the technical setup side.