RFC 6881

Best Current Practice for Communications Services in Support of Emergency Calling

📅 published March 2013, from ietf

RFC 6881 🎀 Best Current Practice for Communications Services in Support of Emergency Calling

Part 1 of 6 💖

Okay bestie, this is RFC 6881 🦋, a Best Current Practice (that's BCP 181 🌸) from the Internet Engineering Task Force (IETF). It was written by B. Rosen from NeuStar and J. Polk from Cisco Systems. The ISSN is 2070-1721, and it's dated March 2013 📅 so yes, it's a bit of a classic now.

Abstract ✨

The IETF and other standards organizations are working on different parts of making emergency calls over IP networks 📞 This memo is the current best practice for how devices, networks, and services that use IETF protocols should use those standards to place emergency calls 🚨

Status of This Memo 💅

This memo documents an Internet Best Current Practice.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🙌 If you want more info on BCPs, check out Section 2 of RFC 5741.

For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6881 🔗

Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) as in effect on the date of publication of this document. Please read these documents carefully, because they describe your rights and restrictions for this document 📜 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 without warranty as described in the Simplified BSD License.

Table of Contents 🗺️

1. Introduction ....................................................3
2. Terminology .....................................................3
3. Overview of How Emergency Calls Are Placed ......................3
4. Which Devices and Services Should Support Emergency Calls? ......4
5. Identifying an Emergency Call ...................................4
6. Location and Its Role in an Emergency Call ......................5
   6.1. Types of Location Information ..............................6
   6.2. Location Determination .....................................6
        6.2.1. User-Entered Location Information ...................6
        6.2.2. Access Network "Wire Database" Location
               Information .........................................6
        6.2.3. End System Measured Location Information ............7
        6.2.4. Network Measured Location Information ...............7
   6.3. Who Adds Location?  The Endpoint, or the Proxy? ............8
   6.4. Location and References to Location ........................8
   6.5. End System Location Configuration ..........................8
   6.6. When Location Should Be Configured ........................10
   6.7. Conveying Location ........................................11
   6.8. Location Updates ..........................................11
   6.9. Multiple Locations ........................................12
   6.10. Location Validation ......................................12
   6.11. Default Location .........................................13
   6.12. Other Location Considerations ............................13
7. LIS and LoST Discovery .........................................13
8. Routing the Call to the PSAP ...................................14
9. Signaling of Emergency Calls ...................................15
   9.1. Use of TLS ................................................15
   9.2. SIP Signaling Requirements for User Agents ................16
   9.3. SIP Signaling Requirements for Proxy Servers ..............17
10. Callbacks .....................................................18
11. Mid-Call Behavior .............................................19
12. Call Termination ..............................................19
13. Disabling of Features .........................................19
14. Media .........................................................20
15. Testing .......................................................21
16. Security Considerations .......................................22
17. IANA Considerations ...........................................22
   17.1. Test Service URN .........................................22
   17.2. 'test' Subregistry .......................................23
18. Acknowledgements ..............................................23
19. References ....................................................23
   19.1. Normative References .....................................23
   19.2. Informative References ...................................27

1. Introduction 🌸

This document explains how access networks, Session Initiation Protocol [RFC3261] user agents, proxy servers, and Public Safety Answering Points (PSAPs) handle emergency calling, following [RFC6443] 💁‍♀️ It's meant to go alongside [RFC6443] and follows the same section headings, numbering, and content, so you really need to understand [RFC6443] before this one makes sense. This Best Current Practice (BCP) breaks down the requirements for end devices and applications (requirements labeled "ED-"), access networks (including enterprise access networks) (requirements labeled "AN-"), service providers (requirements labeled "SP-"), and PSAPs. The goal is globally interoperable emergency calling on the Internet 🌍

This document also covers requirements for "intermediate" devices that sit between end devices or applications and the access network. A home router is one example 🏠 Reporting location on an emergency call (see Section 6) may depend on how well those intermediate devices meet the requirements labeled "INT-".

The access network requirements apply to networks that might be used to place emergency calls using IETF protocols. Local regulations may affect whether you need to support the access network requirements in this document ⚖️

Other organizations, like the National Emergency Number Association (NENA), define the PSAP interface. NENA's documents reference this document ✨

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶

This document uses terms from [RFC3261], [RFC5012], and [RFC6443] 🧚

3. Overview of How Emergency Calls Are Placed 🚑

An emergency call stands out from every other call (Section 5) because of a unique service URN [RFC5031] that goes into the call setup signaling when a home or visited emergency dial string is detected 🔥 Emergency services are local to specific geographic regions, so a caller has to get their location (Section 6) before making an emergency call. To get it, either the endpoint has some way of measuring its location (for example GPS, see [RFC6443] Section 6.2.3), or the endpoint is configured (Section 6.5) with its location by the access network's Location Information Server (LIS) 🛰️ The location is then conveyed (Section 6.7) in the SIP signaling with the call. The call gets routed (Section 8) based on location using the Location-to-Service Translation (LoST) protocol [RFC5222], which maps a location to a set of PSAP URIs. Each URI resolves to either a PSAP or an Emergency Services Routing Proxy (ESRP) that serves a group of PSAPs 🎯 The call arrives at the PSAP with the location included in the SIP INVITE request 💌

4. Which Devices and Services Should Support Emergency Calls? 🤔

ED-1: A device or application that implements SIP calling SHOULD support emergency calling. Some jurisdictions have regulations about which devices need to support emergency calling, and developers are encouraged to make sure the devices they build meet the relevant regulatory requirements. Unfortunately, those regulations vary so much that it's impossible to accurately describe exactly when developers do or don't have to support emergency calling 😩

SP-1: If a device or application expects to be able to place a call for help, the service provider that supports it MUST facilitate emergency calling. Some jurisdictions have regulations governing this 🚨

ED-2: Devices that create media sessions and exchange real-time 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. Some jurisdictions have regulations governing this 🎧

5. Identifying an Emergency Call 🔍

ED-3: Endpoints SHOULD recognize dial strings of emergency calls. If the service provider always knows the location of the device (the correct dial string depends on which country a caller is in), the service provider MAY recognize them; see SP-2. Wait, sorry, let me restate that properly: the service provider may recognize them, see SP-2 💅

SP-2: Proxy servers SHOULD recognize emergency dial strings if, for some reason, the endpoint does not recognize them.

ED-4/SP-3: Emergency calls MUST be marked with a service URN in the Request-URI of the INVITE.

ED-5/SP-4: Geographically local dial strings MUST be recognized.

ED-6/SP-5: Devices MUST be able to be configured with the home country, from which the home dial string(s) can be determined.

ED-7/SP-6: Emergency dial strings SHOULD be determined from LoST [RFC5222]. Dial strings MAY be configured directly into the device.

AN-1: LoST servers MUST return dial strings for emergency services.

ED-8: Endpoints that do not recognize emergency dial strings SHOULD send dial strings as per [RFC4967].

SP-7: If a proxy server recognizes dial strings on behalf of its clients, it MUST recognize emergency dial strings represented by [RFC4967] and SHOULD recognize the emergency dial strings represented by a tel URI [RFC3966] 📱

ED-9: Endpoints SHOULD be able to have home dial strings provisioned.

SP-8: Service providers MAY provision home dial strings in devices.

ED-10: Devices SHOULD NOT have one-button emergency calling initiation. Accidental presses are a whole vibe 🙈

ED-11/SP-9: All sub-services for the 'sos' service specified in [RFC5031] MUST be recognized.

6. Location and Its Role in an Emergency Call 📍

Handling location for emergency calling usually involves several steps, and multiple entities are involved, so it's a whole process 🧩 In Internet emergency calling, the endpoint's location is figured out using a variety of measurement or wire-tracing methods. Endpoints can be configured with their own location by the access network. Sometimes a proxy server can insert location into the signaling on behalf of the endpoint 🎀 The location is mapped to the URI the call gets sent to, and it's conveyed to the PSAP (and other entities) in the signaling. We also use Location Configuration Protocols (LCPs), the Location-to-Service Mapping Protocol, and Location Conveyance Protocols for these jobs 🌷 The Location-to-Service Translation protocol [RFC5222] is the Location Mapping Protocol defined by the IETF 👑

6.1. Types of Location Information ✨

okay so there are a few different forms of location 🗺️ Every IETF location configuration and location conveyance protocol supports both civic and geospatial (geo) forms, bestie. Civic forms can include postal fields and jurisdictional fields. A cell tower/sector can be shown as a point (geo or civic) or as a polygon 🔺 Endpoints, intermediate devices, and service providers that receive any other form of location MUST map it into either a geo or civic form for use in emergency calls. no cap, that's the rule 💅

ED-12/INT-1/SP-10: Endpoints, intermediate devices, and service providers MUST be prepared to handle location represented in either civic or geo form. 🫶

ED-13/INT-2/SP-11/AN-2: Entities MUST NOT convert (civic to geo or geo to civic) from the form of location that the determination mechanism (see Section 6.2) supplied before it gets to the PSAP. Do not switch forms on it 🙅‍♀️ It's giving "keep the original vibe."

6.2. Location Determination 🧭

ED-14/INT-3/AN-3: Any location determination mechanism MAY be used, as long as the accuracy of the location meets local requirements. 🌸

6.2.1. User-Entered Location Information 🎀

ED-15/INT-4/AN-4: Devices, intermediate devices, and/or access networks SHOULD support a manual method to override the location the access network determines. When the override location is supplied in civic form, it MUST be possible for the resultant Presence Information Data Format Location Object (PIDF-LO) received at the PSAP to contain any of the elements specified in [RFC4119] and [RFC5139]. The main character override moment 👑

6.2.2. Access Network "Wire Database" Location Information 🔌

AN-5: Access networks supporting copper, fiber, or other hard-wired IP packet services SHOULD support location configuration. If the network does not support location configuration, it MUST require every device or intermediate device that connects to the network to support end system measured location. 🦋

AN-6/INT-5: Access networks and intermediate devices providing wire database location information SHOULD provide interior location data (building, floor, room, cubicle) where possible. It is RECOMMENDED that interior location be provided when spaces exceed approximately 650 square meters. See [RFC6443] Section 6.2.2 for a discussion of how this value was determined 🤓

AN-7/INT-6: Access networks and intermediate devices (including enterprise networks) that support intermediate range wireless connections (typically 100 m or less of range) and that do not support a more accurate location determination mechanism such as triangulation MUST support location configuration where the location of the access point is reflected as the location of the clients of that access point. 📡

AN-8/INT-7: Where the access network provides location configuration, intermediate devices MUST either be transparent to it or provide an interconnected client for the supported configuration mechanism and a server for a configuration protocol supported by end devices downstream of the intermediate device, such that the location provided by the access network is available to clients as if the intermediate device was not in the path. Be invisible, bestie, like a true icon 🧚

6.2.3. End System Measured Location Information 📏

ED-16/INT-8: Devices MAY support end system measured location. See [RFC6443] Section 6 for a discussion of accuracy of location. ✨

ED-17/INT-9/AN-9: Devices that support endpoint measuring of location MUST have at least a coarse location capability (typically <1 km accuracy) for the routing of calls. The location mechanism MAY be a service provided by the access network. 🍓

6.2.4. Network Measured Location Information 📶

AN-10: Access networks MAY provide network measured location determination. Wireless access networks that do not supply network measured location MUST require every device or intermediate device connected to the network to support end system measured location. Uncertainty and confidence may be specified by local regulation. Where not specified, uncertainty of less than 100 meters with 95% confidence is RECOMMENDED for dispatch location. 💜

AN-11: Access networks that provide network measured location MUST have at least a coarse location (typically <1 km when not location hiding) capability at all times for the routing of calls. 🌈

AN-12: Access networks with a range of <10 meters (e.g., personal area networks such as Bluetooth) MUST provide a location to mobile devices connected to them. The location provided SHOULD be that reported by the upstream access network unless a more accurate mechanism is available. 🫧

6.3. Who Adds Location? The Endpoint, or the Proxy? 🤔

ED-18/INT-10: Endpoints SHOULD attempt to configure their own location using the Location Configuration Protocols (LCPs) listed in ED-21. Do it yourself first, babe 💅

SP-12: Proxies MAY provide location on behalf of devices if:

  • The proxy has a relationship with all access networks the device could connect to, and the relationship allows it to obtain location.
  • The proxy has an identifier, such as an IP address, that can be used by the access network to determine the location of the endpoint, even in the presence of NAT and VPN tunnels that may obscure the identifier between the access network and the service provider. 🕵️‍♀️

ED-19/INT-11/SP-13: Where proxies provide location on behalf of endpoints, the service provider MUST ensure that either the end device is provided with the local dial strings for its current location (where the end device recognizes dial strings), or the service provider proxy MUST detect the appropriate local dial strings at the time of the call. Someone has to know the right number, fr fr 📞

6.4. Location and References to Location 🔗

ED-20/INT-12: Devices SHOULD be able to accept and forward location-by-value or location-by-reference. An end device that receives location-by-reference (and does not also get the corresponding value) MUST be able to perform a dereference operation to obtain a value. Look it up, periodt 🧚‍♀️

6.5. End System Location Configuration 🛰️

Obtaining location from the access network may be preferable even if the device can measure its own location, especially indoors where most measurement mechanisms are not accurate enough. The requirements listed in this section do not apply to devices that can accurately measure their own location. So if your device is already super accurate, you're exempt, iykyk 🙈

ED-21/INT-13: Devices MUST support both the Dynamic Host Configuration Protocol (DHCP) location options [RFC4776] [RFC6225] and HTTP-Enabled Location Delivery (HELD) [RFC5985]. When devices deploy a specific access network interface for which location configuration mechanisms such as Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device SHOULD support the additional respective access network specific location configuration mechanism. 💖

AN-13/INT-14: The access network MUST support either DHCP location options or HELD. The access network SHOULD support other location configuration technologies that are specific to the type of access network. 🌸

AN-14/INT-15: Where a router is employed between a LAN and WAN in a small (less than approximately 650 square meters) area, the router MUST be transparent to the location provided by the WAN to the LAN. This may mean the router must obtain location as a client from the WAN and supply an LCP server to the LAN with the location it obtains. Where the area is larger, the LAN MUST have a location configuration mechanism satisfying the requirements of this document. Routers, be a background character 🧸

ED-22/INT-16: Endpoints SHOULD try all LCPs supported by the device in any order or in parallel. The first one that succeeds in supplying location MUST be used. First one to deliver wins, no drama 🏆

AN-15/INT-17: Access networks that support more than one LCP MUST reply with the same location information (within the limits of the data format for the specific LCP) for all LCPs it supports. Consistency is everything, bestie ✨

ED-23/INT-18/SP-14: When HELD is the LCP, the request MUST specify a value of emergencyRouting for the responseTime parameter and use the resulting location for routing. If a value for dispatch location will be sent, another request with the responseTime parameter set to emergencyDispatch must be completed, with the result sent for dispatch purposes. Two requests, two jobs, very organized 📋

ED-24: Where the operating system supporting application programs that need location for emergency calls does not allow access to Layer 2 and Layer 3 functions necessary for a client application to use DHCP location options and/or other location technologies that are specific to the type of access network, the operating system MUST provide a published API conforming to ED-12 through ED-23 and ED-25 through ED-32. It is RECOMMENDED that all operating systems provide such an API. The OS really needs to share the tea 🫖🎀

⚠️ Reminder: the labels like ED-12 and AN-5 are how the document points back to each rule, so keep them handy when you're cross-checking. 🦋

