RFC 5012
Requirements for Emergency Context Resolution with Internet Technologies
RFC 5012 💖 Requirements for Emergency Context Resolution with Internet Technologies
Bestie, check this out 🫶 This is RFC 5012, published in January 2008. The co-authors are H. Schulzrinne (Columbia U.) and R. Marshall, Ed. (TCS), and it's filed as Informational, so it's guidance for the community, not a binding standard. The header doesn't list any RFCs it obsoletes or updates, so it's standing on its own 🦋
Status of This Memo 📋
Okay so this memo is just info for the Internet community. It is NOT a standard of any kind 🙅♀️ Distribution is unlimited, so you can share it with literally anyone 💌
Abstract ✨
This doc defines the terminology and lists the requirements for resolving the context of emergency calls that the public places using voice-over-IP (VoIP) and general Internet multimedia systems. The big condition is that Internet protocols are used end to end 🌐
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Emergency Services . . . . . . . . . . . . . . . . . . . . 3
3.2. Service Providers . . . . . . . . . . . . . . . . . . . . 3
3.3. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Call Routing Entities . . . . . . . . . . . . . . . . . . 5
3.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.6. Identifiers, Numbers, and Dial Strings . . . . . . . . . . 6
3.7. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. High-Level Requirements . . . . . . . . . . . . . . . . . . . 10
6. Identifying the Caller's Location . . . . . . . . . . . . . . 12
7. Emergency Service Identifier . . . . . . . . . . . . . . . . . 14
8. Mapping Protocol . . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 211. Introduction 🎀
Okay so people who use voice (phone-like) services and people who use non-voice services, like text for hard-of-hearing users (see [RFC3351] and [toip]), both expect to be able to ask for help in an emergency 🚨
The thing is, the emergency call systems built up over the years in the public circuit-switched telephone network (PSTN) don't really fit with IP-based voice, text, and real-time multimedia 😩 This doc lays out the key requirements that IP-based end systems and network elements, like Session Initiation Protocol (SIP) [RFC3261] proxies, need to meet to offer emergency call services. The bare minimum is matching what PSTN already does, and the bigger goal is making emergency calling more robust, cheaper to build, and multimedia-capable ✨
This doc only focuses on end-to-end IP-based calls 💻 That means the emergency call starts on an IP end system, ends at an IP-capable public safety answering point (PSAP), and travels entirely over an IP network.
Here's the roadmap 🗺️ Terminology is in Section 3. The doc then covers the functional stuff for placing an IP-based emergency call: the baseline requirements (Section 5), figuring out the caller's location (Section 6), using a service identifier to declare a call an emergency call (Section 7), and finally the mapping function required to route the call to the right PSAP (Section 8).
The main job of the mapping protocol is to produce a PSAP URI from a preferred set of URI schemes, like SIP or SIPS URIs. It bases this on both location information [RFC4119] and a service identifier, so the emergency call can be completed end to end over IP 🦋
The mapping protocol is useful for more than just getting a PSAP URI, too 💅 For example, say the appropriate emergency number isn't known and you only have the location. The mapping protocol can then return a geographically appropriate emergency number based on that input.
Some PSAPs might not support IP just yet 😬 Also, some user equipment (UE) might not support emergency service identifiers at first. Because of that, it may be necessary to also support emergency service identifiers that use less-preferred URI schemes, like a tel URI, so the call can still be completed via the PSTN 📞
Identifying the caller is outside the scope of this document. It isn't incompatible with the messaging requirements in here, but it's not covered 🙈
Location is needed for two separate reasons 📍 First, it routes the emergency call to the right PSAP. Second, it lets the call taker see where the caller is so they can dispatch help to the right spot 🚑
That second use, showing location info to the PSAP, is orthogonal to the mapping protocol, so it's outside the scope of this document 💜
2. Requirements Terminology 📏
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. There's one important qualification, though: unless otherwise stated, these terms apply to the design of the mapping protocol, not to its implementation or application 🧠
3. Terminology 📖
3.1. Emergency Services 🚨
Basic emergency service: Basic emergency service lets a caller reach a PSAP that serves their current location. However, the PSAP might not be able to tell who the caller is or where they are, unless the call taker asks the caller directly 🤷♀️
Enhanced emergency service: With enhanced emergency service, the PSAP call taker can figure out the caller's current location 📍
3.2. Service Providers 🏢
Internet Access Provider (IAP): An organization that provides physical and data link (layer 2) network connectivity to its customers or users. This can happen through digital subscriber lines, cable TV plants, Ethernet, leased lines, or radio frequencies. Examples include telecommunication carriers, municipal utilities, bigger enterprises with their own network infrastructure, and government organizations, like the military 🛰️
Internet Service Provider (ISP): An organization that provides IP network-layer services to its customers or users. This entity may or may not provide the physical-layer and data link (layer-2) connectivity, like fiber or Ethernet. In other words, it may or may not play the role of an IAP 🔌
Application Service Provider (ASP): The organization or entity that provides application-layer services, which can include voice (see "Voice Service Provider"). This can be a private individual, an enterprise, a government, or a service provider. An ASP is more general than a Voice Service Provider, since emergency calls can use other media beyond voice, like text and video 🎥 For a particular user, the ASP may or may not be the same organization as their IAP or ISP.
Voice Service Provider (VSP): A specific type of Application Service Provider that provides IP-based voice services, like call routing, a SIP URI, or PSTN termination 📞 In this document, unless noted otherwise, any reference to "Voice Service Provider" or "VSP" can be used interchangeably with "Application/Voice Service Provider" or "ASP/VSP" 💖
3.3. Actors 🎭
(Emergency) caller: The terms "caller" or "emergency caller" refer to the person placing an emergency call or sending an emergency instant message (IM) 🫶
User Equipment (UE): User equipment is the device or software the caller operates to place an emergency call. A SIP user agent (UA) is one example of user equipment 📱
Call taker: A call taker is an agent at the PSAP who accepts calls and may dispatch emergency help 🎧 Sometimes call taking and dispatching are handled by different groups of people, but the caller doesn't usually see that split, so we don't need to worry about it here 🙌
3.4. Call Routing Entities 🛤️
Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call routing support entity. It invokes the location-to-PSAP URI mapping function to return either an appropriate PSAP URI or the URI for another ESRP 🔀 Client mapping requests can also come from a number of entities, including ones that run the SIP proxy role and the SIP user agent client role.
Public Safety Answering Point (PSAP): A PSAP is a facility where emergency calls are received under the responsibility of a public authority 🏛️ (This terminology is used by both the European Telecommunications Standards Institute (ETSI), in ETSI SR 002 180, and the National Emergency Number Association (NENA).) In the United Kingdom, PSAPs are called Operator Assistance Centres, and in New Zealand they're called Communications Centres 🇬🇧🇳🇿 Unless stated otherwise, this document assumes PSAPs can receive emergency calls over IP, using application layer protocols like SIP for call signaling and RTP for media 🌈
3.5. Location 📍
Location: A geographic identification assigned to a region or feature, based on a specific coordinate system or on other precise info, like a street number and name. It can be either a civic or a geographic location 🗺️
Civic location: A described location based on some reference system, like a jurisdictional region or a postal delivery grid. A street address is a common example of a civic location 🏠
Geographic location: A reference to a point that can be located, described by a set of defined coordinates within a geographic coordinate system, like latitude and longitude within the WGS-84 datum 🌍 For example, a 2-D geographic location is defined as an (x,y) coordinate value pair, based on how far north or south of the equator it is and how far east or west of the prime meridian 🧭
Location validation: A caller location is considered valid if the civic or geographic location is recognizable within an acceptable location reference system (for example, United States Postal Address or the WGS-84 datum) and can be mapped to one or more PSAPs ✅ Wanna know a tea? Validation doesn't always prove the location exists. It may only confirm that the location falls within some range of known values 🫖 Location validation makes sure a location can be referenced for mapping, but it doesn't assume anything about how the caller is associated with that location 💅
Part 1 of 6 is a wrap 🎀 Section 3.6 (Identifiers, Numbers, and Dial Strings) is up next, bestie 🧚
3.6. Identifiers, Numbers, and Dial Strings ✨
(Emergency) service number: okay so the (emergency) service number is a string of digits you use to reach the (emergency) service 📞. People often just call it the emergency number. It's the one you'd dial on devices plugged straight into the PSTN, and it's the number national or regional numbering authorities have reserved for emergency calls 🫶. It only contains the digits 0 through 9, #, and *. The service number may depend on where the caller is. For example, the general emergency service number in the United States is 911, and the poison control service number is 18002221222 🍓. Most of the time the service number and dial string are the same thing, but they may be different in some private phone networks. A service number may be carried in tel URLs [RFC3966], along with a context identifier. In the North American numbering plan, some service numbers are three-digit N11 or service codes, but not all emergency numbers have three digits 🌈. And a caller may have to dial a service dial string (below) that's different from the service number when they're using a PBX 💅.
(Emergency) service dial string: the service dial string is the string of digits a caller has to dial to reach a particular (emergency) service. On devices directly connected to the PSTN, it's the same as the service number and may depend on where the caller is located 🌸. But in private phone networks, like PBXs, the service dial string is a dialing prefix to get an outside line, followed by the emergency number. For example, in a hotel, the dial string for emergency services in the United States might be 9911 😭. Dial strings may contain indications of pauses or wait-for-secondary-dial-tone indications. Service dial strings are outside the scope of this document 🙈.
(Emergency) service identifier: the (emergency) service identifier describes the emergency service on its own, separate from the user interface mechanism, the signaling protocol used to reach the service, or the caller's geographic location 🧚. It's a protocol constant, used within the mapping and signaling protocols. An example is the service URN [RFC5031] 👑.
(Emergency) service URL: the service URL is an identifier that's either protocol-specific (e.g., SIP) or protocol-agnostic (e.g., im: [RFC3860]). It contains the address of the PSAP or other emergency service. It depends on the specific signaling or data transport protocol used to reach the emergency service 🦋.
Service URN: a service URN is an implementation of a service identifier, and it can be used in both emergency and non-emergency contexts, e.g., urn:service:sos or urn:service:counseling 💜. In this document, service URNs are referred to as 'emergency service URNs' [RFC5031] ✨.
Home emergency number: the home emergency number is the emergency number that's valid at the caller's customary home location, e.g., their permanent residence 🏡. The home location may or may not coincide with the service area of the caller's VSP 🌸.
Home emergency dial string: the home dial string is the dial string that's valid at the caller's customary home location, e.g., their permanent residence 🎀.
Visited emergency number: the visited emergency number is the emergency number that's valid at the caller's current physical location 🗺️. We distinguish it when the caller is traveling outside their home region ✈️.
Visited emergency dial string: the visited emergency dial string is the dial string number that's valid at the caller's current physical location 🧳.
3.7. Mapping 🗺️
Mapping: mapping is the process of resolving a location to one or more PSAP URIs that either directly identify a PSAP, or point to an intermediary that knows about a PSAP and is designated as responsible for serving that location 📍.
Mapping client: a mapping client talks to the mapping server to learn one or more PSAP URIs for a given location 💌.
Mapping protocol: a protocol used to convey the mapping request and response 📨.
Mapping server: the mapping server holds the information about the location-to-PSAP URI mapping 🗂️.
Mapping service: a network service that uses a distributed mapping protocol to perform a mapping between a location and a PSAP, or an intermediary that knows about the PSAP. It's used to help route an emergency call 🚨.
4. Basic Actors 🎭
In order to support emergency services covering a large physical area, a bunch of infrastructure elements are necessary, including Internet Access Providers (IAPs), Application/Voice Service Providers (ASP/VSPs), Emergency Service Routing Proxy (ESRP) providers, mapping service providers, and PSAPs 🏗️.
This section outlines which entities will be considered in the routing scenarios discussed 👀.
Location
Information +-----------------+
|(1) |Internet | +-----------+
v |Access | | |
+-----------+ |Provider | | Mapping |
| | | (3) | | Service |
| Emergency |<---+-----------------+-->| |
| Caller | | (2) | +-----------+
| |<---+-------+ | ^
+-----------+ | +----|---------+------+ |
^ | | Location | | |
| | | Information<-+ | |
| +--+--------------+ |(5) | | (6)
| | | | |
| | +-----------v+ | |
| (4) | | | | |
+--------------+--->| ESRP |<--+---+
| | | | |
| | +------------+ |
| | ^ |
| | (7) | | +----+--+
| (8) | +------------>| |
+--------------+----------------------->| PSAP |
| | | |
|Application/ | +----+--+
|Voice |
|Service |
|Provider |
+---------------------+
Figure 1: Framework for Emergency Call RoutingFigure 1 shows how the entities involved in the call talk to each other 📊. There are a bunch of different deployment choices, and you can totally see them just by looking at the figure 👀✨.
Is the Internet Access Provider also the Application/Voice Service Provider? 🤔 In today's Internet, the roles of Internet access provider and application/voice service provider are usually handled by different entities 🫠. So the Application/Voice Service Provider usually can't directly figure out the physical location of the emergency caller 📍.
The overlapping squares in the figure mean some functions can be collapsed into a single entity 🧩. For example, the Application/Voice Service Provider might be the same entity as the Internet Access Provider. There is, however, no requirement that this must be the case 💅. Also, we consider that end systems might act as their own ASP/VSP, e.g., either for enterprises or for residential users 🏠.
Here are the potential interactions between the entities depicted in Figure 1, described below 🦋:
- Location information might be available to the end host itself 📱.
- Location information might, however, also be obtained from the Internet Access Provider 🛜.
- The emergency caller might need to consult a mapping service to determine the PSAP (or other relevant information) that's appropriate for the physical location of the emergency caller, possibly considering other attributes, such as appropriate language support by the emergency call taker 🌍.
- The emergency caller might get help with emergency call routing from infrastructure elements that are emergency call routing support entities, such as an Emergency Service Routing Proxy (ESRP) in SIP 🙋♀️.
- Location information is used by emergency call routing support entities for subsequent mapping requests 📬.
- Emergency call routing support entities might need to consult a mapping service to determine where to route the emergency call 🧭.
- For infrastructure-based emergency call routing (in contrast to UE-based emergency call routing), the emergency call routing support entity needs to forward the call to the PSAP 🚀.
- The emergency caller may interact directly with the PSAP, where the UE invokes mapping and initiates a connection, without relying on any intermediary emergency call routing support entities 💖.
5. High-Level Requirements ✨
okay so before we get into the nitty gritty, the doc drops a list of big-picture architecture requirements 🏗️ these are the vibes that shape some of the more specific rules later on, so keep them in mind bestie 💖
Re1. Application/Voice service provider existence: The initiation of an IP-based emergency call SHOULD NOT assume the existence of an Application/Voice Service Provider (ASP/VSP). 🙅♀️
Motivation: the caller may not have an application/voice service provider, and that's totally valid 🏠 for example, a residence may have its own DNS domain and run its own SIP proxy server for that domain. on a bigger scale, a university might provide voice services to its students and staff but not be a telecommunication provider at all 🎓
Re2. International applicability: Regional, political, and organizational aspects MUST be considered during the design of protocols and protocol extensions that support IP-based emergency calls. 🌍
Motivation: a device or software made or bought in one country MUST be able to place emergency calls in another country 🛫 system components should not be biased toward one particular set of emergency numbers or languages 🗣️ and countries have evolved different ways of organizing emergency services. some centralize them, while others have smaller regional subdivisions, like the United States or municipalities, handling emergency calls within their own jurisdiction 🗺️
Re3. Distributed administration: Deployment of IP-based emergency services MUST NOT depend on a single central administrative authority. 🕸️
Motivation: the mapping protocol design has to make it possible to deploy and administer emergency calling features on a regional or national basis without needing coordination with other regions or nations 💅 the system cannot assume, for example, that there is one single global entity issuing certificates for PSAPs, ASP/VSPs, IAPs, or other participants. no single boss, periodt 👑
Re4. Multi-mode communication: IP-based emergency calls MUST support multiple communication modes, including, for example, audio, video, and text. 📞📹💬
Motivation: within the PSTN, voice and text telephony (often called TTY or text-phone in North America) are the only commonly supported media 🥱 emergency calling needs to handle a whole variety of media. that should include voice, conversational text (RFC 4103 [RFC4103]), instant messaging, and video ✨
Re5. Mapping result usability: The mapping protocol MUST return one or more URIs that are usable within a standard signaling protocol (i.e., without special emergency extensions). 🎯
Motivation: for example, a SIP URI returned by the mapping protocol needs to be usable by any SIP-capable phone within a SIP-initiated emergency call 📱 this is the opposite of a "special purpose" URI, which a legacy SIP device might not recognize at all 🙈
Re6. PSAP URI accessibility: The mapping protocol MUST support interaction between the client and server where no enrollment to a mapping service exists or is required. 🔓
Motivation: the mapping server may well be operated by a service provider, but getting to the server offering the mapping MUST NOT require use of a specific ISP or ASP/VSP 💖 no gatekeeping allowed
Re7. Common data structures and formats: The mapping protocol SHOULD support common formats (e.g., PIDF-LO) for location data. 🗂️
Motivation: location databases should not need to be transformed or modified in any unusual or unreasonable way for the mapping protocol to use the data 🧃 for example, a database full of civic addresses used by location servers might be used for multiple purposes and applications beyond emergency service location-to-PSAP URI mapping. it's giving reusability 🔁
Re8. Anonymous mapping: The mapping protocol MUST NOT require the true identity of the target for which the location information is attributed. 🕵️♀️
Motivation: ideally, no identity information is provided via the mapping protocol at all 🫥 where identity information is provided, it may be in the form of an unlinked pseudonym (RFC 3693 [RFC3693]) 🦋
6. Identifying the Caller's Location 📍
okay the big question here is how and when to attach location info to the VoIP emergency signaling messages 🤔 location can be provided directly (by value) or through a pointer (by reference), and it can represent either a civic location or a geographic location. honestly it's a lot to keep track of, so let's break it down 💅 in general, there are three modes for associating a location with an emergency call:
- UA-inserted: the caller's user agent inserts the location information into the call-signaling message. 📨
- UA-referenced: the caller's user agent provides a pointer (i.e., a location reference), via a permanent or temporary identifier, to the location information. that info is stored by a location server somewhere else and then retrieved by the PSAP, ESRP, or other authorized entity 🔍
- Proxy-inserted: a proxy along the call path inserts the location or location reference. 🧚
The following requirements apply 📋
Lo1. Reference datum: The mapping protocol MUST support the WGS-84 coordinate reference system and MAY support other coordinate reference systems. 🌐
Motivation: there are lots of different datums around the world, but this document recommends WGS-84 🙌 it's designed to describe the whole earth rather than one continent or other region, and it's commonly used to represent Global Positioning System coordinates. main character datum 🛰️
Lo2. Location delivery by-value: The mapping protocol MUST support the delivery of location information using a by-value method, though it MAY also support de-referencing a URL that references a location object. 🎁
Motivation: the mapping protocol is not required to support the ability to de-reference specific location references 🙃
Lo3. Alternate community names: The mapping protocol MUST support both the jurisdictional community name and the postal community name fields within the PIDF-LO [RFC4119] data. 🏘️
Motivation: the mapping protocol must accept queries with either a postal or jurisdictional community name field, or both, and provide appropriate responses 🫶 if a mapping query contains only one community name but the database has both jurisdictional and postal community names, the mapping protocol response SHOULD return both community names. the full set, no cap ✨
Lo4. Validation of civic location: The mapping protocol MUST be able to report the results of validating civic locations (street addresses). 🏡
Motivation: location validation is a chance to figure out ahead of time whether a successful mapping to the appropriate PSAP will likely happen when it's needed 🔮 validation can also help avoid delays during emergency call setup caused by invalid location data. no one wants that lag 💀
Lo5. Information about location data used for mapping: The mapping protocol MUST support the ability to provide ancillary information about the resolution of location data used to retrieve a PSAP URI. 🔎
Motivation: the mapping server may not use all the data elements in the provided location information to find a match, or it may be able to find a match based on everything except some specific data elements 🧩 the uniqueness of this information set may be used to tell emergency jurisdictions apart. in this requirement, precision or resolution might mean, for example, explicitly identifying the data elements that were successfully used in the mapping ✅
Lo6. Contact for location problems: The mapping protocol MUST support a mechanism to contact an appropriate authority to resolve mapping-related issues for the queried location. 📞
For example, the querier may want to report problems with the response values, or indicate that the mapping database is mistaken in declaring a civic location as non-existent 🙅♀️
Motivation: initially, authorities may provide URLs where a human user can report problems with an address or location 💻 web services may also be defined to automate that reporting. for example, the querier may want to report that the mapping database is missing a newly built or renamed street or house number 🏗️
Lo7. Limits to validation: Successful validation of a civic location MUST NOT be required to place an emergency call. 🚨
Motivation: in some cases, a civic location may not be considered valid. that should NOT get the call dropped or rejected by any entity along the call setup signaling path to the PSAP 🙌 wait, sorry, let me say that properly: that fact SHOULD NOT result in the call being dropped or rejected by any entity along the call setup signaling path to the PSAP. the caller still gets through 💖
Lo8. 3D sensitive mapping: The mapping protocol MUST implement support for both 2D and 3D location information, and MAY accept either a 2D or 3D mapping request as input. 🧊
Motivation: it's expected that queriers may provide either 2D or 3D data 📐 when a 3D request is presented within an area that the mapping server only defines with 2D data, the mapping result would be the same as if the height or altitude coordinate had been omitted from the mapping request. so it all works out 🫧
Lo9. Database type indicator: The mapping protocol MAY support a mechanism that provides an indication describing a specific type of location database used. 🏷️
Motivation: it's useful to know where the data in the database used for location validation came from, whether it's civic or geographic location matching 📚 in the United States, sources of data could include the United States Postal Service, the Master Street Address Guide (MSAG), or commercial map data providers 🇺🇸
7. Emergency Service Identifier ✨
okay so emergency service identifiers are basically protocol constants 💅 they let things like SIP proxy servers tell emergency calls apart from regular ones, and figure out exactly which emergency service the caller wants 🚨 they're a subclass of service identifiers, which is the bigger group of ids for any service a caller can reach. the service URN [RFC5031] is one example, but tel URIs [RFC3966] can also play this role during a transition period 🦋
since this doc only deals with emergency services, we use "emergency service identifier" and "service identifier" interchangeably, no cap 🫶 here's what the requirements look like:
Id1. Multiple emergency services: the mapping protocol MUST be able to support different emergency services distinguished by different service identifiers.
Motivation: some jurisdictions have multiple kinds of emergency services that work independently and can be contacted directly, like fire, police, and ambulance 🚒🚓🚑
Id2. Extensible emergency service identifiers: the mapping protocol MUST support an extensible list of emergency identifiers, though it is not required to provide mappings for every possible service.
Motivation: extensibility is required because new emergency services may pop up over time, globally or in some jurisdictions 🌍 availability also depends on the location, like how the Netherlands is unlikely to offer a mountain rescue service 🏔️
Id3. Discovery of emergency number: the mapping protocol MUST be able to return the location-dependent emergency number for the location indicated in the query.
Motivation: people are trained to dial the right emergency number, so there needs to be a way to figure out the number at the caller's current location 📍
Id4. Home emergency number recognition: User equipment MUST be able to translate a home emergency number into an emergency service identifier.
Motivation: the UE could be pre-provisioned with the info to do that translation, or it could discover the emergency number by querying the mapping protocol with its home location 🏠
Id5. Emergency number replacement: There SHOULD be support for replacement of the emergency number with the appropriate emergency service identifier for each signaling protocol used for an emergency call, based on local conventions, regulations, or preference (e.g., as in the case of an enterprise).
Motivation: any signaling protocol needs some identifier to indicate the called party, and the UE may lack the capability to determine the actual service URL (PSAP URI) 🫠 local conventions may be needed as a transition mechanism. Relying on recognizing local numbering conventions makes it hard for devices to be used outside their home context and for external devices to be introduced into a network, so protocols should use standardized emergency service identifiers 💖
Id6. Emergency service identifier marking: Signaling protocols MUST support emergency service identifiers to mark a call as an emergency call.
Motivation: marking makes sure downstream elements handle the call properly, even if they don't recognize something like a local variant of a logical emergency address 👀 this marking mechanism is related to, but independent of, marking calls for prioritized call handling [RFC4412] ✨
Id7. Handling unrecognized emergency service identifiers: There MUST be support for calls that are initiated as emergency calls even if the specific emergency service requested is not recognized by the ESRP. Such calls will then be routed to a generic emergency service.
Motivation: fallback routing lets new services roll out bit by bit while avoiding non-routable emergency calls 🌸 for example, a call for marine rescue services would be routed to a general PSAP if the caller's location doesn't offer marine rescue services yet 🌊
Id8. Return fallback service identifier: The mapping protocol MUST be able to report back the actual service mapped if the mapping protocol substitutes another service for the one requested.
Motivation: a mapping server may be configured to automatically look up the PSAP for another service if the user-requested service isn't available for that location 🧚 for example, if there's no marine rescue service, the mapping protocol might return the PSAP URL for general emergencies and include the urn:service.sos identifier in the response to alert the querier to that fact 🚨
Id9. Discovery of visited emergency numbers: The mapping protocol MUST support a mechanism to allow the end device to learn visited emergency numbers.
Motivation: travelers visiting a foreign country may spot the local emergency number, like painted on the side of a fire truck, and then rightfully expect to be able to dial it 🚒💅 similarly, a local "good Samaritan" may use a tourist's cell phone to summon help 🫶
8. Mapping Protocol 🗺️✨
Okay bestie, there are two basic ways to invoke the mapping protocol, and we call them caller-based and mediated 💅. Either way, the mapping client starts a request to a mapping server through a mapping protocol. There's a proposed one called LoST, laid out in [lost] 🦋.
For caller-based resolution, the caller's user agent is the one that calls the mapping protocol to figure out the right PSAP from the location it has 📍. This can happen way before the emergency call is actually placed, or right at call time ⏰.
For mediated resolution, an emergency call routing support entity, like a SIP (outbound) proxy or redirect server, is the one that invokes the mapping service 💜.
Servers can get used as outbound proxies by clients who aren't in the same geographic area as the proxy, so any proxy server has to be able to translate any caller location to the appropriate PSAP 😭. (A traveler might accidentally, or even on purpose, set their home proxy as their outbound proxy while they're far away from home 🧳, so yeah, it's a whole thing 🙈.)
Ma1. Baseline query protocol: A mandatory-to-implement protocol MUST be specified.
Motivation: An over-abundance of similarly capable choices appears undesirable for interoperability 🌸.
Ma2. Extensible protocol: The mapping protocol MUST be designed to support the extensibility of location data elements, both for new and existing fields ✨.
Motivation: This is needed, for example, to accommodate future extensions-to-location information that might be included in the PIDF-LO ([RFC4119]) 💅.
Ma3. Incrementally deployable: The mapping protocol MUST be designed to support its incremental deployment 🌱.
Motivation: It must not be necessary, for example, to have a global street level database before deploying the system 🙅♀️. It is acceptable to have some misrouting of calls when the database does not (yet) contain accurate PSAP service area information 🤷♀️.
Ma4. Any time mapping: The mapping protocol MUST support the ability of the mapping function to be invoked at any time, including while an emergency call is in process and before an emergency call is initiated ⏳.
Motivation: If the mapping query fails at call time, it may be advantageous to be able to fall back to the result of an earlier mapping query 🔁. This prior knowledge would be obtained by performing a mapping query at any time prior to an emergency call 🧠.
Ma5. Anywhere mapping: The mapping protocol MUST support the ability to provide mapping information in response to an individual query from any (earthly) location, regardless of where the mapping client is located, either geographically or by network location 🌍.
Motivation: The mapping client, such as an ESRP, may not necessarily be anywhere close to the caller or the appropriate PSAP, but must still be able to obtain mapping information 🛰️.
Ma6. Appropriate PSAP: The mapping protocol MUST support the routing of an emergency call to the PSAP responsible for a particular geographic area 🚨.
Motivation: Routing to the wrong PSAP will result in delays in handling emergencies as calls are redirected, and therefore will also result in inefficient use of PSAP resources at the initial point of contact 😤. It is important that the location determination mechanism not be fooled by the location of IP telephony gateways or dial-in lines into a corporate LAN (and dispatch emergency help to the gateway or campus, rather than the caller), multi-site LANs and similar arrangements 🏢.
Ma7. Multiple PSAP URIs: The mapping protocol MUST support a method to return multiple PSAP URIs, which cover the same geographic area 👯♀️.
Motivation: Different contact protocols (e.g., PSTN via tel URIs and IP via SIP URIs) may be routed to different PSAPs 📞. Less likely, two PSAPs may overlap in their coverage region 🫣.
Ma8. Single primary URI per contact protocol: Though the mapping protocol may be able to include multiple URIs in the response, it SHOULD return only one primary URI per contact protocol used, so that clients are not required to select among different targets for the same contact protocol 🎯.
Motivation: There may be two or more URIs returned when multiple contact protocols are available (e.g., SIP and SMS) 💬. The client may select among multiple contact protocols based on its capabilities, preference settings, or availability 🎛️.
Ma9. Non-preferred URI schemes: The mapping protocol MAY support the return of a less-preferred URI scheme, such as a tel URI ☎️.
Motivation: In order to provide incremental support to non-IP PSAPs, it may be necessary to be able to complete an emergency call via the PSTN 🌉.
Ma10. URI properties: The mapping protocol MUST support the ability to provide ancillary information about a contact that allows the mapping client to determine relevant properties of the PSAP URI 🏷️.
Motivation: In some cases, the same geographic area is served by several PSAPs; for example, a corporate campus might be served by both a corporate security department and the municipal PSAP 🏫🚓. The mapping protocol should then return URIs for both, with information allowing the querying entity to choose one or the other 🧐. This determination could be made by either an ESRP, based on local policy, or by direct user choice, in the case of caller-based methods 🙋♀️.
Ma11. Mapping referral: The mapping protocol MUST support a mechanism for the mapping client to contact any mapping server and be referred to another mapping server that is more qualified to answer the query 🔀.
Motivation: Referrals help mitigate the impact of incorrect configuration that directs a client to the wrong initial mapping server 🩹.
Ma12. Split responsibility: The mapping protocol MUST support the division of data subset handling between multiple mapping servers within a single level of a civic location hierarchy 🧩.
Motivation: For example, two mapping servers for the same city or county may handle different streets within that city or county 🏘️.
Ma13. URL for error reporting: The mapping protocol MUST support the ability to return a URL that can be used to report a suspected or known error within the mapping database 🐛.
Motivation: If an error is returned, for example, there needs to be a URL that points to a resource that can explain or potentially help resolve the error 🔗.
Ma14. Resilience to mapping server failure: The mapping protocol MUST support a mechanism that enables the client to fail over to different (replica) mapping server 🛟.
Motivation: The failure of a mapping server should not preclude the mapping client from receiving an answer to its query 💪.
Ma15. Traceable resolution: The mapping protocol SHOULD support the ability of the mapping client to be able to determine the entity or entities that provided the emergency address resolution information 🕵️♀️.
Motivation: To improve reliability and performance, it is important to be able to trace which servers contributed to the resolution of a query 🧵.
Ma16. Minimal additional delay: Mapping protocol execution SHOULD minimize the amount of delay within the overall call-setup time ⚡.
Motivation: Since outbound proxies will likely be asked to resolve the same geographic coordinates repeatedly, a suitable time-limited caching mechanism should be supported 🗃️.
Ma17. Freshness indication: The mapping protocol SHOULD support an indicator describing how current the information provided by the mapping source is 🕰️.
Motivation: This is especially useful when an alternate mapping is requested, and alternative sources of mapping data may not have been created or updated with the same set of information or within the same time frame 🫠. Differences in currency between mapping data contained within mapping sources should be minimized 🎀.
9. Security Considerations 🔐
Okay, the threats and security requirements get their own document, [RFC5069] 🔥. Security is no joke, so this one is serious business, bestie 💀.
10. Contributors 🌈
The information in this document is partially derived from text written by the following contributors 🫶:
Nadine Abbott nabbott@telcordia.com
Hideki Arai arai859@oki.com
Martin Dawson Martin.Dawson@andrew.com
Motoharu Kawanishi kawanishi381@oki.com
Brian Rosen br@brianrosen.net
Richard Stastny Richard.Stastny@oefeg.at
Martin Thomson Martin.Thomson@andrew.com
James Winterbottom James.Winterbottom@andrew.com11. Acknowledgments 💖
In addition to thanking those listed above, we would like to also thank Guy Caron, Barry Dingle, Keith Drage, Tim Dunn, Patrik Faltstrom, Clive D.W. Feather, Raymond Forbes, Randall Gellens, Michael Haberler, Michael Hammer, Ted Hardie, Gunnar Hellstrom, Cullen Jennings, Marc Linsner, Rohan Mahy, Patti McCalmont, Don Mitchell, John Morris, Andrew Newton, Steve Norreys, Jon Peterson, James Polk, Benny Rodrig, John Rosenberg, Jonathan Rosenberg, John Schnizlein, Shida Schubert, James Seng, Byron Smith, Barbara Stark, Richard Stastny, Tom Taylor, Hannes Tschofenig, and Nate Wilcox for their helpful input 🙌✨.
12. References 📚
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.12.2. Informative References
[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.
[RFC3351] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A.
van Wijk, "User Requirements for the Session Initiation
Protocol (SIP) in Support of Deaf, Hard of Hearing and
Speech-impaired Individuals", RFC 3351, August 2002.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3860] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, August 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[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.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031,
January 2008.
[RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M.
Shanmugam, "Security Threats and Requirements for
Emergency Call Marking and Mapping", RFC 5069,
January 2008.
[lost] Hardie, T., "LoST: A Location-to-Service Translation
Protocol", Work in Progress, August 2007.
[toip] Wijk, A. and G. Gybels, "Framework for real-time text over
IP using the Session Initiation Protocol (SIP)", Work
in Progress, August 2006.Authors' Addresses ✨
okay bestie, here are the people to contact about this one 🫶 I'm keeping their details exactly as written so nothing gets lost in translation 📮
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Roger Marshall (editor)
TeleCommunication Systems, Inc.
2401 Elliott Avenue
2nd Floor
Seattle, WA 98121
US
Phone: +1 206 792 2424
EMail: rmarshall@telecomsys.com
URI: http://www.telecomsys.comHenning is at Columbia University in the Computer Science department 🎓 and Roger is the editor, working at TeleCommunication Systems, Inc. in Seattle 🌸
Full Copyright Statement 💜
the copyright is held by the IETF Trust, and it's dated 2008 📅
this document is subject to the rights, licenses and restrictions in BCP 78 🔐 and, except for what BCP 78 says, the authors keep all of their rights 🦋
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
translation: the contributor, the organisation they represent or sponsor, the Internet Society, the IETF Trust and the IETF all say there are no warranties, express or implied 🙈 that includes no promise that using the info won't infringe anyone's rights, and no implied warranties of merchantability or fitness for a particular purpose 🧚
Intellectual Property 🔥
the IETF doesn't take a side on whether any intellectual property rights apply to the tech in this document, or whether any licence to use those rights is available 🤷♀️ it also doesn't claim it has looked for any such rights on its own 👀 you can find the rules for rights in RFC documents in BCP 78 and BCP 79 📚
copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licences, or the results of anyone trying to get a general licence or permission to use proprietary rights, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 💖
the IETF also invites anyone to flag copyrights, patents, patent applications or other proprietary rights that might cover technology needed to implement this standard 🎀 send that info to the IETF at ietf-ipr@ietf.org 💌
that's the whole document, we made it bestie 🌈✨
📦 where this page comes from
- ietf: rfc5012 2008-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms