Ask ten vendors what SIP trunking is and you will get ten versions of the same sentence: a virtual phone line that carries calls over the internet. Accurate enough as a summary, and it quietly skips the part that matters technically, which is that SIP carries no voice whatsoever.
This guide explains what the term covers, how a call actually travels, how to size a trunk, and where the rules change depending on which country you are operating in.
What is SIP trunking?
SIP trunking is a way of connecting a business phone system to the public telephone network across an IP link instead of physical lines. One trunk carries many conversations at the same time, and how many you can run concurrently is a commercial decision rather than a hardware constraint.
Think of it as replacing a bundle of copper pairs with a data connection and an agreement about how many calls may cross it. What changes is the delivery method and the economics. What stays the same is the telephone number a customer dials.
| Element | What it does |
| SIP | Signals the start, change and end of a session |
| Trunk | The logical connection between your system and a provider |
| Channels | How many conversations can run at once |
| Media | The audio itself, carried by a separate protocol |
| SBC | Guards the boundary between your network and theirs |
Notice the fourth row, because it is the one most explanations leave out entirely.
Two practical consequences follow from that table. Capacity and telephone numbers are bought separately, so the count of each moves independently. And because signalling and audio travel by different routes, the two fail differently, which shapes how you diagnose problems later.
The two words, taken separately
Splitting the term apart makes the rest of this considerably easier to follow.
What SIP actually is
SIP stands for Session Initiation Protocol, an internet standard rather than any vendor’s product. RFC 3261, published by the IETF in June 2002, defines it as an application-layer signalling protocol for creating, modifying and terminating sessions with one or more participants.
Read the specification closely and one point stands out. It states that SIP does not provide services; it provides primitives that can be used to build them, and it works alongside other protocols rather than replacing them. Session details such as media type and codec are described using a separate format, with the audio travelling by yet another mechanism.
So SIP is closer to the language two systems use to agree a call than to the call itself. It says who is calling, who is being called, and what kind of session is proposed. Once both ends agree, the conversation flows elsewhere.
Why labour the distinction? Because troubleshooting hinges on it. A call that connects but has no audio is almost never a signalling problem, and knowing that saves an afternoon of looking in the wrong place.
The standard itself is old enough to be thoroughly settled. Published in 2002 and superseding an earlier 1999 specification, it has been extended many times since without being replaced, which is part of why equipment from different manufacturers generally interoperates.
Why it is called a trunk
The word predates internet telephony by roughly a century. In traditional telephony, a trunk was a shared line between exchanges carrying numerous conversations rather than one, as opposed to the individual line running to a subscriber’s home.
Cloud platforms inherited the vocabulary along with the concept. A modern version is logical rather than physical, so nothing is bundled together in a duct somewhere, yet the idea holds: one connection, many concurrent conversations, sized to expected demand.
That inheritance explains some otherwise puzzling terminology on invoices and order forms. Terms coined for circuit-switched equipment survive into products that contain no circuits at all, which trips up buyers reading a quotation for the first time.
How a SIP trunk works
A call crosses the boundary between your systems and your provider’s, gets signalled into existence, and then carries audio along a path the signalling has already negotiated.
The path a call takes
The sequence is worth knowing in outline, because it maps directly onto where faults occur:
- Somebody dials. Your phone system, or a customer’s handset, initiates the request.
- Signalling begins. An invitation crosses the trunk, naming the parties and proposing session parameters.
- Both ends negotiate. Codecs, ports and media handling get agreed between the systems.
- Audio flows. Voice packets travel between endpoints, independently of the signalling that set them up.
- The session ends. A closing message tears the call down and releases the channel.
Steps two, three and five are SIP. Step four is not, so audio quality problems and call-setup problems have entirely separate causes and separate fixes.
Keep that split in mind when a supplier asks for diagnostic information. Signalling faults appear in call detail records and protocol traces, while media faults surface as jitter, latency and packet-loss readings taken across the network path. Supplying one when the other is needed wastes a support cycle.
What sits at the edge
Most deployments place a session border controller between the internal network and the provider. An SBC handles security, hides internal topology, enforces policy on what traffic is permitted, and translates between systems that implement the standard slightly differently.
That last function matters more than the specification would suggest. The protocol is standardised, and implementations still vary enough that two compliant systems occasionally disagree, so interoperability testing belongs in any deployment plan rather than being assumed.
Smaller deployments sometimes rely on a firewall with protocol awareness instead of a dedicated appliance, a reasonable economy at low volume. The trade is visibility: when something misbehaves at three hundred concurrent calls, a proper border device tells you considerably more about why.
Channels, concurrency and sizing
Channel count is the single most misunderstood commercial decision in this area, and getting it wrong costs money in both directions.
Working out how many you need
Channels represent concurrent conversations, not telephone numbers. A business publishing two hundred direct lines does not require two hundred channels, because the odds of every extension ringing simultaneously are remote.
Size against peak concurrency instead. Pull historical call data, find the busiest fifteen minutes of the busiest day, and add headroom for growth and for seasonal spikes. Guessing produces either wasted spend or blocked calls, and the second costs considerably more in lost business than the first does in licensing.
A rough starting ratio used across many contact operations is one channel for every two to three agents, though that varies enormously with how the team works. Outbound dialling pushes the requirement up sharply, since a predictive dialler may place several calls per available agent. Heavy self-service pushes it down, because automation handles conversations that never reach a person.
Whatever ratio you land on, recalculate it annually. Headcount changes, channel mix changes, and a figure set during one growth phase rarely still fits two years later.
What happens when you run out
Calls beyond the limit are rejected or diverted, depending on configuration. Callers hear a busy signal or reach voicemail, and in most setups nobody inside the business is notified.
Set an alert on channel utilisation and design an overflow path in advance. Some providers offer burst capacity flexing above your committed figure, and that is worth raising where demand is uneven across the year.
Decide too what should happen to the calls that cannot be carried. Diverting overflow to a mobile, to an answering service or to a callback offer preserves the enquiry; a busy tone loses it silently, and the loss never appears in any report you look at.
SIP trunking against the alternatives
| Option | What it is | Suits |
| ISDN or PRI | Circuit-switched lines in fixed blocks | Legacy estates, increasingly withdrawn |
| SIP trunk | IP connection to your own phone system | Businesses keeping an existing PBX |
| Hosted telephony | Provider runs the phone system too | Teams wanting no on-site equipment |
| Contact center platform | Routing, queueing and reporting on top | Operations answering for service levels |
Against ISDN and PRI
Traditional digital lines arrive in fixed increments, typically thirty channels for a European PRI or twenty-three in North America. Adding capacity means ordering more, waiting for installation, and paying for whole blocks whether or not you use them.
IP delivery removes that granularity problem. Capacity changes become configuration changes, often within a day, and the cost of an unused channel is a line on an invoice, not a physical circuit sitting idle.
Availability is the other difference, and increasingly the decisive one. Legacy digital lines are being withdrawn across several major markets, covered further below, so the comparison is moving from which option suits you toward how long the older one will remain on sale at all.
Against hosted telephony and contact center software
Here the difference is ownership. A trunk delivers connectivity to a system you run yourself, whether on-site or in a cloud instance under your control. Hosted telephony bundles the system into the service, so nobody in your business administers it.
Contact center platforms sit higher still, adding routing, queueing, recording and reporting that neither of the other two provides. Those layers complement each other instead of competing, and many organisations run connectivity beneath a platform. Our explainer on how these platforms work covers where that boundary falls.
Choosing between them comes down to how much you want to operate yourself. Running your own system buys control over configuration and, for larger estates, better economics. It also means owning upgrades, security patching and the phone call at nine in the morning when something breaks.
What you need to run one
On your side
Four things, broadly. Equipment capable of speaking the protocol, which covers most systems sold in the last fifteen years. Sufficient bandwidth, with quality of service configured so voice is prioritised over file transfers. An SBC or equivalent security boundary. And somebody who understands the configuration well enough to change it.
That last requirement gets underestimated. Connectivity is infrastructure, and infrastructure needs a named owner, particularly where the business depends on it commercially.
Bandwidth arithmetic is simpler than people expect. A single conversation typically consumes somewhere around 85 to 100 kilobits per second in each direction once protocol overhead is counted, depending on the codec in use. Multiply by peak concurrency, then leave generous room for everything else sharing the connection.
From the provider
Ask for specifics rather than reassurance. Which numbering ranges can they supply, in which territories, and in which categories? What is the committed channel count, and how is traffic above it treated? How is failover handled if the primary connection drops?
Add two commercial questions. What are the minimum term and notice period? And critically, can your numbers be ported out cleanly at the end, because digits printed on vehicles and contracts are far harder to replace than any supplier.
Probe support arrangements as well. Response times, escalation paths and whether anyone is reachable outside office hours all matter more for connectivity than for most software, since an outage here stops customers reaching you entirely.
Benefits, and the honest limits
The advantages are genuine and fairly well established. Capacity flexes without engineering visits. Costs typically fall against legacy circuits, particularly for international calling. Numbers become independent of geography, so a company can present a London line from Abu Dhabi. Disaster recovery improves, since traffic can be rerouted to another site or to mobiles within minutes.
Where it adds work
Nothing here is free of effort, and three areas reliably need attention.
Network quality becomes your responsibility in a way it never was with dedicated circuits. Jitter, packet loss and insufficient upstream bandwidth all show up as complaints about call quality, and they originate inside your own network more often than at the provider.
Security needs designing in. An exposed SIP endpoint attracts automated attack traffic, and toll fraud on a compromised trunk can run up substantial charges quickly. Firewall policy, strong credentials and monitoring are baseline requirements rather than optional hardening.
Power and connectivity dependency also change the risk picture. A traditional line drew power from the exchange; an IP service does not, so battery backup and a secondary connection belong in the design for anything you consider critical.
Emergency calling deserves its own check. Location information behaves differently when a number is no longer tied to a building, and requirements vary by jurisdiction, so confirm how your provider handles it rather than assuming the old behaviour carries across.
Why the copper switch-off matters now
For most of the past decade, moving off traditional lines was optional. In several countries it no longer is, and the timetable is public.
In the United Kingdom, the House of Commons Library reports that landline services will move to a fully digital network by January 2027, with the existing public switched telephone network withdrawn. The same briefing cites Ofcom figures showing UK customers still on that legacy network falling from 5.2 million in mid-2024 to 3.2 million a year later, so migration is well advanced rather than theoretical.
Britain is not first. Estonia and the Netherlands have already completed their switch-offs, and several larger European and Asian markets are winding theirs down on their own timetables, each at a pace set locally rather than by any international agreement.
Gulf operators should read this as direction rather than obligation, since none of it binds a business in Dubai or Riyadh. The useful signal is what it implies about equipment, support and pricing: as legacy platforms retire across major markets, vendor attention and spare parts follow the traffic. An organisation planning a ten-year estate has a reason to move that has nothing to do with any local deadline.
What changes in the Gulf
Everything above is technically identical wherever you operate. The regulatory position is not, and it changes who may sell you connectivity in the first place.
Licensing and outbound obligations
Voice service in the Emirates is regulated at the service level rather than only at the numbering level. TDRA treats voice and video calling over IP as a regulated activity, deliverable by licensed service providers or in collaboration with them, and licensees must block traffic from applications falling outside compliance. Providers absent from the published roster may request an exemption at the authority’s discretion.
Practically, that means you cannot simply buy trunking for this market from any international supplier with an online checkout. Establish which licensee carries the traffic, under what agreement, and confirm it in writing before signing anything.
Outbound campaigns carry a further condition. Cabinet Resolution No. 56 of 2024 requires marketing calls to use local phone numbers issued by telecommunications companies licensed in the State, registered under the calling company’s commercial licence, and prohibits dialling from lines neither registered to nor owned by that business. Free zone entities sit inside that regime, which regularly surprises companies holding a DIFC or ADGM licence.
One more regional planning note. Coverage patterns across the Gulf make concurrency lumpier than any annual average suggests, since Ramadan moves contact volume later into the day and renewal seasons in insurance and property concentrate demand into short windows. Size capacity against those peaks, not against a smooth monthly figure.
Working patterns add to this. Where the federal working week differs from the one your private-sector customers keep, and from the schedule an offshore team follows, the busiest hour may not sit where a planning spreadsheet assumes. Check the actual data before committing to a number.
Frequently asked questions
What is the difference between VoIP and SIP trunking?
VoIP is the broad category of carrying voice over internet networks, while SIP trunking is one specific arrangement within it. Voice over IP describes any telephony delivered across data networks, including hosted phone services and consumer calling apps. A SIP trunk links a phone system you operate to a provider’s network, signalled using that same protocol. Every SIP trunk involves VoIP; plenty of VoIP services involve no trunk at all.
What is the difference between a SIP line and a SIP trunk?
A line generally refers to a single concurrent call path, whereas a trunk is the connection carrying many of them together. Vendors use the terms loosely, and some sell “lines” that behave exactly like channels on a trunk. What matters commercially is the concurrency figure rather than the label, so ask how many simultaneous conversations the arrangement supports and what happens when that ceiling is reached. Compare quotes on that number, not on terminology.
Do I need a PBX to use SIP trunking?
Yes, in the sense that a trunk must terminate somewhere capable of handling calls. That endpoint might be an on-site PBX, software running on a server, or a cloud platform accepting trunk connections. A trunk cannot work alone, since it supplies connectivity rather than call handling. Businesses wanting no system to administer are usually better served by hosted telephony, where the provider runs that layer on their behalf and the question never arises.
Is SIP trunking secure?
It can be, though security is configured rather than inherited. The protocol specification includes provision for authentication, integrity protection and encryption, and those capabilities only help when switched on and maintained. Exposed endpoints attract automated probing, and fraudulent traffic across a compromised connection generates real charges quickly. Treat firewall policy, credential strength, encryption and call-pattern monitoring as baseline requirements, and review them on a schedule rather than after an incident.
What happens to my numbers if I change providers?
Numbers can usually be ported to a new supplier, though the process runs slower than switching the trunk itself. Timelines depend on the releasing operator and on local rules, and some categories move less easily than others. Confirm portability terms before signing, since a contract that makes exit difficult effectively raises your switching cost later. An alternative worth asking about is keeping your existing carrier relationship while changing the software layer above it.
Where TabaTalk fits, and where to go next
Worth being direct about scope. TabaTalk sells cloud contact center technology: routing conversations, dialling them, recording them, analysing them, and passing data onward to whichever systems own the rest. The platform holds no network and does not act as a carrier, so trunking itself sits outside what it provides.
Where the two meet is BYOC, which lets a business keep its existing carrier and numbers while running omnichannel conversations, routing design and live reporting on top. Businesses already holding trunks they are happy with keep them untouched under that arrangement. For anyone who would rather not think about connectivity at all, the virtual phone number coverage grid shows what is available directly.
Planning a migration off legacy lines, sizing concurrency for a contact center, or working out how existing trunks would sit underneath a platform? Those questions resolve faster in conversation than in any specification document. Speak to sales or book a demo, and bring your current call volumes.
