Emergency Calling in Teams — Ray Baum’s Act Compliance Explained
If someone calls 911 from your Teams Phone deployment, emergency responders need to know where that person actually is. Not your headquarters address. Not your billing address. Where the person is physically located at the moment they dial.
That is what Ray Baum’s Act compliance is about. Everything else in the configuration exists to support that outcome.
What Ray Baum’s Act Requires
Ray Baum’s Act expanded emergency calling requirements for modern phone systems — including VoIP and cloud calling platforms like Microsoft Teams. The law requires organizations to provide a “dispatchable location” when a user places an emergency call.
A dispatchable location isn’t just a company address. It means information that helps responders physically locate the caller — street address, floor, suite, wing, office number, or any combination that narrows down where in a building or facility someone actually is.
This requirement exists because traditional desk phones were physically tied to buildings. When a landline called 911, the carrier could associate that number with a specific address and it was almost always accurate. Cloud voice systems broke that assumption entirely.
A Teams user today might be at the main office, a satellite office, a client site, a hotel room, or their home. They might be using a laptop on Wi-Fi, a desk phone in a conference room, or the Teams mobile app on a cellular network. Emergency services can no longer assume the caller is at a fixed location — and that’s exactly the problem Ray Baum’s Act requires organizations to address.
How Teams Handles Emergency Calling
Teams Phone handles emergency calling through a combination of emergency addresses, network topology mapping, dynamic location detection, and emergency calling policies. These four pieces work together to answer one question: when this user dials 911, what location information do we send?
Emergency addresses are the physical locations you register in the Teams Admin Center. Each address needs to be validated against the national emergency address database — unvalidated addresses may not route correctly to the right Public Safety Answering Point (PSAP).
Network topology mapping is how Teams associates a user’s current network connection to a known location. You define subnets, Wi-Fi access points, switches, and ports in the Teams network topology settings, and map each to an emergency address. When a user connects from that network, Teams identifies their location automatically.
Emergency calling policies control the behavior when a 911 call is placed — including which number to dial for emergency services, whether a notification is sent to a security desk or designated personnel, and how external transfer to the PSAP is handled.
Emergency call routing policies determine which PSTN route handles the 911 call. For Microsoft Calling Plans and Operator Connect, Microsoft manages this routing. For Direct Routing deployments, you own the routing configuration — and in most cases this requires integration with a certified E911 provider like Intrado or Bandwidth to handle dynamic location data and PSAP routing correctly. For a full breakdown of what Direct Routing emergency calling requires, see Operator Connect vs Direct Routing — How to Choose for a Real Customer.
Dynamic Emergency Calling
Dynamic emergency calling is the mechanism that makes location-aware 911 work for mobile users inside your facilities.
When a user connects to a network that’s been mapped in your Teams topology, Teams automatically associates their session with the corresponding emergency address. If they dial 911, that location is sent with the call — no manual input required from the user.
A practical example: a user carries their laptop from their desk on Floor 2 to a conference room on Floor 4. If both subnets are mapped in your network topology with accurate floor-level addresses, Teams will use the correct location for whichever subnet they’re connected to when the call is placed. The user doesn’t have to do anything.
Dynamic location detection works through subnet mapping, Wi-Fi access point identification, and switch/port mapping. The more granular your topology, the more accurate the location data. For large multi-floor facilities, floor-level or wing-level subnet segmentation makes a meaningful difference in how precisely you can report location to emergency services.
Remote Workers
Remote and hybrid workers are where emergency calling compliance gets genuinely difficult, and no system handles it perfectly.
A remote worker dialing 911 from their home office is the clearest case — their home address needs to be registered as an emergency address, and Teams needs to either detect it automatically or prompt the user to confirm it. Most organizations handle remote workers through a combination of:
- Allowing users to manually set and update their home office emergency address in the Teams client
- Applying a remote worker emergency calling policy that routes calls appropriately
- Prompting users to confirm their location when they connect from an unrecognized network
The Teams client will prompt users to confirm their emergency address when it can’t determine location automatically — but only if that feature is configured. If it isn’t, the call may route with an incorrect or missing location. Getting this configuration right before a large hybrid deployment goes live is worth the time it takes.
Emergency Notifications
One feature that often gets overlooked during initial deployments is emergency call notification.
Teams can be configured to alert a security desk, front desk, or designated personnel whenever a 911 call is placed from within the organization. The notification includes the caller’s identity and their reported location. This gives on-site staff the ability to respond immediately — direct someone to the caller’s location, meet emergency services at the entrance, or coordinate a response before responders arrive.
This is configured in the emergency calling policy and requires a Teams Phone license on the notification target. For organizations with a physical security desk or reception function, this is a meaningful safety improvement — and in some industries it’s a compliance requirement, not just a best practice.
Direct Routing: Additional Requirements
Direct Routing deployments have emergency calling requirements beyond what Microsoft Calling Plans and Operator Connect need.
Because Microsoft doesn’t control the PSTN path in a Direct Routing environment, you’re responsible for ensuring 911 calls route correctly to the right PSAP and that accurate location data travels with those calls. In most cases this means integrating with a certified E911 provider — Bandwidth, Intrado, and West (Synacor) are common choices.
The E911 provider sits between your SBC and the emergency call routing path. It handles PSAP database lookups, dynamic location data, and call delivery to the correct local 911 center. Without it, 911 calls in a Direct Routing deployment may route to a centralized PSAP rather than the local one, or may route with no location data at all.
If you’re building a Direct Routing deployment, emergency calling compliance is not something to wire in at the end. It needs to be scoped, priced, and integrated from the start. For licensing context on what a Direct Routing deployment requires end to end, see Teams Calling Licensing Templates by Customer Profile.
What Admins Actually Need to Configure
For most Teams Phone deployments, the emergency calling configuration comes down to five things:
1. Emergency addresses — register and validate every physical location where users work. Floor and suite level detail matters for large buildings.
2. Network topology — map subnets, Wi-Fi access points, and switch ports to emergency addresses. The granularity of this mapping directly determines location accuracy for on-site users.
3. Emergency calling policies — configure notification targets, external emergency number, and any site-specific behavior. Assign policies to users.
4. Emergency call routing policies — for Direct Routing deployments, configure the routing path and integrate with your E911 provider. For Calling Plans and Operator Connect, Microsoft handles routing.
5. Testing — test 911 routing before go-live. Most carriers and E911 providers have test procedures that don’t dispatch actual responders. Use them.
What Goes Wrong
Using only the corporate HQ address. If all emergency calls route with the headquarters address, responders may go to the wrong building. This is the most common and most dangerous configuration mistake.
Ignoring remote workers. Remote and hybrid users still need emergency location considerations. An unconfigured remote worker policy means calls may route with no location data or an address that hasn’t been updated since the deployment was first built.
Skipping the notification configuration. Emergency call notification is often treated as optional. For any organization with a physical security presence, it shouldn’t be.
Treating Direct Routing like Calling Plans. Emergency calling for Direct Routing requires active work — an E911 provider, a routing configuration, and testing against that provider’s system. It doesn’t come pre-wired.
Never testing. Emergency calling should be tested before go-live and after any significant network or location change. A deployment that routes everything else correctly can still have broken emergency routing.
The Bottom Line
Ray Baum’s Act compliance in Teams is not a checkbox exercise. It’s the configuration that determines whether emergency services can find your users when it matters.
Most deployments aren’t complicated. A handful of office locations, accurate subnet mapping, properly configured policies, and a test run before go-live covers the majority of organizations. Where it gets complex — remote workers, Direct Routing, large multi-site deployments — the complexity is proportional to the operational reality, not to any quirk in Teams.
Get the location data right, configure the notification, test the routing. That’s the job.