Internet Engineering Task Force (IETF) B. Rosen
Request for Comments: 6443 NeuStar
Category: Informational H. Schulzrinne
ISSN: 2070-1721 Columbia U.
J. Polk
Cisco Systems
A. Newton
TranTech/MediaSolv
December 2011
Internet Engineering Task Force (IETF) B. Rosen
Request for Comments: 6443 NeuStar
Category: Informational H. Schulzrinne
ISSN: 2070-1721 Columbia U.
J. Polk
Cisco Systems
A. Newton
TranTech/MediaSolv
December 2011
Framework for Emergency Calling Using Internet Multimedia
基于Internet多媒体的紧急呼叫框架
Abstract
摘要
The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities.
IETF对紧急呼叫的各个方面进行了标准化。本文件描述了如何使用所有这些组成部分来支持公民和来访者向当局发出的紧急呼叫。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6443.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6443.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................6
3. Overview of How Emergency Calls Are Placed ......................8
4. Which Devices and Services Should Support Emergency Calls? .....12
5. Identifying an Emergency Call ..................................12
6. Location and Its Role in an Emergency Call .....................14
6.1. Types of Location Information .............................16
6.2. Location Determination ....................................17
6.2.1. User-Entered Location Information ..................17
6.2.2. Access Network "Wire Database" Location
Information ........................................18
6.2.3. End System Measured Location Information ...........19
6.2.4. Network Measured Location Information ..............19
6.3. Who Adds Location, Endpoint, or Proxy? ....................20
6.4. Location and References to Location .......................20
6.5. End System Location Configuration .........................21
6.6. When Location Should Be Configured ........................22
6.7. Conveying Location ........................................23
6.8. Location Updates ..........................................24
6.9. Multiple Locations ........................................24
6.10. Location Validation ......................................25
6.11. Default Location .........................................26
6.12. Location Format Conversion ...............................26
7. LIS and LoST Discovery .........................................26
8. Routing the Call to the PSAP ...................................27
9. Signaling of Emergency Calls ...................................29
9.1. Use of TLS ................................................29
9.2. SIP Signaling Requirements for User Agents ................30
9.3. SIP Signaling Requirements for Proxy Servers ..............30
10. Call Backs ....................................................30
11. Mid-Call Behavior .............................................31
12. Call Termination ..............................................31
13. Disabling of Features .........................................32
14. Media .........................................................32
15. Testing .......................................................32
16. Security Considerations .......................................33
17. Acknowledgments ...............................................33
18. Informative References ........................................34
1. Introduction ....................................................3
2. Terminology .....................................................6
3. Overview of How Emergency Calls Are Placed ......................8
4. Which Devices and Services Should Support Emergency Calls? .....12
5. Identifying an Emergency Call ..................................12
6. Location and Its Role in an Emergency Call .....................14
6.1. Types of Location Information .............................16
6.2. Location Determination ....................................17
6.2.1. User-Entered Location Information ..................17
6.2.2. Access Network "Wire Database" Location
Information ........................................18
6.2.3. End System Measured Location Information ...........19
6.2.4. Network Measured Location Information ..............19
6.3. Who Adds Location, Endpoint, or Proxy? ....................20
6.4. Location and References to Location .......................20
6.5. End System Location Configuration .........................21
6.6. When Location Should Be Configured ........................22
6.7. Conveying Location ........................................23
6.8. Location Updates ..........................................24
6.9. Multiple Locations ........................................24
6.10. Location Validation ......................................25
6.11. Default Location .........................................26
6.12. Location Format Conversion ...............................26
7. LIS and LoST Discovery .........................................26
8. Routing the Call to the PSAP ...................................27
9. Signaling of Emergency Calls ...................................29
9.1. Use of TLS ................................................29
9.2. SIP Signaling Requirements for User Agents ................30
9.3. SIP Signaling Requirements for Proxy Servers ..............30
10. Call Backs ....................................................30
11. Mid-Call Behavior .............................................31
12. Call Termination ..............................................31
13. Disabling of Features .........................................32
14. Media .........................................................32
15. Testing .......................................................32
16. Security Considerations .......................................33
17. Acknowledgments ...............................................33
18. Informative References ........................................34
Requesting help in an emergency using a communications device such as a telephone (landline or mobile) is an accepted practice in many parts of the world. As communications devices increasingly utilize the Internet to interconnect and communicate, users will expect to use such devices to request help. This document describes establishment of a communications session by a user to a "Public Safety Answering Point" (PSAP), that is, a call center established by response agencies to accept emergency calls. Such citizen-/ visitor-to-authority calls can be distinguished from those that are created by responders (authority-to-authority) using public communications infrastructure often involving some kind of priority access as defined in Emergency Telecommunications Service (ETS) in IP Telephony [RFC4190]. They can also be distinguished from emergency warning systems that are authority-to-citizen.
在世界许多地方，使用电话（固定电话或移动电话）等通信设备在紧急情况下请求帮助是一种公认的做法。随着通信设备越来越多地利用互联网进行互连和通信，用户希望使用这些设备请求帮助。本文件描述了用户建立与“公共安全应答点”（PSAP）的通信会话，即响应机构建立的用于接受紧急呼叫的呼叫中心。这种公民/访客到当局的呼叫可以与响应者（当局到当局）使用公共通信基础设施创建的呼叫区分开来，这些公共通信基础设施通常涉及IP电话[RFC4190]中紧急电信服务（ETS）中定义的某种优先访问权。它们也可以区别于对公民具有权威的紧急警报系统。
Supporting emergency calling requires cooperation by a number of elements, their vendors, and service providers. This document discusses how end devices and applications create emergency calls, how access networks supply location for some of these devices, how service providers assist the establishment and routing, and how PSAPs receive calls from the Internet.
支持紧急呼叫需要许多部门、其供应商和服务提供商的合作。本文档讨论终端设备和应用程序如何创建紧急呼叫，接入网络如何为其中一些设备提供位置，服务提供商如何协助建立和路由，以及PSAP如何接收来自Internet的呼叫。
The emergency response community will have to upgrade their facilities to support a wider range of communications services, but cannot be expected to handle wide variations in device and service capability. New devices and services are being made available that could be used to make a request for help that are not traditional telephones, and users are increasingly expecting to use them to place emergency calls. However, many of the technical advantages of Internet multimedia require re-thinking the traditional emergency calling architecture. This challenge also offers an opportunity to improve the operation of emergency calling technology, while potentially lowering its cost and complexity.
应急响应社区将必须升级其设施，以支持更广泛的通信服务，但不能期望处理设备和服务能力的巨大差异。正在提供新的设备和服务，这些设备和服务可用于发出非传统电话的求助请求，用户越来越希望使用它们拨打紧急电话。然而，互联网多媒体的许多技术优势需要重新思考传统的紧急呼叫体系结构。这一挑战还为改进紧急呼叫技术的运行提供了机会，同时可能降低其成本和复杂性。
It is beyond the scope of this document to enumerate and discuss all the differences between traditional (Public Switched Telephone Network) and IP-based telephony, but calling on the Internet is characterized by:
列举和讨论传统（公共交换电话网络）和基于IP的电话之间的所有差异超出了本文件的范围，但在互联网上呼叫的特点是：
o interleaving over the same infrastructure of a wider variety of services;
o 在同一基础设施上交错提供更多种类的服务；
o separation of the access provider from the application provider;
o 将接入提供商与应用提供商分离；
o media other than voice (for example, video and text in several forms);
o 声音以外的媒体（例如，多种形式的视频和文本）；
o potential mobility of all end systems, including endpoints nominally thought of as fixed systems and not just those using radio access technology. For example, consider a wired phone connected to a router using a mobile data network such as Evolution Data Optimized (EV-DO) as an uplink.
o 所有终端系统的潜在移动性，包括名义上被认为是固定系统的终端，而不仅仅是使用无线接入技术的终端。例如，考虑使用诸如演进数据优化（EV-DO）作为上行链路的移动数据网络连接到路由器的有线电话。
This document focuses on how devices using the Internet can place emergency calls and how PSAPs can handle Internet multimedia emergency calls natively, rather than describing how circuit-switched PSAPs can handle Voice over IP (VoIP) calls. In many cases, PSAPs making the transition from circuit-switched interfaces to packet-switched interfaces may be able to use some of the mechanisms described here, in combination with gateways that translate packet-switched calls into legacy interfaces, e.g., to continue to be able to use existing call taker equipment. There are many legacy telephone networks that will persist long after most systems have been upgraded to IP origination and termination of emergency calls. Many of these legacy systems route calls based on telephone numbers. Gateways and conversions between existing systems and newer systems defined by this document will be required. Since existing systems are governed primarily by local government regulations and national standards, the gateway and conversion details will be governed by national standards and thus are out of scope for this document.
本文档重点介绍使用Internet的设备如何拨打紧急呼叫，以及PSAP如何以本机方式处理Internet多媒体紧急呼叫，而不是描述电路交换PSAP如何处理IP语音（VoIP）呼叫。在许多情况下，从电路交换接口过渡到分组交换接口的PSAP可以结合将分组交换呼叫转换为传统接口的网关，使用这里描述的一些机制，例如，继续能够使用现有的呼叫接受者设备。在大多数系统升级为IP发起和终止紧急呼叫后，许多传统电话网络将长期存在。这些遗留系统中的许多都基于电话号码来路由呼叫。需要本文件定义的现有系统和更新系统之间的网关和转换。由于现有系统主要受地方政府法规和国家标准管辖，因此网关和转换细节将受国家标准管辖，因此不在本文件范围内。
Existing emergency call systems are organized locally or nationally; there are currently few international standards. However, the Internet crosses national boundaries, and thus Internet standards are required. To further complicate matters, VoIP endpoints can be connected through tunneling mechanisms such as virtual private networks (VPNs). Tunnels can obscure the identity of the actual access network that knows the location. This significantly complicates emergency calling, because the location of the caller and the first element that routes emergency calls can be on different continents, with different conventions and processes for handling of emergency calls.
现有的紧急呼叫系统由当地或全国组织；目前国际标准很少。然而，互联网跨越国界，因此需要互联网标准。更复杂的是，VoIP端点可以通过隧道机制（如虚拟专用网络（VPN））连接。隧道可以掩盖知道位置的实际接入网络的身份。这使紧急呼叫变得非常复杂，因为呼叫者的位置和路由紧急呼叫的第一个元素可能位于不同的大陆，处理紧急呼叫的约定和流程也不同。
The IETF has historically not created national variants of its standards. Thus, this document attempts to take into account best practices that have evolved for circuit-switched PSAPs, but it makes no assumptions on particular operating practices currently in use, numbering schemes, or organizational structures.
IETF历史上没有创建其标准的国家变体。因此，本文件试图考虑电路交换PSAP的最佳实践，但不对当前使用的特定操作实践、编号方案或组织结构进行假设。
This document discusses the use of the Session Initiation Protocol (SIP) [RFC3261] by PSAPs and calling parties. While other inter-domain call signaling protocols may be used for emergency calling, SIP is ubiquitous and possesses the proper support of this use case. Only protocols such as H.323, XMPP/Jingle, ISUP, and SIP are suitable for inter-domain communications, ruling out Media Gateway Controller
本文档讨论PSAP和呼叫方使用会话发起协议（SIP）[RFC3261]。虽然其他域间呼叫信令协议可用于紧急呼叫，但SIP是普遍存在的，并且具有此用例的适当支持。只有H.323、XMPP/Kingle、ISUP和SIP等协议适用于域间通信，排除了媒体网关控制器
protocols such as the Media Gateway Control Protocol (MGCP) or H.248/ Megaco. The latter protocols can be used by the enterprise or carrier placing the call, but any such call would reach the PSAP through a media gateway controller, similar to how inter-domain VoIP calls would be placed. Other signaling protocols may also use protocol translation to communicate with a SIP-enabled PSAP. Peer-to-peer SIP (p2psip) is not considered in this document.
协议，如媒体网关控制协议（MGCP）或H.248/Megaco。后一种协议可由拨打电话的企业或运营商使用，但任何此类呼叫都将通过媒体网关控制器到达PSAP，类似于域间VoIP呼叫的方式。其他信令协议也可以使用协议转换来与启用SIP的PSAP通信。本文件不考虑对等SIP（p2psip）。
Existing emergency services rely exclusively on voice and conventional text telephony ("TTY") media streams. However, more choices of media offer additional ways to communicate and evaluate the situation as well as to assist callers and call takers in making and handling emergency calls, respectively. For example, instant messaging and video could improve the ability to communicate and evaluate the situation and to provide appropriate instruction prior to arrival of emergency crews. Thus, the architecture described here supports the creation of sessions of any media type, negotiated between the caller and PSAP using existing SIP mechanisms [RFC3264].
现有的应急服务完全依赖于语音和传统文本电话（“TTY”）媒体流。然而，更多的媒体选择提供了更多的方式来沟通和评估情况，并分别帮助呼叫者和呼叫者拨打和处理紧急电话。例如，即时消息和视频可以提高沟通和评估情况的能力，并在应急人员到达之前提供适当的指导。因此，这里描述的体系结构支持创建任何媒体类型的会话，使用现有SIP机制在调用者和PSAP之间协商[RFC3264]。
This document focuses on the case in which all three steps in the emergency calling process -- location configuration, call routing, and call placement -- can be and are performed by the calling endpoint, with the endpoint's Access Service Provider supporting the process by providing location information. In this case, calls may be routed via an application-layer Communications Service Provider (e.g., a Voice Service Provider) but need not be. The underlying protocols can also be used to support other models in which parts of the process are delegated to the Communications Service Provider. This document does not address in detail either these models or interoperability issues between them and the model described here.
本文档重点介绍紧急呼叫过程中的所有三个步骤（位置配置、呼叫路由和呼叫放置）都可以由呼叫端点执行的情况，端点的访问服务提供商通过提供位置信息来支持该过程。在这种情况下，呼叫可以经由应用层通信服务提供商（例如，语音服务提供商）路由，但不需要路由。底层协议还可用于支持其他模型，在这些模型中，部分流程被委托给通信服务提供商。本文档未详细讨论这些模型或它们与此处描述的模型之间的互操作性问题。
Since this document is a framework document, it does not include normative behavior. [PHONEBCP] describes the best current practice for this subject and contains normative language for devices as well as access and calling network elements.
由于本文件为框架文件，因此不包括规范行为。[PHONEBCP]描述了本主题的最佳实践，并包含设备以及访问和呼叫网络元素的标准语言。
Supporting emergency calling does not require any specialized SIP header fields, request methods, status codes, message bodies, or event packages, but it does require that existing mechanisms be used in certain specific ways, as described below. User agents (UAs) unaware of the recommendations in this document may be able to place emergency calls, but functionality may be impaired. For example, if the UA does not implement the location mechanisms described, an emergency call may not be routed to the correct PSAP, and if the caller is unable to supply his exact location, dispatch of emergency responders may be delayed. Suggested behavior for both endpoints and servers is provided.
支持紧急呼叫不需要任何专门的SIP头字段、请求方法、状态代码、消息体或事件包，但需要以特定方式使用现有机制，如下所述。不知道本文档中建议的用户代理（UAs）可以拨打紧急电话，但功能可能会受损。例如，如果UA未实施所述的定位机制，则紧急呼叫可能无法路由到正确的PSAP，并且如果呼叫者无法提供其确切位置，则紧急响应者的调度可能会延迟。提供了端点和服务器的建议行为。
From the point of view of the PSAP, three essential elements characterize an emergency call:
从PSAP的角度来看，紧急呼叫有三个基本要素：
o The call is routed to the most appropriate PSAP, based primarily on the location of the caller.
o 呼叫主要根据呼叫者的位置路由到最合适的PSAP。
o The PSAP must be able to automatically obtain the location of the caller with sufficient accuracy to dispatch a responder to help the caller.
o PSAP必须能够以足够的准确度自动获取呼叫者的位置，以便派遣响应者帮助呼叫者。
o The PSAP must be able to re-establish a session to the caller if for any reason the original session is disrupted.
o 如果原始会话因任何原因中断，PSAP必须能够重新建立与调用方的会话。
This document uses terms from [RFC3261], [RFC5222], and [RFC5012]. In addition, the following terms are used:
本文件使用[RFC3261]、[RFC5222]和[RFC5012]中的术语。此外，还使用了以下术语：
Access network: The access network supplies IP packet service to an endpoint. Examples of access networks include digital subscriber lines (DSLs), cable modems, IEEE 802.11, WiMaX, enterprise local area networks, and cellular data networks.
接入网络：接入网络向端点提供IP数据包服务。接入网络的示例包括数字用户线（DSL）、电缆调制解调器、IEEE 802.11、WiMaX、企业局域网和蜂窝数据网络。
Confidence: Confidence is an estimate indicating how sure the measuring system is that the actual location of the endpoint is within the bounds defined by the uncertainty value, expressed as a percentage. For example, a value of 90% indicates that the actual location is within the uncertainty nine times out of ten.
置信度：置信度是一种估计值，表明测量系统对端点的实际位置是否在不确定度值定义的范围内（以百分比表示）的确信程度。例如，90%的值表示实际位置十次中有九次在不确定性范围内。
Dispatch location: The dispatch location is the location used for dispatching responders to the person in need of assistance. The dispatch location must be sufficiently precise to easily locate the caller; typically, it needs to be more accurate than the routing location.
派遣地点：派遣地点是将响应者派遣到需要帮助的人员的地点。调度位置必须足够精确，以便轻松定位呼叫者；通常，它需要比路由位置更精确。
Location configuration: During location configuration, an endpoint learns its physical location.
位置配置：在位置配置期间，端点学习其物理位置。
Location Configuration Protocol (LCP): A protocol used by an endpoint to learn its location.
位置配置协议（LCP）：端点用于了解其位置的协议。
Location conveyance: Location conveyance delivers location information to another element.
位置传递：位置传递将位置信息传递给另一个元素。
Location determination: Location determination finds where an endpoint is physically located. For example, the endpoint may contain a Global Navigation Satellite System (GNSS) receiver used to measure its own location or the location may be determined by a network administrator using a wiremap database.
位置确定：位置确定查找端点的物理位置。例如，端点可以包含用于测量其自身位置的全球导航卫星系统（GNSS）接收器，或者该位置可以由网络管理员使用wiremap数据库确定。
Location Information Server (LIS): A Location Information Server stores location information for retrieval by an authorized entity.
位置信息服务器（LIS）：位置信息服务器存储位置信息，供授权实体检索。
Mobile device: A mobile device is a user agent that may change its physical location and possibly its network attachment point during an emergency call.
移动设备：移动设备是一种用户代理，在紧急呼叫期间可能会更改其物理位置和网络连接点。
National Emergency Number Association (NENA): The National Emergency Number Association is an organization of professionals to "foster the technological advancement, availability and implementation of a universal emergency telephone number system in North America". It develops emergency calling specifications and procedures.
国家紧急电话号码协会（NENA）：国家紧急电话号码协会是一个专业组织，旨在“促进北美通用紧急电话号码系统的技术进步、可用性和实施”。它制定了紧急呼叫规范和程序。
Nomadic device (user): A nomadic user agent is connected to the network temporarily, for relatively short durations, but does not move significantly during the emergency call. Examples include a laptop using an IEEE 802.11 hotspot or a desk IP phone that is moved occasionally from one cubicle to another.
游牧设备（用户）：游牧用户代理暂时连接到网络，持续时间相对较短，但在紧急呼叫期间不会明显移动。示例包括使用IEEE 802.11热点的笔记本电脑或偶尔从一个隔间移动到另一个隔间的台式IP电话。
Physical location: A physical location describes where a person or device is located in physical space, described by a coordinate system. It is distinguished from the network location, described by a network address.
物理位置：物理位置描述人或设备在物理空间中的位置，由坐标系描述。它与由网络地址描述的网络位置不同。
Public Safety Answering Point (PSAP): A PSAP is a call center that answers emergency calls.
公共安全应答点（PSAP）：PSAP是应答紧急呼叫的呼叫中心。
Routing location: The routing location of a device is used for routing an emergency call and may not be as precise as the dispatch location.
路由位置：设备的路由位置用于路由紧急呼叫，可能不如调度位置精确。
Stationary device: An stationary device is not mobile and is connected to the network at a fixed, long-term-stable physical location. Examples include home PCs or pay phones.
固定设备：固定设备不是移动设备，而是在固定、长期稳定的物理位置连接到网络。例如家用电脑或付费电话。
Uncertainty: Uncertainty is an estimate, expressed in a unit of length, indicating the diameter of a circle that contains the endpoint with the probability indicated by the confidence value.
不确定性：不确定性是以长度单位表示的估计值，表示包含端点的圆的直径，其概率由置信值表示。
An emergency call can be distinguished (Section 5) from any other call by a unique service URN [RFC5031] that is placed in the call setup signaling when a home or visited emergency dial string is detected. Because emergency services are local to specific geographic regions, a caller obtains his location (Section 6) prior to making emergency calls. To get this location, either a form of measuring, for example, GNSS (Section 6.2.3) is deployed or the endpoint is configured (Section 6.5) with its location from the access network's Location Information Server (LIS) using a Location Configuration Protocol (LCP). The location is conveyed (Section 6.7) in the SIP signaling with the call. The call is 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 a PSAP or an Emergency Services Routing Proxy (ESRP) that serves as an incoming proxy for a group of PSAPs. The call arrives at the PSAP with the location included in the INVITE request.
当检测到家庭或来访的紧急拨号字符串时，可通过一个独特的服务URN[RFC5031]将紧急呼叫与任何其他呼叫区分开（第5节）。由于紧急服务是特定地理区域的本地服务，因此呼叫者在拨打紧急电话之前先获得其位置（第6节）。为了获得该位置，可以部署一种测量形式，例如GNSS（第6.2.3节），或者使用位置配置协议（LCP）从接入网络的位置信息服务器（LIS）配置端点（第6.5节）。该位置在SIP信令中随呼叫传送（第6.7节）。使用位置到服务转换（丢失）协议[RFC5222]基于位置路由呼叫（第8节），该协议将位置映射到一组PSAP URI。每个URI解析为一个PSAP或一个紧急服务路由代理（ESRP），作为一组PSAP的传入代理。呼叫到达PSAP，其位置包含在INVITE请求中。
The following is a quick overview for a typical Ethernet-connected telephone using SIP signaling. It illustrates one set of choices for various options presented later in this document.
以下是使用SIP信令的典型以太网连接电话的简要概述。它说明了本文档后面介绍的各种选项的一组选择。
o The phone "boots" and connects to its access network.
o 手机“启动”并连接到其接入网络。
o The phone gets location via a Location Configuration Protocol (LCP), for example, from the DHCP server in civic [RFC4776] and/or geo [RFC6225] forms, a HTTP-Enabled Location Delivery (HELD) server [RFC5985] or the first-level switch's Link-Layer Discovery Protocol (LLDP) server [LLDP].
o 手机通过位置配置协议（LCP）获取位置，例如，从civic[RFC4776]和/或geo[RFC6225]形式的DHCP服务器、启用HTTP的位置传递（保持）服务器[RFC5985]或一级交换机的链路层发现协议（LLDP）服务器[LLDP]获取位置。
o The phone obtains the local emergency dial string(s) from the LoST [RFC5222] server for its current location. It also receives and caches the PSAP URI obtained from the LoST server.
o 手机从丢失的[RFC5222]服务器获取其当前位置的本地紧急拨号字符串。它还接收并缓存从丢失的服务器获取的PSAP URI。
o Some time later, the user places an emergency call. The phone recognizes an emergency call from the dial strings and uses the "urn:service:sos" [RFC5031] URN to mark an emergency call.
o 一段时间后，用户拨打紧急电话。手机通过拨号串识别紧急呼叫，并使用“urn:service:sos”[RFC5031]urn标记紧急呼叫。
o It refreshes its location via DHCP and updates the PSAP's URI by querying the LoST mapping server with its location.
o 它通过DHCP刷新其位置，并通过查询丢失的映射服务器及其位置来更新PSAP的URI。
o It puts its location in the SIP INVITE request in a Geolocation header [RFC6442] and forwards the call using its normal outbound call processing, which commonly involves an outbound proxy.
o 它将其位置放在地理位置标头[RFC6442]中的SIP INVITE请求中，并使用其正常出站呼叫处理（通常涉及出站代理）转发呼叫。
o The proxy recognizes the call as an emergency call and routes the call using normal SIP routing mechanisms to the URI specified.
o 代理将该呼叫识别为紧急呼叫，并使用普通SIP路由机制将该呼叫路由到指定的URI。
o The call routing commonly traverses an incoming proxy server (ESRP) in the emergency services network. That proxy then routes the call to the PSAP.
o 呼叫路由通常通过紧急服务网络中的传入代理服务器（ESRP）。然后，该代理将调用路由到PSAP。
o The call is established with the PSAP and mutually agreed upon media streams are created.
o 通过PSAP建立呼叫，并创建双方同意的媒体流。
o The location of the caller is displayed to the call taker.
o 呼叫者的位置会显示给接线员。
Configuration Servers
. . . . . . . . . . . . . . . . .
. .
. +--------+ +----------+ .
. +--------+ | +----------+ | .
. | LIS | | | SIP | | .
. | |-+ | Registrar|-+ .
. +--------+ +----------+ .
. ^ ^ .
. . | . . . . . . . | . . . . . .
| |
|[M1][M4] |[M2]
| | +--------+
|+--------------+ +--------+ |
|| | LoST | |
||+-------------------->| Servers|-+
||| [M3][M5] +--------+ +-------+
||| | PSAP2 |
||| +-------+
|||
||| [M6] +-------+ [M7]+------+ [M8]+-------+
Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call Taker
+-------+ +------+ +-------+
Configuration Servers
. . . . . . . . . . . . . . . . .
. .
. +--------+ +----------+ .
. +--------+ | +----------+ | .
. | LIS | | | SIP | | .
. | |-+ | Registrar|-+ .
. +--------+ +----------+ .
. ^ ^ .
. . | . . . . . . . | . . . . . .
| |
|[M1][M4] |[M2]
| | +--------+
|+--------------+ +--------+ |
|| | LoST | |
||+-------------------->| Servers|-+
||| [M3][M5] +--------+ +-------+
||| | PSAP2 |
||| +-------+
|||
||| [M6] +-------+ [M7]+------+ [M8]+-------+
Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call Taker
+-------+ +------+ +-------+
+-------+
| PSAP3 |
+-------+
+-------+
| PSAP3 |
+-------+
Figure 1: Emergency Call Component Topology
图1：紧急呼叫组件拓扑
The typical message flow for this example using Alice as the caller:
本例中使用Alice作为调用方的典型消息流：
[M1] Alice -> LIS: LCP Request(s) (ask for location)
LIS -> Alice: LCP Reply(s) (replies with location)
[M2] Alice -> Registrar: SIP REGISTER
Registrar -> Alice: SIP 200 OK (REGISTER)
[M3] Alice -> LoST Server: Initial LoST Query (contains location)
Lost Server -> Alice: Initial LoST Response (contains
PSAP-URI and dial string)
[M1] Alice -> LIS: LCP Request(s) (ask for location)
LIS -> Alice: LCP Reply(s) (replies with location)
[M2] Alice -> Registrar: SIP REGISTER
Registrar -> Alice: SIP 200 OK (REGISTER)
[M3] Alice -> LoST Server: Initial LoST Query (contains location)
Lost Server -> Alice: Initial LoST Response (contains
PSAP-URI and dial string)
Some time later, Alice dials or otherwise initiates an emergency call:
一段时间后，Alice拨打或以其他方式拨打紧急电话：
[M4] Alice -> LIS: LCP Request (updates location)
LIS -> Alice: LCP Reply (replies with location)
[M5] Alice -> LoST Server: Update LoST Query (contains location)
Lost Server -> Alice: LoST Response (contains PSAP-URI)
[M6] Alice -> Outgoing Proxy: SIP INVITE (contains service URN,
Location and PSAP URI)
[M7] Outgoing Proxy -> ESRP: SIP INVITE (contains service URN,
Location and PSAP URI)
[M8] ESRP -> PSAP: SIP INVITE (contains service URN,
Location and PSAP URI)
[M4] Alice -> LIS: LCP Request (updates location)
LIS -> Alice: LCP Reply (replies with location)
[M5] Alice -> LoST Server: Update LoST Query (contains location)
Lost Server -> Alice: LoST Response (contains PSAP-URI)
[M6] Alice -> Outgoing Proxy: SIP INVITE (contains service URN,
Location and PSAP URI)
[M7] Outgoing Proxy -> ESRP: SIP INVITE (contains service URN,
Location and PSAP URI)
[M8] ESRP -> PSAP: SIP INVITE (contains service URN,
Location and PSAP URI)
The 200 OK response is propagated back from the PSAP to Alice and the ACK response is propagated from Alice to the PSAP.
200 OK响应从PSAP传回Alice，ACK响应从Alice传回PSAP。
Figure 2: Message Flow
图2：消息流
Figure 1 shows emergency call component topology and the text above shows call establishment. These include the following components:
图1显示了紧急呼叫组件拓扑，上面的文本显示了呼叫建立。其中包括以下组成部分：
o Alice - the user of a UA that places the emergency call.
o Alice-发出紧急呼叫的UA用户。
o Configuration servers - Servers providing Alice's UA its IP address and other configuration information, perhaps including location-by-value or location-by-reference. Configuration servers also may include a SIP registrar for Alice's UA. Most SIP UAs will register, so it will be a common scenario for UAs that make emergency calls to be registered with such a server in the originating calling network. In most cases, a UA would have to register in order for the PSAP to be able to call it back after an emergency call has been completed. All the configuration messages are labeled M1 through M3, but could easily require more than three messages to complete.
o 配置服务器-为Alice的UA提供IP地址和其他配置信息的服务器，可能包括按值列出的位置或按引用列出的位置。配置服务器还可以包括用于Alice的UA的SIP注册器。大多数SIP UAs都会注册，因此，对于发出紧急呼叫的UAs来说，向发起呼叫网络中的此类服务器注册是一种常见的情况。在大多数情况下，UA必须注册，以便PSAP能够在紧急呼叫完成后回拨。所有配置消息都标记为M1到M3，但很容易需要三条以上的消息才能完成。
o LoST server - Processes the LoST request for location plus a service URN to a PSAP-URI, either for an initial request from a UA or an in-call routing by the proxy server in the originating network, or possibly by an ESRP.
o 丢失的服务器-处理丢失的位置请求以及PSAP-URI的服务URN，无论是来自UA的初始请求，还是由发起网络中的代理服务器或可能由ESRP进行的呼叫内路由。
o ESRP - Emergency Services Routing Proxy, a SIP proxy server that is the incoming call proxy in the emergency services domain. The ESRP makes further routing decisions (e.g., based on PSAP state and the location of the caller) to choose the actual PSAP that handles the call. In some jurisdictions, this may involve another LoST query.
o ESRP-紧急服务路由代理，是紧急服务域中的传入呼叫代理的SIP代理服务器。ESRP会做出进一步的路由决策（例如，基于PSAP状态和呼叫者的位置），以选择处理呼叫的实际PSAP。在某些司法管辖区，这可能涉及另一个丢失查询。
o PSAP - Emergency calls are answered at a Public Safety Answering Point, a call center.
o PSAP-紧急呼叫在公共安全应答点（呼叫中心）应答。
Generally, Alice's UA either has location configured manually, has an integral location measurement mechanism, or runs an LCP [M1] to obtain location from the access (broadband) network. Then, Alice's UA will most likely register [M2] with a SIP registrar. This allows her to be contacted by other SIP entities. Next, her UA will perform an initial LoST query [M3] to learn a URI for use if the LoST query fails during an emergency call or to use to test the emergency call mechanism. The LoST response contains the dial string for emergency calls appropriate for the location provided.
通常，Alice的UA要么手动配置位置，要么采用整体位置测量机制，要么运行LCP[M1]从接入（宽带）网络获取位置。然后，Alice的UA很可能会向SIP注册员注册[M2]。这允许其他SIP实体联系她。接下来，她的UA将执行初始丢失查询[M3]，以了解URI，以便在紧急呼叫期间丢失查询失败时使用，或用于测试紧急呼叫机制。丢失响应包含适用于所提供位置的紧急呼叫的拨号字符串。
At some time after her device has booted, Alice initiates an emergency call. She may do this by dialing an emergency dial string valid for her current ("local") location or for her "home" location.
在设备启动后的某个时间，Alice启动了一个紧急呼叫。她可以通过拨打一个对她当前（“本地”）位置或“家”位置有效的紧急拨号字符串来实现这一点。
The UA recognizes either dial string. The UA attempts to refresh its location [M4], and with that location, to refresh the LoST mapping [M5], in order to get the most accurate information to use for routing the call. If the location request or the LoST request fails, or takes too long, the UA uses values it has cached.
UA可识别任一拨号字符串。UA尝试刷新其位置[M4]，并使用该位置刷新丢失的映射[M5]，以获得用于路由呼叫的最准确信息。如果位置请求或丢失的请求失败，或时间过长，UA将使用其缓存的值。
The UA creates a SIP INVITE [M6] request that includes the location. [RFC6442] defines a SIP Geolocation header that contains either a location-by-reference URI or a [RFC3986] "cid:" URL indicating where in the message body the location-by-value is.
UA创建包含位置的SIP INVITE[M6]请求。[RFC6442]定义一个SIP Geolocation头，该头包含一个location by reference URI或一个[RFC3986]“cid:”URL，指示location by value在消息体中的位置。
The INVITE message is routed to the ESRP [M7], which is the first inbound proxy for the emergency services domain. This message is then routed by the ESRP towards the most appropriate PSAP for Alice's location [M8], as determined by the location and other information.
INVITE消息被路由到ESRP[M7]，ESRP[M7]是紧急服务域的第一个入站代理。然后，ESRP将该消息路由到Alice位置[M8]的最合适PSAP，该位置由位置和其他信息确定。
A proxy in the PSAP chooses an available call taker and extends the call to its UA.
PSAP中的代理选择可用的呼叫接受者，并将呼叫扩展到其UA。
The 200 OK response to the INVITE request traverses the path in reverse, from call taker UA to PSAP proxy to ESRP to originating network proxy to Alice's UA. The ACK request completes the call setup and the emergency call is established, allowing the PSAP call taker to talk to Alice about Alice's emergency.
INVITE请求的200OK响应反向遍历路径，从呼叫接受者UA到PSAP代理再到ESRP，再到发起网络代理再到Alice的UA。ACK请求完成呼叫设置并建立紧急呼叫，允许PSAP呼叫接受者与Alice谈论Alice的紧急情况。
Current PSAPs support voice calls and real-time text calls placed through PSTN facilities or systems connected to the PSTN. However, future PSAPs will support Internet connectivity and a wider range of media types and provide higher functionality. In general, if a user could reasonably expect to be able to place a call for help with the device, then the device or service should support emergency calling. Certainly, any device or service that looks like and works like a telephone (wired or mobile) should support emergency calling, but increasingly, users have expectations that other devices and services should work.
当前的PSAP支持通过PSTN设施或连接到PSTN的系统进行语音呼叫和实时文本呼叫。然而，未来的PSAP将支持互联网连接和更广泛的媒体类型，并提供更高的功能。一般来说，如果用户可以合理预期能够通过设备拨打求助电话，那么设备或服务应支持紧急呼叫。当然，任何看起来和工作方式类似于电话（有线或移动）的设备或服务都应该支持紧急呼叫，但用户越来越期望其他设备和服务能够正常工作。
Devices that create media sessions and exchange audio, video, and/or text and that have the capability to establish sessions to a wide variety of addresses and communicate over private IP networks or the Internet should support emergency calls.
创建媒体会话和交换音频、视频和/或文本的设备，以及能够建立到各种地址的会话并通过专用IP网络或Internet进行通信的设备，应支持紧急呼叫。
Traditionally, enterprise support of emergency calling is provided by the telephony service provider to the enterprise. In some more recent systems, the enterprise Private Branch Exchange (PBX) assists emergency calling by providing more fine-grained location in larger enterprises. In the future, the enterprise may provide the connection to emergency services itself, not relying on the telephony service provider.
传统上，企业对紧急呼叫的支持是由电话服务提供商向企业提供的。在一些较新的系统中，企业专用分支交换机（PBX）通过在大型企业中提供更细粒度的位置来协助紧急呼叫。未来，企业可能会自行提供与紧急服务的连接，而不依赖电话服务提供商。
Using the PSTN, emergency help can often be summoned by dialing a nationally designated, widely known number, regardless of where the telephone was purchased. The appropriate number is determined by the infrastructure to which the telephone is connected. However, this number differs between localities, even though it is often the same for a country or region, as it is in many countries in the European Union. In some countries, there is only one uniform digit sequence that is used for all types of emergencies. In others, there are several sequences that are specific to the type of responder needed, e.g., one for police, another for fire. For end systems, on the other hand, it is desirable to have a universal identifier, independent of location, to allow the automated inclusion of location
使用PSTN，无论电话是在哪里购买的，通常都可以通过拨打国家指定的、广为人知的号码来呼叫紧急帮助。适当的号码由电话所连接的基础设施决定。然而，这一数字在不同地区有所不同，尽管一个国家或地区的数字通常是相同的，就像欧盟许多国家的数字一样。在一些国家，只有一个统一的数字序列用于所有类型的紧急情况。在其他情况下，有几个特定于所需响应者类型的序列，例如，一个用于警察，另一个用于火灾。另一方面，对于终端系统，希望具有独立于位置的通用标识符，以允许自动包含位置
information and to allow the device and other entities in the call path to perform appropriate processing within the signaling protocol in an emergency call setup.
在紧急呼叫设置中，允许呼叫路径中的设备和其他实体在信令协议内执行适当的处理。
Since no such universal identifier existed, the overall emergency calling architecture described here defines common emergency call URNs [RFC5031]. When all emergency services use a single number, the URN is "urn:service:sos". Users are not expected to "dial" an emergency URN. Rather, appropriate emergency dial strings are translated to corresponding service URNs, carried in the Request-URI of the INVITE request. Such translation is best done by the endpoint, because, among other reasons, emergency calls convey location in the signaling but non-emergency calls normally do not. If the device recognizes the emergency call, it can include location, if known. A signaling intermediary (proxy server) can also recognize emergency dial strings if the endpoint fails to do so.
由于不存在这样的通用标识符，这里描述的整个紧急呼叫体系结构定义了通用紧急呼叫URN[RFC5031]。当所有应急服务使用单一号码时，URN为“URN:service:sos”。用户不需要“拨打”紧急URN。相反，适当的紧急拨号字符串被转换为相应的服务URN，在INVITE请求的请求URI中携带。这种转换最好由端点完成，因为除其他原因外，紧急呼叫在信令中传递位置，而非紧急呼叫通常不传递位置。如果设备识别出紧急呼叫，它可以包括位置（如果已知）。如果端点无法识别紧急拨号字符串，信令中介（代理服务器）也可以识别紧急拨号字符串。
For devices that are mobile or nomadic, an issue arises of whether the home or visited dial strings should be used. Many users would prefer that their home dialing sequences work no matter where they are. However, local laws and regulations may require that the visited dialing sequence(s) work. Therefore, the visited dial string must work. Devices may have a way to be configured or learn home dial strings.
对于移动设备或游牧设备，会出现一个问题，即是否应使用家庭拨号串或访问拨号串。许多用户希望他们的家庭拨号序列无论在哪里都能正常工作。但是，当地法律法规可能要求访问的拨号序列正常工作。因此，访问的拨号串必须工作。设备可能有一种配置或学习家庭拨号字符串的方法。
LoST [RFC5222] provides the mechanism for obtaining the dialing sequences for a given location. LoST servers must return dial strings for emergency services. If the endpoint does not support the translation of dial strings to service URNs, the dialing sequence from the endpoint to its proxy is represented as a dial string [RFC4967] and the outgoing proxy must recognize the dial string and translate it to the equivalent service URN. To determine the local emergency dial string, the proxy needs the location of the endpoint. This may be difficult in situations where the user can roam or be nomadic. Endpoint recognition of emergency dial strings is therefore preferred. If a service provider is unable to guarantee that it can correctly determine local emergency dial strings, wherever its subscribers may be, then it is required that the endpoint do the recognition.
LoST[RFC5222]提供了获取给定位置的拨号序列的机制。丢失的服务器必须返回紧急服务的拨号字符串。如果端点不支持将拨号字符串转换为服务URN，则从端点到其代理的拨号序列表示为拨号字符串[RFC4967]，传出代理必须识别该拨号字符串并将其转换为等效的服务URN。要确定本地紧急拨号字符串，代理需要端点的位置。在用户可以漫游或游牧的情况下，这可能很困难。因此，首选紧急拨号字符串的端点识别。如果服务提供商无法保证其能够正确确定本地紧急拨号字符串（无论其订户在何处），则要求端点进行识别。
Note: The emergency call practitioners consider it undesirable to have a single-button emergency call user interface element. These mechanisms tend to result in a very high rate of false or accidental emergency calls. In order to minimize this issue, practitioners recommend that devices should only initiate emergency calls based on entry of specific emergency call dial strings. Speed dial mechanisms may effectively create single-button emergency call invocation and practitioners recommend they not be permitted.
注意：急诊科急诊科医生认为单按钮紧急呼叫用户界面元件是不希望的。这些机制往往会导致非常高的错误或意外紧急呼叫率。为了尽量减少这一问题，从业人员建议，设备应仅根据特定紧急呼叫拨号字符串的输入启动紧急呼叫。快速拨号机制可以有效地创建单键紧急呼叫调用，从业人员建议不允许这样做。
Location is central to the operation of emergency services. Location is used for two purposes in emergency call handling: routing of the call and dispatch of responders. It is frequently the case that the callers reporting an emergency are unable to provide a unique, valid location themselves. For this reason, location provided by the endpoint or the access network is needed. For practical reasons, each PSAP generally handles only calls for a certain geographic area, with overload arrangements between PSAPs to handle each others' calls. Other calls that reach it by accident must be manually re-routed (transferred) to the more appropriate PSAP, increasing call handling delay and the chance for errors. The area covered by each PSAP differs by jurisdiction, where some countries have only a small number of PSAPs, while others decentralize PSAP responsibilities to the level of counties or municipalities.
位置对应急服务的运行至关重要。位置在紧急呼叫处理中有两个用途：呼叫路由和响应者调度。通常情况下，报告紧急情况的呼叫者自己无法提供唯一、有效的位置。因此，需要端点或接入网络提供的位置。出于实际原因，每个PSAP通常只处理特定地理区域的呼叫，PSAP之间有过载安排来处理彼此的呼叫。其他意外到达的呼叫必须手动重新路由（转移）到更合适的PSAP，从而增加呼叫处理延迟和出错的机会。每个PSAP所涵盖的区域因管辖权而异，其中一些国家只有少量PSAP，而另一些国家将PSAP职责分散到县或市一级。
In most cases, PSAPs cover at least a city or town, but there are some areas where PSAP coverage areas follow old telephone rate center boundaries and may straddle more than one city. Irregular boundaries are common, often due to historical reasons. Routing must be done based on actual PSAP service boundaries -- the closest PSAP, or the PSAP that serves the nominal city name provided in the location, may not be the correct PSAP.
在大多数情况下，PSAP至少覆盖一个城市或城镇，但在某些地区，PSAP覆盖区域遵循旧的电话费率中心边界，可能跨越多个城市。由于历史原因，不规则的边界很常见。必须根据实际的PSAP服务边界进行路由选择——最近的PSAP，或服务于该位置提供的标称城市名称的PSAP，可能不是正确的PSAP。
Accuracy of routing location is a complex subject. Calls must be routed quickly, but accurately, and location determination is often a time/accuracy trade-off, especially with mobile devices or self-measuring mechanisms. If a more accurate routing location is not available, it is considered acceptable to base a routing decision on an accuracy equal to the area of one sector of a mobile cell site.
路由定位的准确性是一个复杂的问题。呼叫必须快速但准确地路由，位置确定通常是一种时间/准确性权衡，尤其是在移动设备或自我测量机制中。如果没有更准确的路由位置，则可以将路由决策基于等于移动小区站点的一个扇区的面积的精度。
Routing to the most appropriate PSAP is always based on the location of the caller, despite the fact that some emergency calls are placed on behalf of someone else, and the location of the incident is sometimes not the location of the caller. In some cases, there are other factors that enter into the choice of the PSAP that gets the call, such as time of day, caller media requests, language preference, and call load. However, location of the caller is the primary input to the routing decision.
到最合适的PSAP的路由始终基于呼叫者的位置，尽管有些紧急呼叫是代表其他人拨打的，并且事件的位置有时不是呼叫者的位置。在某些情况下，选择接收呼叫的PSAP还需要考虑其他因素，如时间、呼叫方媒体请求、语言偏好和呼叫负载。然而，调用方的位置是路由决策的主要输入。
Many mechanisms used to locate a caller have a relatively long "cold start" time. To get a location accurate enough for dispatch may take as much as 30 seconds. This is too long to wait for emergencies. Accordingly, it is common, especially in mobile systems, to use a coarse location, for example, the cell site and sector serving the call, for call-routing purposes, and then to update the location when
许多用于定位调用方的机制具有相对较长的“冷启动”时间。要获得足够准确的位置以便调度可能需要30秒。等待紧急情况的时间太长了。因此，通常，尤其是在移动系统中，为了呼叫路由的目的，使用粗略的位置，例如，服务于呼叫的小区站点和扇区，然后在需要时更新位置
a more precise value is known prior to dispatch. In this document, we use "routing location" and "dispatch location" when the distinction matters.
在分派之前，已知更精确的值。在本文档中，当区分重要时，我们使用“路由位置”和“调度位置”。
Accuracy of dispatch location is sometimes determined by local regulation, and is constrained by available technology. The actual requirement is more stringent than available technology can deliver: It is required that a device making an emergency call close to the "demising" or separation wall between two apartments in a high-rise apartment building report location with sufficient accuracy to determine on what side of the wall it is. This implies perhaps a 3 cm accuracy requirement. As of the date of this memo, assisted GNSS uncertainty in mobile phones with 95% confidence cannot be relied upon to be less than hundreds of meters. As technology advances, the accuracy requirements for location will need to be tightened. Wired systems using wire-tracing mechanisms can provide location to a wall jack in specific room on a floor in a building, and may even specify a cubicle or even smaller resolution. As this discussion illustrates, emergency call systems demand the most stringent location accuracy available.
调度位置的准确性有时由当地法规决定，并受到可用技术的限制。实际要求比现有技术所能提供的更为严格：要求在高层公寓楼两个公寓之间的“除雾”或隔离墙附近发出紧急呼叫的设备报告位置，并具有足够的准确性，以确定其位于墙的哪一侧。这意味着可能需要3 cm的精度要求。截至本备忘录日期，95%置信度的移动电话中的辅助全球导航卫星系统不确定度不能小于数百米。随着技术的进步，定位的准确度要求将更加严格。使用电线追踪机制的有线系统可以为建筑物地板上特定房间的墙壁插孔提供位置，甚至可以指定隔间或更小的分辨率。正如本讨论所示，紧急呼叫系统要求最严格的定位精度。
In Internet emergency calling, where the endpoint is located is determined using a variety of measurement or wire-tracing methods. Endpoints may be configured with their own location by the access network. In some circumstances, a proxy server may insert location into the signaling on behalf of the endpoint. The location is mapped to the URI to send the call to, and the location is conveyed to the PSAP (and other elements) in the signaling. The terms "determination", "configuration", "mapping", and "conveyance" are used for specific aspects of location handling in IETF protocols. Likewise, we employ Location Configuration Protocols, Location Mapping Protocols, and Location Conveyance Protocols for these functions.
在Internet紧急呼叫中，使用各种测量或导线追踪方法确定端点的位置。端点可以由接入网络配置其自己的位置。在某些情况下，代理服务器可以代表端点将位置插入信令中。该位置被映射到要向其发送呼叫的URI，并且该位置被传送到信令中的PSAP（和其他元素）。术语“确定”、“配置”、“映射”和“传输”用于IETF协议中位置处理的特定方面。同样，我们为这些功能使用位置配置协议、位置映射协议和位置传输协议。
This document provides guidance for generic network configurations with respect to location. It is recognized that unique issues may exist in some network deployments. The IETF will continue to investigate these unique situations and provide further guidance, if warranted, in future documents.
本文档提供了有关位置的通用网络配置指南。人们认识到，某些网络部署中可能存在独特的问题。IETF将继续调查这些独特情况，并在未来的文件中提供进一步的指导（如有必要）。
Location can be specified in several ways:
可通过多种方式指定位置：
Civic: Civic location information describes the location of a person or object by a street address that corresponds to a building or other structure. Civic location may include more fine-grained location information such as floor, room, and cubicle. Civic information comes in two forms:
Civic：Civic位置信息通过与建筑物或其他结构相对应的街道地址来描述人或物体的位置。城市位置可能包括更细粒度的位置信息，如楼层、房间和隔间。公民信息有两种形式：
"Jurisdictional" refers to a civic location using actual political subdivisions, especially for the community name.
“辖区”是指使用实际政治分区的城市位置，尤其是社区名称。
"Postal" refers to a civic location for mail delivery. The name of the post office sometimes does not correspond to the community name and a postal address may contain post office boxes or street addresses that do not correspond to an actual building. Postal addresses are generally unsuitable for emergency call dispatch because the post office conventions (for community name, for example) do not match those known by the responders. The fact that they are unique can sometimes be exploited to provide a mapping between a postal address and a civic address suitable to which to dispatch a responder. In IETF location protocols, there is an element (Postal Community Name) that can be included in a location to provide the post office name as well as the actual jurisdictional community name. There is also an element for a postal code. There is no other accommodation for postal addresses in these protocols.
“邮政”是指用于邮件递送的公共场所。邮局的名称有时与社区名称不符，而邮政地址可能包含与实际建筑不符的邮政信箱或街道地址。邮政地址通常不适合紧急呼叫发送，因为邮局惯例（例如，社区名称）与响应者已知的不匹配。它们是唯一的这一事实有时可以被利用来提供邮政地址和公民地址之间的映射，以便于发送响应者。在IETF位置协议中，有一个元素（邮政团体名称）可以包含在一个位置中，以提供邮局名称以及实际的管辖团体名称。还有一个用于邮政编码的元素。在这些协议中，没有为邮政地址提供其他便利。
Geospatial (geo): Geospatial addresses contain longitude, latitude, and altitude information based on an understood datum and earth shape model (datum). While there have been many datums developed over time, most modern systems are using or moving towards the WGS84 [WGS84] datum.
地理空间（geo）：地理空间地址包含基于已知基准和地球形状模型（基准）的经度、纬度和高度信息。虽然随着时间的推移已经开发了许多基准，但大多数现代系统正在使用WGS84[WGS84]基准或朝着WGS84]基准移动。
Cell tower/sector: Cell tower/sector is often used for identifying the location of a mobile handset, especially for routing of emergency calls. Cell tower and sectors identify the cell tower and the antenna sector that a mobile device is currently using. Traditionally, the tower location is represented as a point chosen to be within a certain PSAP service boundary that agrees to take calls originating from that tower/sector, and routing decisions are made on that point. Cell tower/sector information could also be represented as an irregularly shaped polygon of geospatial coordinates reflecting the likely geospatial location of the mobile device. Whatever representation is used must route correctly in the LoST database, where "correct" is determined by local PSAP management.
手机发射塔/扇区：手机发射塔/扇区通常用于识别手机的位置，特别是用于紧急呼叫的路由。基站和扇区标识移动设备当前使用的基站和天线扇区。传统上，塔台位置表示为选择在特定PSAP服务边界内的一个点，该服务边界同意接听来自该塔台/扇区的呼叫，并在该点上做出路由决策。信元塔/扇区信息也可以表示为地理空间坐标的不规则多边形，反映移动设备可能的地理空间位置。使用的任何表示都必须在丢失的数据库中正确路由，其中“正确”由本地PSAP管理确定。
In IETF protocols, both civic and geospatial forms are supported. The civic forms include both postal and jurisdictional fields. A cell tower/sector can be represented as a geo point or polygon or civic location. Other forms of location representation must be mapped into either a geo or civic value for use in emergency calls.
在IETF协议中，支持民用和地理空间形式。公民形式包括邮政和司法领域。单元塔/扇区可以表示为地理点、多边形或城市位置。其他形式的位置表示必须映射为geo或civic值，以便在紧急呼叫中使用。
For emergency call purposes, conversion of location information from civic to geo or vice versa prior to conveyance is not desirable. The location should be sent in the form it was determined. Conversion between geo and civic requires a database. Where PSAPs need to convert from whatever form they received to another for responder purposes, they have a suitable database. However, if a conversion is done before the PSAP's, and the database used is not exactly the same one the PSAP uses, the double conversion has a high probability of introducing an error.
出于紧急呼叫的目的，不希望在传输之前将位置信息从civic转换为geo，反之亦然。应以确定的形式发送位置。geo和civic之间的转换需要一个数据库。当PSAP需要从收到的任何形式转换为另一种形式以用于响应者时，他们有一个合适的数据库。但是，如果转换是在PSAP之前完成的，并且使用的数据库与PSAP使用的数据库不完全相同，则双重转换很有可能引入错误。
As noted above, location information can be entered by the user or installer of a device ("manual configuration"), measured by the end system, be delivered to the end system by some protocol or measured by a third party, and be inserted into the call signaling.
如上所述，位置信息可由设备的用户或安装者输入（“手动配置”），由终端系统测量，通过某种协议传送到终端系统或由第三方测量，并插入呼叫信令中。
In some cases, an entity may have multiple sources of location information, possibly some that are partially contradictory. This is particularly likely if the location information is determined both by the end system and a third party. Although self-measured location (e.g., GNSS) is attractive, location information provided by the access network could be much more accurate, and more reliable in some environments such as high-rise buildings in dense urban areas.
在某些情况下，一个实体可能有多个位置信息源，其中一些可能部分相互矛盾。如果位置信息由终端系统和第三方共同确定，则这种情况尤其可能发生。虽然自测位置（如全球导航卫星系统）很有吸引力，但在某些环境中，如密集城市地区的高层建筑中，接入网络提供的位置信息可能更准确、更可靠。
The closer an entity is to the source of location, the more likely it is able to determine which location is most appropriate for a particular purpose when there is more than one location determination for a given endpoint. In emergency calling, the PSAP is the least likely to be able to appropriately choose which location to use when multiple conflicting locations are presented to it. While all available locations can be sent towards the PSAP, the order of the locations should be the sender's best attempt to guide the recipient of which one(s) to use.
当给定端点有多个位置确定时，实体离位置源越近，就越有可能确定哪个位置最适合特定目的。在紧急呼叫中，当出现多个冲突位置时，PSAP最不可能正确选择要使用的位置。虽然所有可用的位置都可以发送到PSAP，但位置的顺序应该是发送方引导接收方使用哪个位置的最佳尝试。
Location information can be maintained by the end user or the installer of an endpoint in the endpoint itself, or in a database.
最终用户或端点安装程序可以在端点本身或数据库中维护位置信息。
Location information routinely provided by end users is almost always less reliable than measured or wire database information, as users may mistype location information or may enter civic address information that does not correspond to a recognized (i.e., valid, see Section 6.10) address. Users can forget to change the data when the location of a device changes.
最终用户通常提供的位置信息几乎总是比测量或有线数据库信息更不可靠，因为用户可能键入错误的位置信息，或可能输入与已识别（即有效，见第6.10节）地址不对应的公民地址信息。当设备位置发生变化时，用户可能会忘记更改数据。
However, there are always a small number of cases where the automated mechanisms used by the access network to determine location fail to accurately reflect the actual location of the endpoint. For example, the user may deploy his own WAN behind an access network, effectively removing an endpoint some distance from the access network's notion of its location. To handle these exceptional cases, there must be some mechanism provided to manually provision a location for an endpoint by the user or by the access network on behalf of a user. The use of the mechanism introduces the possibility of users falsely declaring themselves to be somewhere they are not. However, this is generally not a problem in practice. Commonly, if an emergency caller insists that he is at a location different from what any automatic location determination system reports he is, responders will always be sent to the user's self-declared location.
然而，在少数情况下，接入网络用于确定位置的自动机制无法准确反映端点的实际位置。例如，用户可以在接入网络后面部署自己的WAN，从而有效地将端点从接入网络的位置概念中移除一段距离。为了处理这些异常情况，必须提供某种机制，由用户或由接入网络代表用户手动为端点提供位置。该机制的使用引入了用户错误地声明自己不在某个地方的可能性。然而，这在实践中通常不是一个问题。通常，如果紧急呼叫者坚持他所处的位置与任何自动位置确定系统报告的位置不同，则应答者将始终被发送到用户自行声明的位置。
Location information can be maintained by the access network, relating some form of identifier for the end subscriber or device to a location database ("wire database"). In enterprise LANs, wiremap databases map Ethernet switch ports to building locations. In DSL installations, the local telephone carrier maintains a mapping of wire-pairs to subscriber addresses.
位置信息可由接入网络维护，将终端订户或设备的某种形式的标识符与位置数据库（“有线数据库”）相关联。在企业局域网中，wiremap数据库将以太网交换机端口映射到建筑位置。在DSL安装中，本地电话运营商维护线对到用户地址的映射。
Accuracy of location historically has been to a street-address level. However, this is not sufficient for larger structures. The Presence Information Data Format (PIDF) Location Object [RFC4119], extended by [RFC5139] and [RFC5491], permits interior building, floor, and room and even finer specification of location within a street address. When possible, interior location should be supported.
历史上，位置的准确度一直处于街道地址级别。然而，这对于较大的结构来说是不够的。通过[RFC5139]和[RFC5491]扩展的状态信息数据格式（PIDF）位置对象[RFC4119]，允许在街道地址内进行内部建筑、楼层和房间，甚至更精细的位置指定。如果可能，应支持内部位置。
The threshold for when interior location is needed is approximately 650 square meters. This value is derived from US fire brigade recommendations of spacing of alarm pull stations. However, interior space layout, construction materials, and other factors should be considered.
需要内部位置时的阈值约为650平方米。该值源自美国消防队建议的报警拉站间距。但是，室内空间布局、建筑材料和其他因素也应予以考虑。
Even for IEEE 802.11 wireless access points, wire databases may provide sufficient location resolution. The location of the access point as determined by the wiremap may be supplied as the location for each of the clients of the access point. However, this may not
即使对于IEEE 802.11无线接入点，有线数据库也可以提供足够的位置分辨率。由wiremap确定的接入点的位置可以作为接入点的每个客户端的位置提供。然而，这可能不是
be true for larger-scale systems such as IEEE 802.16 (WiMAX) and IEEE 802.22 that typically have larger cells than those of IEEE 802.11. The civic location of an IEEE 802.16 base station may be of little use to emergency personnel, since the endpoint could be several kilometers away from the base station.
对于更大规模的系统，如IEEE 802.16（WiMAX）和IEEE 802.22，这种系统的小区通常比IEEE 802.11的小区大。IEEE 802.16基站的城市位置可能对应急人员没有多大用处，因为端点可能离基站几公里远。
Wire databases are likely to be the most promising solution for residential users where a service provider knows the customer's service address. The service provider can then perform address validation (see Section 6.10), similar to the current system in some jurisdictions.
对于服务提供商知道客户服务地址的住宅用户，Wire数据库可能是最有前途的解决方案。然后，服务提供商可以执行地址验证（见第6.10节），类似于某些司法管辖区的当前系统。
Global Positioning System (GPS) and similar Global Navigation Satellite Systems (e.g., GLONAS and Galileo) receivers may be embedded directly in the end device. GNSS produces relatively high precision location fixes in open-sky conditions, but the technology still faces several challenges in terms of performance (time-to-fix and time-to-first-fix), as well as obtaining successful location fixes within shielded structures, or underground. It also requires all devices to be equipped with the appropriate GNSS capability. Many mobile devices require using some kind of "assist", that may be operated by the access network (A-GPS) or by a government (WAAS). A device may be able to use multiple sources of assist data.
全球定位系统（GPS）和类似的全球导航卫星系统（例如GLONAS和伽利略）接收机可直接嵌入终端设备中。全球导航卫星系统在开放天空条件下提供相对高精度的定位定位，但该技术在性能（定位时间和首次定位时间）以及在屏蔽结构或地下获得成功定位方面仍面临若干挑战。它还要求所有设备都配备适当的全球导航卫星系统能力。许多移动设备需要使用某种“辅助”，这种辅助可能由接入网络（A-GPS）或政府（WAAS）操作。设备可以使用多个辅助数据源。
The GNSS satellites are active continuously; thus, location will always be available as long as the device can "see" enough satellites. However, mobile devices may not be able to afford the power levels required to keep the measuring system active. In such circumstances, when location is needed, the device has to start up the measurement mechanism. Typically, this takes tens of seconds, far too long to wait to be able to route an emergency call. For this reason, devices that have end system measured location mechanisms but need a cold start period lasting more than a couple seconds need another way to get a routing location. Typically, this would be a location associated with a radio link (cell tower/sector).
全球导航卫星系统卫星持续活动；因此，只要设备能够“看到”足够多的卫星，位置就始终可用。但是，移动设备可能无法提供保持测量系统活动所需的功率水平。在这种情况下，当需要定位时，设备必须启动测量机构。通常情况下，这需要数十秒，等待时间太长，无法转接紧急呼叫。因此，具有端系统测量定位机制但需要持续几秒钟以上的冷启动时间的设备需要另一种方式来获得路由位置。通常，这将是与无线电链路（蜂窝塔/扇区）相关联的位置。
The access network may locate end devices. Techniques include various forms of triangulation. Elements in the network infrastructure triangulate end systems based on signal strength, angle of arrival or time of arrival. Common mechanisms deployed include the following:
接入网络可以定位终端设备。技术包括各种形式的三角测量。网络基础设施中的元件根据信号强度、到达角或到达时间对终端系统进行三角测量。已部署的常见机制包括：
o Time Difference Of Arrival - TDOA
o 到达时差
o Uplink Time Difference Of Arrival - U-TDOA
o 上行到达时差-U-TDOA
o Angle of Arrival - AOA
o 到达角-AOA
o Radio Frequency (RF) fingerprinting
o 射频（RF）指纹识别
o Advanced Forward Link Trilateration - AFLT
o 高级前向链路三边测量-AFLT
o Enhanced Forward Link Trilateration - EFLT
o 增强型前向链路三边测量-EFLT
Sometimes multiple mechanisms are combined, for example A-GPS with AFLT.
有时，多种机制结合在一起，例如A-GPS和AFLT。
The IETF emergency call architecture prefers endpoints to learn their location and supply it on the call. Where devices do not support location, proxy servers may have to add location to emergency calls. Some calling networks have relationships with all access networks the device may be connected to, and that may allow the proxy to accurately determine the location of the endpoint. However, NATs and other middleboxes often make it impossible to determine a reference identifier the access network could provide to a LIS to determine the location of the device. System designers are discouraged from relying on proxies to add location. The technique may be useful in some limited circumstances as devices are upgraded to meet the requirements of this document, or where relationships between access networks and calling networks are feasible and can be relied upon to get accurate location.
IETF紧急呼叫体系结构倾向于端点了解其位置并在呼叫时提供。如果设备不支持位置，代理服务器可能必须为紧急呼叫添加位置。一些呼叫网络与设备可能连接到的所有接入网络都有关系，这可能允许代理准确地确定端点的位置。然而，NAT和其他中间盒通常使得无法确定接入网络可以提供给LIS的参考标识符以确定设备的位置。不鼓励系统设计人员依赖代理添加位置。当设备升级以满足本文件的要求时，或当接入网络和呼叫网络之间的关系可行且可依赖于获得准确位置时，该技术在某些有限的情况下可能有用。
Proxy insertion of location complicates dial-string recognition. As noted in Section 6, local dial strings depend on the location of the caller. If the device does not know its own location, it cannot use the LoST service to learn the local emergency dial strings. The calling network must provide another way for the device to learn the local dial string, and update it when the user moves to a location where the dial string(s) change, or do the dial-string determination itself.
位置的代理插入使拨号字符串识别复杂化。如第6节所述，本地拨号字符串取决于呼叫者的位置。如果设备不知道自己的位置，则无法使用丢失的服务来了解本地紧急拨号字符串。呼叫网络必须为设备提供另一种方式来学习本地拨号字符串，并在用户移动到拨号字符串发生变化的位置时更新它，或者自己进行拨号字符串确定。
Location information may be expressed as the actual civic or geospatial value but can be transmitted as by value, i.e., wholly contained within the signaling message, or by reference, i.e., as a URI pointing to the value residing on a remote node waiting to be dereferenced.
位置信息可以表示为实际的公民或地理空间值，但可以通过值（即，完全包含在信令消息中）或通过引用（即，作为指向驻留在等待解引用的远程节点上的值的URI）来传输。
When location is transmitted by value, the location information is available to entities in the call path. On the other hand, location objects can be large and only represent a single snapshot of the device's location. Location references are small and can be used to represent a time-varying location, but the added complexity of the dereference step introduces a risk that location will not be available to parties that need it if the dereference transaction were to fail.
当通过值传输位置时，位置信息可用于呼叫路径中的实体。另一方面，位置对象可以很大，并且只表示设备位置的单个快照。位置引用很小，可以用来表示时变位置，但取消引用步骤的复杂性增加了一个风险，即如果取消引用交易失败，位置将无法提供给需要它的各方。
Unless a user agent has access to provisioned or locally measured location information, it must obtain it from the access network. There are several Location Configuration Protocols (LCPs) that can be used for this purpose including DHCP, HELD, and LLDP:
除非用户代理可以访问配置的或本地测量的位置信息，否则它必须从访问网络获取该信息。有几种位置配置协议（LCP）可用于此目的，包括DHCP、HOLD和LLDP：
DHCP can deliver civic [RFC4776] or geospatial [RFC6225] information. User agents need to support both formats. Note that a user agent can use DHCP, via the DHCP REQUEST or INFORM messages, even if it uses other means to acquire its IP address.
DHCP可以传递公民[RFC4776]或地理空间[RFC6225]信息。用户代理需要支持这两种格式。请注意，用户代理可以通过DHCP请求或通知消息使用DHCP，即使它使用其他方式获取其IP地址。
HELD [RFC5985] can deliver a civic or geo location object, by value or by reference, via a Layer 7 protocol. The query typically uses the IP address of the requester as an identifier and returns the location value or reference associated with that identifier. HELD is typically carried in HTTP.
HOLD[RFC5985]可以通过第7层协议，通过值或引用传递civic或geo location对象。查询通常使用请求者的IP地址作为标识符，并返回与该标识符关联的位置值或引用。HOLD通常在HTTP中携带。
Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device (MED) extensions [LLDP-MED] can be used to deliver location information directly from the Layer 2 network infrastructure and also supports both civic and geo formats identical in format to DHCP methods.
链路层发现协议[LLDP]和媒体端点设备（MED）扩展[LLDP-MED]可用于直接从第2层网络基础设施传递位置信息，还支持与DHCP方法格式相同的civic和geo格式。
Each LCP has limitations in the kinds of networks that can reasonably support it. For this reason, it is not possible to choose a single mandatory-to-deploy LCP. For endpoints with common network connections, such as an Ethernet jack or a WiFi connection, location determination could easily fail unless every network supported every protocol, or alternatively, every device supported every protocol. For this reason, a mandatory-to-implement list of LCPs is established in [PHONEBCP]. Every endpoint that could be used to place emergency calls must implement all of the protocols on the list. Every access network must deploy at least one of them. Since it is the variability of the networks that prevent a single protocol from being acceptable, it must be the endpoints that implement all of them, and to accommodate a wide range of devices, networks must deploy at least one of them.
每个LCP在能够合理支持它的网络类型上都有局限性。因此，不可能选择一个强制部署LCP。对于具有常见网络连接的端点，例如以太网插孔或WiFi连接，位置确定可能很容易失败，除非每个网络支持每个协议，或者每个设备支持每个协议。因此，在[PHONEBCP]中建立了强制实施LCP列表。可以用来拨打紧急呼叫的每个端点都必须实现列表中的所有协议。每个接入网络必须至少部署其中一个。由于网络的可变性使单个协议无法被接受，因此必须由端点实现所有协议，并且为了适应范围广泛的设备，网络必须至少部署其中一个协议。
Often, network operators and device designers believe that they have a simpler environment and some other network specific mechanism can be used to provide location. Unfortunately, it is very rare to actually be able to limit the range of devices that may be connected to a network. For example, existing mobile networks are being used to support routers and LANs behind the WAN connection of a wireless data network, with Ethernet connected phones connected to that. It is possible that the access network could support a protocol not on the list and require every handset in that network to use that protocol for emergency calls. However, the Ethernet-connected phone will not be able to acquire location, and the user of the phone is unlikely to be dissuaded from placing an emergency call on that phone. The widespread availability of gateways, routers, and other network-broadening devices means that indirectly connected endpoints are possible on nearly every network. Network operators and vendors are cautioned that shortcuts to meeting this requirement are seldom successful.
通常，网络运营商和设备设计师认为他们有一个更简单的环境，可以使用一些其他特定于网络的机制来提供位置。不幸的是，实际上能够限制可能连接到网络的设备的范围是非常罕见的。例如，现有的移动网络正被用于支持无线数据网络WAN连接后的路由器和LAN，以太网连接的电话连接到该网络。接入网络可能支持不在列表中的协议，并要求该网络中的每个手机在紧急呼叫时使用该协议。然而，以太网连接的电话将无法获取位置，并且不太可能劝阻电话用户在该电话上拨打紧急电话。网关、路由器和其他网络扩展设备的广泛可用性意味着在几乎所有网络上都可以使用间接连接的端点。网络运营商和供应商应注意，满足这一要求的捷径很少成功。
Location for non-mobile devices is normally expected to be acquired at network attachment time and retained by the device. It should be refreshed when the cached value expires. For example, if DHCP is the acquisition protocol, refresh of location may occur when the IP address lease is renewed. At the time of an emergency call, the location should be refreshed, with the retained location used if the location acquisition does not immediately return a value. Mobile devices may determine location at network attachment time and periodically thereafter as a backup in case location determination at the time of call does not work. Mobile device location may be refreshed when a Time-to-Live (TTL) expires or the device moves beyond some boundaries (as provided by [RFC5222]). Normally, mobile devices will acquire their location at call time for use in an emergency call routing. See Section 6.8 for a further discussion on location updates for dispatch location.
非移动设备的位置通常期望在网络连接时获取并由设备保留。当缓存的值过期时，应该刷新它。例如，如果DHCP是采集协议，则在更新IP地址租约时可能会刷新位置。在紧急呼叫时，应刷新位置，如果位置采集未立即返回值，则使用保留的位置。移动设备可以在网络连接时确定位置，并且在呼叫时的位置确定不起作用的情况下，可以在此后定期确定位置作为备份。当生存时间（TTL）到期或设备超出某些边界时（如[RFC5222]所提供），移动设备位置可能会被刷新。通常情况下，移动设备将在通话时获取其位置，以便在紧急呼叫路由中使用。有关派送地点位置更新的进一步讨论，请参见第6.8节。
There are many examples of endpoints that are user agent applications running on a more general purpose device, such as a personal computer. On some systems, Layer 2 protocols like DHCP and LLDP may not be directly accessible to applications. It is desirable for an operating system to have an API that provides the location of the device for use by any application, especially those supporting emergency calls.
有许多端点示例是在更通用的设备（如个人计算机）上运行的用户代理应用程序。在某些系统上，应用程序可能无法直接访问DHCP和LLDP等第2层协议。操作系统最好有一个API，该API提供设备的位置供任何应用程序使用，特别是支持紧急调用的应用程序。
Devices should get routing location immediately after obtaining local network configuration information. The presence of NAT and VPN tunnels (that assign new IP addresses to communications) can obscure identifiers used by LCPs to determine location, especially for HELD.
设备应在获取本地网络配置信息后立即获取路由位置。NAT和VPN隧道（为通信分配新的IP地址）的存在可能会模糊LCP用于确定位置的标识符，尤其是对于被占用的位置。
In some cases, such as residential NAT devices, the NAT is placed between the endpoint and the access network demarcation point and thus the IP address seen by the access network is the right identifier for location of the residence. However, in many enterprise environments, VPN tunnels can obscure the actual IP address. Some VPN mechanisms can be bypassed so that a query to the LCP can be designated to go through the direct IP path, using the correct IP address, and not through the tunnel. In other cases, no bypass is possible, but location can be configured before the VPN is established. Of course, LCPs that use Layer 2 mechanisms (DHCP location options and LLDP-MED) are usually immune from such problems because they do not use the IP address as the identifier for the device seeking location.
在某些情况下，例如住宅NAT设备，NAT被放置在端点和接入网络分界点之间，因此接入网络看到的IP地址是住宅位置的正确标识符。然而，在许多企业环境中，VPN隧道可能会掩盖实际的IP地址。可以绕过某些VPN机制，以便可以指定对LCP的查询通过直接IP路径，使用正确的IP地址，而不是通过隧道。在其他情况下，不可能绕过，但可以在建立VPN之前配置位置。当然，使用第2层机制（DHCP位置选项和LLDP-MED）的LCP通常不会出现此类问题，因为它们不使用IP地址作为设备查找位置的标识符。
It is desirable that routing location information be periodically refreshed. A LIS supporting a million subscribers each refreshing once per day would need to support a query rate of 1,000,000 / (24 * 60 * 60) = 12 queries per second. For networks with mobile devices, much higher refresh rates could be expected.
希望定期刷新路由位置信息。一个每天刷新一次、支持一百万订户的LIS需要支持每秒1000000/（24*60*60）=12次查询的查询速率。对于带有移动设备的网络，可以预期更高的刷新率。
It is desirable for routing location information to be requested immediately before placing an emergency call. However, if there is any significant delay in getting more recent location, the call should be placed with the most recent location information the device has. In mobile handsets, routing is often accomplished with the cell site and sector of the tower serving the call, because it can take many seconds to start up the location determination mechanism and obtain an accurate location.
在发出紧急呼叫之前，需要立即请求路由位置信息。但是，如果在获取最新位置时有任何明显延迟，则应使用设备拥有的最新位置信息拨打电话。在移动手持设备中，路由通常由服务于呼叫的基站和塔台扇区完成，因为启动位置确定机制和获得准确位置可能需要很多秒。
There is a trade-off between the time it takes to get a routing location and the accuracy (technically, confidence and uncertainty) obtained. Routing an emergency call quickly is required. However, if location can be substantially improved by waiting a short time (e.g., for some sort of "quick (location) fix"), it is preferable to wait. Three seconds, the current nominal time for a quick fix, is a very long time add to post-dial delay. NENA recommends [NENAi3TRD] that IP-based systems complete calls in two seconds from last dial press to ring at the PSAP.
在获得路由位置所需的时间和获得的准确性（技术、置信度和不确定性）之间存在权衡。需要快速拨打紧急电话。然而，如果可以通过等待一段短时间（例如，为了某种“快速（位置）修复”）来显著改善位置，则最好等待。三秒钟，即当前快速修复的标称时间，是一个非常长的时间加上拨号后延迟。NENA建议[NENAi3TRD]基于IP的系统在两秒钟内完成呼叫，从最后一次拨号按到PSAP响起。
When an emergency call is placed, the endpoint should include location in the call signaling. This is referred to as "conveyance" to distinguish it from "configuration". In SIP, the location information is conveyed following the procedures in [RFC6442]. Since
当发出紧急呼叫时，端点应包括呼叫信令中的位置。这被称为“传输”，以区别于“配置”。在SIP中，位置信息按照[RFC6442]中的程序传递。自从
the form of the location information obtained by the acquisition protocol may not be the same as the conveyance protocol uses (PIDF-LO [RFC4119]), mapping by the endpoint from the LCP form to PIDF may be required.
通过采集协议获得的位置信息的形式可能与传输协议使用的不同（PIDF-LO[RFC4119]），可能需要端点从LCP形式映射到PIDF。
As discussed above, it may take some time for some measurement mechanisms to get a location accurate enough for dispatch, and a routing location with less accuracy may be provided to get the call established quickly. The PSAP needs the dispatch location before it sends the call to the responder. This requires an update of the location. In addition, the location of some mobile callers, e.g., in a vehicle or aircraft, can change significantly during the emergency call.
如上所述，一些测量机制可能需要一些时间才能获得足够准确的位置以进行调度，并且可以提供精度较低的路由位置以快速建立呼叫。PSAP在向响应者发送呼叫之前需要调度位置。这需要更新位置。此外，在紧急呼叫期间，一些移动呼叫者的位置（例如在车辆或飞机中）可能会发生显著变化。
A PSAP has no way to request an update of a location provided by value. If the User Agent Client (UAC) gets new location information, it must signal the PSAP using a new INVITE or an UPDATE transaction with a new Geolocation header field to supply the new location.
PSAP无法请求更新value提供的位置。如果用户代理客户端（UAC）获得新的位置信息，它必须使用新的INVITE或具有新地理位置标头字段的UPDATE事务向PSAP发送信号，以提供新位置。
With the wide variation in determination mechanisms, the PSAP does not know when accurate location may be available. The preferred mechanism is that the LIS notifies the PSAP when an accurate location is available rather than requiring a poll operation from the PSAP to the LIS. The SIP Presence subscription [RFC3856] provides a suitable mechanism.
由于测定机制的广泛变化，PSAP不知道何时可以获得准确的位置。首选的机制是，当准确位置可用时，LIS通知PSAP，而不需要从PSAP到LIS的轮询操作。SIP状态订阅[RFC3856]提供了合适的机制。
When using a HELD dereference, the PSAP must specify the value "emergencyDispatch" for the ResponseTime parameter. Since, typically, the LIS is local relative to the PSAP, the LIS can be aware of the update requirements of the PSAP.
当使用保留解除引用时，PSAP必须为ResponseTime参数指定值“emergencyDispatch”。由于LIS通常相对于PSAP是本地的，因此LIS可以知道PSAP的更新要求。
Getting multiple locations all purported to describe the location of the caller is confusing to all, and should be avoided. Handling multiple locations at the point where a PIDF is created is discussed in [RFC5491]. Conflicting location information is particularly harmful if different routes (PSAPs) result from LoST queries for the multiple locations. When they occur anyway, the general guidance is that the entity earliest in the chain generally has more knowledge than later elements to make an intelligent decision, especially about which location will be used for routing. It is permissible to send multiple locations towards the PSAP, but the element that chooses the route must select exactly one location to use with LoST.
获取多个位置都是为了描述调用方的位置，这让所有人都感到困惑，应该避免。[RFC5491]中讨论了在创建PIDF的点处处理多个位置。如果多个位置的查询丢失导致不同的路由（PSAP），则冲突的位置信息尤其有害。无论如何，当它们发生时，一般的指导原则是链中最早的实体通常比后来的元素有更多的知识来做出智能决策，特别是关于哪个位置将用于路由。允许向PSAP发送多个位置，但选择路由的元素必须选择一个位置以用于丢失。
Guidelines for dealing with multiple locations are also given in [RFC5222]. If a UA gets multiple locations, it must choose the one to use for routing, but it may send all of the locations it has in the signaling. If a proxy is inserting location and has multiple locations, it must choose exactly one to use for routing and send it as well as any other locations it has that correspond to this UA.
[RFC5222]中也给出了处理多个位置的指南。如果UA获得多个位置，它必须选择一个用于路由，但它可以发送信令中的所有位置。如果代理正在插入位置且有多个位置，则它必须选择一个位置用于路由并发送该位置，以及与此UA对应的任何其他位置。
The UA or proxy should have the ability to understand how and from whom it learned its location, and should include this information in the location objects that are sent to the PSAP. That labeling provides the call taker with information to make decisions upon, as well as guidance for, what to ask the caller and what to tell the responders.
UA或代理应该能够理解如何以及从谁那里了解其位置，并且应该在发送到PSAP的位置对象中包含此信息。该标签为接听电话的人提供了信息，以便做出决定，并为询问来电者什么以及告诉应答者什么提供指导。
Endpoints or proxies may be tempted to send multiple versions of the same location. For example a database may be used to "geocode" or "reverse geocode", that is, convert from civic to geo or vice versa. It is very problematic to use derived locations in emergency calls. The PSAP and the responders have very accurate databases that they use to convert most commonly from a reported geo to a civic suitable for dispatching responders. If one database is used to convert from, say, civic to geo, and another converts from geo to civic, errors will often occur where the databases are slightly different. Errors of even a single house number are serious as it may lead first responders to the wrong building. Derived locations should be marked with a "derived" method token [RFC4119]. If an entity gets a location that has a measured or other original method, and another with a derived method, it must use the original value for the emergency call.
端点或代理可能会尝试发送同一位置的多个版本。例如，数据库可用于“地理编码”或“反向地理编码”，即从civic转换为geo，反之亦然。在紧急呼叫中使用派生位置是非常有问题的。PSAP和响应者拥有非常精确的数据库，他们通常使用这些数据库将报告的地理信息转换为适合调度响应者的公民信息。如果一个数据库用于从（比如）civic转换为geo，而另一个数据库用于从geo转换为civic，则在数据库略有不同的情况下，通常会发生错误。即使是一个门牌号的错误也很严重，因为它可能会导致第一反应者找到错误的建筑。派生位置应标有“派生”方法标记[RFC4119]。如果一个实体获取的位置具有测量的或其他原始方法，而另一个位置具有派生的方法，则它必须为紧急调用使用原始值。
Validation, in this context, means that there is a mapping from the address to a PSAP and that the PSAP understands how to direct responders to the location. It is recommended that location be validated prior to a device placing an actual emergency call; some jurisdictions require that this be done.
在此上下文中，验证意味着存在从地址到PSAP的映射，并且PSAP了解如何将响应者引导到该位置。建议在设备发出实际紧急呼叫之前验证位置；一些司法管辖区要求这样做。
Determining whether an address is valid can be difficult. There are, for example, many cases of two names for the same street, or two streets with the same name but different "suffixes" (Avenue, Street, Circle) in a city. In some countries, the current system provides validation. For example, in the United States of America, the Master Street Address Guide (MSAG) records all valid street addresses and is used to ensure that the service addresses in phone billing records correspond to valid emergency service street addresses. Validation is normally only a concern for civic addresses, although there could
确定地址是否有效可能很困难。例如，在许多情况下，同一条街道有两个名称，或者一个城市中有两条街道有相同的名称，但“后缀”不同（大道、街道、圆圈）。在一些国家，目前的系统提供验证。例如，在美国，《主街道地址指南》（MSAG）记录所有有效街道地址，并用于确保电话计费记录中的服务地址与有效的紧急服务街道地址相对应。验证通常只是公民地址的一个问题，尽管有可能
be some determination that a given geo is within at least one PSAP service boundary; that is, a "valid" geo is one where there is a mapping in the LoST server.
可以确定给定的地理位置在至少一个PSAP服务边界内；也就是说，“有效”地理位置是指丢失的服务器中存在映射的位置。
LoST [RFC5222] includes a location validation function. Validation is normally performed when a location is entered into a Location Information Server. It should be confirmed periodically, because the mapping database undergoes slow change and locations that previously validated may eventually fail validation. Endpoints may wish to validate locations they receive from the access network, and will need to validate manually entered locations. Proxies that insert location may wish to validate locations they receive from a LIS. When the test functions (Section 15) are invoked, the location used should be validated.
LoST[RFC5222]包括位置验证功能。验证通常在将位置输入位置信息服务器时执行。应该定期确认，因为映射数据库的更改速度很慢，以前验证过的位置最终可能会失败。端点可能希望验证从接入网络接收到的位置，并且需要验证手动输入的位置。插入位置的代理可能希望验证从LIS接收的位置。调用测试功能（第15节）时，应验证使用的位置。
When validation fails, the location given should not be used for an emergency call, unless no other valid location is available. Bad location is better than no location. If validation is completed when location is first loaded into a LIS, any problems can be found and fixed before devices could get the bad location. Failure of validation arises because an error is made in determining the location, although occasionally the LoST database is not up to date or has faulty information. In either case, the problem must be identified and should be corrected before using the location.
当验证失败时，除非没有其他有效位置可用，否则不应将给定的位置用于紧急呼叫。位置不好总比没有位置好。如果验证在位置首次加载到LIS时完成，则可以在设备获取错误位置之前发现并修复任何问题。验证失败是因为在确定位置时出错，尽管有时丢失的数据库不是最新的或信息有误。在任何一种情况下，都必须确定问题，并在使用该位置之前予以纠正。
Occasionally, the access network cannot determine the actual location of the caller. In these cases, it must supply a default location. The default location should be as accurate as the network can determine. For example, in a cable network, a default location for each Cable Modem Termination System (CMTS), with a representative location for all cable modems served by that CMTS could be provided if the network is unable to resolve the subscriber to anything more precise than the CMTS. Default locations must be marked as such so that the PSAP knows that the location is not accurate.
有时，接入网络无法确定呼叫者的实际位置。在这些情况下，它必须提供一个默认位置。默认位置应尽可能精确，由网络确定。例如，在有线网络中，如果网络无法将用户解析为比CMT更精确的任何内容，则可以提供每个有线调制解调器终端系统（CMT）的默认位置，以及该CMT服务的所有有线调制解调器的代表位置。必须标记默认位置，以便PSAP知道该位置不准确。
The endpoint is responsible for mapping any form of location it receives from an LCP into PIDF-LO form if the LCP did not directly return a PIDF-LO.
如果LCP没有直接返回PIDF-LO，端点负责将从LCP接收到的任何形式的位置映射到PIDF-LO形式。
Endpoints must be able to discover a LIS, if the HELD protocol is used and a LoST server. DHCP options are defined for this purpose, namely [RFC5986] and [RFC5223].
如果使用了保留协议，并且服务器丢失，端点必须能够发现LIS。为此定义了DHCP选项，即[RFC5986]和[RFC5223]。
Until such DHCP records are widely available, it may be necessary for the service provider to provision a LoST server address in the device. The endpoint can also do a DNS SRV query to find a LoST server. In any environment, more than one of these mechanisms may yield a LoST server, and they may be different. The recommended priority is DHCP first, provisioned value second, and DNS SRV query in the SIP domain third.
在此类DHCP记录广泛可用之前，服务提供商可能需要在设备中提供丢失的服务器地址。端点还可以执行DNS SRV查询以查找丢失的服务器。在任何环境中，这些机制中的多个都可能导致服务器丢失，而且它们可能不同。建议的优先级为DHCP优先、配置值第二和SIP域中的DNS SRV查询第三。
Emergency calls are routed based on one or more of the following criteria expressed in the call setup request (INVITE):
根据呼叫设置请求（INVITE）中表示的以下一个或多个标准路由紧急呼叫：
Location: Since each PSAP serves a limited geographic region and transferring existing calls delays the emergency response, calls need to be routed to the most appropriate PSAP. In this architecture, emergency call setup requests contain location information, expressed in civic or geospatial coordinates, that allows such routing.
位置：由于每个PSAP服务于有限的地理区域，并且转移现有呼叫会延迟紧急响应，因此需要将呼叫路由到最合适的PSAP。在该体系结构中，紧急呼叫设置请求包含位置信息，以城市或地理空间坐标表示，允许此类路由。
Type of emergency service: In some jurisdictions, emergency calls for specific emergency services such as fire, police, ambulance, or mountain rescue are directed to just those emergency-specific PSAPs. This mechanism is supported by marking emergency calls with the proper service identifier [RFC5031]. Even in single-number jurisdictions, not all services are dispatched by PSAPs and may need alternate URNs to route calls to the appropriate call center.
紧急服务类型：在某些司法管辖区，针对特定紧急服务（如消防、警察、救护车或山地救援）的紧急呼叫仅针对特定于紧急情况的PSAP。通过使用正确的服务标识符[RFC5031]标记紧急呼叫来支持此机制。即使在单一号码管辖区，并非所有服务都由PSAP调度，可能需要备用URN将呼叫路由到相应的呼叫中心。
Media capabilities of caller: In some cases, emergency call centers for specific caller media preferences, such as typed text or video, are separate from PSAPs serving voice calls. ESRPs are expected to be able to provide routing based on media. Also, even if media capability does not affect the selection of the PSAP, there may be call takers within the PSAP that are specifically trained, e.g., in real-time text or sign language communications, where routing within the PSAP based on the media offer would be provided.
呼叫者的媒体功能：在某些情况下，特定呼叫者媒体偏好（如键入的文本或视频）的紧急呼叫中心与服务语音呼叫的PSAP是分开的。ESRP有望提供基于介质的路由。此外，即使媒体能力不影响PSAP的选择，PSAP中也可能有经过专门培训的呼叫接受者，例如，在实时文本或手语通信中，其中将提供基于媒体提供的PSAP内的路由。
Providing a URL to route emergency calls by location and by type of service is the primary function LoST [RFC5222] provides. LoST accepts a query with location (by-value) in either civic or geo form, plus a service identifier, and returns a URI (or set of URIs) to which to route the call. Normal SIP [RFC3261] routing functions are used to resolve the URI to a next-hop destination.
[RFC5222]提供的主要功能是通过URL按位置和服务类型路由紧急呼叫。LoST以civic或geo形式接受带有位置（按值）的查询，再加上服务标识符，并返回要将调用路由到的URI（或URI集）。正常的SIP[RFC3261]路由函数用于将URI解析到下一跳目的地。
The endpoint can complete the LoST mapping from its location at boot time, and periodically thereafter. It should attempt to obtain a "fresh" location, and from that a current mapping when it places an emergency call. If accessing either its location acquisition or its mapping functions fail, it should use its cached value. The call would follow its normal outbound call processing.
端点可以在引导时从其位置完成丢失的映射，并在引导后定期完成。它应该尝试获取一个“新”位置，并在发出紧急呼叫时从该位置获取当前映射。如果访问其位置获取或映射函数失败，则应使用其缓存值。该呼叫将遵循其正常的出站呼叫处理。
Determining when the device leaves the area provided by the LoST service can tax small mobile devices. For this reason, the LoST server should return a simple (small number of points) polygon for geospatial location. This can be a simple enclosing rectangle of the PSAP service area when the reported point is not near an edge, or a smaller polygonal edge section when the reported location is near an edge. Civic location is uncommon for mobile devices, but reporting that the same mapping is good within a community name, or even a street, may be very helpful for WiFi connected devices that roam and obtain civic location from the access point to which they are connected.
确定设备何时离开丢失服务提供的区域可能会对小型移动设备征税。因此，丢失的服务器应返回一个简单（少量点）多边形作为地理空间位置。当报告点不靠近边缘时，可以是PSAP服务区的简单封闭矩形，或当报告位置靠近边缘时，可以是较小的多边形边缘部分。Civic location对于移动设备来说并不常见，但报告相同的地图在社区名称甚至街道内都很好，这可能对WiFi连接的设备非常有帮助，这些设备可以漫游并从其连接的接入点获取Civic location。
Networks that support devices that do not implement LoST mapping themselves may need the outbound proxy do the mapping. If the endpoint recognized the call was an emergency call, provided the correct service URN and/or included location on the call in a Geolocation header, a proxy server could easily accomplish the mapping.
支持自身未实现丢失映射的设备的网络可能需要出站代理进行映射。如果端点识别出呼叫是紧急呼叫，并且提供了正确的服务URN和/或Geolocation头中包含的呼叫位置，则代理服务器可以轻松完成映射。
However, if the endpoint did not recognize the call was an emergency call, and thus did not include location, the proxy's task is more difficult. It is often difficult for the calling network to accurately determine the endpoint's location. The endpoint may have its own location, but would not normally include it on the call signaling unless it knew it was an emergency call. There is no mechanism provided in [RFC6442] for a proxy to request the endpoint supply its location, because that would open the endpoint to an attack by any proxy on the path to get it to reveal location. The proxy can attempt to redirect a call to the service URN, which, if the device recognizes the significance, would include location in the redirected call from the device. All network elements should detect emergency calls and supply default location and/or routing if it is not already present.
但是，如果端点没有识别出呼叫是紧急呼叫，因此没有包括位置，那么代理的任务就更加困难。呼叫网络通常很难准确确定端点的位置。端点可能有自己的位置，但通常不会将其包含在呼叫信令中，除非它知道这是一个紧急呼叫。[RFC6442]中没有提供代理请求端点提供其位置的机制，因为这会使端点受到路径上任何代理的攻击，从而暴露其位置。代理可以尝试将呼叫重定向到服务URN，如果设备认识到其重要性，该服务URN将包括来自设备的重定向呼叫中的位置。所有网络元件应检测紧急呼叫，并提供默认位置和/或路由（如果尚未提供）。
The LoST server would normally be provided by the local emergency authorities, although the access network or calling network might run its own server using data provided by the emergency authorities. Some enterprises may have local responders and call centers, and could operate their own LoST server, providing URIs to in-house "PSAPs". Local regulations might limit the ability of enterprises to direct emergency calls to in-house services.
丢失的服务器通常由当地应急机构提供，尽管接入网络或呼叫网络可能使用应急机构提供的数据运行自己的服务器。一些企业可能有本地响应者和呼叫中心，并且可以运行自己的丢失服务器，为内部“PSAP”提供URI。地方法规可能会限制企业向内部服务部门拨打紧急电话的能力。
The ESRP, which is a normal SIP proxy server in the signaling path of the call, may use a variety of PSAP state information, the location of the caller, and other criteria to route onward the call to the PSAP. In order for the ESRP to route on media choice, the initial INVITE request has to supply an SDP offer.
ESRP是呼叫信令路径中的普通SIP代理服务器，它可以使用各种PSAP状态信息、呼叫方的位置和其他标准将呼叫向前路由到PSAP。为了让ESRP根据媒体选择进行路由，初始邀请请求必须提供SDP报价。
Best current practice for SIP user agents [RFC4504] including handling of audio, video, and real-time text [RFC4103] should be applied. As discussed above, location is carried in all emergency calls in the call signaling. Since emergency calls carry privacy-sensitive information, they are subject to the requirements for geospatial protocols [RFC3693]. In particular, signaling information should be carried in Transport Layer Security (TLS), i.e., in 'sips' mode with a ciphersuite that includes strong encryption, such as AES. There are exceptions in [RFC3693] for emergency calls. For example, local policy may dictate that location is sent with an emergency call even if the user's policy would otherwise prohibit that. Nevertheless, protection from eavesdropping of location by encryption should be provided.
应采用SIP用户代理[RFC4504]的当前最佳实践，包括处理音频、视频和实时文本[RFC4103]。如上所述，在呼叫信令中的所有紧急呼叫中都携带位置。由于紧急呼叫携带隐私敏感信息，因此需要遵守地理空间协议[RFC3693]的要求。特别是，信令信息应在传输层安全（TLS）中传输，即，在“sips”模式下，使用包含强加密（如AES）的密码套件。[RFC3693]中有紧急呼叫的例外情况。例如，即使用户的策略禁止发送紧急呼叫，本地策略也可能规定发送位置。然而，应提供加密保护，防止位置被窃听。
It is unacceptable to have an emergency call fail to complete because a TLS connection was not created for any reason. Thus, the call should be attempted with TLS, but if the TLS session establishment fails, the call should be automatically retried without TLS. [RFC5630] recommends that to achieve this effect, the target specify a sip URI, but use TLS on the outbound connection. An element that receives a request over a TLS connection should attempt to create a TLS connection to the next hop.
由于任何原因都没有创建TLS连接，因此无法完成紧急呼叫是不可接受的。因此，应使用TLS尝试呼叫，但如果TLS会话建立失败，则应在不使用TLS的情况下自动重试呼叫。[RFC5630]建议，为实现此效果，目标指定sip URI，但在出站连接上使用TLS。通过TLS连接接收请求的元素应尝试创建到下一个跃点的TLS连接。
In many cases, persistent TLS connections can be maintained between elements to minimize the time needed to establish them [RFC5626]. In other circumstances, use of session resumption [RFC5077] is recommended. IPsec [RFC4301] is an acceptable alternative to TLS when used with an equivalent crypto suite.
在许多情况下，可以在元件之间保持持久的TLS连接，以尽量减少建立它们所需的时间[RFC5626]。在其他情况下，建议使用会话恢复[RFC5077]。当与等效的加密套件一起使用时，IPsec[RFC4301]是TLS的可接受替代方案。
Location may be used for routing by multiple proxy servers on the path. Confidentiality mechanisms such as Secure/Multipurpose Internet Mail Extensions (S/MIME) encryption of SIP signaling [RFC3261] cannot be used because they obscure location. Only hop-by-hop mechanisms such as TLS should be used. Implementing location conveyance in SIP mandates inclusion of TLS support.
位置可由路径上的多个代理服务器用于路由。不能使用保密机制，例如SIP信令[RFC3261]的安全/多用途Internet邮件扩展（S/MIME）加密，因为它们模糊了位置。只能使用逐跳机制，如TLS。在SIP中实现位置传输要求包含TLS支持。
SIP UAs that recognize local dial strings, insert location, and perform emergency call routing will create SIP INVITE messages with the service URN in the Request-URI, the LoST-determined URI for the PSAP in a Route header, and the location in a Geolocation header. The INVITE request must also have appropriate callback identifiers (in Contact and From headers). To enable media-sensitive routing, the call should include a Session Description Protocol (SDP) offer [RFC3264].
识别本地拨号字符串、插入位置和执行紧急呼叫路由的SIP UAs将创建SIP INVITE消息，其中请求URI中包含服务URN、路由头中PSAP丢失的确定URI以及地理位置头中的位置。INVITE请求还必须具有适当的回调标识符（在Contact和From头中）。要启用媒体敏感路由，调用应包括会话描述协议（SDP）提供[RFC3264]。
SIP caller preferences [RFC3841] can be used to signal how the PSAP should handle the call. For example, a language preference expressed in an Accept-Language header may be used as a hint to cause the PSAP to route the call to a call taker who speaks the requested language. SIP caller preferences may also be used to indicate a need to invoke a relay service for communication with people with disabilities in the call.
SIP呼叫方首选项[RFC3841]可用于指示PSAP应如何处理呼叫。例如，在接受语言报头中表示的语言偏好可以用作提示，以使PSAP将呼叫路由到说所请求语言的呼叫接受者。SIP呼叫方偏好还可用于指示需要调用中继服务以与呼叫中的残疾人通信。
At least one SIP proxy server in the path of an emergency call must be able to assist UAs that are unable to provide any of the location-based routing steps and recognition of dial strings. A proxy can recognize the lack of location awareness by the lack of a Geolocation header. It can recognize the lack of dial-string recognition by the presence of the local emergency call dial string in the From header without the service URN being present. They should obtain the location of the endpoint if possible, and use a default location if they cannot, inserting it in a Geolocation header. They should query LoST with the location and put the resulting URI in a route, with the appropriate service URN in the Request-URI. In any event, they are also expected to provide information for the caller using SIP Identity or P-Asserted-Identity. It is often a regulatory matter whether calls normally marked as anonymous are passed as anonymous when they are emergency calls. Proxies must conform to the local regulation or practice.
紧急呼叫路径中至少有一个SIP代理服务器必须能够帮助无法提供任何基于位置的路由步骤和拨号字符串识别的UAs。代理可以通过缺少地理位置标头来识别缺少位置感知。它可以通过From报头中存在本地紧急呼叫拨号字符串而不存在服务URN来识别缺少拨号字符串识别。如果可能，他们应该获取端点的位置，如果不能，则使用默认位置，将其插入地理位置标头中。他们应该查询丢失的位置，并将结果URI放入路由中，在请求URI中包含相应的服务URN。在任何情况下，它们还应使用SIP标识或P-Asserted-Identity为调用者提供信息。通常标记为匿名的呼叫在紧急呼叫时是否传递为匿名，这通常是一个监管问题。代理人必须符合当地法规或惯例。
The call taker must be able to reach the emergency caller if the original call is disconnected. In traditional emergency calls, wireline and wireless emergency calls include a callback identifier for this purpose. There are two kinds of call backs. When a call is dropped, or the call taker realizes that some important information is needed that it doesn't have, it must call back the device that placed the emergency call. The PSAP, or a responder, may need to call back the caller much later, and for that purpose, it wants a
如果原来的电话断开，接线员必须能够联系到紧急呼叫者。在传统的紧急呼叫中，有线和无线紧急呼叫包括一个用于此目的的回拨标识符。有两种回拨方式。当一个电话被挂断，或者接听电话的人意识到需要一些重要的信息，而这些信息是他所没有的，他必须回拨拨打紧急电话的设备。PSAP或响应者可能需要在很久以后回叫调用方，为此，它需要一个
normal SIP address of record (AOR). In SIP systems, the caller must include a Contact header field in an emergency call containing a globally routable URI, possibly a Globally Routable User Agent URI (GRUU) [RFC5627]. This identifier would be used to initiate callbacks immediately by the call taker if, for example, the call is prematurely dropped. A concern arises with back-to-back user agents (B2BUAs) that manipulate Contact headers. Such B2BUAs should always include a Contact header that routes to the same device.
记录的正常SIP地址（AOR）。在SIP系统中，呼叫者必须在紧急呼叫中包含联系人标头字段，该字段包含全局可路由URI，可能是全局可路由用户代理URI（GRUU）[RFC5627]。例如，如果呼叫被过早地丢弃，该标识符将被呼叫接受者用来立即发起回调。操作联系人头的背对背用户代理（B2BUA）引起了关注。此类B2BUA应始终包括路由到同一设备的联系人标头。
In addition, a callback identifier as an address of record (AoR) must be included either as the URI in the From header field [RFC3261] verified by SIP Identity [RFC4474] or as a network-asserted URI [RFC3325]. If the latter, the PSAP will need to establish a suitable spec(t) with the proxies that send it emergency calls. This identifier would be used to initiate a callback at a later time and may reach the caller, not necessarily on the same device (and at the same location) as the original emergency call as per normal SIP rules. It is often a regulatory matter whether calls normally marked as anonymous are passed as anonymous when they are emergency calls. Proxies must conform to the local regulation or practice.
此外，作为记录地址（AoR）的回调标识符必须作为URI包含在由SIP标识[RFC4474]验证的From标头字段[RFC3261]中，或者作为网络断言URI[RFC3325]中。如果是后者，PSAP将需要与发送紧急呼叫的代理建立适当的规范（t）。该标识符将用于在以后启动回调，并可能到达呼叫者，根据正常SIP规则，不一定在与原始紧急呼叫相同的设备（和相同的位置）上。通常标记为匿名的呼叫在紧急呼叫时是否传递为匿名，这通常是一个监管问题。代理人必须符合当地法规或惯例。
Some PSAPs often include dispatchers, responders, or specialists on a call. Some responders' dispatchers are not located in the primary PSAP, the call may have to be transferred to another PSAP. Most often, this will be an attended transfer, or a bridged transfer. Therefore, a PSAP may need to a REFER request [RFC3515] a call to a bridge for conferencing. Devices that normally involve the user in transfer operations should consider the effect of such interactions when a stressed user places an emergency call. Requiring user interface manipulation during such events may not be desirable. Relay services for communication with people with disabilities may be included in the call with the bridge. The UA should be prepared to have the call transferred (usually attended, but possibly blind) per [RFC5359].
一些PSAP通常包括呼叫的调度员、响应者或专家。一些响应者的调度员不在主PSAP中，呼叫可能必须转移到另一个PSAP。通常情况下，这将是有人值守转移或桥接转移。因此，PSAP可能需要将请求[RFC3515]转介到桥接器以进行会议。在急诊科中，通常涉及用户在转移操作中的设备应考虑这种交互作用。在此类事件期间要求用户界面操作可能并不可取。与残疾人通信的中继服务可能包括在与桥梁的通话中。UA应准备根据[RFC5359]转接呼叫（通常有人接听，但可能是盲拨）。
It is undesirable for the caller to terminate an emergency call. A PSAP terminates a call using the normal SIP call termination procedures, i.e., with a BYE request.
呼叫者不希望终止紧急呼叫。PSAP使用正常的SIP呼叫终止过程（即，通过BYE请求）终止呼叫。
Certain features that can be invoked while a normal call is active are not permitted when the call is an emergency call. Services such as call waiting, call transfer, three-way calling, and hold should be disabled.
当正常呼叫处于活动状态时，如果呼叫是紧急呼叫，则不允许调用某些功能。应禁用呼叫等待、呼叫转接、三方呼叫和保持等服务。
Certain features such as call forwarding can interfere with calls from a PSAP and should be disabled. There is no way to reliably determine a PSAP call back. A UA may be able to determine a PSAP call back by examining the domain of incoming calls after placing an emergency call and comparing that to the domain of the answering PSAP from the emergency call. Any call from the same domain and directed to the supplied Contact header or AoR after an emergency call should be accepted as a callback from the PSAP if it occurs within a reasonable time after an emergency call was placed.
某些功能（如呼叫转移）可能会干扰来自PSAP的呼叫，因此应禁用。无法可靠地确定PSAP回调。UA可以通过在发出紧急呼叫后检查传入呼叫的域并将其与来自紧急呼叫的应答PSAP的域进行比较来确定PSAP回拨。如果紧急呼叫发生在紧急呼叫后的合理时间内，则来自同一域并在紧急呼叫后定向到提供的联系人标头或AoR的任何呼叫都应被接受为PSAP的回调。
PSAPs should always accept RTP media streams [RFC3550]. Traditionally, voice has been the only media stream accepted by PSAPs. In some countries, text, in the form of Baudot codes or similar tone encoded signaling within a voiceband is accepted ("TTY") for persons who have hearing disabilities. Using SIP signaling includes the capability to negotiate media. Normal SIP offer/answer [RFC3264] negotiations should be used to agree on the media streams to be used. PSAPs should accept real-time text [RFC4103]. All PSAPs should accept G.711 A-law (and mu-law in North America) encoded voice as described in [RFC3551]. Newer text forms are rapidly appearing, with instant messaging now very common, PSAPs should accept IM with at least "pager-mode" MESSAGE request [RFC3428] as well as Message Session Relay Protocol [RFC4975]. Video media in emergency calling is required to support Video Relay Service (sign language interpretation) as well as modern video phones.
PSAP应始终接受RTP媒体流[RFC3550]。传统上，语音是PSAP接受的唯一媒体流。在一些国家，对于听力障碍者，语音带内以波多特码或类似音调编码信号形式的文本（“TTY”）是可以接受的。使用SIP信令包括协商媒体的能力。应使用正常的SIP提供/应答[RFC3264]协商来商定要使用的媒体流。PSAP应该接受实时文本[RFC4103]。所有PSAP应接受[RFC3551]中所述的G.711 A-law（以及北美的mu-law）编码语音。新的文本形式正在迅速出现，即时消息现在非常普遍，PSAP应至少接受“寻呼机模式”消息请求[RFC3428]以及消息会话中继协议[RFC4975]的IM。紧急呼叫中的视频媒体需要支持视频中继服务（手语翻译）以及现代视频电话。
It is desirable for media to be kept secure by the use of Secure RTP [RFC3711], using DTLS [RFC5764] for keying.
希望通过使用安全RTP[RFC3711]，使用DTL[RFC5764]进行键控来保持介质的安全。
Since the emergency calling architecture consists of a number of pieces operated by independent entities, it is important to be able to test whether an emergency call is likely to succeed without actually occupying the human resources at a PSAP. Both signaling and media paths need to be tested since NATs and firewalls may allow the session setup request to reach the PSAP, while preventing the exchange of media.
由于紧急呼叫体系结构由许多独立实体操作的部分组成，因此能够测试紧急呼叫是否可能成功而不实际占用PSAP的人力资源非常重要。信令和媒体路径都需要测试，因为NAT和防火墙可能允许会话设置请求到达PSAP，同时阻止媒体交换。
[PHONEBCP] includes a description of an automated test procedure that validates routing, signaling, and media path continuity. This test should be used within some random interval after boot time, and whenever the device location changes enough that a new PSAP mapping is returned by the LoST server.
[PHONEBCP]包括对验证路由、信令和媒体路径连续性的自动测试程序的描述。此测试应该在启动后的某个随机间隔内使用，并且只要设备位置发生足够的变化，丢失的服务器就会返回新的PSAP映射。
The PSAP needs to be able to control frequency and duration of the test, and since the process could be abused, it may temporarily or permanently suspend its operation.
PSAP需要能够控制测试的频率和持续时间，并且由于该过程可能被滥用，它可能会暂时或永久暂停其运行。
There is a concern associated with testing during a so-called "avalanche-restart" event where, for example, a large power outage affects a large number of endpoints, that, when power is restored, all attempt to reboot and, possibly, test. Devices need to randomize their initiation of a boot time test to avoid the problem.
在所谓的“雪崩重启”事件期间，存在一个与测试相关的问题，例如，大停电会影响大量端点，当电源恢复时，所有人都会尝试重启，可能还会进行测试。设备需要随机启动启动时间测试以避免问题。
Security considerations for emergency calling have been documented in [RFC5069] and [RFC6280].
[RFC5069]和[RFC6280]中记录了紧急呼叫的安全注意事项。
This document suggests that security (TLS or IPsec) be used hop-by-hop on a SIP call to protect location information, identity, and other privacy-sensitive call data. It also suggests that if the attempt to create a security association fails, the call be retried without the security. It is more important to get an emergency call through than to protect the data; indeed, in many jurisdictions privacy is explicitly waived when making emergency calls. Placing a call without security may reveal user information, including location. The alternative, failing the call if security cannot be established, is considered unacceptable.
本文档建议在SIP呼叫中逐跳使用安全性（TLS或IPsec），以保护位置信息、身份和其他隐私敏感的呼叫数据。它还建议，如果创建安全关联的尝试失败，则在没有安全机制的情况下重试调用。拨打紧急电话比保护数据更重要；事实上，在许多司法管辖区，拨打紧急电话时明确放弃隐私权。在没有安全保护的情况下拨打电话可能会泄露用户信息，包括位置。另一种选择是，如果无法建立安全性，则呼叫失败，这被认为是不可接受的。
This document was created from "Emergency Services for Internet Telephony Systems" (Schulzrinne, 2004) together with sections from "Emergency Context Routing of Internet Technologies Architecture Considerations" (Polk, 2006).
本文件是根据“互联网电话系统的紧急服务”（Schulzrinne，2004）以及“互联网技术架构考虑的紧急上下文路由”（Polk，2006）中的章节创建的。
Design Team members participating in this document creation include Martin Dolly, Stu Goldman, Ted Hardie, Marc Linsner, Roger Marshall, Shida Schubert, Tom Taylor, and Hannes Tschofenig. Further comments and input were provided by Richard Barnes, Barbara Stark, and James Winterbottom.
参与本文档创作的设计团队成员包括马丁·多利、斯图·戈德曼、泰德·哈迪、马克·林纳、罗杰·马歇尔、希达·舒伯特、汤姆·泰勒和汉内斯·茨霍芬尼。Richard Barnes、Barbara Stark和James Winterbottom提供了进一步的评论和意见。
[LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", December 2004.
[LLDP]IEEE，“IEEE802.1ab站点和媒体访问控制”，2004年12月。
[LLDP-MED] ANSI/TIA, "Link Layer Discovery Protocol - Media Endpoint Discovery", TIA Standard, TIA-1057, April 2006.
[LLDP-MED]ANSI/TIA，“链路层发现协议-媒体端点发现”，TIA标准，TIA-1057，2006年4月。
[NENAi3TRD] NENA, "08-751 v1 - i3 Technical Requirements (Long Term Definition)", 2006.
[NENAi3TRD]NENA，“08-751 v1-i3技术要求（长期定义）”，2006年。
[PHONEBCP] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, September 2011.
[PHONEBCP]Rosen，B.和J.Polk，“支持紧急呼叫的通信服务当前最佳实践”，正在进行的工作，2011年9月。
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[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.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693]Cuellar，J.，Morris，J.，Mulligan，D.，Peterson，J.，和J.Polk，“地质驱动要求”，RFC 3693，2004年2月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856]Rosenberg，J.，“会话启动协议（SIP）的存在事件包”，RFC3856，2004年8月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[RFC4103]Hellstrom，G.和P.Jones，“文本对话的RTP有效负载”，RFC 4103，2005年6月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]Peterson，J.，“一种基于状态的GEOPRIV定位对象格式”，RFC41192005年12月。
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony", RFC 4190, November 2005.
[RFC4190]Carlberg，K.，Brown，I.，和C.Beard，“IP电话中支持紧急电信服务（ETS）的框架”，RFC 41902005年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony Device Requirements and Configuration", RFC 4504, May 2006.
[RFC4504]Sinnreich，H.，Lass，S.，和C.Stredicke，“SIP电话设备要求和配置”，RFC 4504，2006年5月。
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC4776]Schulzrinne，H.，“Civic地址配置信息的动态主机配置协议（DHCPv4和DHCPv6）选项”，RFC 4776，2006年11月。
[RFC4967] Rosen, B., "Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier", RFC 4967, July 2007.
[RFC4967]Rosen，B.，“会话启动协议统一资源标识符的拨号字符串参数”，RFC 4967，2007年7月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]Campbell，B.，Mahy，R.，和C.Jennings，“消息会话中继协议（MSRP）”，RFC 49752007年9月。
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[RFC5012]Schulzrinne，H.和R.Marshall，“利用互联网技术解决紧急情况的要求”，RFC 5012，2008年1月。
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[RFC5031]Schulzrinne，H.，“应急和其他知名服务的统一资源名称（URN）”，RFC 5031，2008年1月。
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[RFC5069]Taylor，T.，Tschofenig，H.，Schulzrinne，H.，和M.Shanmugam，“紧急呼叫标记和映射的安全威胁和要求”，RFC 5069，2008年1月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，2008年1月。
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5139]Thomson，M.和J.Winterbottom，“状态信息数据格式位置对象（PIDF-LO）的修订公民位置格式”，RFC 5139，2008年2月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222]Hardie，T.，Newton，A.，Schulzrinne，H.，和H.Tschofenig，“丢失：位置到服务转换协议”，RFC 5222，2008年8月。
[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.
[RFC5223]Schulzrinne，H.，Polk，J.，和H.Tschofenig，“使用动态主机配置协议（DHCP）发现位置到服务转换（丢失）服务器”，RFC 52232008年8月。
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008.
[RFC5359]Johnston，A.，Sparks，R.，Cunningham，C.，Donovan，S.，和K.Summers，“会话启动协议服务示例”，BCP 144，RFC 5359，2008年10月。
[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.
[RFC5491]Winterbottom，J.，Thomson，M.，和H.Tschofenig，“GEOPRIV存在信息数据格式位置对象（PIDF-LO）使用说明、注意事项和建议”，RFC 54912009年3月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]Jennings，C.，Mahy，R.，和F.Audet，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，2009年10月。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5630]Audet，F.“会话启动协议（SIP）中SIPS URI方案的使用”，RFC 5630，2009年10月。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，RFC 5764，2010年5月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]Barnes，M.，“支持HTTP的位置传递（保留）”，RFC 59852010年9月。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.
[RFC5986]Thomson，M.和J.Winterbottom，“发现本地位置信息服务器（LIS）”，RFC 59862010年9月。
[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.
[RFC6225]Polk，J.，Linsner，M.，Thomson，M.，和B.Aboba，“基于坐标的位置配置信息的动态主机配置协议选项”，RFC 62252011年7月。
[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.
[RFC6280]Barnes，R.，Lepinski，M.，Cooper，A.，Morris，J.，Tschofenig，H.，和H.Schulzrinne，“互联网应用中的位置和位置隐私架构”，BCP 160，RFC 62802011年7月。
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011.
[RFC6442]Polk，J.，Rosen，B.，和J.Peterson，“会话启动协议的位置传输”，RFC 6442，2011年12月。
[WGS84] NIMA, "NGA: DoD World Geodetic System 1984, Its Definition and Relationships with Local Geodetic Systems", Technical Report TR8350.2, Third Edition, July 1997.
[WGS84]NIMA，“NGA:DoD世界大地测量系统1984，其定义及其与本地大地测量系统的关系”，技术报告TR8350.2，第三版，1997年7月。
Authors' Addresses
作者地址
Brian Rosen NeuStar, Inc. 470 Conrad Dr Mars, PA 16046 USA
Brian Rosen NeuStar，Inc.美国宾夕法尼亚州康拉德·马尔斯博士，邮编：16046
EMail: br@brianrosen.net
EMail: br@brianrosen.net
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
美国纽约州纽约市哥伦比亚大学计算机科学系计算机科学大楼450号
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
James Polk Cisco Systems 3913 Treemont Circle Colleyville, Texas 76034 USA
James Polk Cisco Systems 3913美国德克萨斯州Treemont Circle Colleyville 76034
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Andrew Newton TranTech/MediaSolv 4900 Seminary Road Alexandria, VA 22311 USA
美国弗吉尼亚州亚历山大神学院路4900号Andrew Newton TranTech/MediaSolv 22311
Phone: +1 703 845 0656
EMail: andy@hxr.us
Phone: +1 703 845 0656
EMail: andy@hxr.us