E911, Kari's Law, and RAY BAUM's Act for Asterisk PBXes

Emergency calling is one of the places where a PBX configuration stops being just a call-routing problem. If someone dials 911 from a desk phone, softphone, hotel room, classroom, warehouse, or remote worker extension, two things need to happen fast: the call must reach the right emergency answering point, and responders must know where to go.

This reference explains how Kari's Law, Section 506 of RAY BAUM's Act, and the FCC's MLTS rules apply to Asterisk multi-line telephone systems. It then turns those requirements into Asterisk design patterns you can actually audit.

Last reviewed: August 1, 2026

What the laws are trying to prevent

The failure mode is simple. A person in distress dials 911 from a phone attached to a business PBX. The PBX expects a trunk-access digit, so direct 911 fails. Or the call reaches a public safety answering point, but the location delivered with the call only says "100 Main Street" when the caller is actually on floor 14, room 1421. Or security finds out about the emergency only after responders arrive.

Kari's Law and RAY BAUM's Act address those gaps:

• Kari's Law is about reaching 911 directly and notifying someone responsible for the site.
• RAY BAUM's Act is about sending a dispatchable location, not just a billing address.
• The FCC's rules in 47 CFR 9.16 turn those statutes into operational requirements for MLTS manufacturers, installers, managers, and operators.

For an Asterisk administrator, the practical question is this: if any endpoint can call the public telephone network, can that same endpoint dial 911 directly, send the right callback number and location, and alert the people nearby without slowing the emergency call down?

Requirement summary

Effective dates

The key federal dates have already passed:

• February 16, 2020: Kari's Law applies to covered MLTS manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020.
• January 6, 2021: on-premises fixed MLTS devices must provide automated dispatchable location.
• January 6, 2022: on-premises non-fixed and off-premises MLTS devices must provide automated dispatchable location when technically feasible, or use the allowed manual or enhanced-location fallback.

If you operate an old PBX, do not treat age as a free pass without review. Asterisk systems get rebuilt, virtualized, moved to new hosts, converted to PJSIP, merged with hosted trunks, and reworked during office moves. Those changes can make "legacy" assumptions fragile. From an engineering standpoint, build and test the system as if direct 911, notification, and dispatchable location are mandatory.

Applicability for Asterisk deployments

Asterisk is usually part of an MLTS when it serves multiple users and connects them to outside telephone service. That can include:

• A business PBX with desk phones.
• A hosted PBX serving several customer locations.
• A hotel, school, clinic, warehouse, campus, or office system.
• A call center with agents in multiple rooms or buildings.
• A softphone deployment for remote workers.
• A hybrid system where Asterisk routes calls behind another UC platform.

The FCC definition of MLTS is broad enough to include PBX and VoIP systems. The safer working assumption is simple: if Asterisk controls extension dialing and outbound trunk selection for US users, E911 belongs in the design, not in a later ticket.

Kari's Law controls

Direct 911 dialing

Every station with dialing capability needs a working 911 route. Do not place emergency calls behind:

• A trunk access digit.
• A long-distance prefix.
• A PIN prompt.
• A tenant billing gate.
• A class-of-service rule that can accidentally block an extension.
• A time-of-day route that may be closed after hours.

You may keep 9911 or 9-911 as a tolerated legacy pattern. That is a safety net for people trained on old systems. It is not the compliant path by itself.

On-site or responsible-party notification

Kari's Law also requires MLTS notification when the system can provide it without a hardware or software improvement. Under 47 CFR 9.3, the notification should include the fact that a 911 call was made, a valid callback number, and the location information sent to the PSAP when technically feasible.

Good notification targets include:

• Front desk.
• Security desk.
• Facilities team.
• Nurse station.
• School office.
• Building operations.
• An on-call incident channel for remote or unmanned sites.

The notification must not delay the 911 call. In Asterisk terms, keep it out of the critical path. If you call an external script, make it fast, fire-and-forget, and fed only by internally assigned values. Better yet, push an AMI, ARI, syslog, webhook, or queue event to a local service that handles email, SMS, paging, and chat notifications outside the dialplan thread.

RAY BAUM's Act controls

Dispatchable location means more than a street address

The FCC definition of dispatchable location is the validated street address plus additional information needed to identify the caller's location. In a small one-room office, the street address may be enough. In a multi-story building, campus, hotel, hospital, warehouse, or school, it usually is not.

Useful dispatchable-location fields include:

• Street address.
• Building or campus name.
• Floor.
• Suite.
• Room.
• Wing.
• Zone.
• Desk bank.
• Apartment or unit.
• Entry instructions if your emergency provider supports them.

Do not confuse caller ID with dispatchable location. Caller ID is usually the lookup key your ITSP or E911 provider uses. Dispatchable location is the record responders need after that lookup.

Fixed phones

For fixed phones, the location should be automatic. A desk phone in room 214 should not rely on the user saying "room 214" after the call connects. If that phone moves, the location record needs to move with it before the phone is placed back into service.

Non-fixed and remote devices

Softphones, Wi-Fi handsets, VPN phones, and remote worker devices need a different process. If you cannot automatically determine their dispatchable location, make the user confirm or update location before the device is allowed to place normal calls.

A reasonable remote-worker pattern is:

1. User signs in or registers a device.
2. PBX checks whether a current emergency address exists for that device or user.
3. If the address is missing or stale, normal outbound calling is blocked or routed to a location-confirmation workflow.
4. Emergency calling still routes to 911, but the system uses the best available callback and location data.
5. The address update is pushed to the ITSP or E911 provider before the user is considered fully active.

If the provider cannot update E911 records in real time, document the delay and design around it. Do not tell users a location is active until the provider has accepted it.

Asterisk endpoint location model

Keep emergency location data in one place that operations can audit. For small systems, endpoint variables in pjsip.conf may be enough. For larger systems, use a database table keyed by endpoint, MAC address, user, site, or DID.

Example pjsip.conf endpoint variables:

[desk-hq-214]
type=endpoint
aors=desk-hq-214
auth=desk-hq-214
context=internal
set_var=E911_LOCATION_ID=HQ-F02-R214
set_var=E911_CALLBACK=12125550142
set_var=E911_SITE_NAME=Headquarters floor 2 room 214

For this to be useful, HQ-F02-R214 must map to a validated emergency record with your ITSP or E911 provider. A local variable that never reaches the provider or PSAP is only an internal label.

A simple location table should track:

Dialplan pattern

The dialplan should be boring and explicit. Emergency calling is not the place for clever pattern matching.

[internal]
exten => 911,1,Goto(e911,call,1)
exten => 9911,1,Goto(e911,call,1)

[e911]
exten => call,1,NoOp(E911 call from ${CALLERID(all)} on ${CHANNEL})
 same => n,Set(E911_LOCATION_ID=${IF($["${E911_LOCATION_ID}"=""]?UNKNOWN:${E911_LOCATION_ID})})
 same => n,Set(E911_CALLBACK=${IF($["${E911_CALLBACK}"=""]?12125550100:${E911_CALLBACK})})
 same => n,Set(CALLERID(num)=${E911_CALLBACK})
 same => n,Set(CALLERID(name)=Emergency Call)
 same => n,System(/usr/local/sbin/e911-notify '${E911_LOCATION_ID}' '${E911_CALLBACK}' '${UNIQUEID}' &)
 same => n,MixMonitor(e911/${STRFTIME(${EPOCH},,%Y/%m/%d)}/${UNIQUEID}.wav,b)
 same => n,Dial(PJSIP/911@e911-trunk,,b(e911-headers^add^1(${E911_LOCATION_ID})))
 same => n,Hangup()

[e911-headers]
exten => add,1,NoOp(Add emergency location hint for ${ARG1})
 same => n,Set(PJSIP_HEADER(add,X-E911-Location-ID)=${ARG1})
 same => n,Return()

Important details:

• 911 is the primary route. 9911 is only tolerated for legacy muscle memory.
• The notification is started before dialing, but it is backgrounded and must not delay the call.
• Only use internally assigned values in the notification command. Do not pass unsanitized caller-provided values to System().
• CALLERID(num) should be a callback number your provider recognizes for E911. For many providers, this is the field that selects the emergency address record.
• Custom SIP headers only help if your ITSP has explicitly documented support for them. Do not assume X-E911-Location-ID reaches the PSAP.
• The pre-dial handler is used because outbound PJSIP headers must be added on the outbound channel.

Use Dial() for the emergency trunk call and Gosub() for reusable policy logic if your real dialplan has multiple sites or tenants.

Notification design

The notification should be useful to people who can help responders. A good alert says:

• Emergency call placed.
• Time.
• Endpoint or device name.
• Caller ID and callback number.
• Site, floor, room, or zone.
• Current call unique ID.
• Whether the call is still active if your notification service can track that.

Send the alert to more than one channel when the site justifies it. A front-desk screen is good during business hours. It is less useful for a warehouse at 2 AM. For remote sites, send alerts to an on-call destination or central security desk.

Do not build the alert so it can block the 911 call. Email, SMS, Teams, Slack, paging, or ticket creation should be handled by a local notification service that receives a small event from Asterisk and then does the slow network work by itself.

Recording emergency calls

The issue scope calls out MixMonitor(), and recording can be operationally useful for incident review. Treat emergency recordings as sensitive.

If you record emergency calls:

• Start recording only after the emergency route is selected.
• Store recordings outside the web root.
• Use restrictive file permissions.
• Keep retention short unless policy or law requires more.
• Log playback and export.
• Cross-check your recording policy against Call Recording Consent Laws by State.
• For international users or storage outside the US, also review International Call Recording Compliance.

