SIP Trunking: Architecture, Security & SBC Guide for Service Providers

SIP trunking has replaced PRI as the standard method for connecting voice infrastructure to the Public Switched Telephone Network. For service providers (ISPs building SIP trunk platforms, MSPs reselling voice services, UCaaS vendors integrating telephony into their platforms), the technology decisions go far beyond choosing a trunk provider. Architecture, interoperability across carrier implementations, security at the network edge, and integration with collaboration platforms like Microsoft Teams and Zoom Phone all determine whether a SIP trunking deployment scales reliably or becomes an operational burden.

This guide is written for the teams that build and operate SIP trunk infrastructure, not for businesses shopping for a SIP trunk provider. It covers the architecture of a production SIP trunking deployment, the role of a Session Border Controller (SBC) at every stage of the call path, the security considerations that come with exposing SIP to the public internet, and the interoperability challenges that surface when multiple vendors, codecs, and platform certifications intersect in a single network.

What Is SIP Trunking?

SIP trunking uses the Session Initiation Protocol to deliver voice calls over an IP network instead of dedicated TDM circuits. A SIP trunk is a logical connection between two SIP endpoints, typically between a service provider’s SBC and a carrier’s SBC, or between an SBC and an IP-PBX, that carries both signaling (call setup, teardown, mid-call events) and media (the actual voice audio) over the same IP transport.

For service providers, SIP trunking is not a product you buy — it is the infrastructure you build. An ISP delivering voice services to business customers provisions and manages SIP trunks between its own network and upstream carriers, between its SBC and customer-premises PBX systems, and increasingly between its infrastructure and cloud collaboration platforms that require certified SBC interconnection.

The economic model is fundamentally different from PRI. SIP trunks are not bound to physical circuits: capacity scales by adding sessions to a software-based SBC rather than ordering new hardware installations. Routing decisions happen in software, failover between carriers is automatic, and the same SBC infrastructure can serve SIP trunks, Microsoft Teams Direct Routing, Zoom Phone BYOC, and legacy PBX interconnects simultaneously.

SIP Trunking Architecture: How It Works

A production SIP trunking deployment has four primary components: the SBC at the network edge, one or more upstream carrier connections, the customer-facing voice infrastructure (PBX systems, UCaaS platforms, or softphones), and the routing and policy engine that governs how calls flow between them.

The SBC as the Central Control Point

The Session Border Controller is the architectural anchor of every SIP trunking deployment. It sits at the border between the service provider’s trusted network and the untrusted carrier or internet-facing side, independently managing signaling and media on each leg of a call.

In a B2BUA architecture, the SBC fully terminates the incoming SIP session from the carrier and re-originates a new, independent session toward the customer PBX or platform. This complete termination and re-origination gives the SBC full authority over every SIP header on both legs, enabling SIP header manipulation, topology hiding, independent encryption negotiation, and codec renegotiation that a simple SIP proxy cannot perform.

Carrier Interconnection

A typical service provider connects to multiple upstream carriers for redundancy, cost optimization, and geographic coverage. Each carrier trunk terminates on a dedicated trunk group (NAP) on the SBC, with its own SIP transport settings, codec preferences, and header manipulation rules. The SBC’s routing engine selects the appropriate carrier based on dialed number, time of day, cost, or external routing decisions from an API.

Customer-Facing Trunks

On the customer side, the SBC terminates trunks toward IP-PBX systems (FreePBX, 3CX, Asterisk, Broadsoft), hosted UCaaS platforms, or contact center infrastructure. Each customer trunk group carries its own configuration: different codecs, different SIP header requirements, different security profiles. The SBC normalizes between the customer’s SIP dialect and the carrier’s, so neither side needs to accommodate the other.

Routing and Policy

The routing engine is where a service provider’s SIP trunking deployment becomes intelligent. Rule-based routing directs calls across carriers using least-cost routing, priority-based failover, or external decision engines queried via API. Call admission control prevents trunk oversubscription. Policy enforcement applies rate limits, blacklists, and fraud detection rules before a call ever reaches the carrier.

SIP Trunking vs. PRI: A Service Provider Comparison

The shift from PRI to SIP trunking is not optional for most service providers. PSTN decommissioning timelines are accelerating globally, and the economics of maintaining TDM infrastructure alongside IP networks no longer make sense. But the comparison is worth understanding in detail, because the migration path and the operational differences affect how you architect your SIP trunk platform.

	SIP Trunking	PRI
