What is SIP trunking, and do you need it?

A SIP trunk is the link between a phone system you own and the public telephone network, carrying calls as data instead of over dedicated wires. It replaces analog lines and PRI circuits. If your phone system is hosted by somebody else, you already have trunks, and buying one is not a decision you have.

That last sentence is the one most articles on this subject leave out. The rest of this explains what a trunk is, when it is genuinely the right thing to buy, and how to tell which situation you are in. It is the starting point for everything else in SIP and networks.

In a building wired for copper, every desk phone had an extension, and the extensions shared a smaller number of outside lines. Twenty people, six lines. The bundle of six was the trunk, and the switch in the back room decided which conversation got which line.

That arrangement had one useful property and one expensive one. The useful property: you never needed as many outside lines as you had people, because people are not all on the phone at once. The expensive one: each line was a physical circuit, ordered from the carrier, delivered on a schedule, and paid for whether it carried a call that month or not.

A SIP trunk keeps the useful property and drops the physical one. You still buy a number of simultaneous conversations. They now arrive over the internet connection you already have, and adding one is a configuration change rather than a truck roll.

The unit is called a channel, and one channel is one conversation in progress. Two people talking to each other inside your office use none of them.

Worth being precise here, because the vagueness causes real confusion when you start comparing quotes.

SIP is the Session Initiation Protocol, specified in RFC 3261. It is a signalling protocol, and section 2 of the specification says exactly what it is for: locating the end system to be used, working out whether the called party is willing to talk, agreeing what media and media parameters both ends can handle, setting the session up, and managing it afterwards including transfer and termination.

Search the whole specification for the word "trunk" and you will find it zero times.

That is not a technicality. "SIP trunk" is a commercial packaging of the protocol, not a feature of it, which is why two providers can sell you something called a SIP trunk and mean measurably different things: different codec support, different rules about how many channels you may burst to, different handling of the audio path, different behaviour when your equipment stops answering. The protocol is standard. The product is not.

You buy a trunk when you own the thing at the other end of it. That means one of two situations:

You have an on-premises PBX. A physical box in a back room or a server in a rack, running software you administer, with your phones registered to it. It has been sitting on analog lines or a PRI, and replacing those with a SIP trunk usually saves money and always makes adding capacity faster.

You have a phone system you run yourself. A self-hosted platform on a virtual machine somewhere. Same logic. You own the switch; the trunk is how it reaches everybody else's phone.

If neither of those describes you, the honest answer is that a SIP trunk is not the product you are looking for. On a hosted system the provider owns the switch, and the trunks behind it are already bought, already sized, and already somebody else's operational problem. Buying one yourself would be buying a spare part for a machine you do not own.

The most common sizing mistake is to count people. Ten people who answer the phone does not mean ten channels, and a hundred calls a day does not mean a hundred of anything.

What a channel is sized against is overlap: how many conversations are happening at the same instant during your worst half hour. That is a calculation with a real answer, and it comes out lower than most people expect. How many SIP trunks do you need walks through it with an Erlang B table and a worked example, and our free Erlang C calculator does the arithmetic for the staffing side of the same question.

The short version: work out your busiest hour, multiply calls by average length, divide by sixty. That number, in erlangs, is your offered load. Channels are that plus a margin, and the margin is the part worth thinking about, because the cost of one too few is a caller hearing an engaged tone with no way to know you exist.

A trunk carries calls to and from the public network. It has no opinion about what happens to a call once it arrives.

Everything a caller actually experiences, which number rings first, what they hear when nobody is free, whether a transfer works, what happens after hours, is decided by the switch, not by the trunk. A perfect trunk in front of a phone system that sends everyone to a full voicemail box has not solved anything.

It also does not fix your network. Calls over a SIP trunk are subject to the same constraints as any other real-time traffic: enough room going out at your busiest moment, and steady delivery. How much bandwidth does VoIP need does that arithmetic properly, headers included, and explains why a capacity figure is not a test of whether your connection will actually carry calls well.

Capacity is only half of it, because the equipment between your phones and the trunk can ruin a call that has room to spare. SIP ALG, and why to turn it off is the router feature that rewrites signalling it does not understand, network settings that break VoIP audio covers the rest of the usual culprits, and why your VoIP phone will not register is where to start when a handset never gets as far as a call.

When the connection stops altogether, the trunk has nothing to carry and the useful work was done beforehand: what happens when your internet drops is that plan written out.

And it does not fix the sums. If you are comparing a trunk against the alternatives, the true cost of a business phone system is the list of line items that do not appear on the quote.

Three questions, in order:

1. Is there a phone system box in your building, or a server you pay for that runs your phone system? If yes, you own the switch, and a trunk is a genuine option.
2. Do you administer it, or does somebody else? If a vendor logs in to change your call flow, you may own the box and not the decision. Find out who holds the trunk contract before shopping for another.
3. Do your phones register to something on the internet that you do not run? Then you are on a hosted system. The trunks exist and they are not yours to buy.

There is no wrong answer in that list. The wrong move is buying a trunk to solve a problem the trunk is not attached to.

We are the third row of the figure. Ringfully runs the switch, so the trunking is ours: already provisioned, already sized, and not a line on your invoice or a decision on your desk. Billing is per seat with the minutes included, which is a different shape of question from channels and per-minute rates, and what a plan costs is the whole of it.

Numbers are provisioned by hand rather than bought from a page, so if you are moving off a trunk and want to keep the number you publish, that is a conversation with a person and a porting request, not a checkout.

What to do next depends on the row you are in. If you own a PBX and it works, sizing a trunk correctly is the next piece of arithmetic. If you own a PBX and you are tired of owning it, the comparison worth making is not trunk against trunk; it is switch against switch, and the trunk question disappears with the closet it lives in.