Current Location ：
E911 and Location Routing: Ensuring Emergency Calls Reach the Right Site
On an analog phone line, an emergency call is routed using the address the telephone exchange holds for that line number. VoIP breaks that assumption, because the phone may be a softphone on a laptop, a handset travelling between sites, or a device on a network that has never told the carrier where it is. Emergency calling therefore has to be designed rather than inherited, and multi-site organisations have to think harder than single-site ones.
Why VoIP Changes Emergency Calling
Legacy emergency calling depends on a number-to-address database maintained for the analog network. IP-based calling can deliver calls from devices that have no fixed address at all. The regulatory response in the US under the Ray Baum Act requires interconnected VoIP providers to deliver an accurate registered location with emergency calls and to offer users a way to update that location. In the EU, the emergency number itself is a member-state matter, but the underlying principle is the same: the emergency call must reach the right public emergency answer point for where the caller physically is.
Two Levels of Routing Correctness
| Level | Requirement | Typical failure if missing |
|---|---|---|
| Call routing | Emergency number reaches the correct public emergency answer point | Call misrouted or not connected at all |
| Location accuracy | Caller location reaches the answer point with the call | Police or ambulance dispatched to the wrong address |
| Registered address | Number-to-location record reflects where the service is used | Stale address from a previous tenant |
| User override | User can correct location before or during the call | Uncorrected registered address used as-is |
| Multi-device handling | Devices at different sites route distinctly | All sites treated as one location |
The Multi-Site Problem
A company with five offices in one country may have five numbers, each with its own registered address, and emergency calls route correctly by number. A company with five offices in five different countries has a harder problem: emergency numbers are not portable across borders, and a call placed from the Madrid number may be routed by a network that has no concept of the 112 number there. A company with one number across several sites is the hardest case, because routing by number alone cannot distinguish the sites.
Design Principles for Multi-Site Emergency Calling
- Give each physical site its own emergency-relevant identity wherever the regulatory context allows
- Where a single number spans sites, validate site routing by extension or device, not by dialed number
- Publish a test plan that verifies routing from each site before go-live, not just from head office
- Re-test after any change to numbering, trunking, or carrier configuration
- Document which emergency numbers apply at each site and who published them
- Confirm how location reaches the answer point for remote and softphone users
Softphones and Remote Users Deserve Separate Treatment
A softphone on a home laptop is the hardest case, because the emergency answer point will dispatch to a residential address. Organisations with substantial remote work should establish a policy for remote emergency calls rather than leaving users to guess: whether remote users should use a site number at all, whether mobile-native emergency dialling is preferred on company devices, and what the user is expected to do if they call from an unapproved location.
Carrier and Provider Questions
- Does the carrier support emergency calling on the specific trunk type you are buying?
- Does it support the emergency number or numbers applicable to every country you operate in?
- What location information is delivered with the call, and how current is it?
- Is a registered address required per number, and how is it submitted and updated?
- What is the test procedure for verifying routing before and after a port change?
Redstone Approach
Redstone IP-PBX platforms provide per-site extension numbering and emergency call routing configuration, allowing each site to define its own emergency destinations and test routing independently. In multi-site deployments, Redstone site configuration supports treating each location as a distinct routing domain rather than assuming that a single number implies a single physical location.
Redstone can help map your estate by country and site, identify where a single-number strategy creates routing risk, and define a verification plan covering each site before deployment.
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.
