SIP Trunking Migration Without Losing a Single Inbound Call.
Retiring dozens of PRIs is not a phone purchase. It's a carrier-layer project — number porting, session border controllers, bandwidth and codec planning, QoS marking, per-location 911 registration, and a cutover sequence that keeps the lines answering the entire time.
SRS Networks plans, deploys, and cuts over SIP trunks for multi-site businesses across all 48 contiguous states — sizing the trunk from real call data, running the port as a managed project, and parallel-running the old circuit until the new one proves out.
SIP trunking is the carrier layer of a voice system — the connection that carries calls between your PBX and the public telephone network over IP instead of over copper PRI or analog trunks. It is a different job from picking handsets or a PBX platform. This layer is where concurrent call paths, session border controllers, codec and bandwidth budgets, DSCP marking, number portability, per-location 911 records, and failover routing live. Get those right and the phones simply keep working the morning after cutover.
SRS Networks is a nationwide voice and network infrastructure deployment contractor headquartered in Salinas, California, migrating multi-site enterprises off legacy PRI and analog trunks across all 48 contiguous states since 1996. We've completed 500+ deployments across 5,000+ sites, with in-house W-2 field leads, offices in Salinas, South San Francisco, Pasadena, Boston, and Dallas, and every port order and cutover window tracked live in our Project Command Center. If you also need the endpoints, PBX platform, and call routing behind the trunk, that work lives on our VoIP phone systems page. We are the nationwide enterprise deployment business — a separate company from any local Salinas managed IT services provider.
Legacy Trunks Fail Slowly, Then All at Once
Four patterns show up in nearly every multi-site PRI estate we're asked to migrate. Three of them are cost. The fourth one is the one that ends up in a lawsuit.
Paying Peak Capacity at Every Site
A PRI comes in one size: 23 B-channels. A branch that peaks at nine simultaneous calls still buys 23, and multiplied across 40 locations that's a five-figure monthly bill for channels nobody uses.
Carriers Sunsetting Copper Trunks
TDM facilities are being retired market by market. Renewal quotes climb, repair intervals stretch, and eventually the local carrier stops selling the circuit entirely — on their timeline, not yours.
Porting That Drops Inbound Calls
Main numbers ported without the CSR pulled first, a BTN moved before its DIDs, a FOC date nobody staffed. The result is the one failure a business actually notices: customers calling in and getting dead air.
911 Registered to the Wrong Address
One SIP trunk serving twelve sites will route every 911 call to whatever address is on the account. RAY BAUM'S Act requires a dispatchable location per site, and Kari's Law requires direct 911 dialing.
A Trunk Layer Built Before the Cutover, Not During It.
Most bad SIP migrations fail on things that were knowable in week one: the trunk was sized from a spreadsheet instead of call records, the WAN edge never trusted the voice markings, or nobody pulled the CSR before filing the port. We close those gaps first. Voice priority is enforced through our QoS implementation work, and multi-site transport is coordinated alongside SD-WAN and multi-site networking.
Every Phase of a SIP Trunking Migration
From call-record analysis and SBC design through porting, per-site 911 registration, and the parallel-run window that de-risks the day you release the old trunk.
Trunk Design & Capacity Planning
We pull call detail records from the existing PBX, model busy-hour traffic per site, and size a pooled concurrent-call trunk instead of replicating your PRI channel counts one for one.
SBC Deployment & Trunk Security
Ribbon, AudioCodes, or Cisco CUBE at each edge — sized to the call volume, hardened against SIP scanning and toll fraud, and configured for the interop quirks of your specific carrier.
Number Porting & LNP Management
Porting is project management, not paperwork. We pull the Customer Service Record first so the port request matches the carrier's own database, then sequence DIDs ahead of the billing number.
Cutover, E911 & Failover Routing
We run SIP in parallel with the live PRI, test inbound and outbound against every route, register 911 per location, and only then release the old trunk — site by site, on your calendar.
Codec Choice Decides the Bandwidth Budget
Per-call bandwidth is the payload plus RTP, UDP, IP, and Ethernet overhead at 20 ms packetization — in each direction. Multiply by the concurrent call paths that site will actually use, then reserve that inside a priority queue.
| Codec | Payload | Per Call, Each Way | When We Use It |
|---|---|---|---|
| G.711 µ-law | 64 kbps | ~87 kbps | Uncompressed. Default for fax pass-through and best MOS. |
| G.729a | 8 kbps | ~31 kbps | Compressed. Useful on constrained branch circuits. |
| Opus (wideband) | Variable | ~40-90 kbps | Adaptive. Common on modern UCaaS trunks. |
Size to busy hour
A 40-store chain rarely needs 40 × 23 channels. Pooled trunks sized to the aggregate busy hour typically land far below the sum of the PRIs they replace.
Reserve, don't hope
Voice gets an LLQ priority queue on the WAN edge, sized to the trunk and generally kept under a third of the circuit so data traffic still has room to move.
Confirm the carrier honors it
DSCP marks that leave your router mean nothing if the ISP re-marks them to best effort. We confirm the marking contract on every circuit before cutover.
Circuit capacity, contention, and marking policy get validated during bandwidth management planning, and when a site needs a new or upgraded circuit for the trunk, we handle the ordering and install-date chase through internet provider coordination.
Built for Estates Measured in Dozens of Sites
Single-site SIP is a one-afternoon job. The work SRS Networks is built for is the multi-site estate where every location has its own carrier, its own numbers, and its own hours you cannot interrupt.
Multi-Site Retail & Restaurant
Dozens or hundreds of stores each running a single legacy PRI or a handful of analog lines. We consolidate to a pooled trunk, keep every store number, and cut over by region without closing a location.
Healthcare & Clinic Networks
Clinic groups where inbound access is patient safety. Per-suite dispatchable 911 addressing, call-path redundancy, and cutovers scheduled around clinical hours rather than a carrier's convenience.
Property & Facility Portfolios
Office and multi-tenant portfolios carrying legacy copper for leasing offices, elevators, and life-safety panels. We migrate the voice trunks and address the analog stragglers that cannot ride SIP.
Manufacturing & Distribution
Plants and DCs where the phone system shares a WAN circuit with production traffic. Trunk sizing, QoS marking, and segmentation so a shift-change data burst never turns into choppy inbound calls.
One Team Holding the Trunk, the Circuit, and the Cutover.
Most SIP migrations stall in the gaps between vendors: the carrier blames the SBC, the SBC vendor blames the firewall, and the port date slips a month. We own the whole path — trunk design, edge hardware, circuit coordination, port orders, and the field techs standing in the room the morning of cutover.
How a multi-site SIP trunking cutover runs
It starts with data, not a quote. We pull call detail records off the existing PBX and look at the busy hour per site, because the number you are actually buying is concurrent call paths — and it is almost never the sum of your PRI channels. At the same time we inventory every number in the estate: main lines, DID ranges, toll-free, the fax line in the back office, and the analog circuits feeding elevators and fire panels. Then we pull the Customer Service Record from each losing carrier, because the port request has to match their database character for character or it rejects.
Design comes next. We pick the codec and calculate the per-site bandwidth budget, spec the session border controller at each edge, and write the SIP interop profile against your specific carrier — transport, registration or static IP authentication, RTP port range, digit manipulation, and the header rewrites that particular provider expects. Security is part of the design, not a follow-up: TLS on signaling, SRTP on media, access lists that only accept traffic from the carrier's signaling IPs, and SIP ALG turned off on every firewall in the path, because that feature is the single most common cause of one-way audio we see. QoS gets built at the same time — EF on RTP, CS3 on signaling, a priority queue at the WAN edge, and a written confirmation that the circuit provider honors the marks.
Then we file the ports and stage the cutover. LSRs go in with the DID ranges sequenced ahead of the billing number so nothing gets orphaned, and we track every FOC date site by site. Before any port activates we register the dispatchable location for each site with the carrier and place live test calls to confirm the PSAP sees the right street address, floor, and suite. On the night of cutover the SIP trunk runs in parallel with the live PRI: we test inbound to every published number, outbound to long distance and toll-free, 911, and any alarm or fax path, and only when all of it passes do we release the legacy circuit and file the disconnect.
What you get at the end is a documented trunk, not just a working one: the port confirmations, the E911 registration records, the SBC configuration, the QoS policy, the failover routing, and a per-site test log. Every port order and cutover window is visible to your team in the Project Command Center, and where a site's WAN needs work first, we sequence it with our multi-site network deployment crews so the circuit is ready before the trunk lands on it.
Explore More from SRS Networks
SIP Trunking FAQs
The questions IT directors and telecom managers ask us most before signing a SIP trunking migration SOW.
Ready to Retire the PRIs Without Losing a Call?
Send us a site list and a recent carrier invoice. We'll model the concurrent call paths you actually need, map the numbers, and come back with a migration plan and a cutover calendar for every location.
