Multi-Site Deployments

The MSP's Guide to VoIP: Part 15 of 20

Most of the series so far has focused on single-site deployments. One office, one internet connection, one set of switches and phones. The fundamentals are the same for multi-site, but the architecture decisions multiply. You are no longer just connecting phones to a PBX. You are connecting multiple networks across multiple locations into a system that feels like a single office to the people using it.

Multi-site voice is where the value of an MSP becomes undeniable to the client. The complexity of making extension dialing, call routing, and quality monitoring work across locations is well beyond what most businesses can manage on their own.

Architecture options

There are three primary approaches to multi-site voice, and the right choice depends on the client's size, locations, platform, and budget.

Single hosted PBX with phones at all sites

This is the simplest architecture and the one most MSPs should default to for small and mid-sized clients. All phones at all locations register to the same hosted PBX platform. Extension dialing works automatically because every phone is on the same system. Call routing, auto attendants, ring groups, and voicemail are centrally managed. There is no inter-site trunking to configure. There is no replication or synchronization to manage.

The platform provider handles the infrastructure. You handle the local network at each site and the phones. Each site needs its own internet connection with adequate bandwidth and quality for voice, its own voice VLAN and QoS configuration, and its own provisioning for local phones. But the voice platform itself is shared.

The limitation is that calls between extensions at the same site still travel out to the hosted platform and back, which means they use internet bandwidth in both directions and are subject to whatever latency and quality the internet path provides. For most hosted platforms, this is a non-issue because the calls are routed efficiently and the added latency is negligible. But for clients with marginal internet connections at remote sites, it can be a factor.

Separate systems with inter-site trunking

Each site has its own PBX (on-premises or hosted), and the PBXes are connected to each other via SIP trunks. Extension dialing between sites works through the inter-site trunk. Calls between sites are routed over a site-to-site VPN or directly over the internet between the PBX systems.

This approach provides local survivability. If the internet connection at one site goes down, the phones at that site can still make and receive calls through the local PBX (assuming it has its own trunk to the PSTN). Calls between sites are disrupted, but internal calls within each site continue to work.

The complexity is higher. You are managing multiple PBX systems, keeping their configurations synchronized (dial plans, extension numbering, voicemail access), and maintaining the inter-site SIP trunks. Extension number conflicts between sites need to be avoided through careful planning (site A uses 1xx, site B uses 2xx, etc.).

This model makes sense for clients where local survivability is a hard requirement, typically businesses where not having phones for even an hour causes significant operational or revenue impact.

Hybrid approaches

Some deployments combine the two models. The main office runs an on-premises PBX with full PSTN connectivity. Remote offices register to the main PBX over a VPN, with a local SBC (session border controller) or survivability gateway that provides basic calling if the VPN goes down.

Other hybrids use a hosted platform as the primary system with on-premises gateways at key sites for local PSTN breakout, reducing the dependency on internet connectivity for external calls.

The right hybrid depends on the client's specific requirements, and the design process involves mapping each requirement (survivability, quality, cost, management simplicity) to an architectural component.

Extension dialing and numbering

For a multi-site deployment to feel seamless, users need to dial extensions to reach people at other sites the same way they dial extensions for people in the same office. This requires a coherent numbering plan.

With a single hosted platform, this is automatic. All extensions are on the same system. Extension 201 at the main office and extension 305 at the branch are both reachable by dialing their extension number from any phone on the system.

With separate PBX systems, you need non-overlapping extension ranges and inter-site dial plan rules. If site A uses extensions 100 to 199 and site B uses 200 to 299, you configure each PBX's dial plan to route calls to the other site's extension range over the inter-site trunk. This also means that new extensions at any site must stay within the assigned range.

For larger deployments, a four-digit extension plan (site code + extension: 1201 for site 1 extension 201) provides more room to grow and makes it immediately clear which site an extension belongs to.

Network considerations

Multi-site voice adds network requirements that do not exist in single-site deployments.

Bandwidth per site

Every site needs enough upload bandwidth to support its voice traffic. The calculation is the same as for single-site: approximately 85 to 100 kbps per concurrent G.711 call in each direction, which you can model per-site with a Bandwidth Calculator. A site with 10 concurrent calls needs roughly 1 Mbps of dedicated upload bandwidth for voice.

For remote sites with smaller internet connections, bandwidth becomes the primary constraint. A branch office with a 10 Mbps upload connection supporting 5 employees might seem adequate, but if those 5 employees are frequently on calls while also using cloud applications, the upload can become saturated. QoS at each site is mandatory, not optional.

If inter-site calls traverse a VPN, the bandwidth for those calls comes out of both sites' internet connections. A call from site A to site B uses upload bandwidth at site A and download bandwidth at site A for the return path, plus the corresponding upload and download at site B. This doubles the bandwidth accounting for inter-site calls compared to calls to external numbers.

Latency between sites

For inter-site calls that traverse the internet or a VPN, latency between sites matters. Two offices in the same city might see 5 to 15 milliseconds of latency between them. An office in New York and one in Los Angeles will see 60 to 80 milliseconds minimum, just from the speed of light through fiber. Add routing overhead and encryption for VPN, and you might see 80 to 120 milliseconds.

Latency above 150 milliseconds one-way is where conversations start to feel awkward, with people talking over each other because the delay makes it hard to gauge when the other person has stopped speaking. For most domestic multi-site deployments, this is not a problem. For international deployments (US to Europe, US to Asia), it can be.

Measure the latency between sites before deploying with a VoIP quality test and factor the results into the architecture decision. If inter-site latency is high, a hosted platform where both sites register to servers that are geographically between them may provide better quality than direct inter-site trunking.

Failover

What happens when one site's internet connection goes down? The answer depends on the architecture.

Hosted platform with phones at all sites: The site that loses internet loses all phone service. Other sites are unaffected. The mitigation is a backup internet connection at each site, which may or may not be justified depending on the site's importance.

Separate PBX per site: The site that loses internet loses connectivity to other sites and to calls that traverse the internet, but can still make and receive calls through local PSTN trunks (if the PBX has them). Internal calls within the site continue to work.

Hosted platform with local survivability gateway: The gateway detects the internet outage and activates local calling through a local PSTN connection. Functionality is limited (usually just basic inbound and outbound calling, no advanced features), but the phones are not completely dead.

For any multi-site deployment, document the failure modes for each site and ensure the client understands what happens when connectivity is lost. The expectation should be set during the deployment planning, not discovered during an outage.

Common mistakes

Multi-site deployments have failure patterns that repeat across clients and MSPs. Knowing them saves time and credibility.

Underestimating bandwidth at remote sites. The main office has a fiber connection with 100 Mbps upload. The branch office has a cable connection with 10 Mbps upload. The branch gets the same VoIP deployment as the main office. Nobody checks whether 10 Mbps upload is enough when the branch staff is on calls, running cloud backups, and uploading files simultaneously. It is not. The branch has choppy calls every afternoon, and nobody connects it to the bandwidth constraint because the main office is fine.

Not accounting for latency between distant offices. If the two offices are in the same region, this is rarely a problem. If they are on different coasts or different continents, the latency is noticeable on calls and needs to be factored into codec selection and platform architecture.

Assuming the same configuration works everywhere. Each site has its own network equipment, its own internet connection, its own physical layout. The QoS configuration that works on the Cisco router at the main office does not directly translate to the Ubiquiti router at the branch. The VLAN setup on the HP switches at one site needs to be adapted for the Netgear switches at the other. Treat each site as its own deployment that shares a platform with the others, not as a copy of the first site.

Neglecting remote site monitoring. It is easy to monitor the main office because that is where you have the most visibility. Remote sites with smaller staff and less infrastructure get less attention. But remote sites are often more fragile, with less bandwidth, fewer redundancy options, and less on-site technical knowledge. Proactive monitoring at every site, not just headquarters, prevents problems from festering.

Forgetting E911 at every location. Each site needs its own E911 address registered with the VoIP provider. A phone at the branch office that dials 911 must send responders to the branch office, not to the main office. This is a life safety issue. Verify E911 registration for every location, test it, and update it when locations change. E911 compliance at every location is not optional and carries both legal liability and life safety implications. Consult your telecom attorney about per-location regulatory requirements.

Platform choice revisited

The platform selection decision from earlier in the series gets more weight in multi-site scenarios.

Hosted platforms excel at multi-site because the provider handles the central infrastructure and inter-site connectivity is inherent (all phones register to the same platform). Adding a new site means deploying phones and network infrastructure at that site, not deploying and integrating another PBX.

On-premises PBX deployments become significantly more complex in multi-site because you are now managing multiple PBX systems, inter-site trunking, dial plan synchronization, and distributed administration. The operational cost of multi-site on-premises voice is substantially higher than multi-site hosted voice, and for most MSP-managed clients, the hosted model is the better fit.

The exception is when the client has requirements (survivability, data sovereignty, compliance) that mandate local infrastructure. In those cases, the additional complexity is the cost of meeting the requirement.

Next up: Contact Centers and High-Volume Voice, covering what happens when a client's needs go beyond a phone system into queue management, agent metrics, and call recording.