Alert

FCC Adopts New E911 Rules

August 9, 2019

Summary of Report and Order Implementing Kari’s Law and
Section 506 of RAY BAUM’S Act
PS Docket Nos. 18-261 and 17-239, and GN Docket No. 11-117

On August 2, 2019, the Federal Communications Commission (FCC or Commission) released a Report and Order (Order) that adopted rules to facilitate access to 911 and to improve location information received by Public Safety Answering Points (PSAPs) for every 911 call, regardless of the type of service used to make the call. The Order implements two federal statutes: Kari’s Law Act of 2017, which requires implementation of direct 911 dialing and on-site notification capabilities in multi-line telephone systems (MLTS), and Section 506 of RAY BAUM’S Act, which requires the FCC to “consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call, regardless of the technological platform used and including with calls from [MLTS].”

Direct Dialing

Consistent with Kari’s Law, the FCC adopted rules which require that any person engaged in the business of manufacturing, importing, selling, or leasing an MLTS may not manufacture or import the MLTS for use in the United States, or sell or lease or offer to sell or lease it in the United States, unless such system: (1) is pre-configured such that a user may directly initiate a call to 911 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9, regardless of whether the user is required to dial such a digit, code, prefix, or post-fix for other calls; and (2) has the capability of providing the dispatchable location of the caller to the PSAP with 911 calls. 47 C.F.R. § 9.16(a).

Under the FCC’s rules, any person engaged in the business of installing, managing, or operating an MLTS may not install, manage, or operate for use in the United States such a system, unless such system is configured such that a user may directly initiate a call to 911 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9, regardless of whether the user is required to dial such a digit, code, prefix, or post-fix for other calls. 47 C.F.R. § 9.16(b)(1).

Notification

The FCC’s rules require that a person engaged in the business of installing, managing, or operating an MLTS must, in installing, managing, or operating such a system for use in the United States, configure the system to provide MLTS Notification to a central location at the facility where the system is installed or to another person or organization regardless of location, if the system is able to be configured to provide the notification without an improvement to the hardware or software of the system. 47 C.F.R. § 9.16(b)(2).

MLTS Notification is defined as an MLTS feature that can send notice to a central location at the facility where the system is installed or to another person or organization regardless of location. Examples of notification include conspicuous on-screen messages with audible alarms for security desk computers using a client application, text messages for smartphones, and email for administrators. Notification must include, at a minimum, the following information: (1) the fact that a 911 call has been made, (2) a valid callback number, and (3) the information about the caller’s location that the MLTS conveys to the PSAP with the call to 911. 47 C.F.R. § 9.3.

The MLTS Notification does not have to include a callback number or location information if it is technically infeasible to provide this information. 47 C.F.R. § 9.3. For example, if the 911 call comes from a non-Direct Inward Dialing number, the callback number in the notification can be an internal extension that can be directly reached from inside the enterprise but not from outside it. Similarly, a hotel that does not provide a Direct Inward Dialing line to each guest room can provide the number of a central location, such as the front desk, in the notification. Order ¶ 26.

MLTS Notification must meet the following requirements: (1) MLTS Notification must be initiated contemporaneously with the 911 call, provided that it is technically feasible to do so; (2) MLTS Notification must not delay the call to 911; and (iii) MLTS Notification must be sent to a location where someone is likely to see or hear it. 47 C.F.R. § 9.16(b)(2).

The FCC’s rules set minimum requirements, and thus enterprises may add other information to the MLTS Notification as useful and appropriate so long as the notification includes the required elements. This may include, for example, the occupancy status of a hotel room, or the specific location of an IP device. The FCC encourages enterprises to develop voluntary best practices and conduct employee training to prepare enterprises for responding to receipt of notification that a 911 call has been made. For example, training could include the circumstances under which the notice recipient (or someone else at the enterprise) should dial the callback number included with the notification. Order ¶ 28.

Kari’s Law makes clear that the notification requirements of the statute apply only if the MLTS can be configured to provide notification “without an improvement to the hardware or software of the system.” Thus, under the FCC’s rules, enterprises are not required to undertake “upgrades to the core systems of an MLTS,” “substantial upgrades to the software,” or “any software upgrades that require a significant purchase” in order to comply with the notification obligation. Order ¶¶ 71-72.