Capacity scaling	Add sessions in software; no circuit orders	Fixed 23/30 channels per physical circuit
Multi-carrier redundancy	Software-defined failover across carriers	Requires duplicate physical circuits
Geographic flexibility	SBC can be deployed anywhere (cloud, on-prem, hybrid)	Tied to physical circuit termination point
Platform integration	Teams Direct Routing, Zoom BYOC, Webex Calling	Requires media gateway for IP conversion
Cost model	Per-session subscription (OPEX)	Per-circuit recurring + hardware CAPEX
Encryption	TLS/SRTP natively supported	No native encryption
STIR/SHAKEN support	Identity headers in SIP signaling	Requires out-of-band implementation

PRI to SIP Migration for Service Providers

For ISPs and ILECs still operating TDM infrastructure, the migration path typically involves deploying a media gateway alongside an SBC. The media gateway converts TDM signaling and media to SIP, while the SBC handles routing, security, and carrier interconnection on the IP side. This allows a phased migration, converting circuits one trunk group at a time, without disrupting existing service.

TelcoBridges’ Tmedia gateways and ProSBC are deployed together in exactly this configuration across carrier networks globally, handling the TDM-to-SIP conversion while the SBC manages the IP-side routing, encryption, and interoperability.

The Role of a Session Border Controller in SIP Trunking

Every production SIP trunking deployment requires an SBC. This is not a recommendation — it is an architectural requirement. The SBC is the enforcement point for security, interoperability, regulatory compliance, and routing policy. Without it, every SIP endpoint on the network must individually handle encryption negotiation, header normalization, fraud detection, and failover logic, a configuration that does not scale and cannot be centrally managed.

Security Enforcement at the Network Edge

An SBC exposed to the public internet is the first line of defense against SIP-based attacks. Built-in DoS and DDoS mitigation blocks SIP flood attacks before they reach the telephony core. SIP registration scanning protection detects and stops registration enumeration attacks. Dynamic blacklisting and call access control allow real-time response to fraud events without taking the SBC offline. These are not optional features; they are operational requirements for any internet-facing SIP deployment.

SIP Normalization and Interoperability

No two SIP implementations are identical. Carrier A sends P-Asserted-Identity headers in a format that Carrier B rejects. A PBX vendor includes proprietary X-headers that a UCaaS platform strips silently, causing features to break. Session timer handling (RFC 4028) differs between endpoints, leading to calls that disconnect after a fixed interval.

The SBC’s SIP header manipulation engine resolves these incompatibilities by applying rules-based treatments per trunk group. Each carrier, PBX, or platform gets its own normalization profile, and the SBC translates between them so that the call works regardless of how each vendor chose to interpret the SIP RFCs.

Encryption Termination and Translation

SIP trunking increasingly requires encryption, but the requirements differ by leg. Microsoft Teams mandates TLS for signaling and SRTP for media. A carrier trunk may deliver unencrypted RTP over UDP. The SBC terminates encryption on each leg independently: TLS/SRTP toward Teams, plain RTP toward the carrier. The conversion happens transparently at the SBC boundary, and neither side needs to change its configuration to accommodate the other.

Routing Intelligence

The SBC’s routing engine is what turns a collection of SIP trunks into a managed voice platform. Least-cost routing selects the cheapest carrier for each destination. Priority-based failover ensures calls route to a backup carrier within milliseconds if the primary trunk fails. API-driven routing allows external systems (billing platforms, CRM databases, fraud detection engines) to influence routing decisions in real time during the signaling phase, before the call is answered.

Regulatory Compliance

STIR/SHAKEN compliance requires the SBC to sign outbound calls with a cryptographic identity token and verify tokens on inbound calls. The SBC integrates with external signing services to handle attestation (levels A, B, or C) and injects the Identity header into SIP signaling. For service providers operating in the United States, the FCC’s own-certificate rule (effective September 2025) requires that providers sign calls using their own STIR/SHAKEN certificate rather than relying on a third party’s, making the SBC’s integration with the signing infrastructure a direct regulatory requirement.

SIP Trunk Security

Exposing SIP trunks to the public internet introduces a well-documented threat surface. This section covers the security controls that an SBC enforces at the network edge. For a comprehensive treatment of VoIP security, including fraud detection architectures, toll fraud prevention, and advanced threat mitigation, see the dedicated VoIP security coverage.

Signaling and Media Encryption

TLS encrypts SIP signaling, preventing interception of call setup information (who is calling whom, from which addresses, through which routes). SRTP encrypts the voice media itself, protecting call content from eavesdropping. Together, they provide end-to-end protection for the SIP trunk, and the SBC manages both independently per trunk group so encryption requirements can differ between the carrier leg and the customer leg without either side needing to adjust.

Topology Hiding

Without topology hiding, SIP headers leak internal IP addresses to external parties. An attacker capturing SIP signaling can map the internal network, identify specific endpoints, and target them directly. The SBC replaces internal addresses in Contact, Via, and Record-Route headers with its own public address, presenting a single point of contact to the outside world while keeping the internal topology invisible.

DoS/DDoS Mitigation

SIP flood attacks, SIP registration scanning, and INVITE-based denial-of-service are daily realities for internet-facing SIP infrastructure. The SBC’s built-in rate limiting, connection throttling, and dynamic blacklisting absorb these attacks at the edge before they consume resources on the internal telephony platform.

Call Access Control and Fraud Prevention

Dynamic blacklisting of IP ranges or calling/called number patterns, including percentage-based greylisting for anomalous traffic, allows real-time response to fraud events. For service providers, per-call fraud scoring through integration with validated fraud detection partners (TransNexus, SecureLogix, YouMail) catches toll fraud and robocalling patterns before they generate billing exposure.

SIP Interoperability and Normalization

SIP interoperability is the single most persistent operational challenge in multi-vendor voice networks. The SIP RFCs define a flexible framework, and that flexibility means every vendor, carrier, and platform implements the protocol slightly differently. When two endpoints with different SIP implementations try to communicate, calls fail, features break, or sessions disconnect unexpectedly unless an SBC normalizes between them.

Common Interoperability Problems

Proprietary SIP headers are the most frequent source of interop failures. Carrier A includes custom P-headers that Carrier B rejects as malformed. A PBX vendor sends X-headers that a UCaaS platform silently strips, breaking call features that depend on them.

P-Asserted-Identity (PAI) formatting varies between vendors and is critical for caller ID presentation and STIR/SHAKEN attestation. If the originating endpoint formats PAI differently from what the terminating endpoint expects, caller ID display fails or attestation drops from A to C.

Session timer handling under RFC 4028 is implemented inconsistently. Some endpoints expect the caller to refresh the session, others expect the callee. Mismatched session timer behavior causes calls to disconnect after a fixed interval, a problem that only surfaces in production under specific call durations.

Codec negotiation failures occur when endpoints cannot agree on a common audio codec. A mobile carrier offering AMR-WB and an enterprise PBX supporting only G.711 will fail to negotiate unless the SBC transcodes between them.

How the SBC Resolves Interoperability

The SBC’s SIP header manipulation engine applies per-trunk-group rules to add, modify, or remove SIP headers on each call leg. Each carrier, PBX, and platform gets its own normalization profile within its trunk group configuration. When a call crosses between two trunk groups, the SBC translates the SIP dialect of one into the dialect the other expects, transparently, without either endpoint needing to change its configuration.

For codec interoperability, the SBC performs real-time transcoding between incompatible formats. ProSBC supports software-based transcoding for G.711 variants, handling the conversion at the SBC boundary so that each endpoint uses its preferred codec without compromise.

Microsoft Teams Direct Routing with an SBC

Microsoft Teams Direct Routing is the highest-demand SBC use case in the North American MSP market. It connects Teams Phone System to any PSTN carrier through a customer-managed SBC, bypassing Microsoft’s Calling Plans and giving the service provider full control over carrier choice, routing logic, and telephony infrastructure.

What Teams Requires from the SBC

Teams enforces strict SIP requirements that standard SIP trunks and SIP proxies cannot meet. The SBC must terminate TLS (minimum 1.2) on the signaling leg to Teams using a certificate from a Microsoft-trusted Certificate Authority. All media must be SRTP: Teams rejects unencrypted RTP. The SBC must respond to SIP OPTIONS heartbeats to maintain its “online” status in Teams Admin Center. And the SBC must normalize SIP headers between the carrier’s SIP dialect and Teams’ specific expectations, including RTCP-in-RTP multiplexing.

A B2BUA SBC handles all of this natively: it fully terminates the carrier session on one side and re-originates a Teams-compliant session on the other, managing TLS, SRTP, header normalization, and topology hiding independently on each leg.

Why MSPs and ISPs Choose Direct Routing

