Business phone numbers and phone menus for the United States and Canada. FRES(510) 288-6288[email protected]Sign in

Home › Research › NG911 transition

Research

NG911 and NG9-1-1: what the switch to IP emergency calling changes for business phones.

Next Generation 911 moves emergency calls onto IP networks and carries the caller's location inside the call itself. In the United States each 911 authority starts the clock, so there is no single national date; in Canada there is one, and the call centres are behind it. Both changes help a business with a well-run phone system. Neither fixes a wrong address, a softphone that has wandered off-site, or a callback number that lands on a phone menu.

Last checked 26 October 2026 · 31 cited sources · 21 min read

Next generation 911 emergency calling

The short version

For decades a 911 call has been a voice circuit steered by a selective router, with the caller's address looked up afterwards in a separate database. Next Generation 911 (NG911 in the US, NG9-1-1 in Canada) replaces that with IP networks run for emergency services, call routing driven by the caller's location, and location carried in the call signalling itself. For a business phone system the transition changes three things:

  • How your provider hands over the call. 911 traffic goes to the 911 authority in SIP, at delivery points the authority designates, instead of over legacy trunks into a selective router.1
  • How location travels. In the US rule's second phase, location is "embedded in the call signaling using Presence Information Data Format—Location Object (PIDF-LO) or the functional equivalent", and the provider must use a Location Information Server to verify its customer location records.1
  • What a caller can send. The networks are built for text, data and eventually video, not voice alone.2024

The dates differ by country. In the US, the FCC's 2024 rules have no nationwide switch-over date: each 911 authority triggers its own deadlines with a "valid request", and the provider then has six or twelve months per phase depending on its type.1 In Canada the CRTC set one national date: the legacy E9-1-1 networks are to be decommissioned by 31 March 2027, after which "only NG9-1-1 calls will be delivered".23

What NG911 does not change is who answers for your location data: if the address held for a desk phone, softphone or hosted extension is wrong, NG911 delivers the wrong address faster. Kari's Law and the FCC's dispatchable-location rules are on our emergency calling guide, with Canada's VoIP 9-1-1 duties in its Canada section. This piece goes into the NG911 layer underneath.

What NG911 is, in engineering terms

The FCC's definition, in 47 CFR § 9.28, lists six properties. NG911 is "an Internet Protocol-based system" that ensures interoperability, is secure, employs commonly accepted standards, "enables emergency communications centers to receive, process, and analyze all types of 911 requests for emergency assistance", acquires and integrates additional useful information, and supports sharing that information among emergency communications centres and responders.1

The ESInet. The transport is an Emergency Services IP Network: "an Internet Protocol (IP)-based network that is managed or operated by a 911 Authority or its agents or vendors and that is used for emergency services communications".1 In practice it is a managed network operated for the 911 authority, which originating carriers hand traffic to at the delivery points the authority designates.

The core services. On top of the ESInet sit the NG911 Core Services (NGCS), which, in the FCC's words, "collectively replace the caller location and routing functions of selective routers, ANI/ALI databases, and the MSAG in legacy 911 networks". They include a Location Validation Function, "a server that validates civic location information against a Geographic Information System (GIS) database", and an Emergency Call Routing Function that "determines the appropriate destination PSAP by mapping the caller's validated location within the boundaries of emergency response zones".5 Phase 2 also lets answering points "use policy routing functions to dynamically reroute 911 traffic to avoid network disruptions".2

The standard. The architecture is NENA's i3 standard. The current text is NENA-STA-010.3f-2021, which NENA describes as an "ANSI Approved Standard" giving "the detailed functional and interface specifications for a post-transition IP (Internet Protocol)-based multimedia telecommunications system, including the Core Services and legacy gateways". Version 3 moved data interactions between functional elements to a REST/JSON architecture and reworked call bridging, among other changes; NENA marks the standard as "Currently Under Revision".7 Canada uses the same architecture: the CRTC approved "the adoption of the National Emergency Number Association (NENA) i3 architecture standard for NG9-1-1 in Canada" in Telecom Decision 2015-531.26

The gateways. i3 "provides for Legacy Network Gateways (LNGs) and other transitional network elements to ensure that TDM-based OSPs can originate 911 calls and that legacy PSAPs can receive them while the NG911 transition is ongoing".2 The FCC's 2026 order describes the resulting "transitional NG911 networks", which "may retain selective routers, ANI/ALI, and other legacy elements as part of the call path".5

Location by value, location by reference

For anyone who runs a phone system, the most useful idea in NG911 is that location becomes part of the call. The IETF building blocks are old and stable:

  • PIDF-LO (RFC 4119) is "an object format for carrying geographical information on the Internet", extending the Presence Information Data Format.8 RFC 5139 replaced its civic address format with a richer one, adding elements such as building, unit and room to the existing floor and house-number fields.9
  • SIP location conveyance (RFC 6442) defines the Geolocation, Geolocation-Routing and Geolocation-Error header fields. The location object "may appear in a MIME body attached to the SIP request, or it may be a remote resource in the network".10
  • HELD (RFC 5985) is the protocol a device or server uses to get location "from a server within an access network", "in two forms: by value and by reference".11 RFC 6753 describes how a recipient holding a reference dereferences it over HTTPS to obtain the PIDF-LO.31
  • LoST (RFC 5222) maps "service identifiers and geodetic or civic location information to service contact URIs" and "can be used to determine the location-appropriate Public Safety Answering Point".12 The service identifier for emergency calls is urn:service:sos, which "reaches a public safety answering point (PSAP), which in turn dispatches aid appropriate to the emergency".13

The FCC's rules use the same vocabulary: a Location Information Server is "a functional element that provides locations of endpoints", which "can provide Location-by-Reference or Location-by-Value, and, if the latter, in geodetic or civic forms".1 By value means the PIDF-LO document rides inside the INVITE. By reference means the INVITE carries a URI, and the answering point fetches the current location from the provider's server when it needs it, which matters for a device that moves during the call.

A simplified example of a call from a desk phone with its location attached by value, using the RFC 6442 header and the RFC 5139 civic elements. It is illustrative, not a capture from any vendor: real i3 calls carry more headers and the exact profile is set by the 911 authority.109

INVITE urn:service:sos SIP/2.0
To: <urn:service:sos>
From: <sip:[email protected]>;tag=9fxced76sl
Geolocation: <cid:[email protected]>
Geolocation-Routing: yes
Content-Type: multipart/mixed; boundary=boundary1

--boundary1
Content-Type: application/sdp
...
--boundary1
Content-Type: application/pidf+xml
Content-ID: <[email protected]>

<presence xmlns="urn:ietf:params:xml:ns:pidf"
  xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
  xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
  entity="pres:[email protected]">
  <tuple id="ext214"><status><gp:geopriv>
    <gp:location-info>
      <ca:civicAddress>
        <ca:country>US</ca:country><ca:A1>OH</ca:A1>
        <ca:A3>Example City</ca:A3>
        <ca:RD>Main</ca:RD><ca:STS>Street</ca:STS><ca:HNO>100</ca:HNO>
        <ca:FLR>3</ca:FLR><ca:UNIT>310</ca:UNIT>
      </ca:civicAddress>
    </gp:location-info>
  </gp:geopriv></status></tuple>
</presence>
--boundary1--

The point for a business is the FLR and UNIT lines. Under legacy E911 the answering point gets a phone number and looks up whatever address was loaded into the ALI database for it. Under Phase 2 NG911, the floor and suite can travel with the call, and the civic address is checked against the 911 authority's GIS: under § 9.28 an address is valid only if it "can be located within the database uniquely, is suitable to provide an accurate route for an emergency call, and is adequate and specific enough to direct responders to the right location".1 An address that was accepted for years by the old street guide can fail that test, which is a good reason to ask your provider whether your service addresses have been validated.

The FCC's 2024 order: who must deliver what, and when

The FCC adopted its NG911 Report and Order (FCC 24-78, PS Docket Nos. 21-479 and 18-64) on 18 July 2024; it was published at 89 FR 78066 on 24 September 2024 and took effect on 25 November 2024.2 The rules are 47 CFR §§ 9.27 to 9.34. Their premise is that the FCC sets the providers' duties while state and local 911 authorities decide when they are ready, and the rules "preserve the authority of state, territorial, regional, Tribal, and local government to adopt alternative approaches".2

Who is bound. The duties fall on "originating service providers": wireline providers, mobile (CMRS) providers, covered text providers, "interconnected Voice over Internet Protocol (VoIP) providers, including all entities subject to subpart D", and internet-based relay providers that route 911 traffic.1 A business that runs its own PBX is not on that list. Its carrier or hosted VoIP provider is, which is why the questions at the end of this page are addressed to providers.

