Designing SIP Trunk Capacity Planning Models Using Erlang B and C Calculations
Executive Summary & Architectural Context
In the engineering of a voice infrastructure, the most expensive mistake is a “Ghost Bottleneck.” Imagine a contact center with 200 high-performing agents and a sophisticated IVR, but only 150 “SIP Sessions” (concurrent call paths) licensed on their carrier trunk. On a busy Monday morning, as the 151st caller dials in, they don’t hear your “Welcome” greeting or your “We value your call” music. Instead, they hear a jarring “Fast Busy” signal or a generic “Network Congestion” recording from the carrier. Because the call never reached your Genesys Cloud or NICE CXone platform, your “Queue Abandonment” reports show 0%, and your supervisors think everything is fine. Meanwhile, the business is losing thousands of dollars in revenue because 30% of their callers can’t even get into the building.
A Principal Architect knows that voice capacity is a mathematical certainty, not a guess. To prevent this, you must use Erlang B and C Calculations. Erlang B determines how many trunks you need to prevent callers from being “Blocked” (hearing a busy signal), while Erlang C determines how many agents you need to ensure callers aren’t waiting in the queue too long.
This masterclass details how to build a precise capacity planning model for SIP trunking, ensuring you have the exact number of sessions required to protect your customer experience without overpaying for unused licenses.
Prerequisites, Roles & Licensing
Licensing & Permissions
- Licensing Tier: Genesys Cloud CX 1, 2, or 3. BYOC Cloud/Premise.
- Granular Permissions:
Telephony > Trunk > ViewAnalytics > Conversation Detail > View(to gather historical Busy Hour data)
- Dependencies:
- Historical Data: At least 30 days of Call Arrival Rate and Average Handle Time (AHT) data.
- Erlang Calculator: A spreadsheet-based or programmatic Erlang function.
The Implementation Deep-Dive
1. The Physics of Capacity: Erlang B vs. Erlang C
You must distinguish between the “Trunk” (the doorway) and the “Queue” (the waiting room).
- Erlang B (The Trunk Doorway): This model assumes that if all trunks are busy, the next caller is “Blocked” and disappears. This is the math used to decide how many SIP Sessions you need.
- Erlang C (The Agent Waiting Room): This model assumes that if all agents are busy, the next caller waits in a queue. This is the math used to decide your Agent Staffing.
2. Step 1: Calculating “Busy Hour Traffic” (BHT)
To use the Erlang B formula, you must first calculate your “Traffic Intensity” in Erlangs.
The Formula:
Erlangs = (Calls per Hour * Average Handle Time in Seconds) / 3600
The Scenario:
- Your busiest hour (Monday 9 AM) sees 600 calls.
- Your average customer spends 300 seconds (5 minutes) in the system (IVR time + Agent time).
- Calculation:
(600 * 300) / 3600 = 50 Erlangs.
3. Step 2: Determining SIP Sessions (Erlang B)
Now, apply the Grade of Service (GoS). GoS represents the probability that a call will be blocked. For most professional centers, the GoS target is P.01 (only 1% of calls are blocked).
The Principal Architect’s Strategy:
- Use an Erlang B table or function.
- Input
Traffic = 50 Erlangs. - Input
GoS = 0.01. - Result: You need 64 SIP Sessions.
[!IMPORTANT]
Architectural Reasoning: Notice that you need 64 sessions to handle 50 Erlangs of traffic. Why? Because call arrivals are random (Poisson distribution). If you only had 50 sessions, you would block nearly 15% of your calls during the random “Spikes” that occur within the hour.
“The Trap”: The “IVR Soak Time” Blind Spot
The Scenario: You have calculated your trunks based on your agent talk time. You have 100 agents, and you’ve provisioned 120 SIP sessions.
The Catastrophe: You launch a new, sophisticated AI Bot that handles the first 3 minutes of every call. Suddenly, your “All Trunks Busy” errors skyrocket, even though your agents are sitting idle.
The root cause: IVR Soak Time. A SIP session is occupied from the millisecond the carrier sends the INVITE until the final BYE is sent. This includes the time the caller is talking to the bot, waiting in the queue, and talking to the agent. If you only count “Agent Talk Time” in your Erlang model, you are ignoring the 3-5 minutes the caller is “Soaking” in your IVR, effectively cutting your trunk capacity in half.
The Principal Architect’s Solution: The “Total Session Duration” Model
Always use Total Interaction Duration (from “Alerting” to “Disconnected”) in your Erlang calculations, not just “Talk Time.” This ensures the “Doorway” is wide enough to hold everyone currently in the building, regardless of whether they are talking to a human or a bot.
Advanced: Multi-Site Trunk Pooling
If you have 5 sites each needing 50 trunks, you could buy 250 trunks. But a Principal Architect uses Global SIP Pooling.
Implementation Detail:
- Configure a Global Trunk Group in Genesys Cloud.
- Instead of Site A having a hard limit of 50, all sites draw from a shared pool of 200.
- The Result: Because it is statistically unlikely that all 5 sites will hit their “Busy Hour” at the exact same second, you can safely “Over-Subscribe” the pool, saving 20-30% in monthly carrier session costs.
Validation, Edge Cases & Troubleshooting
Edge Case 1: The “Marketing Spike” (Flash Sale)
The failure condition: Your Erlang B model is based on 600 calls/hour. A marketing email goes out, and 3,000 people call in 10 minutes.
The solution: Implement Network Call Redirection (NCR) or Takeback and Transfer (TNT) at the carrier level. If the Genesys platform returns a “User Busy” (all trunks full), the carrier should automatically play a “High Volume” message before the call consumes a SIP session.
Edge Case 2: “All-Trunks-Busy” (ATB) Monitoring
The failure condition: You suspect you are blocking calls, but your reports are empty.
The root cause: Carriers often don’t pass “Busy” signals back to your analytics engine; they just drop the call.
The solution: Monitor the SBC Logs for 603 Decline or 486 Busy Here responses. If you see these codes increasing, your SIP session limit has been reached, and it’s time to increase your Erlang B target.
Reporting & ROI Analysis
Trunk capacity is a balance of Cost vs. Service Level.
Metrics to Monitor:
- Peak Concurrent Sessions: The maximum number of simultaneous calls yesterday.
- Trunk Utilization Percentage: (Peak Sessions / Total Licensed Sessions). (Goal: 70-80%).
- Carrier Reject Rate: Number of calls rejected by the carrier due to session limits.
Target ROI: By using Erlang B models, you prevent unseen revenue loss from blocked calls while ensuring you aren’t paying for “Shelf-ware” licenses that sit idle 99% of the time.