SIP trunking explained

A business moves from ISDN to SIP trunking and the bill halves. Eighteen months later, on the busiest morning of the quarter, customers start hearing a busy tone. Nothing in the phone system logs shows a failure, because the calls never reached the phone system. The trunk was sized for the number of desks rather than for the number of simultaneous conversations, and the difference had never mattered until it did.

That is the characteristic SIP trunking failure, and it is commercial rather than technical. The technology is well standardised and generally works. What causes problems is that a SIP trunk bundles four separate things — signalling, media, phone numbers and concurrent capacity — into one line on an invoice, and businesses buy it as though those four move together.

What a SIP trunk actually is

A SIP trunk replaces the physical lines that used to connect a phone system to the public telephone network with a connection over IP to a provider. That provider terminates calls to and from the ordinary telephone network on your behalf.

Two protocols do the work, and confusing them causes most operational difficulty. SIP, defined in RFC 3261, is described by its authors as an application-layer control protocol for creating, modifying, and terminating sessions with one or more participants. It sets calls up and tears them down. It does not carry the audio. The specification is explicit that the body of a SIP message contains a description of the session encoded in another format, and that in general the end-to-end media packets take a different path from the SIP signalling messages.

The consequence appears constantly in practice. A call can connect with no audio, because signalling reached its destination and the media stream did not. A firewall change can break audio in one direction only. A trunk can register successfully — which is a signalling event — while every call on it is silent. Any monitoring that watches registration alone will report a healthy trunk during exactly the outage customers are experiencing.

How a trunk is reached

Trunks are typically identified either by a fixed IP address or by a domain name. Where a domain is used, the mechanism is standardised in RFC 3263, Locating SIP Servers, by Rosenberg and Schulzrinne, which specifies that SIP uses DNS procedures to allow a client to resolve a SIP URI into the IP address, port, and transport protocol of the next hop to contact.

This matters commercially rather than academically. A carrier that publishes SRV records can direct you to multiple servers with priorities and weights, which is how failover within that carrier is delivered without you configuring anything. A carrier that gives you a single IP address is offering a single point of failure and calling it a trunk. Asking which of the two you are buying is a reasonable question during procurement and an awkward one afterwards.

Channels and numbers are separate purchases

This is the distinction that causes the busy tone in the opening paragraph, and it is worth stating in the plainest possible terms.

A business can hold two hundred direct dial numbers and thirty concurrent channels. That is a perfectly normal arrangement and is not a mistake in itself. It becomes a mistake when the thirty was chosen by counting desks, because concurrency is not the same as headcount.

Sizing concurrency honestly

The figure that matters is simultaneous calls at the busiest realistic minute, not the average and not the staff count. Several things push it above what a headcount suggests.

• Queued calls occupy a channel. A caller waiting to be answered is connected, and is consuming capacity for the whole wait.
• Transfers and conferences can hold more than one channel for a single conversation, depending on how the platform bridges them.
• Outbound campaigns using predictive dialling place more calls than there are agents by design, so their requirement is a multiple of the agent count rather than equal to it.
• Peaks are not uniform. A business with a marketing campaign, a service outage, or a seasonal pattern has a busiest minute far above its busiest average.
• Internal calls between extensions usually do not touch the trunk at all, which pulls the figure the other way — a distinction worth confirming for your own platform rather than assuming.

The practical approach is to monitor channel utilisation against capacity from the first day, not to calculate it once at procurement. Utilisation is the leading indicator of the busy-signal failure, and it is one of the few metrics where the warning arrives well before the incident.

One carrier is a single point of failure

Carriers have outages. This is not a criticism of any particular provider; it is a property of the category, and any provider claiming otherwise is describing an aspiration. The relevant question is what happens to your business during theirs.

A second trunk from a second carrier converts a total outage into degraded service. The cost is usually modest, because trunk pricing is driven mainly by concurrency and usage rather than by the existence of the trunk itself — a standby trunk sized for essential traffic rather than full capacity is cheaper than most businesses expect.

Two details separate failover that works from failover that exists on paper.

1. 1

   Outbound failover is yours to configure

   Your platform decides which trunk to use and can be told to try the second when the first does not answer. This part is within your control and is straightforward.

2. 2

   Inbound failover is the carrier's to arrange

   An inbound call arrives wherever the number points. Your system cannot fail over a call it never receives. This has to be set up with the number provider in advance, and it is the half businesses discover is missing during the outage.

3. 3

   Both have to be tested deliberately

   On a schedule, by actually removing the primary path rather than by reading the configuration. An untested failover is a hypothesis, and the day it is first exercised should not be the day it is needed.

Numbers are the real lock-in

The platform can be replaced over a weekend. The published numbers cannot, because porting is a regulated process involving another company on a timescale you do not control and cannot accelerate.

This inverts the usual procurement emphasis. The per-minute rate is negotiable and comparable; the question that determines your long-term freedom is whether your numbers are portable, what the provider's process is, and how long it takes in practice. A slightly worse rate from a provider with clean porting is a better commercial position than the reverse.

Security: the trunk is an internet-facing service

A SIP trunk terminates on something reachable from the internet, and that something is attacked continuously and automatically. The objective is almost always toll fraud: compromise an extension or the trunk itself, place expensive international calls, and leave the bill. The losses are real because they are billed by a carrier who delivered exactly the calls that were requested.

• Restrict SIP by source address to the carrier's signalling and media ranges where the carrier publishes them, rather than accepting from anywhere.
• Use strong, unique credentials on every extension. Weak extension passwords remain the most exploited weakness in this class of system.
• Rate-limit and ban on repeated authentication failures, so registration brute force is stopped rather than merely logged.
• Set outbound dialling permissions per extension and per route, so no extension can reach destinations it has no business reason to call. This single control caps the loss from a successful compromise more than any other.
• Cap spend with the carrier where they support it, so a successful attack has a ceiling rather than a monthly total.
• Alert on anomalies — international calls out of hours, sudden volume changes, registrations from unfamiliar addresses — because toll fraud is usually discovered on an invoice rather than by monitoring.

Encryption is available and worth using where the carrier supports it: TLS for the SIP signalling and SRTP for the media. It is worth being precise about what that protects. Encrypted transport secures the call while it is moving between you and the carrier. It says nothing about what happens to the audio beyond the carrier, and nothing at all about recordings sitting on a disk afterwards, which is where the concentrated risk usually is.

Quality is a network problem, not a trunk problem

When call quality is poor, the trunk is usually blamed and the network is usually responsible. Voice is intolerant of the delay, jitter and loss that other traffic absorbs invisibly: a file transfer that loses packets retransmits them, while a conversation that loses packets loses words.

The controllable factors are on your side of the connection. Voice traffic should be prioritised over general traffic on your own network and on your own internet circuit, which is achievable because both are yours. Beyond your edge, quality of service is not enforceable, which is why a business that depends on voice quality benefits more from a dedicated or prioritised circuit than from any trunk configuration change.

Codec choice is the other lever and is a straightforward trade: a compressing codec uses less bandwidth per call and sounds worse, while an uncompressed codec sounds better and consumes several times the bandwidth. On a constrained connection the compressing option is correct; on a good one it is a needless quality sacrifice. The decision should be made against measured bandwidth rather than by default.

Common mistakes

A representative scenario

A composite of situations we see repeatedly; no client detail is included.

A company migrates from ISDN to a single SIP trunk sized at thirty channels, chosen because there are twenty-eight desks. It works for over a year and the saving is real.

Two incidents prompt a review. During a promotion, inbound callers receive busy tones for most of a morning; the phone system logs show nothing, because the calls never arrived. Separately, a carrier fault takes the company off the air for an afternoon with no alternative route.

The review found that queued calls had been excluded from the original sizing, so the effective requirement at peak was closer to fifty than thirty. A second carrier was added with a standby trunk sized for essential traffic rather than full capacity, and inbound diversion was arranged with the number provider rather than assumed. Channel utilisation was added to the monitoring dashboard alongside registration state. The failover was tested the following month, which is how a misconfigured inbound route was found while it was still cheap to find.

Procurement checklist

• Concurrency is sized on the busiest realistic minute, with queued calls and any dialler ratio accounted for.
• Channel utilisation is monitored against capacity, with an alert before exhaustion rather than after.
• Numbers and channels are understood and priced as separate purchases.
• A second carrier exists, or its absence has been accepted and documented as a known single point of failure.
• Outbound failover is configured; inbound diversion is arranged with the number provider.
• Both directions of failover have been tested by removing the primary path, on a schedule.
• Number portability and the provider's porting process have been confirmed in writing.
• SIP is restricted by source address where the carrier publishes ranges.
• Extension secrets are strong and unique, with rate limiting and banning on repeated failures.
• Outbound dialling permissions are set per extension and per route, and international access is granted deliberately.
• A spend cap is in place with the carrier where supported.
• TLS and SRTP are enabled where the carrier supports them, with encryption at rest for recordings decided separately.
• Voice traffic is prioritised on your own network and circuit, and codec choice was made against measured bandwidth.

Frequently asked questions

Conclusion

SIP trunking is mature technology and rarely the thing that fails. What fails is the purchase: capacity sized against the wrong number, a single carrier treated as infrastructure rather than as a dependency, inbound failover assumed rather than arranged, and numbers committed before anyone checked they could be moved.

All four are settled in a procurement conversation rather than a configuration screen, and all four are considerably cheaper to settle before the trunk carries production traffic than after a busy morning when nobody can explain the busy tone.