PhaseWhat the provider must do (47 CFR § 9.29)Where location comes from
Phase 1Deliver all 911 traffic "in the IP-based SIP format requested by the 911 Authority" to the designated NG911 Delivery Points, and complete connectivity testing.1Legacy means are still allowed: the provider pays for location and routing "using ALI/ANI databases, selective routers, or other means at Phase 1".1
Phase 2Deliver 911 traffic in SIP "that complies with NG911 commonly accepted standards identified by the 911 Authority", with location embedded as PIDF-LO "or the functional equivalent"; use a LIS "for the verification of its customer location information and records"; complete testing.1"using LIS functionalities or other equivalent means at Phase 2".1

Scroll the table sideways to see every column.

Provider type (47 CFR § 9.30)Phase 1 deadlinePhase 2 deadline
Non-rural wireline, nationwide mobile carriers, covered text providers, interconnected VoIP6 months after a Phase 1 valid request6 months after a Phase 2 valid request (or, if that request comes early, 6 months after Phase 1 compliance or the Phase 1 deadline, whichever is earlier)
Rural incumbent local exchange carriers, non-nationwide mobile carriers, internet-based relay providers12 months after a Phase 1 valid request12 months, on the same rule

Scroll the table sideways to see every column.

Every interconnected VoIP provider, however small, is in the six-month group.1 The FCC was not persuaded that VoIP providers would struggle with Phase 2 location: "interconnected VoIP providers already use a LIS functional element to transmit location information to 911 Authorities, subject to the NENA i2 standard".2

What makes a request valid. The 911 authority must certify that its receiving infrastructure is installed and operating, that its vendors are committed to finish testing in time, and that it is authorised to ask; it must name its delivery points and notify the provider, "via a registry made available by the Commission" or other acceptable written notice. For Phase 2 it must also certify a connection to "a fully functioning Next Generation 911 Core Services network".1 A provider that thinks a request is premature has 60 days to petition the FCC, by affidavit from a director or officer.1

Who pays. Providers pay to get their 911 traffic to the delivery points in the required format, "including the cost of IP conversion using a Legacy Network Gateway or the functional equivalent, if necessary"; they are "not responsible for the costs of furnishing, maintaining, or upgrading NG911 Delivery Points, ESInets, Next Generation 911 Core Services networks, or PSAPs".1 Providers and authorities can agree different terms, but the provider must notify the FCC within 30 days.1

The registry and petition parts needed approval from the federal Office of Management and Budget. The FCC announced that approval, and that compliance was now required, in a notice effective 25 March 2025.3

Where the US transition actually stands

The federal 911 program's data stops in 2021. The National 911 Program (911.gov) describes NG911 as "a digital, internet protocol (IP)-based system that will replace the analog 911 infrastructure" and points to its 911 Profile Database for state progress.20 The most recent National 911 Annual Report it lists is the one on 2021 data.21 That report says that "2,287 PSAPs reported using an ESInet across 47 states", up from 2,177 the year before; that 38 states said they had a statewide NG911 plan; and that 49 states reported 4,637 primary answering points.22 Using an ESInet is a long way from end-to-end i3, and the data is self-reported.22

The FCC's own read in 2024. When it adopted the rules, the FCC wrote that "there are no fully enabled NG911 systems yet operating", while noting that one carrier said it had achieved end-to-end readiness with two local jurisdictions.2

The registry is now the best public signal. In an April 2026 public notice the FCC's bureau reported that its NG911 valid-request registry "posted 95 filings prior to November 1, 2025", which staff estimate to be 72 Phase 1 valid requests once amendments and withdrawals are taken out, and 81 filings between 1 November 2025 and 31 January 2026, estimated at 58 Phase 1 requests. Only two Phase 2 requests had posted in that second window.4 The filings sit in FCC docket 25-143, so anyone can check whether their state or county has asked.4 The notice also reminds readers that authorities can notify providers directly, so the registry is not a complete list.4

The first deadlines are already slipping, and business phone systems are part of the reason. The same notice seeks comment on a Verizon petition to extend its Phase 1 deadlines for wireline service in Massachusetts and other jurisdictions to 30 June and 31 July 2026. In the bureau's summary, Verizon states that its wireline Phase 1 implementation "was largely complete" late in the first quarter of 2026, "but that additional time through mid-2026 will facilitate more seamless support for certain multi-line telephone system (MLTS) users' caller location functions". In the alternative it asks the FCC to "waive or forbear from enforcing relevant Part 9 requirements for affected MLTS managers and operators".4 We could not find a ruling on the petition as of the date of this page. The telling detail: the hard part for a large carrier was not the voice path but keeping business phone systems' per-extension location working.

