SIP Trunking Removes Gateways, Not Outage Risk

SIP trunking remains a practical way to connect a business phone system to public telephone networks without maintaining a conventional carrier trunk at every site. It can preserve a compatible PBX, reduce gateway hardware and make call capacity easier to change, but it does not make voice service independent of local power, broadband or network configuration.

The cost argument still holds, yet resilience deserves more attention as legacy telephone networks retire. In the UK, for example, Ofcom’s current migration guidance says BT plans to retire its PSTN by January 2027 and warns that digital calling needs battery backup during a power cut. That deadline is not a worldwide timetable, but it illustrates why businesses should evaluate SIP as an operational change rather than merely a cheaper calling plan.

What a SIP trunk actually replaces

A SIP trunk is an IP connection between an organization’s telephone environment and an internet telephony service provider. It commonly replaces a PRI, BRI or other carrier-facing circuit, while the business may continue using its existing IP-PBX, desk phones, extensions and call-routing logic if those components are compatible.

SIP itself is not the complete phone service and does not carry every part of a call by definition. The RFC 3261 specification defines it as an application-layer signaling protocol that creates, modifies and terminates sessions; media is negotiated and can travel through a different path. This distinction matters when diagnosing quality problems: successful registration and call setup do not prove that two-way audio will pass through the firewall correctly.

SIP trunking also is not synonymous with a fully hosted phone system. With a hosted service, much of the PBX functionality runs in the provider’s environment. A trunk instead connects a customer-controlled or customer-selected phone platform to a carrier. A business that wants to retain its PBX therefore faces a different project from one replacing the PBX with a cloud calling application.

Where the business case is strongest

The clearest benefit is consolidation. A company can route external calls from multiple extensions through shared IP capacity rather than maintain a separate physical carrier interface for every office. Adding call paths may become a service configuration change instead of an installation of new line cards or circuits, although the provider’s contract and the PBX’s licensed capacity still set limits.

Microsoft’s SIP trunking documentation explains that a direct ITSP connection can eliminate PSTN gateways and associated administration, while actual savings depend on the provider’s service model. It also distinguishes centralized trunks from distributed deployments: centralization is simpler, but local trunks or additional termination sites may be necessary when a branch must retain calling during a WAN failure.

That trade-off prevents a universal savings estimate. A low trunk price can be offset by session border controllers, PBX licenses, number-porting work, managed routers, backup connectivity or professional configuration. Conversely, an organization that already has a compatible IP-PBX and managed network may avoid replacing working endpoints and internal call flows.

Scalability should be assessed in concurrent calls, not simply employee count. Many users may share a modest number of external call paths, while a contact center, booking desk or seasonal campaign may create concentrated peaks. The useful comparison is the required simultaneous-call capacity, including headroom for transfers and outbound bursts, against the provider’s channel, session or usage model.

The hidden dependency is the network

A conventional corded analogue line could receive power from the telephone network. An IP phone system normally depends on several local components: internet access, the router or firewall, switches, the PBX or call-control service and power for endpoints. Moving the carrier connection to SIP therefore changes where continuity must be engineered.

A credible resilience design identifies what happens when each dependency fails. Alternate call routing at the carrier can send calls to mobiles or another site, but it may not help if the failed component prevents the business from placing outbound calls. A second internet circuit provides limited protection if it shares the same physical route, building entry point or upstream carrier as the primary connection.

Businesses should define which functions must survive rather than request “redundancy” without a measurable outcome. Reception may need inbound calls redirected within minutes; a support desk may require both inbound and outbound service; a regulated operation may need recorded calls and location-aware emergency dialing to remain available. Those requirements lead to different architectures and costs.

Call quality is another network responsibility. Voice competes with uploads, backups and video traffic, so available bandwidth alone is not enough; latency, jitter, packet loss and congestion handling affect intelligibility. A pilot should reproduce normal network load and test calls in both directions, transfers, hold, voicemail, caller identification and recovery after an internet or PBX interruption.

Emergency calling and legacy devices need separate checks

Emergency calling must be evaluated for every country and working arrangement in scope. Ask whether the service supports the required emergency number, what location is presented to responders, how that location is updated for remote or relocated users, and whether users can dial directly without a prefix. Do not assume that a familiar desk phone preserves the behavior of the line it replaced.

Equipment attached to an analogue telephone port also needs an explicit compatibility decision. Fax machines, entry systems, lift phones, payment terminals and alarm equipment may rely on tones, timing or line power that an adapter does not reproduce reliably. The correct test is confirmation from the device vendor and the communications provider, followed by an end-to-end functional test—not merely hearing a dial tone.

Security belongs in the purchase specification as well. The buyer should establish how signaling and media are protected, which public addresses may reach the service, how administrators authenticate, who monitors unusual calling patterns and who carries liability for fraudulent traffic. A session border controller can enforce policy at the boundary, but it is not a substitute for secure credentials, restricted management access and prompt patching.

A purchasing checklist that exposes the real price

Before requesting quotes, document the current PBX model and software version, telephone numbers, extensions, peak concurrent calls, office locations, remote users and every non-voice device connected to a line. This inventory lets a provider confirm interoperability instead of treating compatibility as an assumption discovered during cutover.

Ask whether pricing is per channel, per user, per minute, per number or a combination, and identify minimum commitments and burst charges.
Confirm number-porting scope, expected interruption handling, temporary routing and responsibility for rejected or delayed ports.
Specify inbound and outbound failover behavior, recovery targets and whether backup routes are tested automatically or only during an incident.
Verify emergency-calling coverage and location management for offices, home workers and users who move devices.
List supported codecs, encryption options, PBX versions, session border controllers and firewall requirements.
Define support hours, escalation paths, service-level measurements and access to call-detail and diagnostic records.

A phased cutover is preferable when the existing carrier permits it. Porting a limited number range or testing temporary numbers can reveal one-way audio, incorrect caller identification and routing errors before the main number moves. The rollback plan should state which routes can be restored, who can authorize the change and how staff will communicate if both old and new calling paths are disrupted.

When SIP trunking is—and is not—the right fit

SIP trunking is particularly attractive when a business has a serviceable IP-PBX, wants to keep established call workflows and needs more flexible external capacity. It can also suit a multi-site organization prepared to manage centralized routing and design appropriate branch survivability.

It is less compelling when the PBX is near retirement, internal expertise is limited or the organization wants the provider to operate extensions, applications and endpoints as one managed service. In that situation, comparing a hosted phone platform with the full cost of retaining and securing the PBX is more meaningful than comparing subscription prices alone.

The decisive question is therefore not whether SIP is newer than a traditional line. It is whether retaining the existing phone system produces enough operational value to justify responsibility for compatibility, security and continuity. SIP trunking can remove physical gateways and rigid carrier circuits; it cannot remove the need to engineer a dependable path for every important call.

SIP Trunking Can Remove Gateways—but Not Your Outage Risk