VoIP Capacity Planning: SIP Trunks with Erlang Math
VoIP capacity planning combines Erlang B for SIP channel sizing with bandwidth math for codec selection. Get both right before you cut over from PRI to SIP.
> **Quick Answer:** VoIP capacity planning has two parts: use Erlang B to size the number of SIP channels (same math as PRI trunks), then multiply by your codec's bandwidth per call to size the WAN link. G.711 needs ~85 Kbps per call; G.729 needs ~26 Kbps.

Moving from PRI lines to SIP trunks doesn't change the traffic engineering math — Erlang B still determines how many channels you need. What changes is that you now have to also plan the WAN bandwidth to carry those calls, and you have codec choices that affect both quality and bandwidth.
This guide covers both parts of the VoIP capacity equation.
Part 1: Sizing SIP Channels with Erlang B
SIP trunks are virtual circuits. Unlike a T1 that physically has 24 channels, a SIP trunk can theoretically carry unlimited simultaneous calls — but your provider licences a channel limit, and your internet connection has finite bandwidth. Both create effective blocking.
The process mirrors PRI trunk sizing exactly:
1. Find your busy-hour call volume
2. Calculate traffic intensity: A = (calls/hour × avg duration in seconds) / 3600
3. Apply Erlang B at your target Grade of Service (P.02 for most businesses)
4. That result is your minimum licensed SIP channel count
**Example:**
- Busy hour: 300 calls
- Average duration: 240 seconds
- Traffic intensity: (300 × 240) / 3600 = **20 Erlangs**
- At P.02: **27 SIP channels**
Order 27 channels from your SIP provider. Use our [Erlang B calculator](/erlang-calculator) to run your own numbers.
Part 2: Bandwidth Sizing by Codec
Each active call consumes bandwidth. The amount depends on your codec. Codec bandwidth includes the audio payload plus IP headers (RTP, UDP, IP) and, in most enterprise deployments, SRTP encryption overhead.
Common Codecs and Their Bandwidth
| Codec | Audio Quality | Payload kbps | Total with headers |
|-------|--------------|-------------|-------------------|
| G.711 (μ-law/a-law) | High (toll quality) | 64 Kbps | ~85 Kbps per call |
| G.729 | Good | 8 Kbps | ~26 Kbps per call |
| G.722 | HD Voice (wideband) | 64 Kbps | ~85 Kbps per call |
| Opus (WebRTC) | Excellent (variable) | 6–510 Kbps | 16–100+ Kbps per call |
**G.711** is the standard for PSTN-interconnect calls and internal calls where bandwidth is plentiful. It's uncompressed PCM audio — the same quality as a traditional landline. Most SIP trunks to the PSTN use G.711 because it requires no transcoding at the carrier.
**G.729** compresses the audio with minimal perceptible quality loss. It requires a DSP or software transcoding license. If you're running many simultaneous calls over a bandwidth-constrained WAN link (MPLS with limited headroom, a branch office connection), G.729 can be a good choice — it uses one-third the bandwidth of G.711.
**G.722** provides wideband audio (HD Voice) between endpoints that support it. Same bandwidth as G.711, but the audio frequency range is doubled (8 kHz instead of 4 kHz), resulting in noticeably clearer speech. Use it for internal UC calls where both endpoints support wideband.
Calculating Required WAN Bandwidth
**Formula:** Required bandwidth = Simultaneous calls × Bandwidth per call
The key is using the right "simultaneous calls" number. Use your peak concurrent calls, not your Erlang count.
With 20 Erlangs of traffic and 27 SIP channels, your peak concurrent calls could reach up to 27 (when all channels are in use). Size bandwidth for worst-case concurrency, not average.
**Example with G.711:**
- 27 simultaneous calls × 85 Kbps = **2,295 Kbps ≈ 2.3 Mbps** for voice
**Example with G.729:**
- 27 simultaneous calls × 26 Kbps = **702 Kbps ≈ 0.7 Mbps** for voice
This is your voice traffic bandwidth requirement. Your WAN link must have this capacity available above and beyond your data traffic.
QoS: Why Voice Needs Priority
Raw bandwidth isn't enough. VoIP is extremely sensitive to three network conditions:
**Latency:** One-way delay should be under 150ms for good quality (ITU-T G.114 recommendation). Over 250ms, callers start talking over each other.
**Jitter:** Variation in packet arrival time. VoIP endpoints use jitter buffers to smooth this out, but excessive jitter (over 30–50ms) causes audio artifacts. Buffer too much for jitter and you increase latency.
**Packet loss:** Even 1% packet loss is audible in G.711. G.729 and Opus handle packet loss better through their error concealment algorithms, but loss above 3–5% degrades any codec to unintelligible.
**The solution: QoS (Quality of Service)**
Mark voice traffic with DSCP EF (Expedited Forwarding, DSCP 46) and configure your WAN router to prioritize it. In a properly configured QoS policy, voice traffic gets guaranteed bandwidth and low-latency queuing even when data traffic is congesting the link.
Without QoS, a large file download or backup can fill your WAN pipe and cause voice calls to drop or degrade — even if you have technically enough total bandwidth.
Failover and Redundancy Planning
SIP trunks bring flexibility but introduce dependencies that PRI lines didn't have: your internet connection. If your ISP goes down, your SIP trunks go down with it.
Common redundancy approaches:
**Dual SIP providers:** Register with two SIP trunk providers simultaneously. Your PBX registers to both and can route outbound calls through either. Most providers support this.
**SIP + PSTN failover:** Keep one or two POTS lines (or a small BRI/PRI) as backup for outbound calling during SIP outages. Size the backup lines for critical traffic only, not full business volume.
**Hosted SBC (Session Border Controller):** A cloud-based SBC with geographical redundancy can survive single-datacenter failures that a premises-based SBC would not.
**Geographic redundancy:** For multi-site deployments, each site should have its own SIP trunk connection to a local PSTN interconnect point. Cross-site routing should be secondary, not primary.
The PRI-to-SIP Migration Checklist
Before cutting over from PRI to SIP trunks:
- [ ] Calculate required SIP channels using Erlang B at your busy-hour traffic
- [ ] Verify WAN bandwidth headroom for your codec choice
- [ ] Configure and test QoS on all WAN equipment
- [ ] Establish failover routing for SIP outage scenarios
- [ ] Test fax over SIP (T.38 protocol) if you have analog fax machines
- [ ] Verify DTMF tone handling (RFC 2833 vs. SIP INFO vs. in-band)
- [ ] Test emergency services routing (E911 location information must be registered with your SIP provider)
- [ ] Run parallel operation for at least one business week before full cutover
Our [PBX trunk sizing guide](/blog/pbx-trunk-sizing-guide) covers the full provisioning process end-to-end.