Whether a party is a manager, operator, or installer is based on the party’s conduct and whether it has performed activities that fall within the definition in the FCC’s rules. For example, when an enterprise offers a hosted MLTS solution to a business, it is responsible for compliance with the requirements applicable to those engaged in installing, managing, or operating an MLTS to the extent that its hosting service includes those functions. On the other hand, if an enterprise offers a trunking solution that provides PSTN access with the customer operating and managing the MLTS, the customer would have responsibility for compliance as an operator and/or manager. Order ¶ 92.  

If an MLTS fails to comply with the rules, the MLTS manager is presumed to be responsible for that failure, at least in part, unless the manager can rebut the presumption by demonstrating compliance with its obligations under the statute and rules. 47 C.F.R. § 9.17(a). Any determination of a particular party’s liability will necessarily require a fact-specific, case-by-case inquiry. And, while the parties’ contractual arrangements may be relevant in this determination, they are not determinative, and an entity that performs the functions of a manager in violation of a contractual obligation not to do so could still be deemed a “person engaged in the business of managing an MLTS.” Order ¶ 93.

To the extent a violation of the statute or rules results from failure of the enterprise owner/customer to perform the required tasks properly, the owner/customer will be responsible for that violation. Consistent with this approach, if the enterprise customer controls the routing of calls, the enterprise’s voice service provider has fulfilled its responsibilities under the statute and regulations if it ensures that its service will not interfere with the customer’s ability to configure the MLTS to be capable of transmitting direct-dialed calls to 911. Order ¶ 95. Likewise, an MLTS installer, manager, or operator need only offer the central notification capability to the customer to be in compliance with the law; if the enterprise customer declines to use the services offered, a manager, operator, or installer will not be liable as long as it performs its obligations in compliance with the statute and the FCC’s rules. Order ¶ 96.

Compliance Date and Transition Periods

Consistent with Kari’s Law, the direct dialing and notification requirements apply to MLTS manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020. Order ¶ 100.

The FCC declined to require enterprises to notify end users of the 911 capabilities and limitations of MLTS that are not subject to Kari’s Law and the FCC’s rules. Nevertheless, the FCC encourages enterprises to disclose the limitations on dialing 911 from such MLTS as part of voluntary best practices. Order ¶ 103.

Dispatchable Location for MLTS and Other 911-Capable Communications Services

 1. General requirements

RAY BAUM’S Act directed the FCC to consider rules requiring the conveyance of dispatchable location with 911 calls “regardless of the technological platform used.” Based on this directive, the FCC adopts dispatchable location requirements for MLTS and other 911-capable services that do not have such requirements, including fixed telephony, interconnected VoIP service, Telecommunications Relay Services (TRS), and mobile text.

“Dispatchable location” means a location delivered to the PSAP with a 911 call that consists of the validated street address of the calling party, plus additional information such as suite, apartment or similar information necessary to adequately identify the location of the calling party (except for Commercial Mobile Radio Service providers, which are subject to different location information requirements). 47 C.F.R. § 9.3.

 2. MLTS

A person engaged in the business of installing an MLTS may not install such a system in the United States unless it is configured such that it is capable of being programmed with and conveying the dispatchable location of the caller to the PSAP with 911 calls consistent with the FCC’s rules. 47 C.F.R. § 9.16(b)(3).

A person engaged in the business of managing or operating an MLTS may not manage or operate such a system in the United States unless it is configured such that the dispatchable location of the caller is conveyed to the PSAP with 911 calls consistent with the FCC’s rules. 47 C.F.R. § 9.16(b)(3).

Dispatchable location requirements for on-premises fixed telephones associated with a multi-line telephone system. An on-premises fixed telephone associated with an MLTS (for example, where MLTS calls originate from fixed devices such as hotel phones or fixed desk phones) must provide automated dispatchable location no later than one year after the effective date of the FCC’s rule. 47 C.F.R. § 9.16(b)(3)(i).

Dispatchable location requirements for on-premises non-fixed devices associated with a multiline telephone system. No later than two years after the effective date of the FCC’s rules, an on-premises nonfixed device associated with an MLTS (e.g., softphones or mobile handsets that are capable of connecting to multiple Wi-Fi access points and can move from one location to another within a building) must provide to the appropriate PSAP automated dispatchable location, when technically feasible; otherwise, it must provide dispatchable location based on end user manual update (e.g., by responding to a system prompt), or alternative location information as defined in the FCC’s rules. 47 C.F.R. § 9.16(b)(3)(ii).

