appliedbits
LIBRARY  ·  Telecom regulation LIBRARY ENTRY
Last updated 2026-07-19 drafted

The architecture of all-IP 911 — ECRIT, NENA i3, and call identity

Where the 911-funding entry covers who pays for NG911, this one covers how it actually works — the standards that turn an emergency call into IP, route it to the right call center, and (in principle) prove who is calling.

The IP emergency-call model: IETF ECRIT

The internet-standards foundation for emergency calling is the IETF’s ECRIT (Emergency Context Resolution with Internet Technologies) work. Its logic is that an IP endpoint cannot rely on a dialed number to mean “emergency” — a number is just digits, and the device may be anywhere. So ECRIT separates the pieces:

  • The sos service URN (RFC 5031) marks a call as emergency independent of any dial string — urn:service:sos, with sub-services like urn:service:sos.police. The endpoint (or its proxy) recognizes the emergency intent and tags the call with the URN.
  • Location is represented as a PIDF-LO object (RFC 4119 for geodetic, RFC 5139 for civic addresses) and conveyed in the SIP signaling via the Geolocation header (RFC 6442), either by value or by reference.
  • LoST (RFC 5222), the Location-to-Service Translation protocol, takes that location plus the sos URN and returns the URI of the correct destination call center — and validates civic addresses in advance.
  • Additional data (RFC 7852) attaches structured caller, device, and service information.
  • RFC 6443 is the descriptive framework over all of it, and RFC 6881 (BCP 181, the “phone BCP”) is the normative behavioral profile telling endpoints and PSAPs exactly how to implement it.

Put together: an IP device recognizes it is dialing emergency, obtains its own location, asks LoST which PSAP serves that location, and sends a SIP INVITE to the sos URN with location and caller data attached. No selective routers, no fixed trunk assignments.

NENA i3: the North American profile

The FCC’s reference architecture is NENA i3 (NENA-STA-010), the North American operational profile that takes the IETF’s building blocks and specifies the network around them. i3 is SIP-based and explicitly profiles the ECRIT RFCs rather than reinventing them: its ECRF (Emergency Call Routing Function) and LVF (Location Validation Function) are LoST servers; location is PIDF-LO conveyed via SIP Geolocation; the sos URN marks the call. What i3 adds is the managed architecture — the ESInet (the IP transport), the NGCS core services (the ESRP routing proxy, policy store, border control), the GIS data model, and the security framework — that the deliberately-network-agnostic IETF work leaves out. The current published version is the 2021 i3 standard (NENA-STA-010.3).

The payoff over legacy 911 is real: routing on the caller’s actual location rather than a trunk assignment, native support for text and multimedia, and policy-based failover between PSAPs. The FCC’s 2024 NG911 Report and Order (FCC 24-78) mandates that originating providers deliver 911 in IP/SIP to ESInets on a request-driven schedule — the regulatory push behind this architecture.

Signing the emergency call: RPH, SPH, and RFC 9027

Here is where the identity story meets emergency calling — and where the standards are more complete than most people realize. Emergency and priority calls are marked in SIP with the Resource-Priority Header (RPH, RFC 4412), which carries values like the esnet namespace for emergency services. But RPH on its own is unauthenticated — anyone can assert priority.

STIR closes that gap in two layers. RFC 8443 (Standards Track) defines the rph PASSporT claim, letting a STIR signer cryptographically authorize the Resource-Priority values a call asserts. Then RFC 9027 — “Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks” (Dolly and Wendt, 2021) — extends this specifically for emergency networks. It adds emergency-services assertion values for the rph claim, and it defines a new sph claim — the SIP Priority Header claim — whose purpose is to protect the psap-callback marking. That is the answer to the “RPH/SPH” question: RPH signs the emergency priority of the inbound call; SPH signs the psap-callback marking so that when a PSAP calls a 911 caller back, downstream networks can cryptographically trust “this is a 911 callback” and not block or mislabel it. Both directions — subscriber-to-PSAP and PSAP-to-subscriber — can be authenticated.

ATIS has operationalized this for North America: ATIS-1000074 is the base SHAKEN framework, and ATIS-1000098 is the profile for signing the RPH and Priority headers in support of emergency calling.

STIR/SHAKEN at the PSAP: standardized, not yet deployed

The honest current-state answer is that the standards exist but the deployment does not. Inter-carrier SHAKEN coverage is high on the general PSTN-replacement path, but that does not mean a verified caller identity arrives at the PSAP. Today, 911 caller identity is still conveyed the legacy way — through ANI/pseudo-ANI and the location database (ALI/LIS) — not through a verified SHAKEN PASSporT. The 911 delivery path and its remaining legacy segments break the SIP Identity header, and the FCC’s active caller-ID-authentication work in 2025–2026 is aimed at the general non-IP gap, not at a 911-to-PSAP identity mandate. NENA i3 accommodates a validated Identity header at the ESInet border, so an i3 system can make use of signed identity where it is present — but nothing requires verified caller identity to reach the call-taker, and there is no evidence of broad production STIR/SHAKEN verification at PSAPs.

What’s ready, and what isn’t

For an all-IP 911 system in the US, the routing and call-model standards are mature and being mandated into deployment: ECRIT, NENA i3, and the FCC’s IP-delivery order give a complete path from an IP device to the correct PSAP. The identity layer is the gap — not for lack of standards (RFC 8443, RFC 9027, and the ATIS profiles are done) but for lack of deployment. The pieces to authenticate both the inbound emergency call and the PSAP callback are specified and waiting; what remains is carrying verified identity across the 911 delivery path and standing it up at the PSAP. That gap — complete standards, incomplete deployment — is the recurring shape of the whole all-IP transition, and it is nowhere sharper than in emergency calling.