How many simultaneous calls do I need or get on a SIP trunk?

Simultaneous calls on a SIP trunk are measured in channels, also called concurrent call paths or sessions, and one channel carries exactly one call at a time.[1][5] The question really has two sides that are easy to run together. One side is how many concurrent calls you need, which is a sizing problem driven by how many calls your organization runs at the same moment during its busiest hour. The other side is how many you can get, which is a capacity problem set by your internet bandwidth, your audio codec, and whatever channel limit your provider attaches to your plan.[6][7] A well planned trunk lines those two numbers up, with the capacity you buy sitting a comfortable margin above the concurrency you actually use.

The count that matters for sizing is simultaneous calls, not the number of employees, desk phones, or phone numbers you hold.[5][9] A fifty person office almost never has fifty people talking at once, so buying fifty channels wastes money, while a ten seat outbound sales team can run near ten calls continuously and needs close to that many. Direct inward dial numbers are separate again, because you can point hundreds of numbers at a trunk that only carries a dozen concurrent calls, since most of those numbers sit idle at any given second.[5]

Why the old line-counting habit does not transfer

On a legacy PRI circuit, capacity arrived in a fixed block of physical channels, and adding calls beyond that block meant installing another circuit.[9][11] A SIP trunk removes that hardware step, so capacity becomes a number your provider sets in software and bills per channel or per minute.[11][4] That flexibility is useful, yet it shifts the work onto you to pick the right number, because there is no physical circuit forcing the decision. The rest of this answer covers how to calculate the number you need, then what caps the number you can actually run.

The ratio method divides your headcount by a rule-of-thumb figure to get a channel estimate, and it works because most people are not on the phone at the same time.[5] For a general office, a common baseline is one channel for every three to four employees, which assumes a mix of calls, email, and meetings across the day.[5][4] A ten person office lands around three channels on that math, and a fifty person office around thirteen to seventeen.[4] Contact centers break the ratio, because agents are on calls for most of their shift, so the planning figure moves close to one channel per active agent, and outbound teams that dial continuously sometimes need more than one.[4][8]

The appeal of this method is that it takes a minute and needs no call data, which makes it a reasonable first pass for a small, predictable office. Its weakness is that a single divisor cannot know your actual call profile, so a busy inside sales team sized at one channel per four people will hit its ceiling and start blocking calls at peak. Treat the ratio as a starting estimate you refine against real numbers, rather than the final count you buy.

This method multiplies the number of people who make external calls by the share of them on a call at your busiest moment, which produces a concurrency estimate tuned to how your team actually works.[7] The formula is short: estimated concurrent calls equals peak utilization percentage times the number of external call users.[7] What gives the approach its value is the peak utilization figure, because it forces you to describe your own call pattern instead of borrowing an office average.

Published benchmarks give a sense of the spread. Retail or sales call centers often run 40 to 60 percent of seats on calls at once, technical or SaaS support teams tend to land somewhere around 15 to 30 percent, and a law firm or similar professional office may sit at 10 to 20 percent.[7] A forty person support team at 25 percent peak concurrency needs about ten channels, a number a flat office ratio could miss in either direction depending on the divisor you picked. Where you already have history from your phone system or provider, use your own measured peak rather than a benchmark, since the benchmark is only a stand-in until you have the real figure.

Erlang B is the traffic-engineering model built for exactly this question, and it converts your busy-hour calling into the number of channels required to keep blocked calls below a target you set.[2][3] It fits trunk sizing because a SIP trunk clears a blocked call rather than queuing it: when every channel is busy, the next caller gets a busy signal, which is the assumption the model is built on.[3] Erlang C is the related model for agent queues where callers wait on hold, so it sizes staff rather than trunks.[3]

The inputs and the formula

The model needs your busy-hour traffic in a unit called the Erlang and your target blocking rate, and it returns the channel count.[2] Busy-hour traffic reduces to a single number: calls per hour times average call duration in seconds, divided by 3,600.[2][3] A site handling 350 calls an hour at 180 seconds each carries 17.5 Erlangs of traffic.[2] Feed that into an Erlang B calculator at one percent blocking, the normal target in traffic engineering, and the answer is 27 channels, while a more relaxed three percent target needs fewer.[2] A smaller case lands the same way: 120 busy-hour calls at three minutes each is 6 Erlangs, which needs about 11 channels at one percent blocking.[4]

Why the precise method is worth it

The Erlang calculation earns its keep where under-buying has a real cost, such as a contact center that loses revenue on every blocked call, because it ties the channel count to a defined service level instead of a guess.[2] For a small office the ratio method usually lands close enough. Once call volume climbs or turns spiky, the traffic model becomes the difference between paying for idle channels and turning callers away at the peak.