6.6. When Location Should Be Configured

okay so if an endpoint is manually configured, none of the requirements in this section apply to it 💅 the rest of this is for devices that figure out their location on their own

ED-25/INT-19: bestie, endpoints SHOULD obtain location immediately after obtaining local network configuration information 🫶

ED-26/INT-20: if the device is set up to use DHCP for bootstrapping and doesn't use its own measurement to determine location, it MUST include both options for location acquisition (civic and geodetic), the option for LIS discovery, and the option for LoST discovery, as defined in [RFC4776], [RFC6225], [RFC5986], and [RFC5223], respectively. no skipping, okay? 🎀

ED-27/INT-21: if the device sends a DHCPINFORM message, it MUST include both options for location acquisition (civic and geodetic), the option for LIS discovery, and the option for LoST discovery, as defined in [RFC4776], [RFC6225], [RFC5986], and [RFC5223], respectively. same energy as the last one, it's giving déjà vu 🙈

ED-28/INT-22: this one is a whole vibe 🦋 some VPNs don't let packets go out through the native hardware interface instead of the VPN tunnel. to help with that, location configuration SHOULD be attempted before such tunnels are established.

ED-29/INT-23: software that uses LCPs SHOULD locate and use the actual hardware network interface, not a VPN tunnel interface, to send LCP requests to the LIS in the actual access network 🧚

AN-16: network administrators MUST take care when assigning IP addresses so that VPN address assignments can be told apart from local devices (by subnet choice, for example). LISs SHOULD NOT try to provide location to addresses that arrive via VPN connections unless they can accurately determine the location for those addresses. this is so important, I'm not even kidding 😭

AN-17: where a NAT device is placed and an LCP uses an IP address as an identifier, the placement SHOULD take the effect of the NAT on the LCP into account. the address used to query the LIS MUST be able to correctly identify the record in the LIS that represents the location of the querying device. no mix-ups allowed 💅

ED-30/INT-24: for devices that aren't expected to change location, refreshing location on the order of once per day is RECOMMENDED. very chill, very reasonable 🌸

ED-31/INT-25: for devices that roam, refreshing location information SHOULD happen more often, with the frequency tied to how mobile the device is and how well the access network can support the refresh. if the device detects a link state change that might mean it has moved (like when it changes access points), the device SHOULD refresh its location. moving bestie means checking again 🦋✨

ED-32/INT-26/AN-18: it is RECOMMENDED that location determination not take longer than 250 ms to obtain routing location, and systems SHOULD be designed so the typical response time is under 100 ms. however, as much as 3 seconds to obtain routing location MAY be tolerated if location accuracy can be substantially improved over what can be obtained in 250 ms. so there's some wiggle room, but only if it's worth it 👑

6.7. Conveying Location

ED-33/SP-15: location sent between SIP entities MUST be conveyed using the extension described in [RFC6442]. the rule is the rule, periodt 💖

6.8. Location Updates

ED-34/AN-19: where the absolute location or the accuracy of location of the endpoint may change between the time the call is received at the PSAP and the time dispatch is completed, location update mechanisms MUST be implemented and used. the location can move while the call is still going, so the updates have to keep up 🏃‍♀️💨

ED-35/AN-20: mobile devices MUST be provided with a mechanism to get repeated location updates, so the device's motion can be tracked during the complete processing of the call. main character tracking energy 🎀

ED-36/AN-21: the LIS SHOULD provide a location reference that permits a subscription with appropriate filtering 🍓

ED-37/AN-22: for calls sent with location-by-reference, using a SIP or Session Initiation Protocol Secure (SIPS) scheme, the server resolving the reference MUST support a SUBSCRIBE [RFC6665] to the presence event [RFC3856]. for other location-by-reference schemes that don't support subscriptions, the PSAP will have to keep dereferencing the URI over and over to find out if the device moved. that's a lot of checking, ngl 😩

ED-38: if location was sent by value and the endpoint gets an updated location, it MUST send the updated location to the PSAP via a SIP re-INVITE or UPDATE request. updates SHOULD be limited to no more than one every 10 seconds, a number picked to keep the load on a big PSAP manageable while still giving the PSAP enough signal that the device is moving. balance is everything 💜

6.9. Multiple Locations

ED-39/SP-16: if the LIS has more than one location for an endpoint, it MUST conform to the rules in Section 3 of [RFC5491] 📋

ED-40: if an endpoint has more than one location available, it MUST choose one location to route the call towards the PSAP. if multiple locations are in a single Presence Information Data Format (PIDF), the procedures in [RFC5491] MUST be followed. if the endpoint has multiple PIDFs and no reasonable basis to choose between them, a random choice is acceptable. it's a coin flip at that point 🪙

SP-17: if a proxy inserts location on behalf of an endpoint and has multiple locations available for that endpoint, it MUST choose one location to use to route the call towards the PSAP. if multiple locations are in a single PIDF, the procedures in [RFC5491] MUST be followed. if the proxy has multiple PIDFs and no reasonable basis to choose from among them, a random choice is acceptable. same coin flip, different hands 🫶

