Network Working Group P. Kyzivat
Request for Comments: 5628 Cisco Systems, Inc.
Category: Standards Track October 2009
Network Working Group P. Kyzivat
Request for Comments: 5628 Cisco Systems, Inc.
Category: Standards Track October 2009
Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)
会话启动协议（SIP）全局可路由用户代理URI（GROUS）的注册事件包扩展
Abstract
摘要
RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact.
RFC3680为注册状态定义会话启动协议（SIP）事件包。此包允许观察者了解SIP注册器存储的信息，包括其注册联系人。
However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI (GRUU), defined in RFC 5627, is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar.
但是，注册联系人经常无法联系，因此对观察者没有用处。RFC 5627中定义的全局可路由用户代理URI（GRUU）是能够到达特定联系人的URI。但是，此URI不包括在RFC 3680中定义的文档格式中。本规范定义了注册事件包的扩展，以包括注册器分配的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 outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . 4
5. Notifier Generation of NOTIFY Requests . . . . . . . . . . . . 4
6. Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 5
6.1. Managing Temporary GRUU Lifetime . . . . . . . . . . . . . 5
7. Sample reginfo Document . . . . . . . . . . . . . . . . . . . 7
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Example: Welcome Notice . . . . . . . . . . . . . . . . . 8
8.2. Example: Implicit Registration . . . . . . . . . . . . . . 8
9. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 12
10.2. XML Schema Registration . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . 4
5. Notifier Generation of NOTIFY Requests . . . . . . . . . . . . 4
6. Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 5
6.1. Managing Temporary GRUU Lifetime . . . . . . . . . . . . . 5
7. Sample reginfo Document . . . . . . . . . . . . . . . . . . . 7
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Example: Welcome Notice . . . . . . . . . . . . . . . . . 8
8.2. Example: Implicit Registration . . . . . . . . . . . . . . 8
9. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 12
10.2. XML Schema Registration . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . . 14
RFC 3680 [2] defines a Session Initiation Protocol (SIP) [5] event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including the registered contacts.
RFC 3680[2]为注册状态定义会话启动协议（SIP）[5]事件包。这个包允许观察者了解SIP注册器存储的信息，包括注册的联系人。
However, a registered contact is frequently unreachable from hosts outside of the domain of the User Agent (UA). It is commonly a private address, or, when it is a public address, access to it may be blocked by firewalls.
但是，注册联系人通常无法从用户代理（UA）域之外的主机访问。它通常是一个私人地址，或者，当它是一个公共地址时，对它的访问可能会被防火墙阻止。
The Globally Routable User Agent URI (GRUU), defined in RFC 5627 [3], is a URI that reaches a particular UA instance, but is reachable by any host on the Internet. GRUUs assigned by the registrar represent additional registration state. However, GRUUs assigned by the registrar are not included in the notifications provided by RFC 3680. For many applications of the registration event package, a GRUU is needed, and not the registered contact.
RFC 5627[3]中定义的全局可路由用户代理URI（GRUU）是到达特定UA实例的URI，但可由Internet上的任何主机访问。注册官指定的GRUU代表附加注册州。但是，注册官分配的GRUU不包括在RFC 3680提供的通知中。对于注册事件包的许多应用程序，需要GRUU，而不是注册联系人。
For example, the Welcome Notices example in [2] will only operate correctly if the contact address in the registration event notification is reachable by the sender of the welcome notice. When the registering device is using the GRUU extension, it is likely that the registered contact address will not be globally addressable, and a GRUU should be used as the target address for the MESSAGE.
例如，[2]中的欢迎通知示例仅在欢迎通知的发件人可以访问注册事件通知中的联系人地址时才能正常运行。当注册设备使用GRUU扩展时，注册的联系人地址可能无法全局寻址，GRUU应该用作消息的目标地址。
Another case where this feature may be helpful is within the Third Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS). IMS employs a technique where a REGISTER of a contact address to one Address of Record (AOR) causes the implicit registration of the same contact to other associated AORs. If GRUUs are requested and obtained as part of the registration request, then additional GRUUs will also be needed for the implicit registrations. While assigning the additional GRUUs is straightforward, informing the registering UA of them is not. In IMS, UAs typically subscribe to the registration event, and subscriptions to the registration event for an AOR result in notifications, each containing the registration state of all the associated AORs. The proposed extension provides a way to easily deliver the GRUUs for the associated AORs.
此功能可能有用的另一个情况是在第三代合作伙伴项目（3GPP）IP多媒体子系统（IMS）中。IMS采用一种技术，其中将联系人地址注册到一个记录地址（AOR）会导致将同一联系人隐式注册到其他关联的AOR。如果作为注册请求的一部分请求并获得GRUs，那么隐式注册也需要额外的GRUs。虽然分配额外的Gru很简单，但向注册UA通知这些Gru并不简单。在IMS中，UAs通常订阅注册事件，订阅AOR的注册事件会产生通知，每个通知都包含所有关联AOR的注册状态。建议的扩展提供了一种为相关AOR轻松交付GROU的方法。
As specified in RFC 5627 [3], temporary GRUUs are invalidated when contact address bindings for the corresponding AOR and instance ID are not refreshed, or when a registration to the AOR and instance ID is performed with a new Call-ID. A UA cannot always determine with certainty which temporary GRUUs are valid based solely on the response to the REGISTER requests it has issued, or from
如RFC 5627[3]中所述，当对应AOR和实例ID的联系人地址绑定未刷新时，临时GRU将无效，或者，当使用新的Call-ID对AOR和实例ID进行注册时。UA不能总是仅根据对其发出的注册请求的响应或从中确定哪个临时GRUs是有效的
notifications according to RFC 3680 [2]. The extension defined in this document provides sufficient information for a UA to determine which temporary GRUUs are valid.
根据RFC 3680[2]的通知。本文档中定义的扩展为UA提供了足够的信息，以确定哪些临时GRUs是有效的。
The registration event package has provisions for including extension elements within the <contact> element. This document defines new elements that may be used in that context to deliver the public and temporary GRUUs corresponding to the contact.
注册事件包具有在<contact>元素中包含扩展元素的规定。本文档定义了可在该上下文中用于交付与联系人对应的公共和临时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. [1]
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。[1]
Two new elements (<pub-gruu> and <temp-gruu>) are defined, each of which contains a GRUU. The <temp-gruu> element also identifies the oldest temporary GRUU that is currently valid.
定义了两个新元素（<pub gru>和<temp gru>），每个元素都包含一个gru。元素还标识当前有效的最旧临时gruu。
These optional elements may be included within the body of a NOTIFY for the registration event package when GRUUs are associated with the contact. The contact URI and the GRUUs are then all available to the watcher.
当Gru与联系人关联时，这些可选元素可以包含在注册事件包的NOTIFY主体中。然后，联系人URI和Gru都可供观察者使用。
Unchanged from RFC 3680 [2].
与RFC 3680[2]相同。
A notifier for the registration event package [2] SHOULD include the <pub-gruu> element when a contact has an instance ID and a public GRUU is associated with the combination of the AOR and the instance ID. When present, the <pub-gruu> element MUST be positioned as a child of the <contact> element.
当联系人具有实例ID且公共gruu与AOR和实例ID的组合相关联时，注册事件包[2]的通知程序应包含<pub gruu>元素。当存在<pub gruu>元素时，该元素必须定位为<contact>元素的子元素。
A notifier for the registration event package [2] MAY include the <temp-gruu> element when a contact has an instance ID and a temporary GRUU is associated with the combination of the AOR and the instance ID. This element SHOULD be included if the subscriber is also authorized to register to the AOR. This element SHOULD NOT be included if the subscriber is not authorized to register to the AOR, unless there is an explicitly configured policy directing that it be included. When present, the <temp-gruu> element MUST be positioned as a child of the <contact> element.
当联系人具有实例ID且临时gruu与AOR和实例ID的组合相关联时，注册事件包[2]的通知程序可包括<temp gruu>元素。如果订户也被授权注册到AOR，则应包括此元素。如果订户未被授权注册到AOR，则不应包括此元素，除非有明确配置的策略指示将其包括在内。存在时，<temp gruu>元素必须定位为<contact>元素的子元素。
Note that it is possible for multiple registered contacts to share the same instance ID. In such a case, each <contact> element will have child <pub-gruu> and <temp-gruu> elements, which are identical to the corresponding child elements in those other <contact> elements that share the same instance ID. Since a particular contact cannot be associated with more than one instance ID, a <contact> element will never have more than one <pub-gruu> and one <temp-gruu> child element.
请注意，多个已注册联系人可能共享同一实例ID。在这种情况下，每个<contact>元素将具有子<pub gru>和<temp gru>元素，与共享相同实例ID的其他<contact>元素中的相应子元素相同。由于特定联系人不能与多个实例ID关联，因此<contact>元素将永远不会有多个<pub gru>和一个<temp gru>子元素。
If the notifier includes the <pub-gruu> element, it MUST populate the element with the public GRUU that is associated with the instance ID and AOR of the registered contact.
如果通知程序包含<pub gru>元素，则必须使用与已注册联系人的实例ID和AOR关联的公共GRU填充该元素。
If the notifier includes the <temp-gruu> element, it MUST populate the element with the most recently assigned temporary GRUU that is associated with the instance ID and AOR of the registered contact. It MUST also populate the element with a "cseq" attribute corresponding to the first (oldest) currently active temporary GRUU that is associated with the instance ID and AOR of the registered contact. The value of the "cseq" attribute is set to the value of the CSeq header field of the REGISTER request that caused that first temporary GRUU to be assigned.
如果通知程序包含<temp gru>元素，则必须使用最近分配的临时gru填充该元素，该临时gru与已注册联系人的实例ID和AOR关联。它还必须使用“cseq”属性填充元素，该属性对应于当前活动的第一个（最早的）临时GRUU，该GRUU与已注册联系人的实例ID和AOR关联。“cseq”属性的值设置为导致分配第一个临时GRUU的寄存器请求的cseq头字段的值。
When a subscriber receives a registration event notification with a <contact> containing a <pub-gruu>, it MAY associate the public GRUU with the corresponding AOR and instance ID. Any previously received public GRUU for the same AOR and instance ID MUST be discarded. (It will no longer function.)
当订阅者收到包含<pub gru>的<contact>的注册事件通知时，它可能会将公共gru与相应的AOR和实例ID相关联。必须丢弃以前收到的相同AOR和实例ID的任何公共gru。（它将不再工作。）
When a subscriber receives a registration event notification with a <contact> containing a <temp-gruu>, it MAY associate the temporary GRUU, together with the "callid" and "cseq" attributes, with the corresponding AOR and instance ID.
当订阅者接收到包含<temp gru>的<contact>的注册事件通知时，它可以将临时gru以及“callid”和“cseq”属性与相应的AOR和实例ID相关联。
Subscribers that are unaware of this extension will, as required by [2], ignore the <pub-gruu> and <temp-gruu> elements.
根据[2]的要求，不知道此扩展的订阅者将忽略<pub gru>和<temp gru>元素。
Section 4.2 of RFC 5627 [3] gives guidance for developers of UAs on how to ensure that only valid temporary GRUUs are retained and used by the UA. A UA cannot always determine with certainty which temporary GRUUs are valid based solely on the information contained in responses to the REGISTER requests it has issued or from the information contained in notifications that conform solely to RFC 3680 [2]. The extension defined in this document provides sufficient
RFC 5627[3]的第4.2节为UAs的开发者提供了如何确保UA只保留和使用有效的临时GRU的指导。UA不能总是仅根据其发出的注册请求响应中包含的信息或仅符合RFC 3680[2]的通知中包含的信息确定哪个临时GRUs有效。本文档中定义的扩展提供了足够的
added information for a UA to determine which temporary GRUUs are valid. The extension to RFC 3680 defined in this document provides added information to help with that process. The following are steps that the UA MAY take to ensure it only retains valid GRUUs:
为UA添加了信息，以确定哪些临时GRUU是有效的。本文档中定义的RFC 3680扩展提供了附加信息，以帮助完成该过程。以下是UA可能采取的步骤，以确保其仅保留有效的GRUU：
o The UA should subscribe to the registration event package for the AOR it is registering.
o UA应为其正在注册的AOR订阅注册事件包。
o When a UA receives a 2xx response to a REGISTER request, it may extract and retain temporary GRUUs from the response for future use, as long as they remain valid. Appropriate GRUUs to retain are those corresponding to the contact address and instance ID it has registered. (Typically, the UA will register only one contact address, and so receive at most one temporary GRUU.)
o 当UA收到对注册请求的2xx响应时，它可以从响应中提取并保留临时GRUU，以备将来使用，只要它们仍然有效。要保留的适当GRUs是与它已注册的联系人地址和实例ID相对应的GRUs。（通常，UA只注册一个联系地址，因此最多接收一个临时GRUU。）
o The UA may add the temporary GRUU to the set of valid temporary GRUUs associated with the AOR. (Note, in this case AOR is the To-address of the REGISTER request.) To aid in tracking validity, the UA should also associate a "callid" attribute and "cseq" attribute with the temporary GRUU, with values obtained respectively from the Call-ID and CSeq values of the REGISTER response containing the temporary GRUU.
o UA可以将临时GRUU添加到与AOR关联的有效临时GRUU集合中。（注意，在这种情况下，AOR是寄存器请求的To地址。）为了帮助跟踪有效性，UA还应将“callid”属性和“cseq”属性与临时GRUU关联，并分别从包含临时GRUU的寄存器响应的调用ID和cseq值中获得值。
o If the UA receives a registration event notification with an AOR (that it supports) and a <contact>, for a contact address and instance ID (that it has registered and that contains a <temp-gruu>), it may update its set of valid temporary GRUUs associated with the AOR, as follows:
o 如果UA收到带有AOR（其支持）和<contact>的注册事件通知，对于联系人地址和实例ID（其已注册且包含<temp gru>），UA可能会更新其与AOR关联的有效临时GRU集，如下所示：
* It may add the temporary GRUU to the set. To aid in tracking validity, the UA should associate the "callid" and "cseq" attributes of the <contact> with the GRUU in the set.
* 它可以将临时GRUU添加到集合中。为了帮助跟踪有效性，UA应将<contact>的“callid”和“cseq”属性与集合中的GRUU相关联。
* It should remove any temporary GRUUs with a "callid" attribute value different from that in the value of the "callid" attribute of the <contact>, or with a "cseq" attribute with value less than the value of the "first-cseq" attribute of the <temp-gruu>.
* 它应该删除任何具有与<contact>的“callid”属性值不同的“callid”属性值的临时GRU，或者具有小于<temp gru>的“first cseq”属性值的“cseq”属性的临时GRU。
o If the UA receives a registration event notification with an AOR that it supports, and there are no <contact> entries for its instance ID, then it should discard all the temporary GRUUs it has saved for that AOR.
o 如果UA收到其支持的AOR的注册事件通知，并且其实例ID没有<contact>条目，那么它应该放弃为该AOR保存的所有临时GRUU。
Note: This example and others in the following section are indented for readability by the addition of a fixed amount of whitespace to the beginning of each line. This whitespace is not part of the example. The conventions of [7] are used to describe representation of long message lines.
注意：为了便于阅读，此示例和下一节中的其他示例通过在每行开头添加固定数量的空白来缩进。此空白不是示例的一部分。[7]中的约定用于描述长消息行的表示。
The following is an example registration information document that includes the new element:
以下是包含新元素的注册信息文档示例：
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:gr="urn:ietf:params:xml:ns:gruuinfo"
version="0" state="full">
<registration aor="sip:user@example.com" id="as9"
state="active">
<contact id="76" state="active" event="registered"
duration-registered="36001" expires="3599"
callid="1j9FpLxk3uxtm8tn@192.0.2.1" cseq="54321"
q="0.8">
<uri>sip:user@192.0.2.1</uri>
<allOneLine>
<unknown-param name="+sip.instance">
"<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</unknown-param>
</allOneLine>
<allOneLine>
<gr:pub-gruu uri="sip:user@example.com
;gr=hha9s8d-999a"/>
</allOneLine>
<allOneLine>
<gr:temp-gruu uri="sip:8ffkas08af7fasklzi9@example.com
;gr" first-cseq="54301"/>
</allOneLine>
</contact>
</registration>
</reginfo>
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:gr="urn:ietf:params:xml:ns:gruuinfo"
version="0" state="full">
<registration aor="sip:user@example.com" id="as9"
state="active">
<contact id="76" state="active" event="registered"
duration-registered="36001" expires="3599"
callid="1j9FpLxk3uxtm8tn@192.0.2.1" cseq="54321"
q="0.8">
<uri>sip:user@192.0.2.1</uri>
<allOneLine>
<unknown-param name="+sip.instance">
"<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</unknown-param>
</allOneLine>
<allOneLine>
<gr:pub-gruu uri="sip:user@example.com
;gr=hha9s8d-999a"/>
</allOneLine>
<allOneLine>
<gr:temp-gruu uri="sip:8ffkas08af7fasklzi9@example.com
;gr" first-cseq="54301"/>
</allOneLine>
</contact>
</registration>
</reginfo>
Note: In the following examples, the SIP messages have been simplified, removing headers that are not pertinent to the example.
注意：在以下示例中，SIP消息已被简化，删除了与示例无关的头。
When the value of the Content-Length header field is "...", this means that the value should be the computed length of the body.
当内容长度标题字段的值为“…”时，这意味着该值应为正文的计算长度。
Consider the Welcome Notices example in [2]. When the application server receives a notification of a new registration containing the reginfo shown in Section 7, it should address messages using the contained public GRUU as follows:
考虑在[ 2 ]中的欢迎通知示例。当应用程序服务器收到包含第7节所示reginfo的新注册通知时，它应该使用包含的公共GRUU对消息进行寻址，如下所示：
MESSAGE sip:user@example.com;gr=hha9s8d-999a SIP/2.0
To: <sip:user@example.com>
From: "SIPland Notifier" <sip:notifier@example.com>;tag=7xy8
Content-Type: text/plain
Content-Length: ...
MESSAGE sip:user@example.com;gr=hha9s8d-999a SIP/2.0
To: <sip:user@example.com>
From: "SIPland Notifier" <sip:notifier@example.com>;tag=7xy8
Content-Type: text/plain
Content-Length: ...
Welcome to SIPland! Blah, blah, blah.
欢迎来到西普兰！废话，废话，废话。
In a 3GPP IMS setting, a UA may send a single register message, requesting assignment of GRUUs, as follows:
在3GPP IMS设置中，UA可以发送单个寄存器消息，请求分配gruu，如下所示：
REGISTER sip:example.net SIP/2.0
From: <sip:user_aor_1@example.net>;tag=5ab4
To: <sip:user_aor_1@example.net>
Call-ID: faif9a@ua.example.com
CSeq: 23001 REGISTER
Contact: <sip:ua.example.com>
;expires=3600
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Supported: path, gruu
Content-Length: 0
REGISTER sip:example.net SIP/2.0
From: <sip:user_aor_1@example.net>;tag=5ab4
To: <sip:user_aor_1@example.net>
Call-ID: faif9a@ua.example.com
CSeq: 23001 REGISTER
Contact: <sip:ua.example.com>
;expires=3600
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Supported: path, gruu
Content-Length: 0
The response reports success of the registration and returns the GRUUs assigned for the combination of AOR, instance ID, and Contact. It also indicates (via the P-Associated-URI header [6]) that there are two other associated AORs that may have been implicitly registered using the same contact. Each of those implicitly registered AORs will have unique GRUUs assigned. The REGISTER response will not include those GRUUs; it will only include the GRUUs for the AOR and instance ID explicitly included in the registration.
响应报告注册成功，并返回为AOR、实例ID和联系人组合分配的GRUS。它还指示（通过P-Associated-URI头[6]）可能已经使用同一联系人隐式注册了另外两个关联的aor。每个隐式注册的AOR都将分配唯一的GRUU。寄存器响应将不包括这些GRUU；它将只包括注册中显式包含的AOR和实例ID的GROU。
SIP/2.0 200 OK
From: <sip:user_aor_1@example.net>;tag=5ab4
To: <sip:user_aor_1@example.net>;tag=373392
Call-ID: faif9a@ua.example.com
CSeq: 23001 REGISTER
Path: <sip:proxy.example.net;lr>
Service-Route: <sip:proxy.example.net;lr>
SIP/2.0 200 OK
From: <sip:user_aor_1@example.net>;tag=5ab4
To: <sip:user_aor_1@example.net>;tag=373392
Call-ID: faif9a@ua.example.com
CSeq: 23001 REGISTER
Path: <sip:proxy.example.net;lr>
Service-Route: <sip:proxy.example.net;lr>
Contact: <sip:ua.example.com>
;expires=3600
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;pub-gruu="sip:user_aor_1@example.net;gr=hha9s8d-999a"
;temp-gruu="sip:8ffkas08af7fasklzi9@example.net;gr"
P-Associated-URI: <sip:user_aor_2@example.net>,
<sip:+358504821437@example.net;user=phone>
Content-Length: 0
Contact: <sip:ua.example.com>
;expires=3600
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;pub-gruu="sip:user_aor_1@example.net;gr=hha9s8d-999a"
;temp-gruu="sip:8ffkas08af7fasklzi9@example.net;gr"
P-Associated-URI: <sip:user_aor_2@example.net>,
<sip:+358504821437@example.net;user=phone>
Content-Length: 0
The UA then subscribes to the registration event package as follows:
UA然后订阅注册事件包，如下所示：
SUBSCRIBE sip:user_aor_1@example.net SIP/2.0
From: <sip:user_aor_1@example.net>;tag=27182
To: <sip:user_aor_1@example.net>
Call-ID: gbjg0b@ua.example.com
CSeq: 45001 SUBSCRIBE
Route: <sip:proxy.example.net;lr>
Event: reg
Expires: 3600
Accept: application/reginfo+xml
Contact: <sip:user_aor_1@example.net;gr=hha9s8d-999a>
Content-Length: 0
SUBSCRIBE sip:user_aor_1@example.net SIP/2.0
From: <sip:user_aor_1@example.net>;tag=27182
To: <sip:user_aor_1@example.net>
Call-ID: gbjg0b@ua.example.com
CSeq: 45001 SUBSCRIBE
Route: <sip:proxy.example.net;lr>
Event: reg
Expires: 3600
Accept: application/reginfo+xml
Contact: <sip:user_aor_1@example.net;gr=hha9s8d-999a>
Content-Length: 0
(The successful response to the subscription is not shown.) Once the subscription is established, an initial notification is sent giving registration status. In IMS deployments, the response includes, in addition to the status for the requested URI, the status for the other associated URIs.
（未显示对订阅的成功响应。）订阅建立后，将发送一个初始通知，给出注册状态。在IMS部署中，除了请求的URI的状态外，响应还包括其他关联URI的状态。
NOTIFY sip:user_aor_1@example.net;gr=hha9s8d-999a SIP/2.0 From: <sip:user_aor_1@example.net>;tag=27182 To: <sip:user_aor_1@example.net>;tag=262281 Call-ID: gbjg0b@ua.example.com CSeq: 633 NOTIFY Subscription-State: active;expires=3600 Event: reg Content-Type: application/reginfo+xml Contact: <sip:registrar.example.net> Content-Length: ...
通知sip:user\u aor_1@example.net;gr=hha9s8d-999a SIP/2.0发件人：<SIP:user\u aor_1@example.net>;tag=27182到：<sip:user\u aor_1@example.net>;tag=262281呼叫ID:gbjg0b@ua.example.comCSeq:633通知订阅状态：活动；expires=3600事件：注册内容类型：应用程序/reginfo+xml联系人：<sip:register.example.net>内容长度：。。。
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:gr="urn:ietf:params:xml:ns:gruuinfo"
version="1" state="full">
<registration aor="sip:user_aor_1@example.net" id="a7"
state="active">
<contact id="92" state="active" event="registered"
duration-registered="1" expires="3599"
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:gr="urn:ietf:params:xml:ns:gruuinfo"
version="1" state="full">
<registration aor="sip:user_aor_1@example.net" id="a7"
state="active">
<contact id="92" state="active" event="registered"
duration-registered="1" expires="3599"
callid="faif9a@ua.example.com" cseq="23001">
<uri>
sip:ua.example.com
</uri>
<allOneLine>
<unknown-param name="+sip.instance">
"<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</unknown-param>
</allOneLine>
<allOneLine>
<gr:pub-gruu uri="sip:user_aor_1@example.net
;gr=hha9s8d-999a"/>
</allOneLine>
<allOneLine>
<gr:temp-gruu uri="sip:8ffkas08af7fasklzi9@example.net
;gr" first-cseq="54301"/>
</allOneLine>
</contact>
</registration>
<registration aor="sip:user_aor_2@example.net" id="a8"
state="active">
<contact id="93" state="active" event="created"
duration-registered="1" expires="3599"
callid="faif9a@ua.example.com" cseq="23001">
<uri>
sip:ua.example.com
</uri>
<allOneLine>
<unknown-param name="+sip.instance">
"<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</unknown-param>
</allOneLine>
<allOneLine>
<gr:pub-gruu uri="sip:user_aor_2@example.net
;gr=hha9s8d-999b"/>
</allOneLine>
<allOneLine>
<gr:temp-gruu uri="sip:07hcovy36vp6vngvbia@example.net
;gr" first-cseq="54301"/>
</allOneLine>
</contact>
</registration>
<registration
aor="sip:+358504821437@example.net;user=phone"
id="a9"
state="active">
<contact id="94" state="active" event="created"
duration-registered="1" expires="3599"
callid="faif9a@ua.example.com" cseq="23001">
<uri>
sip:ua.example.com
</uri>
<allOneLine>
<unknown-param name="+sip.instance">
"<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</unknown-param>
</allOneLine>
<allOneLine>
<gr:pub-gruu uri="sip:user_aor_1@example.net
;gr=hha9s8d-999a"/>
</allOneLine>
<allOneLine>
<gr:temp-gruu uri="sip:8ffkas08af7fasklzi9@example.net
;gr" first-cseq="54301"/>
</allOneLine>
</contact>
</registration>
<registration aor="sip:user_aor_2@example.net" id="a8"
state="active">
<contact id="93" state="active" event="created"
duration-registered="1" expires="3599"
callid="faif9a@ua.example.com" cseq="23001">
<uri>
sip:ua.example.com
</uri>
<allOneLine>
<unknown-param name="+sip.instance">
"<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</unknown-param>
</allOneLine>
<allOneLine>
<gr:pub-gruu uri="sip:user_aor_2@example.net
;gr=hha9s8d-999b"/>
</allOneLine>
<allOneLine>
<gr:temp-gruu uri="sip:07hcovy36vp6vngvbia@example.net
;gr" first-cseq="54301"/>
</allOneLine>
</contact>
</registration>
<registration
aor="sip:+358504821437@example.net;user=phone"
id="a9"
state="active">
<contact id="94" state="active" event="created"
duration-registered="1" expires="3599"
callid="faif9a@ua.example.com" cseq="23001">
<uri>
sip:ua.example.com
</uri>
<allOneLine>
<unknown-param name="+sip.instance">
"<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</unknown-param>
</allOneLine>
<allOneLine>
<gr:pub-gruu uri="sip:+358504821437@example.net
;user=phone;gr=hha9s8d-999c"/>
</allOneLine>
<allOneLine>
<gr:temp-gruu uri="sip:h99egjbv17fe8ibvlka@example.net
;gr" first-cseq="54301"/>
</allOneLine>
</contact>
</registration>
</reginfo>
callid="faif9a@ua.example.com" cseq="23001">
<uri>
sip:ua.example.com
</uri>
<allOneLine>
<unknown-param name="+sip.instance">
"<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</unknown-param>
</allOneLine>
<allOneLine>
<gr:pub-gruu uri="sip:+358504821437@example.net
;user=phone;gr=hha9s8d-999c"/>
</allOneLine>
<allOneLine>
<gr:temp-gruu uri="sip:h99egjbv17fe8ibvlka@example.net
;gr" first-cseq="54301"/>
</allOneLine>
</contact>
</registration>
</reginfo>
The status indicates that the associated URIs all have the same contact registered. It also includes the unique GRUUs that have been assigned to each. The UA may then retain those GRUUs for use when establishing dialogs using the corresponding AORs.
状态表示关联的URI都注册了相同的联系人。它还包括分配给每个组的唯一Gru。UA然后可以保留这些GRU，以便在使用相应的AOR建立对话时使用。
The <pub-gruu> and <temp-gruu> elements are defined within a new XML namespace URI. This namespace is "urn:ietf:params:xml:ns:gruuinfo". The schema for these elements is:
<pub-gruu>和<temp-gruu>元素在新的XML名称空间URI中定义。这个名称空间是“urn:ietf:params:xml:ns:gruinfo”。这些元素的模式为：
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:gruuinfo"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:gruuinfo">
<xs:complexType name="pubGruu">
<xs:attribute name="uri" type="xs:anyURI"
use="required"/>
</xs:complexType>
<xs:complexType name="tempGruu">
<xs:complexContent>
<xs:extension base="tns:pubGruu">
<xs:attribute name="first-cseq"
type="xs:unsignedLong"
use="required"/>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:gruuinfo"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:gruuinfo">
<xs:complexType name="pubGruu">
<xs:attribute name="uri" type="xs:anyURI"
use="required"/>
</xs:complexType>
<xs:complexType name="tempGruu">
<xs:complexContent>
<xs:extension base="tns:pubGruu">
<xs:attribute name="first-cseq"
type="xs:unsignedLong"
use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="pub-gruu" type="tns:pubGruu"/>
<xs:element name="temp-gruu" type="tns:tempGruu"/>
</xs:schema>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="pub-gruu" type="tns:pubGruu"/>
<xs:element name="temp-gruu" type="tns:tempGruu"/>
</xs:schema>
There are two IANA considerations associated with this specification.
本规范涉及两个IANA注意事项。
This section registers a new XML namespace, per the guidelines in [4].
本节根据[4]中的指南注册一个新的XML名称空间。
URI: The URI for this namespace is urn:ietf:params:xml:ns:gruuinfo
URI: The URI for this namespace is urn:ietf:params:xml:ns:gruuinfo
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
Paul Kyzivat <pkyzivat@cisco.com>
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
Paul Kyzivat <pkyzivat@cisco.com>
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Reg Information GRUU Extension Namespace</title>
</head>
<body>
<h1>Namespace for Reg Information GRUU Extension</h1>
<h2>urn:ietf:params:xml:ns:gruuinfo</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5628.txt">
RFC5628</a>.</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Reg Information GRUU Extension Namespace</title>
</head>
<body>
<h1>Namespace for Reg Information GRUU Extension</h1>
<h2>urn:ietf:params:xml:ns:gruuinfo</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5628.txt">
RFC5628</a>.</p>
</body>
</html>
END
This section registers an XML schema per the procedures in [4].
本节按照[4]中的过程注册XML模式。
URI: urn:ietf:params:xml:schema:gruuinfo.
URI:urn:ietf:params:xml:schema:gruinfo。
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
Paul Kyzivat <pkyzivat@cisco.com>
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
Paul Kyzivat <pkyzivat@cisco.com>
The XML for this schema can be found in Section 9.
该模式的XML可以在第9节中找到。
Security considerations for the registration event package are discussed in RFC 3680 [2], and those considerations apply here.
RFC 3680[2]中讨论了注册事件包的安全注意事项，这些注意事项适用于此处。
If a contact address obtained via subscription to the registration event package is not reachable by the subscriber, then its disclosure may arguably be considered a minimal security risk. In that case, the inclusion of a GRUU may be considered to increase the risk by providing a reachable address. On the other hand, requests addressed to a GRUU are always first processed by the servicing proxy before they reach the intended User Agent. The proxy may control access as desired, just as it may for the AOR. For instance, the proxy servicing a GRUU may accept requests from senders whose identity appears on a white list, and reject other requests. In this respect, disclosing a GRUU presents no more risk than disclosing the AOR.
如果订阅者无法访问通过订阅注册事件包获得的联系地址，则其披露可能被认为是最小的安全风险。在这种情况下，通过提供可访问的地址，可以认为包含GRUU会增加风险。另一方面，发往GRUU的请求总是在到达预期的用户代理之前首先由服务代理进行处理。代理可以根据需要控制访问，就像它可以控制AOR一样。例如，为GRUU提供服务的代理可以接受来自其身份出现在白名单上的发件人的请求，并拒绝其他请求。在这方面，披露GRUU不会比披露AOR带来更多的风险。
Temporary GRUUs have an additional security consideration. The intent of the temporary GRUU is to provide a contact address that cannot be correlated to the identity of the calling party. The recipient of a call using a temporary GRUU may guess the identity of the calling party and then attempt to obtain the temporary GRUUs assigned to that caller to confirm the conjecture. Two possible approaches to obtaining the temporary GRUUs are:
临时GROU还有一个额外的安全考虑。临时GRUU的目的是提供一个与呼叫方身份不相关的联系地址。使用临时Gru的呼叫的接收者可以猜测呼叫方的身份，然后尝试获取分配给该呼叫方的临时Gru以确认该猜测。获得临时GROU的两种可能方法是：
o Send a REGISTER request to a conjectured caller.
o 向推测的调用方发送注册请求。
o Send a SUBSCRIBE request for the registration event package to the conjectured caller.
o 向推测的调用方发送注册事件包的订阅请求。
Typically, REGISTER is restricted to devices or users that are authorized to originate and receive calls with the AOR. Anonymity among users of the same AOR is hard to achieve and typically unnecessary. It is recommended (see Section 5) that the authorization policy for the registration event package permit only those subscribers who are authorized to register to the AOR to receive temporary GRUUs. With this policy, the confidentiality of
通常，注册仅限于授权发起和接收AOR呼叫的设备或用户。同一AOR用户之间的匿名性很难实现，而且通常是不必要的。建议（参见第5节）注册事件包的授权策略只允许授权注册到AOR的订阅者接收临时GRU。有了这项政策
the temporary GRUU will be the same with and without the registration event package. User Agents that use a temporary GRUU should note that confidentiality does not extend to parties that are permitted to register to the AOR or to obtain the temporary GRUU when subscribing to the registration event package.
临时GRUU将与注册事件包和不注册事件包相同。使用临时GRUU的用户代理应注意，保密性不扩展到允许注册到AOR或在订阅注册事件包时获得临时GRUU的各方。
The author would like to thank Jonathan Rosenberg for help with this document, and Jari Urpalainen for assistance with the XML.
作者要感谢Jonathan Rosenberg对本文档的帮助，以及Jari Urpalainen对XML的帮助。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[2] Rosenberg，J.，“用于注册的会话启动协议（SIP）事件包”，RFC 36802004年3月。
[3] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[3] Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理（UA）URI（GRUU）”，RFC 5627，2009年10月。
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[4] Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[5] 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.
[5] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[6] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, January 2003.
[6] Garcia Martin，M.，Henrikson，E.，和D.Mills，“第三代合作伙伴关系项目（3GPP）会话启动协议（SIP）的专用头（P头）扩展”，RFC 3455，2003年1月。
[7] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[7] Sparks，R.，Hawrylyshen，A.，Johnston，A.，Rosenberg，J.，和H.Schulzrinne，“会话启动协议（SIP）酷刑测试消息”，RFC 4475，2006年5月。
Author's Address
作者地址
Paul H. Kyzivat Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Paul H.Kyzivat Cisco Systems，Inc.美国马萨诸塞州Boxborough大道1414号，邮编01719
EMail: pkyzivat@cisco.com
EMail: pkyzivat@cisco.com