There is no single fixed number, because a SIP trunk's ceiling is set by your bandwidth, your codec, and any cap your provider places on the plan, not by the trunk itself.[6][7] In practice a standard business trunk is often provisioned for something like 20 to 25 concurrent calls, a high-capacity trunk for up to around 100, and some cloud providers sell trunks with no hard channel cap at all, letting bandwidth be the only limit.[6] The figure you can actually sustain comes down to a few factors worth understanding separately.

Bandwidth is the hard physical limit

Every concurrent call consumes a slice of your internet connection, so the usable ceiling is your available voice bandwidth divided by the bandwidth per call.[6][9] With the common G.711 codec, each call needs roughly 80 to 90 kilobits per second once IP, UDP, and RTP overhead sits on top of the 64 kilobit payload, and one provider guide puts the practical range at 85 to 115 kilobits depending on codec.[9][10][5] A clean 2 megabit link therefore carries about 25 simultaneous G.711 calls, and the same arithmetic scales up from there.[6]

The codec changes the number sharply

Swapping codecs moves the ceiling a long way, because a more compressed codec fits more calls into the same pipe.[7] G.711 sends uncompressed audio at 64 kilobits and gives the best fidelity, while G.729 compresses to roughly 8 to 24 kilobits and Opus adapts across a similar low range, at some cost to quality.[10][6][7] A 10 megabit connection that holds around 50 G.711 calls can carry closer to 100 with G.729, which is why codec choice is a capacity decision and not only a quality one.[6][7]

The provider plan sets a soft cap

Above the physical limit, most providers attach a channel cap to your subscription, an administrative ceiling that restricts concurrency regardless of how much bandwidth you have.[7] Because that cap lives in software, a provider can raise or lower it on request, often the same day, which is how seasonal peaks get handled without new hardware.[11][9] Confirm both numbers when you buy, the channels your plan permits and the bandwidth your connection can actually sustain, since the smaller of the two is your real ceiling.

Your own network can cap it too

Your network configuration adds its own limits, so a trunk rated for hundreds of calls still stops at whatever your firewall, session border controller, or phone system is set to allow.[6][7] On larger deployments this is worth checking, because the bottleneck is sometimes local equipment rather than the trunk or the circuit.

Sizing a trunk balances the cost of idle channels against the cost of blocked calls, and a few specifics deserve attention before you settle on a number.

Add headroom, but not too much

Plan capacity above your measured peak, since real traffic spikes past its average and calls sometimes hang up slower than expected.[4] A common margin is 20 to 30 percent over peak concurrency, enough to absorb a busy morning without paying year-round for channels that rarely fill.[4] Buy far beyond that and you are funding capacity that sits idle, while sizing exactly to the peak means a single unusual hour starts blocking calls.

Blocking is a business decision, not just a number

The blocking target you choose has a cost on both sides, because a one percent target buys more channels than a three percent target for the same traffic.[2] A sales line where a blocked call is a lost deal justifies the tighter target and the extra channels, while an internal helpdesk can often accept looser blocking and a smaller trunk.[2] The right figure follows from what a missed call actually costs you.

Metered plans change the math

If your provider bills per minute rather than per channel, the concurrency ceiling still matters for quality, but the monthly cost tracks usage instead of provisioned capacity.[8] Lines that sit quiet much of the day can be cheaper on a metered plan, while steady high volume usually favors a flat per-channel rate, so matching the billing model to your call pattern is part of sizing rather than a separate step.[8]

Bandwidth contention degrades calls before it blocks them

A trunk sized correctly on paper can still sound bad if voice competes with other traffic on the same link, because congestion shows up as choppy audio well before it refuses a call.[6] Reserving bandwidth for voice with quality-of-service settings, and keeping headroom on the connection, is what protects the calls you sized for.[6]

The concurrent-call count is a specific measure, and it gets confused with several nearby figures that size differently.

It is not your number of employees or phones

Concurrency counts calls happening at the same instant, not the people or handsets that could place them, and the gap between the two is usually large.[5][9] A team of fifty rarely exceeds fifteen or twenty simultaneous calls, so sizing to headcount overbuys the trunk.[9]

It is not your count of phone numbers

Direct inward dial numbers and channels are billed and sized separately, because a number is an address while a channel is a call path.[5] You can hold hundreds of numbers on a trunk that carries a dozen concurrent calls, since most numbers are idle at any moment.[5]

It is not the number of SIP trunks you buy

A single SIP trunk can carry many channels, so the number of trunks and the number of concurrent calls are different quantities.[8] Providers express capacity as sessions or channels within a trunk, and one trunk with enough channels serves most organizations without adding more trunks.[8]

It is not a permanent figure

Channel capacity is adjustable in software, so the number is a setting you revisit as call volume changes rather than a fixed circuit you live with.[11][4] Reviewing busy-hour concurrency every few months keeps the trunk sized to current demand instead of last year's.[4]