How many SIP channels do you actually need?

The two common ways to size a SIP trunk are both wrong. One is to buy a channel per extension, which pays for capacity nobody uses. The other is to keep whatever the old PRI had, which carries forward a decision made for different traffic on different hardware. The right answer comes from a calculation that takes about ten minutes.

What you are actually sizing

A SIP channel carries one concurrent call. You are not sizing for how many phones exist, you are sizing for how many of them are in use at the same moment during the busiest period of a normal week.

In a typical office that peak is a small fraction of the handsets. In a contact center it is close to the number of agents on shift, because that is what a contact center is. The two need different arithmetic and it is worth being clear which one you are.

Erlangs, briefly

An Erlang is one hour of call time in one hour — one channel occupied continuously. Your busy-hour traffic in Erlangs is:

(calls in the busy hour × average call length in seconds) ÷ 3600

Two hundred calls averaging three minutes gives (200 × 180) ÷ 3600 = 10 Erlangs. That is the load. It is not the number of channels, because calls do not arrive politely spaced.

From load to channels

Erlang B converts that load into a channel count for a chosen blocking probability — the proportion of calls you accept may hit a busy signal. One percent is the usual target for business voice.

Ten Erlangs at 1% blocking needs roughly 18 channels. The gap between 10 and 18 is the overhead of randomness, and it is where sizing by intuition goes wrong in both directions: people either ignore it entirely and under-buy, or panic and double everything.

The relationship is not linear, which matters when you consolidate. Two sites each needing 18 channels do not need 36 between them if they share a trunk — a single 30-Erlang pool needs around 41. Consolidating trunks across sites is usually the largest single saving available on a voice bill.

Get the busy hour from the system, not from memory

Every PBX worth running logs call detail records. Pull a month, group by hour, and look at the concurrent-call peak rather than the call count. Two things regularly turn up:

• The busy hour is not where people assume. Monday morning and the hour after lunch beat mid-afternoon in most offices.
• There is a seasonal or monthly peak — invoicing day, results week, a campaign — that is well above the ordinary busy hour. Size for the recurring peak, not the annual maximum, and have a burst arrangement for the rest.

What the calculation leaves out

• Fax and lift lines.The ones that still exist. Each occupies a channel while active, and none of them appear in your contact center statistics.
• Call recording and monitoring legs.Some platforms create these as separate sessions, each taking a channel.
• Conference bridges.Each external participant is a channel.
• Emergency calling.It must succeed even when the trunk is otherwise full, so reserving a channel or two is cheap insurance.

Bursting, and why it changes the sum

Most SIP providers sell either a fixed channel count or a burstable arrangement priced per concurrent call beyond a committed base. Where bursting is available, the economics change: size the committed base to the ordinary busy hour and let the genuine peaks burst. Sizing to the annual maximum on a fixed plan means paying for the worst Tuesday of the year, every day.

A short procedure

1. Export twelve months of CDRs and find the concurrent-call peak per hour.
2. Take the recurring busy hour, not the annual maximum.
3. Convert to Erlangs, then to channels at 1% blocking.
4. Add the things CDRs miss — fax, lifts, recording legs, conference participants.
5. Reserve for emergency calling.
6. Decide the committed base against burst pricing, and consolidate trunks across sites if they are separate.

AcmaPBX records the call detail you need for step one and reports concurrent-channel occupancy directly, so the sizing exercise is a report rather than a spreadsheet project. If you are carrying a channel count inherited from a PRI, it is worth redoing.