SIP Trunking Basics: How It Works and What You Need

If you run phones on a PBX today (on‑prem or virtual) and want PSTN connectivity without copper, you’re looking at SIP trunks. This field guide covers SIP trunking basics in plain English: what a trunk is, how signaling and media work, what to configure, how to size channels, and where adding a routing layer in front of your trunks gives you more control.

Key takeaways

• A SIP trunk is a virtual bundle of concurrent call paths between your PBX and the PSTN over IP, not a physical line.
• SIP handles signaling; RTP carries the audio. NAT, firewalls, and codecs determine whether callers hear each other.
• Plan capacity in channels (simultaneous calls), not users. Add headroom for busy bursts.
• Common issues (one‑way audio, DTMF failures, flapping registration) are almost always NAT, ports, DNS SRV, or mismatched settings.
• A routing layer like CallFlow in front of trunks adds numbers, IVR, queueing, dynamic routing, analytics, and spam/fraud controls without touching the PBX.

What SIP trunking is (and what it isn’t)

SIP trunking connects your SIP‑capable PBX to the public telephone network over the internet. Instead of a physical PRI circuit, you get virtual call paths (“channels”) from a SIP provider, plus telephone numbers (DIDs) that point to your PBX.

A trunk is not a phone system. It does not replace your PBX features. Think of it as the IP pipe that provides inbound numbers and outbound paths. Your PBX still handles extensions, ring groups, and internal features.

What you need in the picture:

• IP PBX or SBC that supports SIP
• SIP provider for trunks and DIDs
• Internet connection with stable latency/jitter
• Firewall/NAT that won’t mangle SIP/RTP
• Public IP (preferred) or well‑managed NAT

How SIP sets up calls; RTP carries audio

• SIP is the signaling protocol that sets up, modifies, and tears down sessions. It negotiates where and how to send media.
• RTP (with RTCP) carries the audio once the call is up. If SIP is the handshake, RTP is the conversation.
• DIDs map inbound PSTN calls to your PBX; outbound calls from your PBX traverse the trunk to the PSTN.

SIP trunk vs legacy PRI

• PRI (T1/E1) is a physical circuit with a fixed number of B‑channels (23 on a T1 in North America).
• A SIP trunk is virtual. Capacity is purchased/allowed as concurrent call channels and can scale up or down.
• SIP adds resiliency options (multiple IP edges, DNS SRV, failover targets) without truck rolls.

SIP trunking basics: How SIP calls actually flow

Signaling steps: INVITE → ringing → media

At a high level, a successful inbound call looks like this:

1. PSTN call hits your DID at the provider; provider sends a SIP INVITE to your PBX.
2. Your PBX replies with 100 Trying.
3. PBX may send 180 Ringing (remote hears ringback) or 183 Session Progress (early media—useful for pre‑answer announcements).
4. Upon answer, PBX returns 200 OK with its media details; provider ACKs.
5. RTP flows between the provider and your PBX endpoints. Mid‑call re‑INVITEs can change codecs or media endpoints (hold, transfer).

Outbound is the reverse: your PBX initiates the INVITE.

Core transport choices:

• UDP or TCP for SIP on port 5060 (typical). UDP is common; TCP is useful for larger messages and better traversal.
• Optional TLS for SIP signaling encryption on 5061 (names/credentials protected; media encryption is separate and not always supported).
• Media rides RTP/RTCP over a negotiated UDP port range.

Registration vs IP‑ACL models:

• Registration: Your PBX REGISTERs with a username/password at set intervals (e.g., 300–600s). Provider sends calls to the contact learned from registration.
• IP‑ACL (static peer): No credentials. Provider accepts from your static public IP(s) and sends inbound only to those IPs. You must control ACLs on both ends.

Early media matters:

• 183 Session Progress lets the provider send audio before answer (announcements, carrier messages).
• 180 Ringing is signaling only; ringback is locally generated by the provider or PBX.
• IVR tone collection depends on DTMF configuration. Use RFC 2833 (RTP events) for reliable results with trunks; in‑band DTMF is easily distorted by codecs.

Why codec negotiation matters:

• Both ends must agree on a codec. G.711 µ‑law (North America) is the baseline. Compressed codecs like G.729 may be offered by some providers; ensure your PBX licenses and DSPs can handle them.
• Mismatch or unsupported codec = no audio or failed setup.

Standards references:

• SIP base spec: RFC 3261 (IETF) — https://www.rfc-editor.org/rfc/rfc3261
• RTP/RTCP: RFC 3550 — https://www.rfc-editor.org/rfc/rfc3550
• DTMF via RTP events: RFC 2833 — https://www.rfc-editor.org/rfc/rfc2833

Media path, NAT, and why one‑way audio happens

SIP negotiates media addresses inside SDP (Session Description Protocol) bodies. If your PBX is behind NAT, it may advertise a private IP in SDP. If the provider tries to send RTP there, you’ll get one‑way or no audio.

Checklist to avoid media traps:

• Prefer a public IP on your PBX/SBC or enable proper NAT handling (SIP-aware SBC, correct external IP in SDP).
• Disable SIP ALG on the firewall; it often rewrites headers incorrectly.
• Open/allow the provider’s RTP port range inbound to the PBX and permit outbound to the provider.
• Honor re‑INVITE/UPDATE to adjust media if the far end changes endpoints (hold, transfer).
• Use OPTIONS keepalives or SIP session timers so stateful firewalls maintain pinholes.

SIP trunking vs VoIP vs PBX vs PRI

Use the right term for the right layer

• VoIP: Generic method of carrying voice over IP networks.
• SIP: A specific signaling protocol used for VoIP sessions (call setup/control).
• SIP trunk: A service from a provider that gives your PBX concurrent call paths and DIDs over SIP.
• PBX: Your phone system (call routing inside your org: extensions, ring groups, voicemail).
• PRI: Legacy T1/E1 circuit with fixed B‑channels over copper.

Term	What it is	Who manages it	Typical use case
VoIP	The transport of voice over IP	Everyone (generic method)	Any IP voice application (PBX, softphones, conferencing)
SIP	The call signaling protocol	Vendors/engineers	Session setup, modification, and teardown
SIP trunk	Service providing concurrent PSTN call paths + DIDs	SIP provider + your IT	Connect PBX to PSTN for inbound/outbound calling
PBX	Phone system software/appliance	Your IT/telecom team	Internal extensions, ring groups, features
PRI	Physical ISDN circuit (T1/E1)	Telco + facilities	Legacy PSTN connectivity with fixed channel count

Channels and capacity planning

How many concurrent calls do you need?

Channels are simultaneous calls, inbound or outbound. They have nothing to do with how many users you have. A 100‑seat office might only need 10–15 concurrent channels during peak; a 25‑seat sales floor might need 20+. Size to peak busy hour, not average.

Heuristics you can start with:

• General office: 1 channel per 6–8 users
• Sales floor/inside sales: 1 per 1–2 users (predictive dialers need more; check with your vendor)
• Customer support/contact center: 1 per 1–1.5 active agents, plus overflow for callbacks/IVR

Plan for burst handling:

• Add 15–30% headroom above measured/expected busy hour. Marketing campaigns, weather events, and outages elsewhere will spike volume.
• Consider time‑of‑day variation. Monday mornings and lunch hours trend high; nights/weekends may be low.
• If your provider allows it, enable bursting beyond your committed channels with safeguards so the PBX doesn’t overload.

Codec bandwidth and QoS:

• G.711 uses roughly 80–100 kbps per call leg including IP/UDP/RTP overhead. G.729 uses about a quarter of that but at lower quality.
• On your WAN/ISP, apply QoS (priority queuing) to RTP and SIP signaling. Keep jitter and packet loss low; voice is real‑time and intolerant of micro‑bursts.

What you need to set up a SIP trunk

PBX readiness, network checklist, and provider info

PBX requirements:

• SIP‑enabled with support for G.711 µ‑law (and A‑law if you handle international). Optional: G.729/Opus if the provider and your licenses allow.
• DTMF support for RFC 2833 (RTP events). Avoid in‑band DTMF with compressed codecs.
• DNS SRV support for outbound proxy records (multiple edges/failover).