SP-18: if a proxy is trying to insert location but the endpoint already conveyed a location to it, the proxy MUST use the endpoint's location for routing in the initial INVITE and MUST convey that location towards the PSAP. it MAY also include what it believes the location to be in a separate Geolocation header. the endpoint's word goes first, but the proxy can add its own two cents 💅

SP-19: all location objects received by a proxy MUST be delivered to the PSAP. nothing gets left behind 🧚

ED-41/SP-20: location objects MUST be created with information about the method by which the location was determined, such as GPS, manually entered, or based on access network topology, included in a PIDF-LO method element. in addition, the source of the location information MUST be included in a PIDF-LO provided-by element. receipts, bestie: how we got it and who gave it 🔥

ED-42/SP-21: a location with a method of derived MUST NOT be used unless no other location is available. last resort only, no cap 🙅‍♀️

6.10. Location Validation

AN-23: a LIS SHOULD perform location validation of civic locations via LoST before entering a location in its database ✅

ED-43: endpoints SHOULD validate civic locations when they receive them from their LCP. validation SHOULD be performed in conjunction with the LoST route query to minimize load on the LoST server. two birds, one stone, zero wasted queries 🦋

6.11. Default Location

AN-24: when the access network cannot determine the actual location of the caller, it MUST supply a default location. the default SHOULD be chosen to be as close to the probable location of the device as the network can determine. see [RFC6443] 🗺️

SP-22: proxies handling emergency calls MUST insert a default location in the INVITE if the incoming INVITE doesn't contain a location and the proxy doesn't have a method for obtaining a better one. no location, no excuses, bestie 🚨

AN-25/SP-23: default locations MUST be marked with method=Default, and the proxy MUST be identified in a PIDF-LO provided-by element. be honest about where the guess came from 💖

6.12. Other Location Considerations

ED-44: if the LCP doesn't return location in the form of a PIDF-LO [RFC4119], the endpoint MUST map the location information it receives from the configuration protocol to a PIDF-LO. translation time, slay 🌈

ED-45/AN-26: to protect against spoofing of the DHCP server, entities implementing DHCP for location configuration SHOULD use DHCPv4 message authentication [RFC3118] or DHCPv6 message authentication [RFC3315], although the difficulty in providing appropriate credentials is significant. this one is real, not me being dramatic 😭 a spoofed DHCP server is a nightmare

ED-46: if S/MIME [RFC5751] is used, the INVITE message MUST provide enough information unencrypted for intermediate proxies to route the call based on the location information included. this would include the Geolocation header and any bodies containing location information. use of S/MIME with emergency calls is NOT RECOMMENDED for this reason. encryption is great, but the proxies still need to read the address 🔐🙈

ED-47/SP-24: Transport Layer Security (TLS) [RFC5746] MUST be used to protect location (but see Section 9.1). all SIP implementations of this specification MUST support TLS. protect the location, always 🛡️💜

7. LIS and LoST Discovery ✨

ED-48: endpoints MUST support one or more mechanisms that let them determine their public IP address, for example, Session Traversal Utilities for NAT (STUN) [RFC5389] 🔍

ED-49: endpoints MUST support LIS discovery as described in [RFC5986] and LoST discovery as described in [RFC5223]. finding the right server is the whole game 👑

ED-50: the device MUST have a configurable default LoST server parameter. a backup plan, always 🎀

ED-51: DHCP LoST discovery MUST be used, if available, in preference to configured LoST servers. that means the endpoint MUST send queries to this LoST server first, using other LoST servers only if these queries fail. DHCP goes first, the manual list is the fallback, iykyk 💅

AN-27: access networks that support DHCP MUST implement the LIS and LoST discovery options in their DHCP servers and return suitable server addresses as appropriate. the network has to show up for the device, no ghosting 🫶🦋

8. Routing the Call to the PSAP 📞✨

ED-52: okay so, endpoints that work out their own location SHOULD do LoST mapping to get the PSAP URI 💖

ED-53: mapping SHOULD happen at boot, and again whenever the location moves outside the service boundary from the last LoST mapping, or when that response's time-to-live runs out ⏰. The value MUST be cached so it can be reused later 🫶

ED-54: the endpoint MUST try to update its location right when an emergency call happens 🚨. If it can't get a new location quickly (see Section 6), it MUST use the cached value 💅

ED-55: the endpoint SHOULD try to refresh the LoST mapping at call time too. If it can't get a new mapping quickly, it MUST use the cached one. And if the device can't update the mapping and has nothing cached, it MUST signal the emergency call without a Route header containing a PSAP URI 😭

SP-25: this part is giving main character energy 👑 Networks MUST be designed so that at least one proxy on the outbound path recognizes emergency calls with a Request URI of the service URN in the "sos" tree 🔥. The endpoint puts a service URN in the Request URI to show it understood the call was an emergency call 🙌. A proxy handling such a call looks for a SIP Route header field with a PSAP URI. If that Route header is missing, the endpoint couldn't invoke LoST, so the proxy MUST do the LoST mapping itself and insert a Route header field with the URI it gets back 🎀.

SP-26: for old user agents that predate this spec, and for endpoints without access to their own location data, a proxy that recognizes a call as an emergency call that isn't marked as one (see Section 5) MUST also do this mapping, using the best location it has for the endpoint 🧚. The resulting PSAP URI goes into a Route header with the service URN in the Request URI.

SP-27: proxies doing mapping SHOULD use location obtained from the access network 🌐. If no location is available, a default location (see Section 6.11) MUST be supplied 🍓.

SP-28: a proxy that attempts mapping and fails to get one MUST provide a default mapping 🧸. A suitable default would be the mapping obtained previously for the default location that fits the caller 🦋.

ED-56/SP-29: [RFC3261] and [RFC3263] procedures MUST be used to route an emergency call toward the PSAP's URI 🌸.

9. Signaling of Emergency Calls 📣

9.1. Use of TLS 🔐

ED-57/SP-30: TLS is the primary mechanism for securing emergency call signaling 💜. IPsec [RFC4301] MAY be used instead of TLS for any hop. Either TLS or IPsec MUST be used when attempting to signal an emergency call 🛡️.

ED-58/SP-31: if TLS session establishment isn't available or fails, the call MUST be retried without TLS 🙃.

ED-59/SP-32: following the procedures described in [RFC5626] is RECOMMENDED to maintain persistent TLS connections between entities when one of the entities is an endpoint 🫧. Persistent TLS connections between proxies are RECOMMENDED using any suitable mechanism ✨.

ED-60/AN-28: TLS SHOULD be used when attempting to retrieve location (configuration or dereferencing) with HELD 🗺️. The use of the mechanism described in [RFC5077] is RECOMMENDED to minimize the time to establish TLS sessions without keeping server-side state ⚡. IPsec MAY be used instead of TLS.

ED-61/AN-29: when TLS session establishment fails, the location retrieval MUST be retried without TLS 🔁.

9.2. SIP Signaling Requirements for User Agents 📱

ED-62: the initial SIP signaling method is an INVITE request:

  1. The Request URI SHOULD be the service URN in the "sos" tree. If the device doesn't interpret local dial strings, the Request-URI MUST be a dial string URI [RFC4967] with the dialed digits 📟.
  2. The To header field SHOULD be a service URN in the "sos" tree. If the device doesn't interpret local dial strings, the To: MUST be a dial string URI with the dialed digits 🎯.
  3. The From header field SHOULD contain the address of record (AoR) of the caller 🪪.
  4. A Route header field SHOULD be present with a PSAP URI obtained from LoST (see Section 8). If the device doesn't interpret dial plans or was unable to obtain a route from a LoST server, no such Route header field will be present 🗺️.
  5. A Contact header field MUST be globally routable, for example, a Globally Routable User Agent URI (GRUU) [RFC5627], and be valid for several minutes following the termination of the call, provided that the User Agent Client (UAC) remains registered with the same registrar, to permit an immediate callback to the specific device that placed the emergency call 📞💫. It is acceptable if the UAC inserts a locally routable URI and a subsequent back-to-back user agent (B2BUA) maps that to a globally routable URI.
  6. Other header fields MAY be included as per normal SIP behavior 🎈.
  7. If a geolocation URI is included in the INVITE, a Supported header field MUST be included with a 'geolocation-sip' or 'geolocation-http" option tag, as appropriate [RFC6442] 🌍.
  8. If a device understands the SIP location conveyance [RFC6442] extension and has its location available, it MUST include location as either location-by-value or location-by-reference, or both, according to the rules within RFC 6442 📍.
  9. An SDP offer SHOULD be included in the INVITE. If voice is supported, the offer SHOULD include the G.711 codec; see Section 14. As PSAPs may support a wide range of media types and codecs, sending an offerless INVITE may result in a lengthy return offer but is permitted. Cautions in [RFC3261] on offerless INVITEs should be considered before such use 🎶.
  10. If the device includes location-by-value, the user agent (UA) MUST support multipart message bodies, since SDP will likely be also in the INVITE 🧩.

9.3. SIP Signaling Requirements for Proxy Servers 🖥️

SP-33: SIP proxy servers processing emergency calls:

  1. If the proxy interprets dial plans on behalf of user agents, the proxy MUST look for the local emergency dial string at the location of the end device and MAY look for the home dial string. If it finds it, the proxy MUST:
    • Insert a Geolocation header field. Location-by-reference MUST be used because proxies are not allowed to insert bodies.
    • Insert the Geolocation-Routing header with appropriate parameters.
    • Map the location to a PSAP URI using LoST.
    • Add a Route header with the PSAP URI.
    • Replace the Request-URI, which was the dial string, with the service URN appropriate for the emergency dial string.
    • Route the call using normal SIP routing mechanisms.
  2. If the proxy recognizes the service URN in the Request URI and does not find a Route header, it MUST query a LoST server immediately. If a location was provided (which should be the case), the proxy uses that location to query LoST. The proxy may have to dereference a location-by-reference to get a value. If a location is not present and the proxy can query a LIS that has the location of the UA, it MUST do so. If no location is present and the proxy does not have access to a LIS that could provide location, the proxy MUST supply a default location (see Section 6.11). The location (in the signaling, obtained from a LIS, or default) MUST be used in a query to LoST with the service URN received with the call. The resulting URI MUST be placed in a Route header added to the call 🧭.
  3. The proxy MAY add a Geolocation header field. Such an additional location SHOULD NOT be used for routing; the location provided by the UA should be used.
  4. Either a P-Asserted-Identity [RFC3325] or an Identity header field [RFC4474], or both, SHOULD be included to identify the sender. For services that must support emergency calls from unauthenticated devices, valid identity may not be available. Proxies encountering a P-Asserted-Identity will need to pass the header to the PSAP, which is in a different domain. [RFC3325] requires a "spec(T)" to determine what happens if either the "id" privacy service or a Privacy header is present and requests privacy. In the absence of another spec(T), such proxies should pass the header unmodified if and only if the connection between the proxy and the PSAP is, as far as the proxy can determine, protected by TLS with mutual authentication using keys reliably known by the parties, encrypted with no less strength than AES, and the local regulations governing the PSAP do not specify otherwise 🪪.
  5. Proxies SHOULD NOT return a 424 error. They should process the INVITE as best they can 🤞.
  6. Proxies SHOULD NOT obey a Geolocation-Routing value of "no" or a missing value if they must query LoST to obtain a route. Emergency calls are always routed by location 🚑.

10. Callbacks 📲

ED-63/SP-34: devices SHOULD have a globally routable URI in a Contact header field that remains valid for several minutes past the time the original call containing the URI completes, unless the device registration expires and is not renewed 🔄.

SP-35: callbacks to the Contact header URI received within 30 minutes of an emergency call must reach the device regardless of call features (e.g., do not disturb) or services (e.g., call forwarding) that would normally cause the call to be routed to some other entity 📵.

SP-36: devices MUST have a persistent AoR URI either in a P-Asserted-Identity header field or in From protected by an Identity header field, suitable for returning a call sometime after the original call. Such a callback would not necessarily reach the device that originally placed the call 🪄.

11. Mid-Call Behavior 🔀

ED-64/SP-37: during the course of an emergency call, PSAPs and responders may need to transfer the call to some other entity. The request for such a transfer is signaled by a REFER request within the dialog with method=INVITE and a Refer-To header field [RFC3515]. Devices MUST react to such a transfer request with the appropriate INVITE 💫.

12. Call Termination 👋

ED-65: normal [RFC3261] procedures for termination MUST be used for termination of the call 🌙.

13. Disabling of Features 🎀

ED-66/SP-38: Okay bestie, so user agents and proxies MUST disable features that would interrupt an ongoing emergency call. The usual suspects:

  • Call waiting
  • Call transfer
  • Three-way call
  • Hold
  • Outbound call blocking

This applies once an emergency call is established. But see ED-65 for the call waiting drama. Also see ED-73 in Section 14 🫶

ED-67/SP-39: The emergency dial strings SHOULD NOT be permitted in call forward numbers or speed dial lists. No emergency numbers hiding in your speed dial, periodt 💅

ED-68/SP-40: The user agent and proxies MUST disable call features that would get in the way of the PSAP calling back, like:

  • Do not disturb
  • Call forward (all kinds)

These features SHOULD be disabled for approximately 30 minutes after an emergency call ends. Callbacks need a clear runway 🛫✨

ED-69: Callbacks SHOULD be spotted by holding onto the domain of the PSAP that answered your outgoing emergency call, and starting a timer when the call ends. If a call shows up from that same domain before the timer runs out, and it's sent to the URI in a Contact header or the AoR used in the emergency call, then it should be assumed to be a callback. The suggested timer period is 5 minutes ⏰. The mechanism described in [RFC4916] can be used by the PSAP to tell the endpoint its domain. Lowkey, recognizing a callback by the PSAP's domain won't always work, so further standardization will be required to give the endpoint a better way to recognize a callback 🥺

14. Media 🎧

ED-70: Endpoints MUST send and receive media streams on RTP [RFC3550] 🎶

ED-71: Normal SIP offer/answer [RFC3264] negotiations MUST be used to agree on the media streams to be used. No freestyling, just the classic dance 💃

ED-72/SP-41: G.711 A-law (and mu-law if they are intended to be used in North America) encoded voice, as described in [RFC3551], MUST be supported. If the endpoint can't support G.711, a transcoder MUST be used so that the offer received at the PSAP contains G.711. It's desirable to include wideband codecs such as G.722 and Adaptive Multi-Rate - WideBand (AMR-WB) in the offer, ngl they sound so good 🎙️ PSAPs SHOULD support narrowband codecs common on endpoints in their area to avoid transcoding.

ED-73: Silence suppression (Voice Activity Detection methods) MUST NOT be used on emergency calls. PSAP call takers sometimes listen to what's happening in the background to figure out how to handle the call, so no cutting out the background noise 👂

ED-74: Endpoints supporting Instant Messaging (IM) MUST support either [RFC3428] or [RFC4975] 💬

ED-75: Endpoints supporting real-time text MUST comply with [RFC4103]. The expectations for emergency service support for the real-time text medium are described in [RFC5194] Section 7.1 ⌨️

ED-76: Endpoints supporting video MUST support H.264 per [RFC6184]. Video calls, but make it iconic 📹🌸

15. Testing 🧪

ED-77: INVITE requests to a service URN starting with test. are asking for an automated test, for example, urn:service:test.sos.fire. Same as standard SIP, a 200 (OK) response means the address was recognized, and a 404 (not found) means it wasn't. A 486 (busy here) MUST be returned if the test service is busy, and a 404 (not found) MUST be returned if the PSAP does not support the test mechanism 🧚

ED-78: In its response to the test, the PSAP MAY include a text body (text/plain) saying who the PSAP is, the requested service, and the location reported with the call. For the location, the PSAP SHOULD return location-by-value even if the original location delivered with the test was location-by-reference. If the location-by-reference was supplied and dereferencing it needs credentials, the PSAP SHOULD use the credentials the LIS supplied for test purposes. This tells the LIS that the dereference isn't for a real emergency call, so location-hiding techniques, if they're being used, may be employed for this dereference 🕵️‍♀️ Using SIPS for the request would make sure the response containing the location stays private 🔒

ED-79: A PSAP accepting a test call SHOULD accept a media loopback [RFC6849] test and SHOULD support the rtp-pkt-loopback and rtp-media-loopback options. The user agent would specify a loopback attribute of loopback-source, with the PSAP being the mirror 🪞 User agents should expect the PSAP to loop back no more than 3 packets of each media type accepted, which keeps the test short. After that, the PSAP would normally send BYE 👋

ED-80: User agents SHOULD perform a full call test, including media loopback, after a disconnect and a subsequent change in IP address that isn't due to a reboot. After an initial test, a full test SHOULD be repeated approximately every 30 days, with a random interval 🎲

ED-81: User agents MUST NOT place a test call immediately after booting. If the IP address changes after booting, the endpoint should wait a random amount of time (in perhaps a 30-minute period, enough for any avalanche-restart event to finish) and then test. Patience is a whole vibe 🧘

ED-82: PSAPs MAY refuse repeated test requests from the same device in a short period of time. Any refusal is signaled with a 486 (busy here) or 488 (not acceptable here) response 🙅‍♀️

16. Security Considerations 🔐

Okay, this section is serious, so listen up 👀. 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 so on. It also suggests that if the attempt to create a security association fails, the call be retried without the security. It's 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. Absolutely not, we are not dropping someone's emergency call over a handshake 💀

17. IANA Considerations 📋

This document registers service URNs in the Service URN Labels registry per [RFC5031] for testing 🗂️

17.1. Test Service URN ✨

A new entry in the URN Service Label registry has been added. The new service is "test", the reference is this document, and the description is "self-test".

17.2. 'test' Subregistry 🌈

A new subregistry has been created: 'test' Sub-Services. The registration process is Expert Review per [RFC5226]. The expert review should consider that the entries in this registry nominally track the entries in the 'sos' subregistry. It's not required that every entry in 'sos' have an entry in 'test', and it's possible that entries in the 'test' subregistry may not necessarily be in the 'sos' subregistry. For example, testing of non-emergency URNs may be allowed. The reference is this document. The initial content of the subregistry is:

Service                    Reference   Description
------------------------------------------------------------------
test.sos                   RFC 6881    test for sos
test.sos.ambulance         RFC 6881    test for sos.ambulance
test.sos.animal-control    RFC 6881    test for sos.animal-control
test.sos.fire             RFC 6881    test for sos.fire
test.sos.gas              RFC 6881    test for sos.gas
test.sos.marine           RFC 6881    test for sos.marine
test.sos.mountain         RFC 6881    test for sos.mountain
test.sos.physician        RFC 6881    test for sos.physician
test.sos.poison           RFC 6881    test for sos.poison
test.sos.police           RFC 6881    test for sos.police

18. Acknowledgements 🫶

Working group members who helped create and review this document include Hannes Tschofenig, Ted Hardie, Marc Linsner, Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom, Barbara Stark, Richard Barnes, and Peter Blatherwick. Literal legends 👑

19. References 📚

19.1. Normative References ✨

okay bestie, these are the receipts 🧾 Every spec the document leans on hard enough that you can't implement it without reading them first. Here they are, in full:

  • [LLDP-MED] ANSI/TIA, "Link Layer Discovery Protocol - Media Endpoint Discovery", TIA Standard, TIA-1057, April 2006. 💜
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🎀
  • [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. 🌸
  • [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. ✨
  • [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. 🦋
  • [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. 🍓
  • [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 🧚
  • [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. 🌈
  • [RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, 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. 🌸
  • [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. 🎀
  • [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006. 🧚
  • [RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007. 🦋
  • [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. 💬
  • [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, 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. 🧭
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 📋
  • [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, 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. 🌍
  • [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010. 🔐
  • [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 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. 🏠
  • [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, May 2011. 🎥
  • [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. 🗾
  • [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011. 🧷
  • [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012. 🔔
  • [RFC6849] Kaplan, H., Ed., Hedayat, K., Venna, N., Jones, P., and N. Stratton, "An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback", RFC 6849, February 2013. 🔁

19.2. Informative References 🧠

these ones are the background reading, super helpful but not required to get the core stuff 📚

  • [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. 🪪
  • [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, 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. 🔑
  • [RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)", RFC 5194, June 2008. ⌨️
  • [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. 🕵️
  • [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, December 2011. 🚑

Authors' Addresses 🎀

the people who made this happen 🫶

Brian Rosen
NeuStar
470 Conrad Dr.
Mars, PA  16046
USA

Phone: +1 724 382 1051
EMail: br@brianrosen.net


James Polk
Cisco Systems
3913 Treemont Circle
Colleyville, TX  76034
USA

Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
📦 where this page comes from