Hands connecting VoIP phone cables for setup

Every VoIP phone system in your business must transmit a validated dispatchable location or an accepted alternative with every 911 call. That is the core requirement under FCC rules, and it applies whether you have five phones in one office or 500 extensions across multiple sites. If your system cannot confirm where a 911 caller is located, you are exposed to both regulatory liability and a genuine safety failure.

Before you read further, take these three steps:

  • Confirm your service type. Is your VoIP deployment fixed (desk phones tied to known addresses) or non-fixed (softphones, remote workers, hot-desking)? The answer determines which location pathway you must support.
  • Request proof from your provider. Ask your VoIP vendor to document how location data is collected, validated, and transmitted to the PSAP on every 911 call. Get it in writing.
  • Schedule a PSAP test call. Contact your local Public Safety Answering Point and arrange a test. If your provider has never done this with you, that is a red flag.

Loop in your IT lead, facilities manager, and legal or compliance contact now. E911 compliance is not a single-department problem.

Key Takeaways

Every VoIP system must transmit a validated dispatchable location or an accepted alternative with every 911 call, and that obligation requires ongoing location management, not just initial setup.

Point Details
Location pathway is architecture-dependent Fixed VoIP requires automated dispatchable location; non-fixed requires it when feasible, otherwise Registered Location or coordinate-based alternative.
Three laws govern MLTS compliance Kari’s Law, RAY BAUM’S Act, and 47 CFR § 9.11 each add distinct obligations for direct dialing, on-site notification, and location transmission.
Documentation is required evidence Labels, affirmative acknowledgement records, and PSAP test logs are compliance artifacts, not optional paperwork.
Location data degrades without process Annual re-validation and change-control workflows prevent the stale-location failures that cause misrouting.
Mavericks Office Solutions manages the full cycle From MLTS mapping and PSAP test coordination to documentation and scheduled re-validation, Mavericks operationalizes E911 compliance for SMBs.

Your 30/90/180-day action plan

First 30 days:

  • Inventory all VoIP endpoints and classify each as fixed or non-fixed.
  • Request location-pathway documentation from your VoIP provider.
  • Confirm Kari’s Law compliance (direct 911 dialing, on-site notification).
  • Distribute E911 limitation advisories and collect affirmative acknowledgements.

Days 31–90:

  • Validate all addresses against USPS or your provider’s validation tool.
  • Build or update your MLTS location map.
  • Schedule and complete PSAP test calls for each physical location.
  • Document all test results and store them with your compliance records.

Days 91–180:

  • Integrate location-update reminders into HR onboarding and annual review workflows.
  • Establish a change-control process that triggers a location review on every extension move.
  • Review your VoIP provider contract for NG911 Phase 1 and Phase 2 readiness commitments.
  • Set a calendar reminder for annual full re-validation of all location data.

Ignoring these obligations creates both a regulatory exposure under FCC rules and a real safety risk: a 911 call that routes to the wrong PSAP or arrives without a location can delay emergency response when it matters most.

Table of Contents

What does E911 for VoIP actually mean? Key terms explained

Before you can audit your system or talk to your vendor, you need a shared vocabulary. These are the terms that appear in FCC rules and vendor contracts, and each one carries a specific operational implication.

Dispatchable location is the civic address of the caller plus enough in-building detail (floor, suite, room) for a first responder to find them without guessing. For fixed VoIP devices, automated dispatchable location is required. For non-fixed devices, it is required when technically feasible. The FCC’s dispatchable location rules set out the full branching logic.

Registered Location is the most recent address a user has provided to their VoIP provider. Under 47 CFR § 9.11, providers must collect this before activating non-fixed service and must give users at least one method to update it at any time.

PSAP (Public Safety Answering Point) is the dispatch center that receives your 911 call. Routing to the correct PSAP, based on the caller’s actual location, is the whole point of the location-transmission requirement.

ALI (Automatic Location Information) is the database lookup that delivers the caller’s address to the PSAP call-taker’s screen. ANI (Automatic Number Identification) is the callback number transmitted alongside the call. Both must reach the PSAP for a compliant 911 call.

PIDF-LO (Presence Information Data Format Location Object) is the XML-based format used to embed location coordinates or civic address data inside SIP signaling. It is the technical mechanism that carries location through an IP network to a PSAP or NG911 Delivery Point.

NG911 (Next Generation 911) is the IP-based emergency communications infrastructure replacing legacy analog 911 networks. As local 911 Authorities upgrade, your provider’s ability to deliver SIP-formatted calls with embedded PIDF-LO becomes a hard requirement.

What does E911 for VoIP actually mean? Key terms explained — overview diagram