Dispatchable location requirements for off-premises devices associated with a multi-line telephone system. No later than two years after the effective date of the FCC’s rule, an off-premises device associated with an MLTS must provide to the appropriate PSAP automatic dispatchable location, if technically feasible; otherwise, it must provide dispatchable location based on end user manual update, or enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost. 47 C.F.R. § 9.16(b)(3)(iii).

 3. Fixed telephony

Fixed telephony providers are required to deliver automated dispatchable location with 911 calls. This requirement will take effect one year from the effective date of the FCC’s rules. To the extent that fixed telephony providers face limitations in providing automated dispatchable location due to factors beyond the provider’s control (e.g., territories that lack an available street address database, PSAPs that lack the capability to receive automated location information), such providers may request relief under the FCC’s waiver process. Order ¶¶ 171-173.

 4. Interconnected VoIP

Fixed interconnected VoIP providers are required to transmit dispatchable location with each 911 call. While dispatchable location may be determined by means of a customer generated Registered Location in the fixed VoIP context (to the extent a physical location conveys a street address that is validated), it must be provided automatically to the PSAP by the VoIP service provider, without additional action by the caller, at the time the 911 call is made. This requirement will take effect one year from the effective date of the FCC’s rules. Order ¶ 176.

Providers of non-fixed interconnected VoIP service (i.e., a VoIP service that is capable of being used from more than one location) must provide automated dispatchable location, if technically feasible. Otherwise, non-fixed interconnected VoIP service providers must either:

(1) provide Registered Location information that meets the following requirements:

•  the service provider has obtained from the customer, prior to the initiation of service, the Registered Location (as defined in the FCC’s rules) at which the service will first be used;

•  the service provider has provided end users one or more methods of updating their Registered Location, including at least one option that requires use only of the CPE necessary to access the interconnected VoIP service. Any method used must allow an end user to update the Registered Location at will and in a timely manner; and

•  the service provider must identify whether the service is being used to call 911 from a different location than the Registered Location, and if so, either: (i) prompt the customer to provide a new Registered Location; or (ii) update the Registered Location without requiring additional action by the customer.

(2) provide Alternative Location Information (as defined in the FCC’s rules); or

(3) route the caller to a national emergency call center.

 5. Outbound-Only Interconnected VoIP

The FCC adopts 911 location requirements for outbound-only interconnected VoIP providers. The FCC amends the definition of “Interconnected VoIP Service” used for 911 purposes to include outbound-only interconnected VoIP services that generally permit users to initiate calls that terminate to the PSTN. 47 C.F.R. § 9.3.

Outbound-only interconnected VoIP providers are required to comply with the FCC’s 911 rules to provide: (1) dispatchable location if feasible, or, otherwise, either (2) manual updating of Registered Location information; or (3) alternative location information sufficient to identify the caller’s civic address, floor level, and approximate floor location in large buildings. Outbound-only interconnected VoIP providers also must notify subscribers of any limitations to E911 service. However, the notification requirement is modified to clarify that it may be satisfied through stickers or warning labels, or other conspicuous means, provided that the notification is prominently displayed or highlighted in a manner that makes it likely to be seen by the customer. Order ¶ 183.

Outbound-only interconnected VoIP providers must comply with these 911 requirements two years after the effective date of the FCC’s rules. Order ¶ 206.

6. Telecommunications Relay Services (TRS)

For 911 calls from fixed Internet-based TRS, beginning one year from the effective date of the FCC’s rules, Internet-based TRS providers are required to provide automated, validated dispatchable location for each call. For 911 calls from non-fixed Internet-based TRS, beginning two years from the effective date of the rules, Internet-based TRS providers are required to provide with each 911 call (1) automated dispatchable location, if technically feasible, or, otherwise, either (2) manual updating of Registered Location, or (3) alternative location information, which may be coordinate-based, sufficient to identify the caller’s civic address and approximate in-building location, including floor level, in large buildings when the first two are not technically feasible. Order ¶ 211.

The rules do not require TRS providers to automatically detect when a device is being used at a different location from the Registered Location to the extent doing so is not technically feasible. In such cases, the requirement can be met by a manual prompt to the user asking for confirmation whether the user is at the Registered Location or a different location. Order ¶ 214.

7. Liability Protection

MLTS manufacturers, importers, sellers, lessors, installers, operators and managers are entitled to the same liability protections afforded wireless carriers, interconnected VoIP services and text-to-911 services under 47 U.S.C. § 615a, which grants immunity from liability to certain emergency communications providers. Order ¶¶ 168-169.