Reliability rules followed in 2026. In a Second Report and Order adopted on 25 June 2026 (FCC 26-39, effective 10 August 2026), the FCC said it had "seen a corresponding increase in major, multi-state 911 service outages" during the transition, often "in parts of transitional NG911 systems outside the scope of the 911 reliability framework adopted in 2013". It brought all ESInet providers under its 911 reliability rules and replaced the annual reliability certification with a one-time one; several requirements await a further compliance-date notice.5 A companion proposal would require multi-party interstate interoperability testing and asks about Direct Video Calling.6

Canada: one national date, and the call centres behind it

Canada's approach mirrors the American one. The CRTC regulates the providers, not the call centres, and has set national dates; the call centres, a provincial, territorial and municipal responsibility, have struggled to keep up.23

The history. The framework is Telecom Regulatory Policy 2017-182. After the pandemic suspended its deadlines, Telecom Decision 2021-199 directed the NG9-1-1 network providers, and telecommunications service providers on networks technically capable of it, to be ready for NG9-1-1 voice by 1 March 2022, and the incumbent carriers to decommission the old 9-1-1 network components by 4 March 2025.25

The 2025 extension. On 28 February 2025, Telecom Decision CRTC 2025-67 moved that decommissioning date to 31 March 2027. Providers "have since made the necessary upgrades", it said, but "most provincial, territorial, and municipal emergency service organizations will not be able to make the necessary upgrades in time".23 The working-group report it relied on said that "only 3 of Canada's 242 PSAPs have launched NG9-1-1 services as of April 2024" and forecast that the vast majority would not finish before the end of 2026; it cited limited vendor capacity for testing and a shortage of technical expertise.23 The CRTC's consumer page puts it as a direction to "update their networks for NG9-1-1 voice services by March 31, 2027".24

The decision is blunt about what happens on the other side of that date. Legacy PSAP gateways "are not readily available in Canada", so any answering point that has not moved "will no longer be able to receive 9-1-1 calls"; such centres "must either complete their transition or make other arrangements", such as "consolidation, co-location, or outsourcing of call taking functions to an NG9-1-1 PSAP".23 The CRTC did not accept falling back to Basic 9-1-1, noting that it "cannot locate callers who are unable to verbally provide their location".23 It asked the emergency services chiefs for a province-by-province plan by 28 August 2025, and the industry working group for semi-annual status reports until March 2027.23

Who pays in the meantime. Until decommissioning, originating providers pay both the E9-1-1 and the NG9-1-1 wholesale rates (the "dual-rate model"), which the decision estimates will cost them "approximately $135-155 million" collectively over the extension. One carrier told the CRTC that some providers "may need to add a new 9-1-1 charge to customer bills or increase prices".23

Local VoIP is in scope. For this decision, telecommunications service providers include those offering "wireline and/or wireless local exchange telephone services, including local VoIP services".23 The CRTC's own VoIP 9-1-1 guidance tells local VoIP providers to consult Telecom Regulatory Policy 2017-182 "regarding upcoming next-generation 9-1-1 services".27

Text: real-time text, SMS, and two different bets

Text is where the two countries have diverged most visibly.

United States. Text-to-911 by SMS already exists under 47 CFR § 9.10(q), which binds "covered text providers": all mobile carriers plus interconnected text messaging services that reach "all or substantially all text-capable U.S. telephone numbers".16 Separately, the FCC's real-time text rules (Part 67) define RTT as text "transmitted over Internet Protocol (IP) networks immediately as they are created, e.g., on a character-by-character basis", and require covered services and devices to "transmit and receive RTT communications to and from any 911 public safety answering point (PSAP) in the United States", and to carry text and voice simultaneously on the same call.15 The reference protocol is RFC 4103.1415 Mobile carriers had to support location-based routing for RTT to 911 on their IP networks by 13 May 2026.16

Canada. The CRTC chose RTT and rejected SMS for NG9-1-1. In 2017 it found that SMS-based 9-1-1 texting, introduced as an interim service for Canadians who are Deaf, hard of hearing or speech impaired, "cannot be used without first placing a voice call", "is not IP-based", "cannot be directly routed to the appropriate PSAP", "does not provide location information" and is delivered on a best-effort basis, concluding that "SMS is therefore not an appropriate solution for the provision of NG9-1-1 Text Messaging in Canada".26 Standards for RTT callback and bridging were not ready by 2021, so the CRTC set no deadline then.25 Today its consumer page says only that "a deadline for providing NG9-1-1 real-time text messaging to the general public will be set at a later date".24

What it means for a business. The US Part 67 duty attaches to services already required to support RTT under other parts of the FCC's rules,15 and we found no rule in either country requiring a business PBX to originate RTT to 911. Our view: assume emergency text will go from staff members' own mobiles, not your desk phones.

Business phone systems are where location is most fragile

A multi-line telephone system has one main number, many extensions, sometimes several buildings, and staff who take a softphone home. Location has always been weakest there, and NG911 moves the weak point rather than removing it.

US rules already require location from the system. Since 2021 for fixed desk phones and 2022 for non-fixed and off-premises devices, an MLTS must convey dispatchable location to the answering point: automated for fixed on-premises phones, and for off-premises devices automated "if technically feasible", otherwise a manual update or "the best available location that can be obtained from any available technology or combination of technologies at reasonable cost".19

NG911 changes the seam. Under Phase 2, the originating provider must deliver PIDF-LO and use a LIS to verify customer location records.1 For a hosted PBX that is one company's problem end to end. For a premises PBX on a SIP trunk, the per-extension location the PBX knows has to reach the carrier's LIS or be inserted into the call in a form the carrier will pass through. The Verizon petition described above is the first public sign that this seam is where IP delivery gets hard.4 Our view: by-reference location from the provider's LIS is the most robust design for business systems, because the answering point can fetch the current location rather than whatever was loaded months ago; but it only works if the enterprise feeds that LIS, and no rule we found tells you how.

The VoIP rule has not been rewritten for NG911. The interconnected VoIP 911 rule, 47 CFR § 9.11, was amended in January 2026 but still applies "only to 911 calls placed by users whose dispatchable location is in a geographic area served by a Wireline E911 Network", which by definition "includes a selective router", and still has location "available ... from or through the appropriate automatic location information (ALI) database".1718 The NG911 subpart sits alongside it.1 We read this as a transitional overlap rather than a gap in obligations, but the plain text of the VoIP rule describes a network that is being retired.

Canada has no MLTS law. The CRTC's industry working group identified US-style measures (direct 9-1-1 dialling, on-site notification and "a dispatchable location requirement be established for MLTS 9-1-1 calls") but noted that "direct regulation of MLTS by the Commission is not feasible because Canada, unlike the United States, does not have federal or provincial legislation applicable to MLTS". The CRTC approved the resulting best practices in Telecom Decision 2022-265.28 In 2023 it opened a proceeding on "Enabling direct 9-1-1 and 9-8-8 calls from multi-line telephone systems", warning that it "may impose obligations on providers of any telecommunications services that involve an MLTS" and "may also implement rules that would impact any organization that uses an MLTS".29 The CRTC's list of 9-1-1 decisions, in the most recent copy we could read (August 2025), shows no decision closing that proceeding.30 We could not check the list for anything since then.

Where the gaps remain: nomadic VoIP and forwarding services

NG911 is a better pipe. Several of the ways business 911 calls go wrong sit upstream of it.

Nomadic VoIP still depends on the user. For non-fixed interconnected VoIP in the US, the rule's ladder is automated dispatchable location "if technically feasible", otherwise a Registered Location the user can update, alternative location information, or routing "the caller to a national emergency call center".17 The rule also allows calls to be routed "first to a national emergency call center to ascertain the caller's location" when the provider cannot obtain or confirm it.17 Canada's model customer notice for nomadic VoIP is starker: "your 9-1-1 call is forwarded to a third-party service provider that will automatically or manually route your call", and "you must immediately inform the emergency operator of your location".27 The CRTC also requires providers to have default call routing to a third-party call centre "such as those used for nomadic voice over Internet Protocol (VoIP) calls".25 None of this changes when the answering point upgrades: a softphone in a hotel still reports whatever location the user last registered, unless the provider can work it out from the network.

Power and the internet. The CRTC's model notice warns that VoIP 9-1-1 depends "on Internet connectivity and power to function" and recommends keeping "an alternative phone service (such as a cellular telephone) handy".27 An ESInet with automatic failover does nothing for the office whose router is on the same circuit as the kettle.