Fixed vs. non-fixed: why the distinction matters operationally

Factor Fixed VoIP Non-Fixed (Nomadic) VoIP
Location pathway required Automated dispatchable location Automated dispatchable location if feasible; otherwise Registered Location or coordinate-based alternative
Who updates location Provider/IT at provisioning End user (must have an update method)
Primary compliance risk Stale MLTS mapping after a move User relocates without updating Registered Location
Pre-activation requirement Address validation at setup Registered Location collected before service activates

The practical takeaway: fixed deployments demand accurate MLTS (Multi-Line Telephone System) mapping; non-fixed deployments demand a user-facing update workflow that is simple enough that people actually use it.

How does E911 work with VoIP? Call routing and location pathways

When a VoIP user dials 911, the call does not simply ring a dispatch center. A chain of signaling and database lookups must execute correctly, in sequence, for the call to reach the right PSAP with the right location data attached.

Here is the call flow in plain terms:

  • The caller dials 911 from a VoIP endpoint (desk phone, softphone, or ATA-connected device).
  • The edge device or Session Border Controller (SBC) initiates a SIP INVITE toward the VoIP provider’s network.
  • Location data, formatted as PIDF-LO, is embedded in the SIP signaling or retrieved from the provider’s Emergency Services Routing Proxy (ESRP).
  • The provider routes the call to the appropriate PSAP using a mapping protocol (consistent with the ECRIT framework described in RFC 5012) that resolves the caller’s location to a PSAP URI.
  • The PSAP receives the call with ANI (callback number) and ALI (address) delivered to the call-taker’s screen.

Scenario 1: Fixed MLTS deployment

A law firm with 40 desk phones in a single office building has a fixed VoIP deployment. Each phone is mapped to a specific floor and suite in the MLTS configuration. When any phone dials 911, the system automatically transmits the pre-configured dispatchable location for that extension. The PSAP receives the street address, floor, and suite without any user action. The compliance requirement is met as long as the MLTS map stays current after any office moves or reconfigurations.

Scenario 2: Nomadic softphone user

A sales rep working from a hotel dials 911 from a company softphone. The system cannot automatically determine their physical location. The provider falls back to the Registered Location the user last entered, which may be their home office address. The PSAP receives that address, not the hotel. This is a known limitation of non-fixed VoIP, and it is why the FCC requires providers to notify users about it and why § 9.11 mandates accessible, timely update methods.

PIDF-LO and the NG911 transition

The FCC’s NG911 framework uses a two-phase model. Phase 1 requires originating service providers (OSPs) to deliver 911 traffic to NG911 Delivery Points in IP/SIP format. Phase 2 adds the requirement to embed location using PIDF-LO. Compliance windows open six months after a valid request from a 911 Authority. For enterprise planners, this means your current E911 architecture is a baseline, not a final state. Build your VoIP infrastructure to support PIDF-LO delivery now, so a Phase 2 request does not require a full re-architecture.

What U.S. law requires: Kari’s Law, RAY BAUM’S Act, and FCC obligations

The regulatory framework for VoIP emergency calling rests on three pillars: Kari’s Law, the RAY BAUM’S Act, and Part 9 of Title 47 of the CFR. Each one adds a distinct layer of obligation.

Kari’s Law (enacted 2018) requires that MLTS users be able to dial 911 directly without a prefix or access code. It also requires that a notification be sent to a central location (such as a front desk or security station) when a 911 call is placed from within the system. This applies to any MLTS installed, manufactured, or imported after February 16, 2020.

RAY BAUM’S Act (FCC rules effective January 6, 2021 for fixed systems; January 6, 2022 for non-fixed) extended the dispatchable location requirement to MLTS. Fixed MLTS must transmit automated dispatchable location. Non-fixed MLTS must do the same when technically feasible, or fall back to Registered Location or coordinate-based alternative location.

47 CFR § 9.11 governs interconnected VoIP providers directly. The FCC’s guidance states that interconnected VoIP providers must automatically provide 911, transmit ANI and location to the appropriate PSAP, supply customer notifications and labels, and obtain affirmative acknowledgement from subscribers about service limitations.

Compliance obligation map

Obligation Responsible party Regulatory basis
Collect Registered Location before activation VoIP provider 47 CFR § 9.11
Provide end-user location update method VoIP provider 47 CFR § 9.11
Transmit ANI and location to PSAP VoIP provider FCC E911 rules
Distribute labels and plain-language advisories VoIP provider + subscriber FCC consumer guidance
Obtain affirmative acknowledgement from users VoIP provider + business/subscriber FCC E911 rules
Direct 911 dialing without prefix (MLTS) Business/subscriber Kari’s Law
On-site notification when 911 is dialed (MLTS) Business/subscriber Kari’s Law
Dispatchable location for fixed MLTS Business/subscriber + provider RAY BAUM’S Act
Coordinate NG911 delivery with 911 Authority VoIP provider (OSP) FCC NG911 R&O (2024)

