Internet Engineering Task Force (IETF) J. Elwell
Request for Comments: 5947 Siemens Enterprise Communications
Category: Informational H. Kaplan
ISSN: 2070-1721 Acme Packet
September 2010
Internet Engineering Task Force (IETF) J. Elwell
Request for Comments: 5947 Siemens Enterprise Communications
Category: Informational H. Kaplan
ISSN: 2070-1721 Acme Packet
September 2010
Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中对多记录地址（AOR）可达性信息的要求
Abstract
摘要
This document states requirements for a standardized SIP registration mechanism for multiple addresses of record (AORs), the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges (PBXs). The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers.
本文件规定了多记录地址（AOR）标准化SIP注册机制的要求，该机制适合SIP服务提供商大规模部署，以支持中小型专用分支交换机（PBX）。这些要求针对的解决方案至少可以支持基于E.164编号的AOR。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5947.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5947.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Problem Statement ...............................................4
3.1. Issues with the REGISTER Transaction .......................5
3.1.1. Mishandling by SIP-Aware Middleboxes ................5
3.1.2. REGISTER Response Growth ............................6
3.1.3. Illegal "Wildcard" Syntax ...........................6
3.2. Issues with Routing Inbound Requests to the SIP-PBX ........6
3.2.1. Loss of Target Information ..........................6
3.2.2. Inconsistent Placement of Target URI
Information in Inbound Requests .....................6
3.2.3. Request-URI Misrouting ..............................7
3.3. Policy-Related Issues ......................................7
3.3.1. Authorization Policy Mismatches .....................7
3.3.2. PAI or PPI URI Mismatches ...........................7
4. Requirements ....................................................8
5. Desirables .....................................................10
6. Non-Requirements ...............................................11
7. Security considerations ........................................11
8. Acknowledgements ...............................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................12
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Problem Statement ...............................................4
3.1. Issues with the REGISTER Transaction .......................5
3.1.1. Mishandling by SIP-Aware Middleboxes ................5
3.1.2. REGISTER Response Growth ............................6
3.1.3. Illegal "Wildcard" Syntax ...........................6
3.2. Issues with Routing Inbound Requests to the SIP-PBX ........6
3.2.1. Loss of Target Information ..........................6
3.2.2. Inconsistent Placement of Target URI
Information in Inbound Requests .....................6
3.2.3. Request-URI Misrouting ..............................7
3.3. Policy-Related Issues ......................................7
3.3.1. Authorization Policy Mismatches .....................7
3.3.2. PAI or PPI URI Mismatches ...........................7
4. Requirements ....................................................8
5. Desirables .....................................................10
6. Non-Requirements ...............................................11
7. Security considerations ........................................11
8. Acknowledgements ...............................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................12
The Session Initiation Protocol (SIP) [RFC3261], together with its extensions, supports multiple means of obtaining the connection information necessary to deliver out-of-dialog SIP requests to their intended targets. When a SIP proxy needs to send a request to a target address of record (AOR) within its domain, it can use a location service to obtain the registered Contact Universal Resource Identifiers (URIs), together with any associated path information [RFC3327], and build a route set to reach each target user agent (UA). The SIP REGISTER method can be used to register Contact URIs and path information. SIP-outbound [RFC5626] enhances this mechanism to cater to UAs behind Network Address Translators (NATs) and firewalls. When an entity needs to send a request to a target for which it is not authoritative, the entity can follow [RFC3263] procedures for using the Domain Name System (DNS) to obtain the next-hop connection information.
会话启动协议（SIP）[RFC3261]及其扩展支持多种获取连接信息的方法，以将对话外SIP请求发送到其预期目标。当SIP代理需要向其域内的目标记录地址（AOR）发送请求时，它可以使用位置服务获取已注册的联系人通用资源标识符（URI）以及任何相关路径信息[RFC3327]，并构建一个路由集以到达每个目标用户代理（UA）。SIP注册方法可用于注册联系人URI和路径信息。SIP outbound[RFC5626]增强了这种机制，以满足网络地址转换器（NAT）和防火墙后面的UAs。当实体需要向其不具有权威性的目标发送请求时，该实体可以按照[RFC3263]程序使用域名系统（DNS）获取下一跳连接信息。
In practice, many small- and medium-sized businesses use a SIP Private Branch Exchange (SIP-PBX) that is authoritative for tens or hundreds of SIP AORs. This SIP-PBX acts as a registrar/proxy for these AORs for users hosted by the SIP-PBX. A SIP Service Provider (SSP) provides SIP peering/trunking capability to the SIP-PBX. The SIP-PBX needs to be reachable from the SSP so that the SSP can handle inbound out-of-dialog SIP requests targeted at these AORs, routing these requests to the SIP-PBX for onward delivery to registered UAs.
实际上，许多中小型企业使用SIP专用分支交换机（SIP-PBX），该交换机对数十个或数百个SIP AOR具有权威性。此SIP-PBX充当SIP-PBX承载的用户的这些AOR的注册器/代理。SIP服务提供商（SSP）向SIP-PBX提供SIP对等/中继功能。SIP-PBX需要可从SSP访问，以便SSP可以处理针对这些AOR的入站对话外SIP请求，将这些请求路由到SIP-PBX，以便向前传递到注册的UAs。
Experience has shown that existing mechanisms are not always sufficient to support SIP-PBXs for small/medium businesses. In particular, RFC 3263 procedures are generally inappropriate, except for some larger SIP-PBXs. In current deployments, mechanisms for the dynamic provision of reachability information based on the SIP REGISTER method are commonly used. However, these mechanisms vary in detail, leading to interoperability issues between SIP-PBXs and SSPs, and the need for equipment to support different variants. A more detailed statement of the problem is given in Section 3.
经验表明，现有机制并不总是足以支持中小企业的SIP PBX。特别是，RFC3263程序通常是不合适的，除了一些较大的SIP PBX。在当前的部署中，通常使用基于SIP注册方法的可达性信息动态提供机制。然而，这些机制在细节上有所不同，导致SIP PBX和SSP之间存在互操作性问题，并且需要设备支持不同的变体。关于这个问题的更详细说明见第3节。
This document states requirements for a standardized SIP registration mechanism for multiple AORs, the mechanism being suitable for deployment by SSPs on a large scale in support of small- to medium-sized SIP-PBXs. The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers.
本文档说明了多个AOR的标准化SIP注册机制的要求，该机制适合SSP大规模部署，以支持中小型SIP PBX。这些要求针对的解决方案至少可以支持基于E.164编号的AOR。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The terms address of record (AOR), proxy, REGISTER, registrar, request, response, and user agent (UA) are to be interpreted as described in [RFC3261].
术语记录地址（AOR）、代理、注册、注册、请求、响应和用户代理（UA）应按照[RFC3261]中所述进行解释。
A number of other standards organizations have addressed the issue of a SIP-PBX registering with its SSP, notably ETSI [ETSI_TS_182025] and 3rd Generation Partnership Project (3GPP) [3GPP.24.229]. Also, various SSPs have produced proprietary specifications for use with their own offerings. The reader is encouraged to review the documents produced by those organizations.
许多其他标准组织已经解决了SIP-PBX向其SSP注册的问题，特别是ETSI[ETSI_TS_182025]和第三代合作伙伴计划（3GPP）[3GPP.24.229]。此外，各种SSP已经制定了专有规范，用于其自己的产品。鼓励读者阅读这些组织编写的文件。
A short summary of the general concept is as follows. The figure below illustrates the scope of the problem.
一般概念的简要概述如下。下图说明了问题的范围。
+----+
| UA |----+
+----+ | - - - - - - - - - - - - - -
| : SCOPE OF PROBLEM :
+----+ | : :
| UA |--+ | +---------+ +---------+
+----+ | | | | | |
| +------| | | |
+----+ +--------| SIP-PBX |------------------| SSP |
| UA |-----------| | | |
+----+ | | | |
+---------+ +---------+
: :
----------------> : ------------------> :
UAs register with : SIP-PBX registers with :
SIP-PBX on behalf of : SSP once on behalf of :
individual AORs : multiple AORs :
: :
: <------------------ :
<---------------- : SSP delivers inbound :
SIP-PBX forwards : requests to SIP-PBX :
inbound requests : :
to appropriate UAs : :
- - - - - - - - - - - - - -
+----+
| UA |----+
+----+ | - - - - - - - - - - - - - -
| : SCOPE OF PROBLEM :
+----+ | : :
| UA |--+ | +---------+ +---------+
+----+ | | | | | |
| +------| | | |
+----+ +--------| SIP-PBX |------------------| SSP |
| UA |-----------| | | |
+----+ | | | |
+---------+ +---------+
: :
----------------> : ------------------> :
UAs register with : SIP-PBX registers with :
SIP-PBX on behalf of : SSP once on behalf of :
individual AORs : multiple AORs :
: :
: <------------------ :
<---------------- : SSP delivers inbound :
SIP-PBX forwards : requests to SIP-PBX :
inbound requests : :
to appropriate UAs : :
- - - - - - - - - - - - - -
In virtually all models, the SIP-PBX generates a SIP REGISTER request using a mutually agreed-upon SIP AOR -- typically based on the SIP-PBX's main attendant-/reception-desk number. The AOR is often in the domain of the SSP, and both the To and From URIs used for the REGISTER request identify that AOR. In all respects, it appears on
在几乎所有的型号中，SIP-PBX都使用双方同意的SIP AOR生成SIP注册请求——通常基于SIP-PBX的主要服务员/前台号码。AOR通常位于SSP的域中，用于注册请求的To和From URI都标识该AOR。在各个方面，它都出现在
the wire as a "normal" SIP REGISTER request, as if from a typical user's UA. However, it generally implicitly registers other AORs associated with the SIP-PBX.
该线路作为“正常”SIP注册请求，好像来自典型用户的UA。然而，它通常隐式地注册与SIP-PBX关联的其他AOR。
For both 3GPP and ETSI mechanisms, the 200 OK response to the REGISTER request, sent after a successful authentication challenge, contains a P-Associated-URI (PAU) [RFC3455] header field listing the other SIP URIs or TEL URIs (i.e., phone numbers) of the SIP-PBX, which are implicitly registered AORs. The registered reachability information from the REGISTER request will be used to reach not only the single explicitly registered AOR but also each of the implicitly registered AORs. In order to reduce the number of PAU entries, a "wildcard" syntax model is defined [3GPP.23.003], which uses a regular expression syntax in the user field of the URI to express multiple AORs in a compressed manner.
对于3GPP和ETSI机制，在成功的认证质询之后发送的对注册请求的200 OK响应包含P-Associated-URI（PAU）[RFC3455]报头字段，其中列出了SIP-PBX的其他SIP-URI或电话URI（即，电话号码），它们是隐式注册的aor。来自REGISTER请求的注册可达性信息将不仅用于到达单个显式注册的AOR，还用于到达每个隐式注册的AOR。为了减少PAU条目的数量，定义了一个“通配符”语法模型[3GPP.23.003]，它在URI的用户字段中使用正则表达式语法以压缩方式表示多个AOR。
For routing requests for any of the explicitly or implicitly registered AORs from the SSP to the SIP-PBX, the Request-URI is typically replaced with the registered Contact URI. In the case of 3GPP and ETSI, the SSP has the option of using loose routing instead, and inserting the registered Contact URI as a loose route Route header field value, while leaving the Request-URI alone. This decision is made based upon manually provisioned information in the registrar's database (i.e., the Home Subscriber Server (HSS)).
对于将任何显式或隐式注册的AOR的请求从SSP路由到SIP-PBX，请求URI通常替换为注册的联系人URI。在3GPP和ETSI的情况下，SSP可以选择使用松散路由，并将注册的联系人URI作为松散路由头字段值插入，而不使用请求URI。该决定基于注册器数据库（即家庭订户服务器（HSS））中的手动配置信息做出。
None of the currently available mechanisms indicate that the REGISTER request or response is any different from a "normal" REGISTER request or response. This has caused issues when SIP-aware middleboxes between the SIP-PBX and the registrar serve both SIP-PBXs and normal UAs yet need to apply different policies to the two cases.
当前可用的机制中没有一个表明寄存器请求或响应与“正常”寄存器请求或响应有任何不同。当SIP-PBX和注册器之间的SIP感知中间件同时为SIP PBX和普通UAs提供服务时，这就产生了问题，但需要对这两种情况应用不同的策略。
Furthermore, some middleboxes expect the registrar to follow normal [RFC3261] procedures of Request-URI replacement with the registered Contact URI for routing subsequent requests to the SIP-PBX. If the registrar adopts a different practice for requests to SIP-PBXs, this can cause the middlebox to fail to route such requests correctly, because there is no indication that the registration was any different.
此外，一些中间盒期望注册器遵循请求URI替换为注册联系人URI的正常[rfc326]过程，以便将后续请求路由到SIP-PBX。如果注册官对SIP PBX的请求采用不同的做法，这可能会导致中间盒无法正确路由此类请求，因为没有迹象表明注册有任何不同。
Lastly, lack of an indication of implicit registration makes troubleshooting more difficult because the on-the-wire messages are indistinguishable from "normal" registrations. Note that even the
最后，缺少隐式注册的指示使得故障排除更加困难，因为在线消息与“正常”注册无法区分。请注意，即使是
existence of a PAU header field in the response does not indicate that implicit registration for a SIP-PBX has occurred, since the PAU header field is also used for normal UAs with multiple identities.
响应中存在PAU头字段并不表示SIP-PBX已进行隐式注册，因为PAU头字段也用于具有多个身份的正常UAs。
If a SIP-PBX represents many AORs, the PAU list in the response can grow the SIP message size beyond the limits for UDP.
如果SIP-PBX代表多个AOR，则响应中的PAU列表会使SIP消息的大小超出UDP的限制。
The current syntax for "wildcarded" PAUs is illegal for TEL URIs, based on the ABNF rules for TEL URIs in [RFC3966].
根据[RFC3966]中关于TEL URI的ABNF规则，“通配符”PAU的当前语法对于TEL URI是非法的。
If the proxy-registrar follows [RFC3261] for registration resolution of requests targeted at one of the SIP-PBX's AORs, and thus replaces the Request-URI with the registered Contact URI, it is not clear which AOR is the intended target of the request. The To URI, for example, may not contain the intended target AOR if the request was forwarded/retargeted prior to reaching the proxy-registrar. Some middleboxes between the registrar and SIP-PBX will overwrite the Request-URI specifically to try to fix this issue. In some cases, a P-Called-Party-ID header field [RFC3455] will contain the intended target AOR; and in some cases, the History-Info header field [RFC4244] will contain it. The SIP-PBX needs to know where to look to find the required information and, in the case of History-Info, needs to identify the particular element containing the required information.
如果代理注册商遵循[RFC3261]对针对SIP-PBX的AOR之一的请求进行注册解析，从而用注册的联系人URI替换请求URI，则不清楚哪个AOR是该请求的预期目标。例如，如果请求在到达代理注册器之前被转发/重定目标，则To URI可能不包含预期的目标AOR。注册器和SIP-PBX之间的一些中间盒将专门覆盖请求URI，以尝试解决此问题。在某些情况下，P-Called-Party-ID报头字段[RFC3455]将包含预期目标AOR；在某些情况下，历史信息头字段[RFC4244]将包含它。SIP-PBX需要知道在哪里查找所需信息，如果是历史信息，则需要识别包含所需信息的特定元素。
3.2.2. Inconsistent Placement of Target URI Information in Inbound Requests
3.2.2. 入站请求中目标URI信息的位置不一致
Even when all information needed by the SIP-PBX is provided, in some deployments, inbound SIP requests from the SSP have the registered SIP-PBX Contact URI in the Request-URI, whereas in other deployments inbound SIP requests have the intended target SIP-PBX user (AOR) in the Request-URI and the Contact URI in the Route header field. There are other variants, too. Interoperability problems arise when a SIP-PBX designed or configured for one variant attempts to interwork with an SSP designed or configured for another variant.
即使提供了SIP-PBX所需的所有信息，在某些部署中，来自SSP的入站SIP请求在请求URI中具有注册的SIP-PBX联系人URI，而在其他部署中，入站SIP请求在请求URI中具有预期的目标SIP-PBX用户（AOR），在路由头字段中具有联系人URI。还有其他变体。当为一个变体设计或配置的SIP-PBX试图与为另一个变体设计或配置的SSP互通时，会出现互操作性问题。
Although many SIP-PBXs support registration with an SSP, they do not consider themselves authoritative for the explicitly or implicitly registered AORs if the domain portion still identifies the SSP's domain. They expect the domain portion to be their own IP Address, Fully Qualified Domain Name (FQDN), or domain. Currently, middleboxes have to fix that issue.
虽然许多SIP PBX支持用SSP进行注册，但是如果域部分仍然标识SSP域，则它们不认为自己对显式或隐式注册的AOR具有权威性。他们希望域部分是他们自己的IP地址、完全限定域名（FQDN）或域。目前，中间商必须解决这个问题。
The following are largely policy matters for the SSP, but it should be noted the policies described below will not work in some situations. A mechanism for solving the SIP-PBX registration problem will not solve these policy issues directly, although when specifying the mechanism, the opportunity can be taken to highlight the impact of such policies.
以下主要是SSP的政策事项，但应注意，以下所述政策在某些情况下不起作用。解决SIP-PBX注册问题的机制不会直接解决这些策略问题，尽管在指定该机制时，可以借此机会强调此类策略的影响。
Many SSPs perform a first-order level of authorization for requests from the SIP-PBX by checking the URI in the From, P-Asserted-Identity (PAI), or P-Preferred-Identity (PPI) [RFC3325] header field for one matching either an explicitly or implicitly registered AOR for the same Contact URI and/or Layer-3 IP Address. However, some SIP-PBXs change the Contact URI they use for non-REGISTER requests to be different from the one they explicitly registered. For example, they change the user portion of the Contact URI, or even the host portion. This is particularly true for a SIP-PBX operating as a proxy and forwarding the Contact URI from the UA behind the SIP-PBX (the SIP-PBX typically being identified in a Record-Route header field), rather than acting as a Back-to-Back User Agent (B2BUA) and substituting its own Contact URI. This can cause an SSP to fail to find an AOR corresponding to the Contact URI for non-REGISTER requests, resulting in the SSP rejecting such requests or asserting its own PAI value, rather than asserting a value based on received header fields.
许多SSP通过检查from、P-Asserted-Identity（PAI）或P-Preferred-Identity（PPI）[RFC3325]头字段中的URI，对来自SIP-PBX的请求执行一级授权，该URI与相同联系人URI和/或第3层IP地址的显式或隐式注册AOR相匹配。但是，一些SIP PBX将它们用于非注册请求的联系人URI更改为不同于它们显式注册的联系人URI。例如，它们更改联系人URI的用户部分，甚至更改主机部分。对于作为代理运行并从SIP-PBX后面的UA转发联系人URI的SIP-PBX（SIP-PBX通常在记录路由报头字段中标识），而不是充当背靠背用户代理（B2BUA）并替换其自己的联系人URI，情况尤其如此。这可能导致SSP无法找到与非注册请求的联系人URI相对应的AOR，从而导致SSP拒绝此类请求或断言其自己的PAI值，而不是基于接收到的标头字段断言值。
Some SSPs expect the PAI or PPI URI in SIP requests received from the SIP-PBX to match one of the explicitly or implicitly registered AORs, whereas some SIP-PBXs generate the URIs using their local IP Address, hostname, or domain name. Some SSPs expect the PAI or PPI URI in SIP requests received from the SIP-PBX to be the explicitly registered
一些SSP期望从SIP-PBX接收的SIP请求中的PAI或PPI URI与显式或隐式注册的AOR之一匹配，而一些SIP PBX使用其本地IP地址、主机名或域名生成URI。一些SSP期望从SIP-PBX接收的SIP请求中的PAI或PPI URI被显式注册
AOR only, as it is the main billing number, instead of the implicitly registered AOR of the calling party. In either case, this can result in the SSP rejecting requests with values that do not match, or asserting its own PAI value.
仅限AOR，因为它是主计费号码，而不是呼叫方隐式注册的AOR。在任何一种情况下，这都可能导致SSP拒绝具有不匹配值的请求，或声明其自己的PAI值。
Again, these are policy matters for the SSP, but drawbacks should be noted. For example, rejection of requests can rule out requests from sources beyond the SIP-PBX (e.g., calls forwarded by the SIP-PBX), unless the SIP-PBX changes the PAI or PPI URI to a value acceptable to the SSP (in which case it will no longer identify the calling user). If the SSP changes the PAI or PPI URI, again the request will fail to identify the calling user.
同样，这些是SSP的政策事项，但应注意缺点。例如，拒绝请求可以排除来自SIP-PBX之外的源的请求（例如，由SIP-PBX转发的呼叫），除非SIP-PBX将PAI或PPI URI更改为SSP可接受的值（在这种情况下，它将不再识别呼叫用户）。如果SSP更改PAI或PPI URI，请求将再次无法识别呼叫用户。
The following are requirements of the mechanism.
以下是该机制的要求。
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的一组电话号码。
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个号码，这些号码可以是连续的、离散的，也可以是两者的任意组合。
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入站请求。
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参与注册过程。
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.
要求5：该机制必须允许SIP-PBX处理源自其自身UAs并以其指定电话号码为目标的请求，而无需将这些请求路由到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.
要求6：该机制必须允许SIP-PBX接收来自SIP-PBX外部并通过SSP到达的对其分配电话号码的请求，以便SIP-PBX可以将这些请求转发到其UAs，就像对这些电话号码的内部请求一样。
REQ7: The mechanism MUST provide a means whereby a SIP-PBX knows at which of its assigned telephone numbers an inbound request from its SSP is targeted.
要求7：该机制必须提供一种手段，使SIP-PBX能够知道来自其SSP的入站请求针对的是其分配的电话号码中的哪一个。
REQ8: The mechanism MUST provide a means of avoiding problems due to one side using the mechanism and the other side not.
要求8：该机构必须提供一种避免因一方使用该机构而另一方未使用该机构而产生问题的方法。
In other words, the mechanism is required to avoid the situation where one side believes it is using the mechanism and the other side believes it is not, e.g., the SIP-PBX believes it is performing the registration of multiple telephone numbers, but the SSP believes a single AOR is being registered.
换句话说，该机制需要避免一方认为它正在使用该机制而另一方认为它没有使用该机制的情况，例如，SIP-PBX认为它正在执行多个电话号码的注册，但SSP认为正在注册一个AOR。
REQ9: The mechanism MUST observe SIP backwards compatibility principles.
REQ9：机制必须遵守SIP向后兼容性原则。
In other words, the mechanism is required to provide a graceful means of recovery or fall-back if either side does not support the mechanism. For example, this might involve the use of an option tag.
换句话说，如果任何一方都不支持该机构，则该机构需要提供一种优雅的恢复或后退方式。例如，这可能涉及使用选项标记。
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的入站请求路径上。
These intermediate SIP entities can be edge proxies, session border controllers, etc.
这些中间SIP实体可以是边缘代理、会话边界控制器等。
REQ11: The mechanism MUST work when a SIP-PBX obtains its IP address dynamically.
REQ11：当SIP-PBX动态获取其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中发布其域名的情况下工作。
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.
请求13：对于给定的SIP-PBX及其SSP，不得对其他域产生影响，这些域预计能够使用正常的RFC 3263过程路由请求，包括需要通过SSP路由以到达SIP-PBX的请求。
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 Transport Layer Security (TLS) as specified in [RFC3261].
REQ14：该机制必须能够在提供SIP-PBX和SSP之间端到端完整性保护和机密性的传输上运行，例如使用[RFC3261]中规定的传输层安全性（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 [RFC3261].
REQ15：该机制必须支持SSP对SIP-PBX的认证，反之亦然，例如，使用[RFC3261]中规定的SIP摘要认证和TLS服务器认证。
REQ16: The mechanism MUST allow the SIP-PBX to provide its UAs with public or temporary Globally Routable UA URIs (GRUUs) [RFC5627].
要求16：该机制必须允许SIP-PBX向其UAs提供公共或临时全局可路由UA URI（GRUU）[RFC5627]。
REQ17: The mechanism MUST work over any existing transport specified for SIP, including UDP.
REQ17：该机制必须适用于为SIP指定的任何现有传输，包括UDP。
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.
REQ18：文件必须提供有关授权策略如何受机制影响的指导或警告，以解决第3.3节中描述的问题。
REQ19: The mechanism MUST be extensible to allow a set of assigned telephone numbers to comprise local numbers as specified in [RFC3966], which can be in contiguous ranges, discrete, or in any combination of the two.
REQ19：该机制必须可扩展，以允许一组分配的电话号码包含[RFC3966]中规定的本地号码，该号码可以是连续的、离散的，也可以是两者的任意组合。
REQ20: The mechanism MUST be extensible to allow a set of arbitrarily assigned SIP URI's as specified in [RFC3261], as opposed to just telephone numbers, without requiring a complete change of mechanism as compared to that used for telephone numbers.
REQ20：该机制必须是可扩展的，以允许[RFC3261]中规定的一组任意分配的SIP URI，而不仅仅是电话号码，与电话号码相比，无需对机制进行完全更改。
The following are desirable properties of the mechanism.
以下是该机构的理想特性。
In addition to the desirables below, the general aim is to require only relatively modest changes to a substantial population of existing SSP and SIP-PBX implementations, in order to encourage a fast market adoption of the standardized mechanism. Ease of market adoption is paramount here. Many SIP-PBXs and SSPs have implemented mechanisms based on the REGISTER method, and the need for substantial changes to those implementations will discourage convergence on a single standard in the foreseeable future.
除了下面的期望之外，总体目标是只需要对大量现有SSP和SIP-PBX实现进行相对温和的更改，以鼓励快速市场采用标准化机制。在这里，易于市场采用是至关重要的。许多SIP PBX和SSP已经实现了基于寄存器方法的机制，对这些实现进行实质性更改的需要将在可预见的未来阻碍在单一标准上的融合。
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-PBXs.
DES1：该机制应允许SSP利用其向普通UAs提供SIP服务的机制，以便向SIP PBX提供SIP中继服务。
DES2: The mechanism SHOULD scale to SIP-PBXs of several thousand assigned telephone numbers.
DES2：该机制应扩展到数千个指定电话号码的SIP PBX。
This will probably preclude any mechanism involving a separate REGISTER transaction per assigned telephone number.
这可能会排除任何涉及每个指定电话号码的单独登记事务的机制。
In practice, the mechanism is more likely to be used on SIP-PBXs with up to a few hundred telephone numbers, but it is impossible to give a precise limit, and hence the desire to be able to support several thousand.
实际上，该机制更可能用于多达几百个电话号码的SIP PBX，但不可能给出精确的限制，因此希望能够支持几千个。
DES3: The mechanism SHOULD scale to support several thousand SIP-PBXs on a single SSP.
DES3：该机制应该扩展到在单个SSP上支持数千个SIP PBX。
The means by which a third domain can route a request to the SSP for onward delivery to the SIP-PBX is outside the scope of this work. This is related to REQ13, which requires normal routing based on RFC 3263 be used.
第三个域可以将请求路由到SSP，以便将请求转发到SIP-PBX的方法不在本工作范围内。这与REQ13有关，它要求使用基于RFC 3263的正常路由。
Provisioning is outside the scope of this work. In particular, an SSP will need to assign a set of telephone numbers to a SIP-PBX, and a SIP-PBX will need to be aware of the set of assigned numbers and allocate those numbers to its users. Automated means for a SIP-PBX to obtain, from its SSP, the set of assigned telephone numbers is considered to be a provisioning topic.
资源调配不在本工作范围内。特别是，SSP需要为SIP-PBX分配一组电话号码，SIP-PBX需要知道分配的号码集并将这些号码分配给其用户。SIP-PBX从其SSP获取一组指定电话号码的自动化方式被视为一个配置主题。
The security of signaling between the SIP-PBX and the SSP is important. Some of the requirements above already address this.
SIP-PBX和SSP之间的信令安全性非常重要。上面的一些要求已经解决了这个问题。
In particular, it is important that an entity acting as a SIP-PBX cannot register with an SSP and receive inbound requests to which it is not entitled. The SSP is assumed to have procedures for ensuring that a SIP-PBX is entitled to use a set of E.164 telephone numbers prior to entering into agreement with that SIP-PBX for using those telephone numbers with this mechanism. Furthermore, by authenticating the SIP-PBX when it provides reachability information, the SSP can be sure that it delivers inbound requests only to the correct destination.
尤其重要的是，作为SIP-PBX的实体不能向SSP注册并接收其无权接收的入站请求。假设SSP具有确保SIP-PBX有权在与SIP-PBX达成协议之前使用一组E.164电话号码的程序，以使用该机制使用这些电话号码。此外，通过在SIP-PBX提供可达性信息时对其进行身份验证，SSP可以确保其只将入站请求发送到正确的目的地。
The contents of the document have been compiled from extensive discussions within the MARTINI WG, the individuals concerned being too numerous to mention.
该文件的内容是根据马提尼工作组内部的广泛讨论汇编而成的，涉及的个人太多，难以提及。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，2002年6月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3327]Willis，D.和B.Hoeneisen，“用于注册非相邻联系人的会话启动协议（SIP）扩展头字段”，RFC 3327，2002年12月。
[RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, January 2003.
[RFC3455]Garcia Martin，M.，Henrikson，E.，和D.Mills，“第三代合作伙伴关系项目（3GPP）会话启动协议（SIP）的专用头（P头）扩展”，RFC 3455，2003年1月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244]Barnes，M.，“请求历史信息会话启动协议（SIP）的扩展”，RFC 4244，2005年11月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]Jennings，C.，Mahy，R.，和F.Audet，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，2009年10月。
[3GPP.23.003] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 3.15.0, October 2006.
[3GPP.23.003]3GPP，“编号、寻址和标识”，3GPP TS 23.003 3.15.012006年10月。
[3GPP.24.229] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 10.0.0, June 2010.
[3GPP.24.229]3GPP，“基于会话发起协议（SIP）和会话描述协议（SDP）的IP多媒体呼叫控制协议；第3阶段”，3GPP TS 24.229 10.0.02010年6月。
[ETSI_TS_182025] ETSI TS 182 025, "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Business trunking; Architecture and functional description".
[ETSI___182025]ETSI TS 182 025，“用于高级网络的电信和互联网融合服务和协议（TISPAN）；业务集群；体系结构和功能描述”。
Authors' Addresses
作者地址
John Elwell Siemens Enterprise Communications
西门子企业通信公司
EMail: john.elwell@siemens-enterprise.com
EMail: john.elwell@siemens-enterprise.com
Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA
美国马萨诸塞州伯灵顿第三大道71号Hadriel Kaplan Acme包01803
EMail: hkaplan@acmepacket.com
EMail: hkaplan@acmepacket.com