Definitions

Multi-Line Telephone System or MLTS. A system comprised of common control units, telephone sets, control hardware and software and adjunct systems, including network and premises based systems, such as Centrex and VoIP, as well as PBX, Hybrid, and Key Telephone Systems (as classified by the Commission under part 68 of title 47, Code of Federal Regulations), and includes systems owned or leased by governmental agencies and non-profit entities, as well as for profit businesses.” 47 C.F.R. § 9.3.  The definition of MLTS is interpreted to include: (1) the full range of networked communications systems that serve enterprises, including circuit-switched and IP-based enterprise systems, as well as cloud-based IP technology and over-the-top applications; and (2) outbound-only calling systems. Order ¶¶ 48 & 52. MLTS does not include purely internal communications systems that do not rely on telephone numbers under the North American Numbering Plan. Order ¶ 56.

Person engaged in the business of installing an MLTS. A person that configures the MLTS or performs other tasks involved in getting the system ready to operate. These tasks may include, but are not limited to, establishing the dialing pattern for emergency calls, determining how calls will route to the Public Switched Telephone Network (PSTN), and determining where the MLTS will interface with the PSTN. These tasks are performed when the system is initially installed, but they may also be performed on a more or less regular basis by the MLTS operator as the communications needs of the enterprise change. The MLTS installer may be the MLTS manager or a third party acting on behalf of the manager. 47 C.F.R. § 9.3. A manufacturer of a hosted MLTS that configures the system or that provides systems with self-installing software is performing the functions of an installer. There may be multiple parties performing installation functions for a single MLTS when, for example, an entity performs the functions of an installer at the direction of the enterprise operator or manager, in which case the operator or manager in that scenario is also serving as the installer. Order ¶ 83.

Person engaged in the business of managing an MLTS. The entity that is responsible for controlling and overseeing implementation of the MLTS after installation. These responsibilities include determining how lines should be distributed (including the adding or moving of lines), assigning and reassigning telephone numbers, and ongoing network configuration. 47 C.F.R. § 9.3.

Person engaged in the business of manufacturing, importing, selling, or leasing an MLTS. A person that manufactures, imports, sells, or leases an MLTS. 47 C.F.R. § 9.3.

Person engaged in the business of operating an MLTS. A person responsible for the day-to-day operations of the MLTS. 47 C.F.R. § 9.3.

Configured. The settings or configurations for a particular MLTS installation have been implemented so that the MLTS is fully capable when installed of dialing 911 directly and providing MLTS notification as required under the statute and rules. This does not preclude the inclusion of additional dialing patterns to reach 911. However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern. 47 C.F.R. § 9.3.

Pre-configured. An MLTS that comes equipped with hardware and/or software capable of establishing a setting that enables users to directly dial 911 as soon as the system is able to initiate calls to the PSTN. This does not preclude the inclusion of additional dialing patterns to reach 911. However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern. 47 C.F.R. § 9.3.

Alternative Location Information. Location information (which may be coordinate-based) sufficient to identify the caller’s civic address and approximate in-building location, including floor level, in large buildings. 47 C.F.R. § 9.3.

Registered Location. The most recent information obtained by a provider of interconnected VoIP service or telecommunications relay services (TRS), as applicable, that identifies the physical location of an end user. 47 C.F.R. § 9.3.

Read Time: 17 min
Jump to top of page

Wiley Rein LLP Cookie Preference Center

Your Privacy

When you visit our website, we use cookies on your browser to collect information. The information collected might relate to you, your preferences, or your device, and is mostly used to make the site work as you expect it to and to provide a more personalized web experience. For more information about how we use Cookies, please see our Privacy Policy.

Strictly Necessary Cookies

Always Active

Necessary cookies enable core functionality such as security, network management, and accessibility. These cookies may only be disabled by changing your browser settings, but this may affect how the website functions.

Functional Cookies

Always Active

Some functions of the site require remembering user choices, for example your cookie preference, or keyword search highlighting. These do not store any personal information.

Form Submissions

Always Active

When submitting your data, for example on a contact form or event registration, a cookie might be used to monitor the state of your submission across pages.

Performance Cookies

Performance cookies help us improve our website by collecting and reporting information on its usage. We access and process information from these cookies at an aggregate level.

Powered by Firmseek