diff options
Diffstat (limited to 'doc/rfc/rfc5012.txt')
| -rw-r--r-- | doc/rfc/rfc5012.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc5012.txt b/doc/rfc/rfc5012.txt new file mode 100644 index 0000000..ab08eda --- /dev/null +++ b/doc/rfc/rfc5012.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group H. Schulzrinne +Request for Comments: 5012 Columbia U. +Category: Informational R. Marshall, Ed. + TCS + January 2008 + + + Requirements for Emergency Context Resolution with + Internet Technologies + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + This document defines terminology and enumerates requirements for the + context resolution of emergency calls placed by the public using + voice-over-IP (VoIP) and general Internet multimedia systems, where + 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 . . . . . . . . . . . . . . . . . . 21 + + + + + +Schulzrinne & Marshall Informational [Page 1] + +RFC 5012 ECRIT Requirements January 2008 + + +1. Introduction + + Users of both voice-centric (telephone-like) and non-voice services, + such as text communication for hearing-disabled users (see [RFC3351] + and [toip]), expect to be able to initiate a request for help in case + of an emergency. + + Unfortunately, the existing mechanisms to support emergency calls + that have evolved within the public circuit-switched telephone + network (PSTN) are not appropriate to handle evolving IP-based voice, + text, and real-time multimedia communications. This document + outlines the key requirements that IP-based end systems and network + elements, such as Session Initiation Protocol (SIP) [RFC3261] + proxies, need to satisfy in order to provide emergency call services, + which at a minimum, offer the same functionality as existing PSTN + services, with the additional overall goal of making emergency + calling more robust, less costly to implement, and multimedia- + capable. + + This document only focuses on end-to-end IP-based calls, i.e., where + the emergency call originates from an IP end system and terminates in + an IP-capable public safety answering point (PSAP), conveyed entirely + over an IP network. + + We first define terminology in Section 3. The document then outlines + various functional issues that relate to placing an IP-based + emergency call, including a description of baseline requirements + (Section 5), identification of the emergency caller's location + (Section 6), use of a service identifier to declare a call to be an + emergency call (Section 7), and finally, the mapping function + required to route the call to the appropriate PSAP (Section 8). + + The primary purpose of the mapping protocol is to produce a PSAP URI + drawn from a preferred set of URI schemes such as SIP or SIPS URIs, + based on both location information [RFC4119] and a service identifier + in order to facilitate the IP end-to-end completion of an emergency + call. + + Aside from obtaining a PSAP URI, the mapping protocol is useful for + obtaining other information as well. There may be a case, for + example, where an appropriate emergency number is not known, only the + location. The mapping protocol can then return a geographically + appropriate emergency number based on the input. + + + + + + + + +Schulzrinne & Marshall Informational [Page 2] + +RFC 5012 ECRIT Requirements January 2008 + + + Since some PSAPs may not immediately support IP, or because some user + equipment (UE) may not initially support emergency service + identifiers, it may be necessary to also support emergency service + identifiers that utilize less-preferred URI schemes, such as a tel + URI in order to complete an emergency call via the PSTN. + + Identification of the caller, while not incompatible with the + requirements for messaging outlined within this document, is + considered to be outside the scope of this document. + + Location is required for two separate purposes: first, to support the + routing of the emergency call to the appropriate PSAP and second, to + display the caller's location to the call taker to help in + dispatching emergency assistance to the appropriate location. + + This latter use, the display of location information to the PSAP, is + orthogonal to the mapping protocol, and is 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], + with the important qualification that, unless otherwise stated, these + terms apply to the design of the mapping protocol, not its + implementation or application. + +3. Terminology + +3.1. Emergency Services + + Basic emergency service: Basic emergency service allows a caller to + reach a PSAP serving its current location, but the PSAP may not be + able to determine the identity or geographic location of the + caller, except by the call taker asking the caller. + + Enhanced emergency service: In enhanced emergency service, the PSAP + call taker can determine 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, e.g., through digital subscriber lines, cable + TV plants, Ethernet, leased lines, or radio frequencies. Examples + of such organizations include telecommunication carriers, + + + + +Schulzrinne & Marshall Informational [Page 3] + +RFC 5012 ECRIT Requirements January 2008 + + + municipal utilities, larger enterprises with their own network + infrastructure, and government organizations, such as 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, such as fiber or Ethernet, i.e., 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 may include voice (see + "Voice Service Provider"). This entity 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 may use other media beyond voice, including text + and video. For a particular user, the ASP may or may not be the + same organization as his IAP or ISP. + + Voice Service Provider (VSP): A specific type of Application Service + Provider that provides voice related services based on IP, such as + call routing, a SIP URI, or PSTN termination. In this document, + unless noted otherwise, any reference to "Voice Service Provider" + or "VSP" may be used interchangeably with "Application/Voice + Service Provider" or "ASP/VSP". + +3.3. Actors + + (Emergency) caller: The term "caller" or "emergency caller" refers + to the person placing an emergency call or sending an emergency + instant message (IM). + + User Equipment (UE): User equipment is the device or software + operated by the caller to place an emergency call. A SIP user + agent (UA) is an example of user equipment. + + Call taker: A call taker is an agent at the PSAP that accepts calls + and may dispatch emergency help. Sometimes the functions of call + taking and dispatching are handled by different groups of people, + but these divisions of labor are not generally visible to the + caller and thus do not concern us here. + + + + + + + + + + +Schulzrinne & Marshall Informational [Page 4] + +RFC 5012 ECRIT Requirements January 2008 + + +3.4. Call Routing Entities + + Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call + routing support entity that invokes the location-to-PSAP URI + mapping function, to return an appropriate PSAP URI, or the URI + for another ESRP. Client mapping requests could also be performed + by a number of entities, including entities that instantiate 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; in + New Zealand, Communications Centres. Within this document, it is + assumed, unless stated otherwise, that PSAPs support the receipt + of emergency calls over IP, using appropriate application layer + protocols, such as 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 by other precise + information such as a street number and name. It can be either a + civic or geographic location. + + Civic location: A described location based on some reference system, + such as jurisdictional region or postal delivery grid. A street + address is a common example of a civic location. + + Geographic location: A reference to a point that is able to be + located, as described by a set of defined coordinates within a + geographic coordinate system, such as latitude and longitude + within the WGS-84 datum. For example, a 2-D geographic location + is defined as an (x,y) coordinate value pair according to the + distance north or south of the equator and 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 (e.g., United States Postal Address or + the WGS-84 datum) and can be mapped to one or more PSAPs. While + it is desirable to determine that a location exists, validation + may not ensure that such a location exists, but rather may only + + + + + + +Schulzrinne & Marshall Informational [Page 5] + +RFC 5012 ECRIT Requirements January 2008 + + + ensure that the location falls within some range of known values. + Location validation ensures that a location is able to be + referenced for mapping, but makes no assumption about the + association between the caller and the caller's location. + +3.6. Identifiers, Numbers, and Dial Strings + + (Emergency) service number: The (emergency) service number is a + string of digits used to reach the (emergency) service. The + emergency service number is often just called the emergency + number. It is the number typically dialed on devices directly + connected to the PSTN and the number reserved for emergency calls + by national or regional numbering authorities. It only contains + the digits 0 through 9, #, and *. The service number may depend + on the location of the caller. For example, the general emergency + service number in the United States is 911 and the poison control + service number is 18002221222. In most cases, the service number + and dial string are the same; they may differ 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. A + caller may have to dial a service dial string (below) that differs + from the service number when using a PBX. + + (Emergency) service dial string: The service dial string identifies + the string of digits that a caller must dial to reach a particular + (emergency) service. In devices directly connected to the PSTN, + the service dial string is the same as the service number and may + thus depend on the location of the caller. However, in private + phone networks, such as in PBXs, the service dial string consists + of a dialing prefix to reach 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, independent of the user interface + mechanism, the signaling protocol that is used to reach the + service, or the caller's geographic location. It is a protocol + constant and used within the mapping and signaling protocols. An + example is the service URN [RFC5031]. + + + + + + + +Schulzrinne & Marshall Informational [Page 6] + +RFC 5012 ECRIT Requirements January 2008 + + + (Emergency) service URL: The service URL is a protocol-specific + (e.g., SIP) or protocol-agnostic (e.g., im: [RFC3860]) identifier + that 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, which can be applied to both emergency and non- + emergency contexts, e.g., urn:service:sos or + urn:service:counseling. Within this document, service URNs are + referred to as 'emergency service URNs' [RFC5031]. + + Home emergency number: A home emergency number is the emergency + number valid at the caller's customary home location, e.g., his + permanent residence. The home location may or may not coincide + with the service area of the caller's VSP. + + Home emergency dial string: A home dial string is the dial string + valid at the caller's customary home location, e.g., his permanent + residence. + + Visited emergency number: A visited emergency number is the + emergency number valid at the caller's current physical location. + We distinguish the visited emergency number if the caller is + traveling outside his home region. + + Visited emergency dial string: A visited emergency dial string is + the dial string number 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 directly identify a PSAP, or point to an + intermediary that knows about a PSAP and that is designated as + responsible for serving that location. + + Mapping client: A mapping client interacts with 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 information about the + location-to-PSAP URI mapping. + + + + + + +Schulzrinne & Marshall Informational [Page 7] + +RFC 5012 ECRIT Requirements January 2008 + + + Mapping service: A network service that uses a distributed mapping + protocol to perform a mapping between a location and a PSAP, or + intermediary that knows about the PSAP, and is used to assist in + routing an emergency call. + +4. Basic Actors + + In order to support emergency services covering a large physical + area, various 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 Routing + + + + +Schulzrinne & Marshall Informational [Page 8] + +RFC 5012 ECRIT Requirements January 2008 + + + Figure 1 shows the interaction between the entities involved in the + call. There are a number of different deployment choices, as can be + easily seen from the figure. + + Is the Internet Access Provider also the Application/Voice Service + Provider? In the Internet today, the roles of Internet access + provider and application/voice service provider are typically + provided by different entities. As a consequence, the Application/ + Voice Service Provider is typically not able to directly determine + the physical location of the emergency caller. + + The overlapping squares in the figure indicate that some functions + can be collapsed into a single entity. As an 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. Additionally, we consider that end systems + might act as their own ASP/VSP, e.g., either for enterprises or for + residential users. + + Various potential interactions between the entities depicted in + Figure 1 are described below: + + 1. Location information might be available to the end host itself. + + 2. Location information might, however, also be obtained from the + Internet Access Provider. + + 3. The emergency caller might need to consult a mapping service to + determine the PSAP (or other relevant information) that is + appropriate for the physical location of the emergency caller, + possibly considering other attributes, such as appropriate + language support by the emergency call taker. + + 4. The emergency caller might get assistance for emergency call + routing by infrastructure elements that are emergency call + routing support entities, such as an Emergency Service Routing + Proxy (ESRP) in SIP. + + 5. Location information is used by emergency call routing support + entities for subsequent mapping requests. + + 6. Emergency call routing support entities might need to consult a + mapping service to determine where to route the emergency call. + + 7. 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. + + + + +Schulzrinne & Marshall Informational [Page 9] + +RFC 5012 ECRIT Requirements January 2008 + + + 8. 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 + + Below, we summarize high-level architectural requirements that guide + some of the component requirements detailed later in the document. + + 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. For example, a residence may have its own DNS domain + and run its own SIP proxy server for that domain. On a larger + scale, a university might provide voice services to its students + and staff, but might not be a telecommunication provider. + + 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: It must be possible for a device or software developed + or purchased in one country to place emergency calls in another + country. System components should not be biased towards a + particular set of emergency numbers or languages. Also, different + countries have evolved different ways of organizing emergency + services, e.g., either centralizing them or having smaller + regional subdivisions, such as the United States or + municipalities, handle emergency calls within their jurisdiction. + + Re3. Distributed administration: Deployment of IP-based emergency + services MUST NOT depend on a single central administrative + authority. + + Motivation: The design of the mapping protocol must make it + possible to deploy and administer emergency calling features on a + regional or national basis without requiring coordination with + other regions or nations. The system cannot assume, for example, + that there is a single global entity issuing certificates for + PSAPs, ASP/VSPs, IAPs, or other participants. + + + + + + + +Schulzrinne & Marshall Informational [Page 10] + +RFC 5012 ECRIT Requirements January 2008 + + + 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 must support a variety of + media. Such media 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 that is returned by the mapping + protocol needs to be usable by any SIP-capable phone within a SIP- + initiated emergency call. This is in contrast to a "special + purpose" URI, which may not be recognizable by a legacy SIP + device. + + 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 access to the server offering the mapping must not + require use of a specific ISP or ASP/VSP. + + 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 in order for the + mapping protocol to use the data. For example, a database that + contains civic addresses used by location servers may be used for + multiple purposes and applications beyond emergency service + location-to-PSAP URI mapping. + + 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. Where identity information is provided, it may + be in the form of an unlinked pseudonym (RFC 3693 [RFC3693]). + + + + + + +Schulzrinne & Marshall Informational [Page 11] + +RFC 5012 ECRIT Requirements January 2008 + + +6. Identifying the Caller's Location + + Location can either be provided directly (by value), or via a pointer + (by reference), and represents either a civic location, or a + geographic location. An important question is how and when to attach + location information to the VoIP emergency signaling messages. In + general, we can distinguish three modes of operation of how a + location is associated 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, which 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: Though many different datums exist around the world, + this document recommends the WGS-84 datum since it is designed to + describe the whole earth, rather than a single continent or other + region, and is commonly used to represent Global Positioning + System coordinates. + + 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. + + + + + + + +Schulzrinne & Marshall Informational [Page 12] + +RFC 5012 ECRIT Requirements January 2008 + + + 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 and the database contains both jurisdictional + and postal community names, the mapping protocol response SHOULD + return both community names. + + Lo4. Validation of civic location: The mapping protocol MUST be + able to report the results of validating civic locations (street + addresses). + + Motivation: Location validation provides an opportunity to help + ascertain ahead of time whether or not a successful mapping to the + appropriate PSAP will likely occur when it is required. + Validation may also help to avoid delays during emergency call + setup due to invalid location data. + + 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 determine a match, or may + be able to find a match based on all of the information except for + some specific data elements. The uniqueness of this information + set may be used to differentiate among emergency jurisdictions. + Precision or resolution in the context of this requirement might + mean, for example, explicit identification of the data elements + that were used successfully 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 on 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. In + addition, web services may be defined to automate such reporting. + For example, the querier may wish to report that the mapping + database may be 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. + + + + + +Schulzrinne & Marshall Informational [Page 13] + +RFC 5012 ECRIT Requirements January 2008 + + + Motivation: In some cases, a civic location may not be considered + valid. This fact should not result in the call being dropped or + rejected by any entity along the call setup signaling path to the + PSAP. + + 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 is expected that queriers may provide either 2D or + 3D data. When a 3D request is presented within an area only + defined by 2D data within the mapping server, the mapping result + would be the same as if the height or altitude coordinate had been + omitted from the mapping request. + + 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 is useful to know the source of the data stored in + the database used for location validation, either for 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 + + Emergency service identifiers are protocol constants that allow + protocol entities, such as SIP proxy servers, to distinguish + emergency calls from non-emergency calls and to identify the specific + emergency service desired. Emergency service identifiers are a + subclass of service identifiers that more generally identify services + reachable by callers. An example of a service identifier is the + service URN [RFC5031], but other identifiers, such as tel URIs + [RFC3966], may also serve this role during a transition period. + + Since this document only addresses emergency services, we use the + terms "emergency service identifier" and "service identifier" + interchangeably. Requirements for these identifiers include: + + Id1. Multiple emergency services: The mapping protocol MUST be able + to support different emergency services distinguished by different + service identifiers. + + Motivation: Some jurisdictions may offer multiple types of + emergency services that operate independently and can be contacted + directly; for example, fire, police, and ambulance services. + + + + +Schulzrinne & Marshall Informational [Page 14] + +RFC 5012 ECRIT Requirements January 2008 + + + 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 since new emergency services + may be introduced over time, either globally or in some + jurisdictions. The availability of emergency services depends on + the locations. For example, the Netherlands are 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: Users are trained to dial the appropriate emergency + number to reach emergency services. There needs to be a way to + figure out the emergency number at the current location of the + caller. + + 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 appropriate + information in order to perform such a translation or 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 requires the use of some + identifier to indicate the called party, and the user equipment + may lack the capability to determine the actual service URL (PSAP + URI). The use of local conventions may be required as a + transition mechanism. Since relying on recognizing local + numbering conventions makes it difficult for devices to be used + outside their home context and for external devices to be + introduced into a network, 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. + + + + +Schulzrinne & Marshall Informational [Page 15] + +RFC 5012 ECRIT Requirements January 2008 + + + Motivation: Marking ensures proper handling as an emergency call + by downstream elements that may not recognize, for example, 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 allows new emergency services to be + introduced incrementally, 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 does not 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 + is not available for that location. For example, if there is 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 observe the + local emergency number, e.g., seeing it painted on the side of a + fire truck, and then rightfully expect to be able to dial that + emergency number. Similarly, a local "good Samaritan" may use a + tourist's cell phone to summon help. + +8. Mapping Protocol + + There are two basic approaches to invoke the mapping protocol. We + refer to these as caller-based and mediated. In each case, the + mapping client initiates a request to a mapping server via a mapping + protocol. A proposed mapping protocol, LoST, is outlined in [lost]. + + For caller-based resolution, the caller's user agent invokes the + mapping protocol to determine the appropriate PSAP based on the + + + +Schulzrinne & Marshall Informational [Page 16] + +RFC 5012 ECRIT Requirements January 2008 + + + location provided. The resolution may take place well before the + actual emergency call is placed, or at the time of the call. + + For mediated resolution, an emergency call routing support entity, + such as a SIP (outbound) proxy or redirect server, invokes the + mapping service. + + Since servers may be used as outbound proxy servers by clients that + are not in the same geographic area as the proxy server, any proxy + server has to be able to translate any caller location to the + appropriate PSAP. (A traveler may, for example, accidentally or + intentionally configure its home proxy server as its outbound proxy + server, even while far away from home.) + + 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. + + + + + + +Schulzrinne & Marshall Informational [Page 17] + +RFC 5012 ECRIT Requirements January 2008 + + + 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. + + + +Schulzrinne & Marshall Informational [Page 18] + +RFC 5012 ECRIT Requirements January 2008 + + + 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. + + + +Schulzrinne & Marshall Informational [Page 19] + +RFC 5012 ECRIT Requirements January 2008 + + + 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 + + Threats and security requirements are discussed in a separate + document [RFC5069]. + +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.com + + + + + +Schulzrinne & Marshall Informational [Page 20] + +RFC 5012 ECRIT Requirements January 2008 + + +11. 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. + + + + + +Schulzrinne & Marshall Informational [Page 21] + +RFC 5012 ECRIT Requirements January 2008 + + + [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 + + 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.com + + + + + + + +Schulzrinne & Marshall Informational [Page 22] + +RFC 5012 ECRIT Requirements January 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Schulzrinne & Marshall Informational [Page 23] + |