For service providers, Direct Routing is a platform play. A single SBC instance can serve multiple enterprise tenants with isolated routing per tenant, leveraging the provider’s own carrier contracts and negotiated rates. The provider controls the voice infrastructure (failover, fraud detection, call recording, compliance) rather than delegating it to Microsoft’s Calling Plans or Operator Connect program.

To understand the full end-to-end process of connecting Teams to the PSTN, including licensing requirements, Teams Admin Center configuration, and SBC-side setup, see the companion guide.

Zoom Phone BYOC and Webex Calling Integration

Microsoft Teams is not the only collaboration platform requiring SBC integration. Zoom Phone BYOC (Bring Your Own Carrier) and Cisco Webex Calling both support SBC-mediated PSTN connectivity, each with their own certification requirements and SIP specifics.

Zoom Phone BYOC

Zoom Phone BYOC allows service providers to connect their own carrier trunks to Zoom’s cloud telephony platform through a certified SBC. The architecture is similar to Teams Direct Routing: the SBC terminates the carrier trunk on one side and a Zoom-facing trunk on the other, handling encryption, normalization, and routing between them. For service providers already operating SIP trunk infrastructure, adding Zoom BYOC is an incremental trunk group configuration on the same SBC that serves their carrier interconnects and Teams deployments.

Webex Calling

Cisco Webex Calling supports Local Gateway deployment where a customer-managed SBC connects the Webex cloud to PSTN carriers or on-premises PBX systems. The SBC handles SIP interoperability between Webex’s SIP implementation and the carrier’s, with per-trunk encryption and normalization profiles.

Multi-Platform SBC Consolidation

The operational advantage for service providers is consolidation. A single cloud-native SBC deployment, with sufficient trunk group capacity, can terminate carrier trunks, serve Teams Direct Routing tenants, deliver Zoom Phone BYOC, and connect Webex Calling customers, all through isolated trunk groups with their own security, codec, and normalization profiles. This eliminates the need for separate SBC appliances per platform and centralizes routing, security, and monitoring in a single management plane.

PRI to SIP Migration: A Practical Guide for Service Providers

PSTN decommissioning is accelerating globally. Legacy PRI infrastructure is being retired, and service providers that still rely on TDM circuits are facing both a regulatory deadline and an economic reality: maintaining parallel TDM and IP networks is increasingly expensive.

The Migration Architecture

A PRI to SIP migration for a service provider typically involves two components working together: a media gateway that converts TDM signaling and media to SIP, and an SBC that handles the IP-side routing, security, and carrier interconnection.

The media gateway terminates the PRI circuits (T1/E1) and converts the TDM traffic to SIP. The SBC receives the SIP traffic from the gateway and routes it to upstream carriers, enterprise customers, or UCaaS platforms, applying all the security, normalization, and routing intelligence that a production SIP deployment requires.

Phased Migration Strategy

The safest approach is a trunk-by-trunk migration: convert one PRI circuit at a time, validate call quality and routing, then proceed to the next. The SBC’s routing engine can handle both legacy (gateway-sourced) and native SIP trunks simultaneously, allowing a gradual transition without service disruption.

For ILECs and rural carriers with government mandates to provide phone service, the migration path must preserve 911/E911 routing and local number portability throughout the transition. The SBC’s routing engine and the media gateway’s signaling support (SS7, ISDN PRI, CAS) ensure continuity during the cutover period.

Frequently Asked Questions

Conclusion

SIP trunking is the foundation of modern voice infrastructure for service providers. The technology itself is mature, but the architecture decisions (where the SBC sits, how normalization profiles are structured, which security controls operate at the edge, and how routing intelligence connects to external systems) determine whether a deployment scales reliably across carriers, platforms, and customers.

The SBC is the non-negotiable architectural component. It enforces security at the network edge, resolves the SIP interoperability problems that surface in every multi-vendor environment, manages encryption independently per trunk group, and provides the routing intelligence that turns a collection of SIP trunks into a managed voice platform. For service providers delivering voice to enterprise customers, supporting Teams Direct Routing and Zoom Phone BYOC, and maintaining regulatory compliance with STIR/SHAKEN, the SBC is the infrastructure that makes all of it work from a single control point.

Further Reading

To understand how SIP header manipulation works in practice, from vendor normalization to P-Asserted-Identity correction and session timer handling, read SIP Header Manipulation: What It Is and Why Your SBC Needs It.

To learn why a SIP proxy cannot replace a B2BUA SBC in production SIP trunking environments, and when each is the right architectural choice, see What Is a SIP Proxy?.