Network Working Group J. Peterson
Request for Comments: 3323 Neustar
Category: Standards Track November 2002
Network Working Group J. Peterson
Request for Comments: 3323 Neustar
Category: Standards Track November 2002
A Privacy Mechanism for the Session Initiation Protocol (SIP)
会话启动协议（SIP）的隐私机制
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document defines new mechanisms for the Session Initiation Protocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new "privacy service" logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service.
本文档定义了支持隐私的会话启动协议（SIP）的新机制。具体而言，为创建不泄露个人身份信息的消息提供了指南。为中介定义了一个新的“隐私服务”逻辑角色，以满足用户代理无法满足的一些隐私要求。最后，给出了用户可以从隐私服务请求特定功能的方法。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Varieties of Privacy . . . . . . . . . . . . . . . . . . . 4
3.1 When is Privacy Necessary? . . . . . . . . . . . . . . . . 5
3.2 User-Provided Privacy . . . . . . . . . . . . . . . . . . 6
3.3 Network-Provided Privacy . . . . . . . . . . . . . . . . . 7
4. User Agent Behavior . . . . . . . . . . . . . . . . . . . 7
4.1 Constructing Private Messages . . . . . . . . . . . . . . 8
4.1.1 URIs, Display-Names and Privacy . . . . . . . . . . . . . 8
4.1.1.1 Display-Names . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1.2 URI Usernames . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1.3 URI Hostnames and IP Addresses . . . . . . . . . . . . . . 9
4.2 Expressing Privacy Preferences . . . . . . . . . . . . . . 11
4.3 Routing Requests to Privacy Services . . . . . . . . . . . 12
4.4 Routing Responses to Privacy Services . . . . . . . . . . 13
5. Privacy Service Behavior . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Varieties of Privacy . . . . . . . . . . . . . . . . . . . 4
3.1 When is Privacy Necessary? . . . . . . . . . . . . . . . . 5
3.2 User-Provided Privacy . . . . . . . . . . . . . . . . . . 6
3.3 Network-Provided Privacy . . . . . . . . . . . . . . . . . 7
4. User Agent Behavior . . . . . . . . . . . . . . . . . . . 7
4.1 Constructing Private Messages . . . . . . . . . . . . . . 8
4.1.1 URIs, Display-Names and Privacy . . . . . . . . . . . . . 8
4.1.1.1 Display-Names . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1.2 URI Usernames . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1.3 URI Hostnames and IP Addresses . . . . . . . . . . . . . . 9
4.2 Expressing Privacy Preferences . . . . . . . . . . . . . . 11
4.3 Routing Requests to Privacy Services . . . . . . . . . . . 12
4.4 Routing Responses to Privacy Services . . . . . . . . . . 13
5. Privacy Service Behavior . . . . . . . . . . . . . . . . . 14
5.1 Header Privacy . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Session Privacy . . . . . . . . . . . . . . . . . . . . . 17
5.3 Applying User-Level Privacy Functions. . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 19
Normative References . . . . . . . . . . . . . . . . . . . 20
Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . 22
5.1 Header Privacy . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Session Privacy . . . . . . . . . . . . . . . . . . . . . 17
5.3 Applying User-Level Privacy Functions. . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 19
Normative References . . . . . . . . . . . . . . . . . . . 20
Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . 22
This document provides privacy requirements and mechanisms for the Session Initiation Protocol (SIP).
本文档提供会话启动协议（SIP）的隐私要求和机制。
Privacy is defined in this document as the withholding of the identity of a person (and related personal information) from one or more parties in an exchange of communications, specifically a SIP dialog. These parties potentially include the intended destination(s) of messages and/or any intermediaries handling these messages. As identity is defined in this document, withholding the identity of a user will, among other things, render the other parties in the dialog unable to send new SIP requests to the user outside of the context of the current dialog.
本文件将隐私定义为在通信交换中，特别是SIP对话中，从一方或多方扣留个人身份（和相关个人信息）。这些参与方可能包括消息的预期目的地和/或处理这些消息的任何中介。由于本文档中定义了标识，因此保留用户的标识将导致对话框中的其他各方无法在当前对话框的上下文之外向用户发送新的SIP请求。
In SIP, identity is most commonly carried in the form of a SIP URI and an optional display-name. A SIP address-of-record has a form similar to an email address with a SIP URI scheme (for example, sip:alice@atlanta.com). A display-name is a string containing a name for the identified user (for example, "Alice"). SIP identities of this form commonly appear in the To and From header fields of SIP requests and responses. A user may have many identities that they use in different contexts.
在SIP中，标识最常见的形式是SIPURI和可选的显示名称。记录的SIP地址具有类似于具有SIP URI方案的电子邮件地址的形式（例如，SIP:alice@atlanta.com). 显示名称是一个字符串，包含已识别用户的名称（例如，“Alice”）。这种形式的SIP标识通常出现在SIP请求和响应的“收件人”和“发件人”标题字段中。一个用户可能有许多在不同上下文中使用的身份。
There are numerous other places in SIP messages in which identity-related information can be revealed. For example, the Contact header field contains a SIP URI, one that is commonly as revealing as the address-of-record in the From. In some headers, the originating user agent can conceal identity information as a matter of local policy without affecting the operation of the SIP protocol. However, certain headers are used in the routing of subsequent messages in a dialog, and must therefore be populated with functional data.
SIP消息中还有许多其他地方可以显示与身份相关的信息。例如，Contact header字段包含一个SIPURI，该URI通常与From中记录的地址一样公开。在一些报头中，发起用户代理可以根据本地策略隐藏身份信息，而不影响SIP协议的操作。但是，某些标头用于对话框中后续消息的路由，因此必须用功能数据填充。
The privacy problem is further complicated by proxy servers (also referred to in this document as "intermediaries" or "the network") that add headers of their own, such as the Record-Route and Via headers. Information in these headers could inadvertently reveal something about the originator of a message; for example, a Via header might reveal the service provider through whom the user sends requests, which might in turn strongly hint at the user's identity to some recipients. For these reasons, the participation of intermediaries is also crucial to providing privacy in SIP.
由于代理服务器（在本文档中也称为“中介机构”或“网络”）添加了自己的头，例如记录路由和Via头，隐私问题变得更加复杂。这些标题中的信息可能会无意中透露有关消息发起者的信息；例如，Via头可能会显示用户通过其发送请求的服务提供商，这反过来可能会向某些收件人强烈提示用户的身份。由于这些原因，中间人的参与对于在SIP中提供隐私也是至关重要的。
Two complimentary principles have guided the design of this privacy mechanism: Users are empowered to hide their identity and related personal information when they issue requests, but intermediaries and designated recipients of requests are entitled to reject requests whose originator cannot be identified.
两个互补原则指导了这一隐私机制的设计：用户有权在发出请求时隐藏其身份和相关的个人信息，但中间人和指定的请求接收人有权拒绝无法确定发起人的请求。
The privacy properties of only those specific headers enumerated in the core SIP specification ([1]), as opposed to headers defined by any existing or planned extension, are discussed in this document - however, the privacy mechanisms described in this document can be extended to support extensions.
本文档仅讨论核心SIP规范（[1]）中列举的特定头的隐私属性，而不是任何现有或计划扩展所定义的头的隐私属性，但是，本文档中描述的隐私机制可以扩展以支持扩展。
There are other aspects of the general privacy problem for SIP that are not addressed by this document. Most significantly, the mechanisms for managing the confidentiality of SIP headers and bodies, as well the security of session traffic, are not reconsidered here. These problems are sufficiently well addressed in the baseline SIP specification and related documents, and that no new mechanisms are required.
SIP的一般隐私问题还有一些其他方面没有在本文档中解决。最重要的是，这里没有重新考虑用于管理SIP头和主体的机密性以及会话流量的安全性的机制。这些问题在基线SIP规范和相关文档中得到了充分的解决，并且不需要新的机制。
This document begins with a section that provides a general framework and architecture for privacy in SIP (Section 3), followed by sections that detail user agent behavior (Section 4) and privacy service behavior (Section 5).
本文档首先介绍SIP中隐私的一般框架和体系结构（第3节），然后详细介绍用户代理行为（第4节）和隐私服务行为（第5节）。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”将按照BCP 14、RFC 2119[2]中的描述进行解释，并指出合规SIP实施的要求级别。
A user may possess many identities that are used in various contexts; generally, identities are addresses-of-record which are bound to particular registrars (operated by the administrators of a domain) with whom SIP user agents register. The operators of these domains may be employers, service providers, or unaffiliated users themselves.
一个用户可能拥有许多在不同上下文中使用的身份；通常，标识是绑定到SIP用户代理注册的特定注册器（由域管理员操作）的记录地址。这些域的运营商可能是雇主、服务提供商或非关联用户本身。
When a user voluntarily asserts an identity in a request, they are claiming that they can receive requests sent to that identity in that domain. Strictly speaking, privacy entails the restriction of the distribution of a specific identity and related personal information from some particular party or parties that are potentially recipients of the message. In particular, there are scenarios in which a party desiring anonymity may:
当用户自愿在请求中声明身份时，他们声称可以接收发送到该域中该身份的请求。严格地说，隐私意味着限制某一方或某一方可能是信息接收者的特定身份和相关个人信息的传播。特别是，在某些情况下，希望匿名的一方可能：
send a message and withhold an identity from the final destination(s) while still communicating an identity to one or more intermediaries
发送消息并从最终目的地保留标识，同时仍将标识传递给一个或多个中介
send a message and withhold their identity from some or all intermediaries, but still communicate an identity end-to-end to the final destination(s)
向部分或所有中介发送消息并保留其身份，但仍将身份端到端地传递到最终目的地
withhold identity from both intermediaries and final destination(s)
向中介机构和最终目的地隐瞒身份
The result of withholding an identity is that the parties in question would be unable, for example, to attempt to initiate a new dialog with the anonymous party at a later time. However, the anonymous party still must be capable of receiving responses and new requests during the dialog in which it is participating.
例如，保留身份的结果是相关方将无法在以后尝试与匿名方启动新的对话。但是，匿名方仍必须能够在其参与的对话期间接收响应和新请求。
It may be desirable to restrict identity information on both requests and responses. Initially, it might seem unusual to suggest that a response has privacy concerns - presumably, the originator of the request knows who they were attempting to contact, so the identity of the respondent can hardly be confidential. However, some personal information in responses (such as the contact address at which the respondent is currently registered) is subject to privacy concerns and can be addressed by these mechanisms.
可能需要限制请求和响应上的身份信息。最初，认为回复涉及隐私问题似乎不太常见——可能是请求的发起人知道他们试图联系的人，因此回复人的身份很难保密。但是，回复中的一些个人信息（例如回复人当前注册的联系地址）受到隐私问题的影响，可以通过这些机制处理。
Users may wish for identity information to be withheld from a given party for any number of reasons, for example:
用户可能希望出于多种原因而拒绝向给定方提供身份信息，例如：
Users might want to contact a particular party without revealing their identity in order to impart information with which they would not like to be associated
用户可能希望在不透露其身份的情况下联系特定的一方，以便传递他们不希望与之关联的信息
Users might fear that the exposure of their identity or personal information to some networks or destinations will make them a target for unsolicited advertising, legal censure or other undesirable consequences
用户可能担心，将其身份或个人信息暴露于某些网络或目的地会使他们成为主动广告、法律谴责或其他不良后果的目标
Users might want to withhold from participants in a session the identity by which they are known to network intermediaries for the purposes of billing and accounting
出于计费和记帐的目的，用户可能希望不让会话参与者知道网络中介机构知道他们的身份
When a user agent decides to send a request through a proxy server, it may be difficult for the originator to anticipate the final destination of that message. For that reason, users are advised not to base their estimation of their privacy needs on where they expect a message will go. For example, if a user sends a request to telephone number, they may believe that the final destination of the request will be a station in the public switched telephone network (PSTN) that is unable to inspect, say, SIP Contact headers, and therefore assume that it is safe to leave such headers in the clear; however, such a request might very well end up being retargeted by the network to a native SIP endpoint to which Contact headers are quite legible.
当用户代理决定通过代理服务器发送请求时，发起者可能很难预测该消息的最终目的地。出于这个原因，建议用户不要将他们对隐私需求的估计建立在他们预期消息将去哪里的基础上。例如，如果用户向电话号码发送请求，则他们可能认为请求的最终目的地将是公共交换电话网（PSTN）中的一个站，该站不能检查（例如）SIP联系人报头，因此假设将此类报头保留在clear中是安全的；然而，这样的请求很可能最终被网络重新定位到一个本地SIP端点，而该端点的联系人头非常清晰。
This document describes three degrees of privacy - one level of user-provided privacy, and two levels of network-provided privacy (header privacy and session privacy). How much privacy does a user need for any given session? Generally, if a user is seeking privacy, they're going to need as much of it as they can get. However, if a user knows of no privacy service, they must be content with user-provided privacy alone. Similarly, if a user knows of an anonymization service that can provide session privacy, but is unable to secure session traffic to prevent the anonymizer from possibly eavesdropping on the session, they might judge the loss of session privacy to be the lesser evil. The user might also be aware of exceptional conditions about the architecture in which the user agent is deployed that may obviate one or more privacy concerns.
本文档描述了三个级别的隐私-一个级别的用户提供的隐私和两个级别的网络提供的隐私（标题隐私和会话隐私）。用户在任何给定会话中需要多少隐私？一般来说，如果用户正在寻求隐私，他们将需要尽可能多的隐私。然而，如果用户不知道隐私服务，他们必须满足于用户提供的隐私。类似地，如果用户知道可以提供会话隐私的匿名化服务，但无法保护会话流量以防止匿名者可能窃听会话，则他们可能会判断会话隐私的损失是较小的危害。用户还可能知道关于部署用户代理的体系结构的异常情况，这些异常情况可以避免一个或多个隐私问题。
A user may not always be the best judge of when privacy is required even under ideal circumstances, and thus privacy may in some architectures by applied by intermediaries without the user's explicit per-message request. By sending a request through intermediaries that can provide a privacy role, the user tacitly permits privacy functions to be invoked as needed.
即使在理想情况下，用户也不一定能够最好地判断何时需要隐私，因此，在某些体系结构中，在没有用户明确的每条消息请求的情况下，中介可以应用隐私。通过提供隐私角色的中介发送请求，用户默认允许根据需要调用隐私功能。
It is also important that users understand that intermediaries may be unable to provide privacy functions requested by users. Requests for privacy may not be honored due to legal constraints, unimplemented or misconfigured features, or other exceptional conditions.
用户还必须了解，中介机构可能无法提供用户请求的隐私功能。由于法律限制、未实施或配置错误的功能或其他特殊情况，隐私请求可能无法得到满足。
Note that just as it is the prerogative of a user to conceal their identity, so it must also be the prerogative of proxy servers and other users to refuse to process requests from users whom they cannot identify. Therefore users should not just automatically withhold their identity for all requests and responses - inability to ascertain the identity of the originator of the request will frequently be grounds for rejection. Privacy should only be requested when the user has a need for it.
请注意，正如隐藏其身份是用户的特权一样，拒绝处理无法识别的用户的请求也必须是代理服务器和其他用户的特权。因此，用户不应只是自动保留其所有请求和响应的身份-无法确定请求发起人的身份通常是拒绝的理由。只有当用户需要隐私时，才应请求隐私。
Further to this point, withholding some information in signaling might not be necessary for all user agents to ensure privacy. For example, user agents may acquire their IP addresses and hostnames dynamically, and these dynamic addresses may not reveal any information about the user whatsoever. In these cases, restricting access to hostnames (as described in Section 4.1.1.3) is unnecessary.
此外，在信令中保留一些信息可能不是所有用户代理确保隐私所必需的。例如，用户代理可以动态获取其IP地址和主机名，而这些动态地址可能不会透露任何有关用户的信息。在这些情况下，没有必要限制对主机名的访问（如第4.1.1.3节所述）。
There is a certain amount of privacy that a user agent can provide itself. For example, the baseline SIP specification permits a user agent to populate the From header field of a request with an anonymous value. Users can take similar steps to avoid revealing any other unnecessarily identity information in related SIP headers (this is discussed further in Section 4.1.1).
用户代理可以为自己提供一定量的隐私。例如，基线SIP规范允许用户代理使用匿名值填充请求的From头字段。用户可以采取类似的步骤，避免在相关SIP头中泄露任何其他不必要的身份信息（这将在第4.1.1节中进一步讨论）。
A user may have different privacy needs for a message if it traverses intermediaries rather than going directly end-to-end. A user may attempt to conceal things from intermediaries which are not concealed from the final destination, and vice versa. For example, using baseline SIP mechanisms, a user agent can encrypt SIP bodies end-to-end in order to prevent intermediaries from inspecting them. If a SIP message will not pass through intermediaries, however, this step might not be necessary (i.e., lower-layer security, without the addition of security for SIP bodies, could be sufficient).
如果消息通过中介而不是直接端到端，则用户可能对消息有不同的隐私需求。用户可能试图向中间人隐藏未向最终目的地隐藏的内容，反之亦然。例如，使用基线SIP机制，用户代理可以端到端加密SIP主体，以防止中介机构检查它们。但是，如果SIP消息不会通过中介，则可能不需要此步骤（即，如果没有为SIP主体添加安全性，则较低层安全性就足够了）。
Also note that if a dialog goes directly end-to-end between participants, however, it will not be possible to conceal the network addresses of the participants.
另外请注意，如果参与者之间的对话直接进行端到端，则无法隐藏参与者的网络地址。
If a user is sending a request through intermediaries, a user agent can conceal its identity to only a limited extent without the intermediaries' cooperation. Also, some information can only be concealed from destination endpoints if an intermediary is entrusted to remove it.
如果用户通过中介发送请求，则用户代理只能在有限的范围内隐藏其身份，而无需中介的合作。此外，如果委托中介删除某些信息，则只能对目标端点隐藏这些信息。
For these reasons a user must have a way to request privacy from intermediaries, a means that allows users both to signal some indications of the desired privacy services, and to ensure that their call is routed to an intermediary that is capable of providing these services. A user may be aware of a specific third-party anonymizing host, one with which they have a pre-existing relationship, or a user may request that their local administrative domain provide privacy services.
出于这些原因，用户必须有一种向中介机构请求隐私的方法，这种方法允许用户发出所需隐私服务的某些指示信号，并确保其呼叫路由到能够提供这些服务的中介机构。用户可能知道特定的第三方匿名主机，他们与该主机有预先存在的关系，或者用户可能请求其本地管理域提供隐私服务。
Intermediaries may also be empowered to apply privacy to a message without any explicit signaling from the originating user, since user agents may not always be cognizant or capable of requesting privacy when it is necessary.
中介机构还可以被授权对消息应用隐私，而无需原始用户发出任何明确的信号，因为用户代理可能并不总是知道或能够在必要时请求隐私。
There are three different ways that a user agent can contribute to the privacy of a request - by populating headers with values that reflect privacy requirements, by requesting further privacy services from the network, and by using cryptographic confidentiality to secure headers and bodies. Note that the last of these is outside the scope of this document.
用户代理可以通过三种不同的方式来保护请求的隐私—通过使用反映隐私要求的值填充头，通过从网络请求进一步的隐私服务，以及通过使用加密机密性来保护头和主体。请注意，最后一项不在本文件范围内。
The mechanisms provided in this section assume that a user agent is sufficiently configurable that a user can select header values and provision privacy preferences (ideally on a per-call basis). If this isn't the case, it is possible that a user can route their call through a privacy service that is configured to groom signaling from this user agent in order to provide some of the function described below (see Section 5).
本节中提供的机制假设用户代理具有足够的可配置性，用户可以选择头值并提供隐私首选项（理想情况下是基于每次调用）。如果情况并非如此，则用户可以通过隐私服务路由其呼叫，该隐私服务被配置为梳理来自该用户代理的信令，以便提供以下所述的一些功能（参见第5节）。
Privacy starts with the user agent. The bulk of the steps that are required to conceal private information about the sender of a message are, appropriately enough, the sender's responsibility.
隐私从用户代理开始。隐藏有关消息发送者的私人信息所需的大部分步骤都是发送者的责任。
The following SIP headers, when generated by a user agent, can directly or indirectly reveal identity information about the originator of a message: From, Contact, Reply-To, Via, Call-Info, User-Agent, Organization, Server, Subject, Call-ID, In-Reply-To and Warning. Note that the use of an authentication system (such as the SIP Digest authentication method described in [1]) also usually entails revealing identity to one or more parties; for more information see Section 6.
当由用户代理生成时，以下SIP头可以直接或间接地显示消息发起人的身份信息：发件人、联系人、回复人、通过、呼叫信息、用户代理、组织、服务器、主题、呼叫ID、回复和警告。注意，认证系统（例如[1]中描述的SIP摘要认证方法）的使用通常还需要向一方或多方透露身份；有关更多信息，请参见第6节。
The first and most obvious step is that user agents SHOULD not include any optional headers that might divulge personal information; there's certainly no reason for a user seeking privacy to include a Call-Info. Secondly, the user SHOULD populate URIs throughout the message in accordance with the guidelines given in Section 4.1.1. For example, users SHOULD create an anonymous From header field for the request. Finally, users MAY also need to request certain privacy functions from the network, as described in Section 4.2.
第一步也是最明显的一步是，用户代理不应该包含任何可能泄露个人信息的可选头；当然，寻求隐私的用户没有理由包含通话信息。其次，用户应根据第4.1.1节中给出的指南在整个消息中填充URI。例如，用户应该为请求创建一个匿名发件人标头字段。最后，用户可能还需要从网络请求某些隐私功能，如第4.2节所述。
The Call-ID header, which is frequently constructed in a manner that reveals the IP address or hostname of the originating client, requires special mention. User agents SHOULD substitute for the IP address or hostname that is frequently appended to the Call-ID value a suitably long random value (the value used as the 'tag' for the From header of the request might even be reused).
需要特别提及的是Call ID标头，它的构造方式通常会显示原始客户端的IP地址或主机名。用户代理应该用一个适当长的随机值（用作请求From头的“标记”的值甚至可以重用）来代替经常附加到调用ID值的IP地址或主机名。
Note that if the user wants to conceal any of the above headers from intermediaries alone, without withholding them from the final destination of the message, users MAY also place legitimate values for these headers in encapsulated 'message/sip' S/MIME bodies as described in Section 23 of [1].
请注意，如果用户希望仅对中介隐藏上述任何头，而不将其从消息的最终目的地扣留，则用户还可以将这些头的合法值放入封装的“消息/sip”/MIME正文中，如[1]第23节所述。
A certain amount of privacy can be afforded by choosing to populate SIP headers with URIs and display-names that do not reveal any identity information. In some of the header fields (for example, the Reply-To and From headers), URIs are not used in further signaling within the current dialog. In others, like the Contact header, an inaccurate URI will result in a failure to route subsequent requests within the dialog.
通过选择使用URI填充SIP头并显示不显示任何身份信息的名称，可以提供一定程度的隐私。在某些头字段（例如，回复到和来自头）中，URI不用于当前对话框中的进一步信令。在其他情况下，如联系人标头，不准确的URI将导致无法在对话框内路由后续请求。
It is a relatively common practice in email and other applications to use an assumed name in the display-name component of the From header field. Outside of a business context (especially in applications such as instant messaging or Internet gaming) the use of such aliases is unlikely to provide a cause for distrust.
在电子邮件和其他应用程序中，在“发件人”标题字段的“显示名称”组件中使用假名是一种相对常见的做法。在业务环境之外（特别是在即时消息或互联网游戏等应用程序中），使用此类别名不太可能引起不信任。
It is RECOMMENDED that user agents seeking anonymity use a display-name of "Anonymous".
建议寻求匿名的用户代理使用“匿名”显示名称。
The structure of a URI itself can reveal or conceal a considerable amount of personal information. Consider the difference between:
URI本身的结构可以揭示或隐藏大量的个人信息。考虑一下：
sip:jon.peterson@neustar.biz
西普：乔恩。peterson@neustar.biz
and
和
sip:a0017@anonymous-sip.com
抿：a0017@anonymous-sip.com
From the former, the full name and employer of the party in question can easily be guessed. From the latter, you learn nothing other than that the party desires anonymity. In some cases, sufficient anonymity can be achieved by selecting an oblique URI. Today, the SIP specification recommends a URI with "anonymous" in the user portion of the From header.
从前者可以很容易地猜出当事人的全名和雇主。从后者中，你只知道该党要求匿名。在某些情况下，通过选择一个倾斜的URI可以实现足够的匿名性。现在，SIP规范建议在From头的用户部分使用“匿名”URI。
In some URIs, such as those that appear in Contact headers, it MAY also make sense to omit the username altogether, and provide only a hostname, like: sip:anonymous-sip.com
在某些URI中，例如出现在联系人头中的URI，完全省略用户名并仅提供主机名也是有意义的，如：sip:anonymous-sip.com
It is assumed by this document that the user that requests privacy wishes to receive future requests and responses within this dialog, but does not wish to reveal an identity that could be used to send new requests to him outside the scope of this dialog. For that reason, different treatment must be recommended for URIs that are used in the context of routing further requests in the dialog, as opposed to routing new requests outside the context of the dialog.
本文档假设请求隐私的用户希望在此对话框中接收未来的请求和响应，但不希望透露可用于在此对话框范围之外向其发送新请求的身份。因此，对于在对话框中路由进一步请求的上下文中使用的URI，必须推荐不同的处理方法，而不是在对话框上下文之外路由新请求。
For headers indicating how the user would like to be contacted for future sessions (such as the From header), it might not immediately be obvious why changing the hostname would be necessary - if the username is 'anonymous', requests will not be routable to the anonymous user.
对于指示用户希望在未来会话中如何联系的标题（如From标题），可能不清楚为什么需要更改主机名-如果用户名为“匿名”，则请求将无法路由到匿名用户。
Sometimes, merely changing the username will not be enough to conceal a user's identity. A user's SIP service provider might decisively reveal a user's identity (if it reflected something like a small company or a personal domain). So in this case, even though the URI in the From header would not dereference to the anonymous user, humans might easily guess the user's identity and know the proper form of their address-of-record.
有时，仅仅更改用户名不足以隐藏用户的身份。用户的SIP服务提供商可能会决定性地透露用户的身份（如果它反映了小公司或个人域之类的信息）。因此，在这种情况下，即使From头中的URI不会取消对匿名用户的引用，人们也可能很容易猜测用户的身份，并知道其记录地址的正确形式。
For these reasons, the hostname value 'anonymous.invalid' SHOULD be used for anonymous URIs (see [3] for more information about the reserved 'invalid' DNS TLD). The full recommended form of the From header for anonymity is (note that this From header, like all others, MUST contain a valid and unique 'tag=' parameter):
出于这些原因，主机名值“anonymous.invalid”应用于匿名URI（有关保留的“invalid”DNS TLD的更多信息，请参阅[3]）。对于匿名性，完整的推荐From标头形式为（注意，与所有其他标头一样，此From标头必须包含有效且唯一的“tag=”参数）：
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
For headers indicating how further requests in the current dialog should be routed (namely the Contact header, Via header, and session information in the SDP), there seems to be little that a user can do to disguise the existing URI, because users MUST provide a value that will allow them to receive further requests. In some cases, disguising or failing to provide the username, as described above, may create some level of privacy, but the hostname provides a more significant obstacle.
对于指示当前对话框中的进一步请求应如何路由的标头（即联系人标头、Via标头和SDP中的会话信息），用户似乎无法伪装现有URI，因为用户必须提供一个允许他们接收进一步请求的值。在某些情况下，如上所述，伪装或不提供用户名可能会造成某种程度的隐私，但主机名会带来更大的障碍。
Is there much additional privacy in using an IP address rather than a hostname? It does prevent someone who casually inspects a message from gathering information that they might see otherwise. However, reverse-resolving such addresses is generally trivial, and substituting an IP address for a hostname could introduce some complications, for example due to NAT and firewall traversal concerns. Headers used in routing may also rely on certain DNS practices to provide services that would be lost if an IP address is used in place of a hostname.
使用IP地址而不是主机名是否有更多的隐私？它确实阻止了随意检查邮件的人收集他们可能看到的其他信息。然而，反向解析这些地址通常很简单，用IP地址替换主机名可能会带来一些复杂情况，例如由于NAT和防火墙穿越问题。路由中使用的头也可能依赖于某些DNS实践来提供服务，如果使用IP地址代替主机名，这些服务将丢失。
This document thus recommends that the host portion of URIs that are used in the routing of subsequent requests, such as URIs appearing in the Contact header, SHOULD NOT be altered by the user agent due to privacy considerations. If these headers require anonymization, the user requests that service from an intermediary, namely a privacy service.
因此，本文档建议，出于隐私考虑，用户代理不应更改在后续请求路由中使用的URI的主机部分，例如出现在联系人标头中的URI。如果这些头需要匿名化，则用户从中间层（即隐私服务）请求该服务。
Note that many of the considerations regarding the Contact header above apply equal well to SIP headers in which a hostname, rather than a URI, is used for some routing purpose (namely the Via header).
注意，上面关于联系人报头的许多注意事项同样适用于SIP报头，其中主机名（而不是URI）用于某些路由目的（即Via报头）。
There are some headers that a user agent cannot conceal itself, because they are used in routing, that could be concealed by an intermediary that subsequently takes responsibility for directing messages to and from the anonymous user. The user agent must have some way to request such privacy services from the network. For that purpose, this document defines a new SIP header, Privacy, that can be used to specify privacy handling for requests and responses.
有些头是用户代理无法隐藏的，因为它们用于路由，这些头可以被中介隐藏，中介随后负责向匿名用户发送和从匿名用户发送消息。用户代理必须有某种方式从网络请求此类隐私服务。为此，本文定义了一个新的SIP头Privacy，可用于指定请求和响应的隐私处理。
Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value)
priv-value = "header" / "session" / "user" / "none" / "critical"
/ token
Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value)
priv-value = "header" / "session" / "user" / "none" / "critical"
/ token
User agents SHOULD include a Privacy header when network-provided privacy (as described in Section 3.3) is required. Note that some intermediaries may also add the Privacy header to messages, including privacy services. However, such intermediaries SHOULD only do so if they are operating at a user's behest, for example if a user has an administrative arrangement with the operator of the intermediary that it will add such a Privacy header. An intermediary MUST NOT modify the Privacy header in any way if the 'none' priv-value is already specified.
当需要网络提供的隐私（如第3.3节所述）时，用户代理应包括隐私标头。请注意，一些中介机构还可能将隐私标头添加到消息中，包括隐私服务。然而，此类中介机构应仅在其按照用户的要求进行操作的情况下这样做，例如，如果用户与中介机构的运营商有行政安排，则其将添加此类隐私标头。如果已指定“none”priv值，则中间人不得以任何方式修改隐私标头。
The values of priv-value today are restricted to the above options, although further options can be defined as appropriate (see Section 7). Each legitimate priv-value can appear zero or one times in a Privacy header. The current values are:
目前priv value的值仅限于上述选项，但可根据需要定义其他选项（见第7节）。每个合法的priv值可以在隐私标头中出现零次或一次。当前值为：
header: The user requests that a privacy service obscure those headers which cannot be completely expunged of identifying information without the assistance of intermediaries (such as Via and Contact). Also, no unnecessary headers should be added by the service that might reveal personal information about the originator of the request.
header：用户请求隐私服务隐藏那些在没有中间人（如Via和Contact）帮助的情况下无法完全删除的标识信息的header。此外，服务不应添加任何不必要的头，这些头可能会泄露有关请求发起人的个人信息。
session: The user requests that a privacy service provide anonymization for the session(s) (described, for example, in a Session Description Protocol [5] body) initiated by this message. This will mask the IP address from which the session traffic would ordinarily appear to originate. When session privacy is requested, user agents MUST NOT encrypt SDP bodies in messages. Note that requesting session privacy in the absence of any end-to-end session encryption raises some serious security concerns (see Section 5.2).
会话：用户请求隐私服务为该消息发起的会话（例如，在会话描述协议[5]正文中描述）提供匿名化。这将屏蔽会话流量通常从中产生的IP地址。当请求会话隐私时，用户代理不得加密消息中的SDP正文。请注意，在没有任何端到端会话加密的情况下请求会话隐私会引起一些严重的安全问题（请参见第5.2节）。
user: This privacy level is usually set only by intermediaries, in order to communicate that user level privacy functions (as discussed in Section 5.3) must be provided by the network, presumably because the user agent is unable to provide them. User agents MAY however set this privacy level for REGISTER requests, but SHOULD NOT set 'user' level privacy for other requests.
用户：该隐私级别通常仅由中介机构设置，以便传达必须由网络提供的用户级隐私功能（如第5.3节所述），可能是因为用户代理无法提供这些功能。但是，用户代理可以为注册请求设置此隐私级别，但不应为其他请求设置“用户”级别的隐私。
none: The user requests that a privacy service apply no privacy functions to this message, regardless of any pre-provisioned profile for the user or default behavior of the service. User agents can specify this option when they are forced to route a message through a privacy service which will, if no Privacy header is present, apply some privacy functions which the user does not desire for this message. Intermediaries MUST NOT remove or alter a Privacy header whose priv-value is 'none'. User agents MUST NOT populate any other priv-values (including 'critical') in a Privacy header that contains a value of 'none'.
无：用户请求隐私服务对此消息不应用任何隐私功能，而不管用户的任何预设置配置文件或服务的默认行为。当用户代理被迫通过隐私服务路由消息时，可以指定此选项。如果不存在隐私标头，隐私服务将应用用户不希望使用此消息的某些隐私功能。中介机构不得删除或更改priv值为“none”的隐私标头。用户代理不得在包含“无”值的隐私标头中填充任何其他priv值（包括“critical”）。
critical: The user asserts that the privacy services requested for this message are critical, and that therefore, if these privacy services cannot be provided by the network, this request should be rejected. Criticality cannot be managed appropriately for responses.
关键：用户声明此消息请求的隐私服务是关键的，因此，如果网络无法提供这些隐私服务，则应拒绝此请求。无法对响应的关键性进行适当管理。
When a Privacy header is constructed, it MUST consist of either the value 'none', or one or more of the values 'user', 'header' and 'session' (each of which MUST appear at most once) which MAY in turn be followed by the 'critical' indicator.
构建隐私标头时，它必须由值“none”或一个或多个值“user”、“header”和“session”（每个值最多只能出现一次）组成，随后可能会出现“critical”指示器。
The following table specifies extensions to Table 2 in [1].
下表指定了[1]中表2的扩展。
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Privacy amrd o o o o o o
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Privacy amrd o o o o o o
Header field SUB NOT PRK IFO UPD MSG
___________________________________________________________
Privacy o o o o o o
Header field SUB NOT PRK IFO UPD MSG
___________________________________________________________
Privacy o o o o o o
The most obvious way for a user agent to invoke the privacy function is to direct a request through an intermediary known to act as a privacy service. Doing so traditionally entails the configuration of pre-loaded Route headers that designate the privacy service.
用户代理调用隐私功能最明显的方式是通过一个作为隐私服务的中介来引导请求。这样做传统上需要配置指定隐私服务的预加载路由头。
It is RECOMMENDED that service providers couple the privacy service function with a local outbound proxy. Users can thereby send their messages that request privacy through their usual outbound route. Users should not assume, however, that the administrative domain that is the destination of the request would be willing and able to perform the privacy service function on their behalf. If the originating user wishes to keep their local administrative domain a secret, then they must use a third-party anonymization service outside of any of the principal administrative domains associated with the session.
建议服务提供商将隐私服务功能与本地出站代理连接起来。因此，用户可以通过通常的出站路径发送要求隐私的消息。但是，用户不应假设作为请求目的地的管理域愿意并且能够代表他们执行隐私服务功能。如果发起用户希望对其本地管理域保密，则他们必须在与会话关联的任何主要管理域之外使用第三方匿名服务。
It is highly RECOMMENDED that user agents use network or transport layer security, such as TLS, when contacting a privacy service. Ideally, users SHOULD establish a direct (i.e., single pre-loaded Route header) connection to a privacy service; this will both allow the user to inspect a certificate presented by the privacy service, and it will provide confidentiality for requests that will reduce the chances that the information that the privacy service will obscures is revealed before a message arrives at the privacy service. By establishing a direct connection to a privacy service, the user also eliminates the possibility that intermediaries could remove requests for privacy. If a direct connection is impossible, users SHOULD use a mechanism like SIPS to guarantee the use of lower-layer security all the way to the privacy service.
强烈建议用户代理在联系隐私服务时使用网络或传输层安全，如TLS。理想情况下，用户应与隐私服务建立直接（即，单个预加载的路由报头）连接；这将允许用户检查隐私服务提供的证书，并为请求提供保密性，从而减少在消息到达隐私服务之前隐私服务将掩盖的信息被泄露的可能性。通过建立与隐私服务的直接连接，用户还消除了中间人删除隐私请求的可能性。如果无法直接连接，则用户应使用SIPS等机制，以确保从底层安全一直到隐私服务的使用。
If a user agent believes that it is sending a request directly to a privacy service, it SHOULD include a Proxy-Require header containing a new option-tag, 'privacy', especially when the 'critical' priv-value is present in the Privacy header. That way, in the unlikely event that the user agent sends a request to an intermediary that does not support the extensions described in this document, the request will fail. Note that because of special privacy service
如果用户代理认为它正在直接向隐私服务发送请求，它应该包括一个代理请求标头，其中包含一个新的选项标记“privacy”，特别是当privacy标头中存在“critical”priv值时。这样，如果用户代理向不支持本文档中描述的扩展的中介发送请求，则请求将失败。注意，由于特殊的隐私服务
behavior (described in Section 5), no subsequent intermediaries in the signaling path of the request will also need to the support the 'privacy' option-tag - once the privacy service has fulfilled all the required privacy functions, the 'privacy' option-tag is removed from the Proxy-Require header.
行为（如第5节所述），请求信令路径中的后续中介机构也不需要支持“隐私”选项标签-一旦隐私服务完成所有要求的隐私功能，“隐私”选项标签将从代理请求标头中移除。
Making sure that responses will go through a privacy service is a little bit trickier. The path traversed by SIP responses is the same as the path over which the request traveled. Thus, the responding user agent, for example, cannot force a privacy service to be injected in the response path after it has received a request.
确保回复通过隐私服务进行有点棘手。SIP响应所经过的路径与请求所经过的路径相同。因此，例如，响应用户代理在接收到请求后不能强制在响应路径中注入隐私服务。
What a responding user agent can do, however, is ensure that the path by which requests reach them traverses their privacy service. In some architectures, the privacy service function will be fulfilled by the same server to which requests for the local administrative domain are sent, and hence it will automatically be in the path of incoming requests. However, if this is not the case, the user will have to ensure that requests are directed through a third-party privacy service.
然而，响应用户代理所能做的是确保请求到达它们的路径穿过它们的隐私服务。在某些体系结构中，隐私服务功能将由向其发送本地管理域请求的同一服务器来实现，因此它将自动位于传入请求的路径中。但是，如果不是这样，用户将必须确保请求通过第三方隐私服务进行处理。
One way to accomplish this is to procure an 'anonymous callback' URI from the third-party service and to distribute this as an address-of-record. A privacy service provider might offer these anonymous callback URIs to users in the same way that an ordinary SIP service provider grants addresses-of-record. The user would then register their normal address-of-record as a contact address with the third-party service.
实现这一点的一种方法是从第三方服务获取“匿名回调”URI，并将其作为记录地址分发。隐私服务提供商可能以普通SIP服务提供商授予记录地址的相同方式向用户提供这些匿名回调URI。然后，用户将其正常记录地址注册为第三方服务的联系地址。
Alternatively, a user agent could send REGISTER requests through a privacy service with a request for 'user' level privacy. This will allow the privacy service to insert anonymous Contact header URIs. Requests sent to the user's conventional address-of-record would then reach the user's devices without revealing any usable contact addresses.
或者，用户代理可以通过隐私服务发送注册请求，请求“用户”级隐私。这将允许隐私服务插入匿名联系人头URI。发送到用户的常规记录地址的请求随后将到达用户的设备，而不显示任何可用的联系地址。
Finally, a user might generate a CPL ([7]) script that will direct requests to an anonymization service.
最后，用户可能会生成一个CPL（[7]）脚本，将请求定向到匿名化服务。
Users are also advised to use transport or network layer security in the response path. This may involve registering a SIPS URI and/or maintaining persistent TLS connections over which their user agent receives requests.
还建议用户在响应路径中使用传输层或网络层安全性。这可能涉及注册SIPS URI和/或维护其用户代理通过其接收请求的持久TLS连接。
Privacy services MAY in turn route requests through other privacy services. This may be necessary if a privacy service does not support a particular privacy function, but it knows of a peer that does. Privacy services may also cluster themselves into networks that exchange session traffic between one another in order to further disguise the participants in a session, although no specific architecture or method for doing so is described in this document.
隐私服务可以反过来通过其他隐私服务路由请求。如果隐私服务不支持特定的隐私功能，但它知道有一个对等方支持，那么这可能是必要的。隐私服务还可以将其自身集群到彼此之间交换会话流量的网络中，以便进一步伪装会话中的参与者，尽管本文档中没有描述用于这样做的特定架构或方法。
This document defines a new SIP logical role called a "privacy service". The privacy service role is instantiated by a network intermediary, frequently by entities that can act as SIP proxy servers. The function of a privacy service is to supply privacy functions for SIP messages that cannot be provided by user agents themselves.
本文档定义了一个称为“隐私服务”的新SIP逻辑角色。隐私服务角色由网络中介（通常由充当SIP代理服务器的实体）实例化。隐私服务的功能是为用户代理本身无法提供的SIP消息提供隐私功能。
When a message arrives at a server that can act as a privacy service, the service SHOULD evaluate the level of privacy requested in a Privacy header. Usually, only the services explicitly requested should be applied. However, privacy services MAY have some means outside SIP of ascertaining the preferences of the user (such as a pre-arranged user profile) and therefore they MAY perform such other privacy functions without an explicit Privacy header. Performing even a user-level privacy function in a privacy service could be useful, for example, when a user is sending messages from a legacy client that does support the Privacy header, or a user agent that does not allow the user to configure the values of headers that could reveal personal information. However, if the Privacy header value of 'none' is specified in a message, privacy services MUST NOT perform any privacy function and MUST NOT remove or modify the Privacy header.
当消息到达可作为隐私服务的服务器时，该服务应评估隐私标头中请求的隐私级别。通常，只应应用显式请求的服务。然而，隐私服务可以在SIP之外具有确定用户偏好的一些手段（例如预先安排的用户简档），因此它们可以在没有显式隐私报头的情况下执行此类其他隐私功能。即使在隐私服务中执行用户级隐私功能也可能有用，例如，当用户从支持隐私头的旧客户端发送消息时，或从不允许用户配置可能泄露个人信息的头值的用户代理发送消息时。但是，如果在消息中指定隐私标头值“none”，则隐私服务不得执行任何隐私功能，也不得删除或修改隐私标头。
Privacy services MUST implement support for the 'none' and 'critical' privacy tokens, and MAY implement any of other privacy levels described in Section 4.2 as well as any extensions that are not detailed in this document. In some cases, the privacy service will not be capable of fulfilling the requested level of privacy. If the 'critical' privacy level is present in the Privacy header of a request, then if the privacy service is incapable of performing all of the levels of privacy specified in the Privacy header then it MUST fail the request with a 500 (Server Error) response code. The reason phrase of the status line of the response SHOULD contain appropriate text indicating that there has been a privacy failure as well as an enumeration of the priv-value(s) which were not supported by the privacy service (the reason phrase SHOULD also respect any Accept-Language header in the request if possible).
隐私服务必须实现对“无”和“关键”隐私令牌的支持，并且可以实现第4.2节中描述的任何其他隐私级别以及本文档中未详细说明的任何扩展。在某些情况下，隐私服务将无法满足要求的隐私级别。如果请求的隐私标头中存在“关键”隐私级别，则如果隐私服务无法执行隐私标头中指定的所有隐私级别，则必须使用500（服务器错误）响应代码使请求失败。响应状态行的原因短语应包含适当的文本，表明存在隐私故障，以及隐私服务不支持的priv值的枚举（如果可能，原因短语还应尊重请求中的任何Accept Language标头）。
When a privacy service performs one of the functions corresponding to a privacy level listed in the Privacy header, it SHOULD remove the corresponding priv-value from the Privacy header - otherwise, any other privacy service involved with routing this message might unnecessarily apply the same function, which in many cases would be undesirable. When the last priv-value (not counting 'critical') has been removed from the Privacy header, the entire Privacy header MUST be removed from a message.
当隐私服务执行与隐私标头中列出的隐私级别对应的功能之一时，它应该从隐私标头中删除相应的priv值-否则，路由此消息所涉及的任何其他隐私服务可能不必要地应用相同的功能，这在许多情况下是不可取的。当从隐私标头中删除最后一个priv值（不计算“关键”）时，必须从消息中删除整个隐私标头。
When the privacy service removes the entire Privacy header, if the message is a request, the privacy service MUST also remove any 'privacy' option-tag from the Proxy-Require header field of the request.
当隐私服务删除整个隐私标头时，如果消息是请求，隐私服务还必须从请求的代理请求标头字段中删除任何“隐私”选项标记。
If a privacy level of 'header' is requested, then the originating user has asked the privacy service to help to obscure headers that might otherwise reveal information about the originator of the request. However, the values that have been so obscured must be recoverable when further messages in the dialog need to be routed to the originating user agent. In order to provide these functions the privacy service must frequently act as a transparent back-to-back user agent (B2BUA).
如果请求“头”的隐私级别，则发起用户已要求隐私服务帮助隐藏头，否则可能会泄露有关请求发起人的信息。但是，当需要将对话框中的进一步消息路由到原始用户代理时，已被如此模糊的值必须是可恢复的。为了提供这些功能，隐私服务必须经常充当透明的背靠背用户代理（B2BUA）。
Firstly, a request for header privacy entails that the server SHOULD NOT add any headers to the message that reveal any identity or personal information, including the following: Call-Info, Server, and Organization. All of these provide optional information that could reveal facts about the user that has request anonymity.
首先，请求消息头隐私意味着服务器不应向消息中添加任何显示任何身份或个人信息的消息头，包括以下信息：呼叫信息、服务器和组织。所有这些都提供了可选信息，这些信息可能会揭示关于请求匿名的用户的事实。
Privacy services operating on requests SHOULD remove all Via headers that have been added to the request prior to its arrival at the privacy service (a practice referred to as "Via stripping") and then SHOULD add a single Via header representing themselves. Note that the bottommost such Via header field value in a request contains an IP address or hostname that designates the originating client, and subsequent Via header field values may indicate hosts in the same administrative domain as the client. No Via stripping is required when handling responses.
对请求进行操作的隐私服务应删除在请求到达隐私服务之前添加到请求中的所有Via头（这种做法称为“Via剥离”），然后应添加一个代表其自身的Via头。请注意，请求中最底部的Via标头字段值包含指定发起客户端的IP地址或主机名，后续Via标头字段值可能指示与客户端位于同一管理域中的主机。处理响应时不需要通孔剥离。
Contact headers are added by user agents to both requests and responses. A privacy service SHOULD replace the value of the Contact header in a message with a URI that does not dereference to the originator of the message (such as the anonymous URI described in Section 4.1.1.3). The URI that replaces the existing Contact header field value MUST dereference to the privacy service.
联系人标头由用户代理添加到请求和响应中。隐私服务应将消息中联系人标头的值替换为不解除对消息原始发件人引用的URI（如第4.1.1.3节中描述的匿名URI）。替换现有联系人标头字段值的URI必须取消对隐私服务的引用。
In a manner similar to Via stripping, a privacy service SHOULD also strip any Record-Route headers that have been added to a request before it reaches the privacy service - though note that no such headers will be present if there is only one hop between the originating user agent and the privacy service, as is recommended above. Such Record-Route headers might also divulge information about the administrative domain of the client.
以类似于Via剥离的方式，隐私服务还应剥离在请求到达隐私服务之前添加到请求中的任何记录路由头-但请注意，如果原始用户代理和隐私服务之间只有一个跃点，则不会出现此类头，如上所述。这样的记录路由头还可能泄露有关客户端管理域的信息。
For the purposes of this document, it is assumed that the privacy service has locally persisted the values of any of the above headers that are so removed, which requires the privacy service to keep a pretty significant amount of state on a per-dialog basis. When further requests or responses associated with the dialog reach the privacy service, it MUST restore values for the Via, Record-
在本文档中，假设隐私服务已在本地持久化上述任何已删除的头的值，这要求隐私服务在每个对话的基础上保持相当多的状态。当与该对话框关联的进一步请求或响应到达隐私服务时，它必须恢复Via、Record的值-
Route/Route or Contact headers that it has previously removed in the interests of privacy. There may be alternative ways (outside the scope of this document) to perform this function that do not require keeping state in the privacy service (usually means that involve encrypting and persisting the values in the signaling somehow).
出于隐私考虑，已删除的路由/路由或联系人标头。可能有其他方法（不在本文档范围内）来执行此功能，这些方法不需要在隐私服务中保持状态（通常意味着以某种方式涉及加密和持久化信令中的值）。
The following procedures are RECOMMENDED for handling the Record-Route header field of requests and responses, which provides specialchallenges to a privacy service:
建议使用以下过程来处理请求和响应的记录路由标头字段，这会给隐私服务带来特殊的挑战：
When a privacy service is processing (on behalf of the originator) a request that contains one or more Record-Route header field values, the privacy service must strip these values from the request and remember both the dialog identifiers and the ordered Record-Route header field values. As described above, it must also replace the Contact header field with a URI indicating itself. When a response with the same dialog identifiers arrives at the privacy service, the privacy service must reapply any Record-Route header field values to the response in the same order, and it must then add a URI representing itself to the Record-Route header field of the response. If the response contains Record-Route header field values of its own, these must also be included (in order) in the Record-Route header field after the URI representing the privacy service.
当隐私服务（代表发起人）处理包含一个或多个记录路由头字段值的请求时，隐私服务必须从请求中删除这些值，并记住对话框标识符和有序记录路由头字段值。如上所述，它还必须用一个表示自身的URI替换Contact header字段。当具有相同对话框标识符的响应到达隐私服务时，隐私服务必须以相同的顺序将任何记录路由头字段值重新应用于响应，然后必须将表示其自身的URI添加到响应的记录路由头字段。如果响应包含自己的记录路由头字段值，则这些值也必须（按顺序）包含在表示隐私服务的URI之后的记录路由头字段中。
Note that when a privacy service is handling a request and providing privacy on behalf of the destination of the request, providing privacy for Record-Route headers downstream of the privacy service is significantly more complicated. This document recommends no way of statefully restoring those headers if they are stripped.
请注意，当隐私服务处理请求并代表请求的目的地提供隐私时，为隐私服务下游的记录路由头提供隐私要复杂得多。本文档建议，如果这些头被剥离，则无法有状态地恢复它们。
If a privacy level of 'session' is requested, then the user has requested that the privacy service anonymize the session traffic (e.g., for SIP telephony calls, the audio media) associated with this dialog.
如果请求“会话”的隐私级别，则用户已请求隐私服务匿名化与此对话框关联的会话流量（例如，对于SIP电话呼叫、音频媒体）。
The SIP specification dictates that intermediaries such as proxy servers cannot inspect and modify message bodies. The privacy service logical role MUST therefore act as a back-to-back user agent in order to provide media privacy, effectively terminating and re-originating the messages that initiate a session (although in support of session privacy the privacy service does not need to alter headers characterizing the originator or destination when the request is re-originated). In order to introduce an anonymizer for session traffic, the privacy service needs to control a middlebox [8] that can provide an apparent source and sink for session traffic. The details of the implementation of an anonymizer, and the modifications
SIP规范规定，代理服务器等中介机构不能检查和修改消息体。因此，隐私服务逻辑角色必须充当背靠背用户代理，以提供媒体隐私，有效终止和重新发起发起会话的消息（虽然为了支持会话隐私，隐私服务不需要在重新发起请求时更改表征发起人或目的地的标题）。为了引入会话流量匿名器，隐私服务需要控制一个中间箱[8]这可以为会话流量提供一个明显的源和汇。匿名器的实现细节，以及修改
that must be made to the Session Description Protocol (SDP [5]) bodies in the messages that initiate a session are outside the scope of this document.
必须对会话描述协议（SDP[5]）进行修改。发起会话的消息中的主体不在本文档的范围内。
The risk, of course, of using such an anonymizer is that the anonymizer itself is party to your communications. For that reason, requesting session-level privacy without resort to some sort of end-to-end security for the session traffic (with RTP [6] media, for example, SRTP [4]) is NOT RECOMMENDED.
当然，使用这种匿名者的风险在于，匿名者本身就是您的通信的一方。因此，不建议请求会话级隐私而不对会话流量（使用RTP[6]媒体，例如SRTP[4]）求助于某种端到端安全性。
If a privacy level of 'user' is requested, then the originating user has requested that privacy services perform the user-level privacy functions described in Section 4.1.
如果请求“用户”的隐私级别，则发起用户已请求隐私服务执行第4.1节所述的用户级别隐私功能。
Note that the privacy service MUST remove any non-essential informational headers that have been added by the user agent, including the Subject, Call-Info, Organization, User-Agent, Reply-To and In-Reply-To.
请注意，隐私服务必须删除用户代理添加的任何非必要信息头，包括主题、呼叫信息、组织、用户代理、回复和回复。
Significantly, user-level privacy could entail the modification of the From header, changing it from its original value to an anonymous value. Prior to the current issue of the SIP specification, the modification of the values of the To and From headers by intermediaries was not permitted, and would result in improper dialog matching by the endpoints. Currently, dialog matching uses only the tags in the To and From headers, rather than the whole header fields. Thus, under the new rules the URI values in the To and From headers themselves could be altered by intermediaries. However, some legacy clients might consider it an error condition if the value of the URI in the From header altered between the request and the response.
值得注意的是，用户级隐私可能需要修改From头，将其从原始值更改为匿名值。在当前的SIP规范发布之前，不允许中介修改to和From头的值，这将导致端点进行不正确的对话匹配。当前，对话框匹配仅使用“收件人”和“发件人”标题中的标记，而不是整个标题字段。因此，在新规则下，中间人可以更改To和From头中的URI值。但是，如果在请求和响应之间更改了ORI报头中的URI值，一些遗留客户端可能会认为这是一个错误情况。
Also, performing user-level privacy functions MAY entail the modification of the Call-ID header, since the Call-ID commonly contains a hostname or IP address corresponding to the originating client. This field is essential to dialog matching, and it cannot be altered by intermediaries.
此外，执行用户级隐私功能可能需要修改呼叫ID报头，因为呼叫ID通常包含对应于发起客户端的主机名或IP地址。此字段对于对话框匹配至关重要，中介机构无法更改。
Therefore, any time that a privacy service needs to modify any dialog-matching headers for privacy reasons, it SHOULD act as a transparent back-to-back user agent, and it MUST persist the former values of the dialog-matching headers. These values MUST be restored in any messages that are sent to the originating user agent.
因此，每当隐私服务出于隐私原因需要修改任何对话框匹配头时，它都应该充当一个透明的背靠背用户代理，并且它必须保留对话框匹配头的先前值。必须在发送到原始用户代理的任何消息中恢复这些值。
Messages that request privacy require confidentiality and integrity. Without integrity, the requested privacy functions could be downgraded or eliminated, potentially exposing identity information. Without confidentiality, eavesdroppers on the network (or any intermediaries between the user and the privacy service) could see the very personal information that the user has asked the privacy service to obscure.
要求隐私的邮件需要保密性和完整性。如果没有完整性，请求的隐私功能可能被降级或删除，从而可能暴露身份信息。在没有保密性的情况下，网络上的窃听者（或用户与隐私服务之间的任何中间人）可以看到用户要求隐私服务掩盖的非常私人的信息。
All of the network-provided privacy functions in this document entail a good deal of trust for the privacy service. Users should only trust privacy services that are somehow accountable to them.
本文件中所有网络提供的隐私功能都对隐私服务产生了很大的信任。用户应该只信任对他们负责的隐私服务。
Operators of privacy services should be aware that in the eyes of downstream entities, a privacy service will be the only source to which anonymous messages can be traced.
隐私服务的运营商应该意识到，在下游实体的眼中，隐私服务将是唯一可以追踪匿名消息的来源。
Note that authentication mechanisms, including the Digest authentication method described in the SIP specification, are outside the scope of the privacy considerations in this document. Revealing identity through authentication is highly selective, and may not result in the compromise of any private information. Obviously, users that do not wish to reveal their identity to servers that issue authentication challenges MAY elect not to respond to such challenges.
请注意，身份验证机制，包括SIP规范中描述的摘要身份验证方法，超出了本文档中隐私考虑的范围。通过身份验证显示身份具有高度选择性，并且可能不会导致任何私人信息的泄露。显然，不希望向发出身份验证挑战的服务器透露其身份的用户可能会选择不响应此类挑战。
This document defines a new SIP header field called "Privacy" that allows a user agent to request a certain degree of privacy for a message. This behavior associated with this header is specified in Section 4.2. This header has been added to the header sub-registry under http://www.iana.org/assignments/sip-parameters.
本文档定义了一个名为“隐私”的新SIP头字段，该字段允许用户代理为消息请求一定程度的隐私。第4.2节规定了与此标题相关的行为。此标头已添加到下的标头子注册表中http://www.iana.org/assignments/sip-parameters.
Header name: Privacy Compact form: none defined
标题名称：隐私契约表单：未定义
This document also creates an IANA registry for values that populate the Privacy header. This registry should be indexed by priv-value tokens and should contain a short semantic description of the new value. The current values of the "Privacy" header are as follows:
本文档还为填充隐私标头的值创建IANA注册表。该注册表应该由priv-value标记索引，并且应该包含新值的简短语义描述。“隐私”标题的当前值如下所示：
o user: Request that privacy services provide a user-level privacy function
o 用户：请求隐私服务提供用户级隐私功能
o header: Request that privacy services modify headers that cannot be set arbitrarily by the user (Contact/Via).
o header：请求隐私服务修改用户无法任意设置的标题（Contact/Via）。
o session: Request that privacy services provide privacy for session media
o 会话：请求隐私服务为会话媒体提供隐私
o none: Privacy services must not perform any privacy function
o 无：隐私服务不得执行任何隐私功能
o critical: Privacy service must perform the specified services or fail the request
o 关键：隐私服务必须执行指定的服务，否则请求将失败
New values for the "Privacy" header can only be defined by IETF Consensus including RFC publication (RFC 2434). IANA registration for the "Privacy" header field values is required along with the RFC publication.
“隐私”标题的新值只能由IETF共识定义，包括RFC出版物（RFC 2434）。“隐私”标题字段值的IANA注册需要与RFC出版物一起进行。
Authors of extensions to the SIP protocol that expose personal information about the participants in sessions are advised against extending the "Privacy" header - rather, it is preferable to create new identity mechanisms whose privacy can be managed by the user agent without the agency of intermediaries.
建议SIP协议扩展（公开会话参与者的个人信息）的作者不要扩展“隐私”标题——相反，最好创建新的身份机制，其隐私可以由用户代理管理，而无需中介机构。
This document also defines a new SIP option-tag, 'privacy', that represents support for the extension defined in this document.
本文档还定义了一个新的SIP选项标记“privacy”，它表示对本文档中定义的扩展的支持。
Normative References
规范性引用文件
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC 2606, June 1999.
[3] Eastlake，D.和A.Panitz，“保留顶级域名”，RFC 26061999年6月。
Informative References
资料性引用
[4] Baugher, M., McGrew, D., Oran, D., Blom, R., Carrara, E., Naslund, M. and K. Normann, "The Secure Real Time Transport Protocol", Work in Progress.
[4] Baugher，M.，McGrew，D.，Oran，D.，Blom，R.，Carrara，E.，Naslund，M.和K.Normann，“安全实时传输协议”，正在进行中。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[6] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[7] Lennox, J. and H. Schulzrinne, "CPL: A Language for User Control of Internet Telephony Services", Work in Progress
[7] Lennox，J.和H.Schulzrinne，“CPL：互联网电话服务的用户控制语言”，正在进行中
[8] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[8] Srisuresh，P.，Kuthan，J.，Rosenberg，J.，Molitor，A.和A.Rayhan，“中间箱通信架构和框架”，RFC3303，2002年8月。
Author's Address
作者地址
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Acknowledgments
致谢
The author would like to thank Allison Mankin, Rohan Mahy, Eric Rescorla, Mark Watson, Cullen Jennings, Robert Sparks, Jonathan Rosenberg, Ben Campbell, Tom Gray and John Elwell for their comments.
作者要感谢Allison Mankin、Rohan Mahy、Eric Rescorla、Mark Watson、Cullen Jennings、Robert Sparks、Jonathan Rosenberg、Ben Campbell、Tom Gray和John Elwell的评论。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。