Multi-Branch Phone Systems: Central Control With Local Survivability

A multi-site phone system breaks at the branch, not at the headquarters. Centralising call control gives you one place to change routing, numbering and recording policy, but the site that loses its WAN link is the site that stops answering, and no amount of central administration fixes that on its own.

Definition: A multi-site phone system, also sold as a multi-site VoIP deployment or a branch office phone system, spans a headquarters and one or more remote locations where numbering, routing, recording and management are administered as one system, but every site is expected to keep serving calls when its connection to the core is lost.

The Centralisation vs Local Control Trade-off

Almost every multi-site buyer wants the same two things at once: a single point of administration and independent operation at each branch. These pull in opposite directions, and the design work is deciding where to draw the line rather than searching for a configuration that satisfies both.

Centralised control: what it actually buys

Running the call logic in one place gives you consistency that is hard to reproduce site by site. A routing change, a recorded announcement or a permission change is made once and applies everywhere, and the reporting you get afterwards is one consistent set of records rather than a reconciliation job.

• One numbering plan, one dial plan, one set of call-handling rules
• One recording store and one reporting path across all sites
• Configuration changes applied at a single point rather than at each branch
• Substantially less hardware to maintain

The cost sits in the same place. The branch's ability to place and receive calls then depends on a WAN circuit, a router and the health of the system at the core. Every site inherits that dependency, including the site where a broken cable or a carrier outage has nothing to do with the phone system itself.

Local control: what it actually costs

Putting a system at every branch removes the WAN from the critical path for internal calls and lets each site keep an independent outside line if a carrier is present. What you get back in exchange is operational overhead: duplicated hardware, more configurations to keep aligned, more firmware to track, and numbering that has to be coordinated by hand.

This is a real trade and neither side wins it on paper. It gets decided site by site. A two-person branch that only ever places local calls has a different requirement from a regional office that has to answer a queue during a WAN fault.

What Actually Breaks When a Branch Loses Its Link

The useful question is what stops working in the first minutes of an outage, rather than whether the system carries a failover feature on the datasheet. In a typical central deployment the same four things go down together.

• Endpoint registration, because the branch phones register with the core rather than with a local server
• Routing, because dial plans and route tables live at the core
• Shared services such as IVR prompts, voicemail and announcements
• Recording and reporting, because call detail records are written centrally

Outbound calling is the exception worth noting. A branch with an FXO port on a local line can still reach the public network without the WAN, provided the branch holds enough of the number plan to present a correct calling number. That is the whole argument for a local survivability device.

The MA50-LS local survivability branch exchange is built for this failure mode. It is deployed at local offices, buildings or branches so that calls are handled locally when the headquarters server or the cloud/hosted server disconnects, and calling services switch back to the headquarters server or cloud server once the connection recovers. It provides PSTN access through FXO interfaces (2-8) and SIP user registration (50-200), with local features including auto attendant, call forwarding, call transfer, high-speed fax, emergency call and three-way calling.

Read that as a defined scope rather than a licence to remove the branch from the network. MA50-LS keeps a site alive. It does not give that site the full feature set it has under the core, and the two states should not be treated as equivalent.

Designing a Branch Survivability Strategy

The strategy is a decision about which branches need what, expressed as tiering rather than as one standard applied everywhere.

1. List every site and what it does: head office, sales office, warehouse, retail counter, small remote office.
2. Mark the calls that would cause real harm if they went unanswered for the duration of an outage, and separate them from calls that merely slow down.
3. Decide the fallback for each site: local PSTN, a local survivability gateway, or accepting that the site goes quiet and needs an alternative contact route.
4. Decide what the branch must present to the outside world during the outage, and write that number plan down at the branch.
5. Confirm what happens to registrations and to routing when the link returns, then test it deliberately instead of waiting for the first real failure.

Step five is where most designs are untested. A survivability feature that has never been exercised during a maintenance window is a claim rather than a behaviour, so the test belongs in the same calendar as the rest of your change management.

Classifying branches by call criticality

Not all branches need the same treatment, and the distinction is usually commercial rather than technical. A branch that handles customer orders needs a fallback line. A back office that only ever calls another office can wait for the link to come back. Spending local-survivability hardware on the second category is money that buys nothing, and leaving the first category without one is an outage waiting for a carrier maintenance window.

SIP Trunking Between Headquarters and Branches

SIP trunks are how the sites talk to each other, and the trunk design decides how much of your estate depends on the WAN. The OM20G IP-PBX supports headquarters and branch-office communications through SIP-based trunks, and with VoIP it supports free inter-office calls over the Internet or VPN, which makes the quality of the WAN path a voice quality question rather than a purely IT one.

Two trunk topologies dominate. A hub-and-spoke design points every branch at headquarters, which keeps routing simple and central reporting straightforward, but puts the headquarters link on the critical path for every inter-branch call. A mesh or partial mesh lets branches call each other directly, which takes the core out of that path, at the cost of more routing tables to maintain and more places for a numbering mistake to hide.

Where an SBC earns its place

A session border controller is not automatically required, and adding one adds a box, a hop and a troubleshooting layer. It earns its place when the sites genuinely differ: different carriers, different signalling variants, different codec sets, or a network boundary that needs a controlled crossing point.

The SX100 session border controller is positioned for small and medium-sized enterprise branch interconnection. It supports branch networking and cross-network interoperability, with header field customisation, codec conversion, protocol conversion, DTMF mode conversion, call recording, voice quality monitoring, and trunk redundancy and load balancing. It handles 1000 user registrations, 120 concurrent sessions and 70 media transcoding routes, and covers G.711 (A-Law and U-Law), G.723.1, G.729a/b, iLBC, G.722, G.722.1, G.722.2, AMR, H.264 and H.265 over IPv4/IPv6, with SIP/IMS, TLS/SRTP, RTP/RTCP and MSRP supported.

Two details matter more than the feature list in practice. Trunk redundancy and load balancing decide whether a carrier outage at one site becomes a site outage or merely a reroute. And transcoding is a finite resource: a design that transcodes every call across every link will exhaust it, so the routing rules should keep native codec matching wherever the network allows it.

Numbering and Routing Design Across Sites

Numbering is where multi-site deployments usually fail first, because a numbering plan that works in one site assumes that a single system holds all of the state.

Number plan conventions that survive a site move

Give every site an explicit code in the internal numbering plan and make the mapping from site code to destination rule predictable enough to be written down. A branch operating in degraded mode will be working from that document rather than from a live route table, so the document has to be short and current.

• Keep internal extension numbers unique across the whole estate, not per site, so a misrouted call is obvious rather than ambiguous.
• Hold the external number presented for each site at the site, so a degraded branch still presents the right caller identity.
• Separate the digits used for site-to-site dialling from the digits used to reach the public network, so failover routing can be rewritten without touching customer-facing numbers.
• Mirror route tables to whatever device holds the fallback, because a branch with PSTN access but no local number plan can place calls that fail at the carrier.

Where a site carries more than plain telephony traffic, such as IMS and ISDN PRI (30B+D) conversion, several carriers or heavy number translation, the routing and translation rules become a product requirement in their own right. The OM1000-TE media gateway covers that layer with IMS/SIP and ISDN PRI (30B+D) protocol conversion, up to 120 concurrent calls, 500 routing and number translation rules, 512 SIP trunk account registrations, redundant network ports and power supplies, and 6000 MIPS of DSP processing capacity. Whether it belongs at headquarters or at the branch depends on where the carriers actually terminate.

A Reference Architecture for Multi-Branch Voice

A workable multi-branch design has four layers, and each of them can fail on its own.

1. Core call processing at headquarters, sized on the whole estate rather than on the head office alone.
2. A branch edge layer that holds the site's outbound access and, where the tiering calls for it, a local survivability device.
3. A controlled crossing point between the corporate network and the service provider, with an SBC where the networks differ.
4. Central administration, recording and reporting, with local visibility into branch activity even when the central console is unreachable.

Core selection becomes a lookup once the estate numbers are known, because the OM series covers a wide range of sizes on a common feature set.

Two features on the smallest model deserve attention in a branch context. The OM20G's built-in analog gateway modules cover PSTN and analog terminal access where a branch still has copper on the wall, and its hotel application middleware shows the same platform being used in environments where the phone system is one part of a larger application stack rather than the whole of it.

Running the Network Day to Day

A multi-site deployment introduces a specific operational risk: configuration drift. When each branch can be edited locally, the estate slowly diverges, and the divergence usually surfaces during an incident, at the worst possible moment.

Central administration through the New Rock unified management system addresses the routine part of this. UMS provides unified management and remote operations for the OM series IP-PBX and the MX series VoIP gateways, so a change can be pushed and verified from one place instead of visiting site by site. It does not remove the need for a written baseline, but it makes enforcement realistic.

Two operating habits repay the effort. Keep the branch configuration under the same change control as headquarters, even when the site is small enough that nobody thinks of it as a system. And schedule a survivability test at a fixed interval: disconnect the branch uplink on purpose, place and receive calls, then restore it and confirm that registrations and routing return to the core rather than staying local.

Multi-Branch Phone System FAQ

Does every branch need its own phone system?

No. Most estates work well with a central PBX plus a survivability device at the sites that need one. Give a branch its own full system only when it has a call volume, a staffing pattern or a local requirement that justifies it.

What happens to calls in progress when a branch loses its WAN link?

With a survivability gateway in place, the branch keeps serving calls locally and the gateway switches services back to the headquarters server or cloud server once the connection recovers. Without one, established calls can be lost and incoming calls to that site are refused until registration is restored.

Can one central PBX serve branches in different countries?

It can, and it is common practice. The complications are regulatory and commercial rather than technical: local carrier requirements in each country, the number format presented to callers, and whether the site needs a local emergency call path. Confirm these per country with the local provider instead of assuming the headquarters configuration carries over.

How many trunks does a branch need?

Enough to carry the site's concurrent calls plus whatever the carrier requires for availability, and enough for the failover traffic it may have to absorb. Rather than guessing, size the branch against the concurrency it has to sustain, then confirm that the trunk layer supports the redundancy you intend to rely on.

Is local survivability worth the extra hardware?

It is worth it where an outage at that site would cost more than the device, and it is not worth it as a default across every site. It is worth nothing at all if the fallback behaviour is never tested. Decide per site, then test.

Conclusion

Multi-site phone systems fail at the edges, so design for the edge. Central administration, one numbering plan and one recording store are worth having, and the MA50-LS, the SX100 and the OM series IP-PBX cover the branch edge, the network boundary and the core respectively. The next step is concrete: classify each branch by call criticality, decide its fallback, write down the number plan it holds during an outage, and schedule the first failover test before the change calendar fills up.