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

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

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: