RFC 6443
Framework for Emergency Calling Using Internet Multimedia
RFC 6443: Framework for Emergency Calling Using Internet Multimedia 🚨📞
Part 1 of 10, bestie! ✨ This RFC is the big picture on how emergency calls work over the Internet 💖 It's Informational (so it's a guide, not a strict standard 🎀), published in December 2011 🌸 It's written by B. Rosen (NeuStar) 🦋, H. Schulzrinne (Columbia U.) 💜, J. Polk (Cisco Systems) 👑, and A. Newton (TranTech/MediaSolv) 🧚. The ISSN is 2070-1721. Nothing in the title block says it obsoletes or updates any other RFC, so it's a fresh start 💅
Abstract ✨
okay so the IETF has already standardized a bunch of pieces that make emergency calls possible 🌈 This document is the glue 🫶 It explains how all those pieces work together so that citizens and visitors can reach the authorities 🚨
Status of This Memo 🎀
This document is not an Internet Standards Track specification 💅 It's published just for information 💖
This is an IETF product, so it represents the consensus of the IETF community ✨ It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🔥 Not everything the IESG approves is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🧚
For the current status, any errata, and how to give feedback, head to http://www.rfc-editor.org/info/rfc6443 🦋
Copyright Notice 🌸
Copyright (c) 2011 IETF Trust and the persons identified as the document authors 🫶 All rights reserved 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info (as they stood on the publication date) 📜 Please actually read those, bestie, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💀
Table of Contents 🧚
Here's the full map of what's coming in the rest of the parts 🗺️ (the page numbers are from the original, so they won't match up perfectly with my version 🙈)
1. Introduction ....................................................3
2. Terminology .....................................................6
3. Overview of How Emergency Calls Are Placed ......................8
4. Which Devices and Services Should Support Emergency Calls? .....12
5. Identifying an Emergency Call ..................................12
6. Location and Its Role in an Emergency Call .....................14
6.1. Types of Location Information .............................16
6.2. Location Determination ....................................17
6.2.1. User-Entered Location Information ..................17
6.2.2. Access Network "Wire Database" Location
Information ........................................18
6.2.3. End System Measured Location Information ...........19
6.2.4. Network Measured Location Information ..............19
6.3. Who Adds Location, Endpoint, or Proxy? ....................20
6.4. Location and References to Location .......................20
6.5. End System Location Configuration .........................21
6.6. When Location Should Be Configured ........................22
6.7. Conveying Location ........................................23
6.8. Location Updates ..........................................24
6.9. Multiple Locations ........................................24
6.10. Location Validation ......................................25
6.11. Default Location .........................................26
6.12. Location Format Conversion ...............................26
7. LIS and LoST Discovery .........................................26
8. Routing the Call to the PSAP ...................................27
9. Signaling of Emergency Calls ...................................29
9.1. Use of TLS ................................................29
9.2. SIP Signaling Requirements for User Agents ................30
9.3. SIP Signaling Requirements for Proxy Servers ..............30
10. Call Backs ....................................................30
11. Mid-Call Behavior .............................................31
12. Call Termination ..............................................31
13. Disabling of Features .........................................32
14. Media .........................................................32
15. Testing .......................................................32
16. Security Considerations .......................................33
17. Acknowledgments ...............................................33
18. Informative References ........................................34Next up is Part 2, where we get into the Introduction and Terminology! 🎀💖
1. Introduction ✨
okay so calling for help in an emergency on a phone (landline or mobile) is a totally normal thing in lots of parts of the world 📞. And bestie, as devices keep using the Internet to connect and talk, users are going to expect to use those devices to ask for help too 💖. This document describes how a user sets up a communications session to a "Public Safety Answering Point" (PSAP), which is basically a call center run by response agencies to pick up emergency calls 🚨. These citizen-/visitor-to-authority calls are different from the ones responders make to each other (authority-to-authority) over public communications infrastructure, which often involves some kind of priority access defined in Emergency Telecommunications Service (ETS) in IP Telephony [RFC4190] 🎀. They're also different from emergency warning systems, which go authority-to-citizen 📢.
Supporting emergency calling takes teamwork from a bunch of elements, their vendors, and service providers 🫶. This document covers how end devices and apps create emergency calls, how access networks supply location for some of these devices, how service providers help with establishment and routing, and how PSAPs receive calls from the Internet 🌐.
The emergency response community will have to upgrade their facilities to support a wider range of communications services, but they can't be expected to handle wild variations in device and service capability 😭. New devices and services are popping up that could be used to ask for help, and they're not traditional telephones, and users are increasingly expecting to use them for emergency calls 📱. The thing is, many of the technical perks of Internet multimedia mean we have to rethink the traditional emergency calling architecture 🧠. It's also a chance to improve how emergency calling technology works, while potentially lowering its cost and complexity 💅.
It's beyond the scope of this document to list and discuss all the differences between traditional (Public Switched Telephone Network) and IP-based telephony, but calling on the Internet is characterized by:
- interleaving over the same infrastructure of a wider variety of services;
- separation of the access provider from the application provider;
- media other than voice (for example, video and text in several forms);
- potential mobility of all end systems, including endpoints nominally thought of as fixed systems and not just those using radio access technology. For example, consider a wired phone connected to a router using a mobile data network such as Evolution Data Optimized (EV-DO) as an uplink. 🦋
This document focuses on how devices using the Internet can place emergency calls, and how PSAPs can handle Internet multimedia emergency calls natively 🌸. It doesn't describe how circuit-switched PSAPs can handle Voice over IP (VoIP) calls. In many cases, PSAPs making the move from circuit-switched interfaces to packet-switched interfaces may be able to use some of the mechanisms described here, combined with gateways that translate packet-switched calls into legacy interfaces, e.g., so they can keep using existing call taker equipment 🔧. There are lots of legacy telephone networks that will stick around long after most systems have been upgraded to IP origination and termination of emergency calls 🙈. Many of these legacy systems route calls based on telephone numbers. Gateways and conversions between existing systems and the newer systems defined by this document will be required. Since existing systems are governed primarily by local government regulations and national standards, the gateway and conversion details will be governed by national standards too, so they are out of scope for this document 🌍.
Existing emergency call systems are organized locally or nationally, and there are currently few international standards 🗺️. However, the Internet crosses national boundaries, so Internet standards are required. To make things even more complicated, VoIP endpoints can be connected through tunneling mechanisms such as virtual private networks (VPNs). Tunnels can obscure the identity of the actual access network that knows the location 🙃. This seriously complicates emergency calling, because the location of the caller and the first element that routes emergency calls can be on different continents, with different conventions and processes for handling emergency calls 🌏.
The IETF has historically not created national variants of its standards 💜. So this document tries to take into account best practices that have evolved for circuit-switched PSAPs, but it makes no assumptions about particular operating practices currently in use, numbering schemes, or organizational structures 🎀.
This document discusses the use of the Session Initiation Protocol (SIP) [RFC3261] by PSAPs and calling parties. Other inter-domain call signaling protocols may be used for emergency calling, but SIP is ubiquitous and has the proper support for this use case ✨. Only protocols such as H.323, XMPP/Jingle, ISUP, and SIP are suitable for inter-domain communications, which rules out Media Gateway Controller protocols such as the Media Gateway Control Protocol (MGCP) or H.248/Megaco 🚫. The latter protocols can be used by the enterprise or carrier placing the call, but any such call would reach the PSAP through a media gateway controller, similar to how inter-domain VoIP calls would be placed 📞. Other signaling protocols may also use protocol translation to communicate with a SIP-enabled PSAP. Peer-to-peer SIP (p2psip) is not considered in this document 🙅♀️.
Existing emergency services rely exclusively on voice and conventional text telephony ("TTY") media streams 📼. But more media choices offer extra ways to communicate, evaluate the situation, and assist callers and call takers in making and handling emergency calls, respectively 💬. For example, instant messaging and video could improve the ability to communicate and evaluate the situation, and provide appropriate instruction before emergency crews arrive 🚑. So the architecture described here supports the creation of sessions of any media type, negotiated between the caller and PSAP using existing SIP mechanisms [RFC3264] 🥰.
This document focuses on the case where all three steps in the emergency calling process (location configuration, call routing, and call placement) can be, and are, performed by the calling endpoint, with the endpoint's Access Service Provider supporting the process by providing location information 📍. In this case, calls may be routed via an application-layer Communications Service Provider (e.g., a Voice Service Provider), but they don't need to be. The underlying protocols can also be used to support other models where parts of the process are delegated to the Communications Service Provider. This document doesn't address those models in detail, or the interoperability issues between them and the model described here 🤷♀️.
Since this document is a framework document, it does not include normative behavior 📋. [PHONEBCP] describes the best current practice for this subject and contains normative language for devices as well as access and calling network elements 📚.
Supporting emergency calling doesn't require any specialized SIP header fields, request methods, status codes, message bodies, or event packages 🙌. It does require that existing mechanisms be used in certain specific ways, as described below. User agents (UAs) unaware of the recommendations in this document may be able to place emergency calls, but functionality may be impaired. For example, if the UA doesn't implement the location mechanisms described, an emergency call may not be routed to the correct PSAP. And if the caller is unable to supply their exact location, dispatch of emergency responders may be delayed 😰. Suggested behavior for both endpoints and servers is provided 💡.
From the PSAP's point of view, three essential elements characterize an emergency call 🎯:
- The call is routed to the most appropriate PSAP, based primarily on the location of the caller.
- The PSAP must be able to automatically obtain the location of the caller with sufficient accuracy to dispatch a responder to help the caller.
- The PSAP must be able to re-establish a session to the caller if for any reason the original session is disrupted.
These three things are the whole vibe for the PSAP, so every design choice in the rest of this doc is basically chasing them 💅🔥
2. Terminology ✨
okay bestie, this section is where the document gets its vocab sorted 🎀 it borrows a bunch of terms from [RFC3261], [RFC5222], and [RFC5012], and then adds its own list of extra terms for emergency calling 📞💖
Access network 🌐
an access network is what gives an endpoint its IP packet service 🛜 examples you might actually recognize are digital subscriber lines (DSLs), cable modems, IEEE 802.11, WiMaX, enterprise local area networks, and cellular data networks 🦋
Confidence 🎯
confidence is how sure the measuring system is that the endpoint is really inside the bounds set by the uncertainty value 💅 it's written as a percentage, so a value of 90% means the actual location is within the uncertainty nine times out of ten ✨ main character accuracy 😭
Dispatch location 🚨
the dispatch location is where responders get sent to find the person who needs help 🫶 it has to be sufficiently precise to easily locate the caller, so it typically needs to be more accurate than the routing location 🌸 no cap, this one is the big deal
Location configuration 📍
during location configuration, an endpoint learns its physical location 🧚
Location Configuration Protocol (LCP) 📡
LCP is the protocol an endpoint uses to learn its location 💜
Location conveyance 🎀
location conveyance is when location information gets delivered to another element 💌
Location determination 🛰️
location determination is how an endpoint finds out where it's physically located 🔥 the endpoint might have a Global Navigation Satellite System (GNSS) receiver to measure its own location, or a network administrator might figure it out using a wiremap database 🗺️ both are giving real "knows exactly where you are" energy
Location Information Server (LIS) 🗄️
a Location Information Server stores location information so an authorized entity can retrieve it later 🔐 very secure, very organized 💅
Mobile device 📱
a mobile device is a user agent that can change its physical location and possibly its network attachment point during an emergency call 🦋 it's literally the one that moves around while it's calling for help 🏃♀️
National Emergency Number Association (NENA) 🇺🇸
NENA is an organization of professionals who "foster the technological advancement, availability and implementation of a universal emergency telephone number system in North America" 🌈 they develop emergency calling specifications and procedures, so they're basically the rule-writers of 911-land 👑
Nomadic device (user) 🧳
a nomadic user agent is connected to the network temporarily, for relatively short durations, but doesn't move significantly during the emergency call 🌸 examples are a laptop on an IEEE 802.11 hotspot, or a desk IP phone that gets moved from one cubicle to another every once in a while 🪑
Physical location 🌍
a physical location describes where a person or device is in physical space, using a coordinate system 🧭 it's different from the network location, which is described by a network address 🙈 not the same thing, babe
Public Safety Answering Point (PSAP) 📞
a PSAP is a call center that answers emergency calls 🚑 the people on the other end of the line who are ready to help 🫶
Routing location 🛤️
the routing location of a device is used for routing an emergency call, and it may not be as precise as the dispatch location 💀 so it's the "get the call to the right place" location, not the "send the ambulance to the exact door" one 🚒
Stationary device 🏠
a stationary device is not mobile, and it's connected to the network at a fixed, long-term-stable physical location 🏡 examples include home PCs or pay phones ☎️
Uncertainty 🫧
uncertainty is an estimate, written in a unit of length, that gives the diameter of a circle containing the endpoint with the probability shown by the confidence value 💜 it's the "how big is the bubble we're pretty sure you're in" number ✨
3. Overview of How Emergency Calls Are Placed ✨
Okay so here's the big picture 🗺️. An emergency call gets its own special label, a unique service URN [RFC5031], which goes into the call setup signaling as soon as a home or visited emergency dial string shows up 📞. Why does that matter? Emergency help is local, so the police in one city aren't the ones who can help you in another. That means the caller has to know where they are (Section 5) before they dial 📍. The location (Section 6) comes from one of two places. Either it's measured, for example with GNSS (Section 6.2.3), or the endpoint gets configured (Section 6.5) with its location from the access network's Location Information Server (LIS) through a Location Configuration Protocol (LCP). Then the location rides along in the SIP signaling with the call (Section 6.7) 💌. The call is routed (Section 8) based on that location using the Location-to-Service Translation (LoST) protocol [RFC5222], which maps a location to a set of PSAP URIs 🗺️. Each URI resolves to a PSAP or to an Emergency Services Routing Proxy (ESRP), the incoming proxy for a group of PSAPs. The call lands at the PSAP with the location included in the INVITE request 🎀.
Here's a quick run-through for a typical Ethernet-connected phone using SIP signaling. It's just one set of choices out of the various options we'll get into later, so don't panic if your setup looks different 🌸.
- The phone "boots" and connects to its access network 🔌.
- The phone gets its location via a Location Configuration Protocol (LCP), for example from the DHCP server in civic [RFC4776] and/or geo [RFC6225] forms, a HTTP-Enabled Location Delivery (HELD) server [RFC5985], or the first-level switch's Link-Layer Discovery Protocol (LLDP) server [LLDP] 📡.
- The phone grabs the local emergency dial string(s) from the LoST [RFC5222] server for its current location. It also receives and caches the PSAP URI that comes back from the LoST server 💾.
- Some time later, the user places an emergency call 🚨. The phone spots an emergency call from the dial strings and uses the "urn:service:sos" [RFC5031] URN to mark it as one.
- It refreshes its location via DHCP and updates the PSAP's URI by querying the LoST mapping server with that location 🔄.
- It puts its location in the SIP INVITE request in a Geolocation header [RFC6442], then forwards the call using its normal outbound call processing, which commonly involves an outbound proxy 🚀.
- The proxy recognizes the call as an emergency call and routes it using normal SIP routing mechanisms to the URI specified 🧭.
- The call routing commonly goes through an incoming proxy server (ESRP) in the emergency services network. That proxy then routes the call to the PSAP 🏢.
- The call is established with the PSAP, and mutually agreed upon media streams are created 🎶.
- The location of the caller is displayed to the call taker 👀.
Configuration Servers
. . . . . . . . . . . . . . . . .
. .
. +--------+ +----------+ .
. +--------+ | +----------+ | .
. | LIS | | | SIP | | .
. | |-+ | Registrar|-+ .
. +--------+ +----------+ .
. ^ ^ .
. . | . . . . . . . | . . . . . .
| |
|[M1][M4] |[M2]
| | +--------+
|+--------------+ +--------+ |
|| | LoST | |
||+-------------------->| Servers|-+
||| [M3][M5] +--------+ +-------+
||| | PSAP2 |
||| +-------+
|||
||| [M6] +-------+ [M7]+------+ [M8]+-------+
Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call Taker
+-------+ +------+ +-------+
+-------+
| PSAP3 |
+-------+
Figure 1: Emergency Call Component TopologyThe typical message flow for this example, using Alice as the caller, goes like this 💌:
[M1] Alice -> LIS: LCP Request(s) (ask for location)
LIS -> Alice: LCP Reply(s) (replies with location)
[M2] Alice -> Registrar: SIP REGISTER
Registrar -> Alice: SIP 200 OK (REGISTER)
[M3] Alice -> LoST Server: Initial LoST Query (contains location)
Lost Server -> Alice: Initial LoST Response (contains
PSAP-URI and dial string)
Some time later, Alice dials or otherwise initiates an emergency call:
[M4] Alice -> LIS: LCP Request (updates location)
LIS -> Alice: LCP Reply (replies with location)
[M5] Alice -> LoST Server: Update LoST Query (contains location)
Lost Server -> Alice: LoST Response (contains PSAP-URI)
[M6] Alice -> Outgoing Proxy: SIP INVITE (contains service URN,
Location and PSAP URI)
[M7] Outgoing Proxy -> ESRP: SIP INVITE (contains service URN,
Location and PSAP URI)
[M8] ESRP -> PSAP: SIP INVITE (contains service URN,
Location and PSAP URI) The 200 OK response is propagated back from the PSAP to Alice and the
ACK response is propagated from Alice to the PSAP.
Figure 2: Message FlowFigure 1 shows the emergency call component topology, and the text above walks through call establishment. The components are these 🧩:
- Alice - the user of a UA that places the emergency call 🙋♀️.
- Configuration servers - Servers providing Alice's UA its IP address and other configuration information, perhaps including location-by-value or location-by-reference. Configuration servers also may include a SIP registrar for Alice's UA. Most SIP UAs will register, so it will be a common scenario for UAs that make emergency calls to be registered with such a server in the originating calling network. In most cases, a UA would have to register in order for the PSAP to be able to call it back after an emergency call has been completed. All the configuration messages are labeled M1 through M3, but could easily require more than three messages to complete ⚙️.
- LoST server - Processes the LoST request for location plus a service URN to a PSAP-URI, either for an initial request from a UA or an in-call routing by the proxy server in the originating network, or possibly by an ESRP 🧠.
- ESRP - Emergency Services Routing Proxy, a SIP proxy server that is the incoming call proxy in the emergency services domain. The ESRP makes further routing decisions (e.g., based on PSAP state and the location of the caller) to choose the actual PSAP that handles the call. In some jurisdictions, this may involve another LoST query 🚦.
- PSAP - Emergency calls are answered at a Public Safety Answering Point, a call center 🎧.
Generally, Alice's UA either has its location configured manually, has an integral location measurement mechanism, or runs an LCP [M1] to get its location from the access (broadband) network 📶. Then Alice's UA will most likely register [M2] with a SIP registrar, which lets other SIP entities reach her 🔔. Next, her UA performs an initial LoST query [M3] to learn a URI it can use if the LoST query fails during an emergency call, or to test the emergency call mechanism 🧪. The LoST response contains the dial string for emergency calls that fits the location provided 🔢.
At some point after her device has booted, Alice starts an emergency call 🆘. She can do this by dialing an emergency dial string that's valid for her current ("local") location or for her "home" location 🏠.
The UA recognizes either dial string. It tries to refresh its location [M4] and, with that location, to refresh the LoST mapping [M5], so it has the most accurate information for routing the call 🎯. If the location request or the LoST request fails, or takes too long, the UA falls back on the values it has cached 🫶.
The UA creates a SIP INVITE [M6] request that includes the location. [RFC6442] defines a SIP Geolocation header that carries either a location-by-reference URI or a [RFC3986] "cid:" URL, which points to where the location-by-value sits in the message body 💅.
The INVITE message is routed to the ESRP [M7], the first inbound proxy for the emergency services domain 🚪. From there the ESRP routes it toward the most appropriate PSAP for Alice's location [M8], based on the location and other information 🏢.
A proxy in the PSAP picks an available call taker and extends the call to their UA 🎧.
The 200 OK response to the INVITE request travels the same path in reverse: from call taker UA, to PSAP proxy, to ESRP, to originating network proxy, and finally to Alice's UA ↩️. The ACK request completes the call setup, and the emergency call is established, so the call taker can talk to Alice about her emergency 💖.
4. Which Devices and Services Should Support Emergency Calls? ✨
Current PSAPs handle voice calls and real-time text calls placed over PSTN facilities or systems connected to the PSTN ☎️. But future PSAPs will support Internet connectivity, a wider range of media types, and higher functionality 🚀. In general, if a user could reasonably expect to be able to place a call for help with a device, then that device or service should support emergency calling 🆘. Anything that looks and works like a telephone, wired or mobile, definitely should support emergency calling 📱. But more and more, users expect other devices and services to work this way too 🌈.
Devices that create media sessions and exchange audio, video, and/or text, and that can set up sessions to a wide variety of addresses and communicate over private IP networks or the Internet, should support emergency calls 🎥.
Traditionally, a telephony service provider has provided emergency calling support to an enterprise 🏢. In some newer systems, the enterprise Private Branch Exchange (PBX) helps with emergency calling by supplying more fine-grained location in larger enterprises 📍. In the future, the enterprise may provide the connection to emergency services itself, without relying on the telephony service provider 👑.
5. Identifying an Emergency Call ✨
okay so bestie, picture this: in the PSTN world, you can usually summon help by dialing one nationally known number 📞🚨, and it doesn't matter where you bought the phone 💅. The number that actually works is decided by the network the phone is plugged into 🌍. Here's the tea though: it's different from place to place, even though it's often the same across a whole country or region (like lots of EU countries 🇪🇺). Some countries have ONE digit sequence for every emergency 🙌, and others have a few, each one for a different responder, like one for police 👮 and another for fire 🚒. Meanwhile, end systems really want a universal identifier that doesn't care where you are 🦋. That way the device can automatically attach location info 📍 and everyone else in the call path can handle the emergency call setup properly within the signaling protocol 💜.
Since no such universal identifier existed, this emergency calling architecture defines common emergency call URNs [RFC5031] 🎀. When every emergency service uses a single number, the URN is "urn:service:sos" 🆘. Users are not expected to "dial" an emergency URN 🙈. Instead, the appropriate emergency dial strings get translated into the matching service URNs, which ride along in the Request-URI of the INVITE request 📨. This translation is best done by the endpoint 📱, because, among other reasons, emergency calls carry location in the signaling while non-emergency calls normally don't 🗺️. If the device recognizes the emergency call, it can include location, if known ✨. And if the endpoint misses it, a signaling intermediary (proxy server) can still catch the emergency dial strings as a backup 🫶.
For devices that are mobile or nomadic 🧳, there's a whole question about whether the home or visited dial strings should be used. Lots of users would love their home dialing sequences to work wherever they are 🏠. BUT local laws and regulations may require that the visited dialing sequence(s) work 🏛️, so the visited dial string MUST work. Devices may have a way to be configured or learn home dial strings 🧚.
LoST [RFC5222] is the mechanism for getting the dialing sequences for a given location 🗺️. LoST servers MUST return dial strings for emergency services 💖. If the endpoint doesn't support translating dial strings into service URNs, the dialing sequence from the endpoint to its proxy is represented as a dial string [RFC4967], and the outgoing proxy MUST recognize the dial string and translate it to the equivalent service URN 🔁. To figure out the local emergency dial string, the proxy needs the location of the endpoint 📍. This can be tricky when the user can roam or be nomadic 🌏. So endpoint recognition of emergency dial strings is the preferred vibe 👑. If a service provider can't guarantee it can correctly determine local emergency dial strings, wherever its subscribers may be, then the endpoint is REQUIRED to do the recognition 💅.
Note: Emergency call practitioners consider it undesirable to have a single-button emergency call user interface element 🙅♀️. These mechanisms tend to result in a very high rate of false or accidental emergency calls 😭. To minimize this issue, practitioners recommend that devices SHOULD only initiate emergency calls based on entry of specific emergency call dial strings 🔢. Speed dial mechanisms may effectively create single-button emergency call invocation, and practitioners recommend they not be permitted 🚫.
6. Location and Its Role in an Emergency Call 📍🌸
Location is literally central to emergency services 🥹. It gets used for two things in emergency call handling: routing the call 🛣️ and dispatching responders 🚑. A lot of the time, callers reporting an emergency can't give a unique, valid location themselves 😩. That's why location from the endpoint or the access network is needed 🫶. For practical reasons, each PSAP generally only handles calls for a certain geographic area 🗾, with overload arrangements between PSAPs so they can cover each other's calls 🤝. Calls that reach the wrong PSAP by accident have to be manually re-routed (transferred) to the right one, which adds call handling delay and raises the chance of errors 😬. The area each PSAP covers differs by jurisdiction 🌐: some countries have only a few PSAPs, while others split responsibility all the way down to counties or municipalities 🏘️.
In most cases, PSAPs cover at least a city or town 🏙️, but some PSAP coverage areas follow old telephone rate center boundaries and may straddle more than one city 🧩. Irregular boundaries are super common, usually for historical reasons 📜. Routing MUST be based on actual PSAP service boundaries 🗺️ — the closest PSAP, or the PSAP that serves the nominal city name in the location, may NOT be the correct PSAP 🙃.
Accuracy of routing location is a whole complex situation 🌀. Calls need to be routed quickly and accurately ⚡, and figuring out location is often a time/accuracy trade-off, especially with mobile devices or self-measuring mechanisms 📶. If a more accurate routing location isn't available, it's considered acceptable to base the routing decision on an accuracy equal to the area of one sector of a mobile cell site 📡.
Routing to the most appropriate PSAP is always based on the caller's location 🧍♀️, even though some emergency calls are placed on behalf of someone else, and the incident's location is sometimes not the caller's location 🤷♀️. In some cases, other factors also play a role in choosing the PSAP, like time of day 🕐, caller media requests 📹, language preference 🗣️, and call load 📊. But the caller's location is still the primary input to the routing decision 👑.
Lots of mechanisms used to locate a caller have a relatively long "cold start" time 🥶. Getting a location accurate enough for dispatch can take as much as 30 seconds ⏳, which is WAY too long to wait during an emergency 😭. So it's common, especially in mobile systems, to use a coarse location (like the cell site and sector serving the call) for call routing 📶, and then update the location once a more precise value is known, before dispatch 🎯. In this document, we use "routing location" and "dispatch location" when the distinction matters 💅.
Accuracy of dispatch location is sometimes set by local regulation 📜, and it's limited by what technology can actually do 🛠️. The real requirement is stricter than today's tech can deliver 😤. It is REQUIRED that a device making an emergency call close to the "demising" or separation wall between two apartments in a high-rise apartment building report location with enough accuracy to tell which side of the wall it's on 🧱. This implies perhaps a 3 cm accuracy requirement 📏. As of the date of this memo, assisted GNSS uncertainty in mobile phones with 95% confidence cannot be relied upon to be less than hundreds of meters 🛰️. As tech advances, the location accuracy requirements will need to get tighter 📈. Wired systems using wire-tracing mechanisms can pinpoint location to a wall jack in a specific room on a floor in a building 🔌, and may even specify a cubicle or an even smaller resolution 🪑. As this discussion shows, emergency call systems demand the most stringent location accuracy available 🔥.
In Internet emergency calling, the endpoint's location is figured out using a variety of measurement or wire-tracing methods 🕵️♀️. Endpoints may be configured with their own location by the access network 🛜. In some circumstances, a proxy server may insert location into the signaling on behalf of the endpoint 🫡. The location is mapped to the URI the call gets sent to 🗺️, and the location is conveyed to the PSAP (and other elements) in the signaling 📨. The terms "determination", "configuration", "mapping", and "conveyance" are used for specific aspects of location handling in IETF protocols 📚. Likewise, we use Location Configuration Protocols, Location Mapping Protocols, and Location Conveyance Protocols for these functions 🧠.
This document gives guidance for generic network configurations with respect to location 🌈. It's recognized that unique issues may exist in some network deployments 🤔. The IETF will keep investigating these unique situations and will provide further guidance, if warranted, in future documents 🔮. Periodt 💜✨
6.1. Types of Location Information ✨
okay so location can be specified in a few different ways, bestie 🗺️💖 let's go through them 🫶
Civic: 🏠 civic location describes where a person or object is using a street address that matches a building or some other structure. civic location can get super fine-grained too, like floor, room, and cubicle. 💅 civic info comes in two flavors:
"Jurisdictional" means a civic location that uses the actual political subdivisions, especially for the community name. 🏛️
"Postal" means a civic location meant for mail delivery. 📬 the post office name doesn't always match the community name, and postal addresses can have post office boxes or street addresses that don't line up with a real building 💀. postal addresses are generally not great for emergency call dispatch because post office conventions (like the community name) don't match what responders know 🚨. the fact that they're unique can sometimes be used to map a postal address to a civic address that's good enough to send a responder to 🧚. in IETF location protocols, there's an element (Postal Community Name) that can go in a location to give the post office name AND the actual jurisdictional community name 🎀. there's also an element for a postal code. and that's it, there's no other accommodation for postal addresses in these protocols 🙈.
Geospatial (geo): 🌍 geospatial addresses have longitude, latitude, and altitude, based on an understood datum and earth shape model (datum). there have been a ton of datums over time, but most modern systems use or are moving toward the WGS84 [WGS84] datum. ✨
Cell tower/sector: 📡 cell tower/sector is often used to figure out where a mobile handset is, especially for routing emergency calls. it tells you the cell tower and the antenna sector a mobile device is currently using 🦋. traditionally, the tower location is a point picked to sit within a PSAP service boundary that agrees to take calls from that tower/sector, and routing decisions get made on that point 👑. cell tower/sector info could also be an irregularly shaped polygon of geospatial coordinates that reflects where the mobile device probably is 🌈. whatever representation is used MUST route correctly in the LoST database, and "correct" is decided by local PSAP management 🔥.
In IETF protocols, both civic and geospatial forms are supported 💜. the civic forms include both postal and jurisdictional fields. a cell tower/sector can be represented as a geo point, a geo polygon, or a civic location 🧚. other forms of location representation MUST be mapped into either a geo or civic value for use in emergency calls 🫶.
For emergency call purposes, converting location info from civic to geo (or the other way around) before it's conveyed is NOT DESIRABLE 🙅♀️. the location SHOULD be sent in the form it was determined 💅. converting between geo and civic needs a database 🗄️. when PSAPs need to convert from whatever form they received into another for responder purposes, they have a suitable database ✨. but if a conversion is done before the PSAP gets it, and the database used is not exactly the same one the PSAP uses, the double conversion has a high probability of introducing an error 😭.
6.2. Location Determination 🔍
okay so as we said above, location info can be entered by the user or installer of a device ("manual configuration"), measured by the end system, delivered to the end system by some protocol or measured by a third party, and inserted into the call signaling 💖.
sometimes an entity has multiple sources of location info, and some might be partly contradictory 🙃. this is especially likely if the location is determined both by the end system and a third party 👀. self-measured location (e.g., GNSS) is attractive 🤩, but location info provided by the access network could be WAY more accurate, and more reliable in some places like high-rise buildings in dense urban areas 🏙️✨.
the closer an entity is to the source of location, the more likely it is able to figure out which location is most appropriate for a particular purpose when there's more than one location determination for a given endpoint 🧠. in emergency calling, the PSAP is the least likely to be able to choose the right location when multiple conflicting locations are presented to it 💀. all available locations can be sent towards the PSAP, but the ORDER of the locations SHOULD be the sender's best attempt to guide the recipient on which one(s) to use 🎀.
6.2.1. User-Entered Location Information 🧑💻
location info can be maintained by the end user or the installer of an endpoint, either in the endpoint itself or in a database 🌸.
user-entered location info is almost always less reliable than measured or wire database info, because users may mistype it or enter civic address info that doesn't match a recognized (i.e., valid, see Section 6.10) address 😬. users can also forget to change the data when the device's location changes 🙈.
BUT there are always a small number of cases where the automated mechanisms the access network uses to determine location fail to accurately reflect where the endpoint actually is 🫣. for example, the user may deploy their own WAN behind an access network, which effectively moves an endpoint some distance from the access network's idea of its location 🏗️. to handle these exceptional cases, there MUST be some mechanism to manually provision a location for an endpoint, either by the user or by the access network on behalf of a user 🔧. using that mechanism introduces the possibility of users falsely declaring themselves to be somewhere they aren't 🚩. however, this is generally not a problem in practice 💅. commonly, if an emergency caller insists they're at a location different from what any automatic location determination system reports, responders will ALWAYS be sent to the user's self-declared location 🚑✨.
6.2.2. Access Network "Wire Database" Location Information 🔌
location info can be maintained by the access network, linking some form of identifier for the end subscriber or device to a location database ("wire database") 💜. in enterprise LANs, wiremap databases map Ethernet switch ports to building locations 🏢. in DSL installations, the local telephone carrier keeps a mapping of wire-pairs to subscriber addresses 📞.
historically, accuracy of location has been to a street-address level 🛣️. but that's not enough for larger structures 🏬. the Presence Information Data Format (PIDF) Location Object [RFC4119], extended by [RFC5139] and [RFC5491], allows interior building, floor, room, and even finer specification of location within a street address 🪜✨. when possible, interior location SHOULD be supported 🫶.
the threshold for when interior location is needed is roughly 650 square meters 📐. this value comes from US fire brigade recommendations for spacing alarm pull stations 🚒. but interior space layout, construction materials, and other factors SHOULD be considered too 🧱.
even for IEEE 802.11 wireless access points, wire databases may give sufficient location resolution 📶. the location of the access point as determined by the wiremap MAY be supplied as the location for each of the clients of the access point 💖. however, this may not be true for larger-scale systems like IEEE 802.16 (WiMAX) and IEEE 802.22, which typically have bigger cells than IEEE 802.11 🗼. the civic location of an IEEE 802.16 base station may be of little use to emergency personnel, since the endpoint could be several kilometers away from the base station 😵.
wire databases are most promising for residential users, where a service provider knows the customer's service address 🏡. the service provider can then do address validation (see Section 6.10), similar to the current system in some jurisdictions 🧾.
6.2.3. End System Measured Location Information 🛰️
GPS and similar Global Navigation Satellite Systems (e.g., GLONAS and Galileo) receivers may be built directly into the end device 📲. GNSS gives relatively high-precision location fixes in open-sky conditions 🌤️, but the tech still faces several challenges with performance (time-to-fix and time-to-first-fix), and with getting successful fixes inside shielded structures or underground 🚇. it also requires all devices to have the right GNSS capability 📱. many mobile devices need some kind of "assist", which may be run by the access network (A-GPS) or by a government (WAAS) 🏛️. a device may be able to use multiple sources of assist data 🎀.
GNSS satellites are active continuously, so location will ALWAYS be available as long as the device can "see" enough satellites 🌞. however, mobile devices may not be able to afford the power levels needed to keep the measuring system active 🔋. in those situations, when location is needed, the device has to start up the measurement mechanism 🔄. that typically takes tens of seconds, which is WAY too long to wait to route an emergency call 😱. for this reason, devices that have end system measured location mechanisms but need a cold start period lasting more than a couple seconds MUST find another way to get a routing location 🙏. typically, this would be a location associated with a radio link (cell tower/sector) 📡.
Heads up: the original says "need another way to get a routing location" for these devices, so keep an eye on that requirement when you implement it 👀.
6.2.4. Network Measured Location Information 🗼
the access network may locate end devices 🎯. techniques include various forms of triangulation 📐. elements in the network infrastructure triangulate end systems based on signal strength, angle of arrival, or time of arrival 📶. common mechanisms deployed include the following:
- Time Difference Of Arrival - TDOA ⏱️
- Uplink Time Difference Of Arrival - U-TDOA ⬆️
- Angle of Arrival - AOA 📐
- Radio Frequency (RF) fingerprinting 👆
- Advanced Forward Link Trilateration - AFLT 🔺
- Enhanced Forward Link Trilateration - EFLT 🔻
sometimes multiple mechanisms are combined, for example A-GPS with AFLT 🫶💫
6.3. Who Adds Location, Endpoint, or Proxy? 🎀
Okay so the IETF emergency call setup really prefers that the endpoint figures out where it is and attaches that to the call 📍 Only when a device can't support location should a proxy server step in and add it. Some calling networks have deals with every access network a device might connect through, and that can let the proxy pin down the endpoint's location accurately 🙌 But NATs and other middleboxes are sneaky and often make it impossible to find the reference identifier the access network could hand to a LIS for locating the device 🙈 So system designers are discouraged from leaning on proxies to add location. It might still be useful in some limited situations while devices get upgraded to meet this document's requirements, or where the relationships between access networks and calling networks are doable and can be trusted to get accurate location ✨
Proxy insertion of location makes dial-string recognition messier 💀 As noted in Section 6, local dial strings depend on where the caller is. If the device doesn't know its own location, it can't use the LoST service to learn the local emergency dial strings. So the calling network MUST provide another way for the device to learn the local dial string, and update it when the user moves somewhere the dial strings change, or do the dial-string determination itself 🗺️
6.4. Location and References to Location 🦋
Location info can be written as the actual civic or geospatial value, and it can travel either by value, meaning it's fully packed inside the signaling message, or by reference, meaning it's a URI pointing at the value sitting on some remote node, waiting to be dereferenced 🔗
When location goes by value, everyone in the call path can see it 👀 The catch is that location objects can be chunky and only capture a single snapshot of where the device was. Location references are tiny and can represent a location that changes over time 🌸 But that dereference step adds complexity, and if that lookup fails, the parties who need the location might not get it at all 😭
6.5. End System Location Configuration 💜
Unless a user agent has access to provisioned or locally measured location information, it MUST obtain it from the access network 💅 There are several Location Configuration Protocols (LCPs) that can do this job, including DHCP, HELD, and LLDP:
- DHCP can deliver civic [RFC4776] or geospatial [RFC6225] info. User agents need to support both formats 🎀 Also, a user agent can use DHCP, via the DHCP REQUEST or INFORM messages, even if it gets its IP address some other way.
- HELD [RFC5985] can deliver a civic or geo location object, by value or by reference, through a Layer 7 protocol 🧚 The query usually uses the requester's IP address as an identifier, and it returns the location value or reference tied to that identifier. HELD is typically carried in HTTP.
- Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device (MED) extensions [LLDP-MED] can deliver location info straight from the Layer 2 network infrastructure 🌈 It supports both civic and geo formats, which are identical in format to the DHCP methods.
Each LCP has limits on which kinds of networks can reasonably support it, so there's no way to pick a single mandatory-to-deploy LCP 😤 Think about endpoints on common connections, like an Ethernet jack or WiFi. Location determination could easily fail unless every network supported every protocol, or every device supported every protocol. So a mandatory-to-implement list of LCPs is set in [PHONEBCP]. Every endpoint that could be used to place emergency calls MUST implement all of the protocols on that list, and every access network MUST deploy at least one of them 🫶 Since it's the variety of networks that makes one protocol unacceptable on its own, it MUST be the endpoints that implement all of them, and to cover a wide range of devices, networks MUST deploy at least one of them. Iconic teamwork energy 👑
Network operators and device designers often think their setup is simpler, and that some network-specific mechanism can provide location 🙄 Unfortunately, it's super rare to actually limit which devices can connect to a network. For example, existing mobile networks are being used to support routers and LANs behind the WAN connection of a wireless data network, with Ethernet-connected phones plugged into that 💀 It's possible the access network could support a protocol that isn't on the list and require every handset on that network to use it for emergency calls. However, the Ethernet-connected phone won't be able to acquire location, and its user is unlikely to be talked out of placing an emergency call on it 😭 Gateways, routers, and other network-broadening devices are everywhere, so indirectly connected endpoints are possible on nearly every network. Network operators and vendors are warned that shortcuts to meeting this requirement are seldom successful 🚫
Location for non-mobile devices is normally expected to be acquired at network attachment time and kept by the device. It SHOULD be refreshed when the cached value expires 🔄 For example, if DHCP is the acquisition protocol, location might get refreshed when the IP address lease is renewed. At the time of an emergency call, the location SHOULD be refreshed, with the retained location used if the location acquisition doesn't immediately return a value 🌸 Mobile devices MAY determine location at network attachment time and periodically after that, as a backup in case location determination at call time doesn't work. Mobile device location MAY be refreshed when a Time-to-Live (TTL) expires, or when the device moves beyond some boundaries (as provided by [RFC5222]). Normally, mobile devices will acquire their location at call time for use in emergency call routing. See Section 6.8 for more on location updates for dispatch location ✨
There are lots of endpoints that are user agent applications running on a more general purpose device, like a personal computer 💻 On some systems, Layer 2 protocols like DHCP and LLDP may not be directly accessible to applications. It's desirable for an operating system to have an API that provides the device's location for use by any application, especially ones that support emergency calls 🧚
6.6. When Location Should Be Configured ⭐
Devices SHOULD get routing location immediately after they get their local network configuration info 🚀 NAT and VPN tunnels (which assign new IP addresses to communications) can obscure the identifiers that LCPs use to figure out location, especially for HELD 🙈
In some cases, like residential NAT devices, the NAT sits between the endpoint and the access network demarcation point, so the IP address the access network sees is the right identifier for the residence's location 🏡 In many enterprise environments, though, VPN tunnels can hide the actual IP address. Some VPN mechanisms can be bypassed, so a query to the LCP can be routed over the direct IP path, using the correct IP address, instead of going through the tunnel 🔐 In other cases no bypass is possible, but location can be configured before the VPN is established. Of course, LCPs that use Layer 2 mechanisms (DHCP location options and LLDP-MED) are usually immune to these problems, because they don't use the IP address as the identifier for the device seeking location 💖
It's desirable that routing location info be refreshed periodically 🔁 A LIS supporting a million subscribers, each refreshing once per day, would need to handle a query rate of 1,000,000 / (24 * 60 * 60) = 12 queries per second 🧮 For networks with mobile devices, much higher refresh rates could be expected.
It's desirable for routing location to be requested immediately before placing an emergency call 📞 However, if there's any significant delay in getting more recent location, the call SHOULD be placed with the most recent location information the device has. In mobile handsets, routing is often done with the cell site and sector of the tower serving the call, because it can take many seconds to start up the location determination mechanism and get an accurate location 📡
There's a trade-off between how long it takes to get a routing location and the accuracy (technically, confidence and uncertainty) you get 🎯 Routing an emergency call quickly is required. However, if location can be substantially improved by waiting a short time (e.g., for some sort of "quick (location) fix"), it's preferable to wait. Three seconds, the current nominal time for a quick fix, is a loooong time to add to post-dial delay 😩 NENA recommends [NENAi3TRD] that IP-based systems complete calls in two seconds from last dial press to ring at the PSAP ⏱️
6.7. Conveying Location 💌
When an emergency call is placed, the endpoint SHOULD include location in the call signaling. This is called "conveyance" to tell it apart from "configuration" 🧁 In SIP, location info is conveyed following the procedures in [RFC6442]. The form of location info obtained by the acquisition protocol may not match what the conveyance protocol uses (PIDF-LO [RFC4119]), so the endpoint may need to map from the LCP form to PIDF 🔄
6.8. Location Updates 🦋
As discussed above, some measurement mechanisms may take a while to get a location accurate enough for dispatch, so a routing location with less accuracy may be provided to get the call set up quickly ⚡ The PSAP needs the dispatch location before it sends the call to the responder, so an update of the location is needed. Plus, the location of some mobile callers, e.g., in a vehicle or aircraft, can change a lot during the emergency call 🚗✈️
A PSAP has no way to request an update of a location provided by value. If the User Agent Client (UAC) gets new location information, it MUST signal the PSAP using a new INVITE or an UPDATE transaction with a new Geolocation header field to supply the new location 📨
With so much variation in determination mechanisms, the PSAP doesn't know when accurate location might be available 🤷♀️ The preferred mechanism is for the LIS to notify the PSAP when an accurate location is available, rather than requiring the PSAP to poll the LIS. The SIP Presence subscription [RFC3856] provides a suitable mechanism 🌟
When using a HELD dereference, the PSAP MUST specify the value emergencyDispatch for the ResponseTime parameter 💫 Since the LIS is typically local relative to the PSAP, the LIS can be aware of the PSAP's update requirements 🫶
6.9. Multiple Locations ✨
Multiple locations that all claim to describe where the caller is? Super confusing for everyone, so it should be avoided 🙅♀️. How you handle them where a PIDF gets created is covered in [RFC5491]. Conflicting location is especially harmful if different routes (PSAPs) come back from LoST queries for each location 😬. When it happens anyway, the general vibe is that the entity earliest in the chain usually knows more than the later elements, so it's in the best spot to make a smart call, especially about which location gets used for routing 🧠. It is permissible to send multiple locations toward the PSAP, but the element that chooses the route must select exactly one location to use with LoST.
Guidelines for multiple locations are also given in [RFC5222]. If a UA gets multiple locations, it must choose the one to use for routing, but it may send all of the locations it has in the signaling. If a proxy is inserting location and has multiple locations, it must choose exactly one to use for routing and send it, as well as any other locations it has that correspond to this UA. 💅
The UA or proxy should understand how and from whom it learned its location, and should include this information in the location objects that get sent to the PSAP. That labeling gives the call taker something to make decisions upon, plus guidance on what to ask the caller and what to tell the responders 🫶.
Endpoints or proxies may be tempted to send multiple versions of the same location. For example, a database may be used to "geocode" or "reverse geocode", which means converting from civic to geo or vice versa. Using derived locations in emergency calls is very problematic 😭. The PSAP and the responders have very accurate databases that they use to convert, most commonly, from a reported geo to a civic address suitable for dispatching responders. If one database is used to convert from civic to geo and another converts from geo to civic, errors will often happen where the databases are slightly different. Errors of even a single house number are serious, because they may lead first responders to the wrong building 💀. Derived locations should be marked with a derived method token [RFC4119]. If an entity gets a location that has a measured or other original method, and another with a derived method, it must use the original value for the emergency call. 🔥
6.10. Location Validation 🔍
Validation, in this context, means there is a mapping from the address to a PSAP, and that the PSAP understands how to direct responders to the location. It is recommended that location be validated before a device places an actual emergency call, and some jurisdictions require that this be done ✅.
Determining whether an address is valid can be difficult 🙃. There are, for example, many cases of two names for the same street, or two streets with the same name but different "suffixes" (Avenue, Street, Circle) in a city. In some countries, the current system provides validation. For example, in the United States of America, the Master Street Address Guide (MSAG) records all valid street addresses and is used to ensure that the service addresses in phone billing records correspond to valid emergency service street addresses 🇺🇸. Validation is normally only a concern for civic addresses, although there could be some determination that a given geo is within at least one PSAP service boundary. That is, a "valid" geo is one where there is a mapping in the LoST server 🗺️.
LoST [RFC5222] includes a location validation function. Validation is normally performed when a location is entered into a Location Information Server. It should be confirmed periodically, because the mapping database undergoes slow change, and locations that previously validated may eventually fail validation 🕰️. Endpoints may wish to validate locations they receive from the access network, and they will need to validate manually entered locations. Proxies that insert location may wish to validate locations they receive from a LIS. When the test functions (Section 15) are invoked, the location used should be validated 🧪.
When validation fails, the location given should not be used for an emergency call, unless no other valid location is available. Bad location is better than no location 🙏. If validation is completed when location is first loaded into a LIS, any problems can be found and fixed before devices could get the bad location. Failure of validation happens because an error was made in determining the location, although occasionally the LoST database is not up to date or has faulty information. In either case, the problem must be identified and should be corrected before using the location 🛠️.
6.11. Default Location 🌸
Occasionally, the access network cannot determine the actual location of the caller. In these cases, it must supply a default location. The default location should be as accurate as the network can determine 🎯. For example, in a cable network, a default location could be provided for each Cable Modem Termination System (CMTS), with a representative location for all cable modems served by that CMTS, if the network is unable to resolve the subscriber to anything more precise than the CMTS. Default locations must be marked as such, so that the PSAP knows that the location is not accurate 🚩.
6.12. Location Format Conversion 🦋
The endpoint is responsible for mapping any form of location it receives from an LCP into PIDF-LO form, if the LCP did not directly return a PIDF-LO 🧚.
7. LIS and LoST Discovery ✨
Endpoints must be able to discover a LIS, if the HELD protocol is used, and a LoST server. DHCP options are defined for this purpose, namely [RFC5986] and [RFC5223] 🔎.
Until such DHCP records are widely available, it may be necessary for the service provider to provision a LoST server address in the device. The endpoint can also do a DNS SRV query to find a LoST server. In any environment, more than one of these mechanisms may yield a LoST server, and they may be different 🤷♀️. The recommended priority is DHCP first, provisioned value second, and DNS SRV query in the SIP domain third 👑.
8. Routing the Call to the PSAP ✨
Emergency calls are routed based on one or more of the following criteria, expressed in the call setup request (INVITE) 📞:
- Location: Since each PSAP serves a limited geographic region, and transferring existing calls delays the emergency response, calls need to be routed to the most appropriate PSAP 📍. In this architecture, emergency call setup requests contain location information, expressed in civic or geospatial coordinates, that allows such routing.
- Type of emergency service: In some jurisdictions, emergency calls for specific emergency services, such as fire, police, ambulance, or mountain rescue, are directed to just those emergency-specific PSAPs 🚒🚓🚑. This mechanism is supported by marking emergency calls with the proper service identifier [RFC5031]. Even in single-number jurisdictions, not all services are dispatched by PSAPs, and they may need alternate URNs to route calls to the appropriate call center 🏔️.
- Media capabilities of caller: In some cases, emergency call centers for specific caller media preferences, such as typed text or video, are separate from PSAPs serving voice calls 💬. ESRPs are expected to be able to provide routing based on media. Also, even if media capability does not affect the selection of the PSAP, there may be call takers within the PSAP who are specifically trained, for example, in real-time text or sign language communications, where routing within the PSAP based on the media offer would be provided 🤟.
Providing a URL to route emergency calls by location and by type of service is the primary function LoST [RFC5222] provides. LoST accepts a query with location (by-value) in either civic or geo form, plus a service identifier, and returns a URI (or set of URIs) to which to route the call. Normal SIP [RFC3261] routing functions are used to resolve the URI to a next-hop destination 🛣️.
The endpoint can complete the LoST mapping from its location at boot time, and periodically thereafter. It should attempt to obtain a "fresh" location, and from that a current mapping, when it places an emergency call. If accessing either its location acquisition or its mapping functions fails, it should use its cached value. The call would follow its normal outbound call processing 💾.
Determining when the device leaves the area provided by the LoST service can tax small mobile devices 🔋. For this reason, the LoST server should return a simple (small number of points) polygon for geospatial location. This can be a simple enclosing rectangle of the PSAP service area when the reported point is not near an edge, or a smaller polygonal edge section when the reported location is near an edge. Civic location is uncommon for mobile devices, but reporting that the same mapping is good within a community name, or even a street, may be very helpful for WiFi connected devices that roam and obtain civic location from the access point to which they are connected 📶.
Networks that support devices that do not implement LoST mapping themselves may need the outbound proxy to do the mapping. If the endpoint recognized the call was an emergency call, and provided the correct service URN and/or included location on the call in a Geolocation header, a proxy server could easily accomplish the mapping 😌.
However, if the endpoint did not recognize the call was an emergency call, and thus did not include location, the proxy's task is more difficult 😬. It is often difficult for the calling network to accurately determine the endpoint's location. The endpoint may have its own location, but would not normally include it in the call signaling unless it knew it was an emergency call. There is no mechanism provided in [RFC6442] for a proxy to request that the endpoint supply its location, because that would open the endpoint to an attack by any proxy on the path to get it to reveal its location 🕵️♀️. The proxy can attempt to redirect a call to the service URN, which, if the device recognizes the significance, would include location in the redirected call from the device. All network elements should detect emergency calls and supply default location and/or routing if it is not already present 🚨.
The LoST server would normally be provided by the local emergency authorities, although the access network or calling network might run its own server using data provided by the emergency authorities 🏛️. Some enterprises may have local responders and call centers, and could operate their own LoST server, providing URIs to in-house "PSAPs". Local regulations might limit the ability of enterprises to direct emergency calls to in-house services ⚖️.
The ESRP, which is a normal SIP proxy server in the signaling path of the call, may use a variety of PSAP state information, the location of the caller, and other criteria to route the call onward to the PSAP 🧭. In order for the ESRP to route on media choice, the initial INVITE request has to supply an SDP offer 🎀.
9. Signaling of Emergency Calls ✨
9.1. Use of TLS 🔐
Okay, first things first: best current practice for SIP user agents [RFC4504] should be applied, including the handling of audio, video, and real-time text [RFC4103] 💖. Location is carried in all emergency calls in the call signaling ✨. Emergency calls carry super privacy-sensitive info, so they're subject to the requirements for geospatial protocols [RFC3693] 🫶. In particular, signaling information should be carried in Transport Layer Security (TLS), i.e., in sips mode with a ciphersuite that includes strong encryption, such as AES 🔒. There are exceptions in [RFC3693] for emergency calls. For example, local policy may dictate that location is sent with an emergency call even if the user's policy would otherwise prohibit that 🙈. Nevertheless, protection from eavesdropping of location by encryption should be provided 💅.
It is unacceptable to have an emergency call fail to complete because a TLS connection was not created for any reason 💀. So the call should be attempted with TLS, but if the TLS session establishment fails, the call should be automatically retried without TLS 😭. [RFC5630] recommends that, to achieve this effect, the target specify a sip URI but use TLS on the outbound connection 🎀. An element that receives a request over a TLS connection should attempt to create a TLS connection to the next hop 🦋.
In many cases, persistent TLS connections can be maintained between elements to minimize the time needed to establish them [RFC5626] 🌸. In other circumstances, use of session resumption [RFC5077] is recommended ✨. IPsec [RFC4301] is an acceptable alternative to TLS when used with an equivalent crypto suite 🧚.
Location may be used for routing by multiple proxy servers on the path 👑. Confidentiality mechanisms such as Secure/Multipurpose Internet Mail Extensions (S/MIME) encryption of SIP signaling [RFC3261] cannot be used because they obscure location 🙈. Only hop-by-hop mechanisms such as TLS should be used 🔥. Implementing location conveyance in SIP mandates inclusion of TLS support 🫶.
9.2. SIP Signaling Requirements for User Agents 📞
SIP UAs that recognize local dial strings, insert location, and perform emergency call routing will create SIP INVITE messages with the service URN in the Request-URI, the LoST-determined URI for the PSAP in a Route header, and the location in a Geolocation header 💖. The INVITE request must also have appropriate callback identifiers (in Contact and From headers) 🎀. To enable media-sensitive routing, the call should include a Session Description Protocol (SDP) offer [RFC3264] 🌈.
SIP caller preferences [RFC3841] can be used to signal how the PSAP should handle the call 🍓. For example, a language preference expressed in an Accept-Language header may be used as a hint to cause the PSAP to route the call to a call taker who speaks the requested language 🗣️. SIP caller preferences may also be used to indicate a need to invoke a relay service for communication with people with disabilities in the call 🫶.
9.3. SIP Signaling Requirements for Proxy Servers 🧭
At least one SIP proxy server in the path of an emergency call must be able to assist UAs that are unable to provide any of the location-based routing steps and recognition of dial strings 🦸. A proxy can recognize the lack of location awareness by the lack of a Geolocation header 👀. It can recognize the lack of dial-string recognition by the presence of the local emergency call dial string in the From header without the service URN being present 🕵️. They should obtain the location of the endpoint if possible, and use a default location if they cannot, inserting it in a Geolocation header 📍. They should query LoST with the location and put the resulting URI in a route, with the appropriate service URN in the Request-URI 🗺️. In any event, they are also expected to provide information for the caller using SIP Identity or P-Asserted-Identity 🪪. It is often a regulatory matter whether calls normally marked as anonymous are passed as anonymous when they are emergency calls ⚖️. Proxies must conform to the local regulation or practice 💅.
10. Call Backs 📲
The call taker must be able to reach the emergency caller if the original call is disconnected 📞. In traditional emergency calls, wireline and wireless emergency calls include a callback identifier for this purpose 🎀. There are two kinds of call backs 👯. When a call is dropped, or the call taker realizes that some important information is needed that it doesn't have, it must call back the device that placed the emergency call 😤. The PSAP, or a responder, may need to call back the caller much later, and for that purpose, it wants a normal SIP address of record (AOR) 📇. In SIP systems, the caller must include a Contact header field in an emergency call containing a globally routable URI, possibly a Globally Routable User Agent URI (GRUU) [RFC5627] 🌐. This identifier would be used to initiate callbacks immediately by the call taker if, for example, the call is prematurely dropped 📲. A concern arises with back-to-back user agents (B2BUAs) that manipulate Contact headers 🤔. Such B2BUAs should always include a Contact header that routes to the same device 🫶.
In addition, a callback identifier as an address of record (AoR) must be included either as the URI in the From header field [RFC3261] verified by SIP Identity [RFC4474] or as a network-asserted URI [RFC3325] 🔐. If the latter, the PSAP will need to establish a suitable spec(t) with the proxies that send it emergency calls 🤝. This identifier would be used to initiate a callback at a later time and may reach the caller, not necessarily on the same device (and at the same location) as the original emergency call as per normal SIP rules 🦋. It is often a regulatory matter whether calls normally marked as anonymous are passed as anonymous when they are emergency calls ⚖️. Proxies must conform to the local regulation or practice 💅.
11. Mid-Call Behavior 🎧
Some PSAPs often include dispatchers, responders, or specialists on a call 🧑🚒. Some responders' dispatchers are not located in the primary PSAP, the call may have to be transferred to another PSAP 🔁. Most often, this will be an attended transfer, or a bridged transfer 🌉. Therefore, a PSAP may need to a REFER request [RFC3515] a call to a bridge for conferencing 📨. Devices that normally involve the user in transfer operations should consider the effect of such interactions when a stressed user places an emergency call 😰. Requiring user interface manipulation during such events may not be desirable 🙅. Relay services for communication with people with disabilities may be included in the call with the bridge 🤟. The UA should be prepared to have the call transferred (usually attended, but possibly blind) per [RFC5359] 🌷.
12. Call Termination 📴
It is undesirable for the caller to terminate an emergency call 🙃. A PSAP terminates a call using the normal SIP call termination procedures, i.e., with a BYE request 👋.
13. Disabling of Features 🚫
Certain features that can be invoked while a normal call is active are not permitted when the call is an emergency call 🙅♀️. Services such as call waiting, call transfer, three-way calling, and hold should be disabled 📵.
Certain features such as call forwarding can interfere with calls from a PSAP and should be disabled 🧱. There is no way to reliably determine a PSAP call back 🤷. A UA may be able to determine a PSAP call back by examining the domain of incoming calls after placing an emergency call and comparing that to the domain of the answering PSAP from the emergency call 🔍. Any call from the same domain and directed to the supplied Contact header or AoR after an emergency call should be accepted as a callback from the PSAP if it occurs within a reasonable time after an emergency call was placed ⏰.
14. Media 🎬
PSAPs should always accept RTP media streams [RFC3550] 🎶. Traditionally, voice has been the only media stream accepted by PSAPs 📞. In some countries, text, in the form of Baudot codes or similar tone encoded signaling within a voiceband is accepted ("TTY") for persons who have hearing disabilities 🧏. Using SIP signaling includes the capability to negotiate media 🤝. Normal SIP offer/answer [RFC3264] negotiations should be used to agree on the media streams to be used 💬. PSAPs should accept real-time text [RFC4103] ⌨️. All PSAPs should accept G.711 A-law (and mu-law in North America) encoded voice as described in [RFC3551] 🎙️. Newer text forms are rapidly appearing, with instant messaging now very common, PSAPs should accept IM with at least "pager-mode" MESSAGE request [RFC3428] as well as Message Session Relay Protocol [RFC4975] 💬✨. Video media in emergency calling is required to support Video Relay Service (sign language interpretation) as well as modern video phones 🤟🎥.
It is desirable for media to be kept secure by the use of Secure RTP [RFC3711], using DTLS [RFC5764] for keying 🔐.
15. Testing 🧪
Since the emergency calling architecture consists of a number of pieces operated by independent entities, it is important to be able to test whether an emergency call is likely to succeed without actually occupying the human resources at a PSAP 🧑💻. Both signaling and media paths need to be tested since NATs and firewalls may allow the session setup request to reach the PSAP, while preventing the exchange of media 🧱.
[PHONEBCP] includes a description of an automated test procedure that validates routing, signaling, and media path continuity 🤖. This test should be used within some random interval after boot time, and whenever the device location changes enough that a new PSAP mapping is returned by the LoST server 📍.
The PSAP needs to be able to control frequency and duration of the test, and since the process could be abused, it may temporarily or permanently suspend its operation 🛑.
There is a concern associated with testing during a so-called "avalanche-restart" event where, for example, a large power outage affects a large number of endpoints, that, when power is restored, all attempt to reboot and, possibly, test ⚡. Devices need to randomize their initiation of a boot time test to avoid the problem 🎲.
16. Security Considerations 🛡️
Security considerations for emergency calling have been documented in [RFC5069] and [RFC6280] 📚.
This document suggests that security (TLS or IPsec) be used hop-by-hop on a SIP call to protect location information, identity, and other privacy-sensitive call data 🔒. It also suggests that if the attempt to create a security association fails, the call be retried without the security 🔁. It is more important to get an emergency call through than to protect the data; indeed, in many jurisdictions privacy is explicitly waived when making emergency calls 🚨. Placing a call without security may reveal user information, including location 😱. The alternative, failing the call if security cannot be established, is considered unacceptable 💀.
17. Acknowledgments 🙏
This document was created from "Emergency Services for Internet Telephony Systems" (Schulzrinne, 2004) together with sections from "Emergency Context Routing of Internet Technologies Architecture Considerations" (Polk, 2006) 🌟.
Design Team members participating in this document creation include Martin Dolly, Stu Goldman, Ted Hardie, Marc Linsner, Roger Marshall, Shida Schubert, Tom Taylor, and Hannes Tschofenig 💜. Further comments and input were provided by Richard Barnes, Barbara Stark, and James Winterbottom 🫶.
18. Informative References 📚✨
Okay bestie, this is the reading list at the back, and it's a big one 💅 Every entry is here with its full details so you can go find them. Labels go first in inline code, and the title stays in quotes exactly as written.
[LLDP]IEEE, "IEEE802.1ab Station and Media Access Control", December 2004. 🔌[LLDP-MED]ANSI/TIA, "Link Layer Discovery Protocol - Media Endpoint Discovery", TIA Standard, TIA-1057, April 2006. 📡[NENAi3TRD]NENA, "08-751 v1 - i3 Technical Requirements (Long Term Definition)", 2006. 🚨[PHONEBCP]Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, September 2011. 🚧[RFC3261]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 📞[RFC3264]Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. 🤝[RFC3325]Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. 🪪[RFC3428]Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. 💬[RFC3515]Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. 🔁[RFC3550]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. 🎙️[RFC3551]Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 🎧[RFC3693]Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 🗺️[RFC3711]Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 🔐[RFC3841]Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. ⭐[RFC3856]Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. 🟢[RFC3986]Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. 🔗[RFC4103]Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005. ⌨️[RFC4119]Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. 📍[RFC4190]Carlberg, K., Brown, I., and C. Beard, "Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony", RFC 4190, November 2005. 🆘[RFC4301]Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 🛡️[RFC4474]Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. 🪪[RFC4504]Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony Device Requirements and Configuration", RFC 4504, May 2006. ☎️[RFC4776]Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006. 🏠[RFC4967]Rosen, B., "Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier", RFC 4967, July 2007. 🔢[RFC4975]Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. 📨[RFC5012]Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008. 🚑[RFC5031]Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008. 🏷️[RFC5069]Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008. 🕵️[RFC5077]Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008. 🔁[RFC5139]Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008. 🏙️[RFC5222]Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008. 🧭[RFC5223]Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)", RFC 5223, August 2008. 🔎[RFC5359]Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008. 🧪[RFC5491]Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009. 📝[RFC5626]Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009. 🔌[RFC5627]Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009. 🌍[RFC5630]Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009. 🔒[RFC5764]McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 🗝️[RFC5985]Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010. 🌐[RFC5986]Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010. 🏢[RFC6225]Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, July 2011. 🛰️[RFC6280]Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011. 🙈[RFC6442]Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011. 🗺️[WGS84]NIMA, "NGA: DoD World Geodetic System 1984, Its Definition and Relationships with Local Geodetic Systems", Technical Report TR8350.2, Third Edition, July 1997. 🌏
Authors' Addresses 🎀✨
Last but not least, the authors! These are the people who wrote this whole thing, so here are their addresses exactly as they appear.
Brian Rosen
NeuStar, Inc.
470 Conrad Dr
Mars, PA 16046
USA
EMail: br@brianrosen.net
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
James Polk
Cisco Systems
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Andrew Newton
TranTech/MediaSolv
4900 Seminary Road
Alexandria, VA 22311
USA
Phone: +1 703 845 0656
EMail: andy@hxr.usThat's the whole RFC, bestie! 💖 You made it through all 10 parts. Main character energy 👑
📦 where this page comes from
- ietf: rfc6443 2011-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms