How to estimate SIP channel requirements

What a channel is

A SIP channel is the capacity to carry one call at a time between your phone system and the provider. Ten channels means up to ten calls in progress at the same moment, in any mix of inbound and outbound. The eleventh call is refused until one of the ten ends.

Channels are separate from numbers. A company with fifty direct-dial numbers may need only eight channels, because the fifty people are rarely all on the phone together. Sizing channels is therefore a question about concurrency: the most calls that will be in progress at once, not how many people or numbers you have.

Get the figure wrong in one direction and callers hear a busy tone or a failed call at your busiest moment. Get it wrong in the other and you pay for capacity that is never used. The methods below, used together, lead to a defensible number.

The busy hour

Call traffic is not spread evenly. Most organisations have a recognisable busy hour, often mid-morning or just after lunch, and busy days or seasons within the year. Capacity must be sized for that peak, not for the daily average.

The busy hour is the continuous sixty-minute period with the most traffic. When you look at your data, check several weeks and include known peaks such as month-end, renewals, campaign launches or service incidents. A week chosen at random will usually understate what you need.

Method 1: call logs

If you already run a phone system, your own records are the most reliable source. Most PBXs and carriers can export call detail records with a start time and duration for each call. From these you can work out how many calls overlapped at every moment.

1. Export call records for at least four weeks, including any known peak periods.
2. Include inbound and outbound calls, and calls that were answered by a menu or queue, not just by a person.
3. Calculate the maximum number of calls in progress at once for each day. Many PBX reports show this directly as peak concurrent calls or trunk utilisation.
4. Take the highest daily figure across the period, not the average of the daily peaks.

If you are replacing ISDN or analogue lines, also check whether callers have been hearing busy tones. A history of calls that peak at exactly your current line count suggests demand was being capped, and true demand is higher.

Method 2: rules of thumb

Where there is no usable data, such as a new office or a new phone system, ratios of users to channels give a starting point. Treat the figures below as rough starting points for discussion, not industry standards. They should be replaced with measured data as soon as it exists.

Ratios hide the shape of your traffic. Two offices of forty people can need very different capacity if one handles customer enquiries and the other rarely uses the phone. Use a ratio to frame the conversation, then refine it.

Method 3: Erlang B

Erlang B is the standard telephony model for sizing a group of lines. It answers a specific question: given a certain amount of traffic, how many channels are needed so that only a chosen small share of calls is blocked?

It uses two inputs.

• Traffic in Erlangs. One Erlang is one channel kept busy for a full hour. Busy-hour traffic is the number of calls in the busy hour multiplied by the average call duration, expressed in hours. Sixty three-minute calls in an hour is 180 minutes of calling, or 3 Erlangs.
• Grade of service. The share of calls you are prepared to see blocked in the busy hour. 1% is a common target for business lines; contact centres that cannot afford lost calls may choose lower.

The model assumes calls arrive randomly and that blocked callers do not immediately retry. Real callers do retry, so treat Erlang B as a sound baseline rather than an exact prediction. It also does not model queueing: if callers wait in a queue on your PBX, each waiting caller is holding a channel, and that time must be included in the call duration.

Erlang B calculators are widely available online and in spreadsheet form; you do not need to work the formula by hand.

A worked example

Suppose your call records show 300 calls in the busiest hour, inbound and outbound together, with an average duration of 3 minutes, including time spent in menus and queues.

1. Total busy-hour minutes: 300 calls × 3 minutes = 900 minutes.
2. Traffic: 900 minutes ÷ 60 = 15 Erlangs.
3. Apply Erlang B at the chosen grade of service.

At a 1% grade of service, approximately 24 channels are needed. Note that 15 channels, the figure you might reach by dividing minutes evenly across the hour, would block a large share of calls, because traffic arrives in bursts. The curve also flattens quickly: moving from 5% blocking to 1% costs only four more channels at this volume.

The same calculation for other traffic levels gives a sense of scale.

Larger groups are more efficient: the ratio of channels to traffic falls as volume rises. This is one reason a single shared trunk for several sites often needs fewer channels in total than separate trunks per site.

Office and contact-centre profiles

The direction and pattern of calls change the answer as much as the volume does.

Office traffic

A typical office has a mix of inbound and outbound calls of moderate length, with clear peaks during working hours. Internal calls between extensions do not use trunk channels. Transfers to external numbers, call forwarding to mobiles and conference bridges with external participants do, and a forwarded call uses two channels: one for the caller coming in and one for the leg going out.

Contact-centre traffic

In an inbound contact centre, every caller holds a channel from the moment the call is answered by the system, including time in the IVR and in the queue. If twenty agents are busy and ten callers are waiting, thirty channels are in use. Size for agents plus the longest queue you are prepared to hold, and use the queue’s maximum length or wait-time settings to keep demand within that limit. Our page on contact centres covers how numbers, queues and failover are planned together.

Outbound calling

Outbound teams using a predictive or progressive dialler may place more calls than there are agents, because many calls are not answered. The number of channels depends on the dialler’s pacing settings, so take the figure from the dialler configuration rather than from a ratio.

Inbound and outbound mix

Inbound and outbound calls share the same channel pool unless you split them. Some organisations reserve a portion of channels for inbound so that a heavy outbound campaign cannot prevent customers from getting through. Your PBX can usually enforce this with per-route channel limits.

Headroom and burst

A measured or calculated figure is a minimum. Before settling on a number, consider:

• Growth. Planned hiring, new sites or new services expected within the contract period.
• Seasonal peaks. Billing cycles, renewals, sales events or weather-related demand.
• Incidents. A service outage on your side can multiply inbound calls for a few hours.
• Failover. If one site’s calls move to another during an outage, the receiving trunk must carry both.

Some providers offer burst capacity, allowing calls above the committed channel count for short periods, usually charged differently. Where offered, it can cover infrequent peaks more economically than a permanently higher channel count. Confirm how burst is measured and billed before relying on it.

Bandwidth per call

Each concurrent call uses bandwidth in both directions. The codec sets the audio bit rate, but packet headers add a significant overhead, so the figure on the wire is higher than the codec’s nominal rate. The values below assume the common 20 ms packetisation and include IP, UDP, RTP and Ethernet framing.

For the worked example above, 24 concurrent G.711 calls need roughly 24 × 87 kbps, or about 2.1 Mbps in each direction, before any allowance for other traffic. Different packetisation intervals, VPN encapsulation and encryption change the overhead, so check the figures for your own setup.

Bandwidth alone does not guarantee quality. Voice needs low and consistent delay, so prioritise it on your network with quality-of-service settings and keep the connection from running close to saturation at peak times. Where the available bandwidth is limited, a compressed codec such as G.729 reduces the load, at the cost of some audio quality and only on routes that support it.