DEV Community

Jason Shouldice
Jason Shouldice

Posted on • Originally published at vicistack.com

VICIdial SIP Trunk Capacity Planning

Originally published at vicistack.com. Follow us for more call center engineering content.

Last updated: March 2026 | Reading time: ~22 minutes

SIP trunk sizing for a call center is not the same as SIP trunk sizing for an office. Office workers spend 10-20% of their time on the phone. Call center agents spend 60-80%. An office with 50 employees might need 15 SIP channels. A call center with 50 agents needs 75-125. Get the sizing wrong and your agents hear busy signals, your predictive dialer starves, and you're paying for emergency channel upgrades at carrier rush rates.

Most VICIdial admins size their trunks by gut feel: "we have 50 agents, so maybe 100 channels?" That's not terrible, but it's imprecise. The real answer depends on your dial ratio, answer rate, call duration, and how much blocking you're willing to tolerate.

Here's how to calculate it properly, with the same formulas telecom engineers have used since 1917 (seriously — the Erlang formula is over 100 years old and still the standard).


The Core Concept: Concurrent Channels

A SIP trunk channel is a single simultaneous voice path. One channel = one active call. If you have 100 channels and 101 calls try to connect at the same time, call #101 gets a busy signal or fails.

For VICIdial predictive dialing, "concurrent calls" includes:

  • Calls currently connected to agents (talk time)
  • Calls currently ringing (waiting for answer)
  • Calls currently in AMD processing (detecting voicemail)
  • Calls in queue (inbound waiting for agents)
  • Any transfers or 3-way calls (each leg uses a channel)

This is why the channel count is always higher than the agent count. The dialer is making calls before agents are available, waiting for answers, processing AMD results, and handling the connection overhead.


Step 1: Calculate Peak Concurrent Calls

The Simple Formula

For a predictive dialer like VICIdial, the quick calculation:

Peak Channels = Agents × Dial Ratio × Overhead Factor
Enter fullscreen mode Exit fullscreen mode

Where:

  • Agents = peak logged-in agents at any point in the day
  • Dial Ratio = lines dialed per agent (VICIdial's auto_dial_level)
  • Overhead Factor = 1.1-1.2 (10-20% for transfers, recordings, system calls)

Example: 50 agents, dial level 3.0, 1.15 overhead factor:

Peak Channels = 50 × 3.0 × 1.15 = 172.5 → round up to 175
Enter fullscreen mode Exit fullscreen mode

The Detailed Formula

For more precision, break it down by call state:

Active Talk Channels = Agents × Talk Time Ratio
Ringing Channels = Agents × Dial Level × (1 - Connect Rate) × Avg Ring Time / Avg Dial Cycle
AMD Channels = Agents × Dial Level × Connect Rate × AMD Rate × AMD Duration / Avg Dial Cycle
Transfer Channels = Agents × Transfer Rate
Total = Active Talk + Ringing + AMD + Transfer + Buffer
Enter fullscreen mode Exit fullscreen mode

Real numbers from a 50-agent outbound B2C center:

  • Talk Time Ratio: 0.55 (agents on calls 55% of the time)
  • Dial Level: 2.5
  • Connect Rate: 0.28 (28% of dials connect to a human or machine)
  • AMD Rate: 0.65 (65% of answered calls are machines)
  • Transfer Rate: 0.05 (5% of calls result in a transfer)
Active Talk = 50 × 0.55 = 27.5 channels
Ringing = 50 × 2.5 × 0.72 × (10s / 25s) = 36 channels
AMD = 50 × 2.5 × 0.28 × 0.65 × (3s / 25s) = 2.7 channels
Transfer = 50 × 0.05 = 2.5 channels
Buffer = 10% of total = 6.9 channels

Total = 27.5 + 36 + 2.7 + 2.5 + 6.9 = 75.6 → round up to 80
Enter fullscreen mode Exit fullscreen mode

This center needs about 80 concurrent channels at peak, even though the simple formula suggested 145. The difference is that the simple formula assumes all dial slots are active simultaneously, which they're not in practice.


Step 2: Apply Erlang B for Grade of Service

The Erlang B formula calculates how many channels you need to handle your traffic load with an acceptable failure rate (Grade of Service, or GoS). A GoS of 0.01 means 1% of calls will get a busy signal — this is the the baseline for a 50-agent VICIdial shop for call centers.

The Math

Busy Hour Traffic (BHT) in Erlangs:

BHT = (Calls per Hour × Average Call Duration in seconds) / 3600
Enter fullscreen mode Exit fullscreen mode

For our 50-agent center:

  • Calls per hour: 750 (outbound dials that connect, including machines)
  • Average call duration: 45 seconds (including short AMD detections)
BHT = (750 × 45) / 3600 = 9.375 Erlangs
Enter fullscreen mode Exit fullscreen mode

Wait, that seems low. Here's the catch: in predictive dialing, you need to calculate based on total dials (including no-answers), not just connected calls:

  • Total dials per hour: 50 agents × 2.5 dial level × 60 minutes / avg_dial_cycle = about 3,000 dial attempts per hour
  • Average channel hold time (including ring-no-answer): 12 seconds per attempt
BHT = (3000 × 12) / 3600 = 10 Erlangs
Enter fullscreen mode Exit fullscreen mode

Now apply the Erlang B table. For 10 Erlangs at 1% GoS, you need approximately 18 channels for just the traffic load. But this doesn't account for simultaneous channel occupancy in a predictive dialer — Erlang B was designed for random call arrival patterns, not machine-gun dialing.

Adjusting Erlang B for Predictive Dialing

Predictive dialers don't generate random traffic — they generate bursty, correlated traffic. All dial channels fire in waves as agents become available. This means the Erlang B result underestimates channel requirements for predictive dialing by 30-50%.

Adjusted calculation: Multiply the Erlang B result by 1.5 for predictive dialing:

Channels = Erlang_B_channels × 1.5
Enter fullscreen mode Exit fullscreen mode

Or better yet, use the direct calculation from Step 1 and use Erlang B as a sanity check.

Practical Channel Counts by Scale

Based on real VICIdial deployments across our client base:

Agents Dial Level Recommended Channels Bandwidth (G.711)
10 2.0 25-30 2.6 Mbps
20 2.5 55-65 5.7 Mbps
30 2.5 80-95 8.3 Mbps
50 2.5-3.0 130-160 14.0 Mbps
75 2.5 190-220 19.3 Mbps
100 2.5 260-300 26.2 Mbps
150 2.0-2.5 370-420 36.7 Mbps
200 2.0 450-520 45.5 Mbps

These include a 15-20% buffer above calculated peak.


Step 3: Calculate Bandwidth

Each SIP channel consumes bandwidth for the audio payload plus protocol overhead (IP, UDP, RTP headers). The bandwidth per channel depends on the codec:

Codec Audio Bitrate Per-Channel Bandwidth (with overhead) Notes
G.711 ulaw 64 kbps 87.2 kbps Call center standard
G.711 alaw 64 kbps 87.2 kbps Same as ulaw, different encoding
G.729 8 kbps 31.2 kbps Lower quality, saves bandwidth
G.722 64 kbps 87.2 kbps Wideband, better quality
Opus 6-510 kbps (variable) 32-96 kbps typical Adaptive, modern

Bandwidth Calculation

Total Bandwidth = Peak Concurrent Channels × Per-Channel Bandwidth × 2 (bidirectional) × 1.2 (buffer)
Enter fullscreen mode Exit fullscreen mode

For 100 channels at G.711:

Total = 100 × 87.2 kbps × 2 × 1.2 = 20,928 kbps ≈ 21 Mbps
Enter fullscreen mode Exit fullscreen mode

This is just the voice traffic. You also need bandwidth for:

  • SIP signaling: Minimal (~10 kbps per 100 calls)
  • VICIdial agent web interface: ~200 kbps per agent (thin web pages)
  • VPN overhead (if agents are remote): 10-30% additional
  • General internet traffic: Whatever your operation uses

QoS Matters More Than Raw Bandwidth

Having enough bandwidth is necessary but not sufficient. VoIP quality requires:

  • Latency: Under 150ms one-way (under 80ms for excellent quality)
  • Jitter: Under 30ms (under 15ms preferred)
  • Packet loss: Under 0.5% (under 0.1% preferred)

If your internet circuit handles 100 Mbps but a large file download can consume 80 Mbps of it, your voice traffic will suffer. Quality of Service (QoS) configuration is mandatory:

  1. At your router/firewall: Mark RTP traffic (UDP ports 10000-20000) with DSCP EF (value 46)
  2. On your switch: Enable priority queuing for DSCP EF traffic
  3. At your ISP: If possible, get a dedicated circuit or MPLS path for voice

For remote agents, the same QoS rules apply at their home routers. We've found that 60% of "carrier quality" complaints in VICIdial deployments trace back to agent-side network issues. See our MOS score testing guide for diagnostic procedures.


Step 4: Carrier Redundancy

Running all your trunks through a single carrier is asking for a bad day. Carrier outages happen — usually at the worst possible time. A diversified trunk strategy costs slightly more but prevents total calling loss.

The Split Strategy

Divide your channels across 2-3 carriers:

Carrier Channel Allocation Purpose
Primary (e.g., Telnyx) 60% of channels Main calling path
Secondary (e.g., Bandwidth) 30% of channels Secondary path + failover
Tertiary (e.g., VoIP.ms) 10% of channels Emergency failover

Asterisk Failover Configuration

VICIdial supports carrier-level failover. In your carrier configuration (Admin > Carriers), set up multiple carriers with failover order:

  1. Primary carrier as the default outbound route
  2. Secondary carrier with failover on busy/congestion/failure
  3. Configure in Asterisk with dial string failover:
# In the carrier definition
Dial Prefix: PJSIP/primary_carrier/sip:
Dial Timeout: 30
# Alt carrier on failure
Enter fullscreen mode Exit fullscreen mode

In VICIdial, you configure this through the Admin GUI under Carriers:

  • Set the primary carrier with a lower sequential ID
  • Set the failover carrier's registration with the appropriate settings
  • Enable carrier failover in the campaign settings

Testing Failover

Don't wait for a real outage to discover your failover doesn't work. Test quarterly:

  1. Temporarily disable the primary carrier trunk in Asterisk
  2. Verify that calls route to the secondary carrier
  3. Check that audio quality is acceptable on the backup
  4. Re-enable the primary carrier
  5. Document the failover time (should be under 5 seconds for the first call)

Step 5: Monitor and Adjust

Trunk capacity needs change over time. Seasonal hiring bumps, campaign changes, and dial ratio adjustments all affect channel requirements.

Real-Time Channel Monitoring

Check current channel usage on the Asterisk CLI:

asterisk -rx "core show channels count"
Enter fullscreen mode Exit fullscreen mode

Output:

42 active channels
28 active calls
39 calls processed
Enter fullscreen mode Exit fullscreen mode

Active channels includes all legs (both sides of a call, plus conference bridges). Active calls is the number of actual conversations. For capacity planning, you care about active channels.

Peak Concurrent Channel Tracking

Set up a cron job to log channel counts every minute during business hours:

#!/bin/bash
# /usr/local/bin/channel-tracker.sh
CHANNELS=$(asterisk -rx "core show channels count" | head -1 | awk '{print $1}')
TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")
echo "$TIMESTAMP,$CHANNELS" >> /var/log/channel-usage.csv
Enter fullscreen mode Exit fullscreen mode

Cron:

* 8-20 * * 1-5 /usr/local/bin/channel-tracker.sh
Enter fullscreen mode Exit fullscreen mode

After a month, analyze the CSV to find your actual peak:

sort -t, -k2 -n -r /var/log/channel-usage.csv | head -10
Enter fullscreen mode Exit fullscreen mode

Your trunk allocation should be 20-30% above this observed peak.

Carrier Dashboard Monitoring

Most SIP carriers provide usage dashboards showing:

  • Peak concurrent channels
  • Total minutes used
  • Call completion rates
  • Average call duration

Review monthly. If your peak consistently hits 80%+ of your allocated channels, upgrade before you start getting busy signals.

When to Add Capacity

Upgrade trigger: Peak channel usage exceeds 75% of allocated channels for 3+ consecutive business days.

Downgrade trigger: Peak channel usage stays below 40% of allocated channels for a full month. Paying for unused channels wastes money.


Common Sizing Mistakes

Mistake 1: Sizing for Average Instead of Peak

Your average concurrent calls might be 60. Your peak at 10:30 AM on Tuesday might be 140. If you size for 60, Tuesday morning agents hear busy signals and your dial level auto-adjusts downward, killing productivity for the rest of the day.

Always size for peak + 20% buffer.

Mistake 2: Forgetting About Dial Level Changes

If you hire 20 more agents next month and plan to run them at dial level 3.0, that's 60 more channels needed. Plan capacity in advance, not the morning they start.

Mistake 3: Ignoring Inbound Channel Requirements

Blended operations need channels for both outbound dialing and inbound queue capacity. If you get a surge of 50 inbound calls and all your channels are consumed by outbound dialing, inbound callers get busy signals.

Reserve 15-20% of your total channels for inbound if you run blended.

Mistake 4: Not Testing After Changes

After any carrier change, channel upgrade, or Asterisk configuration modification, run a load test during off-hours:

# In Asterisk CLI, dial multiple test numbers simultaneously
# Monitor channel count in real time
watch -n 1 'asterisk -rx "core show channels count"'
Enter fullscreen mode Exit fullscreen mode

Verify that your system can use all the channels you're paying for. Configuration errors can limit concurrent calls below what the carrier provides.


Putting It All Together

Here's the capacity planning worksheet we use for every VICIdial deployment:

1. Peak concurrent agents: ___
2. Target dial level: ___
3. Simple channel estimate (1 × 2 × 1.15): ___
4. Inbound channel reserve (15-20%): ___
5. Total channels needed (3 + 4): ___
6. Primary carrier allocation (60%): ___
7. Secondary carrier allocation (30%): ___
8. Tertiary carrier allocation (10%): ___
9. Codec choice: ___
10. Per-channel bandwidth: ___
11. Total voice bandwidth (5 × 10 × 2 × 1.2): ___
12. QoS configured? (Y/N): ___
Enter fullscreen mode Exit fullscreen mode

Fill this out for your operation. If the numbers surprise you — either you need more channels than expected or you're paying for too many — that's the value of doing the math instead of guessing.



Related reading:

Case 1: 30-Agent B2C Solar Sales Center

Starting parameters:

  • 30 agents, peak hours 9 AM - 6 PM EST
  • Predictive dialing at level 2.5
  • Contact rate: 22% (lots of disconnected/wrong numbers in solar lists)
  • Average talk time: 4.2 minutes for connects, 8 seconds for AMD
  • Transfer rate: 8% (warm transfers to closers)

Channel calculation:

Active talk: 30 × 0.50 = 15 channels
Ringing: 30 × 2.5 × 0.78 × (10/22) = 26.6 channels
AMD processing: 30 × 2.5 × 0.22 × 0.70 × (3/22) = 1.6 channels
Transfers: 30 × 0.08 = 2.4 channels
Buffer (15%): 6.8 channels
Total: 52.4 → 55 channels
Enter fullscreen mode Exit fullscreen mode

Bandwidth at G.711: 55 × 87.2 × 2 × 1.2 = 11.5 Mbps

Carrier split: Primary (Telnyx) 35 channels, Secondary (Bandwidth) 20 channels.

Monthly carrier cost at $0.009/min: ~$4,200 in trunking fees.

Case 2: 80-Agent Blended Insurance Center

Starting parameters:

  • 80 agents: 55 outbound, 25 inbound/blended
  • Outbound dial level: 2.0 (lower because insurance conversations are longer)
  • Inbound volume: ~400 calls/day
  • Average outbound talk time: 6.5 minutes
  • Average inbound talk time: 8.2 minutes

Channel calculation:

Outbound active: 55 × 0.55 = 30 channels
Outbound ringing: 55 × 2.0 × 0.75 × (10/30) = 27.5 channels
Inbound queue: 400/8 hours / 60 minutes × 8.2 min avg × 1.3 overlap = 8.9 channels
Inbound reserve buffer: 15 channels (for burst periods)
Transfers: 80 × 0.12 = 9.6 channels
System overhead: 5 channels (recordings, conferences)
Buffer (15%): 14.4 channels
Total: 110.4 → 115 channels
Enter fullscreen mode Exit fullscreen mode

Bandwidth at G.711: 115 × 87.2 × 2 × 1.2 = 24.1 Mbps

This center runs two dedicated internet circuits — one for voice (30 Mbps dedicated, QoS enabled) and one for data (100 Mbps shared). The voice circuit never competes with agent web browsing or CRM traffic.

Carrier split: Primary 70 channels, Secondary 35 channels, Emergency 10 channels across three carriers.

Case 3: 200-Agent Multi-Campaign Debt Collection

Starting parameters:

  • 200 agents across 6 campaigns
  • Dial levels range from 1.5 (compliance-heavy) to 3.0 (skip-trace)
  • Weighted average dial level: 2.2
  • Contact rate: 18% (debt collection lists have high bad-number rates)
  • Average talk time: 3.1 minutes
  • Heavy callback volume: 15% of daily dials are scheduled callbacks

Channel calculation:

Active talk: 200 × 0.48 = 96 channels
Ringing: 200 × 2.2 × 0.82 × (12/25) = 173 channels
AMD: 200 × 2.2 × 0.18 × 0.55 × (3/25) = 5.2 channels
Callbacks (dedicated channels): 200 × 0.15 × 0.3 = 9 channels
Transfers: 200 × 0.06 = 12 channels
System overhead: 15 channels
Buffer (20%): 62 channels
Total: 372.2 → 380 channels
Enter fullscreen mode Exit fullscreen mode

Bandwidth at G.711: 380 × 87.2 × 2 × 1.2 = 79.5 Mbps

This operation runs on bare-metal servers in a colocation facility with a dedicated 100 Mbps circuit for voice traffic. They carry 3 SIP carriers: primary handles 60% of volume, secondary handles 30%, and a budget carrier handles 10% (used for skip-trace campaigns where quality is less critical).


For VICIdial operations where capacity planning, carrier selection, and voice quality optimization matter, ViciStack does this analysis as part of the $5K engagement. We audit your current trunk utilization, identify waste, right-size your carrier contracts, and configure proper failover — typically saving 10-25% on carrier costs while improving call completion rates.

Top comments (0)