Current Location ：
Branch Office Voice: Designing for Sites With No IT Staff
The head office model of voice does not transfer to branches. At head office there is someone who can check a switch, restart a device, or look at a log. At a branch there is a shop manager, a receptionist, or a warehouse supervisor, and the instruction 'restart the gateway' is either impossible or dangerous. Designing branch voice means designing for an environment where the only available intervention is unplugging something, where support arrives remotely or not at all, and where a failure that requires a specialist visit costs a day of degraded service. This article covers survivability, remote supportability, and standardisation.
Decide What Must Work When the Link Is Down
The first design question is not about features; it is about degradation. If the connection to the central platform or the internet fails, what should the branch still be able to do? Different organisations answer differently, and the answer determines what equipment and configuration the site needs. A site that must keep taking internal calls and placing emergency calls needs something local. A site that can operate on mobiles for an hour needs less.
| Scenario | What the site needs | Design implication |
|---|---|---|
| WAN drop, internal calls only | Local call control between handsets at the site | Local survivability capability at the branch |
| WAN drop, external calls needed | A local path to the public network | Local trunk or cellular fallback provisioned and tested |
| WAN drop, emergency calls required | Local emergency routing that does not depend on the centre | Emergency behaviour verified at the site, not assumed |
| Total power loss | A documented procedure, usually mobile-based | Staff know what to do without calling anyone |
Make Recovery Something Anyone Can Do
The best branch recovery procedure fits on one card and involves actions a non-technical person can perform safely: check the light, wait a defined period, power the device down and up in a stated order, and call a number if it does not recover. Procedures that require interpretation, or that risk losing configuration if performed in the wrong order, will either not be followed or will be followed badly at the worst time.
- Write the procedure for a non-technical reader, with no unexplained terms
- Specify the order of any power operations, because order matters for recovery
- State how long to wait before each step, so nobody restarts too quickly
- Include what to do if recovery fails, including who to call and what to tell them
- Put the card physically at the site, not only in a document nobody opens
Standardise Aggressively
Branch estates become unmanageable when every site is slightly different: a different handset mix, a slightly different dial plan, an extra device added for a local reason. Standardisation is what makes remote support possible, because it means the person diagnosing a fault already knows what is at the site. Allowing local exceptions is sometimes necessary, and every exception should be recorded, because unrecorded exceptions are the ones that consume the next incident.
Remote Visibility Before Remote Support
Remote support depends on seeing the site. Confirm before deployment that someone at the centre can observe device state, registration status, and call behaviour at each branch, and that this visibility survives a WAN failure rather than depending on the same link that failed. Where monitoring depends on the path it is meant to monitor, a branch outage is discovered by customers rather than by dashboards.
Redstone Approach
Redstone supports branch and remote-site voice design on the REX IP-PBX platform with RGW gateway lines and EGW-series cellular options where local path diversity is needed. Our teams can help define survivability requirements per site type, standardise device and dial plan templates, document recovery procedures written for non-technical staff, and verify emergency behaviour at each location. Specific resilience capabilities are scoped in writing against your site list and carrier arrangements.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