Forwarding services. Many small businesses have no desk phones: the business number rings staff mobiles through forwarding, a ring group or an auto attendant. A 911 call then comes from the mobile itself, under the wireless location rules. Nationwide US carriers have had to deploy location-based routing for wireless 911 voice calls on their IP networks since 13 November 2024, and non-nationwide carriers since 13 May 2026.16 Our view: for a small team, a 911 call from a modern mobile is usually better located than one from a desk phone on a badly maintained PBX. The gaps are elsewhere:

  • Softphone apps that dial out. If staff use a VoIP app to place outbound calls "from" the business number, a 911 call made in that app is a nomadic VoIP call, with the Registered Location limits above, not a mobile 911 call. Ask how the app handles 911. The safest answer is that it hands the call to the phone's native dialler.
  • The callback number. The FCC's definitions note that ANI "identifies the calling party and may be used as the callback number".18 If an outbound system presents the main business number on a 911 call, a dispatcher who calls back reaches your phone menu or voicemail, not the person who called. We could not find a rule that addresses this for small hosted systems, and NG911 carries whatever number it is given. Check what number your system sends on a 911 call.
  • Inbound-only services. A service that only receives calls and rings mobiles, such as Auto Attendant, cannot place a 911 call at all, and should say so plainly. Its emergency calling story is the mobile carrier's, which is the point of our emergency calling page.

What a small business should check with its providers

This needs a list of your phone services and a few written answers, not a consultant.

  1. List every way someone in your business can dial 911 or 9-1-1: desk phones, analog lines (alarm and lift lines included), softphones, mobiles, and any app that places calls. Next to each, write who the originating provider is. That provider carries the NG911 duties.1
  2. Ask each VoIP or wireline provider whether your 911 authority has sent it a Phase 1 or Phase 2 request, and when it delivered or will deliver. US filings are public in FCC docket 25-143, though not every request goes through the registry.4
  3. Ask whether your service addresses have been validated against the 911 authority's GIS (the Location Validation Function), not just accepted by the old database, and whether floor and suite are stored.1
  4. For a PBX or hosted system with several floors or sites, ask how per-extension location reaches the provider. Is it location by reference from the provider's LIS, a PIDF-LO the PBX inserts, or a legacy per-number database? Who updates it when someone moves desks?419
  5. For softphones and remote staff, ask what happens on a 911 call from an unregistered location. Is the user prompted to update, is location derived automatically, or does the call go to a national or third-party call centre?1727
  6. Check the callback number your system sends on a 911 call, and make sure a dispatcher calling it back reaches the caller or someone on site, not a menu.18
  7. In Canada, ask your provider what the 31 March 2027 decommissioning means for your lines, whether its 9-1-1 charges will change, and, for nomadic VoIP, how calls are routed through its third-party call centre.2327
  8. Get the written 911 or 9-1-1 limitations notice for each VoIP service. Both countries require one for services with limitations.1727

Our view

Where the transition clearly improves safety. Location as part of the call, checked against GIS and able to carry floor and suite, is a real improvement over a phone number looked up in a database loaded by hand. Policy routing around a failed centre or link is a resilience gain the selective-router design could not offer.25 Canada's one standard and one national date make the end state unambiguous.2326

Where we think it falls short. First, the US timetable is demand-driven, so the improvement arrives county by county, and the public data to tell a business where it stands is either years old or buried in a docket.214 Second, the new networks bring new failure modes. The FCC says outright that multi-state outages rose during the transition.5 Third, the hardest problems for businesses are not in the network at all: stale registered addresses, softphones off-site, nomadic VoIP that still ends at a call centre asking "where are you?", and callback numbers that reach a menu. NG911 carries these faithfully; it does not correct them. Fourth, in Canada, a firm decommissioning date for the network still has no binding MLTS rules and no date for public RTT behind it.242830

The practical conclusion is unexciting: keep an accurate list of where your phones are, make your providers tell you in writing how each one handles 911, and make sure the team knows that a mobile is usually the most reliable way to call for help. The network work is happening without you; the location data your provider holds for your business is something only you can keep accurate.

Further reading

Longer research pieces on this topic, each with its own source list and a downloadable PDF.

Sources

