SIP trunking is how businesses connect a phone system to the public telephone network without physical telephone lines. Instead of copper ISDN circuits running into a building, a SIP trunk is a virtual connection that carries calls over the internet using the same protocol that powers most modern voice communications. If your company has a PBX and wants to make and receive calls, SIP trunking is almost certainly how that happens today.
This guide explains the technology from first principles: what SIP actually does, what physical infrastructure it replaces, how calls flow from the public network through a SIP trunk to a phone on someone's desk, and what network and provider decisions determine call quality. It also covers the realistic comparison between SIP trunking and hosted VoIP — two approaches that serve fundamentally different organizational situations.
Definition: A SIP trunk is a virtual telephone line that connects a PBX or cloud phone system to the Public Switched Telephone Network (PSTN) over an internet or private IP connection. SIP (Session Initiation Protocol), standardized in IETF RFC 3261, handles call setup, modification, and teardown. SIP trunking replaces physical ISDN/PRI circuits with an elastic, software-defined connection that can carry as many simultaneous calls as bandwidth and provisioned capacity allow.
What SIP Trunking Replaces
To understand what SIP trunking is, it helps to understand what came before it. Until the 2000s, businesses connected their PBX to the outside telephone network through physical circuit-switched lines:
- POTS lines (Plain Old Telephone Service) — single analog lines, one call per line. Small offices used a handful of POTS lines directly. Adding capacity meant ordering another physical line from the phone company and waiting for an engineer to install it.
- ISDN BRI (Basic Rate Interface) — digital, two bearer channels (2B+D). Marginally better than POTS: two simultaneous calls per circuit, faster setup, cleaner audio. Common in Europe for SMEs through the 1990s and 2000s. BT completed its ISDN switch-off in January 2027.
- PRI (Primary Rate Interface) — 23 bearer channels in North America (T1 PRI), 30 channels in Europe (E1 PRI). Standard for mid-sized and large businesses. Each channel is a fixed, dedicated circuit. If you had 23 channels and 24 people tried to call simultaneously, the 24th call got a busy signal. Adding capacity required a new T1 circuit — a lead time measured in weeks.
- Analog trunks — similar to POTS but provisioned for business use, sometimes carrying multiple lines over a single physical pair.
Every one of these technologies ties call capacity to physical infrastructure. Capacity is fixed the moment the line is installed. Moving an office means re-provisioning lines at the new location. Getting a number in a new city means a local carrier installs physical lines in that city. SIP trunking removes all of those constraints.
How SIP Trunking Works Technically
A SIP trunk operates on two distinct layers: signaling and media. Understanding the separation between them is key to understanding both how the technology works and what can go wrong.
SIP signaling
SIP handles the control plane — establishing, modifying, and terminating calls. The protocol is text-based, similar in structure to HTTP. When a call is initiated, the originating party sends an INVITE message to the SIP proxy or registrar at the SIP trunk provider. This INVITE contains the calling number, the called number, and an SDP (Session Description Protocol) body that proposes the media parameters: which codecs the caller supports, which IP address and port will receive audio.
The remote end responds through a series of provisional responses (100 Trying, 180 Ringing) and ultimately a 200 OK when the call is answered. The 200 OK carries the remote party's SDP answer — confirming the codec to use and the IP address and port to send audio to. The originating party acknowledges with an ACK. The call is now established. When either party ends the call, a BYE message is sent, acknowledged, and the session is torn down. This three-way handshake for setup (INVITE / 200 OK / ACK) is the core of SIP's call establishment model.
RTP: the voice media
Once SIP establishes where audio should go, the actual voice travels over RTP (Real-time Transport Protocol). RTP carries the digitized, compressed voice packets from one endpoint to the other. It is a separate stream from the SIP signaling — SIP goes to one port, RTP goes to a different port negotiated during the SDP exchange.
RTP is sensitive to network conditions in ways that SIP signaling is not. Voice quality degrades visibly when packets arrive out of order, late (jitter), or not at all (loss). The receiving endpoint uses a jitter buffer to smooth out timing variations, but this trades latency for smoothness. RTCP (RTP Control Protocol) runs alongside RTP and reports quality statistics — packet loss, jitter, round-trip time — that are used for monitoring and troubleshooting.
Codec negotiation
A codec encodes the voice signal into a digital bitstream for transmission, then decodes it at the far end. The codec chosen during the SDP negotiation determines both audio quality and bandwidth consumption:
| Codec | Bitrate | Bandwidth per call (with IP overhead) | Quality | Notes |
|---|---|---|---|---|
| G.711 | 64 kbps | ~87 kbps | Good (MOS ~4.1) | Default for PSTN calls; no transcoding needed at PSTN gateway; most CPU-efficient |
| G.729 | 8 kbps | ~26 kbps | Acceptable (MOS ~3.9) | Used where bandwidth is constrained; slight quality reduction; licensed codec |
| G.722 | 64 kbps | ~87 kbps | HD audio (MOS ~4.5) | Wideband; excellent for internal calls between IP endpoints; requires both ends to support it |
| Opus | 6–510 kbps | Variable | Excellent | Common in WebRTC and app-based calling; not natively supported by all SIP trunks |
For SIP trunking to the PSTN, G.711 is the practical default. It requires no transcoding at the gateway where calls transition from IP to the circuit-switched network, which eliminates a processing step and avoids the quality degradation that transcoding can introduce. G.729 is used when multiple simultaneous calls are running over a bandwidth-constrained connection.
The SBC: Session Border Controller
A Session Border Controller sits at the edge between the SIP trunk provider's network and your PBX. Every production SIP trunk deployment involves an SBC — either on the provider's side, the customer's side, or both. The SBC performs several critical functions:
- Security — the SBC is the only public-facing SIP endpoint. It enforces access control, blocks SIP scanning attacks and toll fraud attempts, and prevents unauthorized registration.
- NAT traversal — SIP and RTP have longstanding problems with Network Address Translation. The SBC mediates the private/public IP boundary so that audio streams connect correctly regardless of NAT configuration.
- Protocol normalization — different PBX vendors implement SIP slightly differently. The SBC normalizes SIP messages between the trunk provider's implementation and the customer's PBX so they interoperate correctly.
- Media anchoring — the SBC can anchor RTP streams through itself, which provides a consistent quality measurement point and ensures that RTCP statistics are visible for troubleshooting.
- Capacity enforcement — the SBC enforces the concurrent call limit on the trunk, preventing oversubscription.
Cloud-hosted SIP trunks often include an SBC as part of the service, which eliminates the need for on-site SBC hardware for most SME deployments. Enterprise deployments with strict security requirements typically run their own SBC on-site in addition to the provider's edge SBC.
How an inbound call flows
From the moment someone dials your number to the moment an agent's phone rings, a call traverses several handoff points:
- The caller dials your DID number from any phone. Their call travels over the PSTN to your SIP trunk provider's carrier interconnect.
- The provider's SBC receives the call, authenticates it as valid traffic for your trunk, and converts it to SIP if it arrived via PSTN signaling (SS7/ISUP).
- A SIP INVITE is sent over the IP connection to your PBX (or your SBC if you have one on-site).
- Your PBX processes the INVITE — it looks at the DID number, applies inbound routing rules, and determines which extension, ring group, IVR, or queue the call should go to.
- The PBX rings the endpoint. The endpoint sends back 180 Ringing, which propagates back to the caller as a ringback tone.
- The endpoint answers. A 200 OK with SDP travels back through the chain. RTP streams are established between the carrier's media server and the endpoint (often via the SBC).
- Conversation proceeds over RTP. When either party hangs up, a BYE message tears down the SIP session and the RTP stream stops.
Key Components of a SIP Trunking Deployment
PBX (Private Branch Exchange)
The PBX is the phone system that SIP trunking connects to the outside world. It manages internal extensions, routing rules, voicemail, IVR, and call features. PBX options fall into three categories:
- On-premise PBX — hardware or software running in your office or data center. Common examples: Cisco CUCM, Avaya IP Office, FreePBX/Asterisk, 3CX. You manage the infrastructure, patching, and capacity planning.
- Virtual PBX (hosted PBX) — PBX software running in a data center managed by a third party, but still a dedicated PBX instance for your organization. The distinction from hosted VoIP: you still manage PBX configuration, even if the hardware is someone else's.
- Cloud phone system — the PBX is fully abstracted. You configure users, routing, and features through a web interface; the underlying telephony infrastructure is entirely the provider's concern. SIP trunking, in the traditional sense, is not how these systems work internally — the provider handles PSTN connectivity. See cloud phone systems for more on this model.
DID numbers
DID (Direct Inward Dialing) numbers are the telephone numbers that callers dial to reach your business. When you provision a SIP trunk, the provider assigns DID numbers to it — local numbers, toll-free numbers, or international numbers depending on what you need. Inbound calls to those DIDs arrive at your SIP trunk and are then routed by your PBX to the right destination.
One of the most significant advantages of SIP trunking over ISDN/PRI is geographic flexibility with DIDs. You can provision a local number with a San Francisco area code without having any physical presence or equipment in San Francisco. The number points to your SIP trunk, and calls arrive at your PBX wherever it runs. This matters for businesses that want local presence in multiple cities, for remote-first organizations, and for disaster recovery scenarios where calls need to quickly reroute to a different location.
SIP Trunking vs. Hosted VoIP
This distinction matters because the two models have different cost structures, different management requirements, and different use cases. Conflating them leads to buying the wrong thing.
SIP trunking assumes you have a PBX. The trunk is connectivity — the pipe from your phone system to the PSTN. You are responsible for the PBX: configuring it, maintaining it, upgrading it, and ensuring its availability. SIP trunking gives you low-cost, flexible PSTN access while preserving control over your phone system infrastructure.
Hosted VoIP (cloud phone system) gives you a complete, managed phone system. There is no PBX to manage. The provider operates the entire stack — extensions, routing, features, PSTN connectivity, and the underlying hardware. You pay a per-user monthly fee and configure everything through a web interface. If a server fails, the provider handles it. If capacity needs to scale, the provider handles it.
The decision between them usually comes down to existing infrastructure. If your organization has invested in on-premise PBX infrastructure that is working well, SIP trunking is how you modernize PSTN connectivity without replacing the PBX. If you are starting fresh, moving offices, or the existing PBX is end-of-life, a cloud phone system eliminates the entire management burden and usually delivers a lower total cost of ownership at SME scale.
For a detailed look at how cloud phone systems work, see cloud phone system: how it works and why businesses are switching. For the broader category comparison, see VoIP vs UCaaS.
SIP Trunking vs. PRI vs. Hosted VoIP
| Dimension | PRI | SIP Trunking | Hosted VoIP |
|---|---|---|---|
| Connectivity | Physical T1/E1 circuit to premise | IP over internet or MPLS | Managed by provider; user only needs internet |
| Channel capacity | 23 (T1) or 30 (E1) fixed channels per circuit | Elastic — add channels on demand, no physical constraint | Elastic; managed by provider |
| Cost structure | High fixed monthly; per-minute long distance | Lower fixed; per-channel or metered usage pricing | Per-user monthly subscription; calling often included |
| Number portability | Possible but tied to geographic area | Port existing numbers; acquire DIDs in any market | Port existing numbers; provider manages number inventory |
| PBX required | Yes | Yes (on-premise or virtual) | No — PBX is part of the service |
| Geographic flexibility | Numbers tied to physical circuit location | DIDs in any country with no on-site infrastructure | Same as SIP trunking |
| Disaster recovery | Circuit failure at premise = no inbound calls | Failover via routing rules to alternate destination | Geo-redundant by default in most cloud platforms |
| Management burden | High — PBX, circuit, and hardware to maintain | Medium — PBX still managed internally; trunk is managed | Low — provider manages the stack; user manages settings |
Concurrent Channels: How SIP Trunk Capacity Works
A SIP trunk's capacity is measured in concurrent channels — the number of calls that can be active at the same time. This is conceptually equivalent to the number of bearer channels in a PRI circuit, but without physical constraints. You can start with five concurrent channels and expand to 50 without ordering new hardware or waiting for an engineer.
Most SIP trunk providers offer two capacity models: committed channels (you pay for a fixed number of channels regardless of usage) and elastic/burstable capacity (you pay per channel per minute, and the system handles any volume of simultaneous calls up to a provider-side cap). Businesses with predictable call volume and sufficient average concurrent call count to justify it use committed channels for cost predictability. Businesses with spiky or unpredictable volume use metered or elastic models.
Calculating the channels you need requires a few inputs: peak hour call volume, average call duration, and an acceptable blocking probability. Erlang B is the standard traffic engineering formula for this calculation. A business handling 200 calls per hour at an average of 3 minutes per call, targeting a 1% blocking probability, needs approximately 12 concurrent channels. Erlang B calculators are freely available online; most SIP trunk providers also provide sizing guidance.
Network Requirements for SIP Trunking
Voice over IP is unforgiving of poor network conditions. A web page loads slowly if bandwidth is constrained. A voice call becomes incomprehensible. The network requirements for SIP trunking are not aspirational — they are the floor for acceptable call quality.
Bandwidth
G.711 requires approximately 87 kbps per simultaneous call (64 kbps encoded audio plus RTP/UDP/IP headers). Ten concurrent calls need roughly 870 kbps of committed bandwidth in each direction. Add 20–30% headroom for signaling traffic, RTCP, and bursts. A business planning for 20 concurrent calls should have at least 2 Mbps of dedicated voice bandwidth — more if that connection also carries general internet traffic without traffic shaping.
Quality of Service (QoS)
QoS prioritizes voice packets over other network traffic. Without it, a large file download or video stream can cause voice packets to queue behind data packets, introducing latency spikes that manifest as choppy audio or echo. QoS is typically implemented at the router level using DSCP (Differentiated Services Code Point) marking. Voice RTP packets are marked EF (Expedited Forwarding, DSCP 46) and given highest queue priority. SIP signaling is typically marked CS3 or AF31.
If your network does not implement QoS, using a separate internet circuit exclusively for voice is a practical alternative. Many businesses with more than 10–15 concurrent calls use a dedicated connection for voice and a separate connection for data.
Jitter and latency targets
One-way latency should be under 150ms for natural conversation; above 250ms callers start talking over each other. Jitter (variation in packet arrival timing) should be under 30ms; above 50ms, the jitter buffer starts introducing noticeable delay or dropping packets. Packet loss above 1% causes audible artifacts. These are ITU-T G.114 targets and represent the standard the industry engineers to.
SIP ALG: usually disable it
SIP ALG (Application Layer Gateway) is a feature on many consumer and SME routers that attempts to modify SIP packets to handle NAT traversal. In practice, it more often corrupts SIP messages than helps them, causing registration failures, one-way audio, and dropped calls. The standard recommendation from SIP trunk providers and PBX vendors is to disable SIP ALG on the router and let the SBC handle NAT traversal instead. Check your router's configuration — it is often enabled by default.
VLAN segmentation
Separating voice and data traffic onto different VLANs is standard practice in any deployment above minimal scale. A voice VLAN isolates voice traffic from data traffic at the network layer, which simplifies QoS configuration and provides a natural boundary for security policy. Most managed switches support VLAN tagging natively; IP phones and softphones can be configured to tag their traffic to the voice VLAN automatically.
Business Use Cases for SIP Trunking
Replacing end-of-life ISDN/PRI
ISDN switch-offs across Europe, North America, and Australia have made this the largest driver of SIP trunking adoption. Organizations with existing PBX infrastructure that works well have no reason to replace it — SIP trunking replaces only the physical lines, converting the PSTN connection from circuit-switched to IP while leaving the PBX unchanged. The PBX sees SIP channels instead of PRI channels; the only required change is adding a SIP trunk license or SIP gateway hardware if the PBX does not natively support SIP.
International presence without local offices
A company wanting to appear local in Germany, Australia, and Brazil can provision local DID numbers in each country through a single SIP trunk provider with international number coverage. Calls to those numbers arrive at the company's PBX, wherever it runs. There is no local office, no local infrastructure, and no local carrier contract in each country. For businesses expanding internationally, this changes the economics of establishing local phone presence from a significant fixed cost to a per-number monthly fee.
Connecting multiple sites
An organization with offices in five cities can run each office's calls over a single SIP trunk infrastructure rather than negotiating separate carrier contracts for each location. Internal calls between sites travel over IP at no incremental cost. Inbound DID numbers in each city are provisioned through the same provider. This simplifies both billing and administration significantly compared to managing separate ISDN circuits at each location.
Disaster recovery and business continuity
A SIP trunk is software-defined. If the primary office location becomes unavailable — power failure, building access, network outage — inbound calls can be re-routed to a backup destination, a mobile number, a different office, or a cloud-based failover system within minutes by changing a routing rule. This is not possible with a physical PRI circuit: when the circuit or the building is unavailable, inbound calls fail. SIP trunking's routing flexibility is one of its most underappreciated operational advantages.
Outbound campaign calling
Predictive dialers and outbound contact centers require the ability to initiate a large number of simultaneous calls — potentially hundreds — while maintaining control over CPS (calls per second) rate. SIP trunking with elastic channel capacity handles this natively. The dialer platform connects via SIP trunk to a carrier capable of the required CPS, and the channel count scales with the campaign without requiring additional physical infrastructure.
Number Porting
Switching to SIP trunking does not require giving up existing phone numbers. Number porting — the regulatory right to transfer a telephone number from one carrier to another — applies to SIP trunk DID numbers just as it does to any other telephone number. The process varies by country and by number type (geographic, non-geographic, toll-free) but typically takes 2–4 weeks in North America and 4–8 weeks in Europe for geographic numbers.
During the porting process, the number remains active on the old carrier until the port completes. At the cutover moment, inbound calls for the ported number begin routing to the new SIP trunk. Outbound caller ID for that number becomes available immediately after the port. Most SIP trunk providers handle the porting process on the customer's behalf; your role is providing the required documentation (the Letter of Authorization from the number holder and the current carrier's account details).
How to Choose a SIP Trunk Provider
SIP trunk providers are not interchangeable. Call quality, compliance coverage, and support quality vary considerably. These are the criteria that actually matter:
| Criterion | What to evaluate |
|---|---|
| Call quality (ASR and NER) | Answer Seizure Ratio and Network Effectiveness Ratio for your key destination markets. Ask for real metrics, not marketing claims. Test with production traffic before committing volume. |
| Geographic coverage | Does the provider have DID numbers available in every country or region you need? Do they own the numbers directly or resell from a third party? Direct ownership usually means faster porting and cleaner support. |
| CPS (calls per second) capacity | Critical for outbound campaigns. What is the maximum CPS the provider supports on a single trunk? What is the burst capability? Low CPS limits create throttling problems for predictive dialer operations. |
| Failover and redundancy | Does the provider offer geo-redundant SIP proxy pairs? What is the SLA and what is the actual uptime track record? Can you configure a backup destination for trunk failure? |
| SBC included | Providers that include an SBC at their edge handle NAT traversal and protocol normalization as part of the service, reducing complexity for the customer's configuration. |
| Pricing model | Per-channel (committed) vs. metered (per-minute). Per-channel is predictable for stable call volumes. Metered suits variable or seasonal volume. Understand how burst is priced in committed models. |
| PBX compatibility | Does the provider publish tested interoperability guides for your PBX? SIP has enough implementation variance that not every trunk works perfectly with every PBX out of the box. |
| Support responsiveness | When a production trunk is down, how fast does the provider respond? 24/7 NOC availability and a direct escalation path matter more than feature lists during an outage. |
SIP Trunking and EaseDial
EaseDial includes built-in SIP trunking connectivity as part of its platform — businesses get inbound and outbound calling, local and toll-free DID numbers, international number coverage, and elastic channel capacity without negotiating a separate carrier agreement. The platform handles number porting, provisioning, and routing configuration through the same interface used for call queues, IVR, and team management.
For businesses with an existing on-premise PBX that they want to keep, EaseDial also supports SIP trunking as a standalone service — replacing a PRI circuit while leaving the PBX in place. For businesses ready to move away from PBX management entirely, the full cloud phone system handles PSTN connectivity, extensions, routing, and every communication feature in a single subscription.
EaseDial
SIP trunking, DID numbers, and cloud calling — built into one platform.