Internet Engineering Task Force (IETF) J. Polk
Request for Comments: 6442 Cisco Systems
Category: Standards Track B. Rosen
ISSN: 2070-1721 J. Peterson
NeuStar
December 2011
Internet Engineering Task Force (IETF) J. Polk
Request for Comments: 6442 Cisco Systems
Category: Standards Track B. Rosen
ISSN: 2070-1721 J. Peterson
NeuStar
December 2011
Location Conveyance for the Session Initiation Protocol
会话启动协议的位置传输
Abstract
摘要
This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target.
本文档定义了会话启动协议（SIP）的扩展，用于将地理位置信息从一个SIP实体传送到另一个SIP实体。SIP扩展包括端到端传输和基于位置的路由，其中SIP中介根据位置目标的位置做出路由决策。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6442.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6442.
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 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions and Terminology Used in This Document ...............4
3. Overview of SIP Location Conveyance .............................4
3.1. Location Conveyed by Value .................................4
3.2. Location Conveyed as a Location URI ........................5
3.3. Location Conveyed though a SIP Intermediary ................6
3.4. SIP Intermediary Replacing Bad Location ....................7
4. SIP Extensions for Geolocation Conveyance .......................8
4.1. The Geolocation Header Field ...............................8
4.2. The Geolocation-Routing Header Field ......................11
4.2.1. Explaining Geolocation-Routing Header-Value
States .............................................12
4.3. 424 (Bad Location Information) Response Code ..............14
4.4. The Geolocation-Error Header Field ........................15
4.5. Location URIs in Message Bodies ...........................19
4.6. Location Profile Negotiation ..............................19
5. Geolocation Examples ...........................................20
5.1. Location-by-Value (in Coordinate Format) ..................20
5.2. Two Locations Composed in Same Location Object Example ....21
6. Geopriv Privacy Considerations .................................23
7. Security Considerations ........................................24
8. IANA Considerations ............................................26
8.1. IANA Registration for the SIP Geolocation Header Field ....26
8.2. IANA Registration for the SIP Geolocation-Routing
Header Field ..............................................26
8.3. IANA Registration for Location Profiles ...................27
8.4. IANA Registration for 424 Response Code ...................27
8.5. IANA Registration of New Geolocation-Error Header Field ...28
8.6. IANA Registration for the SIP Geolocation-Error Codes .....28
9. Acknowledgements ...............................................29
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................31
Appendix A. Requirements for SIP Location Conveyance ..............32
1. Introduction ....................................................3
2. Conventions and Terminology Used in This Document ...............4
3. Overview of SIP Location Conveyance .............................4
3.1. Location Conveyed by Value .................................4
3.2. Location Conveyed as a Location URI ........................5
3.3. Location Conveyed though a SIP Intermediary ................6
3.4. SIP Intermediary Replacing Bad Location ....................7
4. SIP Extensions for Geolocation Conveyance .......................8
4.1. The Geolocation Header Field ...............................8
4.2. The Geolocation-Routing Header Field ......................11
4.2.1. Explaining Geolocation-Routing Header-Value
States .............................................12
4.3. 424 (Bad Location Information) Response Code ..............14
4.4. The Geolocation-Error Header Field ........................15
4.5. Location URIs in Message Bodies ...........................19
4.6. Location Profile Negotiation ..............................19
5. Geolocation Examples ...........................................20
5.1. Location-by-Value (in Coordinate Format) ..................20
5.2. Two Locations Composed in Same Location Object Example ....21
6. Geopriv Privacy Considerations .................................23
7. Security Considerations ........................................24
8. IANA Considerations ............................................26
8.1. IANA Registration for the SIP Geolocation Header Field ....26
8.2. IANA Registration for the SIP Geolocation-Routing
Header Field ..............................................26
8.3. IANA Registration for Location Profiles ...................27
8.4. IANA Registration for 424 Response Code ...................27
8.5. IANA Registration of New Geolocation-Error Header Field ...28
8.6. IANA Registration for the SIP Geolocation-Error Codes .....28
9. Acknowledgements ...............................................29
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................31
Appendix A. Requirements for SIP Location Conveyance ..............32
Session Initiation Protocol (SIP) [RFC3261] creates, modifies and terminates multimedia sessions. SIP carries certain information related to a session while establishing or maintaining calls. This document defines how SIP conveys geographic location information of a Target to a Location Recipient (LR). SIP acts as a Using Protocol of location information, as defined in RFC 3693.
会话启动协议（SIP）[RFC3261]创建、修改和终止多媒体会话。SIP在建立或维护呼叫时携带与会话相关的某些信息。本文档定义了SIP如何将目标的地理位置信息传递给位置接收者（LR）。SIP充当位置信息的使用协议，如RFC 3693中所定义。
In order to convey location information, this document specifies three new SIP header fields, Geolocation, Geolocation-Routing, and Geolocation-Error, which carry a reference to a Location Object (LO), grant permission to route a SIP request based on the location-value and provide error notifications specific to location errors, respectively. The Location Object (LO) may appear in a MIME body attached to the SIP request, or it may be a remote resource in the network.
为了传递位置信息，本文档指定了三个新的SIP头字段Geolocation、Geolocation Routing和Geolocation Error，它们携带对位置对象（LO）的引用，根据位置值授予路由SIP请求的权限，并分别提供特定于位置错误的错误通知。位置对象（LO）可能出现在附加到SIP请求的MIME主体中，或者它可能是网络中的远程资源。
A Target is an entity whose location is being conveyed, per RFC 3693. Thus, a Target could be a SIP user agent (UA), some other IP device (a router or a PC) that does not have a SIP stack, a non-IP device (a person or a black phone), or even a non-communications device (a building or store front). In no way does this document assume that the SIP user agent client that sends a request containing a location object is necessarily the Target. The location of a Target conveyed within SIP typically corresponds to that of a device controlled by the Target, for example, a mobile phone, but such devices can be separated from their owners, and moreover, in some cases, the user agent may not know its own location.
根据RFC 3693，目标是其位置正在传送的实体。因此，目标可以是SIP用户代理（UA）、不具有SIP堆栈的某个其他IP设备（路由器或PC）、非IP设备（个人或黑色电话），甚至是非通信设备（建筑物或店面）。本文档绝不假设发送包含位置对象的请求的SIP用户代理客户端一定是目标。SIP内传送的目标的位置通常对应于由目标控制的设备的位置，例如移动电话，但是这些设备可以与其所有者分离，并且，在某些情况下，用户代理可能不知道其自身的位置。
In the SIP context, a location recipient will most likely be a SIP UA, but due to the mediated nature of SIP architectures, location information conveyed by a single SIP request may have multiple recipients, as any SIP proxy server in the signaling path that inspects the location of the Target must also be considered a Location Recipient. In presence-like architectures, an intermediary that receives publications of location information and distributes them to watchers acts as a Location Server per RFC 3693. This location conveyance mechanism can also be used to deliver URIs pointing to such Location Servers where prospective Location Recipients can request Location Objects.
在SIP上下文中，位置接收者很可能是SIP UA，但是由于SIP架构的中介性质，由单个SIP请求传送的位置信息可能有多个接收者，因为信令路径中检查目标位置的任何SIP代理服务器也必须被视为位置接收者。在类似于存在的体系结构中，根据RFC 3693，接收位置信息发布并将其分发给观察者的中介充当位置服务器。此位置传递机制还可用于传递指向此类位置服务器的URI，潜在位置接收者可在其中请求位置对象。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Furthermore, this document uses numerous terms defined in [RFC3693], including: Location Object, Location Recipient, Location Server, Target, Rule Maker, and Using Protocol.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。此外，本文档使用了[RFC3693]中定义的许多术语，包括：位置对象、位置收件人、位置服务器、目标、规则制定者和使用协议。
An operational overview of SIP location conveyance can be shown in four basic diagrams, with most applications falling under one of the following basic use cases. Each is separated into its own subsection here in Section 3.
SIP位置传输的操作概述可以在四个基本图中显示，大多数应用程序属于以下基本用例之一。在第3节中，每一部分都被分为自己的小节。
Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob is an LR. A SIP intermediary appears in some of the diagrams. Any SIP entity that receives and inspects location information is an LR; therefore, in any of the diagrams, the SIP intermediary that receives a SIP request is potentially an LR -- though that does not mean such an intermediary necessarily has to route the SIP request based on the location information. In some use cases, location information passes through the LS on the right of each diagram.
每个图都有Alice和Bob作为UAs。爱丽丝是目标，鲍勃是LR。SIP中介出现在一些图中。接收和检查位置信息的任何SIP实体都是LR；因此，在任何图中，接收SIP请求的SIP中介可能是LR——尽管这并不意味着这样的中介必须基于位置信息路由SIP请求。在某些用例中，位置信息通过每个图右侧的LS传递。
We start with the simplest diagram of Location Conveyance, Alice to Bob, where no other Layer 7 entities are involved.
我们从最简单的位置传输图开始，从Alice到Bob，其中不涉及其他第7层实体。
Alice SIP Intermediary Bob LS
| | | |
| Request w/Location | |
|----------------------------------->| |
| | |
| Response | |
|<-----------------------------------| |
| | | |
Alice SIP Intermediary Bob LS
| | | |
| Request w/Location | |
|----------------------------------->| |
| | |
| Response | |
|<-----------------------------------| |
| | | |
Figure 1. Location Conveyed by Value
图1。价值传递的位置
In Figure 1, Alice is both the Target and the LS that is conveying her location directly to Bob, who acts as an LR. This conveyance is point-to-point: it does not pass through any SIP-layer intermediary. A Location Object appears by-value in the initial SIP request as a MIME body, and Bob responds to that SIP request as appropriate. There is a 'Bad Location Information' response code introduced within this document to specifically inform Alice if she conveys bad
在图1中，Alice既是目标，也是将她的位置直接传递给Bob的LS，Bob充当LR。此传输是点对点的：它不通过任何SIP层中介。Location对象在初始SIP请求中按值显示为MIME主体，Bob根据需要响应该SIP请求。本文件中引入了“错误位置信息”响应代码，专门通知Alice是否传达了错误信息
location to Bob (e.g., Bob "cannot parse the location provided", or "there is not enough location information to determine where Alice is").
Bob的位置（例如，Bob“无法解析提供的位置”，或“没有足够的位置信息来确定Alice的位置”）。
Here we make Figure 1 a little more complicated by showing a diagram of indirect Location Conveyance from Alice to Bob, where Bob's entity has to retrieve the location object from a third party server.
在这里，我们通过显示从Alice到Bob的间接位置传输图使图1稍微复杂一些，Bob的实体必须从第三方服务器检索位置对象。
Alice SIP Intermediary Bob LS
| | | |
| Request w/Location URI | |
|----------------------------------->| |
| | Dereference |
| | Request |
| (To: Location URI) |
| |---------------->|
| | |
| | Dereference |
| | Response |
| (includes Location Object) |
| |<----------------|
| Response | |
|<-----------------------------------| |
| | | |
Alice SIP Intermediary Bob LS
| | | |
| Request w/Location URI | |
|----------------------------------->| |
| | Dereference |
| | Request |
| (To: Location URI) |
| |---------------->|
| | |
| | Dereference |
| | Response |
| (includes Location Object) |
| |<----------------|
| Response | |
|<-----------------------------------| |
| | | |
Figure 2. Location Conveyed as a Location URI
图2。作为位置URI传递的位置
In Figure 2, location is conveyed indirectly, via a Location URI carried in the SIP request (more of those details later). If Alice sends Bob this Location URI, Bob will need to dereference the URI -- analogous to Content Indirection [RFC4483] -- in order to request the location information. In general, the LS provides the location value to Bob instead of Alice directly for conveyance to Bob. From a user interface perspective, Bob the user won't know that this information was gathered from an LS indirectly rather than culled from the SIP request; practically, this does not impact the operation of location-based applications.
在图2中，位置是通过SIP请求中携带的位置URI间接传递的（稍后将介绍更多细节）。如果Alice向Bob发送此位置URI，Bob将需要取消对URI的引用（类似于内容间接寻址[RFC4483]），以便请求位置信息。通常，LS向Bob提供位置值，而不是直接向Alice提供位置值，以便传输到Bob。从用户界面的角度来看，用户不会知道这些信息是从LS间接收集的，而不是从SIP请求中挑选出来的；实际上，这不会影响基于位置的应用程序的操作。
The example given in this section is only illustrative, not normative. In particular, applications can choose to dereference a location URI at any time, possibly several times, or potentially not at all. Applications receiving a Location URI in a SIP transaction need to be mindful of timers used by different transactions. In particular, if the means of dereferencing the Location URI might take longer than the SIP transaction timeout (Timer C for INVITE
本节给出的示例只是说明性的，不是规范性的。特别是，应用程序可以选择在任何时候、可能多次或根本不去引用位置URI。在SIP事务中接收位置URI的应用程序需要注意不同事务使用的计时器。特别是，如果取消引用位置URI的方法可能需要比SIP事务超时（INVITE的计时器C）更长的时间
transactions, Timer F for non-INVITE transactions), then it needs to rely on mechanisms other than the transaction's response code to convey location errors, if returning such errors are necessary.
事务，计时器F（对于非邀请事务），则如果需要返回此类错误，则需要依赖除事务响应代码以外的机制来传递位置错误。
In Figure 3, we introduce the idea of a SIP intermediary into the example to illustrate the role of proxying in the location architecture. This intermediary can be a SIP proxy or it can be a back-to-back user agent (B2BUA). In this message flow, the SIP intermediary could act as an LR, in addition to Bob. The primary use case for intermediaries consuming location information is location-based routing. In this case, the intermediary chooses a next hop for the SIP request by consulting a specialized location service that selects forwarding destinations based on the geographical location information contained in the SIP request.
在图3中，我们将SIP中介的思想引入到示例中，以说明代理在位置体系结构中的作用。该中介可以是SIP代理，也可以是背靠背用户代理（B2BUA）。在这个消息流中，除了Bob之外，SIP中介还可以充当LR。使用位置信息的中介的主要用例是基于位置的路由。在这种情况下，中介通过咨询专门的位置服务来选择SIP请求的下一跳，该位置服务基于SIP请求中包含的地理位置信息来选择转发目的地。
Alice SIP Intermediary Bob LS
| | | |
| Request | | |
| w/Location | | |
|--------------->| | |
| | Request | |
| | w/Location | |
| |------------------>| |
| | | |
| | Response | |
| |<------------------| |
| Response | | |
|<---------------| | |
| | | |
Alice SIP Intermediary Bob LS
| | | |
| Request | | |
| w/Location | | |
|--------------->| | |
| | Request | |
| | w/Location | |
| |------------------>| |
| | | |
| | Response | |
| |<------------------| |
| Response | | |
|<---------------| | |
| | | |
Figure 3. Location Conveyed though a SIP Intermediary
图3。通过SIP中介传递的位置
However, the most common case will be one in which the SIP intermediary receives a request with location information (conveyed either by-value or by-reference) and does not know or care about Alice's location, or support this extension, and merely passes it on to Bob. In this case, the intermediary does not act as a Location Recipient. When the intermediary is not an LR, this use case is the same as the one described in Section 3.1.
然而，最常见的情况是SIP中介接收到带有位置信息（通过值或引用传递）的请求，不知道或不关心Alice的位置，也不支持此扩展，只将其传递给Bob。在这种情况下，中间人不作为地点接收人。当中介不是LR时，该用例与第3.1节中描述的用例相同。
Note that an intermediary does not have to perform location-based routing in order to be a Location Recipient. It could be the case that a SIP intermediary that does not perform location-based routing does care when Alice includes her location; for example, it could care that the location information is complete or that it correctly identifies where Alice is. The best example of this is
请注意，中间人不必执行基于位置的路由才能成为位置收件人。可能的情况是，当Alice包含她的位置时，不执行基于位置的路由的SIP中介并不关心；例如，它可能关心位置信息是否完整，或者是否正确标识Alice所在的位置。最好的例子是
intermediaries that verify location information for emergency calling, but it could also be for any location based routing, e.g., contacting your favorite local pizza delivery service, making sure that organization has Alice's proper location in the initial SIP request.
验证紧急呼叫位置信息的中介机构，但也可以用于任何基于位置的路由，例如，联系您最喜欢的本地比萨饼递送服务，确保组织在初始SIP请求中有Alice的正确位置。
There is another scenario in which the SIP intermediary cares about location and is not an LR, one in which the intermediary inserts another location of the Target, Alice in this case, into the request, and forwards it. This secondary insertion is generally not advisable because downstream SIP entities will not be given any guidance about which location to believe is better, more reliable, less prone to error, more granular, worse than the other location or just plain wrong.
还有另一种情况，其中SIP中介关心位置，而不是LR，在这种情况下，中介将目标的另一个位置（在本例中为Alice）插入到请求中，并转发它。这种二次插入通常是不可取的，因为下游SIP实体不会得到任何关于哪个位置更好、更可靠、更不容易出错、更细粒度、比其他位置更差或完全错误的指导。
This document takes a "you break it, you bought it" approach to dealing with second locations placed into a SIP request by an intermediary entity. That entity becomes completely responsible for all location within that SIP request (more on this in Section 4).
本文档采用“你打破了它，你买了它”的方法来处理中介实体放入SIP请求中的第二个位置。该实体将完全负责该SIP请求中的所有位置（更多信息，请参见第4节）。
If the SIP intermediary rejects the message due to unsuitable location information, the SIP response will indicate there was 'Bad Location Information' in the SIP request and provide a location-specific error code indicating what Alice needs to do to send an acceptable request (see Figure 4 for this scenario).
如果SIP中介由于不合适的位置信息而拒绝消息，SIP响应将指示SIP请求中存在“错误位置信息”，并提供一个特定于位置的错误代码，指示Alice需要做什么来发送可接受的请求（此场景参见图4）。
Alice SIP Intermediary Bob LS
| | | |
| Request | | |
| w/Location | | |
|--------------->| | |
| | | |
| Rejected | | |
| w/New Location | | |
|<---------------| | |
| | | |
| Request | | |
| w/New Location | | |
|--------------->| | |
| | Request | |
| | w/New Location | |
| |------------------>| |
| | | |
Alice SIP Intermediary Bob LS
| | | |
| Request | | |
| w/Location | | |
|--------------->| | |
| | | |
| Rejected | | |
| w/New Location | | |
|<---------------| | |
| | | |
| Request | | |
| w/New Location | | |
|--------------->| | |
| | Request | |
| | w/New Location | |
| |------------------>| |
| | | |
Figure 4. SIP Intermediary Replacing Bad Location
图4。替换坏位置的SIP中介
In this last use case, the SIP intermediary wishes to include a Location Object indicating where it understands Alice to be. Thus, it needs to inform her user agent of what location it will include in any subsequent SIP request that contains her location. In this case, the intermediary can reject Alice's request and, through the SIP response, convey to her the best way to repair the request in order for the intermediary to accept it.
在最后一个用例中，SIP中介希望包括一个位置对象，指示它理解Alice的位置。因此，它需要通知她的用户代理它将在包含她的位置的任何后续SIP请求中包括的位置。在这种情况下，中介可以拒绝Alice的请求，并通过SIP响应向她传达修复请求的最佳方式，以便中介接受请求。
Overriding location information provided by the user requires a deployment where an intermediary necessarily knows better than an end user -- after all, it could be that Alice has an on-board GPS, and the SIP intermediary only knows her nearest cell tower. Which is more accurate location information? Currently, there is no way to tell which entity is more accurate or which is wrong, for that matter. This document will not specify how to indicate which location is more accurate than another.
覆盖用户提供的位置信息需要一个部署，中间人必须比最终用户更清楚——毕竟，可能是Alice有一个车载GPS，而SIP中间人只知道她最近的手机发射塔。哪个位置信息更准确？就这一点而言，目前还无法判断哪个实体更准确，哪个实体错了。本文档不会指定如何指示哪个位置比另一个位置更准确。
As an aside, it is not envisioned that any SIP-based emergency services request (i.e., IP-911 or 112 type of call attempt) will receive a corrective 'Bad Location Information' response from an intermediary. Most likely, in that scenario, the SIP intermediary would act as a B2BUA and insert into the request by-value any appropriate location information for the benefit of Public Safety Answering Point (PSAP) call centers to expedite call reception by the emergency services personnel; thereby, minimizing any delay in call establishment time. The implementation of these specialized deployments is, however, outside the scope of this document.
另一方面，预计任何基于SIP的紧急服务请求（即IP-911或112类型的呼叫尝试）都不会从中介收到纠正性的“错误位置信息”响应。在这种情况下，SIP中介机构最有可能充当B2BUA，并将任何适当的位置信息按值插入请求中，以利于公共安全应答点（PSAP）呼叫中心加快应急服务人员的呼叫接收；因此，最大限度地减少呼叫建立时间的延迟。但是，这些专门部署的实施不在本文档的范围内。
The following sections detail the extensions to SIP for location conveyance.
以下各节详细介绍了用于位置传输的SIP扩展。
This document defines "Geolocation" as a new SIP header field registered by IANA, with the following ABNF [RFC5234]:
本文档将“地理位置”定义为IANA注册的新SIP头字段，带有以下ABNF[RFC5234]：
message-header =/ Geolocation-header
; (message-header from RFC 3261)
Geolocation-header = "Geolocation" HCOLON locationValue
*( COMMA locationValue )
locationValue = LAQUOT locationURI RAQUOT
*(SEMI geoloc-param)
locationURI = sip-URI / sips-URI / pres-URI
/ http-URI / https-URI
/ cid-url ; (from RFC 2392)
/ absoluteURI ; (from RFC 3261)
message-header =/ Geolocation-header
; (message-header from RFC 3261)
Geolocation-header = "Geolocation" HCOLON locationValue
*( COMMA locationValue )
locationValue = LAQUOT locationURI RAQUOT
*(SEMI geoloc-param)
locationURI = sip-URI / sips-URI / pres-URI
/ http-URI / https-URI
/ cid-url ; (from RFC 2392)
/ absoluteURI ; (from RFC 3261)
geoloc-param = generic-param ; (from RFC 3261)
geoloc参数=通用参数；（来自RFC 3261）
HCOLON, COMMA, LAQUOT, RAQUOT, and SEMI are defined in [RFC3261].
[RFC3261]中定义了HCOLON、逗号、LAQUOTE、RAQUOTE和SEMI。
sip-URI, sips-URI, and absoluteURI are defined according to [RFC3261].
sip URI、sips URI和绝对URI根据[RFC3261]定义。
The pres-URI is defined in [RFC3859].
pres URI在[RFC3859]中定义。
http-URI and https-URI are defined according to [RFC2616] and [RFC2818], respectively.
http URI和https URI分别根据[RFC2616]和[RFC2818]定义。
The cid-url is defined in [RFC2392] to locate message body parts. This URI type is present in a SIP request when location is conveyed as a MIME body in the SIP message.
cid url在[RFC2392]中定义，用于定位消息正文部分。当位置在SIP消息中作为MIME正文传递时，SIP请求中会出现此URI类型。
GEO-URIs [RFC5870] are not appropriate for usage in the SIP Geolocation header because it does not include retention and re-transmission flags as part of the location information. Other URI schemes used in the location URI MUST be reviewed against the criteria in [RFC3693] for a Using Protocol. Section 4.6 discusses how URI schemes are communicated using this SIP extension and what to do if a URI scheme is received that cannot be supported.
地理URI[RFC5870]不适合在SIP地理位置标头中使用，因为它不包括作为位置信息一部分的保留和重新传输标志。必须根据[RFC3693]中关于使用协议的标准审查位置URI中使用的其他URI方案。第4.6节讨论了如何使用此SIP扩展通信URI方案，以及在接收到不受支持的URI方案时该怎么做。
The generic-param in the definition of locationValue is included as a mechanism for future extensions that might require parameters. This document defines no parameters for use with locationValue. If a Geolocation header field is received that contains generic-params, each parameter SHOULD be ignored, and SHOULD NOT be removed when forwarding the locationValue. If a need arises to define parameters for use with locationValue, a revision/extension to this document is required.
locationValue定义中的泛型参数作为一种机制包含在可能需要参数的未来扩展中。本文档未定义与locationValue一起使用的参数。如果接收到包含通用参数的Geolocation标头字段，则应忽略每个参数，并且在转发locationValue时不应删除这些参数。如果需要定义与locationValue一起使用的参数，则需要对本文件进行修订/扩展。
The Geolocation header field MUST have at least one locationValue. A SIP intermediary SHOULD NOT add location to a SIP request that already contains location. This will quite often lead to confusion within LRs. However, if a SIP intermediary adds location, even if location was not previously present in a SIP request, that SIP intermediary is fully responsible for addressing the concerns of any 424 (Bad Location Information) SIP response it receives about this location addition and MUST NOT pass on (upstream) the 424 response. A SIP intermediary that adds a locationValue MUST position the new locationValue as the last locationValue within the Geolocation header field of the SIP request.
地理位置标头字段必须至少有一个locationValue。SIP中介不应向已包含位置的SIP请求添加位置。这通常会导致LRs内部的混乱。然而，如果SIP中介添加了位置，即使该位置以前没有出现在SIP请求中，该SIP中介完全负责解决其收到的关于该位置添加的任何424（错误位置信息）SIP响应的问题，并且不得传递（上游）424响应。添加locationValue的SIP中介必须将新locationValue定位为SIP请求的Geolocation标头字段中的最后一个locationValue。
This document defines the Geolocation header field as valid in the following SIP requests:
本文档将Geolocation标头字段定义为在以下SIP请求中有效：
INVITE [RFC3261] REGISTER [RFC3261]
OPTIONS [RFC3261] BYE [RFC3261]
UPDATE [RFC3311] INFO [RFC6086]
MESSAGE [RFC3428] REFER [RFC3515]
SUBSCRIBE [RFC3265] NOTIFY [RFC3265]
PUBLISH [RFC3903]
INVITE [RFC3261] REGISTER [RFC3261]
OPTIONS [RFC3261] BYE [RFC3261]
UPDATE [RFC3311] INFO [RFC6086]
MESSAGE [RFC3428] REFER [RFC3515]
SUBSCRIBE [RFC3265] NOTIFY [RFC3265]
PUBLISH [RFC3903]
The Geolocation header field MAY be included in any one of the above listed requests by a UA and a 424 response to any one of the requests sent above. Fully appreciating the caveats/warnings mentioned above, a SIP intermediary MAY add the Geolocation header field.
地理位置报头字段可由UA和424响应上述发送的任何一个请求而包括在上述列出的请求中。SIP中介完全理解上述警告/警告，可以添加Geolocation头字段。
A SIP intermediary MAY add a Geolocation header field if one is not present -- for example, when a user agent does not support the Geolocation mechanism but their outbound proxy does and knows the Target's location, or any of a number of other use cases (see Section 3).
如果不存在地理位置头字段，SIP中介可以添加一个地理位置头字段——例如，当用户代理不支持地理位置机制，但其出站代理支持并知道目标的位置，或者其他许多用例中的任何一个时（参见第3节）。
The Geolocation header field MAY be present in a SIP request or response without the presence of a Geolocation-Routing header (defined in Section 4.2). As stated in Section 4.2, the default value of Geolocation-Routing header-value is "no", meaning SIP intermediaries MUST NOT view (i.e., process, inspect, or actively dereference) any direct or indirect location within this SIP message. This is for at least two fundamental reasons:
地理位置报头字段可能出现在SIP请求或响应中，而不存在地理位置路由报头（定义见第4.2节）。如第4.2节所述，地理位置路由报头值的默认值为“否”，这意味着SIP中介机构不得查看（即，处理、检查或主动取消引用）此SIP消息中的任何直接或间接位置。这至少有两个基本原因：
1) to make the possibility of retention of the Target's location moot (because it was not viewed in the first place); and
1) 使保留目标位置的可能性变得毫无意义（因为它一开始没有被查看）；和
2) to prevent a different treatment of this SIP request based on the contents of the Location Information in the SIP request.
2) 防止基于SIP请求中位置信息的内容对此SIP请求进行不同的处理。
Any locationValue MUST be related to the original Target. This is equally true for the location information in a SIP response, i.e., from a SIP intermediary back to the Target as explained in Section 3.4. SIP intermediaries SHOULD NOT modify or delete any existing locationValue(s). A use case in which this would not apply would be where the SIP intermediary is an anonymizer. The problem with this scenario is that the geolocation included by the Target then becomes useless for the purpose or service for which they wanted to use (include) it. For example, 911/emergency calling or finding the nearest (towing company/pizza delivery/dry cleaning) service(s) will not yield intended results if the Location Information were to be modified or deleted from the SIP request.
任何locationValue必须与原始目标相关。这同样适用于SIP响应中的位置信息，即从SIP中介返回目标，如第3.4节所述。SIP中介机构不应修改或删除任何现有locationValue。这不适用的用例是SIP中介是匿名者的情况。这个场景的问题是，目标包含的地理位置对于他们想要使用（包括）它的目的或服务来说变得无用。例如，如果要修改或删除SIP请求中的位置信息，911/紧急呼叫或查找最近的（拖车公司/比萨饼配送/干洗）服务将不会产生预期结果。
This document defines "Geolocation-Routing" as a new SIP header field registered by IANA, with the following ABNF [RFC5234]:
本文档将“地理位置路由”定义为IANA注册的新SIP头字段，带有以下ABNF[RFC5234]：
message-header =/ Georouting-header
; (message-header from RFC 3261)
Georouting-header = "Geolocation-Routing" HCOLON
( "yes" / "no" / generic-value )
generic-value = generic-param; (from RFC 3261)
message-header =/ Georouting-header
; (message-header from RFC 3261)
Georouting-header = "Geolocation-Routing" HCOLON
( "yes" / "no" / generic-value )
generic-value = generic-param; (from RFC 3261)
HCOLON is defined in [RFC3261].
[RFC3261]中定义了HCOLON。
The only defined values for the Geolocation-Routing header field are "yes" or "no". When the value is "yes", the locationValue can be used for routing decisions along the downstream signaling path by intermediaries. Values other than "yes" or "no" are permitted for future extensions. Implementations not aware of an extension MUST treat any other received value the same as "no".
地理位置路由标头字段的唯一定义值为“是”或“否”。当该值为“是”时，locationValue可用于中介机构沿下游信令路径进行路由决策。以后的扩展允许使用“是”或“否”以外的值。不知道扩展的实现必须将任何其他收到的值视为“否”。
If no Geolocation-Routing header field is present in a SIP request, a SIP intermediary MAY insert this header. Without knowledge from a Rule Maker, the SIP intermediary inserting this header-value SHOULD NOT set the value to "yes", as this may be more permissive than the originating party intends. An easy way around this is to have the Target always insert this header-value as "no".
如果SIP请求中不存在地理位置路由报头字段，则SIP中介可以插入此报头。在规则制定者不知情的情况下，插入此标头值的SIP中介机构不应将该值设置为“是”，因为这可能比发起方所希望的更宽松。解决此问题的一个简单方法是让目标始终将此标题值插入为“否”。
When this Geolocation-Routing header-value is set to "no", this means no locationValue (inserted by the originating User Agent Client (UAC) or any intermediary along the signaling path) can be used by any SIP intermediary to make routing decisions. Intermediaries that attempt to use the location information for routing purposes in spite of this counter indication could end up routing the request improperly as a result. Section 4.4 gives the details on what a routing intermediary does if it determines it needs to use the location in the SIP request in order to process the message further. The practical implication is that when the Geolocation-Routing header-value is set to "no", if a cid:url is present in the SIP request, intermediaries MUST NOT view the location (because it is not for intermediaries to consider when processing the request); if a location URI is present, intermediaries MUST NOT dereference it. UAs are allowed to view location in the SIP request even when the Geolocation-Routing header-value is set to "no". An LR MUST by default consider the Geolocation-Routing header-value as set to "no", with no exceptions, unless the header field value is set to "yes".
当此地理位置路由报头值设置为“否”时，这意味着任何SIP中介都不能使用任何位置值（由发起用户代理客户端（UAC）或信令路径上的任何中介插入）来做出路由决策。尽管有此计数器指示，但尝试将位置信息用于路由目的的中介可能会因此而不正确地路由请求。第4.4节详细介绍了路由中介在确定需要使用SIP请求中的位置以进一步处理消息时所做的工作。实际意义是，当地理定位路由报头值设置为“否”时，如果在SIP请求中存在CID:URL，中介机构就不能查看该位置（因为在处理请求时不考虑中间人）；如果存在位置URI，中介机构不得取消对其的引用。即使地理位置路由标头值设置为“否”，UAs也可以查看SIP请求中的位置。默认情况下，LR必须将地理定位路由标头值设置为“否”，没有例外情况，除非将标头字段值设置为“是”。
A Geolocation-Routing header-value that is set to "no" has no special security properties. At most, it is a request for behavior within SIP intermediaries. That said, if the Geolocation-Routing header-value is set to "no", SIP intermediaries are still to process the SIP request and send it further downstream within the signaling path if there are no errors present in this SIP request.
设置为“否”的地理位置路由标头值没有特殊的安全属性。最多，它是SIP中介中的行为请求。也就是说，如果Geolocation Routing header值设置为“no”，则如果该SIP请求中不存在错误，则SIP中介仍将处理SIP请求并在信令路径内将其进一步发送到下游。
The Geolocation-Routing header field satisfies the recommendations made in Section 3.5 of RFC 5606 [RFC5606] regarding indication of permission to use location-based routing in SIP.
地理位置路由报头字段满足RFC 5606[RFC5606]第3.5节中关于在SIP中使用基于位置路由的许可指示的建议。
SIP implementations are advised to pay special attention to the policy elements for location retransmission and retention described in RFC 4119.
建议SIP实施特别注意RFC 4119中描述的位置重传和保留的策略元素。
The Geolocation-Routing header field cannot appear without a header-value in a SIP request or response (i.e., a null value is not allowed). The absence of a Geolocation-Routing header-value in a SIP request is always the same as the following header field:
如果SIP请求或响应中没有标头值（即，不允许空值），则无法显示地理位置路由标头字段。SIP请求中缺少地理位置路由标头值始终与以下标头字段相同：
Geolocation-Routing: no
地理定位路由：否
The Geolocation-Routing header field MAY be present without a Geolocation header field in the same SIP request. This concept is further explored in Section 4.2.1.
在同一SIP请求中，地理位置路由报头字段可能不存在地理位置报头字段。第4.2.1节进一步探讨了这一概念。
The Geolocation header field contains a Target's location, and it MUST NOT be present if there is no location information in this SIP request. The location information is contained in one or more locationValues. These locationValues MAY be contained in a single Geolocation header field or distributed among multiple Geolocation header fields. (See Section 7.3.1 of RFC 3261.)
Geolocation标头字段包含目标的位置，如果此SIP请求中没有位置信息，则该字段不得存在。位置信息包含在一个或多个LocationValue中。这些位置值可以包含在单个地理位置标头字段中，也可以分布在多个地理位置标头字段中。（见RFC 3261第7.3.1节。）
The Geolocation-Routing header field indicates whether or not SIP intermediaries can view and then route this SIP request based on the included (directly or indirectly) location information. The Geolocation-Routing header field MUST NOT appear more than once in any SIP request, and MUST NOT lack a header-value. The default or implied policy of a SIP request that does not have a Geolocation-Routing header field is the same as if one were present and the header-value were set to "no".
Geolocation Routing header字段指示SIP中介机构是否可以查看此SIP请求，然后根据包含的（直接或间接）位置信息对其进行路由。Geolocation Routing header字段在任何SIP请求中不得出现多次，且不得缺少标头值。没有地理位置路由标头字段的SIP请求的默认或隐含策略与存在此字段时相同，并且标头值设置为“否”。
There are only three possible states regarding the Geolocation-Routing header field:
关于地理位置路由标头字段，只有三种可能的状态：
- "no" - "yes" - no header-field present in this SIP request
- “否”-“是”-此SIP请求中不存在标头字段
The expected results in each state are as follows:
每个州的预期结果如下：
If the Geolocation-Routing Only possible interpretations:
-------------------------- -----------------------------
"no" SIP intermediaries MUST NOT process
included geolocation information
within this SIP request.
If the Geolocation-Routing Only possible interpretations:
-------------------------- -----------------------------
"no" SIP intermediaries MUST NOT process
included geolocation information
within this SIP request.
SIP intermediaries inserting a locationValue into a Geolocation header field (whether adding to an existing header-value or inserting the Geolocation header field for the first time) MUST NOT modify or delete the received "no" header-value.
SIP中介机构将locationValue插入地理位置标头字段（无论是添加到现有标头值还是首次插入地理位置标头字段）不得修改或删除收到的“否”标头值。
"yes" SIP intermediaries can process included geolocation information within this SIP request and can change the policy to "no" for intermediaries further downstream.
“是”SIP中介可以处理此SIP请求中包含的地理位置信息，并可以将下游中介的策略更改为“否”。
Geolocation-Routing absent If a Geolocation header field exists (meaning a locationValue is already present), a SIP intermediary MUST interpret the lack of a Geolocation-Routing header field as if there were one present and the header-value is set to "no".
缺少地理位置路由如果存在地理位置标头字段（意味着已经存在locationValue），SIP中介必须将缺少地理位置路由标头字段解释为存在一个字段，并且标头值设置为“否”。
If there is no Geolocation header field in this SIP request, the default Geolocation-Routing is open and can be set by a SIP intermediary or not at all.
如果此SIP请求中没有Geolocation标头字段，则默认的Geolocation路由是打开的，可以由SIP中介设置，也可以根本不设置。
This SIP extension creates a new location-specific response code, defined as follows:
此SIP扩展创建新的特定于位置的响应代码，定义如下：
424 (Bad Location Information)
424（错误位置信息）
The 424 (Bad Location Information) response code is a rejection of the request due to its location contents, indicating location information that was malformed or not satisfactory for the recipient's purpose or could not be dereferenced.
424（错误位置信息）响应代码是由于其位置内容而拒绝请求的代码，表示位置信息格式错误或不符合收件人的目的或无法取消引用。
A SIP intermediary can also reject a location it receives from a Target when it understands the Target to be in a different location. The proper handling of this scenario, described in Section 3.4, is for the SIP intermediary to include the proper location in the 424 response. This SHOULD be included in the response as a MIME message body (i.e., a location value) rather than as a URI; however, in cases where the intermediary is willing to share location with recipients but not with a user agent, a reference might be necessary.
当SIP中介体了解目标位于不同位置时，它还可以拒绝从目标接收的位置。第3.4节中描述的对该场景的正确处理是SIP中介在424响应中包括正确的位置。这应该作为MIME消息体（即位置值）而不是URI包含在响应中；但是，如果中间人愿意与收件人共享位置，但不愿意与用户代理共享位置，则可能需要提供参考。
As mentioned in Section 3.4, it might be the case that the intermediary does not want to chance providing less accurate location information than the user agent; thus, it will compose its understanding of where the user agent is in a separate <geopriv> element of the same Presence Information Data Format Location Object (PIDF-LO) [RFC4119] message body in the SIP response (which also contains the Target's version of where it is). Therefore, both locations are included -- each with different <method> elements. The proper reaction of the user agent is to generate a new SIP request that includes this composed location object, and send it towards the original LR. SIP intermediaries can verify that subsequent requests properly insert the suggested location information before forwarding said requests.
如第3.4节所述，中介机构可能不希望偶然提供比用户代理更不准确的位置信息；因此，它将在SIP响应（还包含目标位置的目标版本）中构成对用户代理在相同存在信息数据格式位置对象（PIDF-LO）[RFC4119]消息体的单独<geopriv>元素中的位置的理解。因此，这两个位置都包括在内——每个位置都有不同的<method>元素。用户代理的正确反应是生成一个包含该组合位置对象的新SIP请求，并将其发送到原始LR。SIP中介机构可以在转发所述请求之前验证后续请求是否正确插入了建议的位置信息。
SIP intermediaries that are forwarding (as opposed to generating) a 424 response MUST NOT add, modify, or delete any location appearing in that response. This specifically applies to intermediaries that are between the 424 response generator and the original UAC. Geolocation and Geolocation-Error header fields and PIDF-LO body parts MUST remain unchanged, never added to or deleted.
转发（而不是生成）424响应的SIP中介不得添加、修改或删除该响应中出现的任何位置。这特别适用于424响应生成器和原始UAC之间的中介。地理位置和地理位置错误标题字段以及PIDF-LO车身零件必须保持不变，不得添加或删除。
Section 4.4 describes a Geolocation-Error header field to provide more detail about what was wrong with the location information in the request. This header field MUST be included in the 424 response.
第4.4节描述了Geolocation Error header字段，以提供有关请求中位置信息错误的更多详细信息。此标题字段必须包含在424响应中。
It is only appropriate to generate a 424 response when the responding entity needs a locationValue and there are no values in the request that are usable by the responder, or when the responder has additional location information to provide. The latter case is shown in Figure 4 of Section 3.4. There, a SIP intermediary is informing the upstream UA which location to include in the next SIP request.
仅当响应实体需要locationValue且请求中没有响应者可用的值时，或者当响应者需要提供其他位置信息时，才适合生成424响应。后一种情况如第3.4节图4所示。在那里，SIP中介通知上游UA在下一个SIP请求中包括哪个位置。
A 424 response MUST NOT be sent in response to a request that lacks a Geolocation header entirely, as the user agent in that case may not support this extension at all. If a SIP intermediary inserted a locationValue into a SIP request where one was not previously present, it MUST take any and all responsibility for the corrective action if it receives a 424 response to a SIP request it sent.
对于完全缺少地理位置标头的请求，不能发送424响应，因为在这种情况下，用户代理可能根本不支持此扩展。如果SIP中介将locationValue插入到SIP请求中，而该请求之前不存在locationValue，则如果收到对其发送的SIP请求的424响应，则该中介必须对纠正措施承担任何和所有责任。
A 424 (Bad Location Information) response is a final response within a transaction and MUST NOT terminate an existing dialog.
424（错误位置信息）响应是事务中的最终响应，不能终止现有对话框。
As discussed in Section 4.3, more granular error notifications specific to location errors within a received request are required if the location inserting entity is to know what was wrong within the original request. The Geolocation-Error header field is used for this purpose.
如第4.3节所述，如果位置插入实体要知道原始请求中的错误，则需要针对接收到的请求中的位置错误发出更细粒度的错误通知。地理位置错误标题字段用于此目的。
The Geolocation-Error header field is used to convey location-specific errors within a response. The Geolocation-Error header field has the following ABNF [RFC5234]:
Geolocation Error header字段用于在响应中传递特定于位置的错误。地理位置错误标头字段具有以下ABNF[RFC5234]：
message-header =/ Geolocation-Error
; (message-header from RFC 3261)
Geolocation-Error = "Geolocation-Error" HCOLON
locationErrorValue
locationErrorValue = location-error-code
*(SEMI location-error-params)
location-error-code = 1*3DIGIT
location-error-params = location-error-code-text
/ generic-param ; from RFC 3261
location-error-code-text = "code" EQUAL quoted-string
; from RFC 3261
message-header =/ Geolocation-Error
; (message-header from RFC 3261)
Geolocation-Error = "Geolocation-Error" HCOLON
locationErrorValue
locationErrorValue = location-error-code
*(SEMI location-error-params)
location-error-code = 1*3DIGIT
location-error-params = location-error-code-text
/ generic-param ; from RFC 3261
location-error-code-text = "code" EQUAL quoted-string
; from RFC 3261
HCOLON, SEMI, and EQUAL are defined in [RFC3261]. DIGIT is defined in [RFC5234].
[RFC3261]中定义了HCOLON、SEMI和EQUAL。数字在[RFC5234]中定义。
The Geolocation-Error header field MUST contain only one locationErrorValue to indicate what was wrong with the locationValue the Location Recipient determined was bad. The locationErrorValue contains a 3-digit error code indicating what was wrong with the
Geolocation Error header字段必须仅包含一个locationErrorValue，以指示Location收件人确定的locationValue存在错误。locationErrorValue包含一个3位数的错误代码，指示错误所在
location in the request. This error code has a corresponding quoted error text string that is human understandable. The text string is OPTIONAL, but RECOMMENDED for human readability, similar to the string phrase used for SIP response codes. That said, the strings are complete enough for rendering to the user, if so desired. The strings in this document are recommendations, and are not standardized -- meaning an operator can change the strings -- but MUST NOT change the meaning of the error code. Similar to how RFC 3261 specifies, there MUST NOT be more than one string per error code.
请求中的位置。此错误代码有一个相应的带引号的错误文本字符串，人类可以理解。文本字符串是可选的，但建议用于人类可读性，类似于用于SIP响应代码的字符串短语。也就是说，如果需要，字符串足够完整，可以呈现给用户。本文档中的字符串是建议的，并且没有标准化，这意味着操作员可以更改字符串，但不能更改错误代码的含义。与RFC 3261的指定方式类似，每个错误代码不得超过一个字符串。
The Geolocation-Error header field MAY be included in any response to one of the SIP Methods mentioned in Section 4.1, so long as a locationValue was in the request part of the same transaction. For example, Alice includes her location in an INVITE to Bob. Bob can accept this INVITE, thus creating a dialog, even though his UA determined the location contained in the INVITE was bad. Bob merely includes a Geolocation-Error header value in the 200 OK response to the INVITE informing Alice the INVITE was accepted but the location provided was bad.
只要locationValue位于同一事务的请求部分，Geolocation Error header字段可以包含在对第4.1节中提到的SIP方法之一的任何响应中。例如，Alice在给Bob的邀请中包括了她的位置。Bob可以接受此邀请，从而创建一个对话框，即使他的UA确定邀请中包含的位置不正确。Bob仅在对INVITE的200 OK响应中包含一个地理位置错误头值，通知Alice INVITE已被接受，但提供的位置不正确。
If, on the other hand, Bob cannot accept Alice's INVITE without a suitable location, a 424 (Bad Location Information) response is sent. This message flow is shown in Figures 1, 2, or 3 in Sections 3.1, 3.2, and 3.3, respectively.
另一方面，如果Bob在没有合适位置的情况下无法接受Alice的邀请，则发送424（错误位置信息）响应。该消息流分别如第3.1、3.2和3.3节中的图1、2或3所示。
If Alice is deliberately leaving location information out of the LO because she does not want Bob to have this additional information, implementations should be aware that Bob could repeatedly error in order to receive more location information about Alice in a subsequent SIP request. Implementations MUST be on guard for this, by not allowing continually more information to be revealed unless it is clear that any LR is permitted by Alice to know all that Alice knows about her location. A limit on the number of such rejections to learn more location information SHOULD be configurable, with a RECOMMENDED maximum of three times for each related transaction.
如果Alice故意将位置信息排除在LO之外，因为她不希望Bob获得此附加信息，那么实现应该知道Bob可能会反复出错，以便在后续SIP请求中接收有关Alice的更多位置信息。实现必须对此保持警惕，除非Alice明确允许任何LR知道Alice知道的关于其位置的所有信息，否则不允许不断披露更多信息。为了解更多位置信息，应设定此类拒绝次数的限制，建议每个相关交易最多三次。
A SIP intermediary that requires Alice's location in order to properly process Alice's INVITE also sends a 424 response with a Geolocation-Error code. This message flow is shown in Figure 4 of Section 3.4.
为了正确处理Alice的邀请，需要Alice的位置的SIP中介还发送一个带有地理位置错误代码的424响应。该消息流如第3.4节的图4所示。
If more than one locationValue is present in a SIP request and at least one locationValue is determined to be valid by the LR, the location in that SIP request MUST be considered good as far as location is concerned, and no Geolocation-Error is to be sent.
如果SIP请求中存在多个locationValue，并且LR确定至少一个locationValue有效，则就位置而言，该SIP请求中的位置必须被视为良好，并且不发送地理位置错误。
Here is an initial list of location-based error code ranges for any SIP response, including provisional responses (other than 100 Trying) and the new 424 (Bad Location Information) response. These error codes are divided into three categories, based on how the response receiver should react to these errors. There MUST be no more than one Geolocation-Error code in a SIP response, regardless of how many locationValues there are in the correlating SIP request. When more than one locationValue is present in a SIP request, this mechanism provides no indication to which one the Geolocation-Error code corresponds. If multiple errors are present, the LR applies local policy to select one.
以下是任何SIP响应的基于位置的错误代码范围的初始列表，包括临时响应（除了100次尝试）和新的424（错误位置信息）响应。根据响应接收器对这些错误的反应，这些错误代码分为三类。无论相关SIP请求中有多少LocationValue，SIP响应中的地理位置错误代码不得超过一个。当SIP请求中存在多个locationValue时，此机制不提供地理位置错误代码对应的指示。如果存在多个错误，LR将应用本地策略选择一个错误。
o 1XX errors mean the LR cannot process the location within the request:
o 1XX错误表示LR无法处理请求中的位置：
A non-exclusive list of reasons for returning a 1XX is as follows:
返回1XX的非排他性原因列表如下：
- the location was not present or could not be found in the SIP request,
- 该位置不存在或在SIP请求中找不到，
- there was not enough location information to determine where the Target was,
- 没有足够的位置信息来确定目标的位置，
- the location information was corrupted or known to be inaccurate.
- 位置信息已损坏或已知不准确。
o 2XX errors mean some specific permission is necessary to process the included location information.
o 2XX错误意味着需要某些特定权限来处理包含的位置信息。
o 3XX errors mean there was trouble dereferencing the Location URI sent.
o 3XX错误意味着取消引用发送的位置URI时出现问题。
Dereference attempts to the same request SHOULD be limited to 10 attempts within a few minutes. This number SHOULD be configurable, but result in a Geolocation-Error: 300 error once reached.
对同一请求的取消引用尝试应在几分钟内限制为10次。这个数字应该是可配置的，但会导致地理位置错误：一旦达到300错误。
It should be noted that for non-INVITE transactions, the SIP response will likely be sent before the dereference response has been received. This document does not alter that SIP protocol reality. This means the receiver of any non-INVITE response to a request containing location SHOULD NOT consider a 200 OK response to mean the act of dereferencing has concluded and the dereferencer (i.e., the LR) has successfully received and parsed the PIDF-LO for errors and found none. The end of Section 3.2 discusses how transaction timing considerations lead to this requirement.
应该注意的是，对于非INVITE事务，SIP响应可能在收到解引用响应之前发送。本文档不会改变SIP协议的实际情况。这意味着对包含位置的请求的任何非邀请响应不应该考虑200 OK响应，这意味着撤销行为已经结束，解引用者（即，LR）已经成功地接收并解析了PIDF-LO的错误，并且没有发现。第3.2节的结尾讨论了事务计时考虑如何导致这一要求。
Additionally, if an LR cannot or chooses not to process location from a SIP request, a 500 (Server Internal Error) SHOULD be used with or without a configurable Retry-After header field. There is no special location error code for what already exists within SIP today.
此外，如果LR无法或选择不处理SIP请求中的位置，则应使用500（服务器内部错误），并在标头字段后使用或不使用可配置的重试。对于目前SIP中已经存在的内容，没有特殊的位置错误代码。
Within each of these ranges, there is a top-level error as follows:
在每个范围内，都存在如下顶级错误：
Geolocation-Error: 100 ; code="Cannot Process Location"
Geolocation-Error: 100 ; code="Cannot Process Location"
Geolocation-Error: 200 ; code="Permission To Use Location Information"
地理定位误差：200；code=“使用位置信息的权限”
Geolocation-Error: 300 ; code="Dereference Failure"
Geolocation-Error: 300 ; code="Dereference Failure"
If an error recipient cannot process a specific error code (such as the 201 or 202 below), perhaps because it does not understand that specific error code, the error recipient SHOULD process the error code as if it originally were a top-level error code where the X in X00 matches the specific error code. If the error recipient cannot process a non-100 error code, for whatever reason, then the error code 100 MUST be processed.
如果错误接收者无法处理特定错误代码（如下面的201或202），可能是因为它不理解该特定错误代码，那么错误接收者应该处理该错误代码，就像它最初是一个顶级错误代码一样，其中X00中的X与特定错误代码匹配。如果错误接收者由于任何原因无法处理非100错误代码，则必须处理错误代码100。
There are two specific Geolocation-Error codes necessary to include in this document, both have to do with permissions necessary to process the SIP request; they are
本文档中需要包含两个特定的地理位置错误代码，它们都与处理SIP请求所需的权限有关；他们是
Geolocation-Error: 201 ; code="Permission To Retransmit Location Information to a Third Party"
地理定位误差：201；code=“向第三方重新传输位置信息的权限”
This location error is specific to having the PIDF-LO [RFC4119] <retransmission-allowed> element set to "no". This location error is stating it requires permission (i.e., PIDF-LO <retransmission-allowed> element set to "yes") to process this SIP request further. If the LS sending the location information does not want to give this permission, it will not change this permission in a new request. If the LS wants this message processed with the <retransmission-allowed> element set to "yes", it MUST choose another logical path (if one exists) for this SIP request.
此位置错误是由于PIDF-LO[RFC4119]<允许重传>元素设置为“否”造成的。此位置错误表示需要权限（即PIDF-LO<允许重传>元素设置为“是”）才能进一步处理此SIP请求。如果发送位置信息的LS不想授予此权限，则不会在新请求中更改此权限。如果LS希望在<retransmission allowed>元素设置为“yes”的情况下处理此消息，则必须为此SIP请求选择另一个逻辑路径（如果存在）。
Geolocation-Error: 202 ; code="Permission to Route based on Location Information"
地理定位误差：202；code=“基于位置信息的路由权限”
This location error is specific to having the Geolocation-Routing header value set to "no". This location error is stating it requires permission (i.e., the Geolocation-Routing header value set to "yes") to process this SIP request further. If the LS sending the location information does not want to give this permission, it will not change this permission in a new request. If the LS wants this message
此位置错误特定于将地理位置路由标头值设置为“否”。此位置错误表示需要权限（即，地理位置路由标头值设置为“是”）才能进一步处理此SIP请求。如果发送位置信息的LS不想授予此权限，则不会在新请求中更改此权限。如果LS想要这个消息
processed with the <retransmission-allowed> element set to "yes", it MUST choose another logical path (if one exists) for this SIP request.
当<retransmission allowed>元素设置为“yes”时，它必须为此SIP请求选择另一个逻辑路径（如果存在）。
In the case where an LR sends a 424 response and wishes to communicate suitable location-by-reference rather than location-by-value, the 424 response MUST include a content-indirection body per RFC 4483.
在LR发送424响应并且希望通过引用而不是通过值传递适当位置的情况下，424响应必须包括符合RFC 4483的内容间接主体。
The following is part of the discussion started in Section 3, Figure 2, which introduced the concept of sending location indirectly.
下面是从第3节图2开始的讨论的一部分，它介绍了间接发送位置的概念。
If a location URI is included in a SIP request, the sending user agent MUST also include a Supported header field indicating which location profiles it supports. Two option tags for location profiles are defined by this document: "geolocation-sip" and "geolocation-http". Future specifications MAY define further location profiles per the IANA policy described in Section 8.3.
如果SIP请求中包含位置URI，则发送用户代理还必须包含受支持的头字段，指示其支持的位置配置文件。本文档定义了位置配置文件的两个选项标记：“地理位置sip”和“地理位置http”。未来的规范可能会根据第8.3节所述的IANA政策定义更多的位置配置文件。
The "geolocation-sip" option tag signals support for acquiring location information via the presence event package of SIP [RFC3856]. A location recipient who supports this option can send a SUBSCRIBE request and parse a resulting NOTIFY containing a PIDF-LO object. The URI schemes supported by this option include "sip", "sips", and "pres".
“地理位置sip”选项标记支持通过sip[RFC3856]的存在事件包获取位置信息。支持此选项的位置收件人可以发送订阅请求并解析包含PIDF-LO对象的结果通知。此选项支持的URI方案包括“sip”、“sips”和“pres”。
The "geolocation-http" option tag signals support for acquiring location information via HTTP [RFC2616]. A location recipient who supports this option can request location with an HTTP GET and parse a resulting 200 response containing a PIDF-LO object. The URI schemes supported by this option include "http" and "https". A failure to parse the 200 response, for whatever reason, will return a "Dereference Failure" indication to the original location sending user agent to inform it that location was not delivered as intended.
“geolocation http”选项标记支持通过http[RFC2616]获取位置信息。支持此选项的位置收件人可以使用HTTP GET请求位置，并解析包含PIDF-LO对象的结果200响应。此选项支持的URI方案包括“http”和“https”。无论出于何种原因，解析200响应失败都会向发送用户代理的原始位置返回“取消引用失败”指示，以通知其位置未按预期交付。
If the location URI receiver does not understand the URI scheme sent to it, it will return an Unsupported header value of the option tag from the SIP request, and include the option tag of the preferred URI scheme in the response's Supported header field.
如果位置URI接收器不理解发送给它的URI方案，它将从SIP请求返回选项标记的不受支持的标头值，并在响应的受支持标头字段中包含首选URI方案的选项标记。
See [GEO-FILTERS] or [HELD-DEREF] for more details on dereferencing location information.
有关取消引用位置信息的更多详细信息，请参阅[GEO-FILTERS]或[HOLD-DEREF]。
This example shows an INVITE message with a coordinate location. In this example, the SIP request uses a sips-URI [RFC3261], meaning this message is protected using Transport Layer Security (TLS) on a hop-by-hop basis.
此示例显示了带有坐标位置的INVITE消息。在此示例中，SIP请求使用sips URI[RFC3261]，这意味着该消息在逐跳的基础上使用传输层安全性（TLS）进行保护。
INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: <cid:target123@atlanta.example.com> Geolocation-Routing: no Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: <sips:alice@atlanta.example.com> Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ...
邀请SIP：bob@biloxi.example.comSIP/2.0 Via:SIPS/2.0/TLS pc33.atlanta.example.com；分支=z9hG4bK74bf9最大转发：70到：Bob<sips:bob@biloxi.example.com>发件人：Alice<sips:alice@atlanta.example.com>;tag=9fxced76sl呼叫ID:3848276298220188511@atlanta.example.com地理位置：<cid:target123@atlanta.example.com>地理定位路由：不接受：应用程序/sdp，应用程序/pidf+xml CSeq:31862邀请联系人：<sips:alice@atlanta.example.com>内容类型：多部分/混合；边界=边界1内容长度：。。。
--boundary1
--边界1
Content-Type: application/sdp
Content-Type: application/sdp
...Session Description Protocol (SDP) goes here
…会话描述协议（SDP）位于此处
--boundary1
--边界1
Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:alice@atlanta.example.com">
<dm:device id="target123-1">
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32.86726 -97.16054</gml:pos>
Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:alice@atlanta.example.com">
<dm:device id="target123-1">
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32.86726 -97.16054</gml:pos>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>802.11</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
--boundary1--
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>802.11</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
--boundary1--
The Geolocation header field from the above INVITE:
上述邀请中的地理位置标头字段：
Geolocation: <cid:target123@atlanta.example.com>
Geolocation: <cid:target123@atlanta.example.com>
... indicates the content-ID location [RFC2392] within the multipart message body of where location information is. The other message body part is SDP. The "cid:" eases message body parsing and disambiguates multiple parts of the same type.
... 指示位置信息所在的多部分消息正文中的内容ID位置[RFC2392]。另一个消息主体部分是SDP。“cid:”简化了消息体解析并消除了同一类型的多个部分的歧义。
If the Geolocation header field did not contain a "cid:" scheme, for example, it could look like this location URI:
例如，如果Geolocation标头字段不包含“cid:”方案，则它可能看起来像以下位置URI：
Geolocation: <sips:target123@server5.atlanta.example.com>
Geolocation: <sips:target123@server5.atlanta.example.com>
... the existence of a non-"cid:" scheme indicates this is a location URI, to be dereferenced to learn the Target's location. Any node wanting to know where the target is located would subscribe to the SIP presence event package [RFC3856] at:
... 非-cid:“模式的存在表明这是一个位置URI，要解引用以了解目标的位置。任何想要知道目标位置的节点都将在以下位置订阅SIP状态事件包[RFC3856]：
sips:target123@server5.atlanta.example.com
啜饮：target123@server5.atlanta.example.com
(see Figure 2 in Section 3.2 for this message flow).
（有关此消息流，请参见第3.2节中的图2）。
This example shows the INVITE message after a SIP intermediary rejected the original INVITE (say, the one in Section 5.1). This INVITE contains the composed LO sent by the SIP intermediary that includes where the intermediary understands Alice to be. The rules of RFC 5491 [RFC5491] are followed in this construction.
本例显示了SIP中介拒绝原始INVITE（例如，第5.1节中的INVITE）后的INVITE消息。此INVITE包含SIP中介发送的合成LO，其中包括中介理解Alice所在的位置。此构造遵循RFC 5491[RFC5491]的规则。
This example is here, but ought not be taken as occurring very often. In fact, this example is believed to be a corner case of location conveyance applicability.
这个例子就在这里，但不应该被视为经常发生。事实上，这个例子被认为是位置运输适用性的一个极端情况。
INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188512@atlanta.example.com Geolocation: <cid:target123@atlanta.example.com> Geolocation-Routing: no Accept: application/sdp, application/pidf+xml CSeq: 31863 INVITE Contact: <sips:alice@atlanta.example.com> Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ...
邀请SIP：bob@biloxi.example.comSIP/2.0 Via:SIPS/2.0/TLS pc33.atlanta.example.com；分支=z9hG4bK74bf0最大转发：70到：Bob<sips:bob@biloxi.example.com>发件人：Alice<sips:alice@atlanta.example.com>;tag=9fxced76sl呼叫ID:3848276298220188512@atlanta.example.com地理位置：<cid:target123@atlanta.example.com>地理定位路由：不接受：应用程序/sdp，应用程序/pidf+xml CSeq:31863邀请联系人：<sips:alice@atlanta.example.com>内容类型：多部分/混合；边界=边界1内容长度：。。。
--boundary1
--边界1
Content-Type: application/sdp
Content-Type: application/sdp
...SDP goes here
…SDP在这里
--boundary1
--边界1
Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:alice@atlanta.example.com">
<dm:device id="target123-1">
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32.86726 -97.16054</gml:pos>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false
Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:alice@atlanta.example.com">
<dm:device id="target123-1">
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32.86726 -97.16054</gml:pos>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>802.11</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device>
<dm:person id="target123">
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>Texas</cl:A1>
<cl:A3>Colleyville</cl:A3>
<cl:RD>Treemont</cl:RD>
<cl:STS>Circle</cl:STS>
<cl:HNO>3913</cl:HNO>
<cl:FLR>1</cl:FLR>
<cl:NAM>Haley's Place</cl:NAM>
<cl:PC>76034</cl:PC>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>triangulation</gp:method>
</gp:geopriv>
<dm:timestamp>2010-11-04T12:28:04Z</dm:timestamp>
</dm:person>
</presence>
--boundary1--
</gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>802.11</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device>
<dm:person id="target123">
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>Texas</cl:A1>
<cl:A3>Colleyville</cl:A3>
<cl:RD>Treemont</cl:RD>
<cl:STS>Circle</cl:STS>
<cl:HNO>3913</cl:HNO>
<cl:FLR>1</cl:FLR>
<cl:NAM>Haley's Place</cl:NAM>
<cl:PC>76034</cl:PC>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>triangulation</gp:method>
</gp:geopriv>
<dm:timestamp>2010-11-04T12:28:04Z</dm:timestamp>
</dm:person>
</presence>
--boundary1--
Location information is considered by most to be highly sensitive information, requiring protection from eavesdropping and altering in transit. [RFC3693] originally articulated rules to be followed by any protocol wishing to be considered a "Using Protocol", specifying how a transport protocol meets those rules. [RFC6280] updates the guidance in RFC 3693 to include subsequently introduced entities and concepts in the geolocation architecture.
大多数人认为位置信息是高度敏感的信息，需要防止在传输过程中被窃听和篡改。[RFC3693]最初阐明了任何希望被视为“使用协议”的协议所遵循的规则，规定了传输协议如何满足这些规则。[RFC6280]更新了RFC 3693中的指南，将随后引入的实体和概念包括在地理定位体系结构中。
RFC 5606 explores the difficulties inherent in mapping the GEOPRIV architecture onto SIP elements. In particular, the difficulties of defining and identifying recipients of location information are given in that document, along with guidance in Section 3.3.2 on the use of location-by-reference mechanisms to preserve confidentiality of location information from unauthorized recipients.
RFC 5606探讨了将GEOPRIV体系结构映射到SIP元素的固有困难。特别是，该文件中给出了定义和识别位置信息接收者的困难，以及第3.3.2节中关于使用参考位置机制保护未经授权接收者位置信息机密性的指南。
In a SIP deployment, location information may be added by any of several elements, including the originating user agent or a proxy server. In all cases, the Rule Maker associated with that location information decides which entity adds location information and what access control rules apply. For example, a SIP user agent that does not support the Geolocation header may rely on a proxy server under the direction of the Rule Maker adding a Geolocation header with a reference to location information. The manner in which the Rule Maker operates on these devices is outside the scope of this document.
在SIP部署中，位置信息可以由多个元素中的任何一个添加，包括发起用户代理或代理服务器。在所有情况下，与该位置信息关联的规则制定者决定哪个实体添加位置信息以及应用何种访问控制规则。例如，不支持地理位置报头的SIP用户代理可以在规则制定者的指导下依赖代理服务器，添加对位置信息的引用的地理位置报头。规则制定者在这些设备上的操作方式超出了本文档的范围。
The manner in which SIP implementations honor the Rule Maker's stipulations for access control rules (including retention and retransmission) is application specific and not within the scope of SIP protocol operations. Entities in SIP networks that fulfill the architectural roles of the Location Server or Location Recipient treat the privacy rules associated with location information per the guidance in [RFC6280], Section 4.2.1. In particular, RFC 4119 (especially Section 2.2.2) gives guidance for handling access control rules; SIP implementations should furthermore consult the recommendations in RFC 5606.
SIP实现遵守规则制定者关于访问控制规则（包括保留和重传）的规定的方式是特定于应用程序的，不在SIP协议操作的范围内。根据[RFC6280]第4.2.1节中的指南，SIP网络中履行位置服务器或位置接收者体系结构角色的实体处理与位置信息相关的隐私规则。特别是，RFC 4119（特别是第2.2.2节）提供了处理访问控制规则的指南；SIP实施还应参考RFC 5606中的建议。
Conveyance of physical location of a UA raises privacy concerns, and depending on use, there probably will be authentication and integrity concerns. This document calls for conveyance to be accomplished through secure mechanisms, like Secure/Multipurpose Internet Mail Extensions (S/MIME) encrypting message bodies (although this is not widely deployed), TLS protecting the overall signaling or conveyance location-by-reference and requiring all entities that dereference location to authenticate themselves. In location-based routing cases, encrypting the location payload with an end-to-end mechanism such as S/MIME is problematic because one or more proxies on the path need the ability to read the location information to retarget the message to the appropriate new destination User Agent Server (UAS). Data can only be encrypted to a particular, anticipated target, and thus if multiple recipients need to inspect a piece of data, and those recipients cannot be predicted by the sender of data, encryption is not a very feasible choice. Securing the location hop-by-hop, using TLS, protects the message from eavesdropping and
UA物理位置的传输会引起隐私问题，根据使用情况，可能会存在身份验证和完整性问题。本文件要求通过安全机制实现传输，如安全/多用途Internet邮件扩展（S/MIME）加密邮件正文（尽管尚未广泛部署），TLS通过引用保护整个信令或传输位置，并要求解除引用位置的所有实体进行身份验证。在基于位置的路由情况下，使用端到端机制（如S/MIME）加密位置有效负载是有问题的，因为路径上的一个或多个代理需要能够读取位置信息以将消息重新定向到适当的新目标用户代理服务器（UAS）。数据只能加密到特定的预期目标，因此，如果多个接收者需要检查一段数据，并且数据发送者无法预测这些接收者，则加密不是一个非常可行的选择。使用TLS逐跳保护位置，防止消息被窃听和丢失
modification in transit, but exposes the information to all proxies on the path as well as the endpoint. In most cases, the UA has no trust relationship with the proxy or proxies providing location-based routing services, so such end-to-middle solutions might not be appropriate either.
修改正在进行中，但将信息公开给路径上的所有代理以及端点。在大多数情况下，UA与提供基于位置的路由服务的一个或多个代理没有信任关系，因此这种端到端解决方案可能也不合适。
When location information is conveyed by reference, however, one can properly authenticate and authorize each entity that wishes to inspect location information. This does not require that the sender of data anticipate who will receive data, and it does permit multiple entities to receive it securely; however, it does not obviate the need for pre-association between the sender of data and any prospective recipients. Obviously, in some contexts, this pre-association cannot be presumed; when it is not, effectively unauthenticated access to location information MUST be permitted. In this case, choosing pseudorandom URIs for location-by-reference, coupled with path encryption like Session Initiation Protocol Secure (SIPS), can help to ensure that only entities on the SIP signaling path learn the URI, and thus restores rough parity with sending location-by-value.
然而，当通过引用传递位置信息时，可以正确地对希望检查位置信息的每个实体进行身份验证和授权。这并不要求数据发送者预测谁将接收数据，并且允许多个实体安全地接收数据；然而，它并不排除数据发送者和任何潜在接收者之间预先关联的需要。显然，在某些情况下，这种预关联是不可推定的；否则，必须允许对位置信息进行有效的未经验证的访问。在这种情况下，选择伪随机URI作为参考位置，再加上像会话启动协议安全（SIPS）这样的路径加密，可以帮助确保只有SIP信令路径上的实体才能学习URI，从而恢复与按值发送位置的大致奇偶校验。
Location information is especially sensitive when the identity of its Target is obvious. Note that there is the ability, according to [RFC3693], to have an anonymous identity for the Target's location. This is accomplished by the use of an unlinkable pseudonym in the "entity=" attribute of the <presence> element [RFC4479]. Though, this can be problematic for routing messages based on location (covered in [RFC4479]). Moreover, anyone fishing for information would correlate the identity at the SIP layer with that of the location information referenced by SIP signaling.
当目标的身份明显时，位置信息尤其敏感。请注意，根据[RFC3693]，可以为目标位置提供匿名身份。这是通过在<presence>元素[RFC4479]的“entity=”属性中使用不可链接的笔名来实现的。但是，这对于基于位置的消息路由来说可能会有问题（参见[RFC4479]）。此外，任何寻找信息的人都会将SIP层的身份与SIP信令引用的位置信息的身份关联起来。
When a UA inserts location, the UA sets the policy on whether to reveal its location along the signaling path -- as discussed in Section 4, as well as flags in the PIDF-LO [RFC4119]. UAC implementations MUST make such capabilities conditional on explicit user permission, and MUST alert the user that location is being conveyed.
当UA插入位置时，UA设置是否沿信令路径显示其位置的策略——如第4节所述，以及PIDF-LO[RFC4119]中的标志。UAC实现必须使此类功能以明确的用户权限为条件，并且必须提醒用户正在传送位置。
This SIP extension offers the default ability to require permission to process location while the SIP request is in transit. The default for this is set to "no". There is an error explicitly describing how an intermediary asks for permission to view the Target's location, plus a rule stating the user has to be made aware of this permission request.
此SIP扩展提供了在SIP请求传输过程中请求处理位置权限的默认功能。默认设置为“否”。有一个错误明确描述了中介如何请求查看目标位置的权限，另外还有一个规则说明必须让用户知道此权限请求。
There is no end-to-end integrity on any locationValue or locationErrorValue header field parameter (or middle-to-end if the value was inserted by a intermediary), so recipients of either header field need to implicitly trust the header field contents, and take whatever precautions each entity deems appropriate given this situation.
任何locationValue或locationErrorValue标头字段参数都没有端到端的完整性（如果该值是由中介插入的，则为中间到端），因此任一标头字段的收件人都需要隐式信任标头字段内容，并在这种情况下采取每个实体认为适当的预防措施。
The following are the IANA considerations made by this SIP extension. Modifications and additions to all these registrations require a Standards Track RFC (Standards Action).
以下是此SIP扩展对IANA的考虑。所有这些注册的修改和添加都需要标准跟踪RFC（标准行动）。
The SIP Geolocation header field is created by this document, with its definition and rules in Section 4.1 of this document, and it has been added to the IANA sip-parameters registry as follows:
SIP Geolocation header字段由本文档创建，其定义和规则见本文档第4.1节，并已添加到IANA SIP参数注册表中，如下所示：
The Header Fields registry has been updated with:
标题字段注册表已更新为：
Header Name Compact Reference
----------------- ------- ---------
Geolocation [RFC6442]
Header Name Compact Reference
----------------- ------- ---------
Geolocation [RFC6442]
The SIP Geolocation-Routing header field is created by this document, with its definition and rules in Section 4.2 of this document, and it has been added to the IANA sip-parameters registry as follows.
SIP Geolocation Routing header字段由本文档创建，其定义和规则见本文档第4.2节，并已添加到IANA SIP参数注册表中，如下所示。
The Header Fields registry has been updated with:
标题字段注册表已更新为：
Header Name Compact Reference
----------------- ------- ---------
Geolocation-Routing [RFC6442]
Header Name Compact Reference
----------------- ------- ---------
Geolocation-Routing [RFC6442]
This document defines two new SIP option tags: "geolocation-sip" and "geolocation-http" that have been added to the IANA sip-parameters Options Tags registry as follows.
本文档定义了两个新的SIP选项标记：“地理位置SIP”和“地理位置http”，它们已添加到IANA SIP参数选项标记注册表中，如下所示。
Name Description Reference
----------- ------------------------------------------ ---------
geolocation-sip The "geolocation-sip" option tag signals [RFC6442]
support for acquiring location information
via the presence event package of SIP
(RFC 3856). A location recipient who
supports this option can send a SUBSCRIBE
request and parse a resulting NOTIFY
containing a PIDF-LO object. The URI
schemes supported by this option include
"sip", "sips", and "pres".
Name Description Reference
----------- ------------------------------------------ ---------
geolocation-sip The "geolocation-sip" option tag signals [RFC6442]
support for acquiring location information
via the presence event package of SIP
(RFC 3856). A location recipient who
supports this option can send a SUBSCRIBE
request and parse a resulting NOTIFY
containing a PIDF-LO object. The URI
schemes supported by this option include
"sip", "sips", and "pres".
geolocation-http The "geolocation-http" option tag signals [RFC6442] support for acquiring location information via HTTP (RFC 2616). A location recipient who supports this option can request location with an HTTP GET and parse a resulting 200 response containing a PIDF-LO object. The URI schemes supported by this option include "http" and "https".
地理位置http“地理位置http”选项标记[RFC6442]支持通过http（RFC 2616）获取位置信息。支持此选项的位置收件人可以使用HTTP GET请求位置，并解析包含PIDF-LO对象的结果200响应。此选项支持的URI方案包括“http”和“https”。
The names of profiles are SIP option tags, and the guidance in this document does not supersede the option tag assignment guidance in [RFC3261] (which requires a Standards Action for the assignment of a new option tag). However, this document does stipulate that option tags included to convey the name of a location profile per this definition MUST begin with the string "geolocation" followed by a dash. All such option tags should describe protocols used to acquire location by reference: these tags have no relevance to location carried in SIP requests by value, which use standard MIME typing and negotiation.
配置文件的名称为SIP选项标签，本文件中的指南不取代[RFC3261]中的选项标签分配指南（该指南要求分配新选项标签的标准操作）。但是，本文件规定，根据本定义，用于传达位置配置文件名称的选项标签必须以字符串“geolocation”开头，后跟破折号。所有这些选项标签都应该描述用于通过引用获取位置的协议：这些标签与SIP请求中的位置无关，而SIP请求使用标准MIME类型和协商。
In the SIP Response Codes registry, the following is added
在SIP响应代码注册表中，添加了以下内容
Reference: RFC 6442 Response code: 424 (recommended number to assign) Default reason phrase: Bad Location Information
参考：RFC 6442响应代码：424（建议分配的号码）默认原因短语：错误位置信息
Registry:
Response Code Reference
------------------------------------------ ---------
Request Failure 4xx
424 Bad Location Information [RFC6442]
Registry:
Response Code Reference
------------------------------------------ ---------
Request Failure 4xx
424 Bad Location Information [RFC6442]
This SIP Response code is defined in Section 4.3 of this document.
本文件第4.3节定义了SIP响应代码。
The SIP Geolocation-Error header field is created by this document, with its definition and rules in Section 4.4 of this document, to be added to the IANA sip-parameters registry with two actions
SIP Geolocation Error header字段由本文档创建，其定义和规则见本文档第4.4节，将通过两个操作添加到IANA SIP参数注册表中
1. Update the Header Fields registry with:
1. 使用以下内容更新标题字段注册表：
Registry:
Header Name Compact Reference
----------------- ------- ---------
Geolocation-Error [RFC6442]
Registry:
Header Name Compact Reference
----------------- ------- ---------
Geolocation-Error [RFC6442]
2. In the portion titled "Header Field Parameters and Parameter Values", add: Predefined Header Field Parameter Name Values Reference ----------------- ------------------- ---------- --------- Geolocation-Error code yes [RFC6442]
2. 在标题为“标题字段参数和参数值”的部分中，添加：预定义标题字段参数名称值参考-----------------------------------地理位置错误代码是[RFC6442]
This document creates a new registry for SIP, called "Geolocation-Error Codes". Geolocation-Error codes provide reason for the error discovered by Location Recipients, categorized by action to be taken by error recipient. The initial values for this registry are shown below.
本文档为SIP创建了一个新的注册表，称为“地理位置错误代码”。地理位置错误代码提供位置收件人发现错误的原因，并按错误收件人要采取的操作分类。此注册表的初始值如下所示。
Registry Name: Geolocation-Error Codes Reference: [RFC6442] Registration Procedures: Specification Required
注册表名称：地理位置错误代码参考：[RFC6442]注册过程：需要规范
Code Default Reason Phrase Reference
---- --------------------------------------------------- ---------
100 "Cannot Process Location" [RFC6442]
Code Default Reason Phrase Reference
---- --------------------------------------------------- ---------
100 "Cannot Process Location" [RFC6442]
200 "Permission To Use Location Information" [RFC6442]
200“使用位置信息的许可”[RFC6442]
201 "Permission To Retransmit Location Information to a Third Party" [RFC6442]
201“向第三方重新传输位置信息的许可”[RFC6442]
202 "Permission to Route based on Location Information" [RFC6442]
202“基于位置信息的路线许可”[RFC6442]
300 "Dereference Failure" [RFC6442]
300“解引用失败”[RFC6442]
Details of these error codes are in Section 4.4 of this document.
这些错误代码的详细信息见本文件第4.4节。
To Dave Oran for helping to shape this idea.
感谢Dave Oran帮助形成了这个想法。
To Dean Willis for guidance of the effort.
请迪安·威利斯指导这项工作。
To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard Barnes, Dan Wing, Matt Lepinski, John Elwell, Thomas Stach, Jacqueline Lee, and Adam Roach for constructive feedback and nit checking.
致Allison Mankin、Dick Knight、Hannes Tschofenig、Henning Schulzrinne、James Winterbottom、Jeroen van Bemmel、Jean-Francois Mule、Jonathan Rosenberg、Keith Drage、Marc Linsner、Martin Thomson、Mike Hammer、Ted Hardie、Shida Shubert、Umesh Sharma、Richard Barnes、Dan Wing、Matt Lepinski、John Elwell、Thomas Stach、Jacqueline Lee、，和亚当·罗奇进行建设性的反馈和吹毛求疵的检查。
Special thanks to Paul Kyzivat for his help with the ABNF in this document and to Robert Sparks for many helpful comments and the proper construction of the Geolocation-Error header field.
特别感谢Paul Kyzivat在本文档中对ABNF的帮助，以及Robert Sparks的许多有用评论和地理位置错误标题字段的正确构造。
And finally, to Spencer Dawkins for giving this document a good scrubbing to make it more readable.
最后，感谢斯宾塞·道金斯（Spencer Dawkins）对本文档进行了良好的整理，使其更具可读性。
[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月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]Peterson，J.，“一种基于状态的GEOPRIV定位对象格式”，RFC41192005年12月。
[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月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]Levinson，E.“内容ID和消息ID统一资源定位器”，RFC 2392，1998年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月。
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[RFC3859]彼得森，J.，“存在的共同特征（CPP）”，RFC3859，2004年8月。
[RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]Campbell，B.，Ed.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, January 2011.
[RFC6086]Holmberg，C.，Burger，E.，和H.Kaplan，“会话初始化协议（SIP）信息方法和包框架”，RFC 6086，2011年1月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903]Niemi，A.，编辑，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，2004年10月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479]Rosenberg，J.，“存在的数据模型”，RFC 4479，2006年7月。
[RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4483]Burger，E.，Ed.“会话初始化协议（SIP）消息中的内容间接寻址机制”，RFC 4483，2006年5月。
[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月。
[RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, June 2010.
[RFC5870]Mayrhofer，A.和C.Sparing，“地理位置的统一资源标识符（‘地理’URI）”，RFC 58702010年6月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[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月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of 'retransmission-allowed' for SIP Location Conveyance", RFC 5606, August 2009.
[RFC5606]Peterson，J.，Hardie，T.，和J.Morris，“SIP位置传输的‘允许重传’影响”，RFC 5606，2009年8月。
[GEO-FILTERS] Mahy, R., Rosen, B., and H. Tschofenig, "Filtering Location Notifications in SIP", Work in Progress, March 2010.
[GEO-FILTERS]Mahy，R.，Rosen，B.，和H.Tschofenig，“在SIP中过滤位置通知”，正在进行的工作，2010年3月。
[HELD-DEREF] Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, M., and M. Dawson, "A Location Dereferencing Protocol Using HELD", Work in Progress, October 2011.
[Hold-DEREF]Winterbottom，J.，Tschofenig，H.，Schulzrinne，H.，Thomson，M.，和M.Dawson，“使用Hold的位置解引用协议”，正在进行的工作，2011年10月。
[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月。
The following subsections address the requirements placed on the UAC, the UAS, as well as SIP proxies when conveying location. This text is from a draft version of the location conveyance requirements that has since evolved into this document (RFC 6442). It has been kept for historical reasons.
以下小节介绍了在传送位置时对UAC、UAS以及SIP代理的要求。本文本来源于《位置运输要求》草案，该草案后来演变为本文件（RFC 6442）。由于历史原因，它一直保留着。
If a requirement is not obvious in intent, a motivational statement is included below it.
如果某项要求的意图不明显，则应在其下方附上动机陈述。
UAC-1 The SIP INVITE Method [RFC3261] must support location conveyance.
UAC-1 SIP INVITE方法[RFC3261]必须支持位置传输。
UAC-2 The SIP MESSAGE method [RFC3428] must support location conveyance.
UAC-2 SIP消息方法[RFC3428]必须支持位置传输。
UAC-3 SIP Requests within a dialog should support location conveyance.
对话框中的UAC-3 SIP请求应支持位置传输。
UAC-4 Other SIP Requests may support location conveyance.
UAC-4其他SIP请求可能支持位置传输。
UAC-5 There must be one, mandatory-to-implement means of transmitting location confidentially.
UAC-5必须有一个，强制实施秘密传输位置的方法。
Motivation: To guarantee interoperability.
动机：保证互操作性。
UAC-6 It must be possible for a UAC to update location conveyed at any time in a dialog, including during dialog establishment.
UAC-6 UAC必须能够随时更新对话中传达的位置，包括在对话建立期间。
Motivation: If a UAC has moved prior to the establishment of a dialog between UAs, the UAC must be able to send location information. If location has been conveyed, and the UA moves, the UAC must be able to update the location previously conveyed to other parties.
动机：如果UAC在UAs之间建立对话之前已经移动，UAC必须能够发送位置信息。如果位置已传达，且UA已移动，则UAC必须能够更新先前传达给其他方的位置。
UAC-7 The privacy and security rules established within [RFC3693] that would categorize SIP as a 'Using Protocol' MUST be met.
UAC-7必须满足[RFC3693]中建立的将SIP归类为“使用协议”的隐私和安全规则。
UAC-8 The PIDF-LO [RFC4119] is a mandatory-to-implement format for location conveyance within SIP.
UAC-8 PIDF-LO[RFC4119]是在SIP中实现位置传输的强制格式。
Motivation: Interoperability with other IETF location protocols and Mechanisms.
动机：与其他IETF定位协议和机制的互操作性。
UAC-9 There must be a mechanism for the UAC to request the UAS send its location.
UAC-9必须有UAC请求UAS发送其位置的机制。
UAC-9 has been DEPRECATED by the SIP WG, due to the many problems this requirement would have caused if implemented. The solution is for the above UAS to send a new request to the original UAC with the UAS's location.
UAC-9已被SIP工作组弃用，因为如果实施该要求，将导致许多问题。解决方案是，上述UAS向原始UAC发送一个新请求，其中包含UAS的位置。
UAC-10 There must be a mechanism to differentiate the ability of the UAC to convey location from the UACs lack of knowledge of its location.
UAC-10必须有一种机制来区分UAC传达位置的能力和UAC不知道其位置的能力。
Motivation: Failure to receive location when it is expected can happen because the UAC does not implement this extension, or because the UAC implements the extension, but does not know where the Target is. This may be, for example, due to the failure of the access network to provide a location acquisition mechanism the UAC supports. These cases must be differentiated.
动机：由于UAC没有实现此扩展，或者因为UAC实现了此扩展，但不知道目标在哪里，因此可能会在预期的时间内接收位置失败。例如，这可能是由于接入网络未能提供UAC支持的位置获取机制。必须区分这些情况。
UAC-11 It must be possible to convey location to proxy servers along the path.
UAC-11必须能够沿路径将位置传递给代理服务器。
Motivation: Location-based routing.
动机：基于位置的路由。
The following are the requirements for location conveyance by a UAS:
以下是UAS位置传输的要求：
UAS-1 SIP Responses must support location conveyance.
UAS-1 SIP响应必须支持位置传输。
The SIPCORE WG reached consensus that this be allowed, but not to communicate the UAS's location; rather for a SIP intermediary to inform the UAC which location to include in its next SIP request (as a matter of correcting what was originally sent by the UAC).
SIPCORE工作组达成共识，允许这样做，但不告知UAS的位置；而是让SIP中介通知UAC在其下一个SIP请求中包括哪个位置（作为纠正UAC最初发送的内容的问题）。
UAS-2 There must be a unique 4XX response informing the UAC it did not provide applicable location information.
UAS-2必须有一个独特的4XX响应，通知UAC它没有提供适用的位置信息。
In addition, requirements UAC-5, 6, 7, and 8 also apply to the UAS.
此外，UAC-5、6、7和8的要求也适用于UAS。
The following are the requirements for location conveyance by a SIP proxies and intermediaries:
以下是SIP代理和中介机构的位置传输要求：
Proxy-1 Proxy servers must be capable of adding a Location header field during processing of SIP requests.
Proxy-1代理服务器必须能够在处理SIP请求期间添加位置标头字段。
Motivation: Provide network assertion of location when UACs are unable to do so, or when network assertion is more reliable than UAC assertion of location
动机：当UAC无法这样做时，或者当网络断言比UAC位置断言更可靠时，提供位置的网络断言
Note: Because UACs connected to SIP signaling networks can have widely varying access network arrangements, including VPN tunnels and roaming mechanisms, it can be difficult for a network to reliably know the location of the endpoint. Proxies SHOULD NOT assert location of an endpoint unless the SIP signaling network has reliable knowledge of the actual location of the Targets.
注意：由于连接到SIP信令网络的UAC可以具有广泛变化的接入网络安排，包括VPN隧道和漫游机制，因此网络很难可靠地知道端点的位置。除非SIP信令网络对目标的实际位置有可靠的了解，否则代理不应该断言端点的位置。
Proxy-2 There must be a unique 4XX response informing the UAC it did not provide applicable location information.
Proxy-2必须有一个独特的4XX响应，通知UAC它没有提供适用的位置信息。
Authors' Addresses
作者地址
James Polk Cisco Systems 3913 Treemont Circle Colleyville, Texas 76034
James Polk Cisco Systems 3913德克萨斯州特雷蒙特圆科利维尔76034
33.00111N 96.68142W
33.00111N 96.68142W
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Brian Rosen NeuStar, Inc. 470 Conrad Dr. Mars, PA 16046
布莱恩·罗森·纽斯塔公司，宾夕法尼亚州康拉德·马尔斯博士，邮编：16046
40.70497N 80.01252W
40.70497N 80.01252W
Phone: +1 724 382 1051
EMail: br@brianrosen.net
Phone: +1 724 382 1051
EMail: br@brianrosen.net
Jon Peterson NeuStar, Inc.
乔恩·彼得森纽斯达公司。
EMail: jon.peterson@neustar.biz
EMail: jon.peterson@neustar.biz