For a practical recording toggle pattern, see Selective Call Recording. Emergency recording should be automatic only if your policy has approved it. It should not depend on an agent remembering to press a feature code.

What your ITSP or E911 provider needs

Asterisk cannot satisfy dispatchable-location rules by itself. The provider handling the emergency call must receive or already have the correct location record.

Ask your provider how they support:

• Validated service addresses.
• Emergency response locations or ERLs.
• Per-DID emergency-address records.
• Caller ID to location mapping.
• Dynamic location updates for remote workers.
• HELD or LIS integration, if offered.
• Provider API updates for nomadic users.
• SIP headers or PIDF-LO, if supported.
• Test calls to verify address presentation.
• Failover behavior if the emergency trunk is unavailable.

For many ITSPs, the right answer is not a custom SIP header. It is a callback number that maps to a provider-side emergency address. For larger or nomadic environments, the answer may be a LIS, HELD workflow, provider API, or dedicated E911 service.

Remote worker location-confirmation pattern

A softphone that registers from a home network is not located at headquarters just because its extension number belongs to headquarters. Build a workflow that forces location maintenance.

A practical policy:

• Store a registered emergency address per user or device.
• Require confirmation after a configurable age, such as every 30 or 90 days.
• Require confirmation when the public IP, VPN region, Wi-Fi network, or device changes.
• Keep normal outbound calling restricted until the location is confirmed if your policy requires it.
• Always allow 911, but flag calls with stale or unknown location for immediate internal follow-up.
• Keep evidence of the last confirmation and provider acceptance.

A voice prompt can work for small deployments:

[location-required]
exten => s,1,Playback(custom/emergency-location-required)
 same => n,Playback(custom/update-location-before-calling)
 same => n,Hangup()

For most real systems, use a web form tied to the provider API. The PBX should consume the resulting status, not become the source of truth for address validation.

Test plan

Do not wait for a real emergency to discover that the wrong DID is registered.

Minimum recurring checks:

• Dial 911 from each site according to your provider's approved test procedure.
• Dial 9911 and confirm it reaches the same emergency route.
• Confirm direct 911 works from restricted phones, lobby phones, hotel rooms, classrooms, and common-area phones.
• Confirm the notification fires and includes callback and location details.
• Confirm the notification does not delay call setup.
• Confirm caller ID maps to the correct dispatchable location at the provider.
• Move a test phone to another room and verify the move process updates the emergency record.
• Test a softphone or remote user with a stale location.
• Test emergency trunk failover.
• Keep screenshots, call IDs, provider tickets, and test dates as audit evidence.

Coordinate test calls with your ITSP and local emergency authority. Do not place casual 911 test calls without following the approved procedure.

Penalties and risk

Kari's Law is enforced under the Communications Act, and 47 U.S.C. 503 gives the FCC civil forfeiture authority for willful or repeated violations of the Act or FCC rules. The FCC's forfeiture rules and inflation-adjusted maximums are in 47 CFR 1.80.

The operational risk is larger than a fine. A bad E911 design can delay emergency response, send responders to the wrong building or floor, expose the organization to civil claims, and leave administrators with no audit trail showing what the PBX did.

Implementation checklist

• 911 routes directly from every endpoint that can dial out.
• 9911 is routed as a legacy fallback.
• Emergency routes bypass normal toll restrictions and account-code prompts.
• Every endpoint maps to a dispatchable location or reviewed fallback.
• Fixed phones have automatic location mapping.
• Remote users have a location confirmation workflow.
• Caller ID selects the correct provider-side emergency record.
• Notification fires at the same time as the emergency call and does not delay it.
• Security, reception, facilities, or on-call staff receive actionable alerts.
• Emergency recordings, if enabled, are restricted and have a retention policy.
• ITSP records are validated and reviewed after moves, adds, and changes.
• Test calls are documented.
• Compliance owners are named for telecom, facilities, security, HR, and legal.

Related Asterisk and compliance pages

• Dial() for sending the emergency call to the provider trunk.
• Gosub() for reusable emergency policy logic.
• System() for simple local hooks, with strict input controls.
• MixMonitor() for emergency-call recording when policy allows it.
• STIR/SHAKEN Caller ID Authentication for caller ID trust concepts outside the E911 path.
• Call Recording Consent Laws by State if emergency calls are recorded in the US.
• International Call Recording Compliance if callers, agents, or recording storage cross borders.
• Selective Call Recording for a practical Asterisk recording pattern.

Official sources used

• 911.gov: Kari's Law and RAY BAUM's Act
• Kari's Law, 47 U.S.C. 623
• RAY BAUM's Act Section 506 note under 47 U.S.C. 615
• MLTS definition, 47 U.S.C. 1471
• FCC definitions, 47 CFR 9.3
• FCC MLTS obligations, 47 CFR 9.16
• FCC forfeiture authority, 47 U.S.C. 503
• FCC forfeiture rules, 47 CFR 1.80