Independent Submission M. Munakata
Request for Comments: 5379 S. Schubert
Category: Informational T. Ohba
ISSN: 2070-1721 NTT
February 2010
Independent Submission M. Munakata
Request for Comments: 5379 S. Schubert
Category: Informational T. Ohba
ISSN: 2070-1721 NTT
February 2010
Guidelines for Using the Privacy Mechanism for SIP
SIP隐私机制使用指南
Abstract
摘要
This is an informational document that provides guidelines for using the privacy mechanism for the Session Initiation Protocol (SIP) that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and the Session Description Protocol (SDP) parameters for each of the privacy header values (priv-values).
这是一份信息性文档，提供了使用会话启动协议（SIP）隐私机制的指南，该协议在RFC 3323中指定，随后在RFC 3325和4244中扩展。其目的在于阐明目标SIP报头/参数的处理以及每个隐私报头值（priv值）的会话描述协议（SDP）参数。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc5379.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5379.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Semantics of Existing priv-values ...............................4
4. Target for Each priv-value ......................................5
4.1. Target SIP Headers for Each priv-value .....................5
4.2. Target SDP Parameters for Each priv-value ..................6
4.3. Treatment of priv-value Not Supported by the
Privacy Service ............................................7
5. Recommended Treatment of User-Privacy-Sensitive Information .....7
5.1. Target SIP Headers .........................................7
5.1.1. Call-ID .............................................7
5.1.2. Call-Info ...........................................8
5.1.3. Contact .............................................8
5.1.4. From ................................................9
5.1.5. History-Info .......................................10
5.1.6. In-Reply-To ........................................10
5.1.7. Organization .......................................11
5.1.8. P-Asserted-Identity ................................11
5.1.9. Record-Route .......................................12
5.1.10. Referred-By .......................................13
5.1.11. Reply-To ..........................................14
5.1.12. Server ............................................14
5.1.13. Subject ...........................................15
5.1.14. User-Agent ........................................15
5.1.15. Via ...............................................15
5.1.16. Warning ...........................................16
5.2. Target SDP Parameters .....................................16
5.2.1. c/m Lines ..........................................16
5.2.2. o Line .............................................17
5.2.3. i/u/e/p Lines ......................................17
5.3. Considerations for Non-Target SIP Headers/Parameters ......17
5.3.1. Identity/Identity-Info .............................17
5.3.2. Path ...............................................18
5.3.3. Replaces Header/Parameter ..........................18
5.3.4. Route ..............................................21
5.3.5. Service-Route ......................................21
5.3.6. Target-Dialog ......................................21
6. Security Considerations ........................................21
7. Acknowledgements ...............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Semantics of Existing priv-values ...............................4
4. Target for Each priv-value ......................................5
4.1. Target SIP Headers for Each priv-value .....................5
4.2. Target SDP Parameters for Each priv-value ..................6
4.3. Treatment of priv-value Not Supported by the
Privacy Service ............................................7
5. Recommended Treatment of User-Privacy-Sensitive Information .....7
5.1. Target SIP Headers .........................................7
5.1.1. Call-ID .............................................7
5.1.2. Call-Info ...........................................8
5.1.3. Contact .............................................8
5.1.4. From ................................................9
5.1.5. History-Info .......................................10
5.1.6. In-Reply-To ........................................10
5.1.7. Organization .......................................11
5.1.8. P-Asserted-Identity ................................11
5.1.9. Record-Route .......................................12
5.1.10. Referred-By .......................................13
5.1.11. Reply-To ..........................................14
5.1.12. Server ............................................14
5.1.13. Subject ...........................................15
5.1.14. User-Agent ........................................15
5.1.15. Via ...............................................15
5.1.16. Warning ...........................................16
5.2. Target SDP Parameters .....................................16
5.2.1. c/m Lines ..........................................16
5.2.2. o Line .............................................17
5.2.3. i/u/e/p Lines ......................................17
5.3. Considerations for Non-Target SIP Headers/Parameters ......17
5.3.1. Identity/Identity-Info .............................17
5.3.2. Path ...............................................18
5.3.3. Replaces Header/Parameter ..........................18
5.3.4. Route ..............................................21
5.3.5. Service-Route ......................................21
5.3.6. Target-Dialog ......................................21
6. Security Considerations ........................................21
7. Acknowledgements ...............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
This document clarifies the privacy mechanism for the Session Initiation Protocol (SIP) [RFC3261] defined in [RFC3323], which was later extended in [RFC3325] and [RFC4244]. This document describes the practical manner of operations of the privacy mechanism as a guideline and does not change the existing privacy mechanism.
本文件澄清了[RFC3323]中定义的会话启动协议（SIP）[RFC3261]的隐私机制，该协议后来在[RFC3325]和[RFC4244]中进行了扩展。本文件描述了隐私机制的实际操作方式，作为指南，并不改变现有的隐私机制。
In RFC 3323, the semantics of the basic set of priv-values (header, session, user, none, and critical) is defined, but there are some ambiguities in regards to the target information to be obscured per priv-value, which are not explicitly specified. An ambiguity such as this could result in different interpretations of privacy handling for each of the priv-values defined, both at an entity setting a Privacy header and at an entity processing a Privacy header, which could have an adverse impact on interoperability.
在RFC 3323中，定义了一组基本priv值（头、会话、用户、无和关键）的语义，但对于每个priv值要隐藏的目标信息，存在一些模糊性，没有明确指定。这样的模糊性可能会导致在设置隐私头的实体和处理隐私头的实体上对定义的每个priv值的隐私处理产生不同的解释，这可能会对互操作性产生不利影响。
Additional priv-values "id" and "history" are defined in RFCs 3325 and 4244, respectively.
RFCs 3325和4244中分别定义了其他priv值“id”和“history”。
In RFC 4244, the priv-value "history" is defined in order to request privacy for History-Info headers, and the target to be obscured for "history" priv-value is specified as only the History-Info headers. In addition, the RFC clearly describes that History-Info headers are also the target when "header"- and "session"-level privacy are requested.
在RFC 4244中，定义priv值“history”是为了请求历史信息头的隐私，并且为“history”priv值模糊的目标仅指定为历史信息头。此外，RFC清楚地描述了当请求“头”和“会话”级隐私时，历史信息头也是目标。
On the other hand, RFC 3325 defines the P-Asserted-Identity header and a priv-value "id", which is used to request privacy for only the P-Asserted-Identity header, but it does not specify how other priv-values may impact the privacy handling of the P-Asserted-Identity header. Because of this lack of specification, it has been observed that some implementations are suffering from the inability to achieve the intended privacy due to discrepancies in interpretations.
另一方面，RFC 3325定义了P-Asserted-Identity报头和priv值“id”，其用于仅请求P-Asserted-Identity报头的隐私，但它没有指定其他priv值如何影响P-Asserted-Identity报头的隐私处理。由于缺乏规范，已经观察到一些实现由于解释上的差异而无法实现预期的隐私。
This document tries to clarify the SIP headers and SDP parameters to be obscured for each of the priv-values to alleviate the potential interoperability issues already seen due to a lack of explicit text.
本文档试图澄清每个priv值要隐藏的SIP头和SDP参数，以缓解由于缺少明确文本而出现的潜在互操作性问题。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Note: This document is informational; therefore, it does not specify any new normative behaviors of privacy mechanism. All the RFC 2119 language in this document is derived from the normative text in the existing RFCs, such as RFC 3323.
注：本文件仅供参考；因此，它没有规定任何新的隐私机制规范行为。本文件中的所有RFC 2119语言均源自现有RFC（如RFC 3323）中的规范性文本。
priv-value: Values registered with IANA to be used in the Privacy header. Registered priv-values are "header", "session", "user", "none", and "critical" defined in [RFC3323]; "id" defined in [RFC3325]; and "history" defined in [RFC4244].
priv值：在IANA注册的值，用于隐私标头。注册的PRV值为[RFC3323]中定义的“头”、“会话”、“用户”、“无”和“关键”；[RFC3325]中定义的“id”；以及[RFC4244]中定义的“历史”。
privacy service: A network entity that executes privacy functions before forwarding messages to the next hop. It is sometimes abbreviated to PS in this document.
隐私服务：在将消息转发到下一跳之前执行隐私功能的网络实体。本文件中有时缩写为PS。
user-level privacy: Privacy for user-inserted information that can be anonymized by the user agent itself.
用户级隐私：用户插入信息的隐私，可由用户代理自身匿名。
This section provides the semantics of each priv-value defined in RFCs 3323, 3325, and 4244. The descriptions are taken from the IANA registration.
本节提供RFCs 3323、3325和4244中定义的每个priv值的语义。描述摘自IANA注册。
Privacy Type Description Reference
------------- ---------------------------------- ----------
user Request that privacy services [RFC3323]
provide a user-level privacy function
Privacy Type Description Reference
------------- ---------------------------------- ----------
user Request that privacy services [RFC3323]
provide a user-level privacy function
header Request that privacy services modify [RFC3323] headers that cannot be set arbitrarily by the user (Contact/Via).
报头请求隐私服务修改用户无法任意设置的[RFC3323]报头（联系人/通过）。
session Request that privacy services provide [RFC3323] privacy for session media
会话请求隐私服务为会话媒体提供[RFC3323]隐私
none Privacy services must not perform any [RFC3323] privacy function
无隐私服务不得执行任何[RFC3323]隐私功能
critical Privacy service must perform the [RFC3323] specified services or fail the request
关键隐私服务必须执行[RFC3323]指定的服务，否则请求将失败
id Privacy requested for Third-Party [RFC3325] Asserted Identity
为第三方[RFC3325]声明的身份请求的id隐私
history Privacy requested for [RFC4244] History-Info header(s)
[RFC4244]历史信息头请求的历史隐私
Tables in this section show the recommended treatment of SIP headers and SDP parameters per priv-value. SIP headers and SDP parameters not shown in the tables are regarded as non-targets of these priv-values. Some non-target SIP headers/SDP parameters may carry privacy-sensitive information that may need privacy treatment regardless of the privacy level requested. This is further described in 5.3.
本节中的表格显示了每个priv值对SIP头和SDP参数的建议处理方式。表中未显示的SIP头和SDP参数被视为这些priv值的非目标。一些非目标SIP头/SDP参数可能携带隐私敏感信息，无论请求的隐私级别如何，这些信息都可能需要隐私处理。这将在5.3中进一步说明。
The way in which SIP headers and SDP parameters listed here are obscured may depend on the implementation and network policy. This document does not prevent different variations that may exist based on local policy but tries to provide recommendations for how a privacy service treats SIP headers and SDP parameters.
此处列出的SIP头和SDP参数的隐藏方式可能取决于实现和网络策略。本文档不阻止基于本地策略可能存在的不同变体，但尝试提供隐私服务如何处理SIP头和SDP参数的建议。
Note: The scope of these tables is SIP headers and related parameters specified in RFCs.
注意：这些表的范围是RFCs中指定的SIP头和相关参数。
Table 1 below shows a recommended treatment of each SIP header for each priv-value. Detailed descriptions of the recommended treatment per SIP header are covered in Section 5.
下表1显示了针对每个priv值的每个SIP头的建议处理方法。第5节详细介绍了每个SIP头的建议处理方法。
The "where" column describes the request and response types in which the header needs the treatment to maintain privacy. Values in this column are:
“where”列描述了报头需要处理以维护隐私的请求和响应类型。此列中的值为：
R: The header needs the treatment when it appears in a request.
R：当标题出现在请求中时，需要对其进行处理。
r: The header needs the treatment when it appears in a response.
r：标题出现在响应中时需要处理。
The next five columns show the recommended treatment for each priv-value:
接下来的五列显示了每个priv值的建议处理方法：
delete: The header is recommended to be deleted at a privacy service.
删除：建议在隐私服务中删除标题。
not add: The header is recommended not to be added at a privacy service.
不添加：建议不要在隐私服务中添加标题。
anonymize: The header is recommended to be anonymized at a privacy service. How to anonymize the header depends on the header. Details are given in Section 5.
匿名化：建议在隐私服务中将标题匿名化。如何匿名化标头取决于标头。详情见第5节。
anonymize*: An asterisk indicates that the involvement of a privacy service and treatment of the relevant header depend on the circumstance. Details are given in Section 5.
匿名*：星号表示隐私服务的参与和相关标头的处理取决于具体情况。详情见第5节。
Target headers where user header session id history
--------------------------------------------------------------------
Call-ID (Note) R anonymize - - - -
Call-Info Rr delete not add - - -
Contact R - anonymize - - -
From R anonymize - - - -
History-Info Rr - delete delete - delete
In-Reply-To R delete - - - -
Organization Rr delete not add - - -
P-Asserted-Identity Rr - delete - delete -
Record-Route Rr - anonymize - - -
Referred-By R anonymize* - - - -
Reply-To Rr delete - - - -
Server r delete not add - - -
Subject R delete - - - -
User-Agent R delete - - - -
Via R - anonymize - - -
Warning r anonymize - - - -
Target headers where user header session id history
--------------------------------------------------------------------
Call-ID (Note) R anonymize - - - -
Call-Info Rr delete not add - - -
Contact R - anonymize - - -
From R anonymize - - - -
History-Info Rr - delete delete - delete
In-Reply-To R delete - - - -
Organization Rr delete not add - - -
P-Asserted-Identity Rr - delete - delete -
Record-Route Rr - anonymize - - -
Referred-By R anonymize* - - - -
Reply-To Rr delete - - - -
Server r delete not add - - -
Subject R delete - - - -
User-Agent R delete - - - -
Via R - anonymize - - -
Warning r anonymize - - - -
Table 1: Recommended PS behavior for each SIP header
表1：每个SIP头的建议PS行为
Note: Any time a privacy service modifies a Call-ID, it MUST retain the former and modified values as indicated in Section 5.3 in RFC 3323. It MUST then restore the former value in a Call-ID header and other corresponding headers and parameters (such as In-Reply-To, Replaces, and Target-Dialog) in any messages that are sent using the modified Call-ID to the originating user agent. It should also modify a Call-ID header and other corresponding headers/parameters (such as Target-Dialog and "replaces" parameter) in any further relevant messages that are sent by the originating user agent. Refer to Section 5.1.1 (Call-ID) for the detailed behavior.
注：任何时候，隐私服务修改呼叫ID时，必须保留RFC 3323第5.3节中所述的前一个和修改后的值。然后，它必须恢复调用ID头中的前一个值，以及使用修改后的调用ID发送到原始用户代理的任何消息中的其他相应头和参数（例如在回复、替换和目标对话框中）。它还应修改发起用户代理发送的任何其他相关消息中的呼叫ID头和其他相应头/参数（如目标对话框和“替换”参数）。有关详细行为，请参阅第5.1.1节（呼叫ID）。
Identity/Identity-Info, Path, Replaces, Route, Service-Route, and Target-Dialog headers are not targets of these priv-values (and should not be anonymized or modified by a privacy service based on a priv-value in a Privacy header). Refer to Section 5.3 for details.
身份/身份信息、路径、替换、路由、服务路由和目标对话框头不是这些priv值的目标（并且不应由隐私服务基于隐私头中的priv值进行匿名化或修改）。详见第5.3节。
The recommended PS behaviors for each SDP parameters are simple. The c, m, o, i, u, e, and p lines in SIP request/response are recommended to be anonymized when user privacy is requested with Privacy:session.
每个SDP参数的建议PS行为很简单。当使用privacy:session请求用户隐私时，建议对SIP请求/响应中的c、m、o、i、u、e和p行进行匿名化。
As specified in RFC 3323, if the priv-value of "critical" is present in the Privacy header of a request, and if the privacy service is incapable of performing all of the levels of privacy specified in the Privacy header, it MUST fail the request with a 500 (Server Error) response code as indicated in Section 5 in RFC 3323.
如RFC 3323所述，如果请求的隐私报头中存在“critical”的priv值，并且如果隐私服务无法执行隐私报头中指定的所有隐私级别，则它必须使用RFC 3323第5节所示的500（服务器错误）响应代码使请求失败。
Since the protection of privacy is important, even if the priv-value "critical" is not present in the Privacy header, the privacy service should fail the request with a 500 response code when it is incapable of performing all of the levels of privacy specified in the Privacy header.
由于隐私保护很重要，即使隐私报头中不存在priv值“critical”，当隐私服务无法执行隐私报头中指定的所有隐私级别时，也应使用500响应代码使请求失败。
The following SIP headers and related parameters may concern privacy. This section describes what kind of user-privacy-sensitive information may be included in each SIP header/parameter, and how to maintain privacy for such information at a user agent or a privacy service when the information is indeed privacy-sensitive.
以下SIP头和相关参数可能涉及隐私。本节描述了在每个SIP头/参数中可能包含哪些类型的用户隐私敏感信息，以及当这些信息确实对隐私敏感时，如何在用户代理或隐私服务中维护这些信息的隐私。
This section describes privacy considerations and recommended treatment for each SIP header that may reveal user-privacy-sensitive information. This section goes into details about how each header affects privacy, the desired treatment of the value by the user agent and privacy service, and other instructions/additional notes necessary to provide privacy.
本节介绍隐私注意事项以及可能泄露用户隐私敏感信息的每个SIP头的建议处理方法。本节详细介绍了每个标题如何影响隐私、用户代理和隐私服务对值的期望处理，以及提供隐私所需的其他说明/附加说明。
This field frequently contains an IP address or hostname of a UAC (User Agent Client) appended to the Call-ID value.
此字段通常包含附加到调用ID值的UAC（用户代理客户端）的IP地址或主机名。
A user agent executing a user-level privacy function on its own 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) as indicated in Section 4.1 in RFC 3323.
如RFC 3323第4.1节所示，自行执行用户级隐私功能的用户代理应使用适当长的随机值（用作请求From标头的“标记”的值，甚至可以重新使用）来代替经常附加到调用ID值的IP地址或主机名。
A privacy service MAY anonymize the Call-ID header when the request contains Privacy:user by substituting for the IP address or hostname in the Call-ID a suitably long random value (such as a From tag value) so that it is sufficiently unique as indicated in Section 5.3 in RFC 3323.
当请求包含privacy:user时，隐私服务可通过将呼叫ID中的IP地址或主机名替换为适当长的随机值（如From标记值）来匿名呼叫ID标头，从而使其具有RFC 3323第5.3节所述的足够唯一性。
Call-ID is essential to dialog matching, so any time a privacy service modifies this field, it MUST retain the former value and restore it in a Call-ID header in any messages that are sent to/by the originating user agent inside the dialog as indicated in Section 5.3 in RFC 3323. A privacy service should be prepared to receive a request outside the dialog containing the value of the Call-ID set by the PS in other SIP headers (e.g., In-Reply-To/Replaces/ Target-Dialog), at least while the dialog state is active for the dialog whose Call-ID was modified by that PS. When such a request is received, the Call-ID value contained in the relevant headers indicated above should be replaced by the retained value.
调用ID对于对话框匹配至关重要，因此，隐私服务在任何时候修改此字段时，都必须保留前一个值，并将其恢复到任何消息中的调用ID头中，该消息由对话框内的发起用户代理发送/由发起用户代理发送，如RFC 3323第5.3节所示。隐私服务应准备好在对话外部接收请求，该请求包含PS在其他SIP头中设置的呼叫ID值（例如，在回复/替换/目标对话中），至少在对话状态为激活状态时，该对话的呼叫ID由该PS修改。当收到该请求时，上述相关标头中包含的调用ID值应替换为保留值。
Note: This is possible only if the privacy service maintains the state and retains all the information it modified to provide privacy. Some PSs are known to encrypt information prior to obfuscation in the Via header, etc. In this case, the PS cannot correlate the modified Call-ID value with the original Call-ID. Further challenges are imposed when the PS needs to stay on a signaling path to ensure that it receives all the messages targeted towards the caller for which a PS provides privacy, especially when the request is out-of-dialog.
注意：只有当隐私服务维护状态并保留为提供隐私而修改的所有信息时，这才有可能。已知一些PSs会在Via标头等中进行混淆之前对信息进行加密。在这种情况下，PS无法将修改后的Call-ID值与原始Call-ID相关联。当PS需要停留在信令路径上以确保其接收到针对PS提供隐私的呼叫方的所有消息时，尤其是当请求不在对话中时，会带来进一步的挑战。
Refer to the corresponding sections, 5.1.6 (In-Reply-To), 5.3.3 (Replaces Header/Parameter), and 5.3.6 (Target-Dialog), for detailed discussion.
有关详细讨论，请参阅相应章节5.1.6（回复）、5.3.3（替换标题/参数）和5.3.6（目标对话框）。
This field contains additional information about the user.
此字段包含有关用户的其他信息。
A user agent executing a user-level privacy function on its own SHOULD NOT add a Call-Info header as indicated in Section 4.1 in RFC 3323.
如RFC 3323第4.1节所述，自行执行用户级隐私功能的用户代理不应添加呼叫信息头。
A privacy service MUST delete a Call-Info header if one exists when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323. A privacy service SHOULD NOT add a Call-Info header when user privacy is requested with Privacy:header as indicated in Section 5.1 in RFC 3323.
如RFC 3323第5.3节所述，当请求用户隐私时，隐私服务必须删除呼叫信息头（如果存在）。如RFC 3323第5.1节所示，隐私服务不应在请求用户隐私时添加呼叫信息报头。
This field contains a URI used to reach the user agent for mid-dialog requests and possibly out-of-dialog requests, such as REFER [RFC3315]. Since the Contact header is essential for routing further requests to the user agent, it must include a functional URI even when it is anonymized.
此字段包含一个URI，该URI用于访问用户代理以获取对话中请求和可能的对话外请求，如参考[RFC3315]。由于联系人标头对于将进一步的请求路由到用户代理至关重要，因此它必须包含一个功能URI，即使它是匿名的。
A user agent MUST NOT anonymize a Contact header, unless it can obtain an IP address or contact address that is functional yet has a characteristic of anonymity as indicated in Section 4.1.1.3 in RFC 3323.
用户代理不得匿名化联系人报头，除非其能够获得IP地址或联系人地址，该IP地址或联系人地址具有RFC 3323第4.1.1.3节所述的匿名特性。
Since RFC 3323 was published, there have been proposals that allow UAs to obtain an IP address or contact address with a characteristic of anonymity.
自RFC3323发布以来，已有一些建议允许UAs获得具有匿名特征的IP地址或联系地址。
The mechanisms that are discussed at the time of this writing are Globally Routable User Agent URIs (GRUU) [SIPGRUU], which provides a functional Contact address with a short life span, making it ideal for privacy sensitive calls, and Traversal Using Relays around NAT (TURN) [TURN], through which an IP address of a relay can be obtained for use in a Contact header.
在撰写本文时讨论的机制是全局可路由用户代理URI（GRUU）[SIPGRUU]，它提供了一个具有短生命周期的功能性联系地址，非常适合于隐私敏感的呼叫，并使用NAT（TURN）[TURN]周围的中继进行遍历，通过它可以获得继电器的IP地址，以便在联系人报头中使用。
A privacy service SHOULD anonymize a Contact header by replacing the existing Contact header field value with the URI that dereferences to the privacy service when user privacy is requested with Privacy:header, as indicated in Section 5.1 in RFC 3323. This is generally done by replacing the IP address or hostname with that of the privacy service.
隐私服务应匿名化联系人标头，方法是将现有联系人标头字段值替换为URI，当用户隐私请求为隐私：标头时，该URI将取消对隐私服务的引用，如RFC 3323第5.1节所示。这通常是通过将IP地址或主机名替换为隐私服务的IP地址或主机名来实现的。
This field contains the identity of the user, such as display-name and URI.
此字段包含用户的标识，例如显示名称和URI。
A user agent executing a user-level privacy function on its own SHOULD anonymize a From header using an anonymous display-name and an anonymous URI as indicated in Section 4.1 in RFC 3323.
自行执行用户级隐私功能的用户代理应使用匿名显示名称和匿名URI对From标头进行匿名化，如RFC 3323第4.1节所示。
A privacy service should anonymize a From header when user privacy is requested with Privacy:user.
当使用privacy:user请求用户隐私时，隐私服务应匿名化From头。
Note: This does not prevent a privacy service from anonymizing the From header based on local policy.
注意：这不会阻止隐私服务根据本地策略匿名化from标头。
The anonymous display-name and anonymous URI mentioned in this section use display-name "Anonymous", a URI with "anonymous" in the user portion of the From header, and the hostname value "anonymous.invalid" as indicated in Section 4.1.1.3 in RFC 3323.
本节中提到的匿名显示名和匿名URI使用显示名“anonymous”、From标头用户部分中带有“anonymous”的URI以及RFC 3323第4.1.1.3节中所述的主机名值“anonymous.invalid”。
The recommended form of the From header for anonymity is:
建议匿名使用From标头的形式为：
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
The tag value varies from dialog to dialog, but the rest of this header form is recommended as shown.
标记值因对话框而异，但建议使用此标题表单的其余部分，如图所示。
History-Info [RFC4244] header URIs to which the request was forwarded or retargeted can reveal general routing information.
历史信息[RFC4244]请求转发或重定目标的头URI可以显示一般路由信息。
A user agent executing a user-level privacy function on its own SHOULD NOT add a History-Info header as indicated in Section 3.3 in RFC 4244.
如RFC 4244第3.3节所示，自行执行用户级隐私功能的用户代理不应添加历史信息头。
A privacy service SHOULD delete the History-Info headers when user privacy is requested with Privacy:header, Privacy:session, or Privacy:history as indicated in Section 3.3 in RFC 4244.
如RFC 4244中第3.3节所示，当用户隐私请求隐私：标题、隐私：会话或隐私：历史时，隐私服务应删除历史信息标题。
The privacy could be also expressed for a specific History-Info entry by inserting "privacy=history" in the History-Info header. In such a case, a privacy service SHOULD delete the History-Info entry as indicated in Section 4.3.3.1.1 in RFC 4244.
还可以通过在历史信息标题中插入“privacy=History”来表示特定历史信息条目的隐私。在这种情况下，隐私服务应删除历史信息条目，如RFC 4244第4.3.3.1.1节所示。
Refer to [RFC4244] for detailed behavior for dealing with History-Info headers.
有关处理历史信息头的详细行为，请参阅[RFC4244]。
The In-Reply-To header contains a Call-ID of the referenced dialog. The replying user may be identified by the Call-ID in an In-Reply-To header.
In-Reply To标头包含引用对话框的调用ID。应答用户可以通过应答报头中的呼叫ID来识别。
Alice > INV(Call-ID:C1) > Bob
Bob > INV(In-Reply-To:C1) > Alice
Alice > INV(Call-ID:C1) > Bob
Bob > INV(In-Reply-To:C1) > Alice
In this case, unless the In-Reply-To header is deleted, Alice might notice that the replying user is Bob because Alice's UA knows that the Call-ID relates to Bob.
在这种情况下，除非删除In-Reply-To报头，否则Alice可能会注意到应答用户是Bob，因为Alice的UA知道呼叫ID与Bob相关。
A user agent executing a user-level privacy function on its own should not add an In-Reply-To header as implied in Section 4.1 in RFC 3323.
自行执行用户级隐私功能的用户代理不应添加RFC 3323第4.1节中暗示的回复标头。
A privacy service MUST delete the In-Reply-To header when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323.
如RFC 3323第5.3节所述，当使用隐私：用户请求用户隐私时，隐私服务必须删除回复标题中的内容。
In addition, since an In-Reply-To header contains the Call-ID of the dialog to which it is replying, special attention is required, as described in Section 5.1.1 (Call-ID), regardless of the priv-value or
此外，由于In Reply To标头包含其应答的对话框的呼叫ID，因此需要特别注意，如第5.1.1节（呼叫ID）所述，无论priv值或
presence of a Privacy header. Once a privacy service modifies a Call-ID in the request, a privacy service should restore the former value in an In-Reply-To header, if present in the INVITE request replying to the original request, as long as the privacy service maintains the dialog state.
存在隐私标头。一旦隐私服务修改了请求中的呼叫ID，只要隐私服务保持对话状态，隐私服务就应该恢复回复到头中的前一个值（如果在回复原始请求的INVITE请求中存在）。
Example:
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Bob > INV(In-Reply-To:C2, Privacy:none) > PS >
INV(In-Reply-To:C1) > Alice
Example:
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Bob > INV(In-Reply-To:C2, Privacy:none) > PS >
INV(In-Reply-To:C1) > Alice
Note: This is possible only if the privacy service maintains the state and retains all the information that it modified to provide privacy even after the dialog has been terminated, which is unlikely. Call-back is difficult to achieve when a privacy service is involved in forming the dialog to be referenced.
注意：只有在隐私服务保持状态并保留其修改以提供隐私的所有信息（即使在对话框终止后）时，这才可能实现，这是不可能的。当隐私服务参与形成要引用的对话框时，很难实现回拨。
This field contains additional information about the user.
此字段包含有关用户的其他信息。
A user agent executing a user-level privacy function on its own should not add an Organization header as implied in Section 4.1 in RFC 3323.
自行执行用户级隐私功能的用户代理不应添加RFC 3323第4.1节中暗示的组织标头。
A privacy service MUST delete the Organization header if one exists when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323. A privacy service SHOULD NOT add an Organization header when user privacy is requested with Privacy: header as indicated in Section 5.1 in RFC 3323.
如RFC 3323第5.3节所述，当用户隐私请求为隐私：用户时，隐私服务必须删除组织标题（如果存在）。如RFC 3323第5.1节所示，隐私服务不应在使用privacy:header请求用户隐私时添加组织标题。
This header contains a network-verified and network-asserted identity of the user sending a SIP message.
此标头包含发送SIP消息的用户的网络验证和网络断言标识。
A privacy service MUST delete the P-Asserted-Identity headers when user privacy is requested with Privacy:id as indicated in Section 7 in RFC 3325 and should delete the P-Asserted-Identity headers when user privacy is requested with Privacy:header before it forwards the message to an entity that is not trusted.
如RFC 3325第7节所示，当使用privacy:id请求用户隐私时，隐私服务必须删除P-Asserted-Identity标头，当使用privacy:header请求用户隐私时，隐私服务应在将消息转发给不受信任的实体之前删除P-Asserted-Identity标头。
It is recommended for a privacy service to remove the P-Asserted-Identity header if user privacy is requested with Privacy:id or Privacy:header even when forwarding to a trusted entity, unless it can be confident that the message will not be routed to an untrusted entity without going through another privacy service.
如果使用privacy:id或privacy:header请求用户隐私，则建议隐私服务删除P-Asserted-Identity标头，即使在转发到受信任的实体时也是如此，除非它可以确信消息不会在不经过其他隐私服务的情况下路由到不受信任的实体。
This field may reveal information about the administrative domain of the user.
此字段可能显示有关用户管理域的信息。
In order to hide Record-Route headers while keeping routability to the sender, privacy services can execute a practice referred to as "stripping". Stripping means removing all the Record-Route headers that have been added to the request prior to its arrival at the privacy service and then adding a single Record-Route header representing itself. In this case, the privacy service needs to retain the removed headers and restore them in a response.
为了隐藏记录路由头，同时保持对发送方的路由能力，隐私服务可以执行一种称为“剥离”的做法。剥离意味着删除在请求到达隐私服务之前添加到请求中的所有记录路由头，然后添加一个表示其自身的记录路由头。在这种情况下，隐私服务需要保留删除的头并在响应中恢复它们。
Alternatively, privacy services can remove the Record-Route headers and encrypt them into a single Record-Route header field. In this case, the privacy service needs to decrypt the header and restore the former values in a response.
或者，隐私服务可以删除记录路由头并将其加密到单个记录路由头字段中。在这种情况下，隐私服务需要解密报头并在响应中恢复以前的值。
A privacy service SHOULD strip or encrypt any Record-Route headers that have been added to a message before it reaches the privacy service when user privacy is requested with Privacy:header as indicated in Section 5.1 in RFC 3323.
如RFC 3323第5.1节所示，当请求用户隐私时，隐私服务应剥离或加密在消息到达隐私服务之前添加到消息中的任何记录路由头。
As in the case of a Call-ID, if a privacy service modifies the Record-Route headers, it MUST be able to restore Route headers with retained values as indicated in Section 5.1 in RFC 3323. Some examples where the restoration of the Route headers is necessary and unnecessary are given below.
与呼叫ID的情况一样，如果隐私服务修改记录路由头，它必须能够使用保留值还原路由头，如RFC 3323第5.1节所示。下面给出了一些需要和不需要恢复路由头的示例。
When a UAC (Alice) requires privacy for a request, a privacy service does not have to restore the Route headers in the subsequent request (see Example 1).
当UAC（Alice）要求请求隐私时，隐私服务不必在后续请求中恢复路由头（参见示例1）。
On the other hand, when a UAS (User Agent Server) (Bob) requires privacy for a response, a privacy service has to restore the Route headers in the subsequent request (see Example 2).
另一方面，当UAS（用户代理服务器）（Bob）要求响应具有隐私时，隐私服务必须在后续请求中恢复路由头（参见示例2）。
Example 1:
Restoration of Route header is UNNECESSARY when UAC requires privacy
Alice > INV(Privacy:header) > P1 >
INV(Record-Route:P1, Privacy:header) > PS >
INV(Record-Route:PS) > P2 >
INV(Record-Route:P2,PS) > Bob
Bob > 200(Record-Route:P2,PS) > P2 > PS >
200(Record-Route:P2,PS,P1) > P1 > Alice
Alice > re-INV(Route:P2,PS,P1, Privacy:header) > P1 >
re-INV(Route:P2,PS, Privacy:header) > PS >
re-INV(Route:P2) > P2 > re-INV > Bob
Example 1:
Restoration of Route header is UNNECESSARY when UAC requires privacy
Alice > INV(Privacy:header) > P1 >
INV(Record-Route:P1, Privacy:header) > PS >
INV(Record-Route:PS) > P2 >
INV(Record-Route:P2,PS) > Bob
Bob > 200(Record-Route:P2,PS) > P2 > PS >
200(Record-Route:P2,PS,P1) > P1 > Alice
Alice > re-INV(Route:P2,PS,P1, Privacy:header) > P1 >
re-INV(Route:P2,PS, Privacy:header) > PS >
re-INV(Route:P2) > P2 > re-INV > Bob
Alice P1 PS P2 Bob
| | | | |
| INV Priv |INV Priv RR:P1 | INV RR:PS | INV RR:P2,PS |
|---------------->|---------------->|---------------->|-------------->|
| | | | |
| 200 RR:P2,PS,P1 | 200 RR:P2,PS,P1 | 200 RR:P2,PS | 200 RR:P2,PS |
|<----------------|<----------------|<----------------|<--------------|
| | | | |
| INV R:P2,PS,P1 | INV R:P2,PS | INV R:P2 | INV |
|---------------->|---------------->|---------------->|-------------->|
| | | | |
Alice P1 PS P2 Bob
| | | | |
| INV Priv |INV Priv RR:P1 | INV RR:PS | INV RR:P2,PS |
|---------------->|---------------->|---------------->|-------------->|
| | | | |
| 200 RR:P2,PS,P1 | 200 RR:P2,PS,P1 | 200 RR:P2,PS | 200 RR:P2,PS |
|<----------------|<----------------|<----------------|<--------------|
| | | | |
| INV R:P2,PS,P1 | INV R:P2,PS | INV R:P2 | INV |
|---------------->|---------------->|---------------->|-------------->|
| | | | |
Figure 1: Example when restoration of Route header is UNNECESSARY
图1：不需要恢复路由头的示例
Example 2:
Restoration of Route header is NECESSARY when UAS requires privacy
Alice > INV > P1 > INV(Record-Route:P1) > P2 >
INV(Record-Route:P2,P1) > Bob
Bob > 200(Record-Route:P2,P1, Privacy:header) > P2 > PS' >
200(Record-Route:PS',P1) > P1 > Alice
Alice > re-INV(Route:PS',P1) > P1 > re-INV(Route:PS') > PS' >
re-INV(Route:P2) > P2 > Bob
Example 2:
Restoration of Route header is NECESSARY when UAS requires privacy
Alice > INV > P1 > INV(Record-Route:P1) > P2 >
INV(Record-Route:P2,P1) > Bob
Bob > 200(Record-Route:P2,P1, Privacy:header) > P2 > PS' >
200(Record-Route:PS',P1) > P1 > Alice
Alice > re-INV(Route:PS',P1) > P1 > re-INV(Route:PS') > PS' >
re-INV(Route:P2) > P2 > Bob
Alice P1 PS' P2 Bob
| | | | |
| INV |INV RR:P1 | | INV RR:P2,P1 |
|-------------->|---------------------------------->|---------------->|
| | | | |
| 200 RR:PS',P1 | 200 RR:PS',P1 |200 Priv RR:P2,P1|200 Priv RR:P2,P1|
|<--------------|<----------------|<----------------|<----------------|
| | | | |
| INV R:PS',P1 | INV R:PS' | INV R:P2 | INV |
|-------------->|---------------->|---------------->|---------------->|
| | | (Restored) | |
Alice P1 PS' P2 Bob
| | | | |
| INV |INV RR:P1 | | INV RR:P2,P1 |
|-------------->|---------------------------------->|---------------->|
| | | | |
| 200 RR:PS',P1 | 200 RR:PS',P1 |200 Priv RR:P2,P1|200 Priv RR:P2,P1|
|<--------------|<----------------|<----------------|<----------------|
| | | | |
| INV R:PS',P1 | INV R:PS' | INV R:P2 | INV |
|-------------->|---------------->|---------------->|---------------->|
| | | (Restored) | |
Figure 2: Example when restoration of Route header is NECESSARY
图2：需要恢复路由头时的示例
Note: In Figures 1 and 2, Priv means Privacy:header, RR means Record-Route header, and R means Route header.
注：在图1和图2中，Priv表示隐私：头，RR表示记录路由头，R表示路由头。
The Referred-By [RFC3892] header carries a SIP URI representing the identity of the referrer.
REFERED By[RFC3892]头包含一个SIP URI，表示引用者的身份。
The Referred-By header is an anonymization target when the REFER request with the Referred-By header is sent by the user (referrer) whose privacy is requested to be processed in the privacy service.
当隐私服务中请求处理其隐私的用户（推荐人）发送带有推荐人报头的推荐请求时，推荐人报头是匿名化目标。
A user agent that constructs REFER requests executing a user-level privacy function on its own should anonymize a Referred-By header by using an anonymous URI.
构造refered请求并自行执行用户级隐私功能的用户代理应使用匿名URI对refered By头进行匿名化。
A privacy service should anonymize a Referred-By header in a REFER request by using an anonymous URI when user privacy is requested with Privacy:user.
当使用privacy:user请求用户隐私时，隐私服务应该通过使用匿名URI来匿名refered请求中的refered By头。
On the other hand, the Referred-By header is not an anonymization target when it appears in a request other than REFER (e.g., INVITE) because the URI in the Referred-By header does not represent the sender of the request.
另一方面，当refered By报头出现在refered以外的请求（例如INVITE）中时，它不是匿名化目标，因为refered By报头中的URI不代表请求的发送者。
Example 1:
Referrer requests no privacy and referee requests privacy
Alice > REF(Referred-By:Alice) > Bob
Bob > INV(Referred-By:Alice, Privacy:user) > PS >
INV(Referred-By:Alice) > Carol
Example 1:
Referrer requests no privacy and referee requests privacy
Alice > REF(Referred-By:Alice) > Bob
Bob > INV(Referred-By:Alice, Privacy:user) > PS >
INV(Referred-By:Alice) > Carol
Example 2:
Referrer requests privacy and referee requests privacy
Alice > REF(Referred-By:Alice, Privacy:user) > PS >
REF(Referred-By:X) > Bob
Bob > INV(Referred-By:X, Privacy:user) > PS >
INV(Referred-By:X) > Carol
Example 2:
Referrer requests privacy and referee requests privacy
Alice > REF(Referred-By:Alice, Privacy:user) > PS >
REF(Referred-By:X) > Bob
Bob > INV(Referred-By:X, Privacy:user) > PS >
INV(Referred-By:X) > Carol
This field contains a URI that can be used to reach the user on subsequent call-backs.
此字段包含一个URI，可用于在后续回调时联系用户。
A user agent executing a user-level privacy function on its own should not add a Reply-To header in the message as implied in Section 4.1 in RFC 3323.
如RFC 3323第4.1节所述，自行执行用户级隐私功能的用户代理不应在消息中添加回复头。
A privacy service MUST delete a Reply-To header when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323.
如RFC 3323第5.3节所述，当使用privacy:user请求用户隐私时，隐私服务必须删除回复标题。
This field contains information about the software used by the UAS to handle the request.
此字段包含有关UAS用于处理请求的软件的信息。
A user agent executing a user-level privacy function on its own should not add a Server header in the response as implied in Section 4.1 in RFC 3323.
自行执行用户级隐私功能的用户代理不应在响应中添加服务器头，如RFC 3323第4.1节所示。
A privacy service must delete a Server header in a response when user privacy is requested with Privacy:user. A privacy service SHOULD NOT add a Server header in a response when user privacy is requested with Privacy:header as indicated in Section 5.1 in RFC 3323.
当使用privacy:user请求用户隐私时，隐私服务必须在响应中删除服务器头。如RFC 3323第5.1节所示，当使用privacy:头请求用户隐私时，隐私服务不应在响应中添加服务器头。
This field contains free-form text about the subject of the call. It may include text describing something about the user.
此字段包含有关呼叫主题的自由格式文本。它可能包括描述用户某些信息的文本。
A user agent executing a user-level privacy function on its own should not include any information identifying the caller in a Subject header.
单独执行用户级隐私功能的用户代理不应在主题标头中包含识别调用方的任何信息。
A privacy service MUST delete a Subject header when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323.
如RFC 3323第5.3节所述，当用户隐私请求为隐私：用户时，隐私服务必须删除主题标题。
This field contains the UAC's information.
此字段包含UAC的信息。
A user agent executing a user-level privacy function on its own should not add a User-Agent header as implied in Section 4.1 in RFC 3323.
自行执行用户级隐私功能的用户代理不应添加RFC 3323第4.1节中暗示的用户代理标头。
A privacy service MUST delete a User-Agent header when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323.
如RFC 3323第5.3节所述，当使用privacy:User请求用户隐私时，隐私服务必须删除用户代理标头。
The bottommost Via header added by a user agent contains the IP address and port or hostname that are used to reach the user agent for responses. Via headers added by proxies may reveal information about the administrative domain of the user.
用户代理添加的最底部的Via头包含IP地址和端口或主机名，用于到达用户代理进行响应。代理添加的Via头可能会显示有关用户管理域的信息。
A user agent MUST NOT anonymize a Via header as indicated in Section 4.1.1.3 in RFC 3323, unless it can obtain an IP address that is functional yet has a characteristic of anonymity. This may be possible by obtaining an IP address specifically for this purpose either from the service provider or through features such as TURN.
用户代理不得如RFC 3323第4.1.1.3节所述匿名化Via头，除非它可以获得一个功能正常但具有匿名特性的IP地址。这可以通过从服务提供商处或通过TURN等功能获取专门用于此目的的IP地址来实现。
A privacy service SHOULD strip or encrypt any Via headers that have been added prior to reaching the privacy service when user privacy is requested with Privacy:header as indicated in Section 5.1 in RFC 3323. Refer to Section 5.1.9 (Record-Route) for details of stripping and encryption.
如RFC 3323第5.1节所示，当用户隐私请求隐私：标题时，隐私服务应剥离或加密在到达隐私服务之前添加的任何Via标题。有关剥离和加密的详细信息，请参阅第5.1.9节（记录路线）。
A privacy service MUST restore the original values of Via headers when handling a response in order to route the response to the originator as indicated in Section 5.1 in RFC 3323.
如RFC 3323第5.1节所示，隐私服务在处理响应时必须恢复Via报头的原始值，以便将响应路由到发起人。
No Via stripping is required when handling responses.
处理响应时不需要通孔剥离。
This field may contain the hostname of the UAS.
此字段可能包含UAS的主机名。
A user agent executing a user-level privacy function on its own should not include the hostname representing its identity in a Warning header.
单独执行用户级隐私功能的用户代理不应在警告标头中包含表示其身份的主机名。
A privacy service should anonymize a Warning header by deleting the hostname portion (if it represents a UAS's identity) from the header when user privacy is requested with Privacy:user.
当使用privacy:user请求用户隐私时，隐私服务应通过从报头中删除主机名部分（如果它代表UAS的身份）来匿名化警告报头。
This section describes privacy considerations for each SDP [RFC4566] parameter that may reveal information about the user.
本节介绍每个SDP[RFC4566]参数的隐私注意事项，这些参数可能会泄露有关用户的信息。
When privacy functions for user-inserted information are requested to be executed at a privacy service, user agents MUST NOT encrypt SDP bodies in messages as indicated in Section 4.2 in RFC 3323.
当要求在隐私服务中执行用户插入信息的隐私功能时，用户代理不得按照RFC 3323第4.2节中的说明对消息中的SDP正文进行加密。
The c and m lines in the SDP body convey the IP address and port for receiving media.
SDP主体中的c和m线传送IP地址和用于接收媒体的端口。
A user agent must not anonymize the IP address and port in the c and m lines, unless it can obtain an IP address that is functional yet has a characteristic of anonymity as implied in Section 4.1.1.3 in RFC 3323. This may be possible by obtaining an IP address specifically for this purpose either from the service provider or through features such as TURN.
用户代理不得匿名化c和m线路中的IP地址和端口，除非其可以获得一个IP地址，该IP地址在功能上仍然具有RFC 3323第4.1.1.3节中暗示的匿名特性。这可以通过从服务提供商处或通过TURN等功能获取专门用于此目的的IP地址来实现。
A privacy service must anonymize the IP address and port in c and m lines using a functional anonymous IP address and port when user privacy is requested with Privacy:session. This is generally done by replacing the IP address and port present in the SDP with that of a relay server.
当使用privacy:session请求用户隐私时，隐私服务必须使用功能性匿名IP地址和端口对c和m线路中的IP地址和端口进行匿名化。这通常通过将SDP中的IP地址和端口替换为中继服务器的IP地址和端口来实现。
The username and IP address in this parameter may reveal information about the user.
此参数中的用户名和IP地址可能会显示有关用户的信息。
A user agent may anonymize the username in an o line by setting username to "-" and anonymize the IP address in the o line by replacing it with a value so that it is sufficiently unique.
用户代理可以通过将用户名设置为“-”来匿名化o行中的用户名，并通过将其替换为值来匿名化o行中的IP地址，从而使其具有足够的唯一性。
A privacy service must anonymize the username and IP address in the o line by setting the username to "-" and replacing the IP address with a value so that it is sufficiently unique when user privacy is requested with Privacy:session.
隐私服务必须匿名化o行中的用户名和IP地址，方法是将用户名设置为“-”，并将IP地址替换为一个值，以便在使用privacy:session请求用户隐私时，IP地址具有足够的唯一性。
These lines may contain information about the user.
这些行可能包含有关用户的信息。
A user agent executing a session-level privacy function on its own should not include user's information in the i, u, e, and p lines.
单独执行会话级隐私功能的用户代理不应在i、u、e和p行中包含用户信息。
A privacy service should modify the i, u, e, and p lines to delete the user's identity information when user privacy is requested with Privacy:session.
隐私服务应修改i、u、e和p行，以便在使用隐私：会话请求用户隐私时删除用户的身份信息。
The Identity [RFC4474] header field contains a signature used for validating the identity. The Identity-Info header field contains a reference to the certificate of the signer of Identity headers. An Identity-Info header may reveal information about the administrative domain of the user.
Identity[RFC4474]标头字段包含用于验证身份的签名。标识信息标头字段包含对标识标头签名者证书的引用。身份信息报头可揭示关于用户的管理域的信息。
The signature in an Identity header provides integrity protection over the From, To, Call-ID, Cseq, Date, and Contact headers and over the message body. The integrity protection is violated if a privacy service modifies these headers and/or the message body for the purpose of user privacy protection.
标识标头中的签名通过发件人、收件人、呼叫ID、Cseq、日期和联系人标头以及消息正文提供完整性保护。如果隐私服务为了保护用户隐私而修改这些头和/或消息正文，则违反完整性保护。
Once those integrity-protected headers (such as From and Call-ID) are modified, the Identity/Identity-Info header fields are not valid any more. Thus, a privacy service acting on a request for Privacy:user, Privacy:header, or Privacy:session can invalidate integrity protection provided by an upstream authentication service that has inserted Identity/Identity-Info header fields. The use of such a privacy service should be avoided if integrity protect needs to be
一旦修改了受完整性保护的头（例如From和Call ID），Identity/Identity Info头字段将不再有效。因此，对隐私：用户、隐私：头或隐私：会话的请求进行操作的隐私服务可以使上游身份验证服务提供的完整性保护失效，上游身份验证服务已插入身份/身份信息头字段。如果需要保护完整性，则应避免使用此类隐私服务
retained. Otherwise, if the privacy service invalidates the integrity protection, it should remove the Identity/Identity-Info header fields.
保留。否则，如果隐私服务使完整性保护无效，则应删除标识/标识信息标题字段。
An authentication service downstream of the privacy service may add Identity/Identity-Info header fields if the domain name of the From header field URI has not been anonymized (e.g., 'sip:anonymous@example.com'), which makes it possible for the service to authenticate the UAC. This authenticated yet anonymous From header means "this is a known user in my domain that I have authenticated, but I am keeping its identity private" as indicated in Section 12 in RFC 4474.
如果From报头字段URI的域名未被匿名化（例如，“sip:anonymous@example.com”），这使服务能够对UAC进行身份验证。如RFC 4474第12节所述，此已验证但匿名的标头表示“这是我已验证的域中的已知用户，但我将其身份保持为私有”。
The desired deployment will have a privacy service located before or co-located with the identity service; thus, integrity and privacy can both be provided seamlessly.
所需部署将具有位于身份服务之前或与身份服务共存的隐私服务；因此，可以无缝地提供完整性和隐私。
This field may contain information about the administrative domain and/or the visited domain of the user agent. However, the Path header is not the target of any priv-values.
此字段可能包含有关用户代理的管理域和/或访问域的信息。但是，路径头不是任何priv值的目标。
Given that the Path header [RFC3327] only appears in REGISTER requests/responses and is essential for a call to reach the registered UA in the visited domain, it serves no purpose to withhold or hide the information contained in the Path header; rather, it is harmful.
鉴于路径头[RFC3327]仅出现在注册请求/响应中，并且对于呼叫到达访问域中的注册UA至关重要，因此保留或隐藏路径头中包含的信息没有任何用途；相反，它是有害的。
The only reason privacy may be considered desirable is if the visited domain wants to withhold its topology from the home domain of the user. In doing so, the domain withholding the topology needs to ensure that it provides sufficient information so that the home domain can route the call to the visited domain, thus reaching the UA.
隐私被认为是可取的唯一原因是，如果访问的域想要从用户的主域保留其拓扑结构。在这样做时，保留拓扑的域需要确保它提供足够的信息，以便归属域可以将呼叫路由到访问域，从而到达UA。
However, anonymization of network-privacy-sensitive information is out of scope.
然而，网络隐私敏感信息的匿名化已超出范围。
The Replaces [RFC3891] header and the "replaces" parameter contain identifiers of a dialog to be replaced, which are composed of Call-ID, local tag, and remote tag.
Replaces[RFC3891]头和“Replaces”参数包含要替换的对话框的标识符，这些标识符由调用ID、本地标记和远程标记组成。
The sender of the INVITE with a Replaces header is usually not the originating user agent or terminating user agent of the target dialog to be replaced. Therefore, the Call-ID within the Replaces header is unlikely to be generated by the sender, and thus this header is outside the anonymization target per priv-value.
带有Replaces标头的INVITE的发件人通常不是要替换的目标对话框的原始用户代理或终止用户代理。因此，发送方不太可能生成Replaces报头中的调用ID，因此该报头超出了每个priv值的匿名化目标。
The "replaces" parameter, which appears in a Refer-To header in a REFER request, is not the target of any particular priv-values either. As described in Section 5.1.1 (Call-ID), regardless of the priv-value or the presence of a Privacy header, once a privacy service modifies a Call-ID in the request, it should monitor headers that may contain Call-ID and restore the portion of the value representing the modified Call-ID to the original Call-ID value in a Replaces header received.
“replaces”参数出现在Refer请求的Refer-Refer标头中，它也不是任何特定priv值的目标。如第5.1.1节（呼叫ID）所述，无论priv值或是否存在隐私标头，一旦隐私服务修改请求中的呼叫ID，它应监控可能包含呼叫ID的标头，并将代表修改的呼叫ID的值部分恢复为接收到的标头中的原始呼叫ID值。
The main challenge for this to function properly is that a privacy service has to be on a signaling path to the originator for every dialog. This is generally not possible and results in REFER requests not functioning at all times. This is a trade-off that is anticipated when privacy is imposed.
这一功能正常运行的主要挑战是，隐私服务必须位于每个对话的发端人的信令路径上。这通常是不可能的，并且会导致REFER请求始终无法运行。这是在实施隐私权时预期的一种权衡。
The privacy requirements mentioned in Section 5.1.1 will cause the Replaces header and "replaces" parameter to contain values that will fail the resulting dialog establishment in some situations. This loss of functionality is allowed and/or intended as illustrated above (i.e., it is not the responsibility of a privacy service to ensure that these features always work).
第5.1.1节中提到的隐私要求将导致Replaces标头和“Replaces”参数包含的值在某些情况下会导致对话框建立失败。如上文所述，允许和/或打算进行这种功能丧失（即，隐私服务不负责确保这些功能始终有效）。
The functionality of the Replaces header/parameter when anonymized depends on the circumstances in which it is used. REFER may work or may not work depending on the following three criteria.
匿名化时替换标头/参数的功能取决于使用它的环境。根据以下三个标准，参考可能有效，也可能无效。
1. Who generated the Call-ID. 2. Where the privacy service is on the signaling path. 3. Who initiates the REFER with the "replaces" parameter.
1. 谁生成了呼叫ID。2。其中隐私服务位于信令路径上。3.谁使用“替换”参数启动引用。
A few examples that explore when the Replaces header/parameter works or fails are given below.
下面给出了几个示例，探讨了Replaces header/参数何时工作或失败。
Example 1:
Transfer initiated by the originator, PS added for first INV and REF
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS >
REF(Refer-To:Bob?Replaces=C2) > Carol
Carol > INV(Replaces:C2) > Bob (SUCCEED)
Example 1:
Transfer initiated by the originator, PS added for first INV and REF
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS >
REF(Refer-To:Bob?Replaces=C2) > Carol
Carol > INV(Replaces:C2) > Bob (SUCCEED)
Example 2:
Transfer initiated by the originator, PS added only for first INV
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1) > Carol
Carol > INV(Replaces:C1) > Bob (FAIL)
Example 2:
Transfer initiated by the originator, PS added only for first INV
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1) > Carol
Carol > INV(Replaces:C1) > Bob (FAIL)
Note: Example 2 would succeed if the same PS (that modifies the Call-ID in the INVITE from Alice) is also added for REFER and modifies the value in the "replaces" parameter from C1 to C2 even if there is no Privacy header in the REFER.
注意：如果同样的PS（修改来自Alice的邀请中的呼叫ID）也被添加到REFER中，并且将“replaces”参数中的值从C1修改为C2，则示例2将成功，即使REFER中没有隐私标头。
Example 3:
Transfer initiated by the originator, PS added only for REF
Alice > INV(Call-ID:C1) > INV(Call-ID:C1) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS >
REF(Refer-To:Bob?Replaces=C1) > Carol
Carol > INV(Replaces:C1, Privacy:user) > PS' >
INV(Replaces:C1) > Bob (SUCCEED)
Example 3:
Transfer initiated by the originator, PS added only for REF
Alice > INV(Call-ID:C1) > INV(Call-ID:C1) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS >
REF(Refer-To:Bob?Replaces=C1) > Carol
Carol > INV(Replaces:C1, Privacy:user) > PS' >
INV(Replaces:C1) > Bob (SUCCEED)
Example 4:
Transfer initiated by the terminating party, PS added for both INV
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Bob > REF(Refer-To:Alice?Replaces=C2) > Carol
Carol > INV(Replaces:C2) > PS > INV(Replaces:C1) > Alice (SUCCEED)
Example 4:
Transfer initiated by the terminating party, PS added for both INV
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Bob > REF(Refer-To:Alice?Replaces=C2) > Carol
Carol > INV(Replaces:C2) > PS > INV(Replaces:C1) > Alice (SUCCEED)
Note: Example 4 succeeds because the same PS (that modifies the Call-ID in the INVITE from Alice) checks the incoming requests and modifies the value in a Replaces header in the INVITE from Carol to the former value of Call-ID (C1).
注意：示例4成功，因为相同的PS（修改Alice邀请中的呼叫ID）检查传入请求，并将Carol邀请中的Replaces头中的值修改为呼叫ID（C1）的前一个值。
Example 5:
Hold, PS added only for first INV
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1) > Music-Server
Music-Server > INV(Replaces:C1) > Bob (FAIL)
Example 5:
Hold, PS added only for first INV
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1) > Music-Server
Music-Server > INV(Replaces:C1) > Bob (FAIL)
Note: Example 5 would succeed if the same PS (that modifies the Call-ID in the INVITE from Alice) is added for the INVITE from the Music-Server and modifies the value in a Replaces header from C1 to C2.
注意：如果为来自音乐服务器的邀请添加相同的PS（修改Alice邀请中的呼叫ID），并将替换头中的值从C1修改为C2，则示例5将成功。
As the above examples show, in some scenarios, information carried in the Replaces header/parameter would result in failure of the REFER. This will not happen if the Call-ID is not modified at a privacy service.
如上示例所示，在某些情况下，Replaces头/参数中包含的信息会导致reference失败。如果在隐私服务中未修改呼叫ID，则不会发生这种情况。
This field may contain information about the administrative domain of the user agent, but the Route header is not the target of any priv-values.
此字段可能包含有关用户代理的管理域的信息，但路由头不是任何priv值的目标。
Route headers appear only in SIP requests to force routing through the listed set of proxies. If a privacy service anonymizes the Route header, the routing does not function. Furthermore, there is no risk in revealing the information in the Route headers to further network entities, including the terminating user agent, because a proxy removes the value from the Route header when it replaces the value in the Request-URI as defined in RFC 3261.
路由头仅出现在SIP请求中，以强制路由通过列出的代理集。如果隐私服务使路由头匿名，则路由不起作用。此外，将路由报头中的信息透露给其他网络实体（包括终端用户代理）没有风险，因为代理在替换RFC 3261中定义的请求URI中的值时从路由报头中移除该值。
A privacy service that modifies Record-Route headers may need to restore the values in Route headers as necessary. As indicated in Section 5.1 in RFC 3323, if a privacy service modifies the Record-Route headers, it MUST be able to restore Route headers with retained values. Please refer to Section 5.1.9 (Record-Route) for further detail and examples.
修改记录路由头的隐私服务可能需要根据需要恢复路由头中的值。如RFC 3323第5.1节所述，如果隐私服务修改记录路由头，它必须能够使用保留值还原路由头。请参考第5.1.9节（记录路线），了解更多详细信息和示例。
Service-Route headers [RFC3608] appear only in 200 OK responses to REGISTER requests and contain information about the registrar. The purpose of the privacy mechanism defined in RFC 3323 is to secure the user's privacy, so the case where a registrar sets a Privacy header is not considered here. Therefore, the Service-Route header is not the target of any priv-values.
服务路由头[RFC3608]仅出现在注册请求的200个OK响应中，并包含有关注册器的信息。RFC 3323中定义的隐私机制的目的是保护用户的隐私，因此这里不考虑注册者设置隐私报头的情况。因此，服务路由头不是任何priv值的目标。
The Target-Dialog [RFC4538] header faces exactly the same issues as seen for the Replaces header. Please refer to Section 5.3.3 (Replaces Header/Parameter) for why this is not a target for any particular priv-values and how a privacy service still needs to evaluate and modify the value contained, even if no privacy is requested.
目标对话框[RFC4538]标题面临与替换标题完全相同的问题。请参考第5.3.3节（替换标题/参数），了解为什么这不是任何特定priv值的目标，以及隐私服务如何仍然需要评估和修改包含的值，即使不要求隐私。
This guideline document adds no new security considerations to those discussed in [RFC3323], [RFC3325], and [RFC4244].
本指南文件未在[RFC3323]、[RFC3325]和[RFC4244]中讨论的安全注意事项中添加新的安全注意事项。
The authors would like to thank John Elwell, Jon Peterson, Jonathan Rosenberg, Mary Barnes, Paul Kyzivat, and Roland Jesske for their reviews and comments.
作者要感谢John Elwell、Jon Peterson、Jonathan Rosenberg、Mary Barnes、Paul Kyzivat和Roland Jeske的评论和评论。
[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月。
[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月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244]Barnes，M.，Ed.，“请求历史信息会话启动协议（SIP）的扩展”，RFC 4244，2005年11月。
[TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Work in Progress, July 2008.
[TURN]Rosenberg，J.，Mahy，R.，和P.Matthews，“使用NAT周围的中继进行遍历（TURN）：NAT会话遍历实用程序的中继扩展（STUN）”，正在进行的工作，2008年7月。
[SIPGRUU] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[SIPGRUU]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，2009年10月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3327]Willis，D.和B.Hoeneisen，“用于注册非相邻联系人的会话启动协议（SIP）扩展头字段”，RFC 3327，2002年12月。
[RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003.
[RFC3608]Willis，D.和B.Hoeneisen，“注册期间服务路由发现的会话启动协议（SIP）扩展头字段”，RFC 3608，2003年10月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891]Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 38912004年9月的“头”。
[RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[RFC3892]Sparks，R.，“机制引用的会话启动协议（SIP）”，RFC 38922004年9月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[RFC4538]Rosenberg，J.，“通过会话启动协议（SIP）中的对话标识请求授权”，RFC 4538，2006年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
Authors' Addresses
作者地址
Mayumi Munakata NTT Corporation
日本新界东道明明株式会社
Phone: +81 422 36 7502
EMail: munakata.mayumi@lab.ntt.co.jp
Phone: +81 422 36 7502
EMail: munakata.mayumi@lab.ntt.co.jp
Shida Schubert NTT Corporation
Shida舒伯特NTT公司
EMail: shida@ntt-at.com
EMail: shida@ntt-at.com
Takumi Ohba NTT Corporation 9-11, Midori-cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan
Takumi Ohba NTT Corporation 9-11，Midori cho 3-Chome Musashino shi，东京180-8585
Phone: +81 422 59 7748
EMail: ohba.takumi@lab.ntt.co.jp
Phone: +81 422 59 7748
EMail: ohba.takumi@lab.ntt.co.jp