Network and security:

• Preferred: Static public IP on the PBX/SBC. If behind NAT, ensure stable mapping and correct external IP in SDP.
• Disable SIP ALG on firewalls/routers.
• Permit SIP transport/port per provider (commonly UDP/TCP 5060; TLS 5061 if used).
• Permit the provider’s RTP UDP port range to/from the PBX.
• Set conservative SIP session timers and state timeouts so long calls don’t drop (e.g., honor keepalives/OPTIONS).

Typical provider parameters you’ll receive:

• SIP domain/edge(s) and whether to use DNS SRV
• Transport (UDP/TCP/TLS) and port
• Authentication model: username/password (registration) or IP‑based
• Registration interval (e.g., 300–600 seconds) and recommended retry logic
• DID list and any CNAM presentation options
• Outbound caller ID formatting rules (E.164 vs 10D)
• Provider IP ranges for ACLs and failover targets

Emergency calling:

• Plan E911 policy and routing with your voice provider and PBX configuration. Ensure correct caller ID for location granularity; test per your organization’s compliance process.

Common SIP trunking problems and fixes

Symptoms, likely causes, specific checks

Registration flaps/timeouts

• Symptoms: Calls stop working every few minutes; logs show repeated REGISTER failures.
• Likely: NAT mapping expiring, short registration TTL, blocked keepalives.
• Checks: Increase registration interval to 300–600s, enable keepalives/OPTIONS; ensure firewall allows outbound/inbound to provider IPs; disable SIP ALG.

No audio or one‑way audio

• Symptoms: Call connects but only one side hears audio, or silence both ways.
• Likely: RTP blocked by firewall, private IPs in SDP, wrong NAT handling, RTP ports closed.
• Checks: Verify PBX advertises correct public IP in SDP; open provider RTP port range; confirm re‑INVITEs aren’t blocked; capture SIP/SDP to confirm media IPs.

DTMF not recognized by IVR

• Symptoms: Callers press keys but menus don’t respond; voicemail PIN entry fails.
• Likely: In‑band DTMF with compressed codecs; provider expects RFC 2833 but PBX sends SIP INFO or in‑band.
• Checks: Set DTMF to RFC 2833 (RTP events) on trunk and endpoints; avoid in‑band through G.729; test with your IVR. For IVR design tips, see IVR for business.

Intermittent call failures

• Symptoms: Some calls complete; others fail with busy/unavailable; spikes during failover events.
• Likely: DNS SRV not honored; only one provider edge allowed through firewall; short UDP timeouts; topology hiding breaking Contact/Record‑Route.
• Checks: Enable DNS SRV; allow all provider edges; extend UDP state timeouts; confirm PBX follows 302/3xx redirects or failover targets.

SIP response codes to watch

• 486 Busy Here: Callee is busy. Real busy, or concurrency cap reached on your side.
• 603 Decline / 607 Unwanted: Rejected by user or flagged as unwanted/spam upstream.
• 403 Forbidden / 404 Not Found: Auth issue or unassigned DID.
• 480 Temporarily Unavailable: Endpoint offline, registration down, or routing window closed.
• 408 Request Timeout: Network/firewall path problem.
• 503 Service Unavailable: Upstream maintenance or failover in progress. For patterns and spam‑related signaling, see our guide on SIP response codes and spam detection.

How to capture a trace safely

• On the PBX/SBC, mirror the WAN interface or use built‑in packet capture.
• Filter on SIP/RTP ports and provider IPs to limit scope.
• Collect a full call: INVITE through BYE, plus RTP; review SDP c= and m= lines for IP/port; match timestamps to media flow.
• Redact credentials and public IPs before sharing logs outside your org.

When to add a call‑routing layer in front of trunks

Use cases where a routing platform makes life easier

If inbound control, analytics, and scale matter—and you’d rather not keep reprogramming the PBX—drop a routing layer in front of your trunks.

What this looks like with CallFlow:

• Numbers and targets
  • Purchase US toll‑free and local business numbers (plus numbers in several other countries) from a prepaid wallet—no monthly subscription.
  • Point numbers to SIP targets (your PBX, an SBC, or agents), PSTN phones, or browser/SIP softphones.
