Internet Engineering Task Force (IETF) B. Rosen
Request for Comments: 6881 NeuStar
BCP: 181 J. Polk
Category: Best Current Practice Cisco Systems
ISSN: 2070-1721 March 2013
Internet Engineering Task Force (IETF) B. Rosen
Request for Comments: 6881 NeuStar
BCP: 181 J. Polk
Category: Best Current Practice Cisco Systems
ISSN: 2070-1721 March 2013
Best Current Practice for Communications Services in Support of Emergency Calling
支持紧急呼叫的通信服务的最佳现行做法
Abstract
摘要
The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls.
IETF和其他标准组织致力于将IP网络紧急呼叫的各个方面标准化。本备忘录描述了使用IETF协议的设备、网络和服务应如何使用此类标准进行紧急呼叫的最佳实践。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见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/rfc6881.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6881.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Overview of How Emergency Calls Are Placed ......................3
4. Which Devices and Services Should Support Emergency Calls? ......4
5. Identifying an Emergency Call ...................................4
6. Location and Its Role in an Emergency Call ......................5
6.1. Types of Location Information ..............................6
6.2. Location Determination .....................................6
6.2.1. User-Entered Location Information ...................6
6.2.2. Access Network "Wire Database" Location
Information .........................................6
6.2.3. End System Measured Location Information ............7
6.2.4. Network Measured Location Information ...............7
6.3. Who Adds Location? The Endpoint, or the Proxy? ............8
6.4. Location and References to Location ........................8
6.5. End System Location Configuration ..........................8
6.6. When Location Should Be Configured ........................10
6.7. Conveying Location ........................................11
6.8. Location Updates ..........................................11
6.9. Multiple Locations ........................................12
6.10. Location Validation ......................................12
6.11. Default Location .........................................13
6.12. Other Location Considerations ............................13
7. LIS and LoST Discovery .........................................13
8. Routing the Call to the PSAP ...................................14
9. Signaling of Emergency Calls ...................................15
9.1. Use of TLS ................................................15
9.2. SIP Signaling Requirements for User Agents ................16
9.3. SIP Signaling Requirements for Proxy Servers ..............17
10. Callbacks .....................................................18
11. Mid-Call Behavior .............................................19
12. Call Termination ..............................................19
13. Disabling of Features .........................................19
14. Media .........................................................20
15. Testing .......................................................21
16. Security Considerations .......................................22
17. IANA Considerations ...........................................22
17.1. Test Service URN .........................................22
17.2. 'test' Subregistry .......................................23
18. Acknowledgements ..............................................23
19. References ....................................................23
19.1. Normative References .....................................23
19.2. Informative References ...................................27
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Overview of How Emergency Calls Are Placed ......................3
4. Which Devices and Services Should Support Emergency Calls? ......4
5. Identifying an Emergency Call ...................................4
6. Location and Its Role in an Emergency Call ......................5
6.1. Types of Location Information ..............................6
6.2. Location Determination .....................................6
6.2.1. User-Entered Location Information ...................6
6.2.2. Access Network "Wire Database" Location
Information .........................................6
6.2.3. End System Measured Location Information ............7
6.2.4. Network Measured Location Information ...............7
6.3. Who Adds Location? The Endpoint, or the Proxy? ............8
6.4. Location and References to Location ........................8
6.5. End System Location Configuration ..........................8
6.6. When Location Should Be Configured ........................10
6.7. Conveying Location ........................................11
6.8. Location Updates ..........................................11
6.9. Multiple Locations ........................................12
6.10. Location Validation ......................................12
6.11. Default Location .........................................13
6.12. Other Location Considerations ............................13
7. LIS and LoST Discovery .........................................13
8. Routing the Call to the PSAP ...................................14
9. Signaling of Emergency Calls ...................................15
9.1. Use of TLS ................................................15
9.2. SIP Signaling Requirements for User Agents ................16
9.3. SIP Signaling Requirements for Proxy Servers ..............17
10. Callbacks .....................................................18
11. Mid-Call Behavior .............................................19
12. Call Termination ..............................................19
13. Disabling of Features .........................................19
14. Media .........................................................20
15. Testing .......................................................21
16. Security Considerations .......................................22
17. IANA Considerations ...........................................22
17.1. Test Service URN .........................................22
17.2. 'test' Subregistry .......................................23
18. Acknowledgements ..............................................23
19. References ....................................................23
19.1. Normative References .....................................23
19.2. Informative References ...................................27
This document describes how access networks, Session Initiation Protocol [RFC3261] user agents, proxy servers, and Public Safety Answering Points (PSAPs) support emergency calling, as outlined in [RFC6443], which is designed to complement the present document in section headings, numbering, and content. Understanding [RFC6443] is necessary to understand this document. This Best Current Practice (BCP) succinctly describes the requirements of end devices and applications (requirements prefaced by "ED-"), access networks (including enterprise access networks) (requirements prefaced by "AN-"), service providers (requirements prefaced by "SP-"), and PSAPs to achieve globally interoperable emergency calling on the Internet.
本文件描述了接入网络、会话启动协议[RFC3261]用户代理、代理服务器和公共安全应答点（PSAP）如何支持紧急呼叫，如[RFC6443]中所述，旨在在章节标题、编号和内容方面补充本文件。理解[RFC6443]是理解本文件的必要条件。本最佳现行做法（BCP）简要描述了终端设备和应用程序的要求（要求以“ED-”开头）、接入网络（包括企业接入网络）（要求以“AN-”开头）、服务提供商（要求以“SP-”开头），以及PSAP，以实现互联网上的全球互操作紧急呼叫。
This document also defines requirements for "intermediate" devices that exist between end devices or applications and the access network. For example, a home router is an intermediate device. Reporting location on an emergency call (see Section 6) may depend on the ability of such intermediate devices to meet the requirements prefaced by "INT-".
本文件还定义了终端设备或应用程序与接入网络之间存在的“中间”设备的要求。例如，家庭路由器是中间设备。紧急呼叫的报告位置（见第6节）可能取决于此类中间设备满足“INT-”开头要求的能力。
The access network requirements apply to those networks that may be used to place emergency calls using IETF protocols. Local regulations may impact the need to support this document's access network requirements.
接入网络要求适用于那些可用于使用IETF协议拨打紧急呼叫的网络。当地法规可能会影响支持本文件访问网络要求的需要。
Other organizations, such as the National Emergency Number Association (NENA), define the PSAP interface. NENA's documents reference this document.
其他组织，如国家应急号码协会（NENA）定义了PSAP接口。NENA的文件引用了本文件。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This document uses terms from [RFC3261], [RFC5012], and [RFC6443].
本文件使用[RFC3261]、[RFC5012]和[RFC6443]中的术语。
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 must obtain his location (Section 6) prior to making emergency calls. To get this location, either a form of measuring (e.g., GPS) ([RFC6443] Section 6.2.3) device location in
当检测到家庭或来访的紧急拨号字符串时，可通过一个独特的服务URN[RFC5031]将紧急呼叫与任何其他呼叫区分开（第5节）。由于紧急服务是特定地理区域的本地服务，因此呼叫者必须在拨打紧急电话之前获得其所在位置（第6节）。要获得该位置，可以使用一种测量形式（如GPS）（[RFC6443]第6.2.3节）在
the endpoint is deployed or the endpoint is configured (Section 6.5) with its location from the access network's Location Information Server (LIS). 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 a group of PSAPs. The call arrives at the PSAP with the location included in the SIP INVITE request.
使用接入网络位置信息服务器（LIS）中的位置部署或配置端点（第6.5节）。该位置在SIP信令中随呼叫传送（第6.7节）。使用位置到服务转换（丢失）协议[RFC5222]基于位置路由呼叫（第8节），该协议将位置映射到一组PSAP URI。每个URI解析为一个PSAP或为一组PSAP服务的紧急服务路由代理（ESRP）。呼叫到达PSAP，其位置包含在SIP INVITE请求中。
ED-1: A device or application that implements SIP calling SHOULD support emergency calling. Some jurisdictions have regulations governing which devices need to support emergency calling, and developers are encouraged to ensure that devices they develop meet relevant regulatory requirements. Unfortunately, the natural variation in those regulations also makes it impossible to accurately describe the cases when developers do or do not have to support emergency calling.
ED-1：实现SIP呼叫的设备或应用程序应支持紧急呼叫。一些司法管辖区有法规规定哪些设备需要支持紧急呼叫，鼓励开发者确保他们开发的设备符合相关法规要求。不幸的是，这些规则中的自然变化也使得不可能准确地描述开发人员是否必须支持紧急呼叫的情况。
SP-1: If a device or application expects to be able to place a call for help, the service provider that supports it MUST facilitate emergency calling. Some jurisdictions have regulations governing this.
SP-1：如果设备或应用程序希望能够拨打求助电话，则支持它的服务提供商必须为紧急呼叫提供便利。一些司法管辖区对此有规定。
ED-2: Devices that create media sessions and exchange real-time 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. Some jurisdictions have regulations governing this.
ED-2：创建媒体会话并交换实时音频、视频和/或文本的设备，以及能够建立到各种地址的会话并通过专用IP网络或Internet进行通信的设备，应支持紧急呼叫。一些司法管辖区对此有规定。
ED-3: Endpoints SHOULD recognize dial strings of emergency calls. If the service provider always knows the location of the device (the correct dial string depends on which country a caller is in), the service provider may recognize them; see SP-2.
ED-3：端点应该识别紧急呼叫的拨号字符串。如果服务提供商始终知道设备的位置（正确的拨号字符串取决于呼叫者所在的国家），则服务提供商可以识别它们；见SP-2。
SP-2: Proxy servers SHOULD recognize emergency dial strings if for some reason the endpoint does not recognize them.
SP-2:如果由于某种原因端点无法识别紧急拨号字符串，则代理服务器应识别这些字符串。
ED-4/SP-3: Emergency calls MUST be marked with a service URN in the Request-URI of the INVITE.
ED-4/SP-3：紧急呼叫必须在INVITE的请求URI中标记服务URN。
ED-5/SP-4: Geographically local dial strings MUST be recognized.
ED-5/SP-4：必须识别地理位置上的本地拨号字符串。
ED-6/SP-5: Devices MUST be able to be configured with the home country from which the home dial string(s) can be determined.
ED-6/SP-5：设备必须能够配置母国，从中可以确定家庭拨号字符串。
ED-7/SP-6: Emergency dial strings SHOULD be determined from LoST [RFC5222]. Dial strings MAY be configured directly into the device.
ED-7/SP-6：应根据丢失的[RFC5222]确定紧急拨号串。拨号字符串可以直接配置到设备中。
AN-1: LoST servers MUST return dial strings for emergency services.
AN-1：丢失的服务器必须返回紧急服务的拨号字符串。
ED-8: Endpoints that do not recognize emergency dial strings SHOULD send dial strings as per [RFC4967].
ED-8：不识别紧急拨号字符串的端点应根据[RFC4967]发送拨号字符串。
SP-7: If a proxy server recognizes dial strings on behalf of its clients, it MUST recognize emergency dial strings represented by [RFC4967] and SHOULD recognize the emergency dial strings represented by a tel URI [RFC3966].
SP-7：如果代理服务器代表其客户端识别拨号字符串，则必须识别由[RFC4967]表示的紧急拨号字符串，并应识别由电话URI[RFC3966]表示的紧急拨号字符串。
ED-9: Endpoints SHOULD be able to have home dial strings provisioned.
ED-9:终结点应该能够设置主拨号字符串。
SP-8: Service providers MAY provision home dial strings in devices.
SP-8：服务提供商可以在设备中提供家庭拨号字符串。
ED-10: Devices SHOULD NOT have one-button emergency calling initiation.
ED-10：设备不应具有一键紧急呼叫启动。
ED-11/SP-9: All sub-services for the 'sos' service specified in [RFC5031] MUST be recognized.
ED-11/SP-9：必须识别[RFC5031]中规定的“sos”服务的所有子服务。
Handling location for emergency calling usually involves several steps to process, and multiple entities are involved. In Internet emergency calling, where the endpoint is located is determined using a variety of measurement or wire-tracing methods. Endpoints can be configured with their own location by the access network. In some circumstances, a proxy server can 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 entities) in the signaling. Likewise, we employ Location Configuration Protocols (LCPs), the Location-to-Service Mapping Protocol, and Location Conveyance Protocols for these functions. The Location-to-Service Translation protocol [RFC5222] is the Location Mapping Protocol defined by the IETF.
紧急呼叫的处理位置通常涉及多个处理步骤，涉及多个实体。在Internet紧急呼叫中，使用各种测量或导线追踪方法确定端点的位置。端点可以通过接入网络配置自己的位置。在某些情况下，代理服务器可以代表端点将位置插入信令中。该位置被映射到要向其发送呼叫的URI，并且该位置被传送到信令中的PSAP（和其他实体）。同样，我们为这些功能使用位置配置协议（LCP）、位置到服务映射协议和位置传输协议。位置到服务转换协议[RFC5222]是IETF定义的位置映射协议。
There are several forms of location. All IETF location configuration and location conveyance protocols support both civic and geospatial (geo) forms. The civic forms include both postal and jurisdictional fields. A cell tower/sector can be represented as a point (geo or civic) or polygon. Endpoints, intermediate devices, and service providers receiving other forms of location representation MUST map them into either a geo or civic for use in emergency calls.
有几种形式的位置。所有IETF位置配置和位置传输协议都支持民用和地理空间（geo）形式。公民形式包括邮政和司法领域。单元塔/扇区可以表示为点（地理或城市）或多边形。接收其他形式位置表示的端点、中间设备和服务提供商必须将它们映射到geo或civic中，以便在紧急呼叫中使用。
ED-12/INT-1/SP-10: Endpoints, intermediate devices, and service providers MUST be prepared to handle location represented in either civic or geo form.
ED-12/INT-1/SP-10：端点、中间设备和服务提供商必须准备好处理以civic或geo形式表示的位置。
ED-13/INT-2/SP-11/AN-2: Entities MUST NOT convert (civic to geo or geo to civic) from the form of location that the determination mechanism (see Section 6.2) supplied prior to receipt by the PSAP.
ED-13/INT-2/SP-11/AN-2：实体不得从PSAP接收前确定机制（见第6.2节）提供的位置形式转换（civic到geo或geo到civic）。
ED-14/INT-3/AN-3: Any location determination mechanism MAY be used, provided the accuracy of the location meets local requirements.
ED-14/INT-3/AN-3：只要定位精度满足当地要求，就可以使用任何定位机制。
ED-15/INT-4/AN-4: Devices, intermediate devices, and/or access networks SHOULD support a manual method to override the location the access network determines. When the override location is supplied in civic form, it MUST be possible for the resultant Presence Information Data Format Location Object (PIDF-LO) received at the PSAP to contain any of the elements specified in [RFC4119] and [RFC5139].
ED-15/INT-4/AN-4：设备、中间设备和/或接入网络应支持手动方法覆盖接入网络确定的位置。当覆盖位置以civic形式提供时，PSAP接收的结果存在信息数据格式位置对象（PIDF-LO）必须能够包含[RFC4119]和[RFC5139]中指定的任何元素。
AN-5: Access networks supporting copper, fiber, or other hard-wired IP packet services SHOULD support location configuration. If the network does not support location configuration, it MUST require every device or intermediate device that connects to the network to support end system measured location.
AN-5：支持铜缆、光纤或其他硬接线IP数据包服务的接入网络应支持位置配置。如果网络不支持位置配置，则必须要求连接到网络的每个设备或中间设备支持终端系统测量的位置。
AN-6/INT-5: Access networks and intermediate devices providing wire database location information SHOULD provide interior location data (building, floor, room, cubicle) where possible. It is RECOMMENDED that interior location be provided when spaces exceed approximately 650 square meters. See [RFC6443] Section 6.2.2 for a discussion of how this value was determined.
AN-6/INT-5：提供线路数据库位置信息的接入网络和中间设备应尽可能提供内部位置数据（建筑物、地板、房间、隔间）。当空间超过约650平方米时，建议提供内部位置。有关如何确定该值的讨论，请参见[RFC6443]第6.2.2节。
AN-7/INT-6: Access networks and intermediate devices (including enterprise networks) that support intermediate range wireless connections (typically 100 m or less of range) and that do not support a more accurate location determination mechanism such as triangulation MUST support location configuration where the location of the access point is reflected as the location of the clients of that access point.
AN-7/INT-6：支持中距离无线连接（通常为100米或更小距离）的接入网络和中间设备（包括企业网络）不支持更精确的位置确定机制（如三角测量）的系统必须支持位置配置，其中接入点的位置反映为该接入点的客户端的位置。
AN-8/INT-7: Where the access network provides location configuration, intermediate devices MUST either be transparent to it or provide an interconnected client for the supported configuration mechanism and a server for a configuration protocol supported by end devices downstream of the intermediate device such that the location provided by the access network is available to clients as if the intermediate device was not in the path.
AN-8/INT-7：其中接入网络提供位置配置，中间设备必须对其透明，或者为受支持的配置机制提供互连客户端，并为中间设备下游的终端设备支持的配置协议提供服务器，以便接入网络提供的位置可供客户端使用，就好像中间设备是不在路上。
ED-16/INT-8: Devices MAY support end system measured location. See [RFC6443] Section 6 for a discussion of accuracy of location.
ED-16/INT-8：设备可支持端系统测量位置。有关定位精度的讨论，请参见[RFC6443]第6节。
ED-17/INT-9/AN-9: Devices that support endpoint measuring of location MUST have at least a coarse location capability (typically <1 km accuracy) for the routing of calls. The location mechanism MAY be a service provided by the access network.
ED-17/INT-9/AN-9：支持端点位置测量的设备必须至少具有呼叫路由的粗略定位能力（通常<1 km精度）。定位机制可以是由接入网络提供的服务。
AN-10: Access networks MAY provide network measured location determination. Wireless access networks that do not supply network measured location MUST require every device or intermediate device connected to the network to support end system measured location. Uncertainty and confidence may be specified by local regulation. Where not specified, uncertainty of less than 100 meters with 95% confidence is RECOMMENDED for dispatch location.
AN-10：接入网络可提供网络测量的位置确定。不提供网络测量位置的无线接入网络必须要求连接到网络的每个设备或中间设备支持终端系统测量位置。不确定性和置信度可由当地法规规定。如果没有规定，建议调度位置的不确定度小于100米，置信度为95%。
AN-11: Access networks that provide network measured location MUST have at least a coarse location (typically <1 km when not location hiding) capability at all times for the routing of calls.
AN-11：提供网络测量位置的接入网络必须始终具有至少一个粗略位置（非位置隐藏时通常<1 km）的呼叫路由能力。
AN-12: Access networks with a range of <10 meters (e.g., personal area networks such as Bluetooth) MUST provide a location to mobile devices connected to them. The location provided SHOULD be that reported by the upstream access network unless a more accurate mechanism is available.
AN-12：范围小于10米的接入网络（例如，蓝牙等个人区域网络）必须为与其连接的移动设备提供位置。提供的位置应为上游接入网络报告的位置，除非有更准确的机制可用。
ED-18/INT-10: Endpoints SHOULD attempt to configure their own location using the Location Configuration Protocols (LCPs) listed in ED-21.
ED-18/INT-10：端点应尝试使用ED-21中列出的位置配置协议（LCP）配置自己的位置。
SP-12: Proxies MAY provide location on behalf of devices if:
SP-12：代理可以代表设备提供位置，如果：
o The proxy has a relationship with all access networks the device could connect to, and the relationship allows it to obtain location.
o 代理与设备可以连接到的所有访问网络都有关系，并且该关系允许它获取位置。
o The proxy has an identifier, such as an IP address, that can be used by the access network to determine the location of the endpoint, even in the presence of NAT and VPN tunnels that may obscure the identifier between the access network and the service provider.
o 代理具有标识符，例如IP地址，接入网络可以使用该标识符来确定端点的位置，即使在存在可能模糊接入网络和服务提供商之间的标识符的NAT和VPN隧道的情况下也是如此。
ED-19/INT-11/SP-13: Where proxies provide location on behalf of endpoints, the service provider MUST ensure that either the end device is provided with the local dial strings for its current location (where the end device recognizes dial strings) or the service provider proxy MUST detect the appropriate local dial strings at the time of the call.
ED-19/INT-11/SP-13：如果代理代表端点提供位置，则服务提供商必须确保为终端设备提供其当前位置的本地拨号字符串（终端设备识别拨号字符串的位置），或者服务提供商代理必须在呼叫时检测适当的本地拨号字符串。
ED-20/INT-12: Devices SHOULD be able to accept and forward location-by-value or location-by-reference. An end device that receives location-by-reference (and does not also get the corresponding value) MUST be able to perform a dereference operation to obtain a value.
ED-20/INT-12：设备应能够通过值或参考位置接受和转发位置。通过引用接收位置的终端设备（并且没有获得相应的值）必须能够执行解引用操作以获得值。
Obtaining location from the access network may be preferable even if the device can measure its own location, especially indoors where most measurement mechanisms are not accurate enough. The requirements listed in this section do not apply to devices that can accurately measure their own location.
即使设备能够测量其自身的位置，尤其是在大多数测量机制不够精确的室内，从接入网络获取位置也可能是优选的。本节列出的要求不适用于能够准确测量自身位置的设备。
ED-21/INT-13: Devices MUST support both the Dynamic Host Configuration Protocol (DHCP) location options [RFC4776] [RFC6225] and HTTP-Enabled Location Delivery (HELD) [RFC5985]. When devices deploy a specific access network interface for which location configuration mechanisms such as Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device SHOULD support the additional respective access network specific location configuration mechanism.
ED-21/INT-13：设备必须同时支持动态主机配置协议（DHCP）位置选项[RFC4776][RFC6225]和启用HTTP的位置传递（保留）[RFC5985]。当设备部署指定了位置配置机制（如链路层发现协议-媒体端点发现（LLDP-MED）[LLDP-MED]或802.11v）的特定接入网络接口时，设备应支持附加的相应接入网络特定位置配置机制。
AN-13/INT-14: The access network MUST support either DHCP location options or HELD. The access network SHOULD support other location configuration technologies that are specific to the type of access network.
AN-13/INT-14：接入网络必须支持DHCP位置选项或保持。接入网络应支持特定于接入网络类型的其他位置配置技术。
AN-14/INT-15: Where a router is employed between a LAN and WAN in a small (less than approximately 650 square meters) area, the router MUST be transparent to the location provided by the WAN to the LAN. This may mean the router must obtain location as a client from the WAN and supply an LCP server to the LAN with the location it obtains. Where the area is larger, the LAN MUST have a location configuration mechanism satisfying the requirements of this document.
AN-14/INT-15：如果在局域网和广域网之间的小面积（小于约650平方米）区域使用路由器，则路由器必须对广域网提供给局域网的位置透明。这可能意味着路由器必须作为客户端从WAN获取位置，并向LAN提供LCP服务器及其获取的位置。当区域较大时，LAN必须具有满足本文件要求的位置配置机制。
ED-22/INT-16: Endpoints SHOULD try all LCPs supported by the device in any order or in parallel. The first one that succeeds in supplying location MUST be used.
ED-22/INT-16：端点应以任意顺序或并行方式尝试设备支持的所有LCP。必须使用第一个成功提供位置的。
AN-15/INT-17: Access networks that support more than one LCP MUST reply with the same location information (within the limits of the data format for the specific LCP) for all LCPs it supports.
AN-15/INT-17：支持多个LCP的接入网络必须对其支持的所有LCP回复相同的位置信息（在特定LCP的数据格式限制范围内）。
ED-23/INT-18/SP-14: When HELD is the LCP, the request MUST specify a value of "emergencyRouting" for the "responseTime" parameter and use the resulting location for routing. If a value for dispatch location will be sent, another request with the "responseTime" parameter set to "emergencyDispatch" must be completed, with the result sent for dispatch purposes.
ED-23/INT-18/SP-14：当LCP被保留时，请求必须为“responseTime”参数指定“emergencyRouting”值，并使用结果位置进行路由。如果要发送调度位置的值，则必须完成另一个“responseTime”参数设置为“emergencyDispatch”的请求，并将结果发送用于调度目的。
ED-24: Where the operating system supporting application programs that need location for emergency calls does not allow access to Layer 2 and Layer 3 functions necessary for a client application to use DHCP location options and/or other location technologies that are specific to the type of access network, the operating system MUST provide a published API conforming to ED-12 through ED-23 and ED-25 through ED-32. It is RECOMMENDED that all operating systems provide such an API.
ED-24：支持需要紧急呼叫定位的应用程序的操作系统不允许访问客户端应用程序使用DHCP定位选项和/或特定于接入网络类型的其他定位技术所需的第2层和第3层功能，操作系统必须提供符合ED-12至ED-23和ED-25至ED-32的已发布API。建议所有操作系统都提供这样的API。
If an endpoint is manually configured, the requirements in this section are not applicable.
如果手动配置端点，则本节中的要求不适用。
ED-25/INT-19: Endpoints SHOULD obtain location immediately after obtaining local network configuration information.
ED-25/INT-19：端点应在获取本地网络配置信息后立即获取位置。
ED-26/INT-20: If the device is configured to use DHCP for bootstrapping and does not use its own measurement to determine location, it MUST include both options for location acquisition (civic and geodetic), the option for LIS discovery, and the option for LoST discovery as defined in [RFC4776], [RFC6225], [RFC5986], and [RFC5223], respectively.
ED-26/INT-20：如果设备配置为使用DHCP进行引导，而不使用其自身的测量来确定位置，则其必须包括位置获取选项（公民和大地测量）、LIS发现选项以及[RFC4776]、[RFC6225]、[RFC5986]和[RFC5223]中定义的丢失发现选项。
ED-27/INT-21: If the device sends a DHCPINFORM message, it MUST include both options for location acquisition (civic and geodetic), the option for LIS discovery, and the option for LoST discovery as defined in [RFC4776], [RFC6225], [RFC5986], and [RFC5223], respectively.
ED-27/INT-21：如果设备发送DHCPINFORM消息，则必须包括位置获取选项（公民和大地测量）、LIS发现选项以及[RFC4776]、[RFC6225]、[RFC5986]和[RFC5223]中定义的丢失发现选项。
ED-28/INT-22: To minimize the effects of VPNs that do not allow packets to be sent via the native hardware interface rather than via the VPN tunnel, location configuration SHOULD be attempted before such tunnels are established.
ED-28/INT-22：为了最大限度地减少VPN（不允许通过本机硬件接口而不是VPN隧道发送数据包）的影响，应在建立此类隧道之前尝试位置配置。
ED-29/INT-23: Software that uses LCPs SHOULD locate and use the actual hardware network interface rather than a VPN tunnel interface to direct LCP requests to the LIS in the actual access network.
ED-29/INT-23：使用LCP的软件应定位并使用实际的硬件网络接口，而不是VPN隧道接口，以将LCP请求定向到实际接入网络中的LIS。
AN-16: Network administrators MUST take care in assigning IP addresses such that VPN address assignments can be distinguished from local devices (by subnet choice, for example), and LISs SHOULD NOT attempt to provide location to addresses that arrive via VPN connections unless they can accurately determine the location for such addresses.
AN-16：网络管理员在分配IP地址时必须小心，以便VPN地址分配可以与本地设备区分开来（例如，通过子网选择），LISs不应尝试为通过VPN连接到达的地址提供位置，除非他们能够准确确定此类地址的位置。
AN-17: Placement of NAT devices where an LCP uses an IP address for an identifier SHOULD consider the effect of the NAT on the LCP. The address used to query the LIS MUST be able to correctly identify the record in the LIS representing the location of the querying device.
AN-17：放置一个LCP使用一个IP地址的标识符的NAT设备应该考虑NAT对LCP的影响。用于查询LIS的地址必须能够正确识别LIS中表示查询设备位置的记录。
ED-30/INT-24: For devices that are not expected to change location, refreshing location on the order of once per day is RECOMMENDED.
ED-30/INT-24：对于预计不会更改位置的设备，建议每天刷新一次位置。
ED-31/INT-25: For devices that roam, refresh of location information SHOULD be more frequent, with the frequency related to the mobility of the device and the ability of the access network to support the refresh operation. If the device detects a link state change that might indicate having moved, for example, when it changes access points, the device SHOULD refresh its location.
ED-31/INT-25：对于漫游的设备，位置信息的刷新应该更频繁，其频率与设备的移动性和接入网络支持刷新操作的能力有关。如果设备检测到可能指示已移动的链路状态更改，例如，当设备更改访问点时，设备应刷新其位置。
ED-32/INT-26/AN-18: It is RECOMMENDED that location determination not take longer than 250 ms to obtain routing location, and systems SHOULD be designed such that the typical response time is under 100 ms. However, as much as 3 seconds to obtain routing location MAY be tolerated if location accuracy can be substantially improved over what can be obtained in 250 ms.
ED-32/INT-26/AN-18：建议位置确定所需时间不超过250 ms，以获得路由位置，并且系统的设计应确保典型响应时间低于100 ms。但是，如果定位精度可以比250毫秒内获得的定位精度大幅度提高，则可以容忍3秒钟的时间来获得路由位置。
ED-33/SP-15: Location sent between SIP entities MUST be conveyed using the extension described in [RFC6442].
ED-33/SP-15：SIP实体之间发送的位置必须使用[RFC6442]中描述的扩展进行传输。
ED-34/AN-19: Where the absolute location or the accuracy of location of the endpoint may change between the time the call is received at the PSAP and the time dispatch is completed, location update mechanisms MUST be implemented and used.
ED-34/AN-19：如果在PSAP接收呼叫和完成调度之间，端点的绝对位置或位置精度可能发生变化，则必须实施和使用位置更新机制。
ED-35/AN-20: Mobile devices MUST be provided with a mechanism to get repeated location updates to track the motion of the device during the complete processing of the call.
ED-35/AN-20：必须为移动设备提供一种机制，以获得重复的位置更新，从而在整个呼叫处理过程中跟踪设备的运动。
ED-36/AN-21: The LIS SHOULD provide a location reference that permits a subscription with appropriate filtering.
ED-36/AN-21：LIS应提供一个位置参考，允许通过适当过滤进行订阅。
ED-37/AN-22: For calls sent with location-by-reference, with a SIP or Session Initiation Protocol Secure (SIPS) scheme, the server resolving the reference MUST support a SUBSCRIBE [RFC6665] to the presence event [RFC3856]. For other location-by-reference schemes that do not support subscription, the PSAP will have to repeatedly dereference the URI to determine if the device moved.
ED-37/AN-22：对于使用SIP或会话启动协议安全（SIPS）方案通过引用位置发送的呼叫，解析引用的服务器必须支持对存在事件[RFC3856]的订阅[RFC6665]。对于不支持订阅的其他按引用定位方案，PSAP必须反复取消对URI的引用，以确定设备是否移动。
ED-38: If location was sent by value and the endpoint gets an updated location, it MUST send the updated location to the PSAP via a SIP re-INVITE or UPDATE request. Such updates SHOULD be limited to no more than one update every 10 seconds, a value selected to keep the load on a large PSAP manageable, and yet provide sufficient indication to the PSAP of motion.
ED-38：如果位置是按值发送的，并且端点获得了更新的位置，那么它必须通过SIP重新邀请或更新请求将更新的位置发送给PSAP。此类更新应限制为每10秒不超过一次更新，选择该值以保持大型PSAP上的负载可管理，同时向PSAP提供足够的运动指示。
ED-39/SP-16: If the LIS has more than one location for an endpoint, it MUST conform to the rules in Section 3 of [RFC5491].
ED-39/SP-16：如果LIS具有多个端点位置，则必须符合[RFC5491]第3节中的规则。
ED-40: If an endpoint has more than one location available to it, it MUST choose one location to route the call towards the PSAP. If multiple locations are in a single Presence Information Data Format (PIDF), the procedures in [RFC5491] MUST be followed. If the endpoint has multiple PIDFs and has no reasonable basis to choose from among them, a random choice is acceptable.
ED-40：如果端点有多个可用位置，它必须选择一个位置将呼叫路由到PSAP。如果多个位置采用单一状态信息数据格式（PIDF），则必须遵循[RFC5491]中的程序。如果端点有多个PIDF，并且没有从中选择的合理依据，则可以接受随机选择。
SP-17: If a proxy inserts location on behalf of an endpoint and it has multiple locations available for the endpoint, it MUST choose one location to use to route the call towards the PSAP. If multiple locations are in a single PIDF, the procedures in [RFC5491] MUST be followed. If the proxy has multiple PIDFs and has no reasonable basis to choose from among them, a random choice is acceptable.
SP-17：如果代理代表端点插入位置，并且该端点有多个可用位置，则必须选择一个位置用于将呼叫路由到PSAP。如果一个PIDF中有多个位置，则必须遵循[RFC5491]中的程序。如果代理有多个PIDF，并且没有从中选择的合理依据，则可以接受随机选择。
SP-18: If a proxy is attempting to insert location but the endpoint conveyed a location to it, the proxy MUST use the endpoint's location for routing in the initial INVITE and MUST convey that location towards the PSAP. It MAY also include what it believes the location to be in a separate Geolocation header.
SP-18：如果代理试图插入位置，但端点向其传递了位置，则代理必须在初始邀请中使用端点的位置进行路由，并且必须向PSAP传递该位置。它还可以包括它认为该位置在单独的地理位置标头中的内容。
SP-19: All location objects received by a proxy MUST be delivered to the PSAP.
SP-19:代理收到的所有位置对象都必须传递到PSAP。
ED-41/SP-20: Location objects MUST be created with information about the method by which the location was determined, such as GPS, manually entered, or based on access network topology included in a PIDF-LO "method" element. In addition, the source of the location information MUST be included in a PIDF-LO "provided-by" element.
ED-41/SP-20：必须使用有关确定位置的方法的信息创建位置对象，如GPS、手动输入或基于包含在PIDF-LO“方法”元素中的接入网络拓扑。此外，位置信息源必须包含在PIDF-LO“提供人”元素中。
ED-42/SP-21: A location with a method of "derived" MUST NOT be used unless no other location is available.
ED-42/SP-21：除非没有其他位置可用，否则不得使用具有“衍生”方法的位置。
AN-23: A LIS SHOULD perform location validation of civic locations via LoST before entering a location in its database.
AN-23:LIS应在其数据库中输入位置之前，通过LoST对城市位置进行位置验证。
ED-43: Endpoints SHOULD validate civic locations when they receive them from their LCP. Validation SHOULD be performed in conjunction with the LoST route query to minimize load on the LoST server.
ED-43：当端点从其LCP接收到城市位置时，应验证这些位置。验证应与丢失路由查询一起执行，以最小化丢失服务器上的负载。
AN-24: When the access network cannot determine the actual location of the caller, it MUST supply a default location. The default SHOULD be chosen to be as close to the probable location of the device as the network can determine. See [RFC6443].
AN-24：当接入网络无法确定呼叫者的实际位置时，它必须提供一个默认位置。默认值应选择为尽可能接近网络可以确定的设备可能位置。见[RFC6443]。
SP-22: Proxies handling emergency calls MUST insert a default location in the INVITE if the incoming INVITE does not contain a location and the proxy does not have a method for obtaining a better location.
SP-22：如果传入的INVITE不包含位置，并且代理没有获得更好位置的方法，则处理紧急呼叫的代理必须在INVITE中插入默认位置。
AN-25/SP-23: Default locations MUST be marked with method=Default, and the proxy MUST be identified in a PIDF-LO "provided-by" element.
AN-25/SP-23：必须使用method=Default标记默认位置，并且必须在PIDF-LO“提供人”元素中标识代理。
ED-44: If the LCP does not return location in the form of a PIDF-LO [RFC4119], the endpoint MUST map the location information it receives from the configuration protocol to a PIDF-LO.
ED-44：如果LCP没有以PIDF-LO[RFC4119]的形式返回位置，则端点必须将其从配置协议接收到的位置信息映射到PIDF-LO。
ED-45/AN-26: To prevent against spoofing of the DHCP server, entities implementing DHCP for location configuration SHOULD use DHCPv4 message authentication [RFC3118] or DHCPv6 message authentication [RFC3315], although the difficulty in providing appropriate credentials is significant.
ED-45/AN-26：为防止对DHCP服务器进行欺骗，实施DHCP进行位置配置的实体应使用DHCPv4消息身份验证[RFC3118]或DHCPv6消息身份验证[RFC3315]，尽管提供适当凭据的难度很大。
ED-46: If S/MIME [RFC5751] is used, the INVITE message MUST provide enough information unencrypted for intermediate proxies to route the call based on the location information included. This would include the Geolocation header and any bodies containing location information. Use of S/MIME with emergency calls is NOT RECOMMENDED for this reason.
ED-46：如果使用S/MIME[RFC5751]，则INVITE消息必须提供足够的未加密信息，以便中间代理根据包含的位置信息路由呼叫。这将包括地理位置标题和包含位置信息的任何主体。因此，不建议在紧急呼叫中使用S/MIME。
ED-47/SP-24: Transport Layer Security (TLS) [RFC5746] MUST be used to protect location (but see Section 9.1). All SIP implementations of this specification MUST support TLS.
ED-47/SP-24：传输层安全（TLS）[RFC5746]必须用于保护位置（但请参见第9.1节）。本规范的所有SIP实现必须支持TLS。
ED-48: Endpoints MUST support one or more mechanisms that allow them to determine their public IP address, for example, Session Traversal Utilities for NAT (STUN) [RFC5389].
ED-48：端点必须支持一个或多个机制，允许它们确定其公共IP地址，例如NAT的会话遍历实用程序（STUN）[RFC5389]。
ED-49: Endpoints MUST support LIS discovery as described in [RFC5986] and LoST discovery as described in [RFC5223].
ED-49：端点必须支持[RFC5986]中所述的LIS发现和[RFC5223]中所述的丢失发现。
ED-50: The device MUST have a configurable default LoST server parameter.
ED-50：设备必须具有可配置的默认丢失服务器参数。
ED-51: DHCP LoST discovery MUST be used, if available, in preference to configured LoST servers. That is, the endpoint MUST send queries to this LoST server first, using other LoST servers only if these queries fail.
ED-51:必须使用DHCP丢失查找（如果可用），而不是配置的丢失服务器。也就是说，端点必须首先将查询发送到此丢失的服务器，只有在这些查询失败时才使用其他丢失的服务器。
AN-27: Access networks that support DHCP MUST implement the LIS and LoST discovery options in their DHCP servers and return suitable server addresses as appropriate.
AN-27：支持DHCP的接入网络必须在其DHCP服务器中实现LIS和丢失发现选项，并根据需要返回适当的服务器地址。
ED-52: Endpoints that obtain their own location SHOULD perform LoST mapping to the PSAP URI.
ED-52：获取自己位置的端点应该执行到PSAP URI的丢失映射。
ED-53: Mapping SHOULD be performed at boot time and whenever a location changes beyond the service boundary obtained from a prior LoST mapping operation, or when the time-to-live value of that response has expired. The value MUST be cached for possible later use.
ED-53：应在启动时以及当某个位置更改超过先前丢失映射操作获得的服务边界时，或者当响应的生存时间值过期时，执行映射。必须缓存该值，以便以后可能使用。
ED-54: The endpoint MUST attempt to update its location at the time of an emergency call. If it cannot obtain a new location quickly (see Section 6), it MUST use the cached value.
ED-54：端点必须在紧急呼叫时尝试更新其位置。如果无法快速获取新位置（参见第6节），则必须使用缓存的值。
ED-55: The endpoint SHOULD attempt to update the LoST mapping at the time of an emergency call. If it cannot obtain a new mapping quickly, it MUST use the cached value. If the device cannot update the LoST mapping and does not have a cached value, it MUST signal an emergency call without a Route header containing a PSAP URI.
ED-55：端点应在紧急呼叫时尝试更新丢失的映射。如果无法快速获得新映射，则必须使用缓存的值。如果设备无法更新丢失的映射并且没有缓存值，则必须在没有包含PSAP URI的路由头的情况下发出紧急呼叫信号。
SP-25: Networks MUST be designed so that at least one proxy in the outbound path will recognize emergency calls with a Request URI of the service URN in the "sos" tree. An endpoint places a service URN in the Request URI to indicate that the endpoint understood the call was an emergency call. A proxy that processes such a call looks for the presence of a SIP Route header field with a URI of a PSAP. The absence of such a Route header indicates that the endpoint was unable to invoke LoST, and the proxy MUST perform the LoST mapping and insert a Route header field with the URI obtained.
SP-25：网络的设计必须确保出站路径中至少有一个代理能够识别“sos”树中带有服务URN请求URI的紧急呼叫。端点在请求URI中放置一个服务URN，以指示端点理解该调用是一个紧急调用。处理此类调用的代理将查找是否存在URI为PSAP的SIP路由头字段。缺少这样的路由头表示端点无法调用LoST，代理必须执行LoST映射并插入一个包含已获取URI的路由头字段。
SP-26: To deal with old user agents that predate this specification and with endpoints that do not have access to their own location data, a proxy that recognizes a call as an emergency call that is not marked as such (see Section 5) MUST also perform this mapping, with the best location it has available for the endpoint. The resulting PSAP URI would be placed in a Route header with the service URN in the Request URI.
SP-26：为了处理早于本规范的旧用户代理以及无法访问其自身位置数据的端点，将呼叫识别为未标记为紧急呼叫（参见第5节）的代理也必须使用其可用于端点的最佳位置执行此映射。生成的PSAP URI将放置在路由头中，服务URN位于请求URI中。
SP-27: Proxy servers performing mapping SHOULD use location obtained from the access network for the mapping. If no location is available, a default location (see Section 6.11) MUST be supplied.
SP-27:执行映射的代理服务器应使用从访问网络获取的位置进行映射。如果没有可用位置，则必须提供默认位置（见第6.11节）。
SP-28: A proxy server that attempts mapping and fails to get a mapping MUST provide a default mapping. A suitable default mapping would be the mapping obtained previously for the default location appropriate for the caller.
SP-28:尝试映射但未能获取映射的代理服务器必须提供默认映射。一个合适的默认映射是先前为适合调用者的默认位置获得的映射。
ED-56/SP-29: [RFC3261] and [RFC3263] procedures MUST be used to route an emergency call towards the PSAP's URI.
ED-56/SP-29:[RFC3261]和[RFC3263]程序必须用于将紧急呼叫路由到PSAP的URI。
ED-57/SP-30: TLS is the primary mechanism used to secure the signaling for emergency calls. IPsec [RFC4301] MAY be used instead of TLS for any hop. Either TLS or IPsec MUST be used when attempting to signal an emergency call.
ED-57/SP-30:TLS是用于保护紧急呼叫信号的主要机制。对于任何跃点，可以使用IPsec[RFC4301]代替TLS。当试图发出紧急呼叫信号时，必须使用TLS或IPsec。
ED-58/SP-31: If TLS session establishment is not available or fails, the call MUST be retried without TLS.
ED-58/SP-31：如果TLS会话建立不可用或失败，则必须在没有TLS的情况下重试呼叫。
ED-59/SP-32: Following the procedures described in [RFC5626] is RECOMMENDED to maintain persistent TLS connections between entities when one of the entities is an endpoint. Persistent TLS connection between proxies is RECOMMENDED using any suitable mechanism.
ED-59/SP-32：当其中一个实体是端点时，建议遵循[RFC5626]中描述的程序，以保持实体之间的持久TLS连接。建议使用任何合适的机制在代理之间建立持久的TLS连接。
ED-60/AN-28: TLS SHOULD be used when attempting to retrieve location (configuration or dereferencing) with HELD. The use of the mechanism described in [RFC5077] is RECOMMENDED to minimize the time to establish TLS sessions without keeping server-side state. IPsec MAY be used instead of TLS.
ED-60/AN-28：尝试检索位置（配置或取消引用）时，应使用TLS。建议使用[RFC5077]中描述的机制，以便在不保持服务器端状态的情况下尽可能缩短建立TLS会话的时间。可以使用IPsec代替TLS。
ED-61/AN-29: When TLS session establishment fails, the location retrieval MUST be retried without TLS.
ED-61/AN-29：当TLS会话建立失败时，必须在没有TLS的情况下重试位置检索。
ED-62: The initial SIP signaling method is an INVITE request:
ED-62：初始SIP信令方法是INVITE请求：
1. The Request URI SHOULD be the service URN in the "sos" tree. If the device does not interpret local dial strings, the Request-URI MUST be a dial string URI [RFC4967] with the dialed digits.
1. 请求URI应该是“sos”树中的服务URN。如果设备不解释本地拨号字符串，则请求URI必须是带有拨号数字的拨号字符串URI[RFC4967]。
2. The To header field SHOULD be a service URN in the "sos" tree. If the device does not interpret local dial strings, the To: MUST be a dial string URI with the dialed digits.
2. “收件人”标题字段应为“sos”树中的服务URN。如果设备不解释本地拨号字符串，则To:必须是带有拨号数字的拨号字符串URI。
3. The From header field SHOULD contain the address of record (AoR) of the caller.
3. From标头字段应包含调用者的记录地址（AoR）。
4. A Route header field SHOULD be present with a PSAP URI obtained from LoST (see Section 8). If the device does not interpret dial plans or was unable to obtain a route from a LoST server, no such Route header field will be present.
4. Route header字段应该包含从LoST获得的PSAP URI（参见第8节）。如果设备不解释拨号计划或无法从丢失的服务器获取路由，则不存在此类路由头字段。
5. A Contact header field MUST be globally routable, for example, a Globally Routable User Agent URI (GRUU) [RFC5627], and be valid for several minutes following the termination of the call, provided that the User Agent Client (UAC) remains registered with the same registrar, to permit an immediate callback to the specific device that placed the emergency call. It is acceptable if the UAC inserts a locally routable URI and a subsequent back-to-back user agent (B2BUA) maps that to a globally routable URI.
5. 联系人标头字段必须是全局可路由的，例如，全局可路由的用户代理URI（GRUU）[RFC5627]，并且在呼叫终止后的几分钟内有效，前提是用户代理客户端（UAC）仍在同一注册器中注册，允许立即回拨到拨打紧急呼叫的特定设备。如果UAC插入一个本地可路由URI，并且随后的背对背用户代理（B2BUA）将其映射到一个全局可路由URI，这是可以接受的。
6. Other header fields MAY be included as per normal SIP behavior.
6. 根据正常的SIP行为，可以包括其他头字段。
7. If a geolocation URI is included in the INVITE, a Supported header field MUST be included with a 'geolocation-sip' or 'geolocation-http" option tag, as appropriate [RFC6442].
7. 如果邀请中包含地理位置URI，则“地理位置sip”或“地理位置http”选项标记（视情况而定）中必须包含受支持的标题字段[RFC6442]。
8. If a device understands the SIP location conveyance [RFC6442] extension and has its location available, it MUST include location as either location-by-value or location-by-reference, or both, according to the rules within RFC 6442.
8. 如果设备理解SIP位置传输[RFC6442]扩展，并且其位置可用，则根据RFC 6442中的规则，必须将位置包括为按值定位或按引用定位，或两者兼而有之。
9. An SDP offer SHOULD be included in the INVITE. If voice is supported, the offer SHOULD include the G.711 codec; see Section 14. As PSAPs may support a wide range of media types and codecs, sending an offerless INVITE may result in a lengthy return offer but is permitted. Cautions in [RFC3261] on offerless INVITEs should be considered before such use.
9. 邀请中应包括SDP报价。如果支持语音，则报价应包括G.711编解码器；见第14节。由于PSAP可能支持多种媒体类型和编解码器，发送无报价邀请可能会导致漫长的回馈报价，但这是允许的。在使用之前，应考虑[RFC3261]中关于无要约邀请的注意事项。
10. If the device includes location-by-value, the user agent (UA) MUST support multipart message bodies, since SDP will likely be also in the INVITE.
10. 如果设备包括按值定位，则用户代理（UA）必须支持多部分消息正文，因为SDP可能也在INVITE中。
SP-33: SIP proxy servers processing emergency calls:
SP-33:处理紧急呼叫的SIP代理服务器：
1. If the proxy interprets dial plans on behalf of user agents, the proxy MUST look for the local emergency dial string at the location of the end device and MAY look for the home dial string. If it finds it, the proxy MUST:
1. 如果代理代表用户代理解释拨号计划，则代理必须在终端设备的位置查找本地紧急拨号字符串，并可能查找家庭拨号字符串。如果找到，代理必须：
* Insert a Geolocation header field. Location-by-reference MUST be used because proxies are not allowed to insert bodies.
* 插入地理位置标题字段。必须使用引用位置，因为不允许代理插入实体。
* Insert the Geolocation-Routing header with appropriate parameters.
* 插入带有适当参数的地理位置路由标头。
* Map the location to a PSAP URI using LoST.
* 使用LoST将位置映射到PSAP URI。
* Add a Route header with the PSAP URI.
* 添加带有PSAP URI的路由头。
* Replace the Request-URI, which was the dial string, with the service URN appropriate for the emergency dial string.
* 将请求URI（即拨号字符串）替换为适用于紧急拨号字符串的服务URN。
* Route the call using normal SIP routing mechanisms.
* 使用普通SIP路由机制路由呼叫。
2. If the proxy recognizes the service URN in the Request URI and does not find a Route header, it MUST query a LoST server immediately. If a location was provided (which should be the case), the proxy uses that location to query LoST. The proxy may have to dereference a location-by-reference to get a value. If a location is not present and the proxy can query a LIS that has the location of the UA, it MUST do so. If no location is present and the proxy does not have access to a LIS that could provide location, the proxy MUST supply a default location (see Section 6.11). The location (in the signaling, obtained from a LIS, or default) MUST be used in a query to LoST with the service URN received with the call. The resulting URI MUST be placed in a Route header added to the call.
2. 如果代理在请求URI中识别出服务URN，但未找到路由头，则必须立即查询丢失的服务器。如果提供了一个位置（应该是这样），代理将使用该位置查询LoST。代理可能必须通过引用解除对位置的引用才能获得值。如果位置不存在，并且代理可以查询具有UA位置的LIS，则必须这样做。如果不存在位置，且代理无法访问可提供位置的LIS，则代理必须提供默认位置（见第6.11节）。在查询中必须使用位置（在信令中，从LIS获取，或默认位置），以便丢失与呼叫一起接收的服务URN。结果URI必须放在添加到调用的路由头中。
3. The proxy MAY add a Geolocation header field. Such an additional location SHOULD NOT be used for routing; the location provided by the UA should be used.
3. 代理可以添加地理位置标头字段。此类附加位置不应用于路由；应使用UA提供的位置。
4. Either a P-Asserted-Identity [RFC3325] or an Identity header field [RFC4474], or both, SHOULD be included to identify the sender. For services that must support emergency calls from unauthenticated devices, valid identity may not be available. Proxies encountering a P-Asserted-Identity will need to pass the header to the PSAP, which is in a different domain. [RFC3325] requires a "spec(T)" to determine what happens if either the "id" privacy service or a Privacy header is present and requests privacy. In the absence of another spec(T), such proxies should pass the header unmodified if and only if the connection between the proxy and the PSAP is, as far as the proxy can determine, protected by TLS with mutual authentication using keys reliably known by the parties, encrypted with no less strength than AES, and the local regulations governing the PSAP do not specify otherwise.
4. 应包括P-Asserted-Identity[RFC3325]或Identity header字段[RFC4474]或两者，以识别发送方。对于必须支持来自未经验证设备的紧急呼叫的服务，可能无法使用有效标识。遇到P-Asserted-Identity的代理将需要将头传递给位于不同域中的PSAP。[RFC3325]需要一个“规范（T）”来确定如果存在“id”隐私服务或隐私标头并请求隐私，会发生什么。在没有其他规范（T）的情况下，如果且仅当代理和PSAP之间的连接受TLS保护，并且使用双方可靠知道的密钥进行相互认证，加密强度不低于AES，则此类代理应在未修改的情况下通过报头，管理PSAP的地方法规没有另行规定。
5. Proxies SHOULD NOT return a 424 error. They should process the INVITE as best they can.
5. 代理不应返回424错误。他们应该尽可能地处理邀请。
6. Proxies SHOULD NOT obey a Geolocation-Routing value of "no" or a missing value if they must query LoST to obtain a route. Emergency calls are always routed by location.
6. 代理不应遵守地理位置路由值“否”或缺失值（如果必须查询丢失以获取路由）。紧急呼叫总是按位置路由。
ED-63/SP-34: Devices SHOULD have a globally routable URI in a Contact header field that remains valid for several minutes past the time the original call containing the URI completes, unless the device registration expires and is not renewed.
ED-63/SP-34：设备应在联系人标头字段中具有全局可路由URI，该URI在包含URI的原始调用完成后的几分钟内保持有效，除非设备注册过期且未续订。
SP-35: Callbacks to the Contact header URI received within 30 minutes of an emergency call must reach the device regardless of call features (e.g., do not disturb) or services (e.g., call forwarding) that would normally cause the call to be routed to some other entity.
SP-35：紧急呼叫30分钟内收到的对联系人标头URI的回调必须到达设备，而不管呼叫功能（如请勿打扰）或服务（如呼叫转接）通常会导致呼叫路由到其他实体。
SP-36: Devices MUST have a persistent AoR URI either in a P-Asserted-Identity header field or From protected by an Identity header field suitable for returning a call sometime after the original call. Such a callback would not necessarily reach the device that originally placed the call.
SP-36：设备必须在P-Asserted-Identity报头字段中具有持久的AoR URI，或者由适合于在原始呼叫后某个时间返回呼叫的Identity报头字段保护。这样的回调不一定会到达最初进行调用的设备。
ED-64/SP-37: During the course of an emergency call, PSAPs and responders may need to transfer the call to some other entity. The request for such a transfer is signaled by a REFER request within the dialog with method=INVITE and a Refer-To header field [RFC3515]. Devices MUST react to such a transfer request with the appropriate INVITE.
ED-64/SP-37：在紧急呼叫过程中，PSAP和响应者可能需要将呼叫转移到其他实体。此类传输的请求由对话框中的REFER请求发出信号，该对话框的方法=INVITE，并有REFER REFER头字段[RFC3515]。设备必须以适当的INVITE响应此类传输请求。
ED-65: Normal [RFC3261] procedures for termination MUST be used for termination of the call.
ED-65：呼叫终止必须使用正常的[RFC3261]终止程序。
ED-66/SP-38: User agents and proxies MUST disable features that will interrupt an ongoing emergency call, such as:
ED-66/SP-38：用户代理和代理必须禁用将中断正在进行的紧急呼叫的功能，例如：
o Call waiting
o 呼叫等待
o Call transfer
o 呼叫转移
o Three-way call
o 三方通话
o Hold
o 持有
o Outbound call blocking
o 出站呼叫阻塞
when an emergency call is established, but see ED-65 with respect to call waiting. Also see ED-73 in Section 14.
当建立紧急呼叫时，但有关呼叫等待，请参阅ED-65。另见第14节中的ED-73。
ED-67/SP-39: The emergency dial strings SHOULD NOT be permitted in call forward numbers or speed dial lists.
ED-67/SP-39：呼叫转接号码或快速拨号列表中不允许使用紧急拨号串。
ED-68/SP-40: The user agent and proxies MUST disable call features that would interfere with the ability of callbacks from the PSAP to be completed, such as:
ED-68/SP-40：用户代理和代理必须禁用会干扰PSAP回调功能的呼叫功能，例如：
o Do not disturb
o 请勿打扰
o Call forward (all kinds)
o 呼叫转发（各种）
These features SHOULD be disabled for approximately 30 minutes following termination of an emergency call.
紧急呼叫终止后，这些功能应禁用约30分钟。
ED-69: Callbacks SHOULD be determined by retaining the domain of the PSAP that answers an outgoing emergency call and instantiating a timer that starts when the call is terminated. If a call is received from the same domain and within the timer period, and it is sent to the URI in a Contact header or the AoR used in the emergency call, then it should be assumed to be a callback. The suggested timer period is 5 minutes. The mechanism described in [RFC4916] can be used by the PSAP to inform the endpoint of the PSAP's domain. Recognizing a callback from the domain of the PSAP will not always work, and further standardization will be required to give the endpoint the ability to recognize a callback.
ED-69：回调应该通过保留应答传出紧急呼叫的PSAP域并实例化在呼叫终止时启动的计时器来确定。如果在计时器周期内从同一域接收到呼叫，并将其发送到联系人标头中的URI或紧急呼叫中使用的AoR，则应假定该呼叫为回调。建议的计时器周期为5分钟。[RFC4916]中描述的机制可由PSAP用于通知PSAP域的端点。识别来自PSAP域的回调并不总是有效的，需要进一步的标准化来赋予端点识别回调的能力。
ED-70: Endpoints MUST send and receive media streams on RTP [RFC3550].
ED-70：端点必须在RTP[RFC3550]上发送和接收媒体流。
ED-71: Normal SIP offer/answer [RFC3264] negotiations MUST be used to agree on the media streams to be used.
ED-71：必须使用正常的SIP提供/应答[RFC3264]协商来商定要使用的媒体流。
ED-72/SP-41: G.711 A-law (and mu-law if they are intended to be used in North America) encoded voice as described in [RFC3551] MUST be supported. If the endpoint cannot support G.711, a transcoder MUST be used so that the offer received at the PSAP contains G.711. It is desirable to include wideband codecs such as G.722 and Adaptive Multi-Rate - WideBand (AMR-WB) in the offer. PSAPs SHOULD support narrowband codecs common on endpoints in their area to avoid transcoding.
ED-72/SP-41:G.711 A-law（和mu-law，如果打算在北美使用）必须支持[RFC3551]中所述的编码语音。如果端点不能支持G.711，则必须使用转码器，以便在PSAP上收到的报价包含G.711。希望在产品中包括宽带编解码器，如G.722和自适应多速率宽带（AMR-WB）。PSAP应支持其所在区域端点上常见的窄带编解码器，以避免转码。
ED-73: Silence suppression (Voice Activity Detection methods) MUST NOT be used on emergency calls. PSAP call takers sometimes get information on what is happening in the background to determine how to process the call.
ED-73：紧急呼叫不得使用静音抑制（语音活动检测方法）。PSAP呼叫接受者有时会获取后台正在发生的事情的信息，以确定如何处理呼叫。
ED-74: Endpoints supporting Instant Messaging (IM) MUST support either [RFC3428] or [RFC4975].
ED-74：支持即时消息（IM）的端点必须支持[RFC3428]或[RFC4975]。
ED-75: Endpoints supporting real-time text MUST comply with [RFC4103]. The expectations for emergency service support for the real-time text medium are described in [RFC5194] Section 7.1.
ED-75：支持实时文本的端点必须符合[RFC4103]。[RFC5194]第7.1节描述了对实时文本媒体的应急服务支持的期望。
ED-76: Endpoints supporting video MUST support H.264 per [RFC6184].
ED-76：根据[RFC6184]，支持视频的端点必须支持H.264。
ED-77: INVITE requests to a service URN starting with "test." indicate a request for an automated test, for example, "urn:service:test.sos.fire". As in standard SIP, a 200 (OK) response indicates that the address was recognized and a 404 (not found) that it was not. A 486 (busy here) MUST be returned if the test service is busy, and a 404 (not found) MUST be returned if the PSAP does not support the test mechanism.
ED-77:INVITE对以“test”开头的服务URN的请求。表示对自动测试的请求，例如，“URN:service:test.sos.fire”。在标准SIP中，200（正常）响应表示该地址已被识别，404（未找到）响应表示该地址未被识别。如果测试服务繁忙，则必须返回486（此处繁忙），如果PSAP不支持测试机制，则必须返回404（未找到）。
ED-78: In its response to the test, the PSAP MAY include a text body (text/plain) indicating the identity of the PSAP, the requested service, and the location reported with the call. For the latter, the PSAP SHOULD return location-by-value even if the original location delivered with the test was location-by-reference. If the location-by-reference was supplied and the dereference requires credentials, the PSAP SHOULD use credentials supplied by the LIS for test purposes. This alerts the LIS that the dereference is not for an actual emergency call, and therefore location-hiding techniques, if they are being used, may be employed for this dereference. Use of SIPS for the request would assure that the response containing the location is kept private.
ED-78：在对测试的响应中，PSAP可能包括一个文本正文（text/plain），指示PSAP的身份、请求的服务以及呼叫报告的位置。对于后者，PSAP应该按值返回location，即使测试附带的原始位置是location by reference。如果提供了引用位置，且取消引用需要凭据，则PSAP应使用LIS提供的凭据进行测试。这会提醒LIS取消引用不是用于实际的紧急呼叫，因此，如果正在使用位置隐藏技术，则可用于此取消引用。对请求使用SIP将确保包含该位置的响应是保密的。
ED-79: A PSAP accepting a test call SHOULD accept a media loopback [RFC6849] test and SHOULD support the "rtp-pkt-loopback" and "rtp-media-loopback" options. The user agent would specify a loopback attribute of "loopback-source", the PSAP being the mirror. User agents should expect the PSAP to loop back no more than 3 packets of each media type accepted (which limits the duration of the test), after which the PSAP would normally send BYE.
ED-79：接受测试调用的PSAP应接受媒体环回[RFC6849]测试，并应支持“rtp pkt环回”和“rtp媒体环回”选项。用户代理将指定“loopback source”的loopback属性，PSAP是镜像。用户代理应该期望PSAP回送不超过3个接受的每种媒体类型的数据包（这限制了测试的持续时间），之后PSAP通常会发送BYE。
ED-80: User agents SHOULD perform a full call test, including media loopback, after a disconnect and subsequent change in IP address not due to a reboot. After an initial test, a full test SHOULD be repeated approximately every 30 days with a random interval.
ED-80：用户代理应在断开连接后执行完整的呼叫测试，包括媒体环回，并随后更改IP地址（不是由于重新启动）。初始试验后，应大约每隔30天以随机间隔重复一次完整试验。
ED-81: User agents MUST NOT place a test call immediately after booting. If the IP address changes after booting, the endpoint should wait a random amount of time (in perhaps a 30-minute period, sufficient for any avalanche-restart event to complete) and then test.
ED-81：用户代理不能在启动后立即进行测试调用。如果IP地址在引导后发生变化，端点应随机等待一段时间（可能在30分钟内，足以让任何雪崩重启事件完成），然后进行测试。
ED-82: PSAPs MAY refuse repeated requests for test from the same device in a short period of time. Any refusal is signaled with a 486 (busy here) or 488 (not acceptable here) response.
ED-82:PSAP可能会在短时间内拒绝来自同一设备的重复测试请求。任何拒绝都会以486（此处忙）或488（此处不可接受）响应发出信号。
Security considerations for emergency calling have been documented in [RFC5069] and [RFC6280]. This document suggests that security (TLS or IPsec) be used hop by hop on a SIP call to protect location information, identity, etc. It also suggests that if the attempt to create a security association fails the call be retried without the security. It's more important to get an emergency call through than to protect the data; indeed, in many jurisdictions privacy is explicitly waived when making emergency calls. Placing a call without security may reveal user information, including location. The alternative -- failing the call if security cannot be established -- is considered unacceptable.
[RFC5069]和[RFC6280]中记录了紧急呼叫的安全注意事项。本文档建议在SIP呼叫中逐跳使用安全性（TLS或IPsec），以保护位置信息、身份等。它还建议，如果尝试创建安全关联失败，则在没有安全性的情况下重试呼叫。拨打紧急电话比保护数据更重要；事实上，在许多司法管辖区，拨打紧急电话时明确放弃隐私权。在没有安全保护的情况下拨打电话可能会泄露用户信息，包括位置。另一种选择——如果无法建立安全性，则调用失败——被认为是不可接受的。
This document registers service URNs in the Service URN Labels registry per [RFC5031] for testing.
本文档根据[RFC5031]在服务URN标签注册表中注册服务URN以进行测试。
A new entry in the URN Service Label registry has been added. The new service is "test", the reference is this document, and the description is "self-test".
已在URN服务标签注册表中添加新条目。新服务是“测试”，参考是本文档，描述是“自检”。
A new subregistry has been created: 'test' Sub-Services. The registration process is Expert Review per [RFC5226]. The expert review should consider that the entries in this registry nominally track the entries in the 'sos' subregistry, although it is not required that every entry in 'sos' have an entry in 'test', and it is possible that entries in the 'test' subregistry may not necessarily be in the 'sos' subregistry. For example, testing of non-emergency URNs may be allowed. The reference is this document. The initial content of the subregistry is:
已创建一个新的子域：“测试”子服务。根据[RFC5226]，注册过程为专家评审。专家评审应该考虑到这个注册表中的条目名义上跟踪“SOS”子注册表中的条目，尽管它并不要求“SOS”中的每个条目在“测试”中都有条目，并且“测试”子注册表中的条目可能不一定在“SOS”子注册表中。例如，可允许对非应急骨灰盒进行测试。参考文件为本文件。该分区域的初始内容为：
Service Reference Description
------------------------------------------------------------------
test.sos RFC 6881 test for sos
test.sos.ambulance RFC 6881 test for sos.ambulance
test.sos.animal-control RFC 6881 test for sos.animal-control
test.sos.fire RFC 6881 test for sos.fire
test.sos.gas RFC 6881 test for sos.gas
test.sos.marine RFC 6881 test for sos.marine
test.sos.mountain RFC 6881 test for sos.mountain
test.sos.physician RFC 6881 test for sos.physician
test.sos.poison RFC 6881 test for sos.poison
test.sos.police RFC 6881 test for sos.police
Service Reference Description
------------------------------------------------------------------
test.sos RFC 6881 test for sos
test.sos.ambulance RFC 6881 test for sos.ambulance
test.sos.animal-control RFC 6881 test for sos.animal-control
test.sos.fire RFC 6881 test for sos.fire
test.sos.gas RFC 6881 test for sos.gas
test.sos.marine RFC 6881 test for sos.marine
test.sos.mountain RFC 6881 test for sos.mountain
test.sos.physician RFC 6881 test for sos.physician
test.sos.poison RFC 6881 test for sos.poison
test.sos.police RFC 6881 test for sos.police
Working group members participating in the creation and review of this document include Hannes Tschofenig, Ted Hardie, Marc Linsner, Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom, Barbara Stark, Richard Barnes, and Peter Blatherwick.
参与本文件创建和审查的工作组成员包括汉内斯·茨霍芬尼、特德·哈迪、马克·林纳、罗杰·马歇尔、斯图·戈德曼、希达·舒伯特、詹姆斯·温特巴顿、芭芭拉·斯塔克、理查德·巴恩斯和彼得·布拉瑟威克。
[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月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118]Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[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月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，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月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[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月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856]Rosenberg，J.，“会话启动协议（SIP）的存在事件包”，RFC3856，2004年8月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[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月。
[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月。
[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月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916]Elwell，J.，“会话启动协议（SIP）中的连接身份”，RFC 4916，2007年6月。
[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月。
[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月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，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月。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
[RFC5746]Rescorla，E.，Ray，M.，Dispensa，S.，和N.Oskov，“传输层安全（TLS）重新协商指示扩展”，RFC 57462010年2月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[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月。
[RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, May 2011.
[RFC6184]Wang，Y.，Even，R.，Kristensen，T.，和R.Jesup，“H.264视频的RTP有效载荷格式”，RFC 6184，2011年5月。
[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月。
[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月。
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012.
[RFC6665]Roach，A.，“SIP特定事件通知”，RFC 66652012年7月。
[RFC6849] Kaplan, H., Ed., Hedayat, K., Venna, N., Jones, P., and N. Stratton, "An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback", RFC 6849, February 2013.
[RFC6849]Kaplan，H.，Ed.，Hedayat，K.，Venna，N.，Jones，P.，和N.Stratton，“媒体环回会话描述协议（SDP）和实时传输协议（RTP）的扩展”，RFC 6849，2013年2月。
[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月。
[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月。
[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月。
[RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)", RFC 5194, June 2008.
[RFC5194]van Wijk，A.和G.Gybels，“使用会话启动协议（SIP）的IP实时文本框架”，RFC 51942008年6月。
[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月。
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, December 2011.
[RFC6443]Rosen，B.，Schulzrinne，H.，Polk，J.，和A.Newton，“使用互联网多媒体进行紧急呼叫的框架”，RFC 64432011年12月。
Authors' Addresses
作者地址
Brian Rosen NeuStar 470 Conrad Dr. Mars, PA 16046 USA
布莱恩·罗森·纽斯塔470康拉德·马尔斯博士，宾夕法尼亚州，美国16046
Phone: +1 724 382 1051
EMail: br@brianrosen.net
Phone: +1 724 382 1051
EMail: br@brianrosen.net
James Polk Cisco Systems 3913 Treemont Circle Colleyville, TX 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