Every regulatory and pricing claim on this page links to the primary source it came from. Figures were checked on the date shown at the top of the page; rules and prices change, so verify before relying on one.

  1. 47 CFR Part 9, Subpart J (§§ 9.27-9.34), Next Generation 911: definitions (ESInet, LIS, LVF, NG911, originating service providers), Phase 1 and Phase 2 requirements, deadlines, valid requests, petitions, delivery points, cost responsibilities, mutual agreements. Source: 89 FR 78128, as amended at 90 FR 13557. Current edition (read through the eCFR API, version of 22 Oct 2026), retrieved 26 Oct 2026
    https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9/subpart-J
  2. FCC, Facilitating Implementation of Next Generation 911 Services (NG911), Report and Order, FCC 24-78, PS Docket Nos. 21-479 and 18-64, 89 FR 78066 (24 September 2024): adoption date, effective date, Phase 1/2 rationale, i3 and Legacy Network Gateways, VoIP LIS finding, state of the transition. Federal Register, retrieved 26 Oct 2026
    https://www.federalregister.gov/documents/2024/09/24/2024-18603/facilitating-implementation-of-next-generation-911-services-ng911-location-based-routing-for
  3. FCC, NG911 Report and Order: OMB approval and announcement of compliance date, 90 FR 13556 (25 March 2025). Federal Register, retrieved 26 Oct 2026
    https://www.federalregister.gov/documents/2025/03/25/2025-04833/facilitating-implementation-of-next-generation-911-services-ng911-location-based-routing-for
  4. FCC Public Safety and Homeland Security Bureau, DA 26-407, Bureau Seeks Comment on Verizon Petition for Waiver of NG911 Phase 1 Deadlines, PS Docket Nos. 21-479 and 25-143 (released 24 April 2026): registry filing counts, MLTS caller-location issue. Retrieved 26 Oct 2026
    https://docs.fcc.gov/public/attachments/DA-26-407A1.txt
  5. FCC, Facilitating Implementation of NG911; Improving 911 Reliability, Second Report and Order, FCC 26-39 (adopted 25 June 2026), 91 FR 42794 (10 July 2026), effective 10 August 2026: NG911 Core Services, transitional networks, multi-state outages, ESInet providers as covered 911 service providers, one-time certification. Federal Register, retrieved 26 Oct 2026
    https://www.federalregister.gov/documents/2026/07/10/2026-13998/facilitating-implementation-of-next-generation-911-services-ng911-improving-911-reliability
  6. FCC, Facilitating Implementation of NG911; Improving 911 Reliability, Further Notice of Proposed Rulemaking, 91 FR 42699 (10 July 2026): interstate interoperability testing, Direct Video Calling. Federal Register, retrieved 26 Oct 2026
    https://www.federalregister.gov/documents/2026/07/10/2026-13999/facilitating-implementation-of-next-generation-911-services-ng911-improving-911-reliability
  7. NENA: The 9-1-1 Association, i3 standards page: NENA-STA-010.3f-2021, NENA i3 Standard for Next Generation 9-1-1 (ANSI approved; version 3 changes; "Currently Under Revision"). Retrieved 26 Oct 2026
    https://www.nena.org/page/i3_Stage3
  8. IETF RFC 4119, A Presence-based GEOPRIV Location Object Format (PIDF-LO), December 2005. Retrieved 26 Oct 2026
    https://www.rfc-editor.org/rfc/rfc4119
  9. IETF RFC 5139, Revised Civic Location Format for PIDF-LO, February 2008 (civic elements including FLR, ROOM, UNIT, BLD). Retrieved 26 Oct 2026
    https://www.rfc-editor.org/rfc/rfc5139
  10. IETF RFC 6442, Location Conveyance for the Session Initiation Protocol, December 2011 (Geolocation header fields; location by value or in the network). Retrieved 26 Oct 2026
    https://www.rfc-editor.org/rfc/rfc6442
  11. IETF RFC 5985, HTTP-Enabled Location Delivery (HELD), September 2010 (location by value and by reference). Retrieved 26 Oct 2026
    https://www.rfc-editor.org/rfc/rfc5985
  12. IETF RFC 5222, LoST: A Location-to-Service Translation Protocol, August 2008. Retrieved 26 Oct 2026
    https://www.rfc-editor.org/rfc/rfc5222
  13. IETF RFC 5031, A Uniform Resource Name (URN) for Emergency and Other Well-Known Services (urn:service:sos). Retrieved 26 Oct 2026
    https://www.rfc-editor.org/rfc/rfc5031
  14. IETF RFC 4103, RTP Payload for Text Conversation, June 2005 (real-time text, ITU-T T.140). Retrieved 26 Oct 2026
    https://www.rfc-editor.org/rfc/rfc4103
  15. 47 CFR Part 67, Real-Time Text (§§ 67.1-67.3): definitions, RTT to any 911 PSAP, RFC 4103. Current edition (read through the eCFR API), retrieved 26 Oct 2026
    https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-67
  16. 47 CFR § 9.10, 911 service (CMRS): (q) text-to-911 and covered text providers; (s) location-based routing deadlines for voice and RTT. Current edition (read through the eCFR API), retrieved 26 Oct 2026
    https://www.ecfr.gov/current/title-47/section-9.10
  17. 47 CFR § 9.11, E911 service for interconnected VoIP (scope, non-fixed location options, national emergency call center, customer notification). As amended at 91 FR 1403, 14 January 2026. Current edition (read through the eCFR API), retrieved 26 Oct 2026
    https://www.ecfr.gov/current/title-47/section-9.11
  18. 47 CFR § 9.3, Definitions (ANI as callback number, dispatchable location, Registered Location, Wireline E911 Network). Current edition (read through the eCFR API), retrieved 26 Oct 2026
    https://www.ecfr.gov/current/title-47/section-9.3
  19. 47 CFR § 9.16, Multi-line telephone systems: direct dialling, notification and dispatchable location. Current edition (read through the eCFR API), retrieved 26 Oct 2026
    https://www.ecfr.gov/current/title-47/section-9.16
  20. National 911 Program (911.gov), Next Generation 911. Last updated 15 May 2025. Retrieved 26 Oct 2026
    https://www.911.gov/issues/ng911/
  21. National 911 Program (911.gov), National 911 Annual Report page (latest listed: 2021 data). Last updated 21 February 2023. Retrieved 26 Oct 2026
    https://www.911.gov/projects/national-911-annual-report/
  22. National 911 Program and NASNA, National 911 Annual Report: 2021 Data (ESInet use, statewide NG911 plans, primary PSAP counts). Retrieved 26 Oct 2026
    https://www.911.gov/assets/2021-911-Profile-Database-Report_FINAL.pdf
  23. Telecom Decision CRTC 2025-67, Various applicants – Updated timeline for full transition to Next-Generation 9-1-1 (Gatineau, 28 February 2025). Read via an Internet Archive copy (the CRTC site blocks automated access), snapshot of 10 Mar 2026; read 26 Oct 2026
    https://crtc.gc.ca/eng/archive/2025/2025-67.htm
  24. CRTC, Next-generation 9-1-1 (consumer page). Date modified 28 February 2025. Read via an Internet Archive copy (the CRTC site blocks automated access), snapshot of 1 Oct 2026; read 26 Oct 2026
    https://crtc.gc.ca/eng/phone/911/gen.htm
  25. Telecom Decision CRTC 2021-199, Establishment of new deadlines for Canada's transition to next-generation 9-1-1 (Ottawa, 14 June 2021). Read via an Internet Archive copy (the CRTC site blocks automated access), snapshot of 9 Mar 2026; read 26 Oct 2026
    https://crtc.gc.ca/eng/archive/2021/2021-199.htm
  26. Telecom Regulatory Policy CRTC 2017-182, Next-generation 9-1-1 – Modernizing 9-1-1 networks to meet the public safety needs of Canadians (1 June 2017): NENA i3 adoption, RTT chosen over SMS. Read via an Internet Archive copy (the CRTC site blocks automated access), snapshot of 9 Mar 2026; read 26 Oct 2026
    https://crtc.gc.ca/eng/archive/2017/2017-182.htm
  27. CRTC, 9-1-1 Obligations of Local VoIP Service Providers in Canada (including the model customer notification for nomadic and fixed/non-native VoIP). Read via an Internet Archive copy (the CRTC site blocks automated access), snapshot of 9 Mar 2026; read 26 Oct 2026
    https://crtc.gc.ca/eng/phone/911/voip.htm
  28. Telecom Decision CRTC 2022-265, CISC ESWG consensus report ESRE0074b on multi-line telephone systems in E9-1-1 and NG9-1-1 (26 September 2022). Read via an Internet Archive copy (the CRTC site blocks automated access), snapshot of 13 Aug 2025; read 26 Oct 2026
    https://crtc.gc.ca/eng/archive/2022/2022-265.htm
  29. Telecom Notice of Consultation CRTC 2023-156, Call for comments – Enabling direct 9-1-1 and 9-8-8 calls from multi-line telephone systems (23 May 2023). Read via an Internet Archive copy (the CRTC site blocks automated access), snapshot of 13 Jun 2024; read 26 Oct 2026
    https://crtc.gc.ca/eng/archive/2023/2023-156.htm
  30. CRTC, Policies, decisions and orders for 9-1-1 services (list of 9-1-1 decisions). Read via an Internet Archive copy (the CRTC site blocks automated access), snapshot of 3 Aug 2025 (no later copy available); read 26 Oct 2026
    https://crtc.gc.ca/eng/phone/911/pol.htm
  31. IETF RFC 6753, A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD), October 2012. Retrieved 26 Oct 2026
    https://www.rfc-editor.org/rfc/rfc6753