The FCC’s September 2024 Report & Order further establishes that OSPs are presumed financially responsible for transmitting 911 traffic to NG911 Delivery Points unless a local cost-sharing arrangement exists. That cost presumption is worth reviewing with your provider before your next contract renewal.

As 911, both Kari’s Law and RAY BAUM’S Act carry implementation guidance for notifying 911 authorities and meeting direct-dial and dispatchable location obligations for MLTS environments.

Compliance obligation map — overview diagram

What are the biggest operational risks with VoIP E911?

Most E911 failures in business VoIP environments are not exotic. They are predictable, preventable, and disproportionately concentrated in a handful of failure modes.

The highest-impact risks your team should address first:

  • Misrouting to PSAP administrative lines. If ANI is missing or malformed, the 911 call may reach a non-emergency number at the PSAP rather than the dispatch queue. Seconds matter in that scenario.
  • Stale Registered Location. A user who moved offices six months ago and never updated their location will route 911 to their old address. This is the single most common non-fixed VoIP failure.
  • MLTS mapping errors after a move or renovation. Reassigning an extension to a new floor without updating the MLTS location map breaks dispatchable location for that device.
  • Power and broadband failure. VoIP phones go silent when the internet or power goes down. Unlike traditional POTS lines, they do not carry their own power. A backup plan (cellular, UPS, analog backup line) is not optional for life-safety environments.
  • Non-native numbers and porting gaps. Numbers ported from another carrier may carry legacy routing data that does not match your current PSAP. This risk is especially acute during vendor transitions. Reviewing number porting considerations before a switchover can prevent a routing mismatch from going undetected.
  • User relocation without notification. Remote workers and hot-deskers who move between sites without updating their Registered Location create silent compliance gaps.

Consider this scenario: a mid-size professional services firm migrated to a cloud VoIP platform and mapped all extensions to the main office address. Six months later, a remote employee dialed 911 from a home office in a different county. The call routed to the wrong PSAP, which had to transfer the call. The delay was under two minutes, but the firm had no documentation showing it had provided a location update method or obtained affirmative acknowledgement. The incident triggered an internal compliance review.

Pro Tip: Three mitigations that prevent the most common failures: (1) Build a location-update reminder into your onboarding and annual HR workflows so every user confirms their Registered Location at least once a year. (2) Require your VoIP provider to contractually commit to ANI/ALI delivery confirmation and PSAP routing validation. (3) Add a UPS to every VoIP gateway and document your backup calling procedure for power outages.

Step-by-step implementation checklist for VoIP E911 compliance

The end state you are building toward: every 911 call from your VoIP system transmits a validated dispatchable location, or an accepted alternative, to the correct PSAP, with ANI intact and documentation on file. Here is how to get there.

Phase 1: Governance and inventory (weeks 1–2)

  • Assign a named owner for E911 compliance (IT lead or compliance officer).
  • Inventory every VoIP endpoint: desk phones, softphones, ATAs, conference room devices, and fax lines.
  • Classify each endpoint as fixed or non-fixed.
  • Identify all physical locations and sub-locations (floors, suites, wings) where endpoints are deployed.

Phase 2: Address collection and validation (weeks 2–4)

  • Collect a civic address for every fixed endpoint, including floor and suite.
  • Validate each address against the USPS database or your provider’s address validation tool.
  • For non-fixed users, confirm that your provider’s portal or app offers a location update method and test it.
  • Capture the MLTS mapping fields for each endpoint: extension number, physical location, building name, floor, room/suite, and callback number.

Phase 3: Configuration and SIP/SBC setup (weeks 3–6)

  • Configure PIDF-LO or location headers in your SBC or hosted PBX for each extension.
  • Verify that your provider routes 911 calls to the correct PSAP for each location, not a single national routing point.
  • For VoIP systems with multiple sites, confirm that each site’s 911 calls route to the local PSAP, not the headquarters PSAP.
  • Confirm Kari’s Law compliance: 911 must be dialable without a prefix, and an on-site notification must fire when 911 is dialed.

Phase 4: Testing and validation (weeks 5–8)

Testing is where most businesses skip a step. Do not.

  • Contact your local PSAP’s non-emergency line and request a test call. Many PSAPs have a standard test protocol. Ask for it.
  • Place a test call from each physical location (or a representative sample for large deployments). Confirm that the PSAP receives the correct address and callback number.
  • Document the test: date, time, extension, address transmitted, PSAP confirmation, and the name of the PSAP contact.
  • Test the on-site notification (Kari’s Law) by placing a test 911 call and confirming the notification fires at the designated station.

