The phone on the desk knew where it was. The cable ran to a specific jack, the jack belonged to a floor plan, the floor plan belonged to a street address. Location was a physical fact. We spent the last decade cutting those wires and replacing them with software clients. A softphone has no jack. What it has is a record in a provisioning system that someone filled out once and nobody has touched since.
The migration from hardware PBX to cloud telephony usually hits a wall when the compliance department asks about emergency calling. The project plan accounts for user training, headset procurement, and SIP trunk cutovers. It rarely accounts for what happens when a remote worker has a medical emergency, dials for help from a laptop, and the dispatch screen displays the address of a corporate data center three hundred miles away.
A remote worker dials the emergency number from a home office. The call routes over the VPN, exits the corporate network through a session border controller in a centralized data center, and hits the carrier trunk. The carrier passes the call to the dispatch center covering the data center’s jurisdiction. The dispatcher receives the corporate headquarters’ billing address. Responders go to an empty building.
To a session border controller, a remote worker in a hotel in London looks exactly like a remote worker in a coffee shop in Tokyo. They are both just an IP address sending encrypted voice packets. Network topology is not geography.
On the corporate network, location discovery works. The softphone checks the local IP subnet, the MAC address of the default gateway, or the BSSID of the Wi-Fi access point. It matches this telemetry to a known corporate location and assigns the physical address. But home networks and hotel Wi-Fi offer almost nothing to discover. When discovery fails, the system degrades to declaration. It looks at the user’s provisioning record. That record was set at onboarding, edited rarely, and owned by whichever team manages the PBX.
Modern clients try to solve this by prompting the user. When the softphone detects an unknown network, it pops up a dialogue box asking for a current emergency location. The employee, three minutes late for a steering committee presentation, clicks dismiss. The client defaults to the last known location: an office building they haven’t visited in years. You cannot mandate a user into caring about their SIP routing profile.
The migration checklist covers voice quality, dial plans, and codec negotiation. Emergency location accuracy from a remote network is usually a line item someone assumes the carrier handles. Sometimes the carrier handles routing but not the address, or the address but not the update workflow. The seam between those two is where the problem lives.
You can test failover, you can test voicemail, but you cannot test an emergency call by making the call. You cannot script automated test calls to a regional emergency dispatch center. An admin tests a softphone from a corporate conference room, sees the right address on the dispatch simulator, and signs off. The test was on the corporate LAN. Nobody tests from a home network because that requires someone to take a laptop off-site and coordinate with a carrier.
Regulators across multiple jurisdictions have been converging on this for years. The specifics differ by country, but the direction is consistent: if a system can place an emergency call, it must provide a dispatchable location, which means a street address and often a floor and suite number. When enterprise voice lived on carrier-managed physical lines, emergency routing was largely the carrier’s problem. With cloud telephony, centralized SIP trunks, and remote workforces, the enterprise owns the routing logic. The liability shifts to the organization that controls the provisioning system.
The engineering for passing this data exists. Modern SIP architecture uses standards to embed XML-formatted location data directly into the call setup messages. The enterprise PBX can generate the correct address. But the address can get lost or rewritten at the boundary between the PBX, the SIP trunk provider, and the emergency services network. The system will confidently send help to the wrong building if the payload is stripped or altered in transit.
Treating emergency location as a configuration task is the root of the failure. It is a record maintenance problem. The address needs an owner and a trigger. Moves, remote-status changes, and office closures must fire an update to the voice provisioning system. If the trigger relies on a user remembering to update their profile, the field is already wrong for someone.
Assume the record is stale until proven otherwise. Pull a sample of remote users and check what address their profile would present. The hit rate on incorrect addresses is usually higher than anyone expects.
Because users will dismiss location prompts, the deployment requires a commercial agreement with an emergency routing provider to catch unmapped calls. When an endpoint is off-net and lacks a verified address, the system routes the call to a specialized triage center. A human operator asks the caller for their location and manually transfers the call to the regional dispatch. This adds seconds to the response time and costs the enterprise a premium per call, but it prevents emergency services from arriving at an empty data center.
Every time a network engineer changes a subnet mask or an employee moves to a new apartment, the provisioning record is one step further from the physical reality of where the phone actually is.