Internet Engineering Task Force (IETF) A.B. Roach
Request for Comments: 6140 Tekelec
Updates: 3680 March 2011
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A.B. Roach
Request for Comments: 6140 Tekelec
Updates: 3680 March 2011
Category: Standards Track
ISSN: 2070-1721
Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)
在会话启动协议（SIP）中注册多个电话号码
Abstract
摘要
This document defines a mechanism by which a Session Initiation Protocol (SIP) server acting as a traditional Private Branch Exchange (PBX) can register with a SIP Service Provider (SSP) to receive phone calls for SIP User Agents (UAs). In order to function properly, this mechanism requires that each of the Addresses of Record (AORs) registered in bulk map to a unique set of contacts. This requirement is satisfied by AORs representing phone numbers regardless of the domain, since phone numbers are fully qualified and globally unique. This document therefore focuses on this use case.
本文档定义了一种机制，通过该机制，充当传统专用分支交换机（PBX）的会话启动协议（SIP）服务器可以向SIP服务提供商（SSP）注册，以接收SIP用户代理（UAs）的电话呼叫。为了正常工作，该机制要求批量注册的每个记录地址（AOR）映射到一组唯一的联系人。由于电话号码是完全限定的且在全球范围内是唯一的，因此表示电话号码的AOR可以满足这一要求，而不考虑域。因此，本文档将重点放在这个用例上。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6140.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6140.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Constraints .....................................................3
3. Terminology and Conventions .....................................4
4. Mechanism Overview ..............................................5
5. Registering for Multiple Phone Numbers ..........................5
5.1. SIP-PBX Behavior ...........................................5
5.2. Registrar Behavior .........................................6
5.3. SIP URI "user" Parameter Handling ..........................8
6. SSP Processing of Inbound Requests ..............................8
7. Interaction with Other Mechanisms ...............................9
7.1. Globally Routable User Agent URIs (GRUU) ...................9
7.1.1. Public GRUUs ........................................9
7.1.2. Temporary GRUUs ....................................11
7.2. Registration Event Package ................................16
7.2.1. SIP-PBX Aggregate Registration State ...............16
7.2.2. Individual AOR Registration State ..................16
7.3. Client-Initiated (Outbound) Connections ...................18
7.4. Non-Adjacent Contact Registration (Path) and
Service-Route Discovery ...................................19
8. Examples .......................................................20
8.1. Usage Scenario: Basic Registration ........................20
8.2. Usage Scenario: Using Path to Control Request URI .........22
9. IANA Considerations ............................................24
9.1. New SIP Option Tag ........................................24
9.2. New SIP URI Parameters ....................................25
9.2.1. 'bnc' SIP URI Parameter ............................25
9.2.2. 'sg' SIP URI Parameter .............................25
9.3. New SIP Header Field Parameter ............................25
10. Security Considerations .......................................25
11. Acknowledgements ..............................................28
12. References ....................................................28
12.1. Normative References .....................................28
12.2. Informative References ...................................29
Appendix A. Requirements Analysis .................................31
1. Introduction ....................................................3
2. Constraints .....................................................3
3. Terminology and Conventions .....................................4
4. Mechanism Overview ..............................................5
5. Registering for Multiple Phone Numbers ..........................5
5.1. SIP-PBX Behavior ...........................................5
5.2. Registrar Behavior .........................................6
5.3. SIP URI "user" Parameter Handling ..........................8
6. SSP Processing of Inbound Requests ..............................8
7. Interaction with Other Mechanisms ...............................9
7.1. Globally Routable User Agent URIs (GRUU) ...................9
7.1.1. Public GRUUs ........................................9
7.1.2. Temporary GRUUs ....................................11
7.2. Registration Event Package ................................16
7.2.1. SIP-PBX Aggregate Registration State ...............16
7.2.2. Individual AOR Registration State ..................16
7.3. Client-Initiated (Outbound) Connections ...................18
7.4. Non-Adjacent Contact Registration (Path) and
Service-Route Discovery ...................................19
8. Examples .......................................................20
8.1. Usage Scenario: Basic Registration ........................20
8.2. Usage Scenario: Using Path to Control Request URI .........22
9. IANA Considerations ............................................24
9.1. New SIP Option Tag ........................................24
9.2. New SIP URI Parameters ....................................25
9.2.1. 'bnc' SIP URI Parameter ............................25
9.2.2. 'sg' SIP URI Parameter .............................25
9.3. New SIP Header Field Parameter ............................25
10. Security Considerations .......................................25
11. Acknowledgements ..............................................28
12. References ....................................................28
12.1. Normative References .....................................28
12.2. Informative References ...................................29
Appendix A. Requirements Analysis .................................31
The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. One of SIP's primary functions is providing rendezvous between users. By design, these rendezvous have been provided through a combination of the server look-up procedures defined in RFC 3263 [4] and the registrar procedures described in RFC 3261 [3].
会话发起协议（SIP）是用于创建、修改和终止与一个或多个参与者的会话的应用层控制（信令）协议。SIP的主要功能之一是提供用户之间的会合。根据设计，这些集合是通过RFC 3263[4]中定义的服务器查找程序和RFC 3261[3]中描述的注册程序的组合提供的。
The intention of the original protocol design was that any user's AOR (Address of Record) would be handled by the authority indicated by the hostport portion of the AOR. The users would register individual reachability information with this authority, which would then route incoming requests accordingly.
原始协议设计的意图是，任何用户的AOR（记录地址）都将由AOR的hostport部分所指示的权限处理。用户将向该机构注册个人可达性信息，然后该机构将相应地路由传入请求。
In actual deployments, some SIP servers have been deployed in architectures that, for various reasons, have requirements to provide dynamic routing information for large blocks of AORs, where all of the AORs in the block were to be handled by the same server. For purposes of efficiency, many of these deployments do not wish to maintain separate registrations for each of the AORs in the block. Thus, an alternate mechanism to provide dynamic routing information for blocks of AORs is desirable.
在实际部署中，一些SIP服务器部署在架构中，由于各种原因，这些架构要求为大型AOR块提供动态路由信息，其中块中的所有AOR都将由同一服务器处理。为了提高效率，许多部署不希望为块中的每个AOR维护单独的注册。因此，需要一种为aor块提供动态路由信息的替代机制。
Although the use of SIP REGISTER request messages to update reachability information for multiple users simultaneously is somewhat beyond the original semantics defined for REGISTER requests by RFC 3261 [3], this approach has seen significant deployment in certain environments. In particular, deployments in which small to medium SIP-PBX servers are addressed using E.164 numbers have used this mechanism to avoid the need to maintain DNS entries or static IP addresses for the SIP-PBX servers.
尽管使用SIP注册请求消息同时更新多个用户的可达性信息在某种程度上超出了RFC 3261[3]为注册请求定义的原始语义，但这种方法在某些环境中得到了显著的部署。特别是，使用E.164号码对中小型SIP-PBX服务器进行寻址的部署使用了这种机制，以避免需要维护SIP-PBX服务器的DNS条目或静态IP地址。
In recognition of the momentum that REGISTER-based approaches have seen in deployments, this document defines a REGISTER-based approach. Since E.164-addressed UAs are very common today in SIP-PBX environments, and since SIP URIs in which the user portion is an E.164 number are always globally unique, regardless of the domain, this document focuses on registration of SIP URIs in which the user portion is an E.164 number.
鉴于基于注册的方法在部署中的发展势头，本文档定义了基于注册的方法。由于E.164寻址的UAs如今在SIP-PBX环境中非常常见，并且由于其中用户部分为E.164号的SIP URI始终是全局唯一的，无论域如何，本文档重点介绍其中用户部分为E.164号的SIP URI的注册。
Within the problem space that has been established for this work, several constraints shape our solution. These are defined in the MARTINI requirements document [22] and are analyzed in Appendix A. In terms of impact to the solution at hand, the following two
在为这项工作建立的问题空间中，有几个约束条件影响我们的解决方案。这些在马提尼需求文件[22]中进行了定义，并在附录A中进行了分析。就对现有解决方案的影响而言，以下两个方面
constraints have the most profound effect: (1) The SIP-PBX cannot be assumed to be assigned a static IP address; and (2) No DNS entry can be relied upon to consistently resolve to the IP address of the SIP-PBX.
限制因素的影响最为深远：（1）不能假定SIP-PBX被分配了一个静态IP地址；和（2）不能依赖DNS条目来一致解析SIP-PBX的IP地址。
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 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
Further, the term "SSP" is meant as an acronym for a "SIP Service Provider," while the term "SIP-PBX" is used to indicate a SIP Private Branch Exchange.
此外，术语“SSP”意指“SIP服务提供商”的首字母缩略词，而术语“SIP-PBX”用于指示SIP专用分支交换。
Indented portions of the document, such as this one, form non-normative, explanatory sections of the document.
本文件的缩进部分，如本文件，构成本文件的非规范性、解释性章节。
Although SIP is a text-based protocol, some of the examples in this document cannot be unambiguously rendered without additional markup due to the constraints placed on the formatting of RFCs. This document uses the <allOneLine/> markup convention established in RFC 4475 [17] to avoid ambiguity and meet the RFC layout requirements. For the sake of completeness, the text defining this markup (Section 2.1 of RFC 4475 [17]) is reproduced in its entirety below:
尽管SIP是一种基于文本的协议，但由于RFC格式的限制，本文档中的一些示例在没有附加标记的情况下无法明确呈现。本文件使用RFC 4475[17]中建立的<allOneLine/>标记约定，以避免歧义并满足RFC布局要求。为完整起见，定义该标记的文本（RFC 4475[17]第2.1节）全文复制如下：
Several of these examples contain unfolded lines longer than 72 characters. These are captured between <allOneLine/> tags. The single unfolded line is reconstructed by directly concatenating all lines appearing between the tags (discarding any line feeds or carriage returns). There will be no whitespace at the end of lines. Any whitespace appearing at a fold-point will appear at the beginning of a line.
其中一些示例包含长度超过72个字符的展开行。这些在<allOneLine/>标记之间捕获。通过直接连接标签之间出现的所有行（丢弃任何换行或回车），可以重建单个展开行。行尾将没有空格。任何出现在折叠点的空白都将出现在一行的开头。
The following represent the same string of bits:
以下表示相同的位串：
Header-name: first value, reallylongsecondvalue, third value
标题名称：第一个值、reallylongsecondvalue、第三个值
<allOneLine> Header-name: first value, reallylongsecondvalue , third value </allOneLine>
<allOneLine>标题名称：第一个值、reallylongsecondvalue、第三个值
<allOneLine> Header-name: first value, reallylong second value, third value </allOneLine>
<allOneLine>标题名称：第一个值、reallylong第二个值、第三个值
Note that this is NOT SIP header-line folding, where different strings of bits have equivalent meaning.
请注意，这不是SIP头行折叠，不同的位串具有相同的含义。
The overall mechanism is achieved using a REGISTER request with a specially formatted Contact URI. This document also defines an option tag that can be used to ensure that a registrar and any intermediaries understand the mechanism described herein.
整个机制是使用带有特殊格式的联系人URI的注册请求实现的。本文档还定义了一个选项标签，可用于确保注册商和任何中介机构了解本文所述的机制。
The Contact URI itself is tagged with a URI parameter to indicate that it actually represents multiple phone-number-associated contacts.
联系人URI本身用URI参数标记，以指示它实际上表示多个与电话号码相关联的联系人。
We also define some lightweight extensions to the Globally Routable UA URIs (GRUU) mechanism defined by RFC 5627 [20] to allow the use of public and temporary GRUUs assigned by the SSP.
我们还为RFC 5627[20]定义的全局可路由UA URI（GRUU）机制定义了一些轻量级扩展，以允许使用SSP分配的公共和临时GRUU。
Aside from these extensions, the REGISTER request itself is processed by a registrar in the same way as normal registrations: by updating its location service with additional AOR-to-Contact bindings.
除了这些扩展之外，注册请求本身由注册器以与正常注册相同的方式处理：通过使用附加的AOR-to-Contact绑定更新其位置服务。
Note that the list of AORs associated with a SIP-PBX is a matter of local provisioning at the SSP and the SIP-PBX. The mechanism defined in this document does not provide any means to detect or recover from provisioning mismatches (although the registration event package can be used as a standardized means for auditing such AORs; see Section 7.2.1).
请注意，与SIP-PBX关联的AOR列表是SSP和SIP-PBX的本地资源调配问题。本文档中定义的机制不提供任何方法来检测或从供应不匹配中恢复（尽管注册事件包可以用作审计此类AOR的标准化方法；请参见第7.2.1节）。
To register for multiple AORs, the SIP-PBX sends a REGISTER request to the SSP. This REGISTER request varies from a typical REGISTER request in two important ways. First, it MUST contain an option tag of "gin" in both a "Require" header field and a "Proxy-Require" header field. (The option tag "gin" is an acronym for "generate implicit numbers".) Second, in at least one "Contact" header field, it MUST include a Contact URI that contains the URI parameter "bnc"
为了注册多个AOR，SIP-PBX向SSP发送一个注册请求。此注册请求在两个重要方面与典型的注册请求不同。首先，它必须在“Require”头字段和“Proxy Require”头字段中都包含一个选项标记“gin”。（选项标记“gin”是“生成隐式数字”的首字母缩略词。）其次，在至少一个“联系人”标题字段中，它必须包含一个包含URI参数“bnc”的联系人URI
(which stands for "bulk number contact") and has no user portion (hence no "@" symbol). A URI with a "bnc" parameter MUST NOT contain a user portion. Except for the SIP URI "user" parameter, this URI MAY contain any other parameters that the SIP-PBX desires. These parameters will be echoed back by the SSP in any requests bound for the SIP-PBX.
（代表“批量号码联系人”），没有用户部分（因此没有“@”符号）。带有“bnc”参数的URI不能包含用户部分。除了SIP URI“user”参数外，此URI可能包含SIP-PBX所需的任何其他参数。SSP将在绑定到SIP-PBX的任何请求中回显这些参数。
Because of the constraints discussed in Section 2, the host portion of the Contact URI will generally contain an IP address, although nothing in this mechanism enforces or relies upon that fact. If the SIP-PBX operator chooses to maintain DNS entries that resolve to the IP address of his SIP-PBX via RFC 3263 resolution procedures, then this mechanism works just fine with domain names in the "Contact" header field.
由于第2节中讨论的限制，联系人URI的主机部分通常包含IP地址，尽管此机制中的任何内容都不强制或依赖于此事实。如果SIP-PBX运营商选择维护通过RFC 3263解析过程解析为其SIP-PBX的IP地址的DNS条目，则该机制在“联系人”标题字段中的域名上运行良好。
The "bnc" URI parameter indicates that special interpretation of the Contact URI is necessary: instead of indicating the insertion of a single Contact URI into the location service, it indicates that multiple URIs (one for each associated AOR) should be inserted.
“bnc”URI参数表示需要对联系人URI进行特殊解释：它表示应该插入多个URI（每个关联的AOR一个），而不是将单个联系人URI插入位置服务。
Any SIP-PBX implementing the registration mechanism defined in this document MUST also support the path mechanism defined by RFC 3327 [10], and MUST include a 'path' option tag in the "Supported" header field of the REGISTER request (which is a stronger requirement than imposed by the path mechanism itself). This behavior is necessary because proxies between the SIP-PBX and the registrar may need to insert "Path" header field values in the REGISTER request for this document's mechanism to function properly, and, per RFC 3327 [10], they can only do so if the User Agent Client (UAC) inserted the option tag in the "Supported" header field. In accordance with the procedures defined in RFC 3327 [10], the SIP-PBX is allowed to ignore the "Path" header fields returned in the REGISTER response.
实现本文档中定义的注册机制的任何SIP-PBX还必须支持RFC 3327[10]定义的路径机制，并且必须在注册请求的“受支持”标题字段中包含“路径”选项标记（这是比路径机制本身强的要求）。这种行为是必要的，因为SIP-PBX和注册器之间的代理可能需要在注册请求中插入“路径”头字段值，以使该文档的机制正常运行，并且，根据RFC 3327[10]，只有在用户代理客户端（UAC）在“支持的”头字段中插入选项标记时，他们才能这样做。根据RFC 3327[10]中定义的程序，允许SIP-PBX忽略寄存器响应中返回的“路径”头字段。
The registrar, upon receipt of a REGISTER request containing at least one "Contact" header field with a "bnc" parameter, will use the value in the "To" header field to identify the SIP-PBX for which registration is being requested. It then authenticates the SIP-PBX (e.g., using SIP digest authentication, mutual Transport Layer Security (TLS) [18], or some other authentication mechanism). After the SIP-PBX is authenticated, the registrar updates its location service with a unique AOR-to-Contact mapping for each of the AORs associated with the SIP-PBX. Semantically, each of these mappings will be treated as a unique row in the location service. The actual implementation may, of course, perform internal optimizations to reduce the amount of memory used to store such information.
注册官在收到包含至少一个带有“bnc”参数的“联系人”报头字段的注册请求后，将使用“收件人”报头字段中的值来标识正在请求注册的SIP-PBX。然后，它认证SIP-PBX（例如，使用SIP摘要认证、相互传输层安全性（TLS）[18]或某种其他认证机制）。在SIP-PBX被认证之后，注册器使用与SIP-PBX相关联的每个AOR的唯一AOR到联系人映射来更新其位置服务。从语义上讲，这些映射中的每一个都将被视为位置服务中唯一的一行。当然，实际实现可能会执行内部优化，以减少用于存储此类信息的内存量。
For each of these unique rows, the AOR will be in the format that the SSP expects to receive from external parties (e.g., "sip:+12145550102@ssp.example.com"). The corresponding contact will be formed by adding to the REGISTER request's Contact URI a user portion containing the fully qualified, E.164-formatted number (including the preceding "+" symbol) and removing the "bnc" parameter. Aside from the initial "+" symbol, this E.164-formatted number MUST consist exclusively of digits from 0 through 9 and explicitly MUST NOT contain any visual separator symbols (e.g., "-", ".", "(", or ")"). For example, if the "Contact" header field contains the URI <sip:198.51.100.3:5060;bnc>, then the contact value associated with the aforementioned AOR will be <sip:+12145550102@198.51.100.3:5060>.
对于这些唯一行中的每一行，AOR将采用SSP预期从外部方收到的格式（例如，“sip:+12145550102@ssp.example.com"). 通过在注册请求的联系人URI中添加一个包含完全限定的、E.164格式的号码（包括前面的“+”符号）的用户部分并删除“bnc”参数，将形成相应的联系人。除首字母“+”符号外，此E.164格式的数字必须仅由0到9的数字组成，并且明确不得包含任何可视分隔符符号（例如“-”、“，”（“，或”））。例如，如果“Contact”头字段包含URI<sip:198.51.100.3:5060；bnc>，则与上述AOR相关的触点值将<sip:+12145550102@198.51.100.3:5060>.
Although the SSP treats this registration as a number of discrete rows for the purpose of re-targeting incoming requests, the renewal, expiration, and removal of these rows is bound to the registered contact. In particular, this means that REGISTER requests that attempt to de-register a single AOR that has been implicitly registered MUST NOT remove that AOR from the bulk registration. In this circumstance, the registrar simply acts as if the UA attempted to unregister a contact that wasn't actually registered (e.g., return the list of presently registered contacts in a success response). A further implication of this property is that an individual extension that is implicitly registered may also be explicitly registered using a normal, non-bulk registration (subject to SSP policy). If such a registration exists, it is refreshed independently of the bulk registration and is not removed when the bulk registration is removed.
虽然SSP将此注册视为若干离散行，以重新定位传入请求，但这些行的续订、过期和删除都绑定到已注册联系人。特别是，这意味着尝试取消注册已隐式注册的单个AOR的注册请求不得从批量注册中删除该AOR。在这种情况下，注册员的行为就好像UA试图注销一个未实际注册的联系人一样（例如，在成功响应中返回当前已注册联系人的列表）。此属性的另一个含义是，隐式注册的单个扩展也可以使用正常的非批量注册（根据SSP策略）进行显式注册。如果存在这样的注册，它将独立于批量注册进行刷新，并且在批量注册被删除时不会被删除。
A registrar that receives a REGISTER request containing a Contact URI with both a "bnc" parameter and a user portion MUST NOT send a 200- class (Success) response. If no other error is applicable, the registrar can use a 400 (Bad Request) response to indicate this error condition.
接收到包含联系人URI的注册请求（包含“bnc”参数和用户部分）的注册器不得发送200类（成功）响应。如果没有其他错误适用，注册器可以使用400（错误请求）响应来指示此错误情况。
Note that the preceding paragraph is talking about the user portion of a URI:
请注意，前面的段落讨论的是URI的用户部分：
sip:+12145550100@example.com
^^^^^^^^^^^^
sip:+12145550100@example.com
^^^^^^^^^^^^
A registrar compliant with this document MUST support the path mechanism defined in RFC 3327 [10]. The rationale for support of this mechanism is given in Section 5.1.
符合本文档要求的注册器必须支持RFC 3327[10]中定义的路径机制。第5.1节给出了支持该机制的理由。
Aside from the "bnc" parameter, all URI parameters present on the Contact URI in the REGISTER request MUST be copied to the contact value stored in the location service.
除了“bnc”参数外，注册请求中联系人URI上存在的所有URI参数都必须复制到存储在位置服务中的联系人值。
If the SSP servers perform processing based on User Agent Capabilities (as defined in RFC 3840 [13]), they will treat any feature tags present on a "Contact" header field with a "bnc" parameter in its URI as applicable to all of the resulting AOR-to-Contact mappings. Similarly, any option tags present on the REGISTER request that indicate special handling for any subsequent requests are also applicable to all of the AOR-to-Contact mappings.
如果SSP服务器基于用户代理功能（如RFC 3840[13]中所定义）执行处理，则它们会将URI中带有“bnc”参数的“联系人”标题字段上的任何功能标记视为适用于所有生成的AOR到联系人映射。类似地，寄存器请求上显示的任何选项标记（指示对任何后续请求的特殊处理）也适用于所有AOR到联系人的映射。
This document does not modify the behavior specified in RFC 3261 [3] for inclusion of the "user" parameter on Request URIs. However, to avoid any ambiguity in handling at the SIP-PBX, the following normative behavior is imposed on its interactions with the SSP.
本文档不修改RFC 3261[3]中指定的在请求URI中包含“用户”参数的行为。然而，为了避免在SIP-PBX处理过程中出现任何歧义，以下规范行为适用于SIP-PBX与SSP的交互。
When a SIP-PBX registers with an SSP using a Contact URI containing a "bnc" parameter, that Contact URI MUST NOT include a "user" parameter. A registrar that receives a REGISTER request containing a Contact URI with both a "bnc" parameter and a "user" parameter MUST NOT send a 200-class (success) response. If no other error is applicable, the registrar can use a 400 (Bad Request) response to indicate this error condition.
当SIP-PBX使用包含“bnc”参数的联系人URI向SSP注册时，该联系人URI不得包含“用户”参数。接收到包含带有“bnc”参数和“用户”参数的联系人URI的注册请求的注册器不得发送200类（成功）响应。如果没有其他错误适用，注册器可以使用400（错误请求）响应来指示此错误情况。
Note that the preceding paragraph is talking about the "user" parameter of a URI:
请注意，前面的段落讨论的是URI的“user”参数：
sip:+12145550100@example.com;user=phone
^^^^^^^^^^
sip:+12145550100@example.com;user=phone
^^^^^^^^^^
When a SIP-PBX receives a request from an SSP, and the Request URI contains a user portion corresponding to an AOR registered using a Contact URI containing a "bnc" parameter, then the SIP-PBX MUST NOT reject the request (or otherwise cause the request to fail) due to the absence, presence, or value of a "user" parameter on the Request URI.
当SIP-PBX从SSP接收到请求，并且请求URI包含与使用包含“bnc”参数的联系人URI注册的AOR相对应的用户部分时，SIP-PBX不得由于请求URI上的“用户”参数的缺失、存在或值而拒绝请求（或以其他方式导致请求失败）。
In general, after processing the AOR-to-Contact mapping described in the preceding section, the SSP proxy/registrar (or equivalent entity) performs traditional proxy/registrar behavior, based on the mapping. For any inbound SIP requests whose AOR indicates an E.164 number assigned to one of the SSP's customers, this will generally involve setting the target set to the registered contacts associated with
通常，在处理上一节中描述的AOR到联系人的映射后，SSP代理/注册机构（或等效实体）根据映射执行传统的代理/注册机构行为。对于AOR指示分配给SSP客户之一的E.164号的任何入站SIP请求，这通常涉及将目标设置为与之关联的已注册联系人
that AOR and performing request forwarding as described in Section 16.6 of RFC 3261 [3]. An SSP using the mechanism defined in this document MUST perform such processing for inbound INVITE requests and SUBSCRIBE requests to the "reg" event package (see Section 7.2.2) and SHOULD perform such processing for all other method types, including unrecognized SIP methods.
该AOR并按照RFC 3261[3]第16.6节所述执行请求转发。使用本文件中定义的机制的SSP必须对入站INVITE请求和“reg”事件包订阅请求执行此类处理（见第7.2.2节），并应对所有其他方法类型（包括未识别的SIP方法）执行此类处理。
The following sections describe the means by which this mechanism interacts with relevant REGISTER-related extensions currently defined by the IETF.
以下各节描述了该机制与IETF当前定义的相关寄存器相关扩展交互的方式。
To enable advanced services to work with UAs behind a SIP-PBX, it is important that the GRUU mechanism defined by RFC 5627 [20] work correctly with the mechanism defined by this document -- that is, that user agents served by the SIP-PBX can acquire and use GRUUs for their own use.
为了使高级服务能够与SIP-PBX后面的UAs一起工作，RFC 5627[20]定义的GRUU机制必须与本文档定义的机制正确工作——也就是说，SIP-PBX服务的用户代理可以获取并使用GRUU供自己使用。
Support of public GRUUs is OPTIONAL in SSPs and SIP-PBXes.
在SSP和SIP PBX中，对公共GRUs的支持是可选的。
When a SIP-PBX registers a Bulk Number Contact (a contact with a "bnc" parameter), and also invokes GRUU procedures for that contact during registration, then the SSP will assign a public GRUU to the SIP-PBX in the normal fashion. Because the URI being registered contains a "bnc" parameter, the GRUU will also contain a "bnc" parameter. In particular, this means that the GRUU will not contain a user portion.
当SIP-PBX注册批量号码联系人（带有“bnc”参数的联系人）并在注册期间调用该联系人的GRUU过程时，SSP将以正常方式向SIP-PBX分配公共GRUU。因为正在注册的URI包含一个“bnc”参数，所以GRUU也将包含一个“bnc”参数。特别是，这意味着GRUU将不包含用户部分。
When a UA registers a contact with the SIP-PBX using GRUU procedures, the SIP-PBX provides to the UA a public GRUU formed by adding an "sg" parameter to the GRUU parameter it received from the SSP. This "sg" parameter contains a disambiguation token that the SIP-PBX can use to route inbound requests to the proper UA.
当UA使用GRUU程序向SIP-PBX注册联系人时，SIP-PBX向UA提供一个公共GRUU，该GRUU是通过向其从SSP接收的GRUU参数添加“sg”参数而形成的。此“sg”参数包含一个消歧令牌，SIP-PBX可以使用该令牌将入站请求路由到适当的UA。
So, for example, when the SIP-PBX registers with the following "Contact" header field:
因此，例如，当SIP-PBX使用以下“联系人”头字段注册时：
Contact: <sip:198.51.100.3;bnc>;
+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Contact: <sip:198.51.100.3;bnc>;
+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
the SSP may choose to respond with a "Contact" header field that looks like this:
SSP可选择使用“联系人”标题字段进行响应，如下所示：
<allOneLine>
Contact: <sip:198.51.100.3;bnc>;
pub-gruu="sip:ssp.example.com;bnc;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6";
+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=7200
</allOneLine>
<allOneLine>
Contact: <sip:198.51.100.3;bnc>;
pub-gruu="sip:ssp.example.com;bnc;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6";
+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=7200
</allOneLine>
When its own UAs register using GRUU procedures, the SIP-PBX can then add whatever device identifier it feels appropriate in an "sg" parameter and present this value to its own UAs. For example, assume the UA associated with the AOR "+12145550102" sent the following "Contact" header field in its REGISTER request:
当它自己的UAs使用GRUU过程注册时，SIP-PBX可以在“sg”参数中添加它认为合适的任何设备标识符，并将该值呈现给它自己的UAs。例如，假设与AOR“+12145550102”关联的UA在其注册请求中发送了以下“联系人”头字段：
Contact: <sip:line-1@10.20.1.17>;
+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
Contact: <sip:line-1@10.20.1.17>;
+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
The SIP-PBX will add an "sg" parameter to the pub-gruu it received from the SSP with a token that uniquely identifies the device (possibly the URN itself; possibly some other identifier), insert a user portion containing the fully qualified E.164 number associated with the UA, and return the result to the UA as its public GRUU. The resulting "Contact" header field sent from the SIP-PBX to the registering UA would look something like this:
SIP-PBX将向从SSP接收的pub gruu添加一个“sg”参数，该参数带有唯一标识设备的令牌（可能是URN本身；可能是其他标识符），插入一个包含与UA关联的完全限定的E.164号的用户部分，并将结果作为其公共gruu返回给UA。从SIP-PBX发送到注册UA的结果“联系人”头字段如下所示：
<allOneLine>
Contact: <sip:line-1@10.20.1.17>;
pub-gruu="sip:+12145550102@ssp.example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6";
+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
;expires=3600
</allOneLine>
<allOneLine>
Contact: <sip:line-1@10.20.1.17>;
pub-gruu="sip:+12145550102@ssp.example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6";
+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
;expires=3600
</allOneLine>
When an incoming request arrives at the SSP for a GRUU corresponding to a bulk number contact ("bnc"), the SSP performs slightly different processing for the GRUU than it would for a URI without a "bnc" parameter. When the GRUU is re-targeted to the registered bulk number contact, the SSP MUST copy the "sg" parameter from the GRUU to the new target. The SIP-PBX can then use this "sg" parameter to determine to which user agent the request should be routed. For example, the first line of an INVITE request that has been re-targeted to the SIP-PBX for the UA shown above would look like this:
当对应于批量号码联系人（“bnc”）的GRUU的传入请求到达SSP时，SSP对GRUU执行的处理与对不带“bnc”参数的URI执行的处理略有不同。当GRUU重新定位到注册的批量号码联系人时，SSP必须将“sg”参数从GRUU复制到新目标。然后，SIP-PBX可以使用这个“sg”参数来确定请求应该路由到哪个用户代理。例如，如上所示，针对UA重新定向到SIP-PBX的INVITE请求的第一行如下所示：
INVITE sip:+12145550102@198.51.100.3;sg=00:05:03:5e:70:a6 SIP/2.0
INVITE sip:+12145550102@198.51.100.3;sg=00:05:03:5e:70:a6 SIP/2.0
In order to provide support for privacy, the SSP SHOULD implement the temporary GRUU mechanism described in this section. Reasons for not doing so would include systems with an alternative privacy mechanism that maintains the integrity of public GRUUs (i.e., if public GRUUs are anonymized, then the anonymizer function would need to be capable of providing -- as the anonymized URI -- a globally routable URI that routes back only to the target identified by the original public GRUU).
为了提供对隐私的支持，SSP应实施本节所述的临时GRUU机制。不这样做的原因包括系统具有另一种隐私机制，以维护公共Gruu的完整性（即，如果公共GRU是匿名的，那么匿名器函数需要能够提供——作为匿名URI——一个全局可路由URI，该URI只路由回原始公共GRU标识的目标）。
Temporary GRUUs are used to provide anonymity for the party creating and sharing the GRUU. Being able to correlate two temporary GRUUs as having originated from behind the same SIP-PBX violates this principle of anonymity. Consequently, rather than relying upon a single, invariant identifier for the SIP-PBX in its UA's temporary GRUUs, we define a mechanism whereby the SSP provides the SIP-PBX with sufficient information for the SIP-PBX to mint unique temporary GRUUs. These GRUUs have the property that the SSP can correlate them to the proper SIP-PBX, but no other party can do so. To achieve this goal, we use a slight modification of the procedure described in Appendix A.2 of RFC 5627 [20].
临时Gru用于为创建和共享Gru的一方提供匿名性。能够将来自同一SIP-PBX的两个临时Gru关联起来违反了匿名原则。因此，我们定义了一种机制，通过该机制，SSP向SIP-PBX提供足够的信息，使SIP-PBX能够创建唯一的临时GRUs，而不是依赖其UA临时GRUs中SIP-PBX的单一不变标识符。这些GRUU的特性是SSP可以将它们与适当的SIP-PBX关联，但其他方不能这样做。为了实现这一目标，我们对RFC 5627[20]附录a.2中描述的程序进行了轻微修改。
The SIP-PBX needs to be able to construct a temp-gruu in a way that the SSP can decode. In order to ensure that the SSP can decode GRUUs, we need to standardize the algorithm for creation of temp-gruus at the SIP-PBX. This allows the SSP to reverse the algorithm in order to identify the registration entry that corresponds to the GRUU.
SIP-PBX需要能够以SSP可以解码的方式构造临时gruu。为了确保SSP能够解码GRUs，我们需要标准化SIP-PBX上创建临时GRUs的算法。这允许SSP反转算法，以识别对应于GRUU的注册条目。
It is equally important that no party other than the SSP be capable of decoding a temporary GRUU, including other SIP-PBXes serviced by the SSP. To achieve this property, an SSP that supports temporary GRUUs MUST create and store an asymmetric key pair: {K_e1,K_e2}. K_e1 is kept secret by the SSP, while K_e2 is shared with the SIP-PBXes via provisioning.
同样重要的是，除了SSP之外，任何一方都不能解码临时GRUU，包括SSP服务的其他SIP PBX。要实现此属性，支持临时GROU的SSP必须创建并存储不对称密钥对：{K_e1，K_e2}。SSP对K_e1保密，而K_e2通过资源调配与SIP PBX共享。
All base64 encoding discussed in the following sections MUST use the character set and encoding defined in Section 4 of RFC 4648 [8], except that any trailing "=" characters are discarded on encoding and added as necessary to decode.
以下各节中讨论的所有base64编码必须使用RFC 4648[8]第4节中定义的字符集和编码，除非编码时丢弃任何尾随“=”字符，并根据需要添加以进行解码。
The following sections make use of the term "HMAC-SHA256-80" to describe a particular Hashed Message Authentication Code (HMAC) algorithm. In this document, HMAC-SHA256-80 is defined as the application of the SHA-256 [24] secure hashing algorithm, truncating the results to 80 bits by discarding the trailing (least-significant) bits.
以下各节使用术语“HMAC-SHA256-80”来描述特定的哈希消息认证码（HMAC）算法。在本文档中，HMAC-SHA256-80被定义为SHA-256[24]安全哈希算法的应用，通过丢弃尾随（最低有效）位将结果截断为80位。
An SSP that supports temporary GRUUs MUST include a "temp-gruu-cookie" parameter on all "Contact" header fields containing a "bnc" parameter in a 200-class REGISTER response. This "temp-gruu-cookie" MUST have the following properties:
支持临时GROU的SSP必须在200类寄存器响应中包含“bnc”参数的所有“联系人”头字段上包含“临时GROU cookie”参数。此“临时Gru cookie”必须具有以下属性：
1. It can be used by the SSP to uniquely identify the registration to which it corresponds.
1. SSP可以使用它来唯一标识其对应的注册。
2. It is encoded using base64. This allows the SIP-PBX to decode it into as compact a form as possible for use in its calculations.
2. 它是使用base64编码的。这允许SIP-PBX将其解码为尽可能紧凑的形式，以便在其计算中使用。
3. It is of a fixed length. This allows for its extraction once the SIP-PBX has concatenated a distinguisher onto it.
3. 它是固定长度的。一旦SIP-PBX连接了一个识别器，就可以提取它。
4. The temp-gruu-cookie MUST NOT be forgeable by any party. In other words, the SSP needs to be able to examine the cookie and validate that it was generated by the SSP.
4. 任何一方都不得伪造临时格鲁饼干。换句话说，SSP需要能够检查cookie并验证它是否由SSP生成。
5. The temp-gruu-cookie MUST be invariant during the course of a registration, including any refreshes to that registration. This property is important, as it allows the SIP-PBX to examine the temp-gruu-cookie to determine whether the temp-gruus it has issued to its UAs are still valid.
5. 临时gruu cookie在注册过程中必须保持不变，包括对该注册的任何刷新。此属性很重要，因为它允许SIP-PBX检查临时GRUcookie，以确定它向其UAs发出的临时GRUs是否仍然有效。
The above properties can be met using the following algorithm, which is non-normative. Implementors may chose to implement any algorithm of their choosing for generation of the temp-gruu-cookie, as long as it fulfills the five properties listed above.
使用以下非规范算法可以满足上述特性。实现者可以选择实现他们选择的任何算法来生成temp-grucookie，只要它满足上面列出的五个属性。
The registrar maintains a counter, I. This counter is 48 bits long and initialized to zero. This counter is persistently stored, using a back-end database or similar technique. When the registrar creates the first temporary GRUU for a particular SIP-PBX and instance ID (as defined by [20]), 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 contact and instance ID using the database, a persistent hash-map, 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 contact containing a "bnc" parameter and instance ID. Based on these rules, the hash-map
注册器维护一个计数器，即，该计数器为48位长，并初始化为零。使用后端数据库或类似技术持久存储此计数器。当注册器为特定SIP-PBX和实例ID（如[20]所定义）创建第一个临时GRUU时，注册器会记录计数器的当前值I_I，并增加数据库中的计数器。然后，注册器使用数据库、持久哈希映射或类似技术将I_I映射到联系人和实例ID。如果注册过期，因此不再有任何与绑定到GRUU的特定实例ID相关的联系人，则注册器将删除映射。类似地，如果临时Gru由于调用ID的更改而无效，则注册器移除从I_I到AOR和实例ID的当前映射，记录计数器I_j的当前值，并存储从I_j到包含“bnc”参数和实例ID的联系人的映射。根据这些规则，哈希映射
will contain a single mapping for each contact containing a "bnc" parameter and instance ID for which there is a currently valid registration.
将为每个联系人包含一个映射，该映射包含一个“bnc”参数和当前有效注册的实例ID。
The registrar maintains a symmetric key SK_a, which is regenerated every time the counter rolls over or is reset. When the counter rolls over or is reset, the registrar remembers the old value of SK_a for a while. To generate a temp-gruu-cookie, the registrar computes:
注册器维护一个对称密钥SK_a，每次计数器翻转或重置时都会重新生成该密钥。当计数器翻转或重置时，注册器会暂时记住SK_a的旧值。要生成临时Gru cookie，注册器将计算：
SA = HMAC(SK_a, I_i)
temp-gruu-cookie = base64enc(I_i || SA)
SA = HMAC(SK_a, I_i)
temp-gruu-cookie = base64enc(I_i || SA)
where || denotes concatenation. "HMAC" represents any suitably strong HMAC algorithm; see RFC 2104 [1] for a discussion of HMAC algorithms. One suitable HMAC algorithm for this purpose is HMAC-SHA256-80.
其中| |表示串联。“HMAC”表示任何适当的强HMAC算法；有关HMAC算法的讨论，请参见RFC 2104[1]。为此目的，一个合适的HMAC算法是HMAC-SHA256-80。
According to Section 3.2 of RFC 5627 [20], every registration refresh generates a new temp-gruu that is valid for as long as the contact remains registered. This property is both critical for the privacy properties of temp-gruu and is expected by UAs that implement the temp-gruu procedures. Nothing in this document should be construed as changing this fundamental temp-gruu property in any way. SIP-PBXes that implement temporary GRUUs MUST generate a new temp-gruu according to the procedures in this section for every registration or registration refresh from GRUU-supporting UAs attached to the SIP-PBX.
根据RFC 5627[20]第3.2节，每次注册刷新都会生成一个新的临时gruu，只要联系人保持注册状态，该临时gruu就有效。该属性对于temp gruu的隐私属性至关重要，并且是实现temp gruu过程的UAs所期望的。本文件中的任何内容均不得解释为以任何方式改变了该基本临时gruu属性。对于连接到SIP-PBX的gruu支持UAs的每次注册或注册刷新，实现临时GRUS的SIP PBX必须根据本节中的过程生成新的临时gruu。
Similarly, if the registration that a SIP-PBX has with its SSP expires or is terminated, then the temp-gruu cookie it maintains with the SSP will change. This change will invalidate all the temp-gruus the SIP-PBX has issued to its UAs. If the SIP-PBX tracks this information (e.g., to include <temp-gruu> elements in registration event bodies, as described in RFC 5628 [9]), it can determine that previously issued temp-gruus are invalid by observing a change in the temp-gruu-cookie provided to it by the SSP.
类似地，如果SIP-PBX对其SSP的注册过期或终止，则它对SSP维护的临时GROU cookie将更改。此更改将使SIP-PBX向其UAs发出的所有临时GRUU无效。如果SIP-PBX跟踪该信息（例如，如RFC 5628[9]中所述，在注册事件主体中包含<temp gru>元素），它可以通过观察SSP提供给它的temp gru cookie中的变化来确定先前发布的temp gru无效。
A SIP-PBX that issues temporary GRUUs to its UAs MUST maintain an HMAC key: PK_a. This value is used to validate that incoming GRUUs were generated by the SIP-PBX.
向其UAs发出临时GROU的SIP-PBX必须维护HMAC密钥：PK_A。此值用于验证传入GRUs是否由SIP-PBX生成。
To generate a new temporary GRUU for use by its own UAs, the SIP-PBX MUST generate a random distinguisher value: D. The length of this value is up to implementors, but it MUST be long enough to prevent collisions among all the temporary GRUUs issued by the SIP-PBX. A size of 80 bits or longer is RECOMMENDED. See RFC 4086 [16] for further considerations on the generation of random numbers in a security context. After generating the distinguisher D, the SIP-PBX MUST calculate:
要生成一个新的临时GRUU供其自己的UAs使用，SIP-PBX必须生成一个随机区分器值：D。该值的长度由实现者决定，但必须足够长，以防止SIP-PBX发出的所有临时GRUU之间发生冲突。建议大小为80位或更长。有关在安全上下文中生成随机数的更多注意事项，请参阅RFC 4086[16]。生成识别器D后，SIP-PBX必须计算：
M = base64dec(SSP-cookie) || D
E = RSA-Encrypt(K_e2, M)
PA = HMAC(PK_a, E)
M = base64dec(SSP-cookie) || D
E = RSA-Encrypt(K_e2, M)
PA = HMAC(PK_a, E)
Temp-Gruu-userpart = "tgruu." || base64(E) || "." || base64(PA)
Temp-Gruu-userpart = "tgruu." || base64(E) || "." || base64(PA)
where || denotes concatenation. "HMAC" represents any suitably strong HMAC algorithm; see RFC 2104 [1] for a discussion of HMAC algorithms. One suitable HMAC algorithm for this purpose is HMAC-SHA256-80.
其中| |表示串联。“HMAC”表示任何适当的强HMAC算法；有关HMAC算法的讨论，请参见RFC 2104[1]。为此目的，一个合适的HMAC算法是HMAC-SHA256-80。
Finally, the SIP-PBX adds a "gr" parameter to the temporary GRUU that can be used to uniquely identify the UA registration record to which the GRUU corresponds. The means of generation of the "gr" parameter are left to the implementor, as long as they satisfy the properties of a GRUU as described in RFC 5627 [20].
最后，SIP-PBX向临时GRU添加一个“gr”参数，该参数可用于唯一标识GRU所对应的UA注册记录。“gr”参数的生成方法留给实现者，只要它们满足RFC 5627[20]中描述的GRUU属性。
One valid approach for generation of the "gr" parameter is calculation of "E" and "A" as described in Appendix A.2 of RFC 5627 [20] and forming the "gr" parameter as:
生成“gr”参数的一种有效方法是计算RFC 5627[20]附录A.2中所述的“E”和“A”，并将“gr”参数形成为：
gr = base64enc(E) || base64enc(A)
gr = base64enc(E) || base64enc(A)
Using this procedure may result in a temporary GRUU returned to the registering UA by the SIP-PBX that looks similar to this:
使用此过程可能会导致SIP-PBX向注册UA返回一个临时GRUU，该GRUU类似于：
<allOneLine>
Contact: <sip:line-1@10.20.1.17>
;temp-gruu="sip:tgruu.MQyaRiLEd78RtaWkcP7N8Q.5qVbsasdo2pkKw@
ssp.example.com;gr=YZGSCjKD42ccxO08pA7HwAM4XNDIlMSL0HlA"
;+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
;expires=3600
</allOneLine>
<allOneLine>
Contact: <sip:line-1@10.20.1.17>
;temp-gruu="sip:tgruu.MQyaRiLEd78RtaWkcP7N8Q.5qVbsasdo2pkKw@
ssp.example.com;gr=YZGSCjKD42ccxO08pA7HwAM4XNDIlMSL0HlA"
;+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
;expires=3600
</allOneLine>
When the SSP proxy receives a request in which the user part begins with "tgruu.", it extracts the remaining portion and splits it at the "." character into E' and PA'. It discards PA'. It then computes E by performing a base64 decode of E'. Next, it computes:
当SSP代理收到一个用户部分以“tgruu”开头的请求时，它将提取剩余部分，并在“.”字符处将其拆分为“E”和“PA”。它抛弃了“爸爸”。然后，它通过执行E'的base64解码来计算E。接下来，它计算：
M = RSA-Decrypt(K_e1, E)
M=RSA解密（K_e1，E）
The SSP proxy extracts the fixed-length temp-gruu-cookie information from the beginning of this M and discards the remainder (which will be the distinguisher added by the SIP-PBX). It then validates this temp-gruu-cookie. If valid, it uses it to locate the corresponding SIP-PBX registration record and routes the message appropriately.
SSP代理从该M的开头提取固定长度的temp gruu cookie信息，并丢弃剩余的信息（这将是SIP-PBX添加的识别器）。然后它验证这个临时gruu cookie。如果有效，它将使用它来定位相应的SIP-PBX注册记录，并适当地路由消息。
If the non-normative, exemplary algorithm described in Section 7.1.2.1 is used to generate the temp-gruu-cookie, then this identification is performed by splitting the temp-gruu-cookie information into its 48-bit counter I and 80-bit HMAC. It validates that the HMAC matches the counter I and then uses counter I to locate the SIP-PBX registration record in its map. If the counter has rolled over or reset, this computation is performed with the current and previous SK_a.
如果使用第7.1.2.1节中描述的非规范性示例性算法来生成临时gruu cookie，则通过将临时gruu cookie信息拆分为其48位计数器I和80位HMAC来执行此标识。它验证HMAC是否与计数器I匹配，然后使用计数器I在其映射中定位SIP-PBX注册记录。如果计数器已翻转或重置，则使用当前和以前的SK_a执行此计算。
When the SIP-PBX receives a request in which the user part begins with "tgruu.", it extracts the remaining portion and splits it at the "." character into E' and PA'. It then computes E and PA by performing a base64 decode of E' and PA', respectively. Next, it computes:
当SIP-PBX接收到用户部分以“tgruu”开头的请求时，它提取剩余部分，并在“.”字符处将其拆分为E和PA。然后，它通过分别对E'和PA'执行base64解码来计算E和PA。接下来，它计算：
PAc = HMAC(PK_a, E)
PAc=HMAC（PK_a，E）
where HMAC is the HMAC algorithm used for the steps in Section 7.1.2.2. If this computed value for PAc does not match the value of PA extracted from the GRUU, then the GRUU is rejected as invalid.
其中，HMAC是用于第7.1.2.2节中步骤的HMAC算法。如果PAc的计算值与从GRUU提取的PA值不匹配，则GRUU将被视为无效而拒绝。
The SIP-PBX then uses the value of the "gr" parameter to locate the UA registration to which the GRUU corresponds, and routes the message accordingly.
然后，SIP-PBX使用“gr”参数的值来定位GRUU所对应的UA注册，并相应地路由消息。
Neither the SSP nor the SIP-PBX is required to support the registration event package defined by RFC 3680 [12]. However, if they do support the registration event package, they MUST conform to the behavior described in this section and its subsections.
SSP和SIP-PBX都不需要支持RFC 3680定义的注册事件包[12]。但是，如果它们确实支持注册事件包，则它们必须符合本节及其子节中描述的行为。
As this mechanism inherently deals with REGISTER transaction behavior, it is imperative to consider its impact on the registration event package defined by RFC 3680 [12]. In practice, there will be two main use cases for subscribing to registration data: learning about the overall registration state for the SIP-PBX and learning about the registration state for a single SIP-PBX AOR.
由于该机制固有地处理寄存器事务行为，因此必须考虑其对RFC 3680（12）定义的登记事件包的影响。实际上，订阅注册数据有两个主要用例：了解SIP-PBX的总体注册状态和了解单个SIP-PBX AOR的注册状态。
If the SIP-PBX (or another interested and authorized party) wishes to monitor or audit the registration state for all of the AORs currently registered to that SIP-PBX, it can subscribe to the SIP registration event package at the SIP-PBX's main URI -- that is, the URI used in the "To" header field of the REGISTER request.
如果SIP-PBX（或其他相关方和授权方）希望监视或审核当前注册到该SIP-PBX的所有AOR的注册状态，则它可以在SIP-PBX的主URI（即注册请求的“to”头字段中使用的URI）订阅SIP注册事件包。
The NOTIFY messages for such a subscription will contain a body that contains one record for each AOR associated with the SIP-PBX. The AORs will be in the format expected to be received by the SSP (e.g., "sip:+12145550105@ssp.example.com"), and the contacts will correspond to the mapped contact created by the registration (e.g., "sip:+12145550105@98.51.100.3").
此类订阅的通知消息将包含一个正文，其中包含与SIP-PBX关联的每个AOR的一条记录。AOR将采用SSP预期接收的格式（例如，“sip:+12145550105@ssp.example.com），联系人将对应于注册创建的映射联系人（例如，“sip:+12145550105@98.51.100.3").
In particular, the "bnc" parameter is forbidden from appearing in the body of a reg-event NOTIFY request unless the subscriber has indicated knowledge of the semantics of the "bnc" parameter. The means for indicating this support are out of scope of this document.
特别地，“bnc”参数被禁止出现在reg event NOTIFY请求的主体中，除非订户已经表示知道“bnc”参数的语义。表示该支持的方法不在本文件范围内。
Because the SSP does not necessarily know which GRUUs have been issued by the SIP-PBX to its associated UAs, these records will not generally contain the <temp-gruu> or <pub-gruu> elements defined in RFC 5628 [9]. This information can be learned, if necessary, by subscribing to the individual AOR registration state, as described in Section 7.2.2.
由于SSP不一定知道SIP-PBX向其相关UAs发出了哪些GRU，因此这些记录通常不包含RFC 5628[9]中定义的<temp gru>或<pub gru>元素。如有必要，可通过订阅第7.2.2节所述的单个AOR注册状态来了解该信息。
As described in Section 6, the SSP will generally re-target all requests addressed to an AOR owned by a SIP-PBX to that SIP-PBX according to the mapping established at registration time. Although policy at the SSP may override this generally expected behavior, proper behavior of the registration event package requires that all
如第6节所述，SSP通常会根据注册时建立的映射，将发往SIP-PBX拥有的AOR的所有请求重新定向到该SIP-PBX。虽然SSP上的策略可能会覆盖这种通常预期的行为，但注册事件包的正确行为要求
"reg" event SUBSCRIBE requests are processed by the SIP-PBX. As a consequence, the requirements on an SSP for processing registration event package SUBSCRIBE requests are not left to policy.
“reg”事件订阅请求由SIP-PBX处理。因此，SSP处理注册事件包订阅请求的要求不由策略决定。
If the SSP receives a SUBSCRIBE request for the registration event package with a Request URI that indicates an AOR registered via the "Bulk Number Contact" mechanism defined in this document, then the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that it would proxy an INVITE bound for that AOR, unless the SSP has and can maintain a copy of complete, accurate, and up-to-date information from the SIP-PBX (e.g., through an active back-end subscription).
如果SSP收到注册事件包的订阅请求，其请求URI表示通过本文档中定义的“批量号码联系人”机制注册的AOR，则SSP必须以代理该AOR绑定的INVITE的相同方式代理订阅SIP-PBX的AOR，除非SSP拥有并能够维护来自SIP-PBX的完整、准确和最新信息的副本（例如，通过活动后端订阅）。
If the Request URI in a SUBSCRIBE request for the registration event package indicates a contact that is registered by more than one SIP-PBX, then the SSP proxy will fork the SUBSCRIBE request to all the applicable SIP-PBXes. Similarly, if the Request URI corresponds to a contact that is both implicitly registered by a SIP-PBX and explicitly registered directly with the SSP proxy, then the SSP proxy will semantically fork the SUBSCRIBE request to the applicable SIP-PBX or SIP-PBXes and to the registrar function (which will respond with registration data corresponding to the explicit registrations at the SSP). The forking in both of these cases can be avoided if the SSP has and can maintain a copy of up-to-date information from the PBXes.
如果注册事件包的订阅请求中的请求URI指示由多个SIP-PBX注册的联系人，则SSP代理将向所有适用的SIP-PBX发出订阅请求。类似地，如果请求URI对应于由SIP-PBX隐式注册和直接向SSP代理显式注册的联系人，则SSP代理将从语义上将订阅请求分叉到适用的SIP-PBX或SIP PBX以及注册器功能（将以与SSP明确注册相对应的注册数据进行响应）。如果SSP拥有并能够维护来自PBX的最新信息的副本，则可以避免这两种情况下的分叉。
Section 4.9 of RFC 3680 [12] indicates that "a subscriber MUST NOT create multiple dialogs as a result of a single [registration event] subscription request". Consequently, subscribers who are not aware of the extension described by this document will accept only one dialog in response to such requests. In the case described in the preceding paragraph, this behavior will result in such clients receiving accurate but incomplete information about the registration state of an AOR. As an explicit change to the normative behavior of RFC 3680, this document stipulates that subscribers to the registration event package MAY create multiple dialogs as the result of a single subscription request. This will allow subscribers to create a complete view of an AOR's registration state.
RFC 3680[12]第4.9节指出，“订户不得因单个[注册事件]订阅请求而创建多个对话框”。因此，不知道本文档所述扩展的订阅者将只接受一个对话框来响应此类请求。在上段描述的情况下，这种行为将导致此类客户机接收到有关AOR注册状态的准确但不完整的信息。作为对RFC 3680规范行为的明确更改，本文件规定注册事件包的订阅者可根据单个订阅请求创建多个对话框。这将允许订阅者创建AOR注册状态的完整视图。
Defining the behavior as described above is important, since the reg-event subscriber is interested in finding out about the comprehensive list of devices associated with the AOR. Only the SIP-PBX will have authoritative access to this information. For example, if the user has registered multiple UAs with differing capabilities, the SSP will not know about the devices or their capabilities. By contrast, the SIP-PBX will.
如上所述定义行为很重要，因为reg事件订阅者希望了解与AOR关联的设备的综合列表。只有SIP-PBX有权访问此信息。例如，如果用户注册了多个具有不同功能的UAs，SSP将不知道这些设备或其功能。相比之下，SIP-PBX将成为一种新的解决方案。
If the SIP-PBX is not registered with the SSP when a registration event subscription for a contact that would be implicitly registered if the SIP-PBX were registered is received, then the SSP SHOULD accept the subscription and indicate that the user is not currently registered. Once the associated SIP-PBX is registered, the SSP SHOULD use the subscription migration mechanism defined in RFC 3265 [5] to migrate the subscription to the SIP-PBX.
如果在收到一个联系人的注册事件订阅（如果SIP-PBX已注册，则该联系人将隐式注册）时，SIP-PBX未向SSP注册，则SSP应接受该订阅并指示该用户当前未注册。注册相关SIP-PBX后，SSP应使用RFC 3265[5]中定义的订阅迁移机制将订阅迁移到SIP-PBX。
When a SIP-PBX receives a registration event subscription addressed to an AOR that has been registered using the bulk registration mechanism described in this document, then each resulting registration information document SHOULD contain an 'aor' attribute in its <registration/> element that corresponds to the AOR at the SSP.
当SIP-PBX接收到一个注册事件订阅，该订阅发往已使用本文档中描述的批量注册机制注册的AOR，则每个生成的注册信息文档应在其<registration/>元素中包含一个“AOR”属性，该属性对应于SSP上的AOR。
For example, consider a SIP-PBX that has registered with an SSP that has a domain of "ssp.example.com". The SIP-PBX used a Contact URI of "sip:198.51.100.3:5060;bnc". After such registration is complete, a registration event subscription arriving at the SSP with a Request URI of "sip:+12145550102@ssp.example.com" will be re-targeted to the SIP-PBX, with a Request URI of "sip:+12145550102@198.51.100.3:5060". The resulting registration document created by the SIP-PBX would contain a <registration/> element with an "aor" attribute of "sip:+12145550102@ssp.example.com".
例如，考虑一个SIP-PBX，它已经注册到一个SSP域，它有一个“SSP .Simult.com”的域。SIP-PBX使用的联系人URI为“SIP:198.51.100.3:5060；bnc”。注册完成后，注册事件订阅到达SSP，请求URI为“sip:+12145550102@ssp.example.com将重新定向到SIP-PBX，请求URI为“SIP:+12145550102@198.51.100.3:5060". SIP-PBX创建的结果注册文档将包含一个<registration/>元素，其“aor”属性为“SIP:+12145550102@ssp.example.com".
This behavior ensures that subscribers external to the system (and unaware of GIN (generate implicit numbers) procedures) will be able to find the relevant information in the registration document (since they will be looking for the publicly visible AOR, not the address used for sending information from the SSP to the SIP-PBX).
此行为确保系统外部的订阅者（不知道GIN（生成隐式数字）过程）能够在注册文档中找到相关信息（因为他们将查找公开可见的AOR，而不是用于将信息从SSP发送到SIP-PBX的地址）。
A SIP-PBX that supports both GRUU procedures and the registration event packages SHOULD implement the extension defined in RFC 5628 [9].
支持GRUU过程和注册事件包的SIP-PBX应实现RFC 5628[9]中定义的扩展。
RFC 5626 [19] defines a mechanism that allows UAs to establish long-lived TCP connections or UDP associations with a proxy in a way that allows bidirectional traffic between the proxy and the UA. This behavior is particularly important in the presence of NATs, and whenever TLS [18] security is required. Neither the SSP nor the SIP-PBX is required to support client-initiated connections.
RFC 5626[19]定义了一种机制，允许UAs以允许代理和UA之间双向通信的方式建立与代理的长期TCP连接或UDP关联。在NAT存在的情况下，以及需要TLS[18]安全性的情况下，此行为尤为重要。SSP和SIP-PBX都不需要支持客户端启动的连接。
Generally, the outbound mechanism works with the solution defined in this document, without any modifications. Implementors should note that the instance ID used between the SIP-PBX and the SSP's registrar
通常，出站机制与本文档中定义的解决方案配合使用，无需任何修改。实施者应注意，SIP-PBX和SSP注册器之间使用的实例ID
identifies the SIP-PBX itself, and not any of the UAs registered with the SIP-PBX. As a consequence, any attempts to use caller preferences (defined in RFC 3841 [14]) to target a specific instance are likely to fail. This shouldn't be an issue, as the preferred mechanism for targeting specific instances of a user agent is GRUU (see Section 7.1).
标识SIP-PBX本身，而不是向SIP-PBX注册的任何UAs。因此，任何使用调用方首选项（在RFC 3841[14]中定义）以特定实例为目标的尝试都可能失败。这不应该是一个问题，因为针对用户代理的特定实例的首选机制是GRUU（参见第7.1节）。
7.4. Non-Adjacent Contact Registration (Path) and Service-Route Discovery
7.4. 非相邻联系人注册（路径）和服务路由发现
RFC 3327 [10] defines a means by which a registrar and its associated proxy can be informed of a route that is to be used between the proxy and the registered user agent. The scope of the route created by a "Path" header field is contact specific; if an AOR has multiple contacts associated with it, the routes associated with each contact may be different from each other. Support for non-adjacent contact registration is required in all SSPs and SIP-PBXes implementing the multiple-AOR-registration protocol described in this document.
RFC 3327[10]定义了一种方法，通过该方法，注册商及其相关代理可以被告知代理和注册用户代理之间要使用的路由。“路径”标题字段创建的路由范围是特定于联系人的；如果AOR有多个关联的联系人，则与每个联系人关联的路由可能彼此不同。实现本文档中描述的多AOR注册协议的所有SSP和SIP PBX都需要支持非相邻联系人注册。
At registration time, any proxies between the user agent and the registrar may add themselves to the "Path" header field. By doing so, they request that any requests destined to the user agent as a result of the associated registration include them as part of the Route towards the user agent. Although the path mechanism does deliver the final path value to the registering UA, UAs typically ignore the value of the path.
在注册时，用户代理和注册器之间的任何代理都可以将自己添加到“路径”头字段。通过这样做，它们请求作为相关联的注册的结果而目的地到用户代理的任何请求包括它们作为朝向用户代理的路由的一部分。尽管路径机制将最终路径值传递给注册UA，但UA通常会忽略路径值。
To provide similar functionality in the opposite direction -- that is, to establish a route for requests sent by a registering UA -- RFC 3608 [11] defines a means by which a UA can be informed of a route that is to be used by the UA to route all outbound requests associated with the AOR used in the registration. This information is scoped to the AOR within the UA, and is not specific to the contact (or contacts) in the REGISTER request. Support of service route discovery is OPTIONAL in SSPs and SIP-PBXes.
为了在相反的方向上提供类似的功能——即为注册UA发送的请求建立路由——RFC 3608[11]定义了一种方法，通过该方法，UA可以被告知一条路由，该路由将被UA用来路由与注册中使用的AOR相关联的所有出站请求。此信息的范围是UA内的AOR，而不是特定于注册请求中的联系人。在SSP和SIP PBX中，服务路由发现的支持是可选的。
The registrar unilaterally generates the values of the service route using whatever local policy it wishes to apply. Although it is common to use the "Path" and/or "Route" header field information in the request in composing the service route, registrar behavior is not constrained in any way that requires it to do so.
注册器使用其希望应用的任何本地策略单方面生成服务路由的值。尽管在组成服务路由时，在请求中使用“路径”和/或“路由”头字段信息是常见的，但注册器行为不受任何要求它这样做的约束。
In considering the interaction between these mechanisms and the registration of multiple AORs in a single request, implementors of proxies, registrars, and intermediaries must keep in mind the following issues, which stem from the fact that GIN effectively registers multiple AORs and multiple contacts.
在考虑这些机制之间的交互以及在单个请求中注册多个AOR时，代理、注册器和中介的实现者必须记住以下问题，这些问题源于GIN有效注册多个AOR和多个联系人的事实。
First, all location service records that result from expanding a single Contact URI containing a "bnc" parameter will necessarily share a single path. Proxies will be unable to make policy decisions on a contact-by-contact basis regarding whether to include themselves in the path. Second, and similarly, all AORs on the SIP-PBX that are registered with a common REGISTER request will be forced to share a common service route.
首先，扩展包含“bnc”参数的单个联系人URI所产生的所有位置服务记录都必须共享一条路径。代理将无法在逐个联系人的基础上就是否将自己包括在路径中做出决策。第二，同样，SIP-PBX上所有使用公共注册请求注册的AOR将被迫共享公共服务路由。
One interesting technique that the path and service route mechanisms enable is the inclusion of a token or cookie in the user portion of the service route or path entries. This token or cookie may convey information to proxies about the identity, capabilities, and/or policies associated with the user. Since this information will be shared among several AORs and several contacts when multiple AOR registration is employed, care should be taken to ensure that doing so is acceptable for all AORs and all contacts registered in a single REGISTER request.
路径和服务路由机制支持的一种有趣的技术是在服务路由或路径条目的用户部分包含令牌或cookie。该令牌或cookie可向代理传递关于与用户相关联的身份、能力和/或策略的信息。由于在使用多个AOR注册时，该信息将在多个AOR和多个联系人之间共享，因此应注意确保所有AOR和在单个注册请求中注册的所有联系人都可以接受该信息。
Note that the following examples elide any steps related to authentication. This is done for the sake of clarity. Actual deployments will need to provide a level of authentication appropriate to their system.
请注意，以下示例省略了与身份验证相关的任何步骤。这是为了清楚起见。实际部署将需要提供适合其系统的身份验证级别。
This example shows the message flows for a basic bulk REGISTER transaction, followed by an INVITE addressed to one of the registered UAs. Example messages are shown after the sequence diagram.
此示例显示了基本批量注册事务的消息流，随后是一个发送到其中一个已注册UAs的INVITE。示例消息显示在序列图之后。
Internet SSP SIP-PBX
| | |
| |(1) REGISTER |
| |Contact:<sip:198.51.100.3;bnc> |
| |<--------------------------------|
| | |
| |(2) 200 OK |
| |-------------------------------->|
| | |
|(3) INVITE | |
|sip:+12145550105@ssp.example.com| |
|------------------------------->| |
| | |
| |(4) INVITE |
| |sip:+12145550105@198.51.100.3 |
| |-------------------------------->|
Internet SSP SIP-PBX
| | |
| |(1) REGISTER |
| |Contact:<sip:198.51.100.3;bnc> |
| |<--------------------------------|
| | |
| |(2) 200 OK |
| |-------------------------------->|
| | |
|(3) INVITE | |
|sip:+12145550105@ssp.example.com| |
|------------------------------->| |
| | |
| |(4) INVITE |
| |sip:+12145550105@198.51.100.3 |
| |-------------------------------->|
(1) The SIP-PBX registers with the SSP for a range of AORs.
(1) SIP-PBX向SSP注册一系列AOR。
REGISTER sip:ssp.example.com SIP/2.0
Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: <sip:pbx@ssp.example.com>
From: <sip:pbx@ssp.example.com>;tag=a23589
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Proxy-Require: gin
Require: gin
Supported: path
Contact: <sip:198.51.100.3:5060;bnc>
Expires: 7200
Content-Length: 0
REGISTER sip:ssp.example.com SIP/2.0
Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: <sip:pbx@ssp.example.com>
From: <sip:pbx@ssp.example.com>;tag=a23589
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Proxy-Require: gin
Require: gin
Supported: path
Contact: <sip:198.51.100.3:5060;bnc>
Expires: 7200
Content-Length: 0
(3) The SSP receives a request for an AOR assigned to the SIP-PBX.
(3) SSP接收分配给SIP-PBX的AOR请求。
INVITE sip:+12145550105@ssp.example.com SIP/2.0
Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
Max-Forwards: 69
To: <sip:2145550105@some-other-place.example.net>
From: <sip:gsmith@example.org>;tag=456248
Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
CSeq: 24762 INVITE
Contact: <sip:line-1@192.0.2.178:2081>
Content-Type: application/sdp
Content-Length: ...
INVITE sip:+12145550105@ssp.example.com SIP/2.0
Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
Max-Forwards: 69
To: <sip:2145550105@some-other-place.example.net>
From: <sip:gsmith@example.org>;tag=456248
Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
CSeq: 24762 INVITE
Contact: <sip:line-1@192.0.2.178:2081>
Content-Type: application/sdp
Content-Length: ...
<sdp body here>
<sdp正文在此>
(4) The SSP re-targets the incoming request according to the information received from the SIP-PBX at registration time.
(4) SSP根据注册时从SIP-PBX接收的信息重新确定传入请求的目标。
INVITE sip:+12145550105@198.51.100.3 SIP/2.0
Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
Max-Forwards: 68
To: <sip:2145550105@some-other-place.example.net>
From: <sip:gsmith@example.org>;tag=456248
Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
CSeq: 24762 INVITE
Contact: <sip:line-1@192.0.2.178:2081>
Content-Type: application/sdp
Content-Length: ...
INVITE sip:+12145550105@198.51.100.3 SIP/2.0
Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
Max-Forwards: 68
To: <sip:2145550105@some-other-place.example.net>
From: <sip:gsmith@example.org>;tag=456248
Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
CSeq: 24762 INVITE
Contact: <sip:line-1@192.0.2.178:2081>
Content-Type: application/sdp
Content-Length: ...
<sdp body here>
<sdp正文在此>
This example shows a bulk REGISTER transaction with the SSP making use of the "Path" header field extension [10]. This allows the SSP to designate a domain on the incoming Request URI that does not necessarily resolve to the SIP-PBX when the SSP applies RFC 3263 procedures to it.
此示例显示了SSP利用“路径”头字段扩展进行的批量寄存器事务[10]。这允许SSP在传入请求URI上指定一个域，当SSP对其应用RFC 3263过程时，该域不一定解析为SIP-PBX。
Internet SSP SIP-PBX
| | |
| |(1) REGISTER |
| |Path:<sip:pbx@198.51.100.3;lr> |
| |Contact:<sip:pbx.example;bnc> |
| |<--------------------------------|
| | |
| |(2) 200 OK |
| |-------------------------------->|
| | |
|(3) INVITE | |
|sip:+12145550105@ssp.example.com| |
|------------------------------->| |
| | |
| |(4) INVITE |
| |sip:+12145550105@pbx.example |
| |Route:<sip:pbx@198.51.100.3;lr> |
| |-------------------------------->|
Internet SSP SIP-PBX
| | |
| |(1) REGISTER |
| |Path:<sip:pbx@198.51.100.3;lr> |
| |Contact:<sip:pbx.example;bnc> |
| |<--------------------------------|
| | |
| |(2) 200 OK |
| |-------------------------------->|
| | |
|(3) INVITE | |
|sip:+12145550105@ssp.example.com| |
|------------------------------->| |
| | |
| |(4) INVITE |
| |sip:+12145550105@pbx.example |
| |Route:<sip:pbx@198.51.100.3;lr> |
| |-------------------------------->|
(1) The SIP-PBX registers with the SSP for a range of AORs. It includes the form of the URI it expects to receive in the Request URI in its "Contact" header field, and it includes information that routes to the SIP-PBX in the "Path" header field.
(1) SIP-PBX向SSP注册一系列AOR。它在“Contact”头字段中包含它希望在请求URI中接收的URI的形式，并在“Path”头字段中包含路由到SIP-PBX的信息。
REGISTER sip:ssp.example.com SIP/2.0
Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: <sip:pbx@ssp.example.com>
From: <sip:pbx@ssp.example.com>;tag=a23589
Call-ID: 326983936836068@998sdasdh09
CSeq: 1826 REGISTER
Proxy-Require: gin
Require: gin
Supported: path
Path: <sip:pbx@198.51.100.3:5060;lr>
Contact: <sip:pbx.example;bnc>
Expires: 7200
Content-Length: 0
REGISTER sip:ssp.example.com SIP/2.0
Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: <sip:pbx@ssp.example.com>
From: <sip:pbx@ssp.example.com>;tag=a23589
Call-ID: 326983936836068@998sdasdh09
CSeq: 1826 REGISTER
Proxy-Require: gin
Require: gin
Supported: path
Path: <sip:pbx@198.51.100.3:5060;lr>
Contact: <sip:pbx.example;bnc>
Expires: 7200
Content-Length: 0
(3) The SSP receives a request for an AOR assigned to the SIP-PBX.
(3) SSP接收分配给SIP-PBX的AOR请求。
INVITE sip:+12145550105@ssp.example.com SIP/2.0
Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
Max-Forwards: 69
To: <sip:2145550105@some-other-place.example.net>
From: <sip:gsmith@example.org>;tag=456248
Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
CSeq: 24762 INVITE
Contact: <sip:line-1@192.0.2.178:2081>
Content-Type: application/sdp
Content-Length: ...
INVITE sip:+12145550105@ssp.example.com SIP/2.0
Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
Max-Forwards: 69
To: <sip:2145550105@some-other-place.example.net>
From: <sip:gsmith@example.org>;tag=456248
Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
CSeq: 24762 INVITE
Contact: <sip:line-1@192.0.2.178:2081>
Content-Type: application/sdp
Content-Length: ...
<sdp body here>
<sdp正文在此>
(4) The SSP re-targets the incoming request according to the information received from the SIP-PBX at registration time. Per the normal processing associated with "Path", it will insert the "Path" value indicated by the SIP-PBX at registration time in a "Route" header field, and set the Request URI to the registered contact.
(4) SSP根据注册时从SIP-PBX接收的信息重新确定传入请求的目标。根据与“路径”相关联的正常处理，它将在注册时在“路由”头字段中插入SIP-PBX指示的“路径”值，并将请求URI设置为注册联系人。
INVITE sip:+12145550105@pbx.example SIP/2.0
Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
Route: <sip:pbx@198.51.100.3:5060;lr>
Max-Forwards: 68
To: <sip:2145550105@some-other-place.example.net>
From: <sip:gsmith@example.org>;tag=456248
Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
CSeq: 24762 INVITE
Contact: <sip:line-1@192.0.2.178:2081>
Content-Type: application/sdp
Content-Length: ...
INVITE sip:+12145550105@pbx.example SIP/2.0
Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
Route: <sip:pbx@198.51.100.3:5060;lr>
Max-Forwards: 68
To: <sip:2145550105@some-other-place.example.net>
From: <sip:gsmith@example.org>;tag=456248
Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
CSeq: 24762 INVITE
Contact: <sip:line-1@192.0.2.178:2081>
Content-Type: application/sdp
Content-Length: ...
<sdp body here>
<sdp正文在此>
This document registers a new SIP option tag to indicate support for the mechanism it defines, two new SIP URI parameters, and a "Contact" header field parameter. The process governing registration of these protocol elements is outlined in RFC 5727 [21].
本文档注册了一个新的SIP选项标记，以指示对其定义的机制的支持、两个新的SIP URI参数和一个“Contact”头字段参数。RFC 5727[21]概述了这些协议要素的注册过程。
This section defines a new SIP option tag per the guidelines in Section 27.1 of RFC 3261 [3].
本节根据RFC 3261[3]第27.1节中的指南定义了一个新的SIP选项标签。
Name: gin
姓名：杜松子酒
Description: This option tag is used to identify the extension that provides registration for Multiple Phone Numbers in SIP. When present in a "Require" or "Proxy-Require" header field of a REGISTER request, it indicates that support for this extension is required of registrars and proxies, respectively, that are a party to the registration transaction.
描述：此选项标签用于标识在SIP中为多个电话号码提供注册的分机。当出现在注册请求的“Require”或“Proxy Require”标题字段中时，表示注册事务的一方注册人和代理分别需要支持此扩展。
Reference: RFC 6140
参考：RFC6140
This specification defines two new SIP URI parameters, as per the registry created by RFC 3969 [7].
根据RFC 3969[7]创建的注册表，本规范定义了两个新的SIP URI参数。
Parameter Name: bnc
参数名称：bnc
Predefined Values: No (no values are allowed)
预定义值：否（不允许有值）
Reference: RFC 6140
参考：RFC6140
Parameter Name: sg
参数名称：sg
Predefined Values: No
预定义值：否
Reference: RFC 6140
参考：RFC6140
This section defines a new SIP header field parameter per the registry created by RFC 3968 [6].
本节根据RFC 3968创建的注册表定义一个新的SIP头字段参数[6]。
Header field: Contact
标题字段：联系人
Parameter name: temp-gruu-cookie
参数名称：临时GROU cookie
Predefined values: No
预定义值：否
Reference: RFC 6140
参考：RFC6140
The change proposed for the mechanism described in this document takes the unprecedented step of extending the previously defined REGISTER method to apply to more than one AOR. In general, this kind of change has the potential to cause problems at intermediaries -- such as proxies -- that are party to the REGISTER transaction. In particular, such intermediaries may attempt to apply policy to the user indicated in the "To" header field (i.e., the SIP-PBX's identity), without any knowledge of the multiple AORs that are being implicitly registered.
本文档中描述的机制的更改采取了前所未有的步骤，将先前定义的寄存器方法扩展到应用于多个AOR。一般来说，这种变化有可能在作为注册交易一方的中介机构（如代理机构）上造成问题。具体地说，这些中介可以尝试将策略应用于在“to”报头字段中指示的用户（即，SIP-PBX的身份），而不知道正在隐式注册的多个aor。
The mechanism defined by this document solves this issue by adding an option tag to a "Proxy-Require" header field in such REGISTER requests. Proxies that are unaware of this mechanism will not process the requests, preventing them from misapplying policy. Proxies that process requests with this option tag are clearly aware of the nature of the REGISTER request and can make reasonable policy decisions.
本文档定义的机制通过向此类注册请求中的“Proxy Require”头字段添加选项标记来解决此问题。不知道此机制的代理将不会处理请求，从而防止它们误用策略。处理带有此选项标记的请求的代理清楚地知道注册请求的性质，并且可以做出合理的策略决策。
As noted in Section 7.4, intermediaries need to take care if they use a policy token in the path and service route mechanisms, as doing so will cause them to apply the same policy to all users serviced by the same SIP-PBX. This may frequently be the correct behavior, but circumstances can arise in which differentiation of user policy is required.
如第7.4节所述，如果中介机构在路径和服务路由机制中使用策略令牌，则需要小心，因为这样做会导致中介机构将相同的策略应用于由相同SIP-PBX服务的所有用户。这通常是正确的行为，但在需要区分用户策略的情况下可能会出现。
Section 7.4 also notes that these techniques use a token or cookie in the "Path" and/or "Service-Route" header values, and that this value will be shared among all AORs associated with a single registration. Because this information will be visible to user agents under certain conditions, proxy designers using this mechanism in conjunction with the techniques described in this document need to take care that doing so does not leak sensitive information.
第7.4节还指出，这些技术在“路径”和/或“服务路由”头值中使用令牌或cookie，并且该值将在与单个注册相关的所有AOR之间共享。由于在某些情况下，用户代理可以看到这些信息，因此使用此机制并结合本文档中描述的技术的代理设计人员需要注意，这样做不会泄漏敏感信息。
One of the key properties of the outbound client connection mechanism discussed in Section 7.3 is the assurance that a single connection is associated with a single user and cannot be hijacked by other users. With the mechanism defined in this document, such connections necessarily become shared between users. However, the only entity in a position to hijack calls as a consequence is the SIP-PBX itself. Because the SIP-PBX acts as a registrar for all the potentially affected users, it already has the ability to redirect any such communications as it sees fit. In other words, the SIP-PBX must be trusted to handle calls in an appropriate fashion, and the use of the outbound connection mechanism introduces no additional vulnerabilities.
第7.3节中讨论的出站客户端连接机制的关键属性之一是确保单个连接与单个用户关联，并且不会被其他用户劫持。通过本文档中定义的机制，用户之间必须共享此类连接。然而，唯一能够劫持呼叫的实体是SIP-PBX本身。由于SIP-PBX充当所有潜在受影响用户的注册器，因此它已经能够根据需要重定向任何此类通信。换句话说，必须信任SIP-PBX以适当的方式处理呼叫，并且使用出站连接机制不会引入额外的漏洞。
The ability to learn the identity and registration state of every user on the PBX (as described in Section 7.2.1) is invaluable for diagnostic and administrative purposes. For example, this allows the SIP-PBX to determine whether all its extensions are properly registered with the SSP. However, this information can also be highly sensitive, as many organizations may not wish to make their entire list of phone numbers available to external entities. Consequently, SSP servers are advised to use explicit (i.e., white-list) and configurable policies regarding who can access this information, with very conservative defaults (e.g., an empty access list or an access list consisting only of the PBX itself).
了解PBX上每个用户的身份和注册状态的能力（如第7.2.1节所述）对于诊断和管理目的是非常宝贵的。例如，这允许SIP-PBX确定其所有扩展是否正确注册到SSP。然而，这些信息也可能是高度敏感的，因为许多组织可能不希望将其全部电话号码列表提供给外部实体。因此，建议SSP服务器使用关于谁可以访问此信息的明确（即白名单）和可配置策略，默认值非常保守（例如，空访问列表或仅由PBX本身组成的访问列表）。
The procedure for the generation of temporary GRUUs requires the use of an HMAC to detect any tampering that external entities may attempt to perform on the contents of a temporary GRUU. The mention of HMAC-SHA256-80 in Section 7.1.2 is intended solely as an example of a suitable HMAC algorithm. Since all HMACs used in this document are generated and consumed by the same entity, the choice of an actual HMAC algorithm is entirely up to an implementation, provided that the cryptographic properties are sufficient to prevent third parties from spoofing GRUU-related information.
生成临时GRU的过程需要使用HMAC来检测外部实体可能试图对临时GRU内容执行的任何篡改。第7.1.2节中提到的HMAC-SHA256-80仅作为适用HMAC算法的示例。由于本文档中使用的所有HMAC均由同一实体生成和使用，因此实际HMAC算法的选择完全取决于实现，前提是加密属性足以防止第三方欺骗GRUU相关信息。
The procedure for the generation of temporary GRUUs also requires the use of RSA keys. The selection of the proper key length for such keys requires careful analysis, taking into consideration the current and foreseeable speed of processing for the period of time during which GRUUs must remain anonymous, as well as emerging cryptographic analysis methods. The most recent guidance from RSA Laboratories [25] suggests a key length of 2048 bits for data that needs protection through the year 2030, and a length of 3072 bits thereafter.
生成临时GROU的过程还需要使用RSA密钥。为这些密钥选择适当的密钥长度需要仔细分析，同时考虑到GROUS必须保持匿名期间当前和可预见的处理速度，以及新兴的密码分析方法。RSA Laboratories[25]的最新指导建议，到2030年需要保护的数据的密钥长度为2048位，之后的密钥长度为3072位。
Similarly, implementors are warned to take precautionary measures to prevent unauthorized disclosure of the private key used in GRUU generation. Any such disclosure would result in the ability to correlate temporary GRUUs to each other and, potentially, to their associated PBXes.
类似地，实现者被警告采取预防措施，以防止未经授权泄露GRUU生成中使用的私钥。任何此类披露都会导致临时GRU相互关联，并可能关联到其关联的PBX。
Further, the use of RSA decryption when processing GRUUs received from arbitrary parties can be exploited by Denial-of-Service (DoS) attackers to amplify the impact of an attack: because of the presence of a cryptographic operation in the processing of such messages, the CPU load may be marginally higher when the attacker uses (valid or invalid) temporary GRUUs in the messages employed by such an attack. Normal DoS mitigation techniques, such as rate-limiting processing of received messages, should help to reduce the impact of this issue as well.
此外，拒绝服务（DoS）攻击者可以利用在处理从任意方收到的Gruu时使用RSA解密来扩大攻击的影响：由于在处理此类消息时存在加密操作，因此攻击者使用（有效或无效）时CPU负载可能会略高一些这种攻击所使用的消息中的临时性的GRUUs。正常的DoS缓解技术，如对接收到的消息进行速率限制处理，也应有助于减少此问题的影响。
Finally, good security practices should be followed regarding the duration an RSA key is used. For implementors, this means that systems MUST include an easy way to update the public key provided to the SIP-PBX. To avoid immediately invalidating all currently issued temporary GRUUs, the SSP servers SHOULD keep the retired RSA key around for a grace period before discarding it. If decryption fails based on the new RSA key, then the SSP server can attempt to use the retired key instead. By contrast, the SIP-PBXes MUST discard the retired public key immediately and exclusively use the new public key.
最后，在使用RSA密钥的持续时间方面，应遵循良好的安全实践。对于实现者来说，这意味着系统必须包括更新提供给SIP-PBX的公钥的简单方法。为避免立即使所有当前发布的临时GRUU无效，SSP服务器应在丢弃失效的RSA密钥之前将其保留一段宽限期。如果基于新RSA密钥的解密失败，则SSP服务器可以尝试改用失效密钥。相反，SIP PBX必须立即丢弃失效的公钥，并专门使用新公钥。
This document represents the hard work of many people in the IETF MARTINI working group and the IETF RAI community as a whole. Particular thanks are owed to John Elwell for his requirements analysis of the mechanism described in this document, to Dean Willis for his analysis of the interaction between this mechanism and the "Path" and "Service-Route" extensions, to Cullen Jennings for his analysis of the interaction between this mechanism and the SIP Outbound extension, and to Richard Barnes for his detailed security analysis of the GRUU construction algorithm. Thanks to Eric Rescorla, whose text in the appendix of RFC 5627 was lifted directly to provide substantial portions of Section 7.1.2. Finally, thanks to Bernard Aboba, Francois Audet, Brian Carpenter, John Elwell, David Hancock, Ted Hardie, Martien Huysmans, Cullen Jennings, Alan Johnston, Hadriel Kaplan, Paul Kyzivat, and Radia Perlman for their careful reviews of and constructive feedback on this document.
本文件代表了IETF MARTINI工作组和整个IETF RAI社区中许多人的辛勤工作。特别感谢John Elwell对本文件所述机制的需求分析，感谢Dean Willis对该机制与“路径”和“服务路由”扩展之间的交互作用的分析，感谢Cullen Jennings对该机制与SIP出站扩展之间交互作用的分析，并向Richard Barnes详细介绍了GRUU构造算法的安全性分析。感谢Eric Rescorla，其RFC 5627附录中的文本被直接删除，以提供第7.1.2节的实质部分。最后，感谢Bernard Aboba、Francois Audet、Brian Carpenter、John Elwell、David Hancock、Ted Hardie、Martien Huysmans、Cullen Jennings、Alan Johnston、Hadriel Kaplan、Paul Kyzivat和Radia Perlman对本文件的仔细审查和建设性反馈。
[1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[1] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] 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.
[3] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[4] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[6] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[6] Camarillo，G.，“会话启动协议（SIP）的Internet分配号码管理局（IANA）头字段参数注册表”，BCP 98，RFC 3968，2004年12月。
[7] 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.
[7] Camarillo，G.，“会话启动协议（SIP）的Internet分配号码管理局（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，2004年12月。
[8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[8] Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[9] Kyzivat, P., "Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)", RFC 5628, October 2009.
[9] Kyzivat，P.，“会话启动协议（SIP）全局可路由用户代理URI（GROUS）的注册事件包扩展”，RFC 56282009年10月。
[10] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[10] Willis，D.和B.Hoeneisen，“用于注册非相邻联系人的会话启动协议（SIP）扩展头字段”，RFC 3327，2002年12月。
[11] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003.
[11] Willis，D.和B.Hoeneisen，“注册期间服务路由发现的会话启动协议（SIP）扩展头字段”，RFC 3608，2003年10月。
[12] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[12] Rosenberg，J.，“用于注册的会话启动协议（SIP）事件包”，RFC 36802004年3月。
[13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[13] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[14] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[14] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[15] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[15] Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[16] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[16] Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[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] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[18] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[19] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[19] Jennings，C.，Mahy，R.，和F.Audet，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
[20] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[20] Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GROUS）”，RFC 5627，2009年10月。
[21] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.
[21] Peterson，J.，Jennings，C.，和R.Sparks，“会话启动协议（SIP）和实时应用程序和基础设施领域的变更过程”，BCP 67，RFC 5727，2010年3月。
[22] Elwell, J. and H. Kaplan, "Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)", RFC 5947, September 2010.
[22] Elwell，J.和H.Kaplan，“会话启动协议（SIP）中对多地址记录（AOR）可达性信息的要求”，RFC 5947，2010年9月。
[23] Kaplan, H., "GIN with Literal AORs for SIP in SSPs (GLASS)", Work in Progress, November 2010.
[23] Kaplan，H.，“SSP（玻璃）中SIP的GIN和文字AOR”，正在进行的工作，2010年11月。
[24] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008, <http:// csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf>.
[24] 国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-3，2008年10月，<http://csrc.nist.gov/publications/FIPS/fips180-3/fips180-3_final.pdf>。
[25] Kaliski, B., "TWIRL and RSA Key Size", May 2003.
[25] Kaliski，B.，“旋转和RSA密钥大小”，2003年5月。
The document "Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)" [22] contains a list of requirements and desired properties for a mechanism to register multiple AORs with a single SIP transaction. This section evaluates those requirements against the mechanism described in this document.
文档“会话启动协议（SIP）中多个记录地址（AOR）可达性信息的要求”[22]包含一系列要求和所需属性，用于向单个SIP事务注册多个AOR的机制。本节根据本文档中描述的机制评估这些需求。
REQ1 - The mechanism MUST allow a SIP-PBX to enter into a trunking arrangement with an SSP whereby the two parties have agreed on a set of telephone numbers assigned to the SIP-PBX.
要求1-该机制必须允许SIP-PBX与SSP达成中继安排，双方据此商定分配给SIP-PBX的一组电话号码。
The requirement is satisfied.
满足要求。
REQ2 - The mechanism MUST allow a set of assigned telephone numbers to comprise E.164 numbers, which can be in contiguous ranges, discrete, or in any combination of the two.
REQ2-该机制必须允许一组分配的电话号码包含例如164个号码，这些号码可以是连续的、离散的，也可以是两者的任意组合。
The requirement is satisfied. The Direct Inward Dialing (DID) numbers associated with a registration are established by bilateral agreement between the SSP and the SIP-PBX; they are not part of the mechanism described in this document.
满足要求。与注册相关的直接向内拨号（DID）号码由SSP和SIP-PBX之间的双边协议确定；它们不是本文件所述机制的一部分。
REQ3 - The mechanism MUST allow a SIP-PBX to register reachability information with its SSP, in order to enable the SSP to route to the SIP-PBX inbound requests targeted at assigned telephone numbers.
REQ3-该机制必须允许SIP-PBX向其SSP注册可达性信息，以使SSP能够路由到针对指定电话号码的SIP-PBX入站请求。
The requirement is satisfied.
满足要求。
REQ4 - The mechanism MUST allow UAs attached to a SIP-PBX to register with the SIP-PBX for AORs based on assigned telephone numbers, in order to receive requests targeted at those telephone numbers, without needing to involve the SSP in the registration process.
需求4-该机制必须允许连接到SIP-PBX的UAs根据分配的电话号码向SIP-PBX注册AOR，以便接收针对这些电话号码的请求，而无需SSP参与注册过程。
The requirement is satisfied; in the presumed architecture, SIP-PBX UAs register with the SIP-PBX and require no interaction with the SSP.
满足要求；在假定的体系结构中，SIP-PBX UAs向SIP-PBX注册，不需要与SSP交互。
REQ5 - The mechanism MUST allow a SIP-PBX to handle requests originating at its own UAs and targeted at its assigned telephone numbers, without routing those requests to the SSP.
REQ5-该机制必须允许SIP-PBX处理源自其自身UAs并针对其指定电话号码的请求，而无需将这些请求路由到SSP。
The requirement is satisfied; SIP-PBXes may recognize their own DID numbers and GRUUs, and perform on-SIP-PBX routing without sending the requests to the SSP.
满足要求；SIP PBX可以识别自己的DID号码和GRUS，并在SIP PBX路由上执行，而无需向SSP发送请求。
REQ6 - The mechanism MUST allow a SIP-PBX to receive requests to its assigned telephone numbers originating outside the SIP-PBX and arriving via the SSP, so that the SIP-PBX can route those requests onwards to its UAs, as it would for internal requests to those telephone numbers.
REQ6-该机制必须允许SIP-PBX接收来自SIP-PBX外部并通过SSP到达的对其分配电话号码的请求，以便SIP-PBX可以将这些请求转发到其UAs，就像对这些电话号码的内部请求一样。
The requirement is satisfied
满足要求
REQ7 - The mechanism MUST provide a means whereby a SIP-PBX knows which of its assigned telephone numbers an inbound request from its SSP is targeted at.
REQ7-该机制必须提供一种手段，使SIP-PBX知道来自其SSP的入站请求针对的是其分配的电话号码中的哪一个。
The requirement is satisfied. For ordinary calls and calls using public GRUUs, the DID number is indicated in the user portion of the Request URI. For calls using Temp GRUUs constructed with the mechanism described in Section 7.1.2, the "gr" parameter provides a correlation token the SIP-PBX can use to identify to which UA the call should be routed.
满足要求。对于普通调用和使用公共GROUS的调用，DID号码在请求URI的用户部分中指示。对于使用第7.1.2节所述机制构造的临时Grus的呼叫，“gr”参数提供SIP-PBX可用于标识呼叫应路由到哪个UA的相关令牌。
REQ8 - The mechanism MUST provide a means of avoiding problems due to one side using the mechanism and the other side not.
要求8-该机构必须提供一种方法，以避免由于一方使用该机构而另一方未使用该机构而导致的问题。
The requirement is satisfied through the 'gin' option tag and the 'bnc' Contact URI parameter.
通过“gin”选项标记和“bnc”联系人URI参数满足要求。
REQ9 - The mechanism MUST observe SIP backwards compatibility principles.
REQ9-机制必须遵守SIP向后兼容性原则。
The requirement is satisfied through the 'gin' option tag.
通过“gin”选项标签满足要求。
REQ10 - The mechanism MUST work in the presence of a sequence of intermediate SIP entities on the SIP-PBX-to-SSP interface (i.e., between the SIP-PBX and the SSP's domain proxy), where those intermediate SIP entities indicated during registration a need to be on the path of inbound requests to the SIP-PBX.
REQ10-该机制必须在SIP PBX到SSP接口（即SIP-PBX和SSP的域代理之间）上存在一系列中间SIP实体的情况下工作，其中，注册期间指示的这些中间SIP实体需要位于SIP-PBX的入站请求路径上。
The requirement is satisfied through the use of the path mechanism defined in RFC 3327 [10]
通过使用RFC 3327[10]中定义的路径机制，可以满足该要求
REQ11 - The mechanism MUST work when a SIP-PBX obtains its IP address dynamically.
REQ11-当SIP-PBX动态获取其IP地址时，该机制必须工作。
The requirement is satisfied by allowing the SIP-PBX to use an IP address in the Bulk Number Contact URI contained in a REGISTER "Contact" header field.
通过允许SIP-PBX在寄存器“联系人”头字段中包含的批量号码联系人URI中使用IP地址，可以满足该要求。
REQ12 - The mechanism MUST work without requiring the SIP-PBX to have a domain name or the ability to publish its domain name in the DNS.
REQ12-该机制必须在不要求SIP-PBX拥有域名或能够在DNS中发布其域名的情况下工作。
The requirement is satisfied by allowing the SIP-PBX to use an IP address in the Bulk Number Contact URI contained in a REGISTER "Contact" header field.
通过允许SIP-PBX在寄存器“联系人”头字段中包含的批量号码联系人URI中使用IP地址，可以满足该要求。
REQ13 - For a given SIP-PBX and its SSP, there MUST be no impact on other domains, which are expected to be able to use normal RFC 3263 procedures to route requests, including requests needing to be routed via the SSP in order to reach the SIP-PBX.
REQ13-对于给定的SIP-PBX及其SSP，不得影响其他域，这些域预计能够使用正常的RFC 3263过程路由请求，包括需要通过SSP路由以到达SIP-PBX的请求。
The requirement is satisfied by allowing the domain name in the Request URI used by external entities to resolve to the SSP's servers via normal RFC 3263 resolution procedures.
通过允许外部实体使用的请求URI中的域名通过正常的RFC 3263解析过程解析到SSP的服务器，可以满足该要求。
REQ14 - The mechanism MUST be able to operate over a transport that provides end-to-end integrity protection and confidentiality between the SIP-PBX and the SSP, e.g., using TLS as specified in [3].
REQ14-该机制必须能够在提供SIP-PBX和SSP之间端到端完整性保护和机密性的传输上运行，例如，使用[3]中规定的TLS。
The requirement is satisfied; nothing in the proposed mechanism prevents the use of TLS between the SSP and the SIP-PBX.
满足要求；提议的机制中没有任何内容阻止SSP和SIP-PBX之间使用TLS。
REQ15 - The mechanism MUST support authentication of the SIP-PBX by the SSP and vice versa, e.g., using SIP digest authentication plus TLS server authentication as specified in [3].
REQ15-该机制必须支持SSP对SIP-PBX的认证，反之亦然，例如，使用SIP摘要认证加上TLS服务器认证，如[3]中所述。
The requirement is satisfied; SIP-PBXes may employ either SIP digest authentication or mutually authenticated TLS for authentication purposes.
满足要求；SIP PBX可采用SIP摘要认证或相互认证的TLS进行认证。
REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with public or temporary Globally Routable UA URIs (GRUUs) [20].
要求16-该机制必须允许SIP-PBX向其UAs提供公共或临时的全局可路由UA URI（GRUU）[20]。
The requirement is satisfied via the mechanisms detailed in Section 7.1.
通过第7.1节详述的机制满足要求。
REQ17 - The mechanism MUST work over any existing transport specified for SIP, including UDP.
REQ17-该机制必须适用于为SIP指定的任何现有传输，包括UDP。
The requirement is satisfied to the extent that UDP can be used for REGISTER requests in general. The application of certain extensions and/or network topologies may exceed UDP MTU sizes, but such issues arise both with and without the mechanism described in this document. This document does not exacerbate such issues.
只要UDP一般可用于注册请求，就满足了这一要求。某些扩展和/或网络拓扑的应用可能超过UDP MTU的大小，但无论是否使用本文档中描述的机制，都会出现此类问题。本文件并未加剧此类问题。
REQ18 - Documentation MUST give guidance or warnings about how authorization policies may be affected by the mechanism, to address the problems described in Section 3.3 [of RFC 5947].
REQ18-文件必须提供有关授权政策如何受机制影响的指导或警告，以解决RFC 5947第3.3节中描述的问题。
These issues are addressed at length in Section 10, as well as summarized in Section 7.4.
第10节详细讨论了这些问题，并在第7.4节进行了总结。
REQ19 - The mechanism MUST be extensible to allow a set of assigned telephone numbers to comprise local numbers as specified in RFC 3966 [15], which can be in contiguous ranges, discrete, or in any combination of the two.
REQ19-该机制必须可扩展，以允许一组分配的电话号码包含RFC 3966[15]中规定的本地号码，这些号码可以是连续的、离散的，也可以是两者的任意组合。
Assignment of telephone numbers to a registration is performed by the SSP's registrar, which is not precluded from assigning local numbers in any combination it desires.
注册电话号码的分配由SSP的注册机构执行，注册机构不排除以其希望的任何组合分配本地号码。
REQ20 - The mechanism MUST be extensible to allow a set of arbitrarily assigned SIP URI's as specified in RFC 3261 [3], as opposed to just telephone numbers, without requiring a complete change of mechanism as compared to that used for telephone numbers.
REQ20-该机制必须是可扩展的，以允许RFC 3261[3]中规定的一组任意分配的SIP URI，而不仅仅是电话号码，与电话号码相比，无需对机制进行完全更改。
The mechanism is extensible in such a fashion, as demonstrated by the document "GIN with Literal AoRs for SIP in SSPs (GLASS)" [23].
该机制可以以这种方式进行扩展，如文档“SSP（GLASS）中SIP的GIN和文字AOR”[23]所示。
DES1 - The mechanism SHOULD allow an SSP to exploit its mechanisms for providing SIP service to normal UAs in order to provide a SIP trunking service to SIP-PBXes.
DES1-该机制应允许SSP利用其向普通UAs提供SIP服务的机制，以便向SIP PBX提供SIP中继服务。
The desired property is satisfied; the routing mechanism described in this document is identical to the routing performed for singly registered AORs.
满足所需特性；本文档中描述的路由机制与为单独注册的AOR执行的路由相同。
DES2 - The mechanism SHOULD scale to SIP-PBXes of several thousand assigned telephone numbers.
DES2-该机制应扩展到具有数千个指定电话号码的SIP PBX。
The desired property is satisfied; nothing in this document precludes DID number pools of arbitrary size.
满足所需特性；本文档中的任何内容都不排除任意大小的DID池。
DES3 - The mechanism SHOULD scale to support several thousand SIP-PBX's on a single SSP.
DES3-该机制应可扩展以支持单个SSP上的数千个SIP-PBX。
The desired property is satisfied; nothing in this document precludes an arbitrary number of SIP-PBXes from attaching to a single SSP.
满足所需特性；本文档中的任何内容都不能阻止任意数量的SIP PBX连接到单个SSP。
Author's Address
作者地址
Adam Roach Tekelec 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US
美国德克萨斯州达拉斯坎贝尔路17210号Adam Roach Tekelec 250套房，邮编75252
EMail: adam@nostrum.com
EMail: adam@nostrum.com