[要約] RFC 5947は、SIPにおける複数のアドレスのレコード（AOR）の到達性情報に関する要件を定義しています。このRFCの目的は、SIPベースの通信システムで複数のAORに対する到達性情報を効果的に管理するためのガイドラインを提供することです。
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登録メカニズムの要件を示しています。これは、小規模から中規模のプライベートブランチ交換（PBX）をサポートするために、SIPサービスプロバイダーによる大規模な展開に適しています。要件は、E.164の数値に基づいて、最小限のサポートAORSを可能にするソリューションのものです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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）にリクエストを送信する必要がある場合、ロケーションサービスを使用して、登録された連絡先ユニバーサルリソース識別子（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 AORに対して権威あるSIPプライベートブランチエクスチェンジ（SIP-PBX）を使用しています。このSIP-PBXは、SIP-PBXがホストするユーザーのこれらのAORのレジストラ/プロキシとして機能します。SIPサービスプロバイダー（SSP）は、SIP-PBXにSIP Pearing/Trunking機能を提供します。SIP-PBXは、SSPがこれらのAORをターゲットにしたインバウンド外のSIPリクエストを処理できるように、SSPから到達可能である必要があり、これらの要求を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-PBXSをサポートするのに十分ではないことが示されています。特に、RFC 3263の手順は一般に不適切ですが、いくつかのより大きなSIP-PBXSを除きます。現在の展開では、SIPレジスタメソッドに基づいた到達可能性情報の動的提供のメカニズムが一般的に使用されています。ただし、これらのメカニズムは詳細に異なり、SIP-PBXSと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登録メカニズムの要件を示しています。メカニズムは、小規模から中規模のSIP-PBXをサポートするために、SSPによる大規模な展開に適しています。要件は、E.164の数値に基づいて、最小限のサポートAORSを可能にするソリューションのものです。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
他の多くの基準組織が、SSPに登録するSIP-PBX、特にETSI [ETSI_TS_182025]および第3世代パートナーシッププロジェクト（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 : :
- - - - - - - - - - - - - -
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は、相互に合意されたSIP AORを使用してSIPレジスタリクエストを生成します。通常、SIP-PBXのメインアテンダント/レセプションデスク番号に基づいています。AORは多くの場合、SSPのドメインにあり、レジスタリクエストに使用されるurisとforの両方がそのaorを識別します。あらゆる点で、典型的なユーザーのUAからのように、「通常の」SIPレジスタリクエストとしてワイヤーに表示されます。ただし、一般に、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応答には、他のSIPウリスまたはテルウリス（つまり、電話の電話）をリストするP Associated-URI（PAU）[RFC3455]ヘッダーフィールドが含まれています。sip-pbxの数字。これは暗黙的に登録されているAORです。レジスタリクエストからの登録された到達可能性情報は、明示的に登録された単一の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のみを残します。この決定は、レジストラのデータベース（つまり、Home Subscriber Server（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の両方にサービスを提供しているが、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との通常の[RFC3261]の手順に従うことを期待しています。レジストラがSIP-PBXSへのリクエストに対して別のプラクティスを採用している場合、登録が異なることを示すことはないため、ミドルボックスがそのような要求を正しくルーティングできない可能性があります。
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の暗黙的な登録が発生したことを示していないことに注意してください。
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].
[RFC3966]のTel URIのABNFルールに基づいて、「ワイルドカード」Pausの現在の構文はTel URISにとって違法です。
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.
Proxy-RegistrarがSIP-PBXのAORのいずれかを対象としたリクエストの登録解決のために[RFC3261]に従い[RFC3261]、したがって、リクエストURIを登録された連絡先URIに置き換える場合、どのAORがリクエストの意図されたターゲットであるかは明らかではありません。たとえば、To URIは、リクエストがプロキシレジストラに到達する前に転送/リターゲティングされた場合、意図したターゲットAORを含めない場合があります。レジストラとSIP-PBXの間のいくつかのミドルボックスは、この問題を修正するためにリクエスト-URIを特に上書きします。場合によっては、P-Called-Party-IDヘッダーフィールド[RFC3455]には、意図したターゲットAORが含まれます。場合によっては、History-INFOヘッダーフィールド[RFC4244]にそれが含まれます。SIP-PBXは、必要な情報を見つけるためにどこを探すべきかを知る必要があり、履歴INFOの場合、必要な情報を含む特定の要素を特定する必要があります。
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リクエストには意図したターゲットSIPがあります。Request-URIの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-PBXSは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.
多くのSSPSは、from、p-asserted-Identity（pai）、またはp-preferred-Identity（ppi）[rfc3325]ヘッダーフィールドのURIを1つのヘッダーフィールドでチェックすることにより、SIP-PBXからのリクエストの1次レベルの認可を実行します。同じ連絡先URIおよび/またはレイヤー-3 IPアドレスに対して、明示的または暗黙的に登録されたAORのいずれかを一致させます。ただし、一部のSIP-PBXSは、非登録要求に使用している連絡先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 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.
一部のSSPは、SIP-PBXから受け取ったSIPリクエストでPAIまたはPPI URIが明示的または暗黙的に登録されたAORの1つに一致することを期待していますが、一部のSIP-PBXはローカルIPアドレス、ホスト名、またはドメイン名を使用してURIを生成します。一部のSSPSは、SIP-PBXから受け取ったSIPリクエストでPAIまたはPPI URIが、呼び出し当事者の暗黙的に登録された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がPAIまたはPPI URIをSSPに許容できる値に変更しない限り、SIP-PBXを超えたソースからのリクエスト（SIP-PBXによって転送される）を除外することができます（場合は、呼び出しユーザーを識別しなくなります）。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が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：メカニズムは、割り当てられた電話番号のセットを、隣接する範囲、離散、または2つの任意の組み合わせで存在する可能性がある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：メカニズムは、SSPが割り当てられた電話番号をターゲットにしたSIP-PBXインバウンドリクエストにルーティングできるようにするために、SIP-PBXがSSPにリーチ性情報を登録できるようにする必要があります。
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に接続されたUASが、登録プロセスにSSPを関与させる必要なく、それらの電話番号を対象としたリクエストを受信するために、割り当てられた電話番号に基づいてAORSの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が独自のUASで発信され、割り当てられた電話番号をターゲットにしたリクエストを処理できるようにする必要があります。
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に内部と同様にルーティングできます。それらの電話番号へのリクエスト。
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：メカニズムは、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.
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.
言い換えれば、メカニズムは、一方がメカニズムを使用していると信じている状況を回避するために必要であり、他の側はそれがそうではないと信じている。単一の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-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.
Req13：特定のSIP-PBXおよびそのSSPについて、他のドメインに影響を与える必要はありません。他のドメインは、通常のRFC 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：メカニズムは、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].
Req16：メカニズムにより、SIP-PBXがUASに公共または一時的にルーティング可能な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]で指定されているように、割り当てられた電話番号のセットが[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]で指定されているarbitrarilyに割り当てられた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-PBXSと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がSIPトランキングサービスをSIP-PBXSに提供するために、SPSサービスを通常のUASに提供するメカニズムを活用できるようにする必要があります。
DES2: The mechanism SHOULD scale to SIP-PBXs of several thousand assigned telephone numbers.
DES2：メカニズムは、数千の割り当てられた電話番号のSIP-PBXSにスケーリングする必要があります。
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-PBXSで使用される可能性が高くなりますが、正確な制限を与えることは不可能であり、したがって数千をサポートできることを望んでいます。
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.
3番目のドメインが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.
ドキュメントの内容は、マティーニWG内の広範な議論から編集されており、関係者は言及するには多すぎることです。
[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：SESSION INTIANIATION Protocol」、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 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] Willis、D。およびB. Hoeneisen、「Addjacentコンタクトを登録するためのセッション開始プロトコル（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、「Private Header（P-Header）セッション開始プロトコル（SIP）の第3世代パートナーシッププロジェクト（3GPP）の拡張」、RFC3455、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] 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）でグローバルにルーティング可能なユーザーエージェントURIS（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.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）、ステージ3 "、3GPP TS 24.229 10.0.0、2010年6月に基づくIPマルチメディアコールコントロールプロトコル。
[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
John Elwell Siemens Enterprise Communications
EMail: john.elwell@siemens-enterprise.com
Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA
ハドリエル・カプランACMEパケット71サードアベニュー、バーリントン、マサチューセッツ州01803 USA
EMail: hkaplan@acmepacket.com