How We Provisioned SIP Trunks
for a 5,000-Employee Enterprise
A detailed inside look at how NetViaVoice planned, configured, secured, and deployed SIP trunking across 12 global sites for a large enterprise — from first call audit to live production, with measurable outcomes.
In early 2026, NetViaVoice was engaged by a global professional services firm with 5,000 employees across 12 sites in North America, Europe, and the Asia-Pacific region. The company was running legacy ISDN PRI circuits at all major sites, facing imminent PSTN switch-off deadlines in the UK and Germany, and paying approximately $480,000 per year in line rental and call charges. This case study documents the complete SIP trunk migration project: the pre-deployment audit that revealed serious over-provisioning on legacy lines, the capacity modelling that calculated optimal channel counts per site, the multi-site architecture decisions, the security framework that replaced exposed PRI infrastructure, the QoS implementation across the enterprise WAN, the phased go-live that kept zero calls down during migration, and the final measured outcomes — a 54% reduction in total telephony costs with improved call quality across all sites.
📑 Table of Contents
- The Challenge: Why This Enterprise Needed to Migrate
- Phase 1 — The Communication Audit (Week 1)
- Phase 2 — Architecture Design & Site Classification (Week 2)
- Phase 3 — Capacity Planning: 850 Channels Across 12 Sites
- Phase 4 — Security Framework for Enterprise SIP
- Phase 5 — QoS & Network Readiness (Week 3–4)
- Phase 6 — Phased Go-Live Without Downtime (Week 4–6)
- Measured Outcomes: Before vs After
- Key Lessons From a 5,000-Seat Enterprise Deployment
- Frequently Asked Questions
- Related Articles
1. The Challenge: Why This Enterprise Needed to Migrate
When the client's IT Director first contacted NetViaVoice, the immediate trigger was regulatory: BT in the UK had confirmed ISDN switch-off dates, and Deutsche Telekom had announced the end of ISDN services in Germany. Both the London and Frankfurt offices — together accounting for 1,400 employees and over 180 PRI channels — faced hard deadlines to migrate away from legacy circuits within 18 months. However, as our discovery process revealed, the PSTN switch-off was only the most urgent reason to modernise. The full scope of the challenge was significantly larger.
The company was running 34 PRI circuits across 12 sites — every circuit a fixed cost regardless of actual usage. Our initial analysis of three months of CDR data revealed the average circuit utilisation across all sites was just 38%. The company was paying for 782 PRI channels but only ever using a peak of 297 simultaneously. At an average monthly cost of $85 per PRI channel, this represented over $40,000 per month in wasted capacity. Beyond cost, the PRI infrastructure had no redundancy — a single circuit failure at any site meant complete loss of external telephone communications until the circuit was repaired, which averaged 4–8 hours.
The third challenge was geographic expansion. The company was opening a new office in Singapore and expanding its Sydney team from 40 to 180 employees within the year. Provisioning PRI circuits for these Asia-Pacific sites would require 6–8 week lead times and expensive local carrier contracts. SIP trunking from NetViaVoice could provision new channels for these sites within hours, from a single global agreement. For context on the full enterprise provisioning process we applied, see our Complete Guide to SIP Trunk Provisioning for Enterprises.
Planning a Large-Scale SIP Trunk Migration?
NetViaVoice has delivered enterprise SIP deployments from 50 to 5,000 seats — with dedicated provisioning engineers, phased go-live support, and a single global agreement covering all your sites.
2. Phase 1 — The Communication Audit (Week 1)
Before a single SIP trunk was ordered, our provisioning team spent the first week conducting a thorough communication audit. This is the step that most enterprise migrations skip — and the primary reason they encounter capacity and routing problems after go-live. Our audit covered four areas:
CDR Analysis — 90 Days of Call Data
We extracted three months of call detail records from all 12 sites. For each site: peak concurrent calls per hour, average call duration, inbound vs outbound call split, international destination breakdown, and after-hours call volumes. This data drove every capacity decision.
- Identified that 3 sites had zero calls after 7 PM — informing after-hours IVR configuration
- Revealed that 82% of international calls went to just 6 countries — used to pre-configure LCR routing
- Found one site (Chicago, 220 users) had peak concurrent calls of only 18 — massively over-provisioned with 2 PRI circuits (46 channels)
Network Readiness Assessment
We ran network quality tests at each site: latency to proposed SIP carrier PoPs, available bandwidth headroom after existing traffic, existing QoS policy (or lack of), firewall SIP ALG status, and WAN redundancy. Results were mixed — 4 sites had no voice QoS at all.
DID Inventory & Porting Assessment
Catalogued every DDI/DID number in use across all sites. Identified which numbers needed porting to SIP (existing numbers the company wanted to keep) and which could be replaced with new SIP DIDs. UK and US numbers had straightforward porting timelines; Australian numbers required 15-business-day lead time.
Compliance & Regulatory Review
Reviewed E911 obligations for US sites, BT ISDN switch-off deadlines for UK, local telecommunications licensing in Singapore and Australia, and call recording retention requirements (the firm had 7-year retention obligations for compliance). These requirements drove TLS/SRTP encryption and call recording storage architecture decisions.
3. Phase 2 — Architecture Design & Site Classification (Week 2)
Based on the audit findings, we classified all 12 sites into three tiers that determined their SIP trunk architecture. This tiered approach is the critical design decision in any multi-site enterprise deployment — it balances cost, resilience, and management complexity:
New York HQ
London
Frankfurt
Singapore
Sydney
Chicago
Los Angeles
Paris
Toronto
Tokyo
São Paulo
Amsterdam
4. Phase 3 — Capacity Planning: 850 Channels Across 12 Sites
Using the CDR data from the audit, we applied Erlang B traffic modelling to calculate the optimal channel count for each site at a 1% Grade of Service (GoS) — meaning a maximum 1% probability of a caller receiving a busy signal during peak hours. We then added a 20% headroom buffer for unexpected spikes and growth.
| Site | Users | Peak Concurrent Calls (Measured) | Erlang B Result | +20% Buffer | Final Channels | Previous PRI Channels |
|---|---|---|---|---|---|---|
| New York HQ | 1,800 | 198 | 225 | +45 | 280 | 345 (15 PRIs) |
| London | 820 | 96 | 108 | +22 | 130 | 161 (7 E1s) |
| Frankfurt | 580 | 68 | 76 | +14 | 90 | 115 (5 E1s) |
| Singapore | 340 | 40 | 46 | +9 | 55 | 46 (2 E1s) |
| Sydney | 280 | 32 | 37 | +8 | 45 | 46 (2 E1s) |
| Branch offices (×7) | ~1,180 | Various | Various | Various | 150 (combined) | 69 (3 T1s) |
| TOTAL | 5,000 | 434 peak | — | — | 850 | 782 (34 circuits) |
Key Insight: After rigorous capacity analysis, the enterprise actually needed more channels in some regions (Singapore's existing 2 E1s were under-provisioned) and far fewer in others (New York had 65 excess PRI channels). Total net reduction of 0 channels — but the distribution was radically optimised, and the cost per channel dropped from PRI rates to SIP rates across all 850 channels. The combination produced 54% total cost reduction.
5. Phase 4 — Security Framework for Enterprise SIP
Moving from closed PRI circuits to internet-based SIP trunks expanded the attack surface for telecommunications fraud. We implemented a comprehensive security framework before any trunk went live:
🔒 Enterprise SIP Security Framework — 6 Layers
Layer 1: Session Border Controllers (SBC) at All Tier 1 & Tier 2 Sites
Deployed enterprise-grade SBCs (AudioCodes Mediant series) at all 5 primary and regional hub sites. The SBC provides topology hiding (external parties cannot see internal PBX infrastructure), SIP normalisation (fixing header anomalies before they reach the PBX), and rate limiting (blocking SIP floods and brute-force REGISTER attacks).
Layer 2: TLS + SRTP Encryption on All Trunks
All 850 channels configured with TLS on port 5061 for SIP signalling and SRTP for RTP media. Mandatory given the firm's compliance obligations and the sensitivity of client-related calls. Certificate management centralised through the enterprise PKI infrastructure.
Layer 3: IP Allowlisting via NetViaVoice Portal
Every SIP trunk configured to accept traffic only from registered SBC IP addresses. The NetViaVoice portal was configured with an allowlist of public IP addresses for each site. Any REGISTER or INVITE from an unknown IP is dropped before reaching the PBX.
Layer 4: Concurrent Call Hard Limits + Spend Caps
Each site's trunk configured with a hard concurrent call cap matching its provisioned channel count. Provider-level spend caps set at 150% of expected monthly spend — triggering automatic suspension and instant alert to the IT Director if exceeded.
Layer 5: International Route Allowlist
Only the 6 countries that accounted for 82% of international traffic in the CDR audit were initially permitted. All other international destinations blocked by default. A formal request process established for adding destinations — approved by IT security before activation.
Layer 6: Real-Time CDR Fraud Monitoring
Automated CDR analysis running every 5 minutes — alerting on: calls to new destinations, after-hours call spikes, any single extension making 10+ consecutive calls, and spend rate anomalies. Alert escalation to IT Security and auto-suspension of the offending extension pending investigation.
6. Phase 5 — QoS & Network Readiness (Weeks 3–4)
The network readiness audit had identified 4 sites with no voice QoS. Before any trunk was activated at those sites, the network team (working alongside our provisioning engineers) implemented the following QoS framework consistently across all 12 locations:
⚙️ QoS Implementation Applied at All 12 Sites
- Dedicated Voice VLAN: All IP phones and SBCs placed on VLAN 20 (voice), completely isolated from data traffic on VLAN 10
- DSCP Marking: RTP media marked EF (DSCP 46) — highest priority queue. SIP signalling marked CS3 (DSCP 24).
- WAN Bandwidth Reservation: 30% of WAN bandwidth reserved for voice at each site (calculated from peak channels × 87 kbps G.711 + 10% overhead)
- SIP ALG Disabled: Confirmed disabled on all routers and firewalls at all 12 sites — this was the single most common configuration issue found during the readiness assessment
- Jitter Buffer: 30ms adaptive jitter buffer configured on the Cisco CUCM SIP trunk settings and Asterisk branch configs
- Monitoring: SNMP monitoring deployed on all network devices, alerting on WAN utilisation, packet loss >0.1%, and jitter >20ms
7. Phase 6 — Phased Go-Live Without Downtime (Weeks 4–6)
With infrastructure ready, the go-live was executed as a controlled phased rollout — never cutting over an entire site in a single event. The approach: run SIP trunks parallel to PRI circuits for 48 hours at each site, routing 10% of test traffic over SIP initially, increasing to 50%, then 100% before decommissioning PRI. This zero-downtime methodology was non-negotiable for the client.
| Week | Sites Go-Live | Method | Issues Encountered | Resolution Time |
|---|---|---|---|---|
| Week 4, Day 1 | New York HQ (pilot) | Parallel SIP + PRI, 10% → 100% | DID format mismatch on 3 inbound routes | 22 minutes |
| Week 4, Day 3 | Chicago, Toronto branches | WAN-routed to NY hub | SIP ALG not fully disabled on Chicago router | 45 minutes |
| Week 5, Day 1 | London | Parallel SIP + E1, 10% → 100% | None — cleanest go-live | — |
| Week 5, Day 2 | Frankfurt, Amsterdam, Paris | Parallel SIP + E1 | QoS DSCP marking not applying on Frankfurt WAN router | 2 hours |
| Week 5, Day 4 | Singapore | SIP only (new channels) | None | — |
| Week 6 | Sydney, Tokyo, São Paulo, LA | Mixed — SIP parallel then cutover | Tokyo DTMF issue (SIP carrier DTMF mode mismatch) | 35 minutes |
"The parallel cutover approach gave us complete confidence at every step. We never had a moment where we feared losing calls during the migration — we could see SIP traffic increasing and PRI traffic decreasing in real time, with our team on the line with NetViaVoice engineering throughout each cutover window."
— Global IT Infrastructure Director, Client (name withheld for confidentiality)8. Measured Outcomes: Before vs After
Six weeks after project completion, we conducted a formal measurement of all key metrics against the pre-migration baseline. The results exceeded the client's initial targets in every category:
9. Key Lessons From a 5,000-Seat Enterprise Deployment
Every large-scale deployment teaches lessons that improve the next one. Here are the most valuable insights from this project — applicable to any enterprise SIP migration regardless of size:
📚 7 Lessons That Made This Deployment Successful
- The audit always uncovers over-provisioning: Every enterprise we have assessed was running more PRI capacity than it needed. Never skip the CDR analysis — it is where the cost savings are found before the first trunk is ordered.
- Site classification saves complexity: Not every site needs dual trunks. Classifying sites into tiers (hub vs branch) right-sizes the investment and focuses redundancy where it matters most.
- Disable SIP ALG before anything else: This was the single most common configuration error across all 12 sites. Check it explicitly — routers often re-enable it after firmware updates.
- Parallel cutover is non-negotiable for enterprise: Running SIP parallel to PRI for 48 hours per site, with a phased traffic migration (10% → 50% → 100%), eliminates go-live risk entirely. The 35-minute Tokyo DTMF issue was caught and fixed before any user experienced it.
- DID format is always a gotcha: Document the exact format your carrier delivers DIDs in (E.164, 10-digit, 11-digit) before configuring a single inbound route. It caused 3 DID routing failures on the first site — we added format verification to the standard pre-live checklist after that.
- Security must be day-zero: The SBC, IP allowlisting, and spend caps were in place before the first call. Never bring a SIP trunk live without these controls — the median time from an exposed SIP trunk to first fraud attempt is under 4 hours.
- IVR rationalisation delivers surprise value: While migrating, we also redesigned 8 of the 12 sites' IVR systems (using the approach in our IVR Auto-Attendant Setup Guide). Average misrouted call rate dropped from 22% to 6% — reducing handle time and agent transfers significantly.
10. Frequently Asked Questions
For a deployment of this scale (5,000 employees, 12 sites, 850 channels), the total project duration was 6 weeks from engagement to full production cutover. The breakdown was approximately:
- Week 1: Communication audit — CDR analysis, network assessment, DID inventory, compliance review
- Week 2: Architecture design, capacity modelling, site classification, security framework design
- Weeks 3–4: Network QoS implementation, SBC deployment, trunk provisioning, number porting initiation
- Weeks 4–6: Phased site go-lives (parallel cutover), issue resolution, PRI decommissioning
For smaller enterprises (500–1,000 employees, 2–3 sites), the same process typically completes in 2–3 weeks. The bottleneck is almost always number porting timelines — if existing numbers need to be ported, plan for 5–10 business days (US) to 4 weeks (international) before those numbers are live on the new trunks. New numbers from NetViaVoice are available instantly.
For the full provisioning methodology we follow, see: Complete Guide to SIP Trunk Provisioning for Enterprises.
Yes — with proper parallel cutover methodology, a PRI-to-SIP migration can be completed with zero user-facing downtime. The key is running both systems simultaneously during the transition period, not performing a "big bang" cutover. The approach we use:
- Provision SIP trunks parallel to existing PRI circuits — both are active at the same time
- Route 10% of outbound traffic to SIP initially — monitor call quality and success rate
- Increase to 50% — verify consistency, monitor CDR for anomalies
- Increase to 100% — all new calls go via SIP; PRI is standing by as emergency fallback
- Monitor for 24–48 hours at 100% SIP — confirm stability
- Decommission PRI — cancel circuits with the legacy carrier
For inbound numbers: continue receiving calls on PRI numbers until they are fully ported to SIP (the porting process preserves the number — calls ring on the SIP trunk the moment porting completes, with no change for the caller).
Based on our enterprise deployments, the typical ROI of a PRI-to-SIP migration is extremely strong — most enterprises recover the migration project cost within 3–6 months from ongoing savings:
- Line rental savings: SIP channel costs are typically 40–60% lower than PRI circuit rental for equivalent capacity
- Right-sizing savings: CDR-based capacity planning typically reveals 20–40% over-provisioning on legacy PRI circuits — the actual channel count needed is lower than what was being rented
- International call savings: SIP + Least Cost Routing typically reduces international call costs by 30–50% compared to PRI-based international rates
- Maintenance savings: No physical circuits means no engineer callouts, no circuit repair wait times, and no hardware replacement cycles
- Scaling efficiency: Adding channels takes hours and is instantly reversible — no overordering "just in case"
For this specific 5,000-employee deployment: $261,000 annual saving / project implementation cost = payback in under 4 months. Read our full step-by-step setup guide: How to Set Up SIP Trunks in 7 Easy Steps.
International enterprise SIP call quality depends on four factors working together correctly. Here is exactly how we ensure quality across global deployments:
- Carrier PoP proximity: NetViaVoice has Points of Presence in multiple regions — we route each site's SIP traffic to the nearest PoP to minimise latency. For Asia-Pacific sites in this deployment, we used Singapore and Sydney PoPs rather than routing traffic back to US infrastructure.
- QoS end-to-end: DSCP marking at the site level ensures voice traffic is prioritised across the enterprise WAN and on the local internet connection. We implement QoS before any trunk goes live.
- Codec selection: G.711 for all sites with adequate bandwidth (the majority). G.729 only for sites with constrained WAN links. Never compromise to G.729 unnecessarily — the quality difference is noticeable on longer calls.
- SBC jitter buffering: Enterprise SBCs provide 20–50ms adaptive jitter buffers that smooth packet arrival variation before audio is decoded — essential for international calls with variable internet paths.
- Continuous monitoring: Real-time MOS score monitoring on all trunks. Automatic alerting if MOS drops below 3.8 — triggering investigation before users formally complain.
In this deployment, average MOS improved from 3.6 (PRI quality was actually degraded on some legacy circuits) to 4.2 post-migration — a measurable, user-perceptible improvement in voice clarity.
For an enterprise deployment with properly configured redundancy, a primary SIP trunk failure during business hours is a managed event — not an emergency. Here is what happens:
- Active calls in progress: Generally continue unaffected — the RTP audio stream is already established and does not depend on the SIP signalling trunk being continuously active
- New outbound calls: Within 3–5 seconds of the primary trunk failure being detected, new calls automatically route via the secondary trunk. The user experience is a brief pause before hearing a ring tone.
- Inbound calls: If the primary trunk is unreachable, NetViaVoice's carrier network detects the lapse in SIP registration and automatically activates the pre-configured DID failover — routing inbound calls to the secondary trunk or, as a final fallback, to a designated mobile number
- Alerting: The monitoring system triggers an alert to the IT team within 60 seconds of trunk failure — the team can investigate the root cause without any user-impacting action required
- Recovery: When the primary trunk recovers, traffic automatically shifts back to the primary — no manual intervention required
In the 12 months following this deployment, the client experienced two primary trunk failures (both at different sites, both due to ISP issues). In both cases, failover was automatic, and the IT team received alerts before any user reported a problem. Total user-impacting downtime: zero. For the full failover architecture guide, read: Migrating Phone Systems to Modern SIP.
🏢 Plan Your Enterprise SIP Migration With NetViaVoice
Whether you have 500 employees or 50,000, NetViaVoice brings the same structured, audit-first approach to every enterprise SIP deployment — capacity modelling, security architecture, phased go-live, and dedicated engineering support throughout. Contact us to start your communication audit today.