Network Working Group J. Rosenberg
Request for Comments: 5627 Cisco Systems
Category: Standards Track October 2009
Network Working Group J. Rosenberg
Request for Comments: 5627 Cisco Systems
Category: Standards Track October 2009
Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)
在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUU）
Abstract
摘要
Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog.
会话发起协议（SIP）的几个应用程序要求用户代理（UA）构造和分发URI，Internet上的任何人都可以使用该URI将呼叫路由到该特定UA实例。路由到特定UA实例的URI称为全局可路由UA URI（GRUU）。本文档描述了SIP的一个扩展，用于从注册器获取GRUU，并在对话中与对等方通信GRUU。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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 BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。未获得控制此类材料版权的人员的充分许可，不得修改本文件
outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
在IETF标准过程之外，不得在IETF标准过程之外创建其衍生作品，除非将其格式化为RFC出版或将其翻译为英语以外的语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
3.1. Structure of GRUUs . . . . . . . . . . . . . . . . . . . . 5
3.1.1. GRUUs That Expose the Underlying AOR . . . . . . . . . 6
3.1.2. GRUUs That Hide the Underlying AOR . . . . . . . . . . 6
3.2. Obtaining a GRUU . . . . . . . . . . . . . . . . . . . . . 7
3.3. Using a GRUU . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Dereferencing a GRUU . . . . . . . . . . . . . . . . . . . 8
4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 9
4.1. Generating a REGISTER Request . . . . . . . . . . . . . . 9
4.2. Learning GRUUs from REGISTER Responses . . . . . . . . . . 10
4.3. Constructing a Self-Made GRUU . . . . . . . . . . . . . . 11
4.4. Using One's Own GRUUs . . . . . . . . . . . . . . . . . . 12
4.4.1. Considerations for Multiple AORs . . . . . . . . . . . 13
4.5. Dereferencing a GRUU . . . . . . . . . . . . . . . . . . . 14
4.6. Rendering GRUUs on a User Interface . . . . . . . . . . . 14
5. Registrar Behavior . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Processing a REGISTER Request . . . . . . . . . . . . . . 14
5.2. Generating a REGISTER Response . . . . . . . . . . . . . . 16
5.3. Timing Out a Registration . . . . . . . . . . . . . . . . 16
5.4. Creation of a GRUU . . . . . . . . . . . . . . . . . . . . 17
5.5. Registration Event Support . . . . . . . . . . . . . . . . 19
6. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Request Targeting . . . . . . . . . . . . . . . . . . . . 19
6.2. Record-Routing . . . . . . . . . . . . . . . . . . . . . . 21
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10.1. Outside Attacks . . . . . . . . . . . . . . . . . . . . . 29
10.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . . . 30
10.3. Privacy Considerations . . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11.1. Header Field Parameter . . . . . . . . . . . . . . . . . . 33
11.2. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 33
11.3. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 33
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Example GRUU Construction Algorithms . . . . . . . . 37
A.1. Public GRUU . . . . . . . . . . . . . . . . . . . . . . . 37
A.2. Temporary GRUU . . . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Network Design Considerations . . . . . . . . . . . . 39
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
3.1. Structure of GRUUs . . . . . . . . . . . . . . . . . . . . 5
3.1.1. GRUUs That Expose the Underlying AOR . . . . . . . . . 6
3.1.2. GRUUs That Hide the Underlying AOR . . . . . . . . . . 6
3.2. Obtaining a GRUU . . . . . . . . . . . . . . . . . . . . . 7
3.3. Using a GRUU . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Dereferencing a GRUU . . . . . . . . . . . . . . . . . . . 8
4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 9
4.1. Generating a REGISTER Request . . . . . . . . . . . . . . 9
4.2. Learning GRUUs from REGISTER Responses . . . . . . . . . . 10
4.3. Constructing a Self-Made GRUU . . . . . . . . . . . . . . 11
4.4. Using One's Own GRUUs . . . . . . . . . . . . . . . . . . 12
4.4.1. Considerations for Multiple AORs . . . . . . . . . . . 13
4.5. Dereferencing a GRUU . . . . . . . . . . . . . . . . . . . 14
4.6. Rendering GRUUs on a User Interface . . . . . . . . . . . 14
5. Registrar Behavior . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Processing a REGISTER Request . . . . . . . . . . . . . . 14
5.2. Generating a REGISTER Response . . . . . . . . . . . . . . 16
5.3. Timing Out a Registration . . . . . . . . . . . . . . . . 16
5.4. Creation of a GRUU . . . . . . . . . . . . . . . . . . . . 17
5.5. Registration Event Support . . . . . . . . . . . . . . . . 19
6. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Request Targeting . . . . . . . . . . . . . . . . . . . . 19
6.2. Record-Routing . . . . . . . . . . . . . . . . . . . . . . 21
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10.1. Outside Attacks . . . . . . . . . . . . . . . . . . . . . 29
10.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . . . 30
10.3. Privacy Considerations . . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11.1. Header Field Parameter . . . . . . . . . . . . . . . . . . 33
11.2. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 33
11.3. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 33
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Example GRUU Construction Algorithms . . . . . . . . 37
A.1. Public GRUU . . . . . . . . . . . . . . . . . . . . . . . 37
A.2. Temporary GRUU . . . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Network Design Considerations . . . . . . . . . . . . 39
In the Session Initiation Protocol (SIP), RFC 3261 [1], the basic unit of reference is the Address of Record (AOR). However, in SIP systems a single user can have a number of user agents (handsets, softphones, voicemail accounts, etc.) that are all referenced by the same AOR. There are a number of contexts in which it is desirable to have an identifier that addresses a single user agent rather than the group of user agents indicated by an AOR.
在会话启动协议（SIP）RFC3261[1]中，基本参考单位是记录地址（AOR）。然而，在SIP系统中，单个用户可以拥有多个用户代理（手机、软电话、语音信箱帐户等），这些代理都由同一AOR引用。在许多上下文中，希望具有针对单个用户代理而不是AOR指示的用户代理组的标识符。
As an example, consider a blind transfer application (see RFC 5589 [19]). User A is talking to user B. User A wants to transfer the call to user C. So, user A sends a REFER to user C. That REFER looks like, in part:
作为一个例子，考虑盲传输应用（参见RFC 5589〔19〕）。用户A正在与用户B通话。用户A希望将呼叫转接给用户C。因此，用户A向用户C发送了一个refere。该refere部分类似于：
REFER sip:C@example.com SIP/2.0
From: sip:A@example.com;tag=99asd
To: sip:C@example.com
Refer-To: (URI that identifies B's UA)
REFER sip:C@example.com SIP/2.0
From: sip:A@example.com;tag=99asd
To: sip:C@example.com
Refer-To: (URI that identifies B's UA)
The Refer-To header field needs to contain a URI that can be used by user C to place a call to user B. However, this call needs to route to the specific UA instance that user B is using to talk to user A. If it doesn't, the transfer service will not execute properly. For example, if A provides C with B's AOR, the call might be routed to B's voicemail rather than B's current handset.
refere-To-header字段需要包含一个URI，用户C可以使用该URI向用户B发出呼叫。但是，该呼叫需要路由到用户B用来与用户a通话的特定UA实例。如果没有，传输服务将无法正常执行。例如，如果A向C提供B的AOR，呼叫可能会被路由到B的语音信箱，而不是B当前的手机。
In order to enable this functionality, user B provides an instance-specific URI to user A in the Contact header of their SIP exchange. This URI refers to the user agent B is currently using, and it can be dereferenced by C's user agent. Because user B doesn't know in advance who user A will transfer the call to, the URI has to be usable by anyone.
为了启用此功能，用户B在其SIP交换的联系人标头中向用户A提供特定于实例的URI。此URI引用B当前使用的用户代理，C的用户代理可以解除对它的引用。因为用户B事先不知道用户A将呼叫转接给谁，所以URI必须可供任何人使用。
Many current clients attempt to meet the need for an instance-specific identifier by using explicit IP addresses in the values they provide in the Contact header field. However, this interacts poorly with NATs and firewalls, and as a practical matter, these URIs cannot be used by arbitrary external clients. Usage of hostnames has proven problematic for similar reasons. In addition, many SIP clients do not have or cannot obtain a hostname for themselves at all.
许多当前客户端试图通过在Contact header字段中提供的值中使用显式IP地址来满足对实例特定标识符的需求。但是，这与NAT和防火墙的交互很差，而且实际上，这些URI不能由任意外部客户端使用。由于类似的原因，主机名的使用已证明存在问题。此外，许多SIP客户端根本没有或无法为自己获取主机名。
This specification describes a mechanism for providing a unique user-agent identifier which is still globally routable. This identifier is called a Globally Routable User Agent (UA) URI (GRUU).
本规范描述了一种机制，用于提供仍然可以全局路由的唯一用户代理标识符。该标识符称为全局可路由用户代理（UA）URI（GRUU）。
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 RFC 2119 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中所述进行解释。
This specification defines the following additional terms:
本规范定义了以下附加条款：
contact: The term "contact", when used in all lowercase, refers to a URI that is bound to an AOR and GRUU by means of a registration. A contact is usually a SIP URI, and is bound to the AOR and GRUU through a REGISTER request by appearing as a value of the Contact header field. The contact URI identifies a specific UA.
contact：术语“contact”在所有小写字母中使用时，指的是通过注册绑定到AOR和GRUU的URI。联系人通常是一个SIPURI，通过一个注册请求将其作为联系人头字段的值绑定到AOR和GRUU。联系人URI标识特定UA。
remote target: The term "remote target" refers to a URI that a user agent uses to identify itself for receipt of both mid-dialog and out-of-dialog requests. A remote target is established by placing a URI in the Contact header field of a dialog-forming request or response and is updated by target refresh requests or responses.
远程目标：术语“远程目标”是指用户代理用于识别自身以接收对话中请求和对话外请求的URI。通过在形成请求或响应的对话框的Contact header字段中放置URI来建立远程目标，并通过目标刷新请求或响应进行更新。
Contact header field: The term "Contact header field", with a capitalized C, refers to the header field that can appear in REGISTER requests and responses, redirects, or dialog-creating requests and responses. Depending on the semantics, the Contact header field sometimes conveys a contact, and sometimes conveys a remote target.
联系人标题字段：术语“联系人标题字段”以大写字母C表示可以出现在注册请求和响应、重定向或创建请求和响应的对话框中的标题字段。根据语义，Contact header字段有时传递联系人，有时传递远程目标。
The basic idea behind a GRUU is simple. GRUUs are issued by SIP domains and always route back to a proxy in that domain. In turn, the domain maintains the binding between the GRUU and the particular UA instance. When a GRUU is dereferenced while sending a SIP request, that request arrives at the proxy. It maps the GRUU to the contact for the particular UA instance, and sends the request there.
GRUU背后的基本思想很简单。GRUU由SIP域发出，并始终路由回该域中的代理。反过来，域维护GRUU和特定UA实例之间的绑定。当GRUU在发送SIP请求时被解除引用时，该请求将到达代理。它将GRUU映射到特定UA实例的联系人，并在那里发送请求。
A GRUU is a SIP URI that has two properties:
GRUU是具有两个属性的SIP URI：
o It routes to a specific UA instance.
o 它路由到特定的UA实例。
o It can be successfully dereferenced by any user agent on the Internet, not just ones in the same domain or IP network as the UA instance to which the GRUU points.
o 它可以由Internet上的任何用户代理成功地解除引用，而不仅仅是与GRUU指向的UA实例位于同一域或IP网络中的用户代理。
In principle, a GRUU can be constructed in any way the domain chooses, as long as it meets the criteria above. However, all GRUUs contain the "gr" URI parameter (either with or without a value), so that a recipient of a GRUU can tell that it has these two properties.
原则上，GRUU可以以域选择的任何方式构造，只要它满足上述标准。但是，所有GRUU都包含“gr”URI参数（带值或不带值），因此GRUU的接收者可以知道它具有这两个属性。
In practice, there are two different types of GRUUs:
实际上，有两种不同类型的Gruu：
1. GRUUs that expose the underlying AOR
1. 暴露底层AOR的GRUUs
2. GRUUs that hide the underlying AOR
2. 隐藏潜在AOR的GRUUs
In many cases, it is desirable to construct the GRUU in such a way that the mapping to the AOR is apparent. For example, many user agents retain call logs, which keep track of incoming and outgoing call attempts. If the UA had made a call to a GRUU (perhaps as a consequence of a transfer request), the call log will contain the GRUU. Since the call log is rendered to the user, it would be useful to be able to present the user with the AOR instead, since the AOR is meaningful to users as an identifier.
在许多情况下，以这样一种方式构造GRUU是可取的，即到AOR的映射是显而易见的。例如，许多用户代理保留呼叫日志，用于跟踪传入和传出的呼叫尝试。如果UA对GRUU进行了调用（可能是传输请求的结果），则调用日志将包含GRUU。由于调用日志是呈现给用户的，因此能够向用户呈现AOR将非常有用，因为AOR作为标识符对用户来说是有意义的。
This type of GRUU is called a public GRUU. It is constructed by taking the AOR, and adding the "gr" URI parameter with a value chosen by the registrar in the domain. The value of the "gr" URI parameter contains a representation of the UA instance. For instance, if the AOR was "sip:alice@example.com", the GRUU might be:
这种类型的GRUU称为公共GRUU。它是通过获取AOR并添加“gr”URI参数和域中注册器选择的值来构造的。“gr”URI参数的值包含UA实例的表示。例如，如果AOR是“sip:alice@example.com“，GRUU可能是：
sip:alice@example.com;gr=kjh29x97us97d
sip:alice@example.com;gr=kjh29x97us97d
If a UA removes the "gr" URI parameter, the result is the AOR. Since many systems ignore unknown parameters anyway, a public GRUU will "look" like the AOR to those systems.
如果UA删除“gr”URI参数，则结果是AOR。由于许多系统无论如何都会忽略未知参数，因此对于这些系统来说，公共GRUU将“看起来”像AOR。
In other cases, it is desirable to construct a GRUU that obfuscates the AOR such that it cannot be extracted by a recipient of the GRUU. Such a GRUU is called a temporary GRUU. The most obvious reason to do this is to protect the user's privacy. In such cases, the GRUU can have any content, provided that it meets the requirements in Sections 3.1 and 5.4, and the AOR cannot be readily determined from the GRUU. The GRUU will have the "gr" URI parameter, either with or without a value. In order to avoid creating excessive state in the registrar, it is often desirable to construct cryptographically protected "stateless" GRUUs using an algorithm like that described in Appendix A.
在其他情况下，最好构造一个使AOR模糊的GRUU，以便GRUU的接收者无法提取它。这样的咕噜叫临时咕噜。这样做最明显的原因是为了保护用户的隐私。在这种情况下，GRUU可以包含任何内容，前提是它满足第3.1节和第5.4节中的要求，并且无法从GRUU中轻松确定AOR。GRUU将具有“gr”URI参数，可以有值也可以没有值。为了避免在注册器中创建过多的状态，通常需要使用附录A中描述的算法构造受加密保护的“无状态”GRUU。
An example of a temporary GRUU constructed using a stateful algorithm would be:
使用有状态算法构造的临时GRUU示例如下：
sip:asd887f9dfkk76690@example.com;gr
sip:asd887f9dfkk76690@example.com;gr
A user agent can obtain a GRUU in one of several ways:
用户代理可以通过以下几种方式之一获取GRUU：
o As part of its REGISTER transaction.
o 作为其注册交易的一部分。
o By constructing one locally, using the IP address or hostname of the user agent instance as the domain part of the URI. These are called self-made GRUUs, and are only really GRUUs when constructed by UAs that know they are globally reachable using their IP address or hostname.
o 通过在本地构造一个，使用用户代理实例的IP地址或主机名作为URI的域部分。这些被称为自制Gru，只有在UAs构建时才是真正的Gru，UAs知道它们可以使用其IP地址或主机名进行全局访问。
o Via some locally specified administrative mechanism.
o 通过一些当地指定的管理机制。
A UA that wants to obtain a GRUU via its REGISTER request does so by providing an instance ID in the "+sip.instance" Contact header field parameter, defined in RFC 5626 [14]. For example:
想要通过注册请求获得GRUU的UA通过在RFC 5626[14]中定义的“+sip.instance”联系人头字段参数中提供实例ID来实现。例如：
Contact: <sip:callee@192.0.2.2>
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Contact: <sip:callee@192.0.2.2>
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
The registrar detects this header field parameter and provides two GRUUs in the REGISTER response. One of these is a temporary GRUU, and the other is the public GRUU. These two GRUUs are returned in the "temp-gruu" and "pub-gruu" Contact header field parameters in the response, respectively. For example:
注册器检测到这个头字段参数，并在寄存器响应中提供两个GRU。其中一个是临时咕噜，另一个是公共咕噜。这两个Gru分别在响应中的“temp gru”和“pub gru”联系人头字段参数中返回。例如：
<allOneLine>
Contact: <sip:callee@192.0.2.2>
;pub-gruu="sip:callee@example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu="sip:tgruu.7hs==
jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=3600
</allOneLine>
<allOneLine>
Contact: <sip:callee@192.0.2.2>
;pub-gruu="sip:callee@example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu="sip:tgruu.7hs==
jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=3600
</allOneLine>
Note that the <allOneLine> tag is used as defined in [17].
请注意，<allOneLine>标记的使用与[17]中的定义相同。
When a user agent refreshes this registration prior to its expiration, the registrar will return back the same public GRUU, but will create a new temporary GRUU. Despite the fact that each refresh provides the UA with a new temporary GRUU, all of the temporary GRUUs
当用户代理在该注册到期之前刷新该注册时，注册器将返回相同的公共GRUU，但将创建一个新的临时GRUU。尽管每次刷新都为UA提供一个新的临时GRUU，但所有的临时GRUU
learned from previous REGISTER responses during the lifetime of a contact remain valid as long as (1) a contact with that instance ID remains registered, and (2) the UA doesn't change the Call-ID in its REGISTER request compared to previous ones for the same reg-id [14]. When the last contact for the instance expires, either through explicit de-registration or timeout, all of the temporary GRUUs become invalidated. Similarly, if a register refresh for a contact (or, if RFC 5626 is being used, for a reg-id) changes the Call-ID compared to previous register refreshes, all of the previous temporary GRUUs are invalidated. When the user agent later creates a new registration with the same instance ID, the public GRUU is the same. The temporary GRUU will be new (as it is with refreshes), and it will be the only valid temporary GRUU for the instance until the next refresh, at which point a second one becomes valid too. Consequently, temporary GRUUs "accumulate" during the lifetime of a registration.
只要（1）具有该实例ID的联系人保持注册状态，并且（2）UA不会改变其注册请求中的呼叫ID（与相同注册ID的先前请求相比）[14]，则在联系人的生命周期内从先前的注册响应中学习到的信息仍然有效。当实例的最后一个联系人过期时（通过显式取消注册或超时），所有临时GRUU都将失效。类似地，如果联系人的寄存器刷新（或者，如果正在使用RFC 5626，则为reg id）与以前的寄存器刷新相比更改了呼叫id，则所有以前的临时GRUU都将无效。当用户代理稍后使用相同的实例ID创建新注册时，公共GRUU是相同的。临时GRUU将是新的（与刷新一样），并且在下一次刷新之前，它将是实例的唯一有效临时GRUU，此时第二个GRUU也将变为有效。因此，在注册的有效期内，临时GRUU会“累积”。
Once a user agent obtains GRUUs from the registrar, it uses them in several ways. First, it uses them as the contents of the Contact header field in non-REGISTER requests and responses that it emits (for example, an INVITE request and 200 OK response). According to RFC 3261 [1], the Contact header field is supposed to contain a URI that routes to that user agent. Prior to this specification, there hasn't been a way to really meet that requirement. The user agent would use one of its temporary GRUUs for anonymous calls, and use its public GRUU otherwise.
一旦用户代理从注册器获得GRUUs，它就会以多种方式使用它们。首先，它将它们用作它发出的非注册请求和响应（例如，INVITE请求和200 OK响应）中联系人标头字段的内容。根据RFC3261[1]，联系人标头字段应该包含路由到该用户代理的URI。在本规范之前，还没有一种方法能够真正满足该要求。用户代理将使用其一个临时GRUU进行匿名调用，否则将使用其公共GRUU。
Second, the UA can use the GRUU in any other place it needs to use a URI that resolves to itself, such as a webpage.
其次，UA可以在需要使用解析为自身的URI的任何其他位置使用GRUU，例如网页。
Because a GRUU is simply a URI, a UA dereferences it in exactly the same way as it would any other URI. However, once the request has been routed to the appropriate proxy, the behavior is slightly different. The proxy will map the GRUU to the AOR and determine the set of contacts that the particular UA instance has registered. The GRUU is then mapped to those contacts, and the request is routed towards the UA.
因为GRUU只是一个URI，UA以与任何其他URI完全相同的方式解除对它的引用。但是，一旦请求被路由到适当的代理，行为就会略有不同。代理将GRUU映射到AOR，并确定特定UA实例已注册的联系人集。然后将GRUU映射到这些联系人，并将请求路由到UA。
This section defines the normative behavior for user agents.
本节定义了用户代理的规范行为。
When a UA compliant to this specification generates a REGISTER request (initial or refresh), it MUST include the Supported header field in the request. The value of that header field MUST include "gruu" as one of the option tags. This alerts the registrar for the domain that the UA supports the GRUU mechanism.
当符合本规范的UA生成注册请求（初始或刷新）时，它必须在请求中包含受支持的标头字段。该标题字段的值必须包含“gruu”作为选项标记之一。这会提醒域的注册器UA支持GRUU机制。
Furthermore, for each contact for which the UA desires to obtain a GRUU, the UA MUST include a "sip.instance" media feature tag (see RFC 5626 [14]) as a UA characteristic (see [7]), whose value MUST be the instance ID that identifies the UA instance being registered. Each such Contact header field SHOULD NOT contain a "pub-gruu" or "temp-gruu" header field. The contact URI MUST NOT be equivalent, based on the URI equality rules in RFC 3261 [1], to the AOR in the To header field. If the contact URI is a GRUU, it MUST NOT be a GRUU for the AOR in the To header field.
此外，对于UA希望获得GRUU的每个联系人，UA必须包括“sip.instance”媒体特征标签（参见RFC 5626[14]）作为UA特征（参见[7]），其值必须是标识正在注册的UA实例的实例ID。每个此类联系人标头字段不应包含“发布gruu”或“临时gruu”标头字段。根据RFC 3261[1]中的URI相等规则，联系人URI不得与to标头字段中的AOR等效。如果联系人URI是GRUU，则它不能是To头字段中AOR的GRUU。
As in RFC 3261 [1], the Call-ID in a REGISTER refresh SHOULD be identical to the Call-ID used to previously register a contact. With GRUU, an additional consideration applies. If the Call-ID changes in a register refresh, the server will invalidate all temporary GRUUs associated with that UA instance; the only valid one will be the new one returned in that REGISTER response. When RFC 5626 is in use, this rule applies to the reg-ids: If the Call-ID changes for the registration refresh for a particular reg-id, the server will invalidate all temporary GRUUs associated with that UA instance as a whole. Consequently, if a UA wishes its previously obtained temporary GRUUs to remain valid, it MUST utilize the same Call-ID in REGISTER refreshes. However, it MAY change the Call-ID in a refresh if invalidation is the desired objective.
与RFC 3261[1]中一样，寄存器刷新中的呼叫ID应与先前用于注册联系人的呼叫ID相同。对于GRUU，还需要考虑其他因素。如果在寄存器刷新中调用ID发生更改，服务器将使与该UA实例关联的所有临时GRUU无效；唯一有效的将是该寄存器响应中返回的新值。当使用RFC 5626时，此规则适用于reg ID：如果某个特定reg ID的注册刷新更改了调用ID，则服务器将使与该UA实例作为一个整体关联的所有临时GRU无效。因此，如果UA希望其先前获得的临时GRUU保持有效，则必须在寄存器刷新中使用相同的呼叫ID。但是，如果无效是所需的目标，它可能会在刷新中更改调用ID。
Note that, if any dialogs are in progress that utilize a temporary GRUU as a remote target, and a UA performs a registration refresh with a change in Call-ID, those temporary GRUUs become invalid, and the UA will not be reachable for subsequent mid-dialog messages.
请注意，如果正在进行任何将临时GRUU用作远程目标的对话框，并且UA在更改呼叫ID的情况下执行注册刷新，则这些临时GRUU将无效，后续mid对话消息将无法访问UA。
If a UA instance is trying to register multiple contacts for the same instance for the purposes of redundancy, it MUST use the procedures defined in RFC 5626 [14].
如果UA实例试图为同一实例注册多个联系人以实现冗余，则必须使用RFC 5626[14]中定义的程序。
A UA utilizing GRUUs can still perform third-party registrations and can include contacts that omit the "+sip.instance" Contact header field parameter.
使用GROUS的UA仍然可以执行第三方注册，并且可以包括省略“+sip.instance”联系人头字段参数的联系人。
If a UA wishes to guarantee that the REGISTER request is not processed unless the domain supports and uses this extension, it MAY include a Require header field in the request with a value that contains the "gruu" option tag. This is in addition to the presence of the Supported header field, also containing the "gruu" option tag. The use of Proxy-Require is not necessary and is NOT RECOMMENDED.
如果UA希望保证注册请求不被处理，除非域支持并使用此扩展，它可以在请求中包含一个Require头字段，该字段的值包含“gruu”选项标记。这是除了支持的标头字段之外的，该字段还包含“gruu”选项标记。不需要也不建议使用Proxy Require。
If the REGISTER response is a 2xx, each Contact header field that contains the "+sip.instance" Contact header field parameter can also contain a "pub-gruu" and "temp-gruu" Contact header field parameter. These header field parameters convey the public and a temporary GRUU for the UA instance, respectively. A UA MUST be prepared for a Contact header field to contain just a "pub-gruu", just a "temp-gruu", neither, or both. The temporary GRUU will be valid for the duration of the registration (that is, through refreshes), while the public GRUU persists across registrations. The UA will receive a new temporary GRUU in each successful REGISTER response, while the public GRUU will typically be the same. However, a UA MUST be prepared for the public GRUU to change from a previous one, since the persistence property is not guaranteed with complete certainty. If a UA changed its Call-ID in this REGISTER request compared to a previous REGISTER request for the same contact or reg-id, the UA MUST discard all temporary GRUUs learned through prior REGISTER responses. A UA MAY retain zero, one, some, or all of the temporary GRUUs that it is provided during the time over which at least one contact or reg-id remains continuously registered. If a UA stores any temporary GRUUs for use during its registration, it needs to be certain that the registration does not accidentally lapse due to clock skew between the UA and registrar. Consequently, the UA MUST refresh its registration such that the REGISTER refresh transaction will either complete or timeout prior to the expiration of the registration. For default transaction timers, this would be at least 32 seconds prior to expiration, assuming the registration expiration is larger than 64 seconds. If the registration expiration is less than 64 seconds, the UA SHOULD refresh its registration halfway prior to expiration.
如果寄存器响应为2xx，则包含“+sip.instance”联系人标头字段参数的每个联系人标头字段也可以包含“pub gruu”和“temp gruu”联系人标头字段参数。这些头字段参数分别为UA实例传递公共和临时GRUU。UA必须为联系人标头字段做好准备，以便只包含“发布gruu”，只包含“临时gruu”，两者都不包含，或两者都包含。临时GRUU在注册期间有效（即通过刷新），而公共GRUU在注册期间保持有效。UA将在每个成功的寄存器响应中接收一个新的临时GRUU，而公共GRUU通常是相同的。但是，必须为公共GRUU准备一个UA，以使其从上一个GRUU更改，因为持久性属性不能完全确定。如果UA在该注册请求中更改了其呼叫ID，与之前针对同一联系人或注册ID的注册请求相比，UA必须放弃通过之前的注册响应学习到的所有临时GRUU。UA可以保留其在至少一个联系人或注册id保持连续注册期间提供的零、一、部分或全部临时GRU。如果UA存储任何临时GRUU以供注册期间使用，则需要确保注册不会因UA和注册器之间的时钟偏移而意外失效。因此，UA必须刷新其注册，以使注册刷新事务在注册到期之前完成或超时。对于默认事务计时器，假设注册过期时间大于64秒，则这将至少比过期时间提前32秒。如果注册到期时间少于64秒，UA应在到期前一半时间刷新其注册。
Note that, when [14] is in use, and the UA is utilizing multiple flows for purposes of redundancy, the temporary GRUUs remain valid as long as at least one flow is registered. Thus, even if the registration of one flow expires, the temporary GRUUs learned previously remain valid.
注意，当[14]正在使用时，UA正在利用多个流来实现冗余，只要至少注册了一个流，临时GRUs就会保持有效。因此，即使一个流的注册过期，以前学习到的临时GRUU仍然有效。
In cases where registrars forcefully shorten registration intervals, the registration event package, RFC 3680 [24], is used by user agents to learn of these changes. A user agent implementing both RFC 3680 [24] and GRUU MUST also implement the extensions to RFC 3680 [24] for
在注册者强制缩短注册间隔的情况下，用户代理使用注册事件包RFC 3680[24]了解这些更改。实现RFC 3680[24]和GRUU的用户代理还必须实现对RFC 3680[24]的扩展，以便
conveying information on GRUU, as defined in RFC 5628 [28], as these are necessary to keep the set of temporary GRUUs synchronized between the UA and the registrar. More generally, the utility of temporary GRUUs depends on the UA and registrar being in sync on the set of valid temporary GRUUs at any time. Without support of RFC 3680 [24] and its extension for GRUU, the client will remain in sync only as long as it always re-registers well before the registration expiration. Besides forceful de-registrations, other events (such as network outages, connection failures, and short refresh intervals) can lead to potential inconsistencies in the set of valid temporary GRUUs. For this reason, it is RECOMMENDED that a UA that utilizes temporary GRUUs implement RFC 3680 [24] and RFC 5628 [28].
根据RFC 5628[28]中的定义，传递有关GRUU的信息，因为这些信息对于保持UA和注册器之间的临时GRUU集同步是必要的。更一般地说，临时GRUs的实用性取决于UA和注册器在任何时候都同步于有效的临时GRUs集。如果不支持RFC 3680[24]及其GRUU扩展，则只有在注册到期之前重新注册时，客户端才会保持同步。除了强制取消注册外，其他事件（如网络中断、连接故障和较短的刷新间隔）可能会导致有效临时GRU集中的潜在不一致。因此，建议使用临时GROU的UA实现RFC 3680[24]和RFC 5628[28]。
A non-2xx response to the REGISTER request has no impact on any existing GRUUs previously provided to the UA. Specifically, if a previously successful REGISTER request provided the UA with a GRUU, a subsequent failed request does not remove, delete, or otherwise invalidate the GRUU.
对注册请求的非2xx响应对先前提供给UA的任何现有GRUs没有影响。具体地说，如果先前成功的注册请求向UA提供了GRUU，则后续失败的请求不会删除、删除GRUU或使GRUU无效。
The user and host parts of the GRUU learned by the UA in the REGISTER response MUST be treated opaquely by the UA. That is, the UA MUST NOT modify them in any way. A UA MUST NOT modify or remove URI parameters it does not recognize. Furthermore, the UA MUST NOT add, remove, or modify URI parameters relevant for receipt and processing of request at the proxy, including the transport, lr, maddr, ttl, user, and comp (see RFC 3486 [25]) URI parameters. The other URI parameter defined in RFC 3261 [1], method, would not typically be present in a GRUU delivered from a registrar, and a UA MAY add a method URI parameter to the GRUU before handing it out to another entity. Similarly, the URI parameters defined in RFC 4240 [26] and RFC 4458 [27] are meant for consumption by the UA. These would not be included in the GRUU returned by a registrar and MAY be added by a UA wishing to provide services associated with those URI parameters.
UA在寄存器响应中学习到的GRUU的用户和主机部分必须由UA进行不透明处理。也就是说，UA不得以任何方式修改它们。UA不得修改或删除其无法识别的URI参数。此外，UA不得添加、删除或修改与代理接收和处理请求相关的URI参数，包括传输、lr、maddr、ttl、用户和comp（参见RFC 3486[25]）URI参数。RFC 3261[1]方法中定义的另一个URI参数通常不会出现在从注册器交付的GRUU中，UA可以在将方法URI参数发送给另一个实体之前将其添加到GRUU中。类似地，RFC 4240[26]和RFC 4458[27]中定义的URI参数是供UA使用的。这些将不包括在注册器返回的GRUU中，并且可能由希望提供与这些URI参数相关联的服务的UA添加。
Note, however, that should another UA dereference the GRUU, the parameters will be lost at the proxy when the Request-URI is translated into the registered contact, unless some other means is provided for the attributes to be delivered to the UA. Mechanisms for such delivery are currently the subject of future standardization activity (see "Delivery of Request-URI Targets to User Agents" [29]).
但是，请注意，如果另一个UA取消对GRUU的引用，则当请求URI转换为注册联系人时，代理上的参数将丢失，除非为要传递给UA的属性提供了一些其他方式。此类交付机制目前是未来标准化活动的主题（请参阅“向用户代理交付请求URI目标”[29]）。
Many user agents (such as gateways to the Public Switched Telephone Network (PSTN), conferencing servers, and media servers) do not perform registrations, and cannot obtain GRUUs through that mechanism. These types of user agents can be publicly reachable. This would mean that the policy of the domain is that requests can
许多用户代理（例如到公共交换电话网络（PSTN）、会议服务器和媒体服务器的网关）不执行注册，并且无法通过该机制获取GROU。这些类型的用户代理可以公开访问。这意味着域的策略是请求可以
come from anywhere on the public Internet and be delivered to the user agent without requiring processing by intervening proxies within the domain. Furthermore, firewall and NAT policies administered by the domain would allow such requests into the network. When a user agent is certain that these conditions are met, a UA MAY construct a self-made GRUU. Of course, a user agent that does REGISTER, but for whom these conditions are met regardless, MAY also construct a self-made GRUU. However, usage of GRUUs obtained by the registrar is RECOMMENDED instead.
来自公共互联网上的任何位置，并交付给用户代理，无需通过域内的代理进行处理。此外，域管理的防火墙和NAT策略将允许此类请求进入网络。当用户代理确定满足这些条件时，UA可以构造自制的GRUU。当然，注册的用户代理也可以构造一个自制的GRUU，但不管这些条件是否满足。但是，建议使用注册官获得的GROUS。
A self-made GRUU is one whose domain part equals the IP address or hostname of the user agent. The user part of the SIP URI is chosen arbitrarily by the user agent. Like all other GRUUs, the URI MUST contain the "gr" URI parameter, with or without a value, indicating it is a GRUU.
自制GRUU的域部分等于用户代理的IP地址或主机名。SIPURI的用户部分由用户代理任意选择。与所有其他GRUU一样，URI必须包含“gr”URI参数（带或不带值），以指示它是GRUU。
If a user agent does not register, but is not publicly reachable, it would need to obtain a GRUU through some other means. Typically, the UA would be configured with a GRUU, the GRUU would be configured into the proxy, and the proxy will be configured with a mapping from the GRUU to the IP address (or hostname) and port of the UA.
如果用户代理未注册，但无法公开访问，则需要通过其他方式获取GRUU。通常，UA将配置GRUU，GRUU将配置到代理中，代理将配置从GRUU到UA的IP地址（或主机名）和端口的映射。
A UA SHOULD use a GRUU when populating the Contact header field of dialog-forming and target refresh requests and responses. In other words, a UA compliant to this specification SHOULD use one of its GRUUs as its remote target. This includes:
UA在填充对话框形成和目标刷新请求和响应的联系人标头字段时应使用GRUU。换句话说，符合此规范的UA应该使用其Gru之一作为其远程目标。这包括：
o the INVITE request
o 邀请请求
o a 2xx or 18x response to an INVITE which contains a To tag
o 对包含to标记的邀请的2xx或18x响应
o the SUBSCRIBE request (see [5])
o 订阅请求（请参见[5]）
o a 2xx response to a SUBSCRIBE which contains a To tag
o 对包含to标记的订阅的2xx响应
o the NOTIFY request
o 通知请求
o the REFER request (see [6])
o REFER请求（参见[6]）
o a 2xx response to NOTIFY
o 通知的2xx响应
o the UPDATE request
o 更新请求
o a 2xx response to NOTIFY
o 通知的2xx响应
The only reason not to use a GRUU would be privacy considerations; see Section 10.3.
不使用GRUU的唯一原因是出于隐私考虑；见第10.3节。
When using a GRUU obtained through registrations, a UA MUST have an active registration prior to using a GRUU, and MUST use a GRUU learned through that registration. It MUST NOT reuse a GRUU learned through a previous registration that has lapsed (in other words, one obtained when registering a contact that has expired). The UA MAY use either the public or one of its temporary GRUUs provided by its registrar. A UA MUST NOT use a temporary GRUU learned in a REGISTER response whose Call-ID differs from the one in the most recent REGISTER request generated by the UA for the same AOR and instance ID (and, if RFC 5626 [14] is in use, reg-id). When a UA wishes to construct an anonymous request as described in RFC 3323 [15], it SHOULD use a temporary GRUU. See Section 10.3 for a more complete discussion on the level of privacy afforded by temporary GRUUs.
当使用通过注册获得的GRUU时，UA必须在使用GRUU之前进行活动注册，并且必须使用通过该注册学习的GRUU。它不得重复使用通过先前已过期的注册（换句话说，注册已过期的联系人时获得的）学习到的GRUU。UA可使用公众或其注册机构提供的临时GRUU。UA不得使用在寄存器响应中学习的临时GRUU，该响应的调用ID与UA为相同AOR和实例ID生成的最新寄存器请求中的调用ID不同（如果使用RFC 5626[14]，则为reg ID）。当UA希望按照RFC 3323[15]中的描述构造匿名请求时，它应该使用临时GRUU。有关临时GROUS提供的隐私级别的更完整讨论，请参见第10.3节。
As per RFC 3261 [1], a UA SHOULD include a Supported header with the option tag "gruu" in requests and responses it generates.
根据RFC 3261[1]，UA应在其生成的请求和响应中包含一个带有选项标记“gruu”的受支持标头。
In some SIP networks, a user agent can have a multiplicity of AORs, either in different domains or within the same domain. In such cases, additional considerations apply.
在某些SIP网络中，用户代理可以在不同域或同一域中具有多个AOR。在这种情况下，需要考虑其他因素。
When a UA sends a request, the request will be sent 'using' one of its AORs. This AOR will typically show up in the From header field of the request, and credentials unique to that AOR will be used to authenticate the request. The GRUU placed into the Contact header field of such a request SHOULD be one that is associated with the AOR used to send the request. In cases where the UA uses a tel URI (as defined in [11]) to populate the From header field, the UA typically has a SIP AOR that is treated as an alias for the tel URI. The GRUU associated with that SIP AOR SHOULD be used in the Contact header field.
当UA发送请求时，该请求将“使用”其一个AOR发送。此AOR通常会显示在请求的From标头字段中，并且该AOR特有的凭据将用于验证请求。放置在此类请求的Contact header字段中的GRUU应该是与用于发送请求的AOR关联的GRUU。在UA使用tel URI（如[11]中所定义）填充From标头字段的情况下，UA通常具有SIP AOR，该SIP AOR被视为tel URI的别名。应该在Contact header字段中使用与该SIP AOR关联的GRUU。
When a UA receives a request, the GRUU placed into the Contact header field of a 2xx response SHOULD be the one associated with the AOR or GRUU to which the request was most recently targeted. There are several ways to determine the AOR or GRUU to which a request was sent. For example, if a UA registered a different contact to each AOR (by using a different user part of the URI), the Request-URI (which contains that contact) will indicate the AOR.
当UA收到请求时，放入2xx响应的Contact header字段中的GRUU应该是与请求最近针对的AOR或GRUU关联的GRUU。有几种方法可以确定向其发送请求的AOR或GRUU。例如，如果UA向每个AOR注册了不同的联系人（通过使用URI的不同用户部分），则请求URI（包含该联系人）将指示AOR。
A GRUU is identified by the presence of the "gr" URI parameter, and this URI parameter might or might not have a value. A UA that wishes to send a request to a URI that contains a GRUU knows that the request will be delivered to a specific UA instance without further action on the part of the requestor.
GRUU由“gr”URI参数的存在来标识，该URI参数可能有值，也可能没有值。希望向包含GRUU的URI发送请求的UA知道该请求将被传递到特定的UA实例，而无需请求者采取进一步行动。
Some UAs implement non-standard URI-handling mechanisms that compensate for the fact that heretofore many contact URIs have not been globally routable. Since any URI containing the "gr" URI parameter is known to be globally routable, a UA SHOULD NOT apply such mechanisms when a contact URI contains the "gr" URI parameter.
一些UAs实现了非标准的URI处理机制，以补偿迄今为止许多联系人URI不可全局路由的事实。由于已知任何包含“gr”URI参数的URI都是全局可路由的，因此当联系人URI包含“gr”URI参数时，UA不应应用此类机制。
Because the instance ID is a callee capabilities parameter, a UA might be tempted to send a request to the AOR of a user, and include an Accept-Contact header field (defined in [12]) that indicates a preference for routing the request to a UA with a specific instance ID. Although this would appear to have the same effect as sending a request to the GRUU, it does not. The caller preferences expressed in the Accept-Contact header field are just preferences. Their efficacy depends on a UA constructing an Accept-Contact header field that interacts with domain-processing logic for an AOR, to cause a request to route to a particular instance. Given the variability in routing logic in a domain (for example, time-based routing to only selected contacts), this doesn't work for many domain-routing policies. However, this specification does not forbid a client from attempting such a request, as there can be cases where the desired operation truly is a preferential routing request.
由于实例ID是被调用方能力参数，UA可能会尝试向用户的AOR发送请求，并包含一个Accept Contact header字段（在[12]中定义）这表示将请求路由到具有特定实例ID的UA的首选项。尽管这看起来与向GRUU发送请求具有相同的效果，但实际上并非如此。Accept Contact header字段中表示的调用方首选项只是首选项。它们的有效性取决于UA构造一个Accept Contact header字段，该字段与AOR的域处理逻辑交互，以使请求路由到特定实例。考虑到域中路由逻辑的可变性（例如，仅针对选定联系人的基于时间的路由），这不适用于许多域路由策略。然而，本规范并不禁止客户机尝试此类请求，因为在某些情况下，所需的操作确实是优先路由请求。
When rendering a GRUU to a user through a user interface, it is RECOMMENDED that the "gr" URI parameter be removed. For public GRUUs, this will produce the AOR, as desired. For temporary GRUUs, the resulting URI will be seemingly random. Future work might provide improved mechanisms that would allow an automaton to know that a URI is anonymized, and therefore inappropriate to render.
当通过用户界面向用户呈现GRUU时，建议删除“gr”URI参数。对于公共GROUS，这将根据需要生成AOR。对于临时GROU，生成的URI看起来是随机的。未来的工作可能会提供改进的机制，让自动机知道URI是匿名的，因此不适合呈现。
A REGISTER request might contain a Require header field with the "gruu" option tag; this indicates that the registrar has to understand this extension in order to process the request. It does not require the registrar to create GRUUs, however.
注册请求可能包含带有“gruu”选项标记的Require头字段；这表明登记官必须理解此扩展才能处理请求。但是，它不要求注册器创建GROUS。
As the registrar is processing the contacts in the REGISTER request according to the procedures of step 7 in Section 10.3 of RFC 3261 [1], the registrar checks whether each Contact header field in the REGISTER message contains a "+sip.instance" header field parameter. If present with a non-zero expiration, the contact is processed further based on the rules in the remainder of this section. Otherwise, the contact is processed based on normal RFC 3261 [1] rules.
由于注册官根据RFC 3261[1]第10.3节中步骤7的程序处理注册请求中的联系人，注册官检查注册消息中的每个联系人标头字段是否包含“+sip.instance”标头字段参数。如果存在非零过期，则将根据本节剩余部分中的规则进一步处理该联系人。否则，将根据正常RFC 3261[1]规则处理联系人。
Note that handling of a REGISTER request containing a Contact header field with value "*" and an expiration of zero still retains the meaning defined in RFC 3261 [1] -- all contacts, not just those with a specific instance ID, are deleted. As described in Section 5.4, this removes the binding of each contact to the AOR and the binding of each contact to its GRUUs.
请注意，对包含值为“*”且过期时间为零的联系人标头字段的注册请求的处理仍然保留RFC 3261[1]中定义的含义——删除所有联系人，而不仅仅是具有特定实例ID的联系人。如第5.4节所述，这将消除每个触点与AOR的绑定以及每个触点与GRUU的绑定。
If the contact URI is equivalent (based on URI equivalence in RFC 3261 [1]) to the AOR, the registrar MUST reject the request with a 403, since this would cause a routing loop. If the contact URI is a GRUU for the AOR in the To header field of the REGISTER request, the registrar MUST reject the request with a 403, for the same reason. If the contact is not a SIP URI, the REGISTER request MUST be rejected with a 403.
如果联系人URI与AOR等效（基于RFC 3261[1]中的URI等效），则注册器必须使用403拒绝请求，因为这将导致路由循环。如果联系人URI是注册请求的To头字段中AOR的GRUU，则注册器必须以403拒绝该请求，原因与此相同。如果联系人不是SIPURI，则必须使用403拒绝注册请求。
Next, the registrar checks if there is already a valid public GRUU for the AOR (present in the To header field of the REGISTER request) and the instance ID (present as the content of the "+sip.instance" Contact header field parameter). If there is no valid public GRUU, the registrar SHOULD construct a public GRUU at this time according to the procedures of Section 5.4. The public GRUU MUST be constructed by adding the "gr" URI parameter, with a value, to the AOR. If the contact contained a "pub-gruu" Contact header field parameter, the header field parameter MUST be ignored by the registrar. A UA cannot suggest or otherwise provide a public GRUU to the registrar.
接下来，注册器检查AOR（存在于注册请求的To头字段中）和实例ID（作为“+sip.instance”联系人头字段参数的内容存在）是否已经存在有效的公共GRUU。如果没有有效的公共GRUU，注册官此时应根据第5.4节的程序构建公共GRUU。必须通过向AOR添加带有值的“gr”URI参数来构造公共GRUU。如果联系人包含“pub gruu”联系人标题字段参数，则注册器必须忽略标题字段参数。UA不能向注册官建议或以其他方式提供公共GRUU。
Next, the registrar checks for any existing contacts registered to the same AOR, instance ID, and if the contact in the REGISTER request is registering a flow [14], reg-id. If there is at least one, the registrar finds the one that was most recently registered, and examines the Call-ID value associated with that registered contact. If it differs from the one in the REGISTER request, the registrar MUST invalidate all previously generated temporary GRUUs for the AOR and instance ID. A consequence of this invalidation is that requests addressed to those GRUUs will be rejected by the domain with a 404 from this point forward.
接下来，注册官检查注册到同一AOR实例ID的任何现有联系人，以及注册请求中的联系人是否正在注册流[14]，reg-ID。如果至少有一个，注册官将查找最近注册的联系人，并检查与该注册联系人相关联的呼叫ID值。如果与注册请求中的请求不同，注册器必须使之前为AOR和实例ID生成的所有临时GRUs无效。该无效的结果是，从此时起，域将以404拒绝向这些GRUs发送的请求。
Next, the registrar SHOULD create a new temporary GRUU for the AOR and instance ID with the characteristics described in Section 5.4. The temporary GRUU construction algorithm MUST have the following two properties:
接下来，注册器应该为AOR和实例ID创建一个新的临时GRUU，其特征如第5.4节所述。临时GRUU构造算法必须具有以下两个属性：
1. The likelihood that the temporary GRUU is equal to another GRUU that the registrar has created MUST be vanishingly small.
1. 临时GRUU与注册器创建的另一个GRUU相等的可能性必须非常小。
2. Given a pair of GRUUs, it MUST be computationally infeasible to determine whether they were issued for the same AOR or instance ID or for different AORs and instance IDs.
2. 给定一对GROU，确定它们是针对相同的AOR或实例ID还是针对不同的AOR和实例ID发出的在计算上一定是不可行的。
If the contact contained a "temp-gruu" Contact header field parameter, the header field parameter MUST be ignored by the registrar. A UA cannot suggest or otherwise provide a temporary GRUU to the registrar.
如果联系人包含“temp gruu”联系人标题字段参数，则注册员必须忽略标题字段参数。UA不能向注册官建议或以其他方式提供临时GRUU。
When generating the 200 (OK) response to the REGISTER request, the procedures of step 8 of Section 10.3 of RFC 3261 [1] are followed. Furthermore, for each Contact header field value placed in the response, if the registrar has stored an instance ID associated with that contact, that instance ID is returned as a Contact header field parameter. If the REGISTER request contained a Supported header field that included the "gruu" option tag, and the registrar has at least one temporary GRUU assigned to the instance ID and AOR, the registrar MUST add a "temp-gruu" Contact header field parameter to that Contact header field. The value of the "temp-gruu" parameter is a quoted string, and MUST contain the most recently created temporary GRUU for that AOR and instance ID. In addition, if the registrar has a public GRUU assigned to the instance ID and AOR (and the client supports GRUUs), the registrar MUST add a "pub-gruu" Contact header field parameter to that Contact header field. The value of the "pub-gruu" Contact header field parameter is the public GRUU.
当生成对寄存器请求的200（OK）响应时，遵循RFC 3261[1]第10.3节步骤8的程序。此外，对于放置在响应中的每个联系人标头字段值，如果注册器已存储与该联系人相关联的实例ID，则该实例ID将作为联系人标头字段参数返回。如果注册请求包含包含“gruu”选项标记的受支持标头字段，并且注册器至少为实例ID和AOR分配了一个临时gruu，则注册器必须将“temp gruu”联系人标头字段参数添加到该联系人标头字段。“temp gruu”参数的值是一个带引号的字符串，必须包含最近为该AOR和实例ID创建的临时gruu。此外，如果注册器为实例ID和AOR分配了一个公共gruu（并且客户端支持gruu），则注册器必须添加一个“发布gruu”“联系人标题字段”参数添加到该联系人标题字段。“pub gru”Contact header字段参数的值是public gru。
The registrar SHOULD NOT include the "gruu" option tag in the Require or Supported header field of the response.
注册器不应在响应的Require或Supported头字段中包含“gruu”选项标记。
When a registered contact expires (either due to timeout or explicit de-registration), its binding to the AOR is removed as usual. In addition, its binding to its GRUUs are removed at the same time, as a consequence of the relationships described in Section 5.4
当已注册的联系人过期时（由于超时或显式取消注册），其与AOR的绑定将像往常一样被删除。此外，由于第5.4节中所述的关系，其与Gru的绑定同时被移除
If, as a consequence of the expiration of the contact, a particular GRUU no longer has any registered contacts bound to it, and the GRUU is a temporary GRUU, the GRUU MUST be invalidated. This means that all of the accumulated temporary GRUUs get invalidated once the last contact for a given instance ID expires.
如果由于联系人过期，特定GRUU不再绑定任何已注册的联系人，并且GRUU是临时GRUU，则必须使GRUU无效。这意味着，一旦给定实例ID的最后一个联系人过期，所有累积的临时Gru就会失效。
If, however, the GRUU was a public GRUU, the registrar SHOULD continue to treat the GRUU as valid. Consequently, subsequent requests targeted to the GRUU, prior to re-registration of a contact to the GRUU, SHOULD return a 480 (Temporarily Unavailable) response. In addition, since the GRUU remains valid, the rules in Section 5.1 will cause it to be retained when a contact with that instance ID is once again registered to the AOR.
但是，如果GRUU是公共GRUU，则注册官应继续将GRUU视为有效。因此，在将联系人重新注册到GRUU之前，针对GRUU的后续请求应返回480（暂时不可用）响应。此外，由于GRUU仍然有效，因此当具有该实例ID的联系人再次注册到AOR时，第5.1节中的规则将使其保留。
These rules give a public GRUU a semi-permanent property. The intent is that the registrar make every attempt to retain validity of the GRUU for as long as the AOR itself is known within the domain. The requirements for doing so are at SHOULD strength and not MUST strength because of the difficulty in meeting a MUST strength requirement; registrar failures could cause the set of valid GRUUs to be lost, and this specification requires the UA to be robust against such cases. That said, it is possible for a public GRUU to be constructed such that a registrar does not need to retain any additional state for it, yet the GRUU still meets the requirements described here.
这些规则赋予公共GRUU半永久性财产。其目的是，只要AOR本身在域中是已知的，注册官就会尽一切努力保持GRUU的有效性。这样做的要求是应该有力量，而不是必须有力量，因为难以满足必须有力量的要求；注册器故障可能会导致有效GRUU集丢失，该规范要求UA对此类情况具有鲁棒性。也就是说，公共GRUU的构造可以使注册器不需要为其保留任何附加状态，但GRUU仍然满足此处描述的要求。
This section defines additional behaviors associated with the construction and maintenance of a GRUU that are specific to a registrar. These rules do not apply to self-made GRUUs or GRUUs not obtained through registrations.
本节定义了与特定于注册器的GRUU的构造和维护相关的其他行为。这些规则不适用于自制GRUU或非通过注册获得的GRUU。
When a registrar creates a GRUU, it is required to maintain certain information associated with the GRUU, regardless of whether it is a public or temporary GRUU. Every GRUU is associated with a single AOR and a single instance ID. A registrar MUST be able to determine the instance ID and AOR when presented with a GRUU. In addition, the GRUU, like an AOR, resolves to zero or more contacts. While the AOR resolves to all registered contacts for an AOR, a GRUU resolves only to those contacts whose instance ID matches the one associated with the GRUU. For this reason, a contact with an instance ID is always bound to both a GRUU and its AOR, never just an AOR or just a GRUU. This is shown pictorially in Figure 1. The figure shows three contacts registered to a single AOR. One of the contacts has an instance ID of 1, and the other two have an instance ID of 2. There are two GRUUs for this AOR. One is associated with instance ID 1, and the other with instance ID 2. The first GRUU resolves only to
注册器创建GRUU时，需要维护与GRUU相关的某些信息，无论它是公共GRUU还是临时GRUU。每个GRUU都与一个AOR和一个实例ID相关联。注册器必须能够在提供GRUU时确定实例ID和AOR。此外，GRUU与AOR一样，解析为零个或多个联系人。当AOR解析为AOR的所有已注册联系人时，GRUU只解析为实例ID与GRUU关联的联系人。因此，具有实例ID的联系人始终绑定到GRUU及其AOR，而不仅仅是AOR或GRUU。如图1所示。该图显示了注册到单个AOR的三个联系人。其中一个联系人的实例ID为1，另外两个联系人的实例ID为2。这个AOR有两个Gruu。一个与实例ID 1关联，另一个与实例ID 2关联。第一个GRUU只决定
contacts whose instance ID is 1, and the second resolves only to contacts whose instance ID is 2. There will typically be multiple contacts for a given instance ID if a UA has crashed, rebooted, and re-registered with the same instance ID, or is using the mechanisms of RFC 5626 [14] to have multiple registrations for redundancy. If the contact for instance ID 1 expires, the AOR would resolve to two contacts, but the GRUU associated with instance ID 1 would resolve to zero.
实例ID为1的联系人，第二个仅解析为实例ID为2的联系人。如果UA已崩溃、重新启动并使用相同的实例ID重新注册，或者正在使用RFC 5626[14]的机制进行多个冗余注册，则给定实例ID通常会有多个联系人。如果实例ID 1的联系人过期，AOR将解析为两个联系人，但与实例ID 1关联的GRUU将解析为零。
+----------+ +----------+ +----------+
| GRUU | | | | GRUU |
| | | AOR | | |
|Instance:1| | | |Instance:2|
+----------+ +----------+ +----------+
| / | \ / |
| / | \ / |
| / | \ / |
| / | \ / |
| / | \ / |
| / | \ / |
| / | X |
| / | / \ |
| / | / \ |
| / | / \ |
V V V V V V
+----------+ +----------+ +----------+
| Contact | | Contact | | Contact |
| | | | | |
|Instance:1| |Instance:2| |Instance:2|
+----------+ +----------+ +----------+
+----------+ +----------+ +----------+
| GRUU | | | | GRUU |
| | | AOR | | |
|Instance:1| | | |Instance:2|
+----------+ +----------+ +----------+
| / | \ / |
| / | \ / |
| / | \ / |
| / | \ / |
| / | \ / |
| / | \ / |
| / | X |
| / | / \ |
| / | / \ |
| / | / \ |
V V V V V V
+----------+ +----------+ +----------+
| Contact | | Contact | | Contact |
| | | | | |
|Instance:1| |Instance:2| |Instance:2|
+----------+ +----------+ +----------+
Figure 1
图1
There can be multiple GRUUs with the same instance ID and AOR. Indeed, this specification requires registrars to maintain many -- one that is public, and several that are temporary. However, if two GRUUs are associated with different AORs or different instance IDs or both, the GRUUs MUST be different based on URI equality comparison. A GRUU in a domain MUST NOT be equivalent, based on URI comparison, to any AOR in a domain except for the one associated with the GRUU.
可以有多个具有相同实例ID和AOR的GRU。事实上，这个规范要求注册者维护很多——一个是公共的，还有几个是临时的。但是，如果两个Gru与不同的AOR或不同的实例ID或两者都关联，则基于URI相等性比较，Gru必须不同。基于URI比较，域中的GRUU不能等同于域中的任何AOR，与GRUU关联的AOR除外。
A public GRUU will always be equivalent to the AOR based on URI equality rules. The reason is that the rules in RFC 3261 [1] cause URI parameters that are in one URI, but not in the other, to be ignored for equality purposes. Since a public GRUU differs from an AOR only by the presence of the "gr" URI parameter, the two URIs are equivalent based on those rules.
基于URI相等规则，公共GRUU将始终等同于AOR。原因是RFC 3261[1]中的规则导致忽略一个URI中的URI参数，而不是另一个URI中的URI参数，以实现相等。由于公共GRUU与AOR的区别仅在于“gr”URI参数的存在，因此基于这些规则，这两个URI是等效的。
Once a temporary GRUU is constructed, it MUST be considered valid by the registrar until invalidated based on the rules described previously. Once a public GRUU is constructed, it MUST be considered valid for the duration that the AOR itself is valid. Once an AOR is no longer valid within a domain, all of its GRUUs MUST be considered invalid as well.
一旦构建了临时GRUU，注册官必须将其视为有效的，直到根据前面描述的规则无效为止。一旦构建了公共GRUU，它就必须在AOR本身有效的期间内被认为是有效的。一旦一个AOR在域内不再有效，它的所有Gru也必须被视为无效。
This specification does not mandate a particular mechanism for construction of the GRUU. Example algorithms for public and temporary GRUUs that work well are given in Appendix A. However, in addition to the properties described in Section 3.1, a GRUU constructed by a registrar MUST exhibit the following properties:
本规范不强制规定GRUU构造的特定机制。附录A中给出了运行良好的公共和临时GRUU的示例算法。但是，除了第3.1节中所述的属性外，注册机构构建的GRUU必须具有以下属性：
o The domain part of the URI is an IP address present on the public Internet, or, if it is a hostname, the resolution procedures of RFC 3263 [2], once applied, result in an IP address on the public Internet.
o URI的域部分是公共Internet上的IP地址，或者，如果它是主机名，RFC 3263[2]的解析过程一旦应用，就会在公共Internet上产生IP地址。
o When a request is sent to the GRUU, it routes to a proxy that can access the registration data generated by the registrar. Such a proxy is called an authoritative proxy, defined in RFC 5626 [14].
o 当一个请求被发送到GRUU时，它将路由到一个代理，该代理可以访问注册器生成的注册数据。这种代理称为权威代理，定义见RFC 5626[14]。
RFC 3680 [24] defines an event package that allows a client to learn about registration events at the registrar. This package allows registrars to alter registrations forcefully (for example, shortening them to force a re-registration). If a registrar is supporting RFC 3680 [24] and GRUU, it MUST also support RFC 5628 [28].
RFC 3680[24]定义了一个事件包，允许客户机在注册器上了解注册事件。该软件包允许注册者强制更改注册（例如，缩短注册以强制重新注册）。如果注册器支持RFC 3680[24]和GRUU，则它还必须支持RFC 5628[28]。
Proxy behavior is fully defined in Section 16 of RFC 3261 [1]. GRUU processing impacts that processing in two places -- request targeting at the authoritative proxy and record-routing.
RFC 3261[1]第16节对代理行为进行了全面定义。GRUU处理在两个方面影响了该处理——以权威代理为目标的请求和记录路由。
When a proxy receives a request, owns the domain in the Request-URI, and is supposed to access a location service in order to compute request targets (as specified in Section 16.5 of RFC 3261 [1]), the proxy examines the Request-URI. If it contains the "gr" URI parameter but is not equivalent, based on URI comparison, to a currently valid GRUU within the domain, it SHOULD be rejected with a 404 (Not Found) response; this is the same behavior a proxy would exhibit for any other URI within the domain that is not valid.
当代理收到请求，拥有请求URI中的域，并应访问位置服务以计算请求目标（如RFC 3261[1]第16.5节所述）时，代理将检查请求URI。如果它包含“gr”URI参数，但根据URI比较，它与域中当前有效的gru不等效，则应使用404（未找到）响应拒绝它；这与代理对域中任何其他无效URI所表现的行为相同。
If the Request-URI contains the "gr" URI parameter and is equivalent, based on URI comparison, to a GRUU which is currently valid within the domain, processing proceeds as it would for any other URI present in the location service, as defined in Section 16.5 of RFC 3261 [1], except that the "gr" URI parameter is not removed as part of the canonicalization process. This is the case for both out-of-dialog requests targeted to the GRUU, and mid-dialog requests targeted to the GRUU (in which case the incoming request would have a Route header field value containing the URI that the proxy used for record-routing.).
如果请求URI包含“gr”URI参数，并且基于URI比较，与域内当前有效的GRUU等效，则处理过程将按照RFC 3261[1]第16.5节中定义的位置服务中存在的任何其他URI进行，但“gr”除外URI参数不会作为规范化过程的一部分删除。对于以GRUU为目标的对话外请求和以GRUU为目标的对话中请求（在这种情况下，传入请求将具有包含代理用于记录路由的URI的路由头字段值），都是这种情况。
Note that the "gr" URI parameter is retained just for the purposes of finding the GRUU in the location service; if a match is found, the Request-URI will be rewritten with the registered contacts, replacing the GRUU and its "gr" URI parameter. The "gr" URI parameter is not carried forward into the rewritten Request-URI.
注意，“gr”URI参数只是为了在位置服务中查找GRUU而保留的；如果找到匹配项，将使用注册的联系人重写请求URI，替换GRUU及其“gr”URI参数。“gr”URI参数未结转到重写的请求URI中。
If there are no registered contacts bound to the GRUU, the server MUST return a 480 (Temporarily Unavailable) response. If there are more than one, there are two cases:
如果没有绑定到GRUU的已注册联系人，服务器必须返回480（暂时不可用）响应。如果有多个，则有两种情况：
1. The client is using RFC 5626 [14] and registering multiple contacts for redundancy. In that case, these contacts contain "reg-id" Contact header field parameters, and the rules described in Section 7 of RFC 5626 [14] for selecting a single registered contact apply.
1. 客户端正在使用RFC 5626[14]并注册多个联系人以进行冗余。在这种情况下，这些联系人包含“reg id”联系人标题字段参数，RFC 5626[14]第7节中描述的选择单个注册联系人的规则适用。
2. The client was not using RFC 5626 [14], in which case there would only be multiple contacts with the same instance ID if the client had rebooted, restarted, and re-registered. In this case, these contacts would not contain the "reg-id" Contact header field parameter. The proxy MUST select the most recently refreshed contact. As with RFC 5626, if a request to this target fails with a 408 (Request Timeout) or 430 (Flow Failed) response, the proxy SHOULD retry with the next most recently refreshed contact. Furthermore, if the request fails with any other response, the proxy MUST NOT retry on any other contacts for this instance.
2. 客户端未使用RFC 5626[14]，在这种情况下，如果客户端已重新启动、重新启动并重新注册，则只有多个联系人具有相同的实例ID。在这种情况下，这些联系人将不包含“reg id”联系人标题字段参数。代理必须选择最近刷新的联系人。与RFC 5626一样，如果对该目标的请求失败，并出现408（请求超时）或430（流失败）响应，则代理应使用下一个最近刷新的联系人重试。此外，如果请求失败，并且出现任何其他响应，则代理不得在此实例的任何其他联系人上重试。
Any caller preferences in the request (as defined in RFC 3841 [12]) SHOULD be processed against the contacts bound to the GRUU.
请求中的任何呼叫者首选项（如RFC 3841[12]中所定义）都应针对绑定到GRUU的联系人进行处理。
In essence, to select a registered contact, the GRUU is processed just like it was the AOR, but with only a subset of the contacts bound to the AOR.
本质上，要选择已注册的联系人，GRUU的处理方式与AOR相同，但只有一部分联系人绑定到AOR。
Special considerations apply to the processing of any Path headers stored in the registration (see RFC 3327 [3]). If the received request has Route header field values beyond the one pointing to the
特殊注意事项适用于注册中存储的任何路径头的处理（参见RFC 3327[3]）。如果收到的请求的路由头字段值超出指向
authoritative proxy itself (this will happen when the request is a mid-dialog request), the Path URI MUST be discarded. This is permitted by RFC 3327 [3] as a matter of local policy; usage of GRUUs will require this policy in order to avoid call spirals and likely call failures.
权威代理本身（当请求是mid对话请求时会发生这种情况），必须放弃路径URI。这是RFC 3327[3]根据当地政策允许的；为了避免呼叫螺旋和可能的呼叫失败，GROUS的使用将需要此策略。
A proxy MAY apply other processing to the request, such as execution of called party features, as it might do for requests targeted to an AOR. For requests that are outside of a dialog, it is RECOMMENDED to apply screening types of functions, both automated (such as blacklist and whitelist screening) and interactive (such as interactive voice response (IVR) applications that confer with the user to determine whether to accept a call). In many cases, the new request is related to an existing dialog, and might be an attempt to join it (using the Join header field defined in RFC 3911 [21]) or replace it (using the Replaces header field defined in RFC 3891 [22]). When the new request is related to an existing dialog, the UA will typically make its own authorization decisions; bypassing screening services at the authoritative proxy might make sense, but needs to be carefully considered by network designers, as the ability to do so depends on the specific type of screening service.
代理可以对请求应用其他处理，例如执行被叫方功能，就像它对以AOR为目标的请求所做的那样。对于对话框之外的请求，建议应用屏蔽类型的功能，包括自动（如黑名单和白名单屏蔽）和交互式（如交互式语音应答（IVR）应用程序，与用户协商以确定是否接受呼叫）。在许多情况下，新请求与现有对话框相关，可能是试图加入该对话框（使用RFC 3911[21]中定义的联接标头字段）或替换它（使用RFC 3891[22]中定义的替换标头字段）。当新请求与现有对话框相关时，UA通常会做出自己的授权决策；绕过权威代理上的筛选服务可能是有意义的，但网络设计者需要仔细考虑，因为这样做的能力取决于特定类型的筛选服务。
However, forwarding services, such as call forwarding, SHOULD NOT be provided for requests sent to a GRUU. The intent of the GRUU is to target a specific UA instance, and this is incompatible with forwarding operations.
但是，不应为发送到GRUU的请求提供转发服务，例如呼叫转发。GRUU的目的是针对特定的UA实例，这与转发操作不兼容。
If the request is a mid-dialog request, a proxy SHOULD only apply services that are meaningful for mid-dialog requests, generally speaking. This excludes screening and forwarding functions.
如果请求是mid对话请求，一般来说，代理应该只应用对mid对话请求有意义的服务。这不包括筛选和转发功能。
In addition, a request sent to a GRUU SHOULD NOT be redirected. In many instances, a GRUU is used by a UA in order to assist in the traversal of NATs and firewalls, and a redirection might prevent such a case from working.
此外，发送到GRUU的请求不应重定向。在许多情况下，UA使用GRUU来帮助穿越NAT和防火墙，重定向可能会阻止这种情况的发生。
There are two distinct requirements for record-routing -- in the originating domain and in the terminating domain. These requirements avoid unnecessary, and possibly problematic, spirals of requests.
记录路由有两个不同的要求——在起始域和终止域中。这些需求避免了不必要的、可能有问题的螺旋式请求。
If:
如果：
o an originating authoritative proxy receives a dialog-forming request,
o 发起的权威代理接收对话形成请求，
o AND the Contact header field contains a GRUU in the domain of the proxy,
o 联系人标头字段包含代理域中的GRUU，
o AND that GRUU is a valid one in the domain of the proxy,
o 而且GRUU在代理的域中是有效的，
o AND that GRUU is associated with the AOR matching the authenticated identity of the requestor (assuming such authentication has been performed),
o 并且GRUU与与与请求者的认证身份相匹配的AOR相关联（假设已经执行了此类认证），
o AND the request contains Record-Route header fields,
o 请求包含记录路由头字段，
then the authoritative proxy MUST record-route. If all of these conditions are true, except that the GRUU is associated with an AOR that did not match the authenticated identity of the requestor, it is RECOMMENDED that the proxy reject the request with a 403 (Forbidden) response.
然后，权威代理必须记录路由。如果所有这些条件都为真，除了GRUU与与请求者的身份验证不匹配的AOR关联外，建议代理使用403（禁止）响应拒绝请求。
If:
如果：
o a terminating authoritative proxy receives a dialog-forming request,
o 终止的权威代理接收对话形成请求，
o AND the Request-URI contains a URI in the location service (either a GRUU or an AOR),
o 请求URI包含位置服务中的URI（GRUU或AOR），
o AND the contact selected for sending the request has an instance ID and is bound to a GRUU,
o 选择用于发送请求的联系人具有实例ID并绑定到GRUU，
o AND the registration contain Path URI,
o 并且注册包含路径URI，
then the authoritative proxy MUST record-route.
然后，权威代理必须记录路由。
If a proxy is in either the originating or terminating domains but is not an authoritative proxy, the proxy MAY record-route.
如果代理位于发起域或终止域中，但不是权威代理，则该代理可以记录路由。
If a proxy in the terminating domain requires mid-dialog requests to pass through it for whatever reason (firewall traversal, accounting, etc.), the proxy MUST still record-route, and MUST NOT assume that a UA will utilize its GRUU in the Contact header field of its response (which would cause mid-dialog requests to pass through the proxy without record-routing).
如果终止域中的代理出于任何原因（防火墙遍历、记帐等）需要mid对话请求通过它，则代理仍必须记录路由，并且不得假设UA将在其响应的联系人标头字段中使用其GRUU（这将导致mid对话请求通过代理而不通过记录路由）。
Implementors should note that, if a UA uses a GRUU in its contact, and a proxy inserted itself into the Path header field of a registration, that proxy will be receiving mid-dialog requests regardless of whether it record-routes or not. The only distinction is what URI the proxy will see in the topmost Route
实现者应该注意，如果UA在其联系人中使用GRUU，并且代理将自己插入到注册的路径头字段中，则该代理将接收mid对话请求，而不管它是否记录路由。唯一的区别是代理将在最顶端的路由中看到什么URI
header field of mid-dialog requests. If the proxy record-routes, it will see that URI. If it does not, it will see the Path URI it inserted.
mid对话框请求的标题字段。如果代理记录路由，它将看到该URI。如果没有，它将看到它插入的路径URI。
This specification defines two new Contact header field parameters ("temp-gruu" and "pub-gruu") by extending the grammar for "contact-params" as defined in RFC 3261 [1]. It also defines a new SIP URI parameter ("gr") by extending the grammar for "uri-parameter" as defined in RFC 3261 [1]. The ABNF [13] is as follows:
本规范通过扩展RFC 3261[1]中定义的“联系人参数”语法，定义了两个新的联系人标头字段参数（“temp gru”和“pub gru”）。它还通过扩展RFC3261[1]中定义的“URI参数”语法来定义新的SIP URI参数（“gr”）。ABNF[13]如下所示：
contact-params =/ temp-gruu / pub-gruu
temp-gruu = "temp-gruu" EQUAL quoted-string
pub-gruu = "pub-gruu" EQUAL quoted-string
contact-params =/ temp-gruu / pub-gruu
temp-gruu = "temp-gruu" EQUAL quoted-string
pub-gruu = "pub-gruu" EQUAL quoted-string
uri-parameter =/ gr-param
gr-param = "gr" ["=" pvalue] ; defined in RFC 3261
uri-parameter =/ gr-param
gr-param = "gr" ["=" pvalue] ; defined in RFC 3261
The quoted strings for temp-gruu and pub-gruu MUST contain a SIP URI. However, they are encoded like all other quoted strings and can therefore contain quoted-pair escapes when represented this way.
temp gruu和pub gruu的带引号的字符串必须包含SIP URI。但是，它们像所有其他带引号的字符串一样进行编码，因此当以这种方式表示时，可以包含带引号的对转义。
This specification was created in order to meet the following requirements:
创建本规范是为了满足以下要求：
REQ 1: When a UA invokes a GRUU, it must cause the request to be routed to the specific UA instance to which the GRUU refers.
REQ 1：当UA调用GRUU时，它必须使请求路由到GRUU引用的特定UA实例。
REQ 2: It must be possible for a GRUU to be invoked from anywhere on the Internet, and still cause the request to be routed appropriately. That is, a GRUU must not be restricted to use within a specific addressing realm.
REQ 2：必须能够从Internet上的任何位置调用GRUU，并且仍然能够正确路由请求。也就是说，GRUU不能被限制在特定的寻址域内使用。
REQ 3: It must be possible for a GRUU to be constructed without requiring the network to store additional state.
REQ 3：必须能够在不要求网络存储额外状态的情况下构造GRUU。
REQ 4: It must be possible for a UA to obtain a multiplicity of GRUUs that each route to that UA instance. For example, this is needed to support ad hoc conferencing where a UA instance needs a different URI for each conference it is hosting. NOTE: This requirement is not met by this specification, and is being addressed in a separate specification (currently, "Delivery of Request-URI Targets to User Agents" [29]).
REQ 4：UA必须能够获得多个GRUU，每个GRUU路由到该UA实例。例如，这是支持特别会议所必需的，在这种情况下，UA实例需要为其主持的每个会议使用不同的URI。注：本规范未满足此要求，并在单独的规范中解决（目前为“向用户代理交付请求URI目标”[29]）。
REQ 5: When a UA receives a request sent to a GRUU, it must be possible for the UA to know the GRUU that was used to invoke the request. This is necessary as a consequence of REQ 4. NOTE: This requirement is not met by this specification, and is being addressed in a separate specification (currently, "Delivery of Request-URI Targets to User Agents" [29]).
REQ 5：当UA收到发送给GRUU的请求时，UA必须能够知道用于调用请求的GRUU。根据要求4，这是必要的。注：本规范未满足此要求，并在单独的规范中解决（目前为“向用户代理交付请求URI目标”[29]）。
REQ 6: It must be possible for a UA to add opaque content to a GRUU. This content is not interpreted or altered by the network, and is used only by the UA instance to whom the GRUU refers. This provides a basic cookie type of functionality, allowing a UA to build a GRUU with the state embedded. NOTE: This requirement is not met by this specification, and is being addressed in a separate specification (currently, "Delivery of Request-URI Targets to User Agents" [29]).
请求6：UA必须能够向GRUU添加不透明内容。该内容不由网络解释或更改，仅由GRUU引用的UA实例使用。这提供了一种基本的cookie类型的功能，允许UA构建嵌入状态的GRUU。注：本规范未满足此要求，并在单独的规范中解决（目前为“向用户代理交付请求URI目标”[29]）。
REQ 7: It must be possible for a proxy to execute services and features on behalf of a UA instance represented by a GRUU. As an example, if a user has call-blocking features, a proxy might want to apply those call-blocking features to calls made to the GRUU, in addition to calls made to the user's AOR.
REQ 7：代理必须能够代表由GRUU表示的UA实例执行服务和功能。例如，如果用户具有呼叫阻塞功能，则代理可能希望将这些呼叫阻塞功能应用于对GRUU的调用，以及对用户AOR的调用。
REQ 8: It must be possible for a UA in a dialog to inform its peer of its GRUU, and for the peer to know that the URI represents a GRUU. This is needed for the conferencing and dialog reuse applications of GRUUs, where the URIs are transferred within a dialog.
REQ 8：对话中的UA必须能够通知其对等方其GRUU，并且对等方知道URI代表GRUU。GRUUs的会议和对话框重用应用程序需要这样做，其中URI在对话框中传输。
REQ 9: When transferring a GRUU per REQ 8, it must be possible for the UA receiving the GRUU to be assured of its integrity and authenticity.
REQ 9：当根据REQ 8传输GRUU时，接收GRUU的UA必须能够确保其完整性和真实性。
REQ 10: It must be possible for a server that is authoritative for a domain to construct a GRUU that routes to a UA instance bound to an AOR in that domain. In other words, the proxy can construct a GRUU, too. This is needed for the presence application.
REQ 10：域的权威服务器必须能够构造路由到绑定到该域中AOR的UA实例的GRUU。换句话说，代理也可以构造GRUU。这是状态应用程序所必需的。
The following call flow, shown in Figure 2, shows a basic registration and call setup, followed by a subscription directed to the GRUU. It then shows a failure of the callee, followed by a re-registration. The conventions of RFC 4475 [17] are used to describe the representation of long message lines.
下面的调用流（如图2所示）显示了一个基本的注册和调用设置，然后是指向GRUU的订阅。然后显示被调用方失败，然后是重新注册。RFC 4475[17]的约定用于描述长消息行的表示。
Caller Proxy Callee
| |(1) REGISTER |
| |<--------------------|
| |(2) 200 OK |
| |-------------------->|
|(3) INVITE | |
|-------------------->| |
| |(4) INVITE |
| |-------------------->|
| |(5) 200 OK |
| |<--------------------|
|(6) 200 OK | |
|<--------------------| |
|(7) ACK | |
|-------------------->| |
| |(8) ACK |
| |-------------------->|
|(9) SUBSCRIBE | |
|-------------------->| |
| |(10) SUBSCRIBE |
| |-------------------->|
| |(11) 200 OK |
| |<--------------------|
|(12) 200 OK | |
|<--------------------| |
| |(13) NOTIFY |
| |<--------------------|
|(14) NOTIFY | |
|<--------------------| |
|(15) 200 OK | |
|-------------------->| |
| |(16) 200 OK |
| |-------------------->|
| | |Crashes,
| |(17) REGISTER | Reboots
| |<--------------------|
| |(18) 200 OK |
| |-------------------->|
Caller Proxy Callee
| |(1) REGISTER |
| |<--------------------|
| |(2) 200 OK |
| |-------------------->|
|(3) INVITE | |
|-------------------->| |
| |(4) INVITE |
| |-------------------->|
| |(5) 200 OK |
| |<--------------------|
|(6) 200 OK | |
|<--------------------| |
|(7) ACK | |
|-------------------->| |
| |(8) ACK |
| |-------------------->|
|(9) SUBSCRIBE | |
|-------------------->| |
| |(10) SUBSCRIBE |
| |-------------------->|
| |(11) 200 OK |
| |<--------------------|
|(12) 200 OK | |
|<--------------------| |
| |(13) NOTIFY |
| |<--------------------|
|(14) NOTIFY | |
|<--------------------| |
|(15) 200 OK | |
|-------------------->| |
| |(16) 200 OK |
| |-------------------->|
| | |Crashes,
| |(17) REGISTER | Reboots
| |<--------------------|
| |(18) 200 OK |
| |-------------------->|
Figure 2
图2
The callee supports the GRUU extension. As such, its REGISTER (1) looks like:
被调用方支持GRUU扩展。因此，其寄存器（1）类似于：
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Callee <sip:callee@example.com>;tag=a73kszlfl
Supported: gruu
To: Callee <sip:callee@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:callee@192.0.2.1>
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Content-Length: 0
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Callee <sip:callee@example.com>;tag=a73kszlfl
Supported: gruu
To: Callee <sip:callee@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:callee@192.0.2.1>
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Content-Length: 0
The registrar assigns a temporary and a public GRUU. The REGISTER response (message 2) would look like:
注册官分配临时和公共GRUU。寄存器响应（消息2）如下所示：
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
From: Callee <sip:callee@example.com>;tag=a73kszlfl
To: Callee <sip:callee@example.com> ;tag=b88sn
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
<allOneLine>
Contact: <sip:callee@192.0.2.1>
;pub-gruu="sip:callee@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu="sip:tgruu.7hs==
jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=3600
</allOneLine>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
From: Callee <sip:callee@example.com>;tag=a73kszlfl
To: Callee <sip:callee@example.com> ;tag=b88sn
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
<allOneLine>
Contact: <sip:callee@192.0.2.1>
;pub-gruu="sip:callee@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu="sip:tgruu.7hs==
jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=3600
</allOneLine>
Content-Length: 0
The Contact header field in the REGISTER response contains the "pub-gruu" Contact header field parameter with the public GRUU sip:callee@ example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6, and the "temp-gruu" header field parameter with the temporary GRUU sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr. Both are valid GRUUs for the AOR and instance ID, and both translate to the contact sip:callee@192.0.2.1.
寄存器响应中的Contact header字段包含“pub gruu”Contact header字段参数，该参数带有public gruu sip:callee@example.com；gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6，以及带有临时gruu sip:tgruu.7hs==jd7vnzga5w7fajsc7的“temp gruu”头字段参数-ajd6fabz0f8g5@example.com;gr。两者都是AOR和实例ID的有效GRUU，并且都转换为联系人sip：callee@192.0.2.1.
The INVITE from the caller (message 3) is a normal SIP INVITE. However, the 200 OK generated by the callee (message 5) now contains a GRUU as the remote target. The UA has chosen to use its public GRUU.
来自呼叫者的邀请（消息3）是正常的SIP邀请。但是，被调用方生成的200OK（消息5）现在包含一个GRUU作为远程目标。UA已选择使用其公共GRUU。
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a
From: Caller <sip:caller@example.com>;tag=n88ah
To: Callee <sip:callee@example.com> ;tag=a0z8
Call-ID: 1j9FpLxk3uxtma7@host.example.com
CSeq: 1 INVITE
Supported: gruu
Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, SUBSCRIBE
<allOneLine>
Contact:
<sip:callee@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
</allOneLine>
Content-Length: --
Content-Type: application/sdp
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a
From: Caller <sip:caller@example.com>;tag=n88ah
To: Callee <sip:callee@example.com> ;tag=a0z8
Call-ID: 1j9FpLxk3uxtma7@host.example.com
CSeq: 1 INVITE
Supported: gruu
Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, SUBSCRIBE
<allOneLine>
Contact:
<sip:callee@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
</allOneLine>
Content-Length: --
Content-Type: application/sdp
[SDP Not shown]
[未显示SDP]
At some point later in the call, the caller decides to subscribe to the dialog event package (defined in [16]) at that specific UA. To do that, it generates a SUBSCRIBE request (message 9), but directs it towards the remote target, which is a GRUU:
在调用的稍后某个时刻，调用方决定在该特定UA订阅对话事件包（定义见[16]）。为此，它生成一个订阅请求（消息9），但将其指向远程目标，即GRUU：
<allOneLine>
SUBSCRIBE sip:callee@example.com;gr=urn:uuid:f8
1d4fae-7dec-11d0-a765-00a0c91e6bf6
SIP/2.0
</allOneLine>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:caller@example.com>;tag=kkaz-
<allOneLine>
To: <sip:callee@example.com;gr=urn:uuid:f8
1d4fae-7dec-11d0-a765-00a0c91e6bf6>
</allOneLine>
Call-ID: faif9a@host.example.com
CSeq: 2 SUBSCRIBE
Supported: gruu
Event: dialog
Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY
Contact: <sip:caller@example.com;gr=hdg7777ad7aflzig8sf7>
Content-Length: 0
<allOneLine>
SUBSCRIBE sip:callee@example.com;gr=urn:uuid:f8
1d4fae-7dec-11d0-a765-00a0c91e6bf6
SIP/2.0
</allOneLine>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:caller@example.com>;tag=kkaz-
<allOneLine>
To: <sip:callee@example.com;gr=urn:uuid:f8
1d4fae-7dec-11d0-a765-00a0c91e6bf6>
</allOneLine>
Call-ID: faif9a@host.example.com
CSeq: 2 SUBSCRIBE
Supported: gruu
Event: dialog
Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY
Contact: <sip:caller@example.com;gr=hdg7777ad7aflzig8sf7>
Content-Length: 0
In this example, the caller itself supports the GRUU extension and is using its own GRUU to populate its remote target.
在本例中，调用方本身支持GRUU扩展，并使用自己的GRUU填充其远程目标。
This request is routed to the proxy, which proceeds to perform a location lookup on the Request-URI. It is translated into the contact for that instance, and then proxied to that contact.
此请求被路由到代理，代理继续对请求URI执行位置查找。它被转换为该实例的联系人，然后代理给该联系人。
SUBSCRIBE sip:callee@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK9555
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:caller@example.com>;tag=kkaz-
<allOneLine>
To: <sip:callee@example.com;gr=urn:uuid:f8
1d4fae-7dec-11d0-a765-00a0c91e6bf6>
</allOneLine>
Call-ID: faif9a@host.example.com
CSeq: 2 SUBSCRIBE
Supported: gruu
Event: dialog
Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY
Contact: <sip:caller@example.com;gr=hdg7777ad7aflzig8sf7>
Content-Length: 0
SUBSCRIBE sip:callee@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK9555
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:caller@example.com>;tag=kkaz-
<allOneLine>
To: <sip:callee@example.com;gr=urn:uuid:f8
1d4fae-7dec-11d0-a765-00a0c91e6bf6>
</allOneLine>
Call-ID: faif9a@host.example.com
CSeq: 2 SUBSCRIBE
Supported: gruu
Event: dialog
Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY
Contact: <sip:caller@example.com;gr=hdg7777ad7aflzig8sf7>
Content-Length: 0
The SUBSCRIBE generates a 200 response (message 11), which is followed by a NOTIFY (message 13 and 14) and its response (message 15 and 16). At some point after message 16 is received, the callee's machine crashes and recovers. It obtains a new IP address, 192.0.2.2. Unaware that it had previously had an active registration, it creates a new one (message 17 below). Notice how the instance ID remains the same, as it persists across reboot cycles:
订阅生成200响应（消息11），随后是通知（消息13和14）及其响应（消息15和16）。在收到消息16后的某个时刻，被叫方的机器崩溃并恢复。它获得一个新的IP地址192.0.2.2。由于不知道以前有一个活动注册，它创建了一个新的注册（下面的消息17）。请注意，实例ID如何保持不变，因为它在重新启动周期中持续存在：
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba
Max-Forwards: 70
From: Callee <sip:callee@example.com>;tag=ha8d777f0
Supported: gruu
To: Callee <sip:callee@example.com>
Call-ID: hf8asxzff8s7f@192.0.2.2
CSeq: 1 REGISTER
<allOneLine>
Contact: <sip:callee@192.0.2.2>
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</allOneLine>
Content-Length: 0
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba
Max-Forwards: 70
From: Callee <sip:callee@example.com>;tag=ha8d777f0
Supported: gruu
To: Callee <sip:callee@example.com>
Call-ID: hf8asxzff8s7f@192.0.2.2
CSeq: 1 REGISTER
<allOneLine>
Contact: <sip:callee@192.0.2.2>
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</allOneLine>
Content-Length: 0
The registrar notices that a different contact, sip:callee@192.0.2.1, is already associated with the same instance ID. It registers the new one too and returns both in the REGISTER response. Both have the same public GRUUs, but the registrar has generated a second temporary GRUU for this AOR and instance ID combination. Both contacts are
注册官注意到另一个联系人sip：callee@192.0.2.1，已与同一实例ID关联。它也将注册新实例ID，并在寄存器响应中返回这两个ID。两者都有相同的公共GRUU，但是注册器已经为这个AOR和实例ID组合生成了第二个临时GRUU。两个联系人都是
included in the REGISTER response, and the temporary GRUU for each is the same -- the most recently created one for the instance ID and AOR. The registrar then generates the following response:
包括在寄存器响应中，每个的临时GRUU都是相同的——最近为实例ID和AOR创建的一个。然后，注册官生成以下响应：
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba
From: Callee <sip:callee@example.com>;tag=ha8d777f0
To: Callee <sip:callee@example.com>;tag=99f8f7
Call-ID: hf8asxzff8s7f@192.0.2.2
CSeq: 1 REGISTER
<allOneLine>
Contact: <sip:callee@192.0.2.2>
;pub-gruu="sip:callee@example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu="sip:tgruu.7hatz6cn-098shfyq193=
ajfux8fyg7ajqqe7@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=3600
</allOneLine>
<allOneLine>
Contact: <sip:callee@192.0.2.1>
;pub-gruu="sip:callee@example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu="sip:tgruu.7hatz6cn-098shfyq193=
ajfux8fyg7ajqqe7@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=400
</allOneLine>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba
From: Callee <sip:callee@example.com>;tag=ha8d777f0
To: Callee <sip:callee@example.com>;tag=99f8f7
Call-ID: hf8asxzff8s7f@192.0.2.2
CSeq: 1 REGISTER
<allOneLine>
Contact: <sip:callee@192.0.2.2>
;pub-gruu="sip:callee@example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu="sip:tgruu.7hatz6cn-098shfyq193=
ajfux8fyg7ajqqe7@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=3600
</allOneLine>
<allOneLine>
Contact: <sip:callee@192.0.2.1>
;pub-gruu="sip:callee@example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu="sip:tgruu.7hatz6cn-098shfyq193=
ajfux8fyg7ajqqe7@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=400
</allOneLine>
Content-Length: 0
There is no need for the UA to remove the stale registered contact; the request targeting rules in Section 6.1 will cause the request to be delivered to the most recent one.
UA无需删除过时的已注册联系人；第6.1节中的请求目标规则将导致将请求交付给最近的请求。
Attacks in SIP networks using GRUUs can be divided into outside attacks (where a third party is trying to attack the system) and inside attacks (where the attacker is a valid participant in the system but is malicious). In addition, there are privacy considerations with using GRUUs.
使用GRUUs的SIP网络中的攻击可分为外部攻击（第三方试图攻击系统）和内部攻击（攻击者是系统中的有效参与者，但具有恶意）。此外，使用GRUUs还需要考虑隐私问题。
It is important for a UA to be assured of the integrity of a GRUU given in a REGISTER response. If the GRUU is tampered with by an attacker, the result could be denial of service (DoS) to the UA. As a result, it is RECOMMENDED that a UA use the SIPS URI scheme in the
UA必须确保寄存器响应中给出的GRUU的完整性。如果GRUU被攻击者篡改，结果可能是UA拒绝服务（DoS）。因此，建议UA在应用程序中使用SIPS URI方案
Request-URI when registering. Proxies and registrars MUST support the SIPS URI and MUST support TLS. This does not represent a change from the requirements in RFC 3261 [1].
注册时请求URI。代理和注册人必须支持SIPS URI，并且必须支持TLS。这并不代表RFC 3261[1]中要求的变更。
The example GRUU construction algorithm in Appendix A.1 makes no attempt to create a GRUU that hides the AOR and instance ID associated with the GRUU. In general, determination of the AOR associated with a GRUU is considered a good property, since it allows for easy tracking of the target of a particular call. Learning the instance ID provides little benefit to an attacker. To register or otherwise impact registrations for the user, an attacker would need to obtain the credentials for the user. Knowing the instance ID is insufficient.
附录A.1中的示例GRUU构造算法没有试图创建隐藏与GRUU关联的AOR和实例ID的GRUU。一般来说，与GRUU关联的AOR的确定被认为是一个良好的特性，因为它允许轻松跟踪特定调用的目标。了解实例ID对攻击者没有什么好处。要注册或以其他方式影响用户的注册，攻击者需要获取用户的凭据。了解实例ID是不够的。
The example GRUU construction algorithm in Appendix A.1 makes no attempt to create a GRUU that prevents users from guessing a GRUU based on knowledge of the AOR and instance ID. A user that is able to do that will be able to direct a new request at a particular instance. However, this specification recommends that service treatment (in particular, screening features) be given to requests that are sent to a GRUU. That treatment will make sure that the GRUU does not provide a back door for attackers to contact a user that has tried to block the attacker.
附录A.1中的示例GRUU构造算法并不试图创建一个GRUU，以防止用户根据AOR和实例ID的知识猜测GRUU。能够这样做的用户将能够将新请求定向到特定实例。但是，本规范建议对发送到GRUU的请求进行服务处理（特别是筛选功能）。这种处理方法将确保GRUU不会为攻击者提供后门，以便他们联系试图阻止攻击者的用户。
As a consequence of this specification, a UA will begin using GRUUs in the dialog forming and target refresh requests and responses it emits. These GRUUs will be passed to another UA (called the correspondent), which then uses them in requests that they emit.
作为该规范的结果，UA将开始在对话框中使用GROUS，并将其发出的刷新请求和响应作为目标。这些Gru将被传递给另一个UA（称为通讯器），后者随后在它们发出的请求中使用它们。
If a malicious correspondent removes the "gr" URI parameter, the request will be routed to the authoritative proxy. If the GRUU had been temporary, removal of the "gr" URI parameter produces a URI that is not recognized as a GRUU and is not equal to any AOR. The request will be rejected. If the GRUU had been public, removing the "gr" URI parameter would have produced the AOR. Therefore, the request is treated like a call to the AOR. Since it is a desired goal to allow users to extract the AOR from the GRUU, this is not an attack, and the call will be handled normally.
如果恶意通讯器删除“gr”URI参数，则请求将路由到权威代理。如果GRUU是临时的，那么删除“gr”URI参数会生成一个URI，该URI不能被识别为GRUU，并且不等于任何AOR。请求将被拒绝。如果GRUU是公共的，删除“gr”URI参数将产生AOR。因此，请求被视为对AOR的调用。由于允许用户从GRUU中提取AOR是一个理想的目标，因此这不是攻击，调用将正常处理。
A malicious user in the system might try to use a GRUU for launching a DoS attack against another SIP UA. To do that, it would wait for a call from that UA, and from it, observe their GRUU. Once the GRUU is obtained, the UA would launch a SIP request to an entity, such as a presence server, which will generate many requests back towards the UA. However, the attacker will use the target's GRUU in the Contact header field of that SUBSCRIBE request. This will cause the traffic
系统中的恶意用户可能试图使用GRUU对另一个SIP UA发起DoS攻击。要做到这一点，它将等待来自UA的电话，并从中观察他们的咕噜声。一旦获得GRUU，UA将向实体（如状态服务器）启动SIP请求，该实体将生成许多返回UA的请求。但是，攻击者将在该订阅请求的联系人标头字段中使用目标的GRUU。这会造成交通堵塞
to be directed towards the target instead. Since the GRUU is globally routable, such traffic is more likely to be delivered to the target than traffic sent to its IP address. This specification helps mitigate this attack by requiring proxies to validate that the GRUU in the Contact of a request matches the authenticated identity of the sender of the request. This check requires the use of an outbound proxy. SIP does not require outbound proxies, and this does leave a potential area of vulnerability. However, in practice, nearly all deployments of SIP utilize an outbound proxy, and therefore this vulnerability is not likely to be a concern.
而是直接指向目标。由于GRUU是全局可路由的，因此与发送到目标IP地址的流量相比，此类流量更有可能发送到目标。此规范通过要求代理验证请求联系人中的GRUU是否与请求发送方的已验证身份相匹配来帮助缓解此攻击。此检查需要使用出站代理。SIP不需要出站代理，这确实留下了一个潜在的漏洞区域。然而，在实践中，几乎所有SIP部署都使用出站代理，因此不太可能担心此漏洞。
RFC 3323 [15] defines mechanisms for privacy. It distinguishes between network-provided privacy and user-provided privacy. In the former, the user requests privacy services from the network by including a Privacy header field in the request. In the latter, the UA follows a basic set of guidelines for construction of its request, so a certain level of privacy is afforded.
RFC 3323[15]定义了隐私机制。它区分了网络提供的隐私和用户提供的隐私。在前者中，用户通过在请求中包括隐私报头字段从网络请求隐私服务。在后者中，UA遵循其请求构造的一组基本准则，因此提供了一定程度的隐私。
The guidelines in Section 4.1 of RFC 3323 [15] for user-provided privacy request that a UA construct its Contact header field with a URI that omits a user part, and utilizes the IP address or hostname of the UA. Such recommendations are in conflict with the rules defined in this specification, which require the usage of a GRUU in the Contact header field.
RFC 3323[15]第4.1节中关于用户提供隐私的指南要求UA使用省略用户部分的URI构造其联系人标头字段，并利用UA的IP地址或主机名。此类建议与本规范中定义的规则相冲突，这些规则要求在Contact header字段中使用GRUU。
However, the temporary GRUUs provided by the registrar can be used in place of the Contact URI format described in RFC 3323 [15]. A user agent would gather the temporary GRUU returned in each REGISTER response, and keep a small number of them cached. When it makes or receives a call, a temporary GRUU is used to populate the Contact header field.
然而，注册官提供的临时GRUs可以用来代替RFC 3323[15]中描述的联系人URI格式。用户代理将收集每个寄存器响应中返回的临时GRUU，并将少量GRUU缓存起来。当它拨打或接听电话时，会使用临时GRUU填充Contact header字段。
A UA can either elect to use the same temporary GRUU in each call, or it can use a different temporary GRUU in each call. The choice depends on the level of privacy desired:
UA可以选择在每次呼叫中使用相同的临时GRUU，也可以在每次呼叫中使用不同的临时GRUU。选择取决于所需的隐私级别：
o A UA utilizing the same temporary GRUU for each call will allow a correspondent, based solely on investigation of the Contact header field, to correlate calls as coming from the same UA. This is also true for the user-provided privacy procedures in RFC 3323 [15], since the IP address or hostname in the Contact URI provides a similar correlator.
o 对于每个呼叫使用相同的临时GRUU的UA将允许通讯员仅基于对Contact header字段的调查来关联来自同一UA的呼叫。RFC 3323[15]中用户提供的隐私程序也是如此，因为联系人URI中的IP地址或主机名提供了类似的相关器。
o A UA utilizing a different temporary GRUU for each call will not allow a correspondent, based solely on investigation of the Contact header field, to correlate calls as coming from the same UA.
o 对每个呼叫使用不同临时GRUU的UA将不允许通讯员仅基于对Contact header字段的调查来关联来自同一UA的呼叫。
o In both cases, absent network-provided privacy, IP address and port information in the Session Description Protocol (SDP) (defined in [10]) will allow a correspondent to correlate calls as coming from the same UA.
o 在这两种情况下，会话描述协议（SDP）（定义见[10]）中缺少网络提供的隐私、IP地址和端口信息将允许通信者关联来自同一UA的呼叫。
o In both cases, if a user makes a call, the correspondent will be able to call back by directing requests towards the GRUU in the Contact header field. Similarly, features such as transfer and digit collection by network application servers (see RFC 4730 [20]), which depend on a Contact with the GRUU property, will also be possible. These kinds of inbound requests will be possible until the registration for that UA lapses. A UA that wishes to invalidate its previous temporary GRUU in order to limit reachability MAY do so by generating a REGISTER refresh with a Call-ID that differs from ones used previously. A UA SHOULD NOT forcefully expire its registration and then re-register in order to invalidate a temporary GRUU; this results in a brief period of unreachability and will often produce excess load on the network. Refreshing with a new Call-ID is more efficient and is meant as the technique for coarse-grained control over the validity of temporary GRUUs. A UA wishing to not be disturbed by a specific call back will need to implement manual or automated call-handling procedures to reject it. This specification does not provide the UA the ability to manually invalidate individual temporary GRUUs. If a UA insists on not receiving any such inbound requests (including ones generated by network applications, such as those used for collecting digits), the UA can place a non-GRUU into the Contact header field. However, this is NOT RECOMMENDED. Usage of a GRUU coupled with automated call rejection features is far superior.
o 在这两种情况下，如果用户进行了呼叫，通讯员将能够通过在Contact header字段中将请求定向到GRUU来回拨。类似地，网络应用服务器的传输和数字收集（参见RFC 4730[20]）等功能也将成为可能，这些功能取决于与GRUU属性的联系。在UA注册失效之前，此类入站请求是可能的。为了限制可达性，希望使其先前的临时GRUU无效的UA可以通过使用不同于先前使用的调用ID生成寄存器刷新来实现。UA不应强制终止其注册，然后重新注册以使临时GRUU无效；这会导致短暂的不可访问性，并且通常会在网络上产生过多负载。使用新的调用ID进行刷新效率更高，这意味着对临时Gru的有效性进行粗粒度控制的技术。希望不受特定回拨干扰的UA需要实施手动或自动回拨处理程序以拒绝回拨。本规范不提供UA手动使单个临时GRUU无效的能力。如果UA坚持不接收任何此类入站请求（包括由网络应用程序生成的请求，例如用于收集数字的请求），UA可以将非GRUU放入Contact header字段。但是，不建议这样做。使用GRUU加上自动呼叫拒绝功能是非常优越的。
o As long as a temporary GRUU is used to populate the Contact header field, a correspondent will not be able to ascertain any information about the AOR or instance ID of the UA by inspection of the Contact header field. However, absent a network-provided privacy service, the IP address in the SDP can be used to determine information about the UA, such as its geographic location and ISP.
o 只要使用临时GRUU填充Contact header字段，通讯员就无法通过检查Contact header字段来确定有关UA的AOR或实例ID的任何信息。然而，如果没有网络提供的隐私服务，SDP中的IP地址可用于确定有关UA的信息，例如其地理位置和ISP。
o In all cases, regardless of whether the UA uses a temporary or public GRUU in the Contact, regardless of whether it utilizes GRUU at all, and regardless of whether it invokes a network-provided privacy service, a correspondent will be able to determine the SIP
o 在所有情况下，无论UA是否在联系人中使用临时或公共GRUU，无论其是否使用GRUU，也无论其是否调用网络提供的隐私服务，通讯员都将能够确定SIP
service provider of the UA.
UA的服务提供商。
This specification defines two new Contact header field parameters, one SIP URI parameter, and a SIP option tag.
此规范定义了两个新的联系人标头字段参数、一个SIP URI参数和一个SIP选项标记。
This specification defines two new header field parameters, as per the registry created by RFC 3968 [8]. The required information is as follows:
根据RFC 3968[8]创建的注册表，本规范定义了两个新的标题字段参数。所需资料如下：
Header field in which the parameter can appear: Contact Name of the Parameter: pub-gruu Predefined Values: none RFC Reference: RFC 5627
参数可出现的标题字段：参数的联系人名称：pub gruu预定义值：无RFC参考：RFC 5627
Header field in which the parameter can appear: Contact Name of the Parameter: temp-gruu Predefined Values: none RFC Reference: RFC 5627
可显示参数的标题字段：参数的联系人名称：temp gruu预定义值：无RFC参考：RFC 5627
This specification defines one new SIP URI parameter, as per the registry created by RFC 3969 [9].
根据RFC 3969[9]创建的注册表，本规范定义了一个新的SIP URI参数。
Name of the Parameter: gr Predefined Values: none RFC Reference: RFC 5627
参数名称：gr预定义值：无RFC参考：RFC 5627
This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of RFC 3261 [1].
根据RFC 3261[1]第27.1节中的指南，本规范注册了一个新的SIP选项标签。
Name: gruu
姓名：格鲁
Description: This option tag is used to identify the Globally Routable User Agent URI (GRUU) extension. When used in a Supported header, it indicates that a User Agent understands the extension. When used in a Require header field of a REGISTER request, it indicates that the registrar is not expected to process the registration unless it supports the GRUU extension.
描述：此选项标记用于标识全局可路由用户代理URI（GRUU）扩展。在受支持的标头中使用时，它表示用户代理理解扩展。当在注册请求的Require头字段中使用时，它表示除非注册器支持GRUU扩展，否则注册器不会处理注册。
The author would like to thank Eric Rescorla, Robert Sparks, Rohan Mahy, Paul Kyzivat, Alan Johnston, Ya-Ching Tan, Dale Worley, Jeroen van Bemmel, Vijay Gurbani, Andrew Allen, Alan Hawrylyshen, Francois Audet, Fredrik Thulin, Dean Willis, David Hancock, Keith Drage, and Cullen Jennings for their comments and contributions to this work. Eric Rescorla provided the text for the introduction and the GRUU construction algorithm in the appendix.
作者要感谢Eric Rescorla、Robert Sparks、Rohan Mahy、Paul Kyzivat、Alan Johnston、Ya Ching Tan、Dale Worley、Jeroen van Bemmel、Vijay Gurbani、Andrew Allen、Alan Hawrylyshen、Francois Audet、Fredrik Thulin、Dean Willis、David Hancock、Keith Drage和Cullen Jennings对本书的评论和贡献。Eric Rescorla在附录中提供了介绍文本和GRUU构造算法。
[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] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[2] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[3] Willis，D.和B.Hoeneisen，“用于注册非相邻联系人的会话启动协议（SIP）扩展头字段”，RFC 3327，2002年12月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[6] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[6] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[7] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[7] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[8] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[8] Camarillo，G.，“会话启动协议（SIP）的Internet分配号码管理局（IANA）头字段参数注册表”，BCP 98，RFC 3968，2004年12月。
[9] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[9] Camarillo，G.，“会话启动协议（SIP）的Internet分配号码管理局（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，2004年12月。
[10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[10] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[11] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[11] Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[12] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[13] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[13] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[14] Jennings, C., Ed. and R. Mahy, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[14] Jennings，C.，Ed.和R.Mahy，Ed.，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
[15] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[15] Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[16] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[16] Rosenberg，J.，Schulzrinne，H.，和R.Mahy，“会话启动协议（SIP）的邀请启动对话事件包”，RFC 42352005年11月。
[17] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[17] Sparks，R.，Hawrylyshen，A.，Johnston，A.，Rosenberg，J.，和H.Schulzrinne，“会话启动协议（SIP）酷刑测试消息”，RFC 4475，2006年5月。
[18] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002.
[18] Schulzrinne，H.，“会话启动协议（SIP）服务器的动态主机配置协议（DHCP-for-IPv4）选项”，RFC 3361，2002年8月。
[19] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, June 2009.
[19] Sparks，R.，Johnston，A.，和D.Petrie，“会话发起协议（SIP）呼叫控制-传输”，BCP 149，RFC 5589，2009年6月。
[20] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006.
[20] Burger，E.和M.Dolly，“按键刺激（KPML）的会话启动协议（SIP）事件包”，RFC 4730，2006年11月。
[21] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[21] Mahy，R.和D.Petrie，“会话启动协议（SIP）”加入“头”，RFC 3911，2004年10月。
[22] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[22] Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 38912004年9月的“头”。
[23] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003.
[23] Willis，D.和B.Hoeneisen，“注册期间服务路由发现的会话启动协议（SIP）扩展头字段”，RFC 3608，2003年10月。
[24] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[24] Rosenberg，J.，“用于注册的会话启动协议（SIP）事件包”，RFC 36802004年3月。
[25] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003.
[25] Camarillo，G.“压缩会话启动协议（SIP）”，RFC 3486，2003年2月。
[26] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[26] Burger，E.，Van Dyke，J.，和A.Spitzer，“具有SIP的基本网络媒体服务”，RFC 42402005年12月。
[27] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, April 2006.
[27] Jennings，C.，Audet，F.，和J.Elwell，“语音邮件和交互式语音应答（IVR）等应用程序的会话启动协议（SIP）URI”，RFC 4458，2006年4月。
[28] Kyzivat, P., "Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)", RFC 5628, October 2009.
[28] Kyzivat，P.，“会话启动协议（SIP）全局可路由用户代理URI（GROUS）的注册事件包扩展”，RFC 56282009年10月。
[29] Rosenberg, J., van Elburg, J., Holmberg, C., Audet, F., and S. Schubert, Ed., "Delivery of Request-URI Targets to User Agents", Work in Progress, June 2009.
[29] Rosenberg，J.，van Elburg，J.，Holmberg，C.，Audet，F.，和S.Schubert，Ed.，“向用户代理交付请求URI目标”，正在进行的工作，2009年6月。
The mechanism for constructing a GRUU is not subject to specification. This appendix provides an example that can be used by a registrar to construct a public and a temporary GRUU. Of course, others are permitted, as long as they meet the constraints defined for a GRUU.
构造GRUU的机制不受规范约束。本附录提供了一个示例，注册官可以使用该示例构建公共GRUU和临时GRUU。当然，只要满足为GRUU定义的约束，就允许使用其他约束。
The most basic approach for constructing a public GRUU is to take the AOR and place the actual value of the instance ID into the contents of the "gr" URI parameter.
构造公共GRUU的最基本方法是采用AOR并将实例ID的实际值放入“gr”URI参数的内容中。
This specification requires a registrar to create a new temporary GRUU on each registration refresh. If a registration is very long lived, this can quickly result in hundreds or even thousands of temporary GRUUs being created and allocated to a UA. Consequently, it is important to have an algorithm for constructing temporary GRUUs that does not require additional storage that grows in size with the number of temporary GRUUs. The following algorithm meets this goal.
此规范要求注册器在每次注册刷新时创建一个新的临时GRUU。如果注册时间很长，这可能会很快导致数百甚至数千个临时GRUU被创建并分配给UA。因此，重要的是要有一个构建临时GRUs的算法，该算法不需要随着临时GRUs数量的增加而增加的额外存储。下面的算法满足这一目标。
The registrar maintains a counter, I. This counter is 48 bits and is initialized to zero. The counter is persistently stored, using a backend database or other similar technique. When the registrar creates the first temporary GRUU for a particular AOR and instance ID, the registrar notes the current value of the counter, I_i, and increments the counter in the database. The registrar then maps I_i to the AOR and instance ID using the database, a persistent hashmap or similar technology. If the registration expires such that there are no longer any contacts with that particular instance ID bound to the GRUU, the registrar removes the mapping. Similarly, if the temporary GRUUs are invalidated due to a change in Call-ID, the registrar removes the current mapping from I_i to the AOR and instance ID, notes the current value of the counter I_j, and stores a mapping from I_j to the AOR and instance ID. Based on these rules, the hashmap will contain a single mapping for each AOR and instance ID for which there is a currently valid registration.
注册器维护一个计数器，即，该计数器为48位，并初始化为零。计数器使用后端数据库或其他类似技术进行持久存储。当注册器为特定AOR和实例ID创建第一个临时GRUU时，注册器会记录计数器的当前值I_I，并增加数据库中的计数器。然后，注册器使用数据库、持久hashmap或类似技术将I_I映射到AOR和实例ID。如果注册过期，因此不再有任何与绑定到GRUU的特定实例ID相关的联系人，则注册器将删除映射。类似地，如果临时Gru由于调用ID的更改而无效，则注册器移除从I_I到AOR和实例ID的当前映射，记录计数器I_j的当前值，并存储从I_j到AOR和实例ID的映射。基于这些规则，hashmap将为当前存在有效注册的每个AOR和实例ID包含一个映射。
The usage of a counter in a 48-bit space with sequential assignment allows for a compact representation of the hashmap key, which is important for generating GRUUs of reasonable size. The counter starts at zero when the system is initialized. Persistent and reliable storage of the counter is required to avoid misrouting of a GRUU to the wrong AOR and instance ID. Similarly, persistent storage of the hashmap is required, even through proxy and registrar
在具有顺序分配的48位空间中使用计数器允许hashmap键的紧凑表示，这对于生成合理大小的GROU非常重要。系统初始化时，计数器从零开始。为了避免GRUU错误地路由到错误的AOR和实例ID，需要对计数器进行持久和可靠的存储。同样，需要对hashmap进行持久存储，即使是通过代理和注册器
restarts. If the hashmap is reset, all previous temporary GRUUs become invalidated. This might cause dialogs in progress to fail, or future requests towards a temporary GRUU to fail when they normally would not. The same hashmap needs to be accessible by all proxies and registrars that can field requests for a particular AOR and instance ID.
重新启动。如果hashmap被重置，所有以前的临时GRUU都将失效。这可能会导致正在进行的对话框失败，或者将来对临时GRUU的请求在通常不会失败的情况下失败。所有代理和注册器都需要访问相同的hashmap，这些代理和注册器可以对特定AOR和实例ID的请求进行字段化。
The registrar maintains a pair of local symmetric keys K_e and K_a. These are regenerated every time the counter is reset. When the counter rolls over or is reset, the registrar remembers the old values of K_e and K_a for a time. Like the hashmap itself, these keys need to be shared across all proxy and registrars that can service requests for a particular AOR and instance ID.
注册器维护一对本地对称密钥K_e和K_a。每次计数器复位时，这些都会重新生成。当计数器翻转或重置时，注册器会记住K_e和K_a的旧值一段时间。与hashmap本身一样，这些密钥需要在所有能够为特定AOR和实例ID的请求提供服务的代理和注册器之间共享。
To generate a new temporary GRUU, the registrar generates a random 80-bit distinguisher value D. It then computes:
为了生成新的临时GRUU，注册器生成一个随机的80位区分器值D。然后计算：
M = D || I_i
E = AES-ECB-Encrypt(K_e, M)
A = HMAC-SHA256-80(K_a, E)
M = D || I_i
E = AES-ECB-Encrypt(K_e, M)
A = HMAC-SHA256-80(K_a, E)
Temp-Gruu-userpart = "tgruu." || base64(E) || base64(A)
Temp-Gruu-userpart = "tgruu." || base64(E) || base64(A)
where || denotes concatenation, and AES-ECB-Encrypt represents AES encryption in electronic codebook mode. M will be 128 bits long, producing a value of E that is 128 bits and A that is 80 bits. This produces a user part which has 42 characters.
其中| |表示串联，AES ECB Encrypt表示电子码本模式下的AES加密。M将是128位长，产生128位的E值和80位的a值。这将生成一个具有42个字符的用户部件。
When a proxy receives a request whose user part begins with "tgruu.", it extracts the remaining portion, and splits it into 22 characters (E') and the remaining 14 characters (A'). It then computes A and E by performing a base64 decode of A' and E' respectively. Next, it computes:
当代理收到一个用户部分以“tgruu”开头的请求时，它提取剩余部分，并将其拆分为22个字符（E'）和剩余14个字符（a'）。然后，它通过分别对A'和E'执行base64解码来计算A和E。接下来，它计算：
Ac = HMAC-SHA256-80(K_a, E)
Ac=HMAC-SHA256-80（K_a，E）
If the counter has rolled over or reset, this computation is performed with the current and previous K_a. If the Ac value(s) that are computed do not match the value of A extracted from the GRUU, the GRUU is rejected as invalid. Next, the proxy computes:
如果计数器已翻转或重置，则使用当前和以前的K_a执行此计算。如果计算的Ac值与从GRUU提取的值不匹配，GRUU将被视为无效而拒绝。接下来，代理计算：
M = AES-ECB-Decrypt(K_e, E)
M=AES ECB解密（K_e，e）
If the counter has rolled over, this computation is done using the value of K_e that goes with the value of K_a, which produced a valid Ac in the previous HMAC validation. The leading 80 bits (the distinguisher D) are discarded, leaving an index I_i in the hashmap. This index is looked up. If it exists, the proxy now has the AOR and
如果计数器已翻转，则使用K_e的值与K_a的值进行计算，该值在之前的HMAC验证中产生了有效的Ac。前导的80位（区分符D）被丢弃，在hashmap中留下索引I_I。该索引已被查找。如果存在，代理现在拥有AOR和
instance ID corresponding to this temporary GRUU. If there is nothing in the hashmap for the key I_i, the GRUU is no longer valid and the request is rejected.
与此临时GRUU对应的实例ID。如果hashmap中没有键I_I的任何内容，则GRU不再有效，请求将被拒绝。
The usage of a 48-bit counter allows for the registrar to have as many as a billion AORs, with 10 instances per AOR, and cycle through 10,000 Call-ID changes for each instance through the duration of a single registration. These numbers reflect the average; the system works fine if a particular AOR has more than 10 instances or a particular instance cycles through more than 10,000 Call-IDs in its registration, as long as the average meets these constraints.
48位计数器的使用允许注册器拥有多达10亿个AOR，每个AOR有10个实例，并在单个注册期间循环每个实例的10000个调用ID更改。这些数字反映了平均水平；如果某个特定AOR有10个以上的实例，或者某个特定实例在其注册中循环使用了10000多个调用ID，那么只要平均值满足这些约束，系统就可以正常工作。
The GRUU specification works properly based on logic implemented at the user agents and in the authoritative proxies on both sides of a call. Consequently, it is possible to construct network deployments in which GRUUs will not work properly.
GRUU规范基于在用户代理和调用双方的权威代理中实现的逻辑正常工作。因此，可以构建GRUUs无法正常工作的网络部署。
One important assumption made by the GRUU mechanism is that, if a request passes through any proxies in the originating domain prior to visiting the terminating domain, one of those proxies will be the authoritative proxy for the User Agent Client (UAC). Administrators of SIP networks will need to make sure that this property is retained. There are several ways it can be accomplished:
GRUU机制做出的一个重要假设是，如果请求在访问终止域之前通过发起域中的任何代理，那么这些代理之一将是用户代理客户端（UAC）的权威代理。SIP网络的管理员需要确保保留此属性。有几种方法可以实现：
1. If the user agents support the service-route mechanism [23], the registrar can implement it and return a service route that points to the authoritative proxy. This will cause requests originated by the user agent to pass through the authoritative proxy.
1. 如果用户代理支持服务路由机制[23]，则注册器可以实现该机制并返回指向权威代理的服务路由。这将导致用户代理发起的请求通过权威代理。
2. The user agents can be configured to never use an outbound proxy, and send requests directly to the domain of the terminating party. This configuration is not practical in many use cases, but it is a solution to this requirement.
2. 用户代理可以配置为从不使用出站代理，并将请求直接发送到终止方的域。这种配置在许多用例中都不实用，但它是这一需求的解决方案。
3. The user agents can be configured with an outbound proxy in the same domain as the authoritative proxy, and this outbound proxy forwards requests to the authoritative proxy by default. This works very well in cases where the clients are not roaming; in such cases, the outbound proxy in a visited network may be discovered dynamically through DHCP [18].
3. 用户代理可以在与权威代理相同的域中配置出站代理，默认情况下，此出站代理将请求转发给权威代理。这在客户端不漫游的情况下非常有效；在这种情况下，访问网络中的出站代理可以通过DHCP动态发现[18]。
4. In cases where the client discovers a local outbound proxy via a mechanism such as DHCP, and is not implementing the service route mechanism, the UA can be configured to automatically add an additional Route header field after the outbound proxy, which points to a proxy in the home network. This has the same net
4. 如果客户端通过DHCP等机制发现本地出站代理，并且未实现服务路由机制，则UA可以配置为在出站代理之后自动添加额外的路由头字段，该字段指向家庭网络中的代理。这张网是一样的
effect of the service route mechanism, but is accomplished through static configuration.
服务路由机制的影响，但通过静态配置实现。
Author's Address
作者地址
Jonathan Rosenberg Cisco Systems Edison, NJ US
Jonathan Rosenberg思科系统爱迪生，美国新泽西州
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net