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)
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.
この文書では、メカニズムは中規模のPBX（構内交換機）に小型の支援で大規模にSIPサービスプロバイダが展開するのに適している、レコードの複数のアドレス（AORが）のための標準化されたSIP登録メカニズムのための要件を述べています。要件は、最低限として、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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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）に要求を送信する必要がある場合、それは、一緒に関連するパス情報[RFC3327]を用いて、登録された連絡先ユニバーサルリソース識別子（URIを）取得するために位置情報サービスを使用することができ各ターゲットユーザーエージェント（UA）に到達するために設定された経路を構築します。 SIPのREGISTERメソッドは、連絡先のURIやパス情報を登録するために使用することができます。 SIP-アウトバウンド[RFC5626]は、ネットワークの背後のUA翻訳器（NAT）およびファイアウォールに対処するために応えるために、このメカニズムを強化します。エンティティは、それが権威されていないターゲットに要求を送信する必要がある場合、エンティティは、ネクストホップ接続情報を取得するためにドメインネームシステム（DNS）を使用する[RFC3263]の手順に従うことができます。
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のAORの何百ものための権威であるSIP構内交換機（SIP-PBX）を使用します。このSIP-PBXは、SIP-PBXでホストされているユーザのためにこれらのAORのためのレジストラ/プロキシとして働きます。 SIPサービスプロバイダ（SSP）は、SIP-PBXにSIPピア/トランキング機能を提供します。 SIP-PBXは、SSPが登録のUAへの以降の配信のためのSIP-PBXにこれらの要求をルーティングこれらのAORを対象に、インバウンド、アウトオブダイアログSIPリクエストを処理できるように、SSPから到達可能である必要があります。
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のをサポートするのに十分でないことが示されています。具体的には、RFC 3263の手順は、いくつかの大きなSIP-PBXのを除いて、一般的に不適切です。現在の展開では、SIP REGISTER法に基づく到達可能性情報を動的に提供するための機構が一般的に使用されます。しかし、これらのメカニズムは、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.
この文書では、機構は、中型SIP-PBXに小規模の支援に大規模でのSSPによって配備するのに適している、複数のAORのための標準化されたSIP登録メカニズムの要件を述べています。要件は、最低限として、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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）の用語アドレス、プロキシ、REGISTERは、レジストラ、要求、応答、及びユーザエージェント（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.
他の標準化団体の数は、そのSSP、特にETSI [ETSI_TS_182025]および第3世代パートナーシッププロジェクト（3GPP）[3GPP.24.229]に登録するSIP-PBXの問題に対処しています。また、様々の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 : :
- - - - - - - - - - - - - -
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 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-PBXのメインattendant- /フロントデスクの数に基づいて、 - 実質的にすべてのモデルにおいて、SIP-PBXは、相互に合意したSIP AORを使用して、SIP REGISTER要求を生成します。 AORは、SSPのドメインであることが多い、との両方にとREGISTERリクエストのために使用されるURIからAORことを確認します。典型的なユーザーのUAからかのようにすべての点で、それは、「通常」のSIP REGISTER要求としてワイヤーに表示されます。しかし、一般的に暗黙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の両方のメカニズムのために、成功した認証チャレンジ後に送信されるREGISTER要求、200 OK応答は、他のSIPのURIまたはTEL URIの（すなわち、電話をリストP-関連-URI（PAU）[RFC3455]ヘッダーフィールドを含みます暗黙登録のAORであるSIP-PBXの数）。 REGISTERリクエストから登録到達可能性情報は、単一の明示的に登録AORだけでなく、暗黙的に登録されたのAORの各だけでなく、に到達するために使用されます。 PAUエントリの数を減らすために、「ワイルドカード」のシンタックスモデルは、圧縮方法で複数のAORを発現するためにURIのユーザフィールドの正規表現構文を使用する、[3GPP.23.003]に定義されています。
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)).
SIP-PBXへのSSPから明示的または暗黙的に登録されたのAORのいずれかの要求をルーティングするために、Request-URIが、通常、登録連絡先URIに置き換えられます。リクエストURIのみを残して、3GPPおよびETSIの場合、SSPは、代わりにルーズルーティングを使用して、緩い経路Routeヘッダーフィールド値として登録された連絡先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.
現在利用可能なメカニズムのいずれもREGISTERリクエストまたは応答が「ノーマル」REGISTER要求または応答から任意の異なることを示していません。これは、SIP-PBXとレジストラ間のSIP対応のミドルボックスは、両方のSIP-PBXに、通常のUAのに役立つ、まだ2例に異なるポリシーを適用する必要のある問題を引き起こしました。
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.
さらに、いくつかの中間装置は、レジストラは、SIP-PBXへの後続のリクエストをルーティングするための登録連絡先URIとのRequest-URI置換の正常[RFC3261]の手順に従うことを期待します。レジストラは、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ヘッダフィールドの偶数存在がPAUヘッダフィールドが複数のIDを持つ通常のUAのためにも使用されるので、SIP-PBXのための暗黙の登録が、発生したことを示すものではないことに留意されたいです。
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リストは、UDPのための限界を超えてSIPメッセージのサイズを拡張することができます。
The current syntax for "wildcarded" PAUs is illegal for TEL URIs, based on the ABNF rules for TEL URIs in [RFC3966].
「ワイルドカード」PAUSのための現在の構文は、[RFC3966]にTEL URIのABNF規則に基づいて、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.
プロキシレジストラは、SIP-PBXのAORがの1を対象要求の登録解像度のための[RFC3261]に従うため、登録された連絡先URIでのRequest-URIを置き換える場合は、AORは、要求の意図したターゲットであるかが明確ではありません。要求は/転送プロキシレジストラに到達する前に再標的化された場合URIに、例えば、意図された標的AORを含まなくてもよいです。レジストラとSIP-PBXとの間にいくつかのミドルボックスは、この問題を解決しようとするために特別のRequest-URIを上書きします。いくつかのケースでは、P-Called-Party-IDヘッダフィールド[RFC3455]は意図された標的AORを含むであろう。いくつかのケースでは、歴史-Infoヘッダーフィールド[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が必要とするすべての情報が提供された場合でも、他の展開で、着信SIP要求が意図した目標を持っているのに対し、いくつかの展開で、SSPからの着信SIP要求は、要求URIに登録SIP-PBX連絡先URIを持つSIP- Request-URIとRouteヘッダーフィールドに接触URIでPBXユーザ（AOR）。他の変異体は、あまりにも、あります。設計又は他の変形のために設計又は構成SSPと連動する一つの変異体の試みのために構成された場合に、SIP-PBX相互運用性の問題が生じます。
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.
SSPと多くのSIP-PBXのサポート登録がドメイン部分は依然として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は、いずれかのP-アサート・アイデンティティ（PAI）、又はP-好ましいアイデンティティ（PPI）から、[RFC3325]ヘッダーフィールドにURIをチェックすることにより、SIP-PBXからの要求の許可の一次レベルを実行します同じ連絡先URIおよび/またはレイヤ3のIPアドレスのための明示的または暗黙的に登録さAORのいずれかに一致します。しかし、いくつかのSIP-PBXが、彼らが明示的に登録1異なるように非REGISTER要求に使用連絡先URIを変更します。例えば、彼らは連絡先URIのユーザ部分、あるいはホスト部分を変更します。これはむしろバックとして作用よりも、SIP-PBXは、プロキシとして動作し、SIP-PBX（SIP-PBXは、典型的には、Record-Routeヘッダフィールドで識別される）の後ろUAから接触URIを転送するために特に真実でありますツーバックユーザエージェント（B2BUA）と、自身の連絡先URIを代入。これは、SSPがそのような要求を拒否またはむしろ受信したヘッダフィールドに基づいて値をアサートよりも、独自のPAI値をアサートSSP、その結果、非REGISTER要求の連絡先URIに対応するAORを検索するために失敗する可能性があります。
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
いくつかのSIP-PBXのは、自分のローカルIPアドレス、ホスト名、またはドメイン名を使用してURIを生成するのに対し、いくつかのSSPは、明示的または暗黙的に登録されたのAORのいずれかと一致するSIP-PBXから受信したSIPリクエストにPAIまたはPPI URIを期待しています。いくつかのSSPは、SIPリクエストでPAIまたはPPI URIを明示的に登録するSIP-PBXから受信した期待します
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があるとして。いずれの場合も、これは一致しない値を持つ要求を拒否、または独自のPAI値をアサートするSSPをもたらす可能性があります。
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は、（SSPに許容される値にPAIまたはPPI URIを変更しない限り、ここで場合は、それはもはや）発信ユーザを識別しません。 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.
REQ1：メカニズムはSIP-PBXは、2人の当事者がSIP-PBXに割り当てられた電話番号のセットに合意したことにより、SSPとのトランキング配列内に入ることを可能にしなければなりません。
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：機構が連続範囲、別個に、またはこれらの任意の組み合わせであり得る、E.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.
REQ4：メカニズムはSIP-PBXに取り付けられたUAが登録プロセス中SSPが関与することなく、これらの電話番号を対象の要求を受信するために、割り当てられた電話番号に基づいのAORのSIP-PBXに登録することを可能にしなければなりません。
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は、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は、そのユーザエージェントへこれらの要求以降ルートできるように、内部の場合と、SIP-PBX外に発信し、SSPを介して到着その割り当てられた電話番号へのリクエストを受信することを可能にしなければなりませんこれらの電話番号への要求。
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.
REQ7：メカニズムは、SSPからの着信要求が対象として、その割り当てられた電話番号のれるSIP-PBXが知っているができる手段を提供しなければなりません。
REQ8: The mechanism MUST provide a means of avoiding problems due to one side using the mechanism and the other side not.
REQ8：メカニズムは、メカニズムや他の側面ではないを使用して片側に起因する問題を回避する手段を提供しなければなりません。
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.
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エンティティが登録A中に示されている（すなわち、SIP-PBXとSSPのドメインのプロキシ間の）SIP-PBXツーSSPインターフェイス上の中間SIPエンティティの配列の存在下で働かなければなりませんSIP-PBXへのインバウンド要求のパスにする必要があります。
These intermediate SIP entities can be edge proxies,
session border controllers, etc.
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：メカニズムは、ドメイン名またはDNSにそのドメイン名を公開する機能を持っているSIP-PBXを必要とせずに動作する必要があります。
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に到達するために、SSPを介してルーティングする必要が要求を含むルート要求に3263個の手順を使用することができるように期待されている他のドメインへの影響、があってはなりません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：メカニズムは[RFC3261]で指定されるように、トランスポート層セキュリティ（TLS）を使用して、例えば、SIP-PBXとSSPとの間のエンドツーエンドの完全性保護、機密性を提供するトランスポートで動作できなければなりません。
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：メカニズムは[RFC3261]で指定されるようにSIPダイジェスト認証プラスTLSサーバー認証を使用して、例えば、SSPおよびその逆によってSIP-PBXの認証をサポートしなければなりません。
REQ16: The mechanism MUST allow the SIP-PBX to provide its UAs with public or temporary Globally Routable UA URIs (GRUUs) [RFC5627].
REQ16：SIP-PBXは、公衆または一時的なグローバルにルーティング可能なUAのURI（GRUUs）[RFC5627]とのユーザエージェントを提供することを可能にしなければならないメカニズム。
REQ17: The mechanism MUST work over any existing transport specified for SIP, including UDP.
REQ17：メカニズムはUDPを含め、SIPに指定された既存のトランスポートを介して動作する必要があります。
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：機構が任意に割り当てられたSIP URIのような電話番号のために使用されるものと比べて機構の完全な変更を必要とせず、単に電話番号とは対照的に、[RFC3261]で指定された一連のを可能にするように拡張可能でなければなりません。
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.
以下desirablesに加えて、一般的な目的は、標準化されたメカニズムの速い市場での採用を奨励するために、既存のSSPとSIP-PBXの実装の大幅な人口にのみ、比較的控えめな変更を必要とすることです。市場導入のしやすさは、ここでは最も重要です。多くのSIP-のPBXとのSSPは、REGISTERメソッドに基づくメカニズムを実装して、それらの実装に大幅な変更の必要性は、近い将来における単一の標準に収束を阻止します。
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がSIP-PBXにSIPトランキングサービスを提供するために、通常のUAにSIPサービスを提供するためのメカニズムを利用することを可能にするべきです。
DES2: The mechanism SHOULD scale to SIP-PBXs of several thousand assigned telephone numbers.
DES2：メカニズムは、数千割り当てられた電話番号の-のPBXをSIPに拡大すべきです。
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.
第三のドメインがSIP-PBXへの以降の配信のためのSSPへのルートリクエストをすることができる手段によって、この仕事の範囲外です。これは、使用されるRFC 3263に基づいて、通常のルーティングを必要とREQ13、に関連しています。
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は、割り当てられた数値の組を認識する必要があり、そのユーザーにこれらの数字を割り当てます。自動化され、そのSSPから、取得するためにSIP-PBXするための手段と、割り当てられた電話番号のセットが、プロビジョニング・トピックであると考えられます。
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.
文書の内容は、当該個人が枚挙にいとまがないこと、MARTINI WG内の広範囲の議論からコンパイルされています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]ローゼンバーグ、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]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3327]ウィリス、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]ガルシア・マーチン、M.、Henrikson、E.、およびD.ミルズ、RFC "第三世代パートナーシッププロジェクト（3GPP）のためのセッション開始プロトコル（SIP）のプライベートヘッダ（P-ヘッダー）の拡張" 3455、2003年1月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinneと、H.、 "電話番号については、TEL 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]バーンズ、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]ジェニングス、C.、マーイ、R.、およびF. Audet、RFC 5626、2009年10月 "セッション開始プロトコル（SIP）におけるクライアント開始された接続の管理"。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]ローゼンバーグ、J.、RFC 5627、2009年10月 "セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザエージェントのURI（GRUUs）の取得と使用" を参照してください。
[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.0、2006年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.0 2010年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_TS_182025] ETSI TS 182 025には、「電気通信およびインターネットは高度なネットワーク（TISPAN）のためのサービスおよびプロトコルを収束し、ビジネスは、トランキング、建築と機能説明」。
Authors' Addresses
著者のアドレス
John Elwell Siemens Enterprise Communications
ジョンエルウェルシーメンスエンタープライズコミュニケーションズ
EMail: john.elwell@siemens-enterprise.com
メールアドレス：john.elwell@siemens-enterprise.com
Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA
Hadrielカプランアクメパケット71サードアベニュー。バーリントン、MA 01803 USA
EMail: hkaplan@acmepacket.com
メールアドレス：hkaplan@acmepacket.com