SIP in one paragraph
SIP — the Session Initiation Protocol, defined in RFC 3261 — establishes, modifies and terminates sessions. It does not carry audio. The media travels separately over RTP, and the two endpoints negotiate what codec to use and where to send it via SDP carried inside the SIP messages. That separation of signaling and media is the source of most of SIP's flexibility and most of its operational difficulty.
| Method | Purpose |
|---|---|
| INVITE | Start a session, or modify one already in progress (re-INVITE) |
| ACK | Confirm a final response to an INVITE |
| BYE | End the session |
| CANCEL | Abandon a request still in progress |
| REGISTER | Bind a user to a contact address |
| OPTIONS | Query capabilities — in practice, the standard trunk heartbeat |
| REFER | Ask the far end to transfer the call elsewhere |
Responses are numbered like HTTP: 1xx provisional, 2xx success, 3xx redirection, 4xx client error (486 Busy Here, 404 Not Found), 5xx server error, 6xx global failure.
What a SIP trunk actually is
A SIP trunk is a commercial and logical arrangement between your network and a service provider's, carrying a contracted number of concurrent sessions. It is not a physical circuit. Two consequences follow, and they surprise people coming from PRI:
- Capacity is a policy, not a fact. Nothing physically prevents session number 500. Only configuration does.
- Quality is a spectrum. The trunk can be entirely "up" while calls are unusable. See voice quality.
The session border controller
An SBC sits at the boundary between your network and the provider's. Formally it operates as a back-to-back user agent (B2BUA) as defined in RFC 3261: it terminates the inbound SIP session completely, inspects and transforms both the signaling and the media, and then initiates a fresh outbound session toward the destination.
That full termination is what makes everything else possible. The SBC is not forwarding packets — it is re-originating the call, which means it can change anything.
What it does
| Function | What it solves |
|---|---|
| Topology hiding | Internal addresses, hostnames and network structure never leave your boundary. Without it, your SIP headers advertise your internal architecture to anyone who receives a call. |
| SIP normalization | Every vendor and carrier implements SIP with its own dialect. The SBC rewrites headers so your PBX sees what it expects and the carrier sees what it expects. In practice this is the function that consumes most configuration effort. |
| Call admission control (CAC) | Per-trunk-group enforcement of concurrent session limits, stopping calls that would exceed contracted capacity from ever reaching the PBX. This is your capacity ceiling — the closest equivalent to "we only have 23 channels." |
| Transcoding | Converts between codecs when the two sides cannot agree. Useful, expensive in resources, and quality-degrading — so design to avoid needing it rather than relying on it. |
| Media handling & NAT traversal | Anchors or relays RTP so media flows correctly across address boundaries and firewalls. |
| Security | Registration and INVITE flood protection, malformed-message rejection, access control, and encryption via TLS for signaling and SRTP for media. |
| Routing & failover | Least-cost routing, carrier failover, and load distribution across multiple providers. |
Media anchoring: the decision that costs money
An SBC can either anchor the media — RTP flows through it in both directions — or let the endpoints send media directly to each other while only the signaling passes through.
| Mode | Advantages | Costs |
|---|---|---|
| Anchored | Full control: recording, transcoding, quality measurement, topology hiding of media, consistent NAT behavior. | Every concurrent call consumes SBC media capacity, which sizes the hardware. Adds a hop of latency. |
| Direct media | Lower latency, far lower SBC resource consumption. | No recording, no transcoding, no independent quality measurement, and NAT complications. |
Most enterprises anchor, because recording and measurement are non-negotiable. The important part is knowing you have made that choice, because it determines SBC sizing — and because a transfer scenario where the carrier does not support REFER leaves media anchored on your SBC for the entire duration of the onward call, consuming capacity you may not have planned for.
Sizing a SIP trunk
Two steps, as covered in TDM to IP migration: determine concurrent session requirement using Erlang B against a stated grade of service, then calculate the bandwidth to carry it.
Bandwidth per session is codec payload plus IP, UDP and RTP header overhead, and the overhead is not trivial — for low-bitrate codecs the headers can approach the size of the payload. Calculate it rather than estimating, and calculate it for the actual WAN links the media will traverse, including any VPN encapsulation.
Security, briefly but seriously
An internet-facing SIP interface is scanned continuously. Toll fraud is automated and relentless, and a misconfigured trunk can accumulate a very large bill overnight.
- Restrict signaling to the carrier's addresses. Do not accept SIP from anywhere.
- Use TLS for signaling and SRTP for media where the carrier supports it.
- Enforce CAC — it is a fraud control as much as a capacity control.
- Apply outbound dial-plan restrictions by destination, especially to international premium ranges.
- Alert on anomalous call volume and on out-of-hours international traffic. Fraud happens at 2am on a public holiday, by design.
Deployment patterns
- Centralized SIP trunking. One or two SBC sites terminate all trunks; branches route internally. Simplest to manage, and it concentrates your failure domain — so make those sites genuinely redundant.
- Distributed. Local breakout per region or site. Lower latency and better survivability, at the cost of more SBCs to operate.
- Cloud SBC. Offered as a service, including by several CCaaS providers. Reduces operational burden; verify what visibility and control you retain, particularly for independent quality measurement.
- Dual carrier. Two providers with automatic failover. The most effective single availability improvement available, and it also gives you commercial leverage.
Related reading
- TDM to IP migration — planning the move.
- Voice quality: MOS, R-factor & POLQA — measuring the result.
- STIR/SHAKEN — identity on SIP trunks.
Sources
SBC normalization is where most SIP migrations are actually won or lost.
Book a call