# SIP trunking and the session border controller

> A SIP trunk is a virtual connection that carries voice over IP between a phone system and a carrier, replacing physical PRI/TDM trunks. A session border controller (SBC) sits at the border of a SIP network to secure it, hide internal topology, solve NAT traversal (with STUN/TURN/ICE) and control which sessions are admitted.

- Canonical URL: https://www.broadnet.me/reference/sip-trunking-and-sbc
- Language: en
- Last updated: 2026-07-18
- Publisher: BroadNet (https://www.broadnet.me)

What a SIP trunk is and the role of the session border controller (SBC): NAT traversal with STUN/TURN/ICE, topology hiding via B2BUA, security and admission control at the network border, and transcoding.

## What a SIP trunk is

A SIP trunk replaces the physical telephone trunk (an ISDN PRI or TDM circuit) with a SIP session over an IP connection between an enterprise phone system (IP-PBX) and an internet telephony service provider or carrier. It carries concurrent calls as SIP-signalled, RTP-borne media, scaling by provisioning channels rather than installing copper. SIP trunking is how organisations connect their voice to the PSTN over IP, and how carriers interconnect voice between networks.

## The NAT problem

SIP and SDP embed IP addresses and ports inside their messages — the Contact header, the Via, and the SDP c= and m= lines. When an endpoint sits behind NAT, those embedded addresses are its private ones, which are unroutable from outside, so signalling may connect while media has nowhere to go — the classic one-way or no-audio symptom. Solving this means discovering and advertising the public address/port a NAT will actually use, which is what STUN, TURN and ICE are for.

*NAT-traversal building blocks*

| Mechanism | RFC | Role |
|---|---|---|
| STUN | RFC 8489 | Discover the public IP/port a NAT assigns to the endpoint |
| TURN | RFC 8656 | Relay media through a server when direct paths fail (symmetric NAT) |
| ICE | RFC 8445 | Gather candidates and test which address pair actually works |

## STUN, TURN and ICE

The three work together. STUN lets an endpoint ask a server 'what public address do you see me on?', revealing the NAT binding it should advertise. TURN provides a relay: when NATs are too restrictive for a direct path, media is forwarded through a TURN server that both sides can reach. ICE ties them together — each side gathers candidate addresses (local, STUN-derived, TURN-relayed), exchanges them in SDP, and runs connectivity checks to pick the best working pair. ICE is mandatory in WebRTC and increasingly used for SIP behind NAT.

## The session border controller

An SBC is the demarcation device at the edge of a SIP network — between an enterprise and its carrier, or between two carriers. It almost always acts as a Back-to-Back User Agent, terminating each call and re-originating it, which lets it perform its core jobs: hiding internal topology (external parties never see internal addresses or the real signalling path), enforcing security and admission control, and fixing NAT and interoperability issues. It is, in effect, a firewall and translator purpose-built for real-time voice.

*What a session border controller does*

| Function | Purpose |
|---|---|
| Topology hiding (B2BUA) | Conceal internal addresses, routing and dialog details |
| Security | Block SIP scanning/DoS, enforce TLS/SRTP, rate-limit registrations |
| NAT traversal | Fix embedded private addresses; anchor/relay media |
| Admission control / CAC | Cap concurrent calls, protect bandwidth and licences |
| Interworking | Normalise SIP dialects, transcode codecs, bridge transports |
| Media anchoring | Route RTP through the SBC for monitoring and lawful intercept |

## Topology hiding and security

Because the SBC re-originates every call as a B2BUA, external peers only ever see the SBC's own addresses, not the internal PBX, proxies or subscriber IPs — this topology hiding both simplifies interconnect and denies attackers a map of the internal network. On top of that the SBC enforces the security posture: TLS for signalling and SRTP for media, registration and call-rate limits to blunt flooding and toll-fraud attempts, and normalisation of malformed or dialect-specific SIP so quirks on one side do not reach the other. This is why SIP trunks in production terminate on an SBC rather than exposing a PBX directly.

## Frequently asked questions

### What is a SIP trunk?

A SIP trunk is a virtual voice connection over IP between a phone system (IP-PBX) and a carrier or service provider, replacing physical PRI/TDM trunks. It carries concurrent calls as SIP signalling with RTP media, and scales by provisioning channels rather than installing physical lines.

### What does a session border controller do?

An SBC sits at the edge of a SIP network and secures it: it hides internal topology (acting as a B2BUA), enforces TLS/SRTP and rate limits, solves NAT traversal and media anchoring, controls how many concurrent calls are admitted, and normalises SIP between systems that implement it differently.

### Why do I get one-way or no audio on SIP calls?

Usually NAT. SIP and SDP carry embedded IP addresses; behind NAT those are private and unroutable, so signalling connects but RTP media has nowhere to return. Fixing it means advertising the correct public address via STUN/ICE or relaying media through TURN or an SBC.

### What is the difference between STUN, TURN and ICE?

STUN discovers the public address a NAT assigns you. TURN relays media through a server when a direct path is impossible. ICE orchestrates both — gathering candidate addresses, exchanging them, and testing which pair actually connects. ICE uses STUN and TURN as its tools.

### Is an SBC a firewall?

It is a firewall specialised for real-time voice. A general firewall does not understand SIP dialogs, SDP-embedded media ports or RTP, so it cannot safely open the right pinholes or hide topology. An SBC is SIP- and RTP-aware, adding topology hiding, admission control and transcoding a data firewall cannot.

## Sources

- [IETF RFC 8445 — ICE: Interactive Connectivity Establishment](https://datatracker.ietf.org/doc/html/rfc8445)
- [IETF RFC 7092 — Taxonomy of SBCs (B2BUA)](https://datatracker.ietf.org/doc/html/rfc7092)

## Related

- [SIP protocol overview](https://www.broadnet.me/reference/sip-protocol-overview)
- [SIP call flow](https://www.broadnet.me/reference/sip-call-flow)
- [RTP and SRTP media](https://www.broadnet.me/reference/rtp-and-srtp-media)
- [Voice API & SIP trunking](https://www.broadnet.me/answers/voice-api-sip-trunking)
- [Programmable voice (product)](https://www.broadnet.me/products/voice)