The branch office telephony decision sounds deceptively simple: buy trunks or subscribe to a hosted service. In practice, the choice between SIP trunking and hosted VoIP sets the architecture for call control, failover behaviour, and data residency for years. Get it wrong and you are either paying to maintain on-premises kit that no longer fits your estate, or you have handed call-processing sovereignty to a platform whose audio path you cannot fully map.
This guide works through the structural differences, the failure modes that matter most at branch scale, and the compliance considerations that have become non-negotiable for regulated industries.
The core architectural split
SIP trunking and hosted VoIP solve different problems. With SIP trunking, your organisation owns and operates the call-control layer: an IP-PBX sits at the centre, Session Border Controllers handle security and QoS at the edge, and the SIP trunk provider supplies the carrier connectivity. The provider terminates calls; you route them. With hosted VoIP, the provider operates the entire phone system. You consume it as a service; the PBX logic, dial plans, and call processing all live in the provider’s infrastructure.
That distinction has direct consequences for every branch-office decision that follows. SIP trunking is a connectivity product bolted onto infrastructure you already control. Hosted VoIP is a managed system that replaces infrastructure you would otherwise have to run.
The CAPEX profile reflects this cleanly. A SIP trunking deployment requires IP-PBX hardware, enterprise-grade IP phones, SBC licences, and the engineering time to integrate them. Hosted VoIP implementations typically complete in days or weeks with minimal disruption; SIP trunking transitions require careful planning, staged cutover, and failover testing before you touch production traffic. Neither is inherently superior; the right answer depends on what your organisation already owns and how much operational control it wants to retain.
Branch survivability and failover architecture
Branch offices introduce a failure mode that centralised deployments can ignore: WAN loss. When the link between a branch and the central PBX drops, call control disappears unless you have planned for it.
SIP trunking handles this through local survivability gateways. A local gateway at the branch maintains basic calling functionality independently of the central system. When the primary trunk path fails, calls reroute automatically through backup trunks, alternate carriers, or the PSTN. From the caller’s perspective, the cutover is transparent. Healthcare and financial institutions frequently keep PSTN backup in place as a last-resort path, partly because their regulatory obligations require it and partly because no software-defined failover is unconditional.
A voice disaster recovery plan that has not been tested quarterly is a document, not a capability. Defined RTO/RPO targets, mapped failure scenarios, SBC clustering, and redundant routing logic only prove their value under controlled load before they are needed under real conditions.
Hosted VoIP handles branch survivability differently. Because call control lives in the provider’s infrastructure, branch resilience depends entirely on the provider’s network redundancy and geographic distribution. A provider with dense points of presence and automatic regional failover can deliver strong survivability without any local gateway. A provider running a single region cannot. This is where network topology matters as much as the product’s feature list.
We operate 44 points of presence across Europe and the Middle East, with direct peering to AWS, Azure, GCP, Oracle, and Cloudflare at every site. For branch deployments routed through our Telecom product, that peering density means audio paths stay short and failover targets are geographically close, which is the practical difference between a 200-millisecond reroute and one that crosses an ocean.
Security requirements in 2025
The security baseline for SIP deployments has moved substantially. Sending SIP over UDP port 5060 with cleartext RTP is no longer acceptable practice. Modern deployments require TLS 1.2 or 1.3 for signaling and SRTP or DTLS-SRTP for media. STIR/SHAKEN signing on outbound calls is now expected; carriers increasingly block unsigned or mis-labelled traffic, so an unsigned trunk is increasingly a liability rather than just a gap.
Hosted VoIP providers absorb most of this complexity: encryption, signing, and SBC management are the provider’s problem. With SIP trunking, they are yours. That is not an argument against SIP trunking for organisations with the engineering depth to handle it; it is an argument for being clear-eyed about what the operational commitment actually involves.
Data residency and GDPR: what the audio path actually means
VoIP and cloud telephony systems process personal data: call logs, audio recordings, caller ID, geolocation metadata. Under GDPR, any international transfer of that data requires a lawful basis under Chapter V (Articles 44 to 50), with adequate safeguards. The fines for violations reach €20 million or 4% of global annual turnover, whichever is higher, and a Data Processing Agreement under Article 28 is mandatory regardless of architecture.
EU data residency is not technically required by GDPR, which is technology-neutral in principle. But keeping data within the EU eliminates the Chapter V transfer obligation entirely: no transfer impact assessment, no standard contractual clauses, and lower expectations from supervisory authorities on additional safeguards. For most organisations, that simplification is worth more than the marginal flexibility of a non-EU provider.
The subtlety that buyers miss: an EU-hosted system can still route audio through carrier infrastructure that touches non-EU points of presence. Hosting region and audio path are not the same thing. Before signing any enterprise voice contract, ask the vendor for the audio-path diagram, not just the region where inference or call records are stored. If they cannot produce one, that is your answer.
Regulated industries: DORA and NIS2 obligations
For financial-sector organisations, DORA (Regulation EU 2022/2554, applicable from January 2025) adds a layer of third-party oversight that directly affects the hosted VoIP procurement decision. DORA requires formal ICT risk frameworks, structured oversight of all ICT third-party providers, and a complete Register of Information covering every vendor arrangement. The regulation explicitly excludes traditional analog telephone services from its ICT third-party provider definition, but cloud-hosted VoIP sits in a different category: any provider delivering covered ICT services is within scope. Financial entities should confirm with legal counsel how their specific telephony arrangement is classified before signing.
NIS2 (Directive EU 2022/2555, in force from October 2024) is relevant on the supplier side. Telecom operators and cloud infrastructure providers are explicitly classified as essential or important entities under NIS2. A hosted VoIP provider serving EU enterprises is subject to NIS2’s security risk-management requirements and the 24-hour incident reporting obligation. Asking a prospective provider for their NIS2 classification and incident response documentation is a reasonable part of due diligence, not an edge-case request.
Choosing the right architecture
SIP trunking fits organisations that already operate an IP-PBX, carry heavy call volumes across multiple locations, and have the engineering team to manage SBCs, encryption, and failover logic. The control is real, but so is the operational surface.
Hosted VoIP fits organisations consolidating branch infrastructure, reducing on-premises footprint, or moving to a consumption model where telephony is a service rather than a system to maintain. The trade-off is dependency on the provider’s network quality, geographic reach, and data-residency commitments.
For enterprises consolidating onto sovereign cloud, the decision rarely turns on features. It turns on where call control lives, where audio travels, and whether the provider’s network topology can actually deliver the failover behaviour the architecture diagram promises. Those are engineering questions, and they deserve engineering answers before the contract is signed.