Questions to ask your VoIP provider before signing or renewing:

  • How do you transmit location data to the PSAP? PIDF-LO, ALI database, or both?
  • Do you support automated dispatchable location for fixed endpoints?
  • What update methods do you provide for non-fixed users?
  • Can you provide documentation of PSAP routing for each of our locations?
  • Are you NG911-ready for Phase 1 and Phase 2 delivery?

Phase 5: Documentation and change control (ongoing)

  • Maintain a current MLTS map as a living document. Update it within 24 hours of any extension move, add, or change.
  • Keep affirmative acknowledgement records for every user who received the E911 limitation advisory.
  • Store label distribution records and plain-language advisory copies.
  • Schedule a full re-validation of location data every 12 months, or after any significant office move or VoIP platform change.

How Mavericks Office Solutions operationalizes E911 for SMBs

For most small and mid-size businesses, the gap between knowing what E911 compliance requires and actually executing it is a resource problem, not a knowledge problem. The steps above are straightforward in theory. In practice, they require coordination between IT, facilities, HR, and your VoIP vendor, sustained over time.

Mavericks Office Solutions handles that coordination as part of its managed VoIP and UCaaS service. The workflow follows a defined sequence:

  • Inventory and classification. Every endpoint is cataloged, classified as fixed or non-fixed, and mapped to a physical location.
  • Location pathway design. Based on your architecture, Mavericks selects the appropriate location pathway (automated dispatchable location, Registered Location, or coordinate-based alternative) and documents the decision rationale.
  • Configuration and validation. MLTS maps are built, PIDF-LO or ALI entries are configured, and address validation is run against each entry.
  • PSAP test coordination. Mavericks coordinates test calls with your local PSAP and documents the results.
  • Documentation and change control. All compliance artifacts are maintained: MLTS maps, test logs, affirmative acknowledgement records, label distribution plans, and update-method documentation.
  • Scheduled re-validation. Location data is reviewed on a defined schedule, and any changes to your phone system trigger an automatic compliance check.

Clients typically receive a complete MLTS location map, PSAP test logs, subscriber acknowledgement records, a label distribution plan, and a change-control log as standing deliverables.

To prepare for an intake conversation, have these documents ready: your current phone system architecture diagram, a list of all extensions and their physical locations, your existing VoIP vendor contract, and any prior PSAP test records. That preparation cuts the discovery phase significantly and gets your compliance posture documented faster.

What compliance officers get wrong about VoIP E911

Most compliance officers I work with treat E911 as a one-time provisioning task. They get the addresses loaded at deployment, confirm the system routes to a PSAP, and move on. That approach works until someone moves desks, a new site opens, or a remote employee works from a different state for three months.

The real compliance risk is not the initial setup. It is the gap between what your system thinks is true and what is actually true on any given day. Registered Location data degrades. MLTS maps go stale. Users never update their softphone location because the update process is buried in a portal they have never opened.

My first recommendation: treat location data as a living asset, not a provisioning field. Build the update workflow into your HR onboarding, your annual IT audit, and your change-management process for any office move. The § 9.11 requirement to provide timely update methods is not satisfied by a portal that exists but nobody uses.

My second recommendation: do not skip the documentation artifacts. Labels, plain-language advisories, and affirmative acknowledgement records are required evidence of compliance. A technically correct system with no paper trail is still a compliance failure when an auditor or incident investigator asks for proof. Build the documentation habit from day one, not after an incident.

Mavericks Office Solutions can handle your E911 compliance

E911 compliance for your VoIP system is manageable when you have the right partner handling the configuration, testing, and documentation. Mavericks Office Solutions gives your business a single point of accountability for your entire phone system, from initial MLTS mapping through annual re-validation, with a USA-based help desk that responds in under 12 minutes when something needs attention.

Mavericks Office Solutions

Rather than coordinating between your VoIP vendor, your IT team, and your facilities manager every time an extension moves, Mavericks owns that process. Your PSAP test logs, affirmative acknowledgement records, and location maps stay current without you tracking them manually. For an intake call, have your phone architecture diagram, extension list, and current vendor contract ready.

Schedule a discovery call to get your E911 compliance posture assessed and documented.

Sources

Use these primary sources when building your compliance documentation file. Regulators and auditors expect references to primary authority, not secondary summaries.

When citing these sources in internal compliance documentation, reference the specific section or page number alongside the URL so your evidence trail is auditor-ready.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.