Internet Engineering Task Force (IETF) M. Munakata
Request for Comments: 5767 S. Schubert
Category: Informational T. Ohba
ISSN: 2070-1721 NTT
April 2010
Internet Engineering Task Force (IETF) M. Munakata
Request for Comments: 5767 S. Schubert
Category: Informational T. Ohba
ISSN: 2070-1721 NTT
April 2010
User-Agent-Driven Privacy Mechanism for SIP
用户代理驱动的SIP隐私机制
Abstract
摘要
This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUUs) and Traversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323.
本文档为用户代理（UA）定义了一个指南，该指南通过利用诸如全局可路由用户代理URI（GROUS）和使用NAT（TURN）周围的中继进行遍历等机制来生成匿名会话发起协议（SIP）消息，而无需RFC 3323中定义的隐私服务。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5767.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5767.
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Concept of Privacy ..............................................3
4. Treatment of Privacy-Sensitive Information ......................3
4.1. Obtaining a Functional Anonymous URI Using the GRUU
Mechanism ..................................................4
4.2. Obtaining a Functional Anonymous IP Address Using
the TURN Mechanism .........................................5
5. UA Behavior .....................................................6
5.1. Critical Privacy-Sensitive Information .....................6
5.1.1. Contact Header Field ................................6
5.1.2. From Header Field in Requests .......................7
5.1.3. Via Header Field in Requests ........................8
5.1.4. IP Addresses in SDP .................................8
5.2. Non-Critical Privacy-Sensitive Information .................8
5.2.1. Host Names in Other SIP Header Fields ...............8
5.2.2. Optional SIP Header Fields ..........................9
6. Security Considerations .........................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References ....................................10
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Concept of Privacy ..............................................3
4. Treatment of Privacy-Sensitive Information ......................3
4.1. Obtaining a Functional Anonymous URI Using the GRUU
Mechanism ..................................................4
4.2. Obtaining a Functional Anonymous IP Address Using
the TURN Mechanism .........................................5
5. UA Behavior .....................................................6
5.1. Critical Privacy-Sensitive Information .....................6
5.1.1. Contact Header Field ................................6
5.1.2. From Header Field in Requests .......................7
5.1.3. Via Header Field in Requests ........................8
5.1.4. IP Addresses in SDP .................................8
5.2. Non-Critical Privacy-Sensitive Information .................8
5.2.1. Host Names in Other SIP Header Fields ...............8
5.2.2. Optional SIP Header Fields ..........................9
6. Security Considerations .........................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References ....................................10
[RFC3323] defines a privacy mechanism for the Session Initiation Protocol (SIP) [RFC3261], based on techniques available at the time of its publication. This mechanism relies on the use of a separate privacy service to remove privacy-sensitive information from SIP messages sent by a User Agent (UA) before forwarding those messages to the final destination. Since then, numerous SIP extensions have been proposed and standardized. Some of those enable a UA to withhold its user's identity and related information without the need for privacy services, which was not possible when RFC 3323 was defined.
[RFC3323]基于发布时可用的技术，定义会话启动协议（SIP）[RFC3261]的隐私机制。该机制依赖于使用单独的隐私服务来从用户代理（UA）发送的SIP消息中删除隐私敏感信息，然后再将这些消息转发到最终目的地。从那时起，许多SIP扩展被提出并标准化。其中一些允许UA在不需要隐私服务的情况下保留其用户身份和相关信息，这在定义RFC 3323时是不可能的。
The purpose of this document is not to obsolete RFC 3323, but to enhance the overall privacy mechanism in SIP by allowing a UA to take control of its privacy, rather than being completely dependent on an external privacy service.
本文档的目的不是要淘汰RFC 3323，而是通过允许UA控制其隐私，而不是完全依赖外部隐私服务来增强SIP中的整体隐私机制。
The UA-driven privacy mechanism defined in this document will not eliminate the need for the RFC 3323 usage defined in [RFC3325], which instructs a privacy service not to forward a P-Asserted-Identity header field outside the Trust Domain. In order to prevent forwarding a P-Asserted-Identity header field outside the Trust Domain, a UA needs to include the Privacy header field with value
本文档中定义的UA驱动隐私机制不会消除[RFC3325]中定义的RFC 3323使用的需要，该使用指示隐私服务不在信任域之外转发P-Asserted-Identity标头字段。为了防止在信任域之外转发P-Asserted-Identity报头字段，UA需要包含具有值的隐私报头字段
'id' (Privacy:id) in the request, even when the UA is utilizing this specification.
请求中的“id”（隐私：id），即使UA正在使用此规范。
This document defines a guideline in which a UA controls all the privacy functions on its own utilizing SIP extensions such as Globally Routable User Agent URIs (GRUUs) [RFC5627] and Traversal Using Relays around NAT (TURN) [RFC5766].
本文档定义了一个指南，其中UA利用SIP扩展（如全局可路由用户代理URI（GROUS）[RFC5627]和使用NAT（TURN）[RFC5766]周围的中继进行遍历）自行控制所有隐私功能。
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]中所述进行解释。
privacy-sensitive information: The information that identifies a user who sends the SIP message, as well as other information that can be used to guess the user's identity.
隐私敏感信息：标识发送SIP消息的用户的信息，以及可用于猜测用户身份的其他信息。
The concept of privacy in this document is the act of concealing privacy-sensitive information. The protection of network privacy (e.g., topology hiding) is outside the scope of this document. Privacy-sensitive information includes display-name and Uniform Resource Identifier (URI) in a From header field that can reveal the user's name and affiliation (e.g., company name), and IP addresses or host names in a Contact header field, a Via header field, a Call-ID header field, or a Session Description Protocol (SDP) [RFC4566] body that might reveal the location of a UA.
本文件中的隐私概念是隐藏隐私敏感信息的行为。网络隐私保护（如拓扑隐藏）不在本文件范围内。隐私敏感信息包括From标头字段中的显示名称和统一资源标识符（URI），该字段可显示联系人标头字段、Via标头字段、呼叫ID标头字段或会话描述协议（SDP）中的用户名和从属关系（例如，公司名），以及IP地址或主机名。[RFC4566]可能显示UA位置的尸体。
Some fields of a SIP message potentially contain privacy-sensitive information but are not essential for achieving the intended purpose of the message and can be omitted without any side effects. Other fields are essential for achieving the intended purpose of the message and need to contain anonymized values in order to avoid disclosing privacy-sensitive information. Of the privacy-sensitive information listed in Section 3, URIs, host names, and IP addresses in Contact, Via, and SDP are required to be functional (i.e., suitable for purpose) even when they are anonymized.
SIP消息的某些字段可能包含隐私敏感信息，但对于实现消息的预期目的不是必需的，可以省略，而不会产生任何副作用。其他字段对于实现消息的预期目的至关重要，并且需要包含匿名值，以避免泄露隐私敏感信息。在第3节中列出的隐私敏感信息中，联系人、Via和SDP中的URI、主机名和IP地址要求是功能性的（即适用于目的），即使是匿名的。
With the use of GRUU [RFC5627] and TURN [RFC5766], a UA can obtain URIs and IP addresses for media and signaling that are functional yet anonymous, and do not identify either the UA or the user.
通过使用GRUU[RFC5627]和TURN[RFC5766]，UA可以获得功能正常但匿名的媒体和信令的URI和IP地址，并且不识别UA或用户。
Instructions on how to obtain a functional anonymous URI and IP address are given in Section 4.1 and 4.2, respectively.
第4.1节和第4.2节分别给出了有关如何获取功能性匿名URI和IP地址的说明。
Host names need to be concealed because the user's identity can be guessed from them, but they are not always regarded as critical privacy-sensitive information.
主机名需要隐藏，因为可以从中猜出用户的身份，但它们并不总是被视为关键的隐私敏感信息。
In addition, a UA needs to be careful not to include any information that identifies the user in optional SIP header fields such as Subject and User-Agent.
此外，UA需要小心，不要在可选的SIP头字段（如Subject和user Agent）中包含任何标识用户的信息。
A UA wanting to obtain a functional anonymous URI MUST support and utilize the GRUU mechanism unless it is able to obtain a functional anonymous URI through other means outside the scope for this document. By sending a REGISTER request requesting GRUU, the UA can obtain an anonymous URI, which can later be used for the Contact header field.
想要获得功能性匿名URI的UA必须支持并利用GRUU机制，除非它能够通过本文档范围之外的其他方式获得功能性匿名URI。通过发送请求GRUU的注册请求，UA可以获得一个匿名URI，该URI稍后可用于Contact header字段。
The detailed process on how a UA obtains a GRUU is described in [RFC5627].
[RFC5627]中描述了UA如何获得GRUU的详细过程。
In order to use the GRUU mechanism to obtain a functional anonymous URI, the UA MUST request GRUU in the REGISTER request. If a "temp-gruu" SIP URI parameter and value are present in the REGISTER response, the user agent MUST use the value of the "temp-gruu" as an anonymous URI representing the UA. This means that the UA MUST use this URI as its local target and that the UA MUST place this URI in the Contact header field of subsequent requests and responses that require the local target to be sent.
为了使用GRUU机制获得功能性匿名URI，UA必须在REGISTER请求中请求GRUU。如果寄存器响应中存在“temp gru”SIP URI参数和值，则用户代理必须使用“temp gru”的值作为表示UA的匿名URI。这意味着UA必须将此URI用作其本地目标，并且UA必须将此URI放在需要发送本地目标的后续请求和响应的联系人标头字段中。
If there is no "temp-gruu" SIP URI parameter in the 200 (OK) response to the REGISTER request, a UA SHOULD NOT proceed with its anonymization process, unless something equivalent to "temp-gruu" is provided through some administrative means.
如果在对注册请求的200（OK）响应中没有“temp gru”SIP URI参数，则UA不应继续其匿名化过程，除非通过某些管理手段提供与“temp gru”等效的内容。
It is RECOMMENDED that the UA consult the user before sending a request without a functional anonymous URI when privacy is requested from the user.
当用户请求隐私时，建议UA在发送不带功能性匿名URI的请求之前咨询用户。
Due to the nature of how GRUU works, the domain name is always revealed when GRUU is used. If revealing the domain name in the Contact header field is a concern, use of a third-party GRUU server is a possible solution, but this is outside the scope of this document. Refer to the Security Considerations section for details.
由于GRUU工作方式的性质，在使用GRUU时总是会显示域名。如果在Contact header字段中显示域名是一个问题，那么使用第三方GRUU服务器是一个可能的解决方案，但这超出了本文档的范围。有关详细信息，请参阅安全注意事项部分。
4.2. Obtaining a Functional Anonymous IP Address Using the TURN Mechanism
4.2. 使用TURN机制获取功能性匿名IP地址
A UA that is not provided with a functional anonymous IP address through some administrative means MUST obtain a relayed address (IP address of a relay) if anonymity is desired for use in SDP and in the Via header field. Such an IP address is to be derived from a Session Traversal Utilities of NAT (STUN) relay server through the TURN mechanism, which allows a STUN server to act as a relay.
如果在SDP和Via报头字段中需要匿名性，则未通过某些管理手段提供功能匿名IP地址的UA必须获得中继地址（中继的IP地址）。这样的IP地址将通过TURN机制从NAT（STUN）中继服务器的会话遍历实用程序派生，该机制允许STUN服务器充当中继。
Anonymous IP addresses are needed for two purposes. The first is for use in the Via header field of a SIP request. By obtaining an IP address from a STUN relay server, using that address in the Via header field of the SIP request, and sending the SIP request to the STUN relay server, the IP address of the UA will not be revealed beyond the relay server.
匿名IP地址有两个用途。第一个用于SIP请求的Via头字段。通过从STUN中继服务器获取IP地址，在SIP请求的Via报头字段中使用该地址，并将SIP请求发送到STUN中继服务器，UA的IP地址将不会显示在中继服务器之外。
The second is for use in SDP as an address for receiving media. By obtaining an IP address from a STUN relay server and using that address in SDP, media will be received via the relay server. Also, media can be sent via the relay server. In this way, neither SDP nor media packets reveal the IP address of the UA.
第二个在SDP中用作接收媒体的地址。通过从STUN中继服务器获取IP地址并在SDP中使用该地址，将通过中继服务器接收媒体。此外，还可以通过中继服务器发送媒体。这样，SDP和媒体包都不会显示UA的IP地址。
It is assumed that a UA is either manually or automatically configured through means such as the configuration framework [SIPPING-CONFIG] with the address of one or more STUN (Session Traversal Utilities for NAT) [RFC5766] relay servers to obtain anonymous IP address.
假设UA通过配置框架[SIPPING-CONFIG]等方式手动或自动配置，地址为一个或多个STUN（NAT会话遍历实用程序）[RFC5766]中继服务器，以获得匿名IP地址。
This section describes how to generate an anonymous SIP message at a UA.
本节描述如何在UA上生成匿名SIP消息。
A UA fully compliant with this document MUST obscure or conceal all the critical UA-inserted privacy-sensitive information in SIP requests and responses as shown in Section 5.1 when user privacy is requested. In addition, the UA SHOULD conceal the non-critical privacy-sensitive information as shown in Section 5.2.
当请求用户隐私时，完全符合本文件要求的UA必须掩盖或隐藏SIP请求和响应中所有关键UA插入的隐私敏感信息，如第5.1节所示。此外，UA应隐藏第5.2节所示的非关键隐私敏感信息。
Furthermore, when a UA uses a relay server to conceal its identity, the UA MUST send requests to the relay server to ensure request and response follow the same signaling path.
此外，当UA使用中继服务器隐藏其身份时，UA必须向中继服务器发送请求，以确保请求和响应遵循相同的信令路径。
When using this header field in a dialog-forming request or response or in a mid-dialog request or response, this field contains the local target, i.e., a URI used to reach the UA for mid-dialog requests and possibly out-of-dialog requests, such as a REFER request [RFC3515]. The Contact header field can also contain a display-name. Since the Contact header field is used for routing further requests to the UA, the UA MUST include a functional URI even when it is anonymized.
当在对话框形成请求或响应中或在中间对话框请求或响应中使用此标头字段时，此字段包含本地目标，即用于到达UA的URI，用于中间对话框请求和可能的对话外请求，如REFER请求[RFC3515]。联系人标题字段还可以包含显示名称。由于Contact header字段用于将进一步的请求路由到UA，因此UA必须包括一个功能URI，即使它是匿名的。
When using this header field in a dialog-forming request or response or in a mid-dialog request or response, the UA MUST anonymize the Contact header field using an anonymous URI ("temp-gruu") obtained through the GRUU mechanism, unless an equivalent functional anonymous URI is provided by some other means. For other requests and responses, with the exception of 3xx responses, REGISTER requests and 200 (OK) responses to a REGISTER request, the UA MUST either omit the Contact header field or use an anonymous URI.
当在形成请求或响应的对话中或在中间对话请求或响应中使用此头字段时，UA必须使用通过gruu机制获得的匿名URI（“temp gruu”）来匿名化联系人头字段，除非通过某些其他方式提供等效的功能匿名URI。对于其他请求和响应，除了3xx响应、注册请求和注册请求的200（确定）响应外，UA必须省略联系人标头字段或使用匿名URI。
Refer to Section 4.1 for details on how to obtain an anonymous URI through GRUU.
有关如何通过GRUU获取匿名URI的详细信息，请参阅第4.1节。
The UA MUST omit the display-name in a Contact header field or set the display-name to "Anonymous".
UA必须省略联系人标题字段中的显示名称，或将显示名称设置为“匿名”。
Without privacy considerations, this field contains the identity of the user, such as display-name and URI.
在不考虑隐私的情况下，此字段包含用户的标识，例如显示名和URI。
RFCs 3261 and 3323 recommend setting "sip:anonymous@anonymous.invalid" as a SIP URI in a From header field when user privacy is requested. This raises an issue when the SIP-Identity mechanism [RFC4474] is applied to the message, because SIP-Identity requires an actual domain name in the From header field.
RFCs 3261和3323建议设置“sip:anonymous@anonymous.invalid“当请求用户隐私时，作为发件人标头字段中的SIP URI。当SIP标识机制[RFC4474]应用于消息时，这会引发一个问题，因为SIP标识在From头字段中需要实际的域名。
A UA generating an anonymous SIP message supporting this specification MUST anonymize the From header field in one of the two ways described below.
生成支持此规范的匿名SIP消息的UA必须采用以下两种方式之一对From头字段进行匿名化。
Option 1:
备选案文1：
A UA anonymizes a From header field using an anonymous display-name and an anonymous URI following the procedure noted in Section 4.1.1.3 of RFC 3323.
UA按照RFC 3323第4.1.1.3节所述的程序，使用匿名显示名称和匿名URI来匿名From标头字段。
The example form of the From header field of option 1 is as follows:
选项1的From标头字段的示例形式如下：
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
Option 2:
备选案文2：
A UA anonymizes a From header field using an anonymous display-name and an anonymous URI with user's valid domain name instead of "anonymous.invalid".
UA使用匿名显示名和带有用户有效域名的匿名URI（而不是“anonymous.invalid”）来匿名From标头字段。
The example form of the From header field of option 2 is as follows:
选项2的From标头字段的示例形式如下：
From: "Anonymous" <sip:anonymous@example.com>;tag=1928301774
From: "Anonymous" <sip:anonymous@example.com>;tag=1928301774
A UA SHOULD go with option 1 to conceal its domain name in the From header field. However, SIP-Identity cannot be used with a From header field in accordance with option 1, because the SIP-Identity mechanism uses authentication based on the domain name.
UA应使用选项1在From标头字段中隐藏其域名。但是，根据选项1，SIP标识不能与From头字段一起使用，因为SIP标识机制使用基于域名的身份验证。
If a UA expects the SIP-Identity mechanism to be applied to the request, it is RECOMMENDED to go with option 2. However, the user's domain name will be revealed from the From header field of option 2.
如果UA希望SIP标识机制应用于请求，建议使用选项2。但是，用户的域名将从选项2的“发件人”标题字段中显示。
If the user wants both anonymity and strong identity, a solution would be to use a third-party anonymization service that issues an Address of Record (AoR) for use in the From header field of a request and that also provides a SIP-Identity Authentication Service. Third-party anonymization service is out of scope for this document.
如果用户想要匿名性和强身份，一个解决方案是使用第三方匿名化服务，该服务发布记录地址（AoR）以用于请求的From报头字段，并且还提供SIP身份验证服务。第三方匿名服务不在此文档范围内。
Without privacy considerations, the bottommost Via header field added to a request by a UA contains the IP address and port or hostname that are used to reach the UA for responses.
在不考虑隐私的情况下，UA添加到请求中的最底部Via header字段包含用于到达UA进行响应的IP地址和端口或主机名。
A UA generating an anonymous SIP request supporting this specification MUST anonymize the IP address in the Via header field using an anonymous IP address obtained through the TURN mechanism, unless an equivalent functional anonymous IP address is provided by some other means.
生成支持本规范的匿名SIP请求的UA必须使用通过TURN机制获得的匿名IP地址匿名化Via报头字段中的IP地址，除非通过其他方式提供等效的功能匿名IP地址。
The UA SHOULD NOT include a host name in a Via header field.
UA不应在Via标头字段中包含主机名。
A UA generating an anonymous SIP message supporting this specification MUST anonymize IP addresses in SDP, if present, using an anonymous IP address obtained through the TURN mechanism, unless an equivalent functional anonymous IP address is provided by some other means.
生成支持本规范的匿名SIP消息的UA必须使用通过TURN机制获得的匿名IP地址对SDP中的IP地址（如果存在）进行匿名化，除非通过其他方式提供等效的功能匿名IP地址。
Refer to Section 4.2 for details on how to obtain an IP address through TURN.
有关如何通过TURN获得IP地址的详细信息，请参阅第4.2节。
A UA generating an anonymous SIP message supporting this specification SHOULD conceal host names in any SIP header fields, such as Call-ID and Warning header fields, if considered privacy-sensitive.
生成支持此规范的匿名SIP消息的UA应在任何SIP头字段（如Call ID和Warning header字段）中隐藏主机名（如果认为对隐私敏感）。
Other optional SIP header fields (such as Call-Info, In-Reply-To, Organization, Referred-By, Reply-To, Server, Subject, User-Agent, and Warning) can contain privacy-sensitive information.
其他可选的SIP头字段（如呼叫信息、回复、组织、引用人、回复、服务器、主题、用户代理和警告）可以包含隐私敏感信息。
A UA generating an anonymous SIP message supporting this specification SHOULD NOT include any information that identifies the user in such optional header fields.
生成支持此规范的匿名SIP消息的UA不应在此类可选标头字段中包含任何标识用户的信息。
This specification uses GRUU and TURN and inherits any security considerations described in these documents.
本规范使用GRUU和TURN，并继承这些文档中描述的任何安全注意事项。
Furthermore, if the provider of the caller intending to obscure its identity consists of a small number of people (e.g., small enterprise, Small Office, Home Office (SOHO)), the domain name alone can reveal the identity of the caller.
此外，如果有意掩盖其身份的呼叫者的提供者由少数人组成（例如，小型企业、小型办公室、家庭办公室（SOHO）），则仅域名就可以揭示呼叫者的身份。
The same can be true when the provider is large but the receiver of the call only knows a few people from the source of call.
当提供者很大时，情况也是如此，但是呼叫的接收者只知道来自呼叫源的几个人。
There are mainly two places in the message, the From header field and Contact header field, where the domain name is expected to be functional.
消息中主要有两个位置，发件人标头字段和联系人标头字段，在这两个位置，域名将起作用。
The domain name in the From header field can be obscured as described in Section 5.1.2, whereas the Contact header field needs to contain a valid domain name at all times in order to function properly.
如第5.1.2节所述，“发件人”标题字段中的域名可能会模糊，而“联系人”标题字段需要始终包含有效的域名才能正常工作。
Note: Generally, a device will not show the contact address to the receiver, but this does not mean that one cannot find the domain name in a message. In fact, as long as this specification is used to obscure identity, the message will always contain a valid domain name as it inherits key characteristics of GRUU.
注意：一般来说，设备不会向接收者显示联系人地址，但这并不意味着无法在消息中找到域名。事实上，只要该规范用于隐藏身份，消息将始终包含有效的域名，因为它继承了GRUU的关键特征。
Note: For UAs that use a temporary GRUU, confidentiality does not extend to parties that are permitted to register to the same AoR or are permitted to obtain temporary GRUUs when subscribed to the 'reg' event package [RFC3680] for the AoR. To limit this, it is suggested that the authorization policy for the 'reg' event package permit only those subscribers authorized to register to the AoR to receive temporary GRUUs. With this policy, the confidentiality of the temporary GRUU will be the same whether or not the 'reg' event package is used.
注：对于使用临时GROU的UAs，保密性不适用于允许注册到同一AoR或允许在订阅AoR的“reg”事件包[RFC3680]时获得临时GROU的各方。为了限制这一点，建议“reg”事件包的授权策略只允许授权注册到AoR的订阅者接收临时GRU。根据此策略，无论是否使用“reg”事件包，临时GRUU的机密性都是相同的。
If one wants to assure anonymization, it is suggested that the user seek and rely on a third-party anonymization service, which is outside the scope of this document.
如果希望确保匿名，建议用户寻求并依赖第三方匿名服务，这不在本文档的范围内。
A third-party anonymization service provides registrar and TURN service that have no affiliation with the caller's provider, allowing caller to completely withhold its identity.
第三方匿名服务提供与呼叫者提供商无关的注册和转机服务，允许呼叫者完全保留其身份。
[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月。
[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月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，2009年10月。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，2010年4月。
[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月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[RFC3680]Rosenberg，J.，“用于注册的会话启动协议（SIP）事件包”，RFC3680，2004年3月。
[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月。
[SIPPING-CONFIG] Channabasappa, S., "A Framework for Session Initiation Protocol User Agent Profile Delivery", Work in Progress, September 2009.
[SIPING-CONFIG]Channabasappa，S.，“会话启动协议用户代理配置文件交付框架”，正在进行的工作，2009年9月。
Authors' Addresses
作者地址
Mayumi Munakata NTT Corporation
日本新界东道明明株式会社
EMail: munakata.mayumi@lab.ntt.co.jp
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
URI: http://www.ntt.co.jp
Phone: +81 422 59 7748
EMail: ohba.takumi@lab.ntt.co.jp
URI: http://www.ntt.co.jp