Concept renderA voice service meets the interconnected VoIP definition in 47 CFR 9.3 when it offers real-time two-way voice over broadband, uses IP-compatible equipment and connects calls with the telephone network. 9.11 then sets provider notice and location duties. Kari's Law rules in 9.15 and 9.16 cover multi-line telephone systems. Engineering reading as of October 31, 2026, not legal advice.
If you build an elder check-in speaker or an SOS watch, someone will ask whether 911 rules apply to it. The answer depends on what the device does on a call. This guide lays out the rule text we reviewed, turns the definition into a yes or no check per device type, and lists what to test on your own hardware.
This is the engineering team's summary and does not constitute legal advice. It rests on the Code of Federal Regulations text as mirrored by Cornell Law School's Legal Information Institute, accessed October 31, 2026. We could not retrieve the FCC's own Kari's Law pages or the statute text, so we did not use them. We did not review the rules for cellular emergency calling. Check every quote against the current eCFR before you act. We do not say that any device, ours or yours, is compliant. Where a device has medical or health features, this is an engineering summary of general wellness products and is not a guide to medical devices.
What does the rule text say?
Five provisions matter for this question. The table gives our paraphrase and one short excerpt for each, with the source, as of October 31, 2026.
| Topic | Section | What it says (our paraphrase) | Excerpt | Source |
|---|---|---|---|---|
| Interconnected VoIP definition | 47 CFR 9.3 | Four conditions: real-time two-way voice, a broadband connection, IP-compatible customer premises equipment, and the ability to receive calls from and terminate calls to the public switched telephone network (PSTN). For 911 compliance, a service that meets the first three and can only terminate calls to the PSTN is also covered. | Opening condition: "Enables real-time, two-way voice communications;" | 47 CFR 9.3, Oct 31, 2026 |
| Subscriber notice | 47 CFR 9.11 | A provider must advise every subscriber, new and existing, prominently and in plain language, of the circumstances under which E911 service may not be available, and must keep a record of affirmative acknowledgement. | "shall specifically advise every subscriber, both new and existing, prominently and in plain language, of the circumstances under which E911 service may not be available" | 47 CFR 9.11, Oct 31, 2026 |
| Registered Location | 47 CFR 9.11 | For non-fixed interconnected VoIP, the provider obtains the Registered Location from the customer before service starts and offers update methods, including one that needs only the customer premises equipment used to access the service. | "The service provider has obtained from the customer, prior to the initiation of service, the Registered Location" | 47 CFR 9.11, Oct 31, 2026 |
| Who Kari's Law and RAY BAUM'S Act rules reach | 47 CFR 9.15 | The rules apply to makers, importers, sellers and lessors of multi-line telephone systems (MLTS), and to installers and operators of them. MLTS is a defined term covering common control units, telephone sets, control software and adjunct systems. | "A person engaged in the business of manufacturing, importing, selling, or leasing multi-line telephone systems" | 47 CFR 9.15, Oct 31, 2026 |
| What an MLTS must do | 47 CFR 9.16 | Direct 911 dialing with no prefix digit, on-site notification where configurable, and dispatchable location for on-premises and off-premises devices. The dates in the rule are January 6, 2021 and January 6, 2022. | "may directly initiate a call to 911 from any station equipped with dialing facilities" | 47 CFR 9.16, Oct 31, 2026 |
These excerpts are short quotes. The surrounding text has exceptions and definitions that this summary leaves out.
Which device types are in or out of scope?
The check is a set of yes or no questions: the four conditions in 9.3, then the MLTS question in 9.15. The matrix below applies them to five common designs. The answers are our reading of the definitions, as of October 31, 2026, and they change with your actual call path. Treat each row as a prompt for a conversation with counsel.
| Device type | Real-time two-way voice | Broadband | IP-compatible equipment | Calls to and from the PSTN | 9.3 reading | MLTS? | What to look at next |
|---|---|---|---|---|---|---|---|
| Cellular-only SOS watch | Depends on the call path | Depends on whether the voice path is a broadband IP connection. Not settled here. | Depends on the modem and firmware | Yes if it dials phone numbers | Not answered here. The cellular 911 path falls under a separate rule that this article did not review. | Unlikely, it is a single handset | Ask counsel which rule governs the cellular path before you write any 911 text. |
| Wi-Fi speaker that places calls to phone numbers | Yes, if the call is live voice | Yes | Yes | Yes | Likely inside 9.3. Read 9.11 for notice and Registered Location. | Not obviously | Notice and acknowledgement record, Registered Location capture and update path. |
| Wi-Fi speaker with one-way alerts, no live voice | No | Yes | Yes | Not applicable | Fails the first condition on our reading. | Not obviously | Still tell users in plain language what the device does not do. |
| Device that calls only app contacts over the internet | Yes | Yes | Yes | No, unless the service also reaches the PSTN | Outside the four-condition definition if the PSTN is never involved. The extended coverage for PSTN-terminating service applies only if you can place calls out to phone numbers. | Not obviously | Tell users that the device cannot reach 911 and what to use instead. |
| Speaker sold into an enterprise phone system | Yes | Yes | Yes | Through the customer's system | Depends on who provides the service. Your firmware may be only a telephone set. | Possibly, if it is a telephone set of an MLTS | Check 9.15 and 9.16 with the system integrator: direct dialing, notification, location. |
Definitions: 47 CFR 9.3 and 47 CFR 9.15, as of October 31, 2026. The extended coverage for PSTN-terminating service is in 9.3 for 911 compliance purposes.
What common mistakes follow from the rule text?
These come from engineering reasoning about the rules above. None describes an incident at any company.
- A voice feature added late changes the scope. The definition in 9.3 turns on features. A firmware update that adds outbound calls to phone numbers can move a device from the "no" rows to the "yes" rows. This is engineering reasoning from the four conditions.
- The word "SOS" on the box does not decide anything. The rule text tests the service: voice, broadband, equipment, PSTN. The product name plays no part. A button labeled SOS that sends a text or notifies an app contact is a different design from one that places a phone call. This is engineering reasoning.
- A notice that nobody has to acknowledge leaves a gap. 9.11 asks for a record of affirmative acknowledgement. If the device has no screen, the acknowledgement has to happen in a companion channel, and the firmware has to be able to prove it happened. This is engineering reasoning from the rule text.
- A Registered Location needs an update path on the device. The rule asks for an update method that needs only the equipment used to access the service. A speaker that can be moved room to room or house to house needs a way for the user to change the address without another device. This is engineering reasoning.
- Plan for a device that moves from the start. The rules distinguish non-fixed service and require location handling for on-premises and off-premises MLTS devices. If your product is carried, the location logic is part of the architecture. This is engineering reasoning.
What should you test on your own board?
The rules do not say how any particular device behaves. Run these on your own hardware.
| What to test | How to instrument or capture it | Raw data to record |
|---|---|---|
| What the device does when the emergency path is triggered | Press the SOS control on each hardware build in each network state: Wi-Fi up, Wi-Fi down, cellular only if present. Route the emergency path to a test number you control, or use the modem or service test mode. Do not place live 911 test calls unless you have arranged them with the local emergency call center. Capture the user-facing result and the device log. | Build and firmware version, network state, what the user saw and heard, what the device sent, the log lines for the attempt. |
| Whether the call path reaches the PSTN | Place a test call to a number you control through each path the product offers. Record which carrier or service handled it. | Path name, called number type, whether the call connected, who the terminating provider was. |
| The notice and acknowledgement flow | Walk a new user and an existing user through setup. Record every screen and voice prompt that mentions emergency calling. | Exact notice text, where it appears, how the user acknowledges, where the acknowledgement record is stored and how you retrieve it. |
| Registered Location capture and update | Set an address, move the device, then change the address using only the device or its own access channel. | Steps required, which equipment was used, time of each step, what the system recorded for the old and new address. |
| Behavior when power or network fails | Pull power and network during idle and during a call attempt. Restore and repeat. | What the user was told, what state the device came back in, whether any attempt was queued or lost. |
Set the pass line for each test yourself, from your product requirements, and record the basis for it. Vendors of cellular modems and voice services publish different details. Where they have not published a number, write "vendor has not published it, test on your board" in your own notes.
What should you ask before you commit?
Take this list to your product, firmware and legal reviewers.
- Does your device place live two-way voice calls, or only send alerts and messages?
- Can any user-initiated call reach a phone number on the telephone network, now or in a planned update?
- Is your service the one the user depends on for emergency calling, or only a telephone set on someone else's phone system?
- If the device cannot reach 911, where in the product does the user learn that, and how do you record that they saw it?
- Can the device be moved, and if so, how does the user tell you where it is?
- Who in your team owns the written position on 911, and has counsel reviewed it?
- Does your marketing or packaging use words such as "SOS" or "emergency" in a way that could suggest a capability the device lacks?
These products are for adults and older adults. Keep every user-facing sentence about emergency capability plain and literal, and keep recording or location features visible to the user.
Questions about E911 and SOS devices
Does my elder check-in speaker have to support 911?
It depends on what the device does. If it offers real-time two-way voice over broadband with IP-compatible equipment and can connect calls with the telephone network, it likely meets the interconnected VoIP definition in 47 CFR 9.3. If it only sends alerts or calls app contacts, it falls outside the four-condition test on our reading. This is an engineering summary. It is not legal advice.
What do I have to tell users if the device cannot call 911?
The rules we reviewed address the case of a provider whose service may not offer E911. 47 CFR 9.11 requires prominent, plain-language notice of the circumstances under which E911 may not be available, plus a record of affirmative acknowledgement. For a device outside the definition, the same plain-language approach is a sensible engineering choice, and counsel should confirm the wording.
Does Kari's Law apply to a consumer SOS speaker or watch?
Not obviously. The rules in 47 CFR 9.15 apply to makers, importers, sellers and lessors of multi-line telephone systems, and MLTS is a defined term. A standalone consumer device is not clearly one. A speaker sold into an enterprise phone system is a closer question. Ask counsel.
What does an MLTS have to do?
47 CFR 9.16 requires direct 911 dialing with no prefix digit, on-site notification where configurable, and dispatchable location for on-premises and off-premises devices. The rule lists dates of January 6, 2021 and January 6, 2022. Read the current text before you rely on this summary.
Can Duobay tell me my device is compliant?
No. This article reads published rule text and does not claim that any device is compliant. Compliance depends on your exact call path and on legal review. We can help you plan the engineering and the tests as part of a project. How our engineering gates work.
If you want to plan the call path, the notices and the tests for your device, tell us about your device. You can also read about our AI companion and elder care device development.
Sources
All pages accessed October 31, 2026. Rules change, so re-read the current text before you decide.
- Cornell Law School LII, 47 CFR 9.3 (definitions): https://www.law.cornell.edu/cfr/text/47/9.3 (accessed 2026-10-31)
- Cornell Law School LII, 47 CFR 9.11 (E911 for interconnected VoIP): https://www.law.cornell.edu/cfr/text/47/9.11 (accessed 2026-10-31)
- Cornell Law School LII, 47 CFR 9.15 (MLTS): https://www.law.cornell.edu/cfr/text/47/9.15 (accessed 2026-10-31)
- Cornell Law School LII, 47 CFR 9.16 (MLTS requirements): https://www.law.cornell.edu/cfr/text/47/9.16 (accessed 2026-10-31)
Planning an AI companion or elder-care device? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →