Why 911 compliance for an open source PBX starts with the call path, not the handset
US 911 compliance for an open source PBX is a build and evidence problem that starts in the call path, covering direct dialing, notification and location. Kari's Law requires that staff can dial 911 without a prefix and that a notification reach a designated internal point when the call is placed. RAY BAUM's Act requires that the call carry a dispatchable location, an address detailed enough for responders to find the caller inside a building. Asterisk and FreePBX make these behaviors configurable, which is the core of the work: your team owns the dial plan that routes emergency digits, the SIP trunks that carry the call to the carrier, and the location data attached to each extension. A commercial system often hides these pieces behind a vendor. With open source, you must design them, test them and be able to show the results.
The deployment pattern decides how much of the location problem you carry. A PBX serving fixed phones at known sites, with trunks that pass the caller's location to the emergency service provider, fits most readily, because each extension can be mapped to a building and floor. Hosted Asterisk in your own cloud account can follow the same design if the carrier's emergency routing is confirmed in writing. Softphones and home desk phones are harder because the device can move between networks, so location must be updated by the user or derived from registration data, and that design needs its own review. Multi-site and survivable designs add another question: which site's trunk handles an emergency call when a WAN link fails. Confirm each path with your carrier and counsel before cutover.
Plan the evidence from the start. Keep a current location register for every extension, an export of the dial plan, a log of test calls with timestamps and outcomes, and a record of who receives notifications and how those recipients are verified. Ask any implementation partner to deliver these artifacts with the system. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and it does not replace advice from counsel or your 911 service provider. Your first decision is which SIP trunk and emergency provider you will use, because every later configuration depends on that answer.
Which 911 requirements apply to an Asterisk or FreePBX build and what each means for the design
This table maps the main 911 obligations under Kari's Law and RAY BAUM's Act to the parts of an Asterisk or FreePBX build they touch. Read each row as a design decision: what the rule asks for in general terms, what the build must do, and what evidence to keep. Confirm current FCC rule details with counsel or the regulator before finalizing the design.
| Requirement | What it means for the build | Evidence to keep |
|---|---|---|
| Direct 911 dialing without a prefix | Dial plan must route 911 directly to the local PSAP trunk without an outside-line code, and must work on every phone type the site uses. | Dial plan export and test call logs for each site and extension class |
| Central notification for multi-line systems | Notification to a designated on-site location, such as a front desk or security console, when 911 is dialed. Confirm the notification channels and recipients required for each site. | Notification configuration, test records and sign-off from the site owner |
| Dispatchable location for fixed phones | Each fixed endpoint needs a location record that is passed with the emergency call. Map extensions, ports and subnets to civic addresses and keep them current after moves. | Location database export, change log and periodic reconciliation records |
| Dispatchable location for non-fixed phones | Mobile or relocatable endpoints need a method to update location, such as user entry or a supported location service. Confirm which methods the rule accepts for your endpoint types. | Location update procedure, user acknowledgment process and sample records |
| Off-premises and remote phones | Softphones and home phones registered from the internet need a location method that works away from the office network. Confirm the current FCC requirements for remote users with counsel. | Remote user location policy, provisioning records and registration logs |
| Testing and validation | Calls to 911 must be tested after changes to trunks, dial plans or locations. Coordinate test calls with the PSAP and the carrier so they are not treated as live emergencies. | Test plan, test call results, dated sign-off and change tickets |
| Recordkeeping and audit trail | Keep records of configuration changes, location updates and test results so the organization can show what was in place on a given date. | Configuration backups, change history and retention schedule for these records |
| Coverage of all sites and carriers | Each site, trunk and failover path must meet the same 911 rules. Confirm how survivability or backup routing preserves location and notification behavior. | Site inventory, trunk routing tables and failover test results |
Which call, location and notification data the 911 path touches
The 911 path in an Asterisk or FreePBX deployment touches four kinds of system: the trunks that carry the call, the dial plan that decides where it goes, the location source that tells the emergency center where the caller is, and the notification endpoints that alert on-site staff. The dial plan is the control point. Emergency numbers should match a dedicated context ahead of any general outbound rule, so that 911 is never blocked by a restriction, a prefix requirement or a queue. Confirm with your trunk provider which path the call takes, because some carriers route emergency calls through their own networks and the PBX configuration must match what the provider expects.
Location data lives in one of two places. For fixed phones, it is typically a location record tied to the extension, the registered device or the port on a switch, held in the emergency provider's database or in a service your PBX calls. For softphones and other non-fixed endpoints, the location depends on what the device or user reports at registration or at the time of the call, so the PBX's own registration records and any user-entered address become part of the evidence. Call detail records, notification logs and location updates each hold personal and operational data about staff and callers. Decide in advance who can read them, usually a small group in telecom and security administration, and restrict access to the database, the logs and the file system that stores them.
Retention is a separate question. Call detail records and recordings may fall under records rules that apply to your sector or contract, and those rules can be longer or shorter than the 911 evidence you keep for testing. Confirm retention periods with your legal, compliance and records owners before you configure log rotation or backups, and note that emergency call records that must be produced to a dispatch authority may need to survive a shorter default purge. Document where each record type is stored, how it is protected and when it is deleted.
How deployment constraints change the 911 design
On a single site, the Asterisk or FreePBX server, the local network and the trunk usually sit behind the same firewall and under one administrative team. The 911 route is decided inside your own dial plan, and dispatchable location is usually a registered civic address tied to each extension, endpoint or port. Because you control every hop, the design question is whether the address records and the emergency route stay accurate as people and equipment move.
- Location source: Each extension or endpoint carries a civic address record, and that record must change whenever a desk, room or floor changes.
- Route decision: The 911 pattern should be matched before outbound rules, least-cost routing or any catch-all pattern, so no other rule can take precedence.
- Trunk path: Confirm with your carrier whether emergency calls leave on the primary SIP trunk or a separate emergency path, and whether the carrier passes location with the call.
- Central notification: Kari's Law notification is built as a PBX-generated alert to a designated internal recipient, so the alert path itself must be configured and tested.
Before go-live, check that every extension resolves to a current address and that a test call from each building produces the expected location record and alert.
When each site has its own trunk or local gateway, the 911 route is usually decided at the site where the call starts, even if one central Asterisk server handles call control. A phone at a branch must produce that branch's location, not the location of the head office where the server runs. The main risk is a split design where a central dial plan sends emergency calls out through a trunk that is far from the caller or is unavailable during a WAN outage.
- Site-level routing: Emergency calls should exit through the local trunk for the originating site, with the dial plan confirmed for every site.
- Location tied to site: Address records should follow the site subnet, port or registration context so a phone that moves between sites is identified correctly.
- WAN failure behavior: Local survivability must still route 911 when the link to the central server is down, and this should be tested by cutting the WAN in a controlled window.
- Consistent notification: The central notification recipient list must cover every site, including sites with no on-site staff.
- Number moves: When a number or extension moves between sites, the associated location record must move with it.
Before cutover, test a 911 call from each site under normal conditions and during a simulated WAN failure, and record the location and route for each result.
In a cloud-hosted design, call control runs in a cloud account, but the phones, users and often the trunks are in physical locations you do not operate. The cloud region of the server does not define the caller's location. Dispatchable location still comes from the address records held for each endpoint, and the emergency route depends on how the trunk provider and the emergency service path handle the call. Responsibility is split between you, the hosting team and the carrier, so the handoffs need to be written down.
- Location from endpoints: Civic addresses are attached to each registered endpoint or DID, since the server has no physical knowledge of where a phone sits.
- Carrier path: Confirm with the carrier whether emergency traffic enters the public network through its own infrastructure and how it delivers location.
- Trunk connectivity: If trunks terminate on an on-premises session border controller, the 911 route depends on both the cloud dial plan and the local gateway.
- Failover: Document what happens during a cloud or region outage, including whether on-site or mobile fallback is available.
- Administrative access: Changes to emergency routes and address records should be restricted, logged and reviewed like other telephony configuration.
Before relying on the design, confirm each handoff in writing with the carrier and hosting provider, and run a test call from each physical site.
Softphones and desk phones on home broadband register from networks you do not control, and the caller's location changes whenever staff move or travel. The PBX can still decide the route, but the location is only as good as the address the user or administrator last recorded for that registration. Registration loss, NAT problems and internet outages can also stop a softphone from reaching the server at all, which makes fallback planning part of the 911 design.
- Registration-based addresses: Capture a civic address for each softphone or home desk phone at provisioning, and make it visible to the person responsible for updates.
- Address changes: Establish a process for staff to update the address when they move or change networks, and confirm whether your tooling supports prompts or self-service updates.
- Registration loss: Monitor for softphones that drop registration, because an endpoint that is not registered cannot place a call through the PBX.
- Fallback devices: Document that a softphone may be unavailable during an internet outage, and tell staff what alternate device they should use for emergencies.
- Remote testing: Test 911 from representative home networks and from a mobile connection, and record the location delivered on each test.
Ask counsel to confirm your obligations for off-premises staff, and retain the test records with the address management process.
Which open source platforms fit a compliant 911 design and why
A compliant 911 design for open source telephony is assembled from several components, not installed as a single product. Asterisk carries the emergency routing logic, FreePBX administers it, and notification and location services are added around them. Each component needs its own confirmation of what it does, how it is tested, and what evidence it leaves behind.
Asterisk as the call engine
Asterisk holds the dial plan, so it is where direct 911 dialing without a prefix must be built and tested. Your team or partner should confirm how the dial plan matches 911 and 933 test calls, how emergency calls bypass any outbound restrictions, and how calls from every trunk and endpoint reach the same emergency path. Each trunk and SIP route should be traced in test calls, not assumed from configuration files.
FreePBX as the administration layer
FreePBX provides the web administration, extension management and module set on top of Asterisk. Module choices matter for 911 because emergency routes, outbound route priority and location fields are set through the interface, and changes made there can override dial plan logic. Confirm which modules your build uses, which are community supported, and which version pairs with your Asterisk release before cutover.
Central notification components
Kari's Law requires that a 911 call from a multi-line system can trigger notification to a designated person on site, often a front desk or security desk. Open source builds usually add this with an Asterisk dialplan step that sends an SMS, email or paging message, or with a notification service connected to the PBX. Confirm the delivery path, the fallback if the message fails, and the record kept of each notification.
Dispatchable location services
RAY BAUM's Act requires dispatchable location, meaning a street address plus additional information such as floor or room, to be delivered with the 911 call. Location for fixed phones can be stored in the PBX, while non-fixed and remote phones need a method to report location at the time of the call. Ask any location vendor to show which data is passed in the SIP signaling, how updates are made when a softphone moves, and how the location is logged.
Test and evidence tooling
A 911 design is only as good as its test record. Build a repeatable test plan covering direct dialing, notification, location delivery and failure cases, and keep call detail records, configuration exports and test results together. Confirm that logs from Asterisk and FreePBX are retained long enough to answer a regulator or a public safety question, and that changes to the emergency routing are tracked in version control.
Asterisk upgrade planning
Asterisk publishes a lifecycle, and the emergency routing you test today can change with a new release, a FreePBX update or a patched module. Plan upgrades so that 911 tests are repeated after each change to the engine, the administration layer or the location and notification components. Confirm the current support status of your Asterisk version with the project's published lifecycle before you commit to a design.
How to roll out and test 911 routing before go-live
The rollout sequence confirms that every phone can reach 911 directly, that the right people are notified, and that each caller's dispatchable location arrives correctly, with test evidence kept for the handover file.
Scope locations and phone types
Your team and DeployOpen list every site, floor and building, along with each phone type in use: desk phones, softphones, analog devices such as elevator or fire panel lines, and phones used off premises by remote staff. Each entry is tied to a registered address and a responsible owner. The output is a signed inventory that shows which devices need location handling and which phone numbers route to which sites. The step is done when no endpoint in the inventory lacks a location source.
Design the dial plan and location method
The team designs how 911 is dialed, from which extension ranges and trunks, and whether any prefix or dialing habit could delay the call. It also selects the method that supplies dispatchable location for each phone type, such as a location database tied to the carrier or a per-port or per-subnet mapping for fixed phones, and a method for non-fixed and remote phones. Confirm each option with the trunk provider and the 911 service provider in writing. The output is a design document that the carrier and the local public safety answering point, where permitted, can review.
Build and configure routing and notification
DeployOpen builds the emergency dial rules in your Asterisk or FreePBX configuration so that 911 bypasses any outbound prefix, restricted dialing or least-cost routing. Notification rules are created to alert the designated staff by a channel that works outside business hours, such as a page, email or text, and the notification content includes the caller's extension and location. Changes are made under version control and peer-reviewed. The step is complete when the configuration matches the approved design and each rule has a named test case.
Run controlled live test calls
Test calls are placed from each phone type and location in the inventory, coordinated in advance with the carrier and, where the local rules permit, with the public safety answering point so that call-takers know a test is underway. For each call, the team records whether the call connected directly, whether notification fired, which location was delivered and how long it took to appear. Failed calls are fixed and retested. The output is a test log with timestamps, results and the person who verified each one, and the step closes only when every test case has a passing result.
Test failure modes and notification gaps
The team tests what happens when things go wrong: a trunk outage, a location update that has not synchronized, a remote phone outside the office network, and a notification recipient who does not answer. Each result is compared with the expected behavior in the design. Where a failure has no automated fallback, the design is updated with a manual procedure and the owner is named. The output is a list of accepted residual risks, approved by the customer's compliance or security owner before go-live.
Hand over documentation and evidence
DeployOpen compiles the handover file: the inventory, the approved design, configuration exports, the test log, the residual risk list, and the procedures for moving a phone, adding a site or changing a trunk, which must trigger a location update. Staff who maintain the system are trained on the notification path and on how to report a change. The evidence supports your own compliance review; it is not an audit report or certification. Confirm with your legal and compliance team which records they need to retain and for how long, and ask the partner to schedule a repeat test after any significant change.
Which evidence proves the 911 configuration works and which component produces it
This table maps the records an assessor or regulator is likely to ask for to the system that produces each one in an Asterisk or FreePBX deployment. Use it to plan what to keep, where it lives and who signs off. Whether any set of records is sufficient is a decision for the auditor, the regulator or the authority having jurisdiction, so confirm scope with them before relying on it.
| Evidence | What it shows | Produced by |
|---|---|---|
| Signed configuration baseline | The approved 911 dial plan, trunk routing and emergency numbering as of a given date | Version-controlled Asterisk and FreePBX configuration, approved in a change record |
| Dial plan exports | That 911 and 933 routes point to the intended emergency trunk and are not overridden by other contexts | FreePBX configuration backup and Asterisk dialplan output taken at each change |
| Test call records with timestamps | That a test call to 911 or a test number reached the intended trunk and route, and when | Asterisk logs and call detail records, plus the tester's signed test log |
| Location update logs | That the dispatchable location sent with each call matches the registered location for that phone | Location or registration records from the phone system and the emergency location provider, confirm with the provider's documentation |
| Notification test results | That on-site staff receive notification when 911 is dialed, and how quickly, as tested | Notification system logs, paging or email delivery records and a signed test sign-off |
| Change records | Who changed emergency routes or location data, what changed and why, and who approved it | Ticketing or change management system linked to configuration commits |
| Periodic re-test reports | That 911 routing and location still work after upgrades, moves, new phones and carrier changes | Scheduled test plan results recorded in the ticketing system, with logs attached |
| Off-premises and remote phone records | How registered remote and softphone users provide location, and how changes are verified | Provisioning records, softphone registration logs and user location update records |
What buyers ask about 911 compliance for open source PBX before hiring help
What does a partner work package for 911 compliance actually cover?
A partner work package usually covers the design and configuration of direct 911 dialing in the Asterisk or FreePBX dial plan, the notification path to a designated staff group, the dispatchable location method for each phone type, and the test plan with its evidence. Effort is driven by the number of sites and buildings, how many floors or rooms need distinct location data, whether remote and softphone users are in scope, how many trunks and carriers are involved, and how much of the existing dial plan has to be reviewed. The written scope should list each of these items and state what the client must supply. Ask the partner to name every deliverable, including the test records and the configuration backup, before work starts.
Can our internal team handle 911 compliance for the PBX alone?
Some internal teams can, especially when they already run Asterisk or FreePBX in production, have a clear owner for telecom regulatory duties, and can reach the carrier and the local public safety contacts. The work is less about the dial plan syntax and more about proving that the design works across every site and phone type, and keeping that proof current. Teams that lack recent telephony testing experience, or that must cover many sites, often use a partner for the design review, the test plan, or the documentation, and keep operations in house. Decide which parts you own before you start: the carrier relationship, the location database, the test calls, the sign-off and the evidence file.
How long do 911 testing and documentation usually take?
Duration depends on the number of sites, the number of location-enabled endpoints, how many carriers and trunk paths are involved, and whether test calls can be run in a maintenance window. Testing includes direct dialing from each trunk and extension class, notification delivery to each recipient, location display or delivery for each phone type, and retest after any change. Documentation takes time because the configuration, the test results, the location records and the sign-off must agree with each other. Ask a partner for a timeline built from your site list and test matrix, and confirm which steps depend on carrier or public safety responses that you do not control.
What do we need to provide before the engagement starts?
The partner will need a current inventory of sites, trunks, extensions and phone types, including which handsets are fixed, which are non-fixed and which are used remotely. You should provide the carrier contacts and any emergency service provisioning documents, the building and room layouts used for location, and access to the PBX, the trunks and the test phones. Named staff for notification recipients and a change process for moves are also needed. Access to a non-production copy or a maintenance window for live test calls should be agreed in writing. Missing inputs are the most common reason a 911 schedule slips, so confirm each item in the scope document.
How are moves, new phones and site changes handled after go-live?
Every change that alters a phone's location, number, trunk or dial plan can affect 911 behavior, so each change needs a defined owner and a short re-test. Common triggers include a staff member moving desks, a new softphone registration from a home network, a new site, a carrier change, or a new handset model. Your internal process should update the location record before the phone is used, and a retest should cover at least the changed path. Ongoing support can be arranged as a retainer covering change review, periodic test calls and documentation updates, which is usually priced against the expected change volume and the number of sites. Ask the partner how they log changes and how the evidence file is kept current.
What drives the cost of 911 work on an open source PBX?
The main cost components are design and review time, configuration and change control, test execution, location setup, documentation, and any carrier or emergency service provisioning fees that the carrier charges directly. Costs go up with more sites, more buildings or floors that need distinct location data, more remote users, more trunk paths, and more phone types to test. Costs go down when the site inventory is accurate, the dial plan is already clean, and the client can supply records and access promptly. Your one-time costs include the initial design and testing, while recurring costs include change support, periodic retests and documentation upkeep. Ask any partner for a quote that separates these items and states which ones are fixed in the written scope.
Which 911 obligations apply to the PBX and who is responsible for them?
The obligations are set by US federal rules, and the details depend on the organization, the phone types in use and the carrier arrangement, so confirm the applicable requirements with counsel and your carrier before design. Responsibility is usually shared: the organization owns its compliance program and its PBX configuration, the carrier provides the emergency call path, and the implementation partner helps design, test and document the system. Ask the partner which obligations their work package addresses and which remain with you, and get that split in writing.
What evidence should a 911 test file contain?
A useful evidence file includes the design document, the dial plan and configuration backup at the time of testing, a test matrix listing each trunk, extension class and phone type, the dated results with the caller and location details, notification delivery records, and the sign-off by the responsible owner. It should also include the change log and the retest records for later changes. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, so independent auditors and your own compliance function make the final assessment. Confirm with your auditor which records they will request before testing begins.
What to ask an implementation partner about 911 design and testing
Start with the test plan, because a 911 design is only as good as the calls someone has actually placed. Ask the partner to describe how they test direct dialing from every phone type you run: desk phones on the local network, softphones on laptops and mobiles, remote desk phones on home broadband, and any analog or paging endpoints that sit behind the PBX. Ask for the dial plan entries that handle 911 and 9-1-1, the trunk and carrier path each call takes, and whether test calls go to a live emergency center or to a carrier-provided test procedure. Ask how they confirm that a 911 call bypasses any outbound prefix, extension restriction or call-recording rule that would otherwise delay it. Ask for their experience with Asterisk and FreePBX emergency routing, and whether they can show how they built it on a past project without naming the client.
Next, press on location and documentation. Ask how dispatchable location is entered, stored and updated when a softphone user moves between networks, works from home or travels, and who is responsible when an employee does not update their address. Ask who holds carrier and public safety answering point coordination, meaning who files and maintains the registration with the provider, who receives notifications, and who answers the carrier when a location record fails. Ask how each test is recorded (date, phone, route, location presented, result and the person who ran it), where that evidence is kept, and how it is produced for an auditor. Finally, ask how changes are re-tested after a firmware update, a trunk change, a FreePBX upgrade or an Asterisk release move, and what the partner keeps in writing as the client's responsibility, such as keeping location records current and training staff.