• Smart routing you won’t want to script in a PBX
  • Priority, weighted, round‑robin, and simultaneous ring to distribute calls.
  • Time‑of‑day and day‑of‑week windows per target.
  • Geographic/caller‑state routing for regionally distributed teams.
  • Daily and concurrent caps per target to protect capacity and SLAs.
• Front‑end call control
  • IVR menus, a call queue with hold music, voicemail, and whisper messages before connect.
  • Real‑time call logs and analytics; call recording; live call monitoring; scheduled email reports for stakeholders.
• Hygiene and fraud protection
  • Per‑number spam‑score monitoring; VoIP‑caller blocking; HLR/line‑type lookup; blocklists; rate limits.
• Teams and endpoints
  • Sub‑accounts/agents with extensions; SIP softphone registration and browser agents.
• Under the hood
  • Multiple redundant carriers and direct SIP trunks for resilience.

Example: A multi‑location service brand receives inbound calls nationwide. CallFlow routes by caller state to the appropriate regional PBX via SIP targets. If a region is at channel capacity or after hours, overflow goes to a queue with hold music, then to voicemail. Marketing gets scheduled email reports each morning; operations monitors live call status during peak campaigns. You keep the PBX unchanged while gaining control at the edge.

For more on routing design patterns, see call routing and how cloud call forwarding separates call control from on‑prem systems. If you’re building IVRs to front‑end those trunks, our IVR for business guide covers menu structure and DTMF choices.

Example configurations (read‑only checklist)

PBX registration model

• Trunk server: Set SIP domain/edge from provider; enable DNS SRV if given multiple records.
• Auth: Username/password; registration interval 300–600s; retry with backoff; enable OPTIONS ping.
• Transport: UDP or TCP 5060; use TLS 5061 if supported and required.
• Codecs: Prefer G.711 µ‑law; optionally enable G.729/Opus if both ends support; set ptime consistently (e.g., 20 ms).
• DTMF: RFC 2833 (RTP events); disable in‑band for compressed codecs.
• NAT: Set external/public IP in SDP; enable keepalives; disable SIP ALG on the firewall.
• Firewall: Allow provider SIP IPs/ports; open provider RTP UDP range to PBX; set adequate UDP state timeouts (>180s).
• Caller ID: Format per provider rules (E.164 +1NXXNXXXXXX vs 10‑digit).
• Failover: Honor DNS SRV priorities/weights; allow multiple provider edges; configure outbound proxy if specified.

IP‑auth model

• Static IP: Provide your public IP(s) to the provider for ACLs; keep them stable.
• Inbound ACL: Accept SIP only from provider IP ranges; drop all else.
• Outbound: Send to provider SIP edge(s) using DNS SRV if provided; no authentication.
• Headers: Set From/Contact formatting per provider; ensure P‑Asserted‑Identity or Remote‑Party‑ID if required for caller ID.
• Media: As above—RTP port range open; correct external IP in SDP; RFC 2833 for DTMF.
• Monitoring: Enable OPTIONS keepalives so the provider can mark the trunk available/unavailable.

Test plan

• Inbound DID test: Call each DID; verify it hits the intended destination on the PBX; confirm caller ID presentation and name if applicable.
• Concurrent call test: Place multiple simultaneous calls up to planned channels; watch CPU/DSP utilization and audio quality.
• IVR/DTMF test: Navigate menus and voicemail PINs; confirm RFC 2833 events reach applications reliably.
• Failover test: Block one provider edge temporarily or simulate an outage; confirm DNS SRV/secondary target kicks in.
• Packet capture: If any issue arises, collect a full INVITE‑to‑BYE pcap and correlate SIP/SDP to RTP flow.

Next steps

• If you own the PBX and want more inbound control without rewiring it, set up a CallFlow account and provision a test number to your PBX via a SIP target. You can get numbers from a prepaid wallet and pay only for what you use. Start here: /register
• Planning a migration or troubleshooting a complex trunk? Bring us your call flow and current settings via /contact. We’ll sanity‑check NAT, codecs, and routing, and suggest a rollout and test plan.