SIP Trunk Capacity Planning: How Many Channels Do You Need?

Why SIP Trunk Capacity Planning Matters

With traditional PRI (Primary Rate Interface) lines, capacity planning was straightforward but inflexible: each PRI delivered exactly 23 voice channels (in North America) or 30 channels (E1 in Europe). Need 24 calls? Buy a second PRI and pay for 46 channels, even if you only use 24.

SIP trunking changes this equation entirely. SIP channels scale dynamically -- you can go from 5 concurrent calls to 50 in the same day without installing new hardware or waiting weeks for provisioning. But this flexibility means you need to understand your actual usage patterns to provision the right amount of SIP trunk bandwidth and ensure voice quality stays high.

Proper SIP trunk capacity planning prevents two costly problems:

• Under-provisioning: Callers get busy signals or calls fail during peak hours
• Over-provisioning: You pay for bandwidth or channel licenses you never use

Understanding Concurrent Calls vs Channels

Before asking "how many SIP channels do I need," it helps to understand the terminology:

The key insight: you size for peak concurrent calls, not total daily volume. A company making 500 calls per day with an average duration of 3 minutes might never have more than 10-15 calls happening simultaneously. That means 15 channels is sufficient, not 500.

The Erlang B Formula Simplified

The Erlang B formula is the industry-standard method for calculating the number of channels (trunks) needed based on call traffic. It accounts for the statistical nature of call arrivals -- not everyone calls at exactly the same time.

The formula uses three variables:

• Traffic (in Erlangs): Calls per hour x average duration in hours. Example: 60 calls/hour with 3 min average = 60 x (3/60) = 3 Erlangs
• Channels (N): The number of trunks/channels available
• Blocking probability: The chance a call gets a busy signal (target: 1% or less)

Traffic (Erlangs) = (Calls per hour x Average call duration in seconds) / 3600
Example:
  Busy hour: 120 calls
  Average duration: 3 minutes (180 seconds)
  Traffic = (120 x 180) / 3600 = 6 Erlangs
  At 1% blocking: ~11 channels needed

Quick Reference: Channels by Company Size

Rather than running the Erlang calculation yourself, use this rule-of-thumb table based on typical office usage (average 3-minute calls, 1% blocking probability):

SIP Trunk Bandwidth Requirements by Codec

Once you know how many concurrent calls to support, you need to calculate the SIP trunk bandwidth required. The bandwidth per call depends on the audio codec used, plus protocol overhead (IP, UDP, RTP headers).

Here is the actual bandwidth consumption per call for common VoIP codecs:

Understanding the Overhead

The difference between audio bitrate and actual bandwidth comes from protocol headers added to each RTP packet:

Per packet overhead:
  IP header:       20 bytes
  UDP header:       8 bytes
  RTP header:      12 bytes
  --------------------
  Total overhead:  40 bytes per packet
G.711 at 20ms ptime:
  Payload:  160 bytes (20ms of audio at 64 kbps)
  + Header:  40 bytes
  --------------------
  Total:    200 bytes x 50 packets/sec = 80,000 bytes/sec
  = 80 kbps + Ethernet framing = ~87.2 kbps per direction
  = ~174.4 kbps bidirectional per call

Total Bandwidth Formula

Bandwidth Formula:

Total Bandwidth = Concurrent Calls x Codec Bandwidth x 2 (bidirectional) x 1.2 (20% overhead buffer)

The 20% overhead buffer accounts for SIP signaling, retransmissions, silence suppression variability, and network protocol overhead (Ethernet framing, etc.).

Bandwidth Calculation Examples

Here are real-world bandwidth calculations for different business sizes using the formula above:

Network Quality Requirements for VoIP

Bandwidth is only one piece of the puzzle. Voice quality depends on three additional network metrics. If any of these exceed acceptable thresholds, call quality degrades regardless of available bandwidth:

How to Test Your Network

Before deploying SIP trunks, run these tests to your provider's SIP server:

# Test latency and packet loss to SIP server
ping -c 100 s1.ipcomms.net
# Test jitter (requires iperf3 on both ends)
iperf3 -c s1.ipcomms.net -u -b 1M -t 60
# Continuous monitoring with mtr (shows per-hop stats)
mtr -n --report-cycles 100 s1.ipcomms.net
# Check for consistent latency (look for spikes)
ping -c 1000 -i 0.02 s1.ipcomms.net | tail -1

QoS Configuration for Voice Traffic

Quality of Service (QoS) marks voice packets as high priority so routers and switches can prioritize them over data traffic. This is critical when voice and data share the same network connection.

DSCP Markings for VoIP

Linux/Asterisk QoS (iptables marking)

# Mark RTP traffic (voice media) with DSCP EF (46)
iptables -t mangle -A OUTPUT -p udp --dport 10000:20000 \
  -j DSCP --set-dscp 46
# Mark SIP signaling with DSCP CS3 (24)
iptables -t mangle -A OUTPUT -p udp --dport 5060 \
  -j DSCP --set-dscp 24

IPComms Advantages for Capacity Planning

Traditional SIP trunk providers sell channels in fixed bundles (10, 25, 50). IPComms takes a different approach that simplifies capacity planning:

Monitoring Your SIP Trunk Usage

Ongoing monitoring ensures your capacity planning stays aligned with actual usage. Focus on these metrics:

Key Metrics to Track

• Peak concurrent calls: The highest number of simultaneous calls in any given period (daily, weekly, monthly)
• Busy hour traffic: Average concurrent calls during your busiest hour each day
• Average call duration: Longer calls mean fewer channels needed for the same call volume
• Failed calls (SIP 503): If you see 503 responses, you are hitting capacity limits
• ASR (Answer-Seizure Ratio): A drop in ASR can indicate trunk congestion

CDR Analysis for Peak Detection

Use CDR (Call Detail Records) data to identify your actual peak concurrent usage:

-- Find peak concurrent calls per hour (PostgreSQL)
WITH call_intervals AS (
  SELECT
    date_trunc('hour', setup_time) AS hour,
    setup_time AS start_time,
    setup_time + (duration || ' seconds')::interval AS end_time
  FROM cdrs
  WHERE setup_time >= NOW() - INTERVAL '30 days'
    AND usage > 0
)
SELECT
  hour,
  COUNT(*) AS total_calls,
  MAX(concurrent) AS peak_concurrent
FROM (
  SELECT
    ci.hour,
    ci.start_time,
    (SELECT COUNT(*) FROM call_intervals ci2
     WHERE ci2.start_time <= ci.start_time
       AND ci2.end_time > ci.start_time
       AND ci2.hour = ci.hour) AS concurrent
  FROM call_intervals ci
) sub
GROUP BY hour
ORDER BY peak_concurrent DESC
LIMIT 10;

Scaling Tips: Start Small, Grow Confidently

One of the biggest advantages of SIP trunking over PRI is the ability to scale instantly. Here is a practical approach to growth:

Start with Your Erlang Estimate

Use the table above to determine your baseline channel count. For a 25-person office, start with bandwidth supporting 9 concurrent calls.

Monitor Your First 30 Days

Track peak concurrent calls daily. You will likely find your actual usage is 20-30% below the Erlang estimate (the formula has built-in conservatism).

Add 20-30% Headroom

Once you know your real peak, ensure your bandwidth supports at least 30% more concurrent calls. This handles seasonal spikes, marketing campaigns, or organic growth.

Plan for Growth Events

Opening a new office? Launching a campaign? Add capacity proactively. With SIP, scaling up is instant - no 4-6 week PRI provisioning lead time.

Review Quarterly

Reassess capacity every quarter. Usage patterns change with hiring, remote work adoption, and seasonal trends. Adjust bandwidth allocation accordingly.

Stop Paying for Channels You Don't Use

IPComms SIP trunking eliminates channel counting. Pay per minute with unlimited concurrent calls, burst capacity, and real-time CDR analytics. Get started today.