[要約] RFC 6140は、SIPで複数の電話番号を登録するための仕様です。目的は、SIPクライアントが複数の電話番号を使用できるようにすることです。
Internet Engineering Task Force (IETF) A.B. Roach
Request for Comments: 6140 Tekelec
Updates: 3680 March 2011
Category: Standards Track
ISSN: 2070-1721
Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）での複数の電話番号の登録
Abstract
概要
This document defines a mechanism by which a Session Initiation Protocol (SIP) server acting as a traditional Private Branch Exchange (PBX) can register with a SIP Service Provider (SSP) to receive phone calls for SIP User Agents (UAs). In order to function properly, this mechanism requires that each of the Addresses of Record (AORs) registered in bulk map to a unique set of contacts. This requirement is satisfied by AORs representing phone numbers regardless of the domain, since phone numbers are fully qualified and globally unique. This document therefore focuses on this use case.
このドキュメントは、従来のプライベートブランチエクスチェンジ（PBX）として機能するセッション開始プロトコル（SIP）サーバーがSIPサービスプロバイダー（SSP）に登録して、SIPユーザーエージェント（UAS）の電話を受けるメカニズムを定義します。適切に機能するためには、このメカニズムでは、一意の連絡先セットにバルクマップで登録されているレコード（AOR）の各アドレスが必要です。この要件は、電話番号が完全に資格があり、グローバルに一意であるため、ドメインに関係なく電話番号を表すAORによって満たされます。したがって、このドキュメントは、このユースケースに焦点を当てています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6140.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6140で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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. Constraints .....................................................3
3. Terminology and Conventions .....................................4
4. Mechanism Overview ..............................................5
5. Registering for Multiple Phone Numbers ..........................5
5.1. SIP-PBX Behavior ...........................................5
5.2. Registrar Behavior .........................................6
5.3. SIP URI "user" Parameter Handling ..........................8
6. SSP Processing of Inbound Requests ..............................8
7. Interaction with Other Mechanisms ...............................9
7.1. Globally Routable User Agent URIs (GRUU) ...................9
7.1.1. Public GRUUs ........................................9
7.1.2. Temporary GRUUs ....................................11
7.2. Registration Event Package ................................16
7.2.1. SIP-PBX Aggregate Registration State ...............16
7.2.2. Individual AOR Registration State ..................16
7.3. Client-Initiated (Outbound) Connections ...................18
7.4. Non-Adjacent Contact Registration (Path) and
Service-Route Discovery ...................................19
8. Examples .......................................................20
8.1. Usage Scenario: Basic Registration ........................20
8.2. Usage Scenario: Using Path to Control Request URI .........22
9. IANA Considerations ............................................24
9.1. New SIP Option Tag ........................................24
9.2. New SIP URI Parameters ....................................25
9.2.1. 'bnc' SIP URI Parameter ............................25
9.2.2. 'sg' SIP URI Parameter .............................25
9.3. New SIP Header Field Parameter ............................25
10. Security Considerations .......................................25
11. Acknowledgements ..............................................28
12. References ....................................................28
12.1. Normative References .....................................28
12.2. Informative References ...................................29
Appendix A. Requirements Analysis .................................31
The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. One of SIP's primary functions is providing rendezvous between users. By design, these rendezvous have been provided through a combination of the server look-up procedures defined in RFC 3263 [4] and the registrar procedures described in RFC 3261 [3].
セッション開始プロトコル（SIP）は、1人以上の参加者とセッションを作成、変更、終了するためのアプリケーション層制御（シグナリング）プロトコルです。SIPの主要な機能の1つは、ユーザー間でランデブーを提供することです。設計上、これらのランデブーは、RFC 3263 [4]で定義されているサーバールックアップ手順とRFC 3261 [3]で説明されているレジストラ手順の組み合わせにより提供されています。
The intention of the original protocol design was that any user's AOR (Address of Record) would be handled by the authority indicated by the hostport portion of the AOR. The users would register individual reachability information with this authority, which would then route incoming requests accordingly.
元のプロトコル設計の意図は、ユーザーのAOR（記録アドレス）がAORのホストポート部分によって示される当局によって処理されることでした。ユーザーは、この権限に個々の到達可能性情報を登録し、それに応じて着信要求をルーティングします。
In actual deployments, some SIP servers have been deployed in architectures that, for various reasons, have requirements to provide dynamic routing information for large blocks of AORs, where all of the AORs in the block were to be handled by the same server. For purposes of efficiency, many of these deployments do not wish to maintain separate registrations for each of the AORs in the block. Thus, an alternate mechanism to provide dynamic routing information for blocks of AORs is desirable.
実際の展開では、一部のSIPサーバーがアーキテクチャに展開されており、さまざまな理由で、ブロック内のすべてのAORが同じサーバーによって処理されるAORの大きなブロックに動的なルーティング情報を提供する要件があります。効率のために、これらの展開の多くは、ブロック内の各AORの個別の登録を維持したくありません。したがって、AORのブロックに動的なルーティング情報を提供する代替メカニズムが望ましいです。
Although the use of SIP REGISTER request messages to update reachability information for multiple users simultaneously is somewhat beyond the original semantics defined for REGISTER requests by RFC 3261 [3], this approach has seen significant deployment in certain environments. In particular, deployments in which small to medium SIP-PBX servers are addressed using E.164 numbers have used this mechanism to avoid the need to maintain DNS entries or static IP addresses for the SIP-PBX servers.
SIPレジスタリクエストメッセージを使用して複数のユーザーのリーチビリティ情報を同時に更新することは、RFC 3261 [3]によるレジスタリクエストのために定義された元のセマンティクスを多少超えていますが、このアプローチでは特定の環境で重要な展開が見られました。特に、SIP-PBXサーバーのDNSエントリまたは静的IPアドレスを維持する必要性を回避するために、このメカニズムを使用して、小規模から中程度のSIP-PBXサーバーを使用してアドレス指定される展開が行われました。
In recognition of the momentum that REGISTER-based approaches have seen in deployments, this document defines a REGISTER-based approach. Since E.164-addressed UAs are very common today in SIP-PBX environments, and since SIP URIs in which the user portion is an E.164 number are always globally unique, regardless of the domain, this document focuses on registration of SIP URIs in which the user portion is an E.164 number.
レジスタベースのアプローチが展開に見られる勢いを認識して、このドキュメントはレジスタベースのアプローチを定義しています。e.164に吸収されたUASは今日ではSIP-PBX環境で非常に一般的であるため、ユーザー部分がE.164番号であるSIP URIは、ドメインに関係なく常にグローバルに一意です。ユーザー部分はE.164番号です。
Within the problem space that has been established for this work, several constraints shape our solution. These are defined in the MARTINI requirements document [22] and are analyzed in Appendix A. In terms of impact to the solution at hand, the following two constraints have the most profound effect: (1) The SIP-PBX cannot be assumed to be assigned a static IP address; and (2) No DNS entry can be relied upon to consistently resolve to the IP address of the SIP-PBX.
この作業のために確立された問題の分野では、いくつかの制約が私たちのソリューションを形成します。これらはMartini要件ドキュメント[22]で定義されており、付録Aで分析されています。手元のソリューションへの影響に関して、次の2つの制約が最も深い効果を持っています。静的IPアドレスを割り当てました。（2）SIP-PBXのIPアドレスに一貫して解決するDNSエントリを依存することはできません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [2]に記載されているように解釈される。
Further, the term "SSP" is meant as an acronym for a "SIP Service Provider," while the term "SIP-PBX" is used to indicate a SIP Private Branch Exchange.
さらに、「SSP」という用語は「SIPサービスプロバイダー」の頭字語として意味され、「SIP-PBX」という用語は、SIPプライベートブランチ交換を示すために使用されます。
Indented portions of the document, such as this one, form non-normative, explanatory sections of the document.
このようなドキュメントのインデント部分は、ドキュメントの非規範的な説明セクションを形成します。
Although SIP is a text-based protocol, some of the examples in this document cannot be unambiguously rendered without additional markup due to the constraints placed on the formatting of RFCs. This document uses the <allOneLine/> markup convention established in RFC 4475 [17] to avoid ambiguity and meet the RFC layout requirements. For the sake of completeness, the text defining this markup (Section 2.1 of RFC 4475 [17]) is reproduced in its entirety below:
SIPはテキストベースのプロトコルですが、このドキュメントの例のいくつかは、RFCのフォーマットに課される制約のため、追加のマークアップなしでは明確にレンダリングすることはできません。このドキュメントでは、RFC 4475 [17]で確立された<alloneline/>マークアップコンベンションを使用して、あいまいさを避け、RFCレイアウト要件を満たしています。完全性のために、このマークアップを定義するテキスト（RFC 4475 [17]のセクション2.1）を以下に複製します。
Several of these examples contain unfolded lines longer than 72 characters. These are captured between <allOneLine/> tags. The single unfolded line is reconstructed by directly concatenating all lines appearing between the tags (discarding any line feeds or carriage returns). There will be no whitespace at the end of lines. Any whitespace appearing at a fold-point will appear at the beginning of a line.
これらの例のいくつかには、72文字より長い展開された行が含まれています。これらは<alloneline/>タグ間でキャプチャされます。単一の展開ラインは、タグ間に表示されるすべての線を直接連結することにより再構築されます（ラインフィードまたはキャリッジリターンを破棄します）。線の終わりには、空白はありません。折りたたみ点に表示される白人は、行の先頭に表示されます。
The following represent the same string of bits:
以下は、同じ一連のビットを表しています。
Header-name: first value, reallylongsecondvalue, third value
Header-Name：最初の値、reallongSecondValue、3番目の値
<allOneLine> Header-name: first value, reallylongsecondvalue , third value </allOneLine>
<Alloneline> Header-Name：最初の値、reallongsecondValue、3番目の値</alloneline>
<allOneLine> Header-name: first value, reallylong second value, third value </allOneLine>
<Alloneline> Header-Name：最初の値、本当にロング2番目の値、3番目の値</alloneline>
Note that this is NOT SIP header-line folding, where different strings of bits have equivalent meaning.
これは、ビットの異なる文字列が同等の意味を持つSIPヘッダーライン折りたたみではないことに注意してください。
The overall mechanism is achieved using a REGISTER request with a specially formatted Contact URI. This document also defines an option tag that can be used to ensure that a registrar and any intermediaries understand the mechanism described herein.
全体的なメカニズムは、特別にフォーマットされた連絡先URIを使用したレジスタリクエストを使用して達成されます。このドキュメントでは、レジストラと仲介者が本明細書に記載されているメカニズムを理解するために使用できるオプションタグも定義します。
The Contact URI itself is tagged with a URI parameter to indicate that it actually represents multiple phone-number-associated contacts.
連絡先URI自体には、URIパラメーターがタグ付けされており、実際に複数の電話番号関連の連絡先を表していることを示します。
We also define some lightweight extensions to the Globally Routable UA URIs (GRUU) mechanism defined by RFC 5627 [20] to allow the use of public and temporary GRUUs assigned by the SSP.
また、RFC 5627 [20]によって定義されたグローバルにルーティング可能なUA URIS（GRUU）メカニズムにいくつかの軽量拡張機能を定義し、SSPによって割り当てられた公共および一時的なGruusの使用を可能にします。
Aside from these extensions, the REGISTER request itself is processed by a registrar in the same way as normal registrations: by updating its location service with additional AOR-to-Contact bindings.
これらの拡張機能とは別に、レジスタリクエスト自体は、通常の登録と同じ方法でレジストラによって処理されます。
Note that the list of AORs associated with a SIP-PBX is a matter of local provisioning at the SSP and the SIP-PBX. The mechanism defined in this document does not provide any means to detect or recover from provisioning mismatches (although the registration event package can be used as a standardized means for auditing such AORs; see Section 7.2.1).
SIP-PBXに関連付けられたAORのリストは、SSPおよびSIP-PBXでのローカルプロビジョニングの問題であることに注意してください。このドキュメントで定義されているメカニズムは、プロビジョニングの不一致から検出または回復する手段を提供しません（ただし、登録イベントパッケージは、そのようなAORを監査するための標準化された手段として使用できます。セクション7.2.1を参照）。
To register for multiple AORs, the SIP-PBX sends a REGISTER request to the SSP. This REGISTER request varies from a typical REGISTER request in two important ways. First, it MUST contain an option tag of "gin" in both a "Require" header field and a "Proxy-Require" header field. (The option tag "gin" is an acronym for "generate implicit numbers".) Second, in at least one "Contact" header field, it MUST include a Contact URI that contains the URI parameter "bnc" (which stands for "bulk number contact") and has no user portion (hence no "@" symbol). A URI with a "bnc" parameter MUST NOT contain a user portion. Except for the SIP URI "user" parameter, this URI MAY contain any other parameters that the SIP-PBX desires. These parameters will be echoed back by the SSP in any requests bound for the SIP-PBX.
複数のAORSに登録するために、SIP-PBXはSSPにレジスタリクエストを送信します。このレジスタリクエストは、2つの重要な方法で典型的なレジスタリクエストから異なります。まず、「「ジン」の「ジン」のオプションタグが「必要」ヘッダーフィールドと「プロキシリクイア」ヘッダーフィールドの両方に含まれている必要があります。（オプションタグ "gin"は、「暗黙の数字を生成する」の頭字語です。）次に、少なくとも1つの「連絡先」ヘッダーフィールドに、URIパラメーター「BNC」を含む連絡先URIを含める必要があります（「Bulk」数字の連絡先 "）とユーザー部分はありません（したがって、「@」記号はありません）。「BNC」パラメーターを備えたURIには、ユーザー部分が含まれてはなりません。SIP URI「ユーザー」パラメーターを除き、このURIにはSIP-PBXが望む他のパラメーターが含まれている場合があります。これらのパラメーターは、SIP-PBXに拘束された任意の要求で、SSPによってエコーされます。
Because of the constraints discussed in Section 2, the host portion of the Contact URI will generally contain an IP address, although nothing in this mechanism enforces or relies upon that fact. If the SIP-PBX operator chooses to maintain DNS entries that resolve to the IP address of his SIP-PBX via RFC 3263 resolution procedures, then this mechanism works just fine with domain names in the "Contact" header field.
セクション2で説明されている制約のため、接触URIのホスト部分には一般にIPアドレスが含まれますが、このメカニズムにはその事実に依存しているか依存していません。SIP-PBXオペレーターがRFC 3263解決手順を介してSIP-PBXのIPアドレスに解決するDNSエントリを維持することを選択した場合、このメカニズムは「コンタクト」ヘッダーフィールドのドメイン名で正常に機能します。
The "bnc" URI parameter indicates that special interpretation of the Contact URI is necessary: instead of indicating the insertion of a single Contact URI into the location service, it indicates that multiple URIs (one for each associated AOR) should be inserted.
「BNC」URIパラメーターは、接触URIの特別な解釈が必要であることを示しています。単一の接触URIのロケーションサービスへの挿入を示す代わりに、複数のURI（関連する各AORに1つ）を挿入する必要があることを示します。
Any SIP-PBX implementing the registration mechanism defined in this document MUST also support the path mechanism defined by RFC 3327 [10], and MUST include a 'path' option tag in the "Supported" header field of the REGISTER request (which is a stronger requirement than imposed by the path mechanism itself). This behavior is necessary because proxies between the SIP-PBX and the registrar may need to insert "Path" header field values in the REGISTER request for this document's mechanism to function properly, and, per RFC 3327 [10], they can only do so if the User Agent Client (UAC) inserted the option tag in the "Supported" header field. In accordance with the procedures defined in RFC 3327 [10], the SIP-PBX is allowed to ignore the "Path" header fields returned in the REGISTER response.
このドキュメントで定義されている登録メカニズムを実装するSIP-PBXは、RFC 3327 [10]で定義されたパスメカニズムもサポートする必要があり、レジスタリクエストの「サポートされている」ヘッダーフィールドに「パス」オプションタグを含める必要があります（これはパスメカニズム自体によって課されるよりも強い要件）。SIP-PBXとレジストラの間のプロキシは、このドキュメントのメカニズムが適切に機能するためのレジスタリクエストに「パス」ヘッダーフィールド値を挿入する必要があるため、この動作が必要です。ユーザーエージェントクライアント（UAC）が「サポートされている」ヘッダーフィールドにオプションタグを挿入した場合。RFC 3327 [10]で定義されている手順に従って、SIP-PBXはレジスタ応答で返される「パス」ヘッダーフィールドを無視することができます。
The registrar, upon receipt of a REGISTER request containing at least one "Contact" header field with a "bnc" parameter, will use the value in the "To" header field to identify the SIP-PBX for which registration is being requested. It then authenticates the SIP-PBX (e.g., using SIP digest authentication, mutual Transport Layer Security (TLS) [18], or some other authentication mechanism). After the SIP-PBX is authenticated, the registrar updates its location service with a unique AOR-to-Contact mapping for each of the AORs associated with the SIP-PBX. Semantically, each of these mappings will be treated as a unique row in the location service. The actual implementation may, of course, perform internal optimizations to reduce the amount of memory used to store such information.
レジストラは、「BNC」パラメーターを備えた少なくとも1つの「連絡先」ヘッダーフィールドを含むレジスタリクエストを受け取ったときに、 "to"ヘッダーフィールドの値を使用して、登録が要求されているSIP-PBXを識別します。次に、SIP-PBX（たとえば、SIPダイジェスト認証、相互輸送層セキュリティ（TLS）[18]、またはその他の認証メカニズムを使用して）を認証します。SIP-PBXが認証された後、レジストラはSIP-PBXに関連付けられた各AORの一意のAORから接触マッピングでロケーションサービスを更新します。意味的には、これらの各マッピングは、ロケーションサービスの一意の行として扱われます。もちろん、実際の実装は、そのような情報を保存するために使用されるメモリの量を減らすために内部最適化を実行する場合があります。
For each of these unique rows, the AOR will be in the format that the SSP expects to receive from external parties (e.g., "sip:+12145550102@ssp.example.com"). The corresponding contact will be formed by adding to the REGISTER request's Contact URI a user portion containing the fully qualified, E.164-formatted number (including the preceding "+" symbol) and removing the "bnc" parameter. Aside from the initial "+" symbol, this E.164-formatted number MUST consist exclusively of digits from 0 through 9 and explicitly MUST NOT contain any visual separator symbols (e.g., "-", ".", "(", or ")"). For example, if the "Contact" header field contains the URI <sip:198.51.100.3:5060;bnc>, then the contact value associated with the aforementioned AOR will be <sip:+12145550102@198.51.100.3:5060>.
これらの一意の行のそれぞれについて、AORはSSPが外部関係者から受け取ることを期待する形式になります（例： "sip：12145550102@ssp.example.com"）。対応する連絡先は、レジスタリクエストの連絡先に、完全に資格のあるE.164形式の数字（前の「シンボルを含む）を含むユーザー部分を連絡し、「BNC」パラメーターを削除することによって形成されます。初期の「シンボルとは別に、このE.164形式の数値は0〜9までの数字のみで構成されている必要があり、視覚的なセパレーター記号（例： " - "、 "。"、 "（"、 "（"、 "））を明示的に含めてはなりません。） "）。たとえば、「コンタクト」ヘッダーフィールドにURI <SIP：198.51.100.3：5060; BNC>が含まれている場合、前述のAORに関連付けられた接点値は<SIP：12145550102@198.51.100.3：5060>です。
Although the SSP treats this registration as a number of discrete rows for the purpose of re-targeting incoming requests, the renewal, expiration, and removal of these rows is bound to the registered contact. In particular, this means that REGISTER requests that attempt to de-register a single AOR that has been implicitly registered MUST NOT remove that AOR from the bulk registration. In this circumstance, the registrar simply acts as if the UA attempted to unregister a contact that wasn't actually registered (e.g., return the list of presently registered contacts in a success response). A further implication of this property is that an individual extension that is implicitly registered may also be explicitly registered using a normal, non-bulk registration (subject to SSP policy). If such a registration exists, it is refreshed independently of the bulk registration and is not removed when the bulk registration is removed.
SSPは、この登録を、着信要求を再ターゲットする目的で多数の離散行として扱いますが、これらの行の更新、有効期限、および削除は登録された連絡先に拘束されます。特に、これは、暗黙的に登録された単一のAORを削除しようとする試みが、そのAORをバルク登録から削除してはならないことを意味することを意味します。この状況では、レジストラは、UAが実際に登録されていない連絡先の登録を解除しようとしたかのように機能します（たとえば、成功応答で現在登録されている連絡先のリストを返します）。このプロパティのさらなる意味は、暗黙的に登録されている個々の拡張機能が、通常の非バルク登録（SSPポリシーの対象）を使用して明示的に登録される可能性があることです。そのような登録が存在する場合、それはバルク登録とは無関係に更新され、バルク登録が削除されたときに削除されません。
A registrar that receives a REGISTER request containing a Contact URI with both a "bnc" parameter and a user portion MUST NOT send a 200- class (Success) response. If no other error is applicable, the registrar can use a 400 (Bad Request) response to indicate this error condition.
「BNC」パラメーターとユーザー部分の両方を持つ連絡先URIを含むレジスタリクエストを受信するレジストラは、200クラス（成功）応答を送信してはなりません。他のエラーが適用されない場合、レジストラは400（悪い要求）応答を使用して、このエラー条件を示すことができます。
Note that the preceding paragraph is talking about the user portion of a URI:
前の段落は、URIのユーザー部分について話していることに注意してください。
sip:+12145550100@example.com
^^^^^^^^^^^^
A registrar compliant with this document MUST support the path mechanism defined in RFC 3327 [10]. The rationale for support of this mechanism is given in Section 5.1.
このドキュメントに準拠したレジストラは、RFC 3327で定義されているパスメカニズムをサポートする必要があります[10]。このメカニズムのサポートの理論的根拠は、セクション5.1に記載されています。
Aside from the "bnc" parameter, all URI parameters present on the Contact URI in the REGISTER request MUST be copied to the contact value stored in the location service.
「BNC」パラメーターとは別に、レジスタリクエストの連絡先URIに存在するすべてのURIパラメーターは、ロケーションサービスに保存されている連絡先値にコピーする必要があります。
If the SSP servers perform processing based on User Agent Capabilities (as defined in RFC 3840 [13]), they will treat any feature tags present on a "Contact" header field with a "bnc" parameter in its URI as applicable to all of the resulting AOR-to-Contact mappings. Similarly, any option tags present on the REGISTER request that indicate special handling for any subsequent requests are also applicable to all of the AOR-to-Contact mappings.
SSPサーバーがユーザーエージェント機能（RFC 3840 [13]で定義されているように）に基づいて処理を実行する場合、「コンタクト」ヘッダーフィールドに存在する機能タグを、すべてに適用できる「BNC」パラメーターを持つ「BNC」パラメーターを扱います。結果のAORから接触マッピング。同様に、レジスタリクエストに存在するオプションタグは、後続のリクエストの特別な取り扱いを示すもので、すべてのAORから接触マッピングのすべてにも適用できます。
This document does not modify the behavior specified in RFC 3261 [3] for inclusion of the "user" parameter on Request URIs. However, to avoid any ambiguity in handling at the SIP-PBX, the following normative behavior is imposed on its interactions with the SSP.
このドキュメントは、RFC 3261 [3]で指定された動作を変更して、「ユーザー」パラメーターをリクエストに応じてurisに含めることは変更されません。ただし、SIP-PBXでの取り扱いのあいまいさを回避するために、SSPとの相互作用に次の規範的な挙動が課されます。
When a SIP-PBX registers with an SSP using a Contact URI containing a "bnc" parameter, that Contact URI MUST NOT include a "user" parameter. A registrar that receives a REGISTER request containing a Contact URI with both a "bnc" parameter and a "user" parameter MUST NOT send a 200-class (success) response. If no other error is applicable, the registrar can use a 400 (Bad Request) response to indicate this error condition.
SIP-PBXが「BNC」パラメーターを含むコンタクトURIを使用してSSPを使用してレジスタする場合、その連絡先URIは「ユーザー」パラメーターを含めてはなりません。「BNC」パラメーターと「ユーザー」パラメーターの両方を持つ連絡先URIを含むレジスタリクエストを受信するレジストラは、200クラス（成功）応答を送信してはなりません。他のエラーが適用されない場合、レジストラは400（悪い要求）応答を使用して、このエラー条件を示すことができます。
Note that the preceding paragraph is talking about the "user" parameter of a URI:
前の段落は、URIの「ユーザー」パラメーターについて話していることに注意してください。
sip:+12145550100@example.com;user=phone
^^^^^^^^^^
When a SIP-PBX receives a request from an SSP, and the Request URI contains a user portion corresponding to an AOR registered using a Contact URI containing a "bnc" parameter, then the SIP-PBX MUST NOT reject the request (or otherwise cause the request to fail) due to the absence, presence, or value of a "user" parameter on the Request URI.
SIP-PBXがSSPからリクエストを受信し、リクエストが「BNC」パラメーターを含む連絡先URIを使用して登録されたAORに対応するユーザー部分を含む場合、SIP-PBXはリクエストを拒否してはなりません（リクエストURIの「ユーザー」パラメーターの不在、存在、または値による失敗の要求）。
In general, after processing the AOR-to-Contact mapping described in the preceding section, the SSP proxy/registrar (or equivalent entity) performs traditional proxy/registrar behavior, based on the mapping. For any inbound SIP requests whose AOR indicates an E.164 number assigned to one of the SSP's customers, this will generally involve setting the target set to the registered contacts associated with that AOR and performing request forwarding as described in Section 16.6 of RFC 3261 [3]. An SSP using the mechanism defined in this document MUST perform such processing for inbound INVITE requests and SUBSCRIBE requests to the "reg" event package (see Section 7.2.2) and SHOULD perform such processing for all other method types, including unrecognized SIP methods.
一般に、前のセクションで説明したAORから接触マッピングを処理した後、SSPプロキシ/レジストラ（または同等のエンティティ）は、マッピングに基づいて従来のプロキシ/レジストラの動作を実行します。AORがSSPの顧客のいずれかに割り当てられたE.164番号を示すインバウンドSIP要求の場合、これには通常、ターゲットセットをそのAORに関連付けられた登録連絡先に設定し、RFC 3261のセクション16.6で説明されているリクエスト転送を実行することが含まれます。3]。このドキュメントで定義されているメカニズムを使用するSSPは、インバウンド招待要求に対してそのような処理を実行し、「Reg」イベントパッケージ（セクション7.2.2を参照）にリクエストを購読する必要があり、認識されていないSIPメソッドを含む他のすべてのメソッドタイプに対してそのような処理を実行する必要があります。
The following sections describe the means by which this mechanism interacts with relevant REGISTER-related extensions currently defined by the IETF.
次のセクションでは、このメカニズムが現在IETFによって定義されている関連するレジスタ関連拡張機能と相互作用する手段について説明します。
To enable advanced services to work with UAs behind a SIP-PBX, it is important that the GRUU mechanism defined by RFC 5627 [20] work correctly with the mechanism defined by this document -- that is, that user agents served by the SIP-PBX can acquire and use GRUUs for their own use.
高度なサービスがSIP-PBXの背後にあるUASと連携できるようにするために、RFC 5627 [20]によって定義されたGruuメカニズムは、このドキュメントで定義されたメカニズム、つまりSIPによって提供されるユーザーエージェントで正しく機能することが重要です。PBXは、Gruusを取得して使用するために使用できます。
Support of public GRUUs is OPTIONAL in SSPs and SIP-PBXes.
Public Gruusのサポートは、SSPSおよびSIP-PBXESでオプションです。
When a SIP-PBX registers a Bulk Number Contact (a contact with a "bnc" parameter), and also invokes GRUU procedures for that contact during registration, then the SSP will assign a public GRUU to the SIP-PBX in the normal fashion. Because the URI being registered contains a "bnc" parameter, the GRUU will also contain a "bnc" parameter. In particular, this means that the GRUU will not contain a user portion.
SIP-PBXがバルク番号の接触（「BNC」パラメーターとの接触）を登録し、登録中にその接触のGruu手順を呼び出すと、SSPは通常の方法でSIP-PBXにパブリックGruを割り当てます。登録されているURIには「BNC」パラメーターが含まれているため、Gruuには「BNC」パラメーターも含まれます。特に、これはGruuにユーザー部分が含まれていないことを意味します。
When a UA registers a contact with the SIP-PBX using GRUU procedures, the SIP-PBX provides to the UA a public GRUU formed by adding an "sg" parameter to the GRUU parameter it received from the SSP. This "sg" parameter contains a disambiguation token that the SIP-PBX can use to route inbound requests to the proper UA.
UAがGRUU手順を使用してSIP-PBXとの接触を登録すると、SIP-PBXはUAに、SSPから受信したGruuパラメーターに「SG」パラメーターを追加することにより形成されたパブリックGruuを提供します。この「SG」パラメーターには、SIP-PBXが適切なUAにインバウンドリクエストをルーティングするために使用できる曖昧性除去トークンが含まれています。
So, for example, when the SIP-PBX registers with the following "Contact" header field:
したがって、たとえば、SIP-PBXが次の「連絡先」ヘッダーフィールドを登録する場合：
Contact: <sip:198.51.100.3;bnc>;
+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
the SSP may choose to respond with a "Contact" header field that looks like this:
SSPは、次のような「コンタクト」ヘッダーフィールドで応答することを選択できます。
<allOneLine>
Contact: <sip:198.51.100.3;bnc>;
pub-gruu="sip:ssp.example.com;bnc;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6";
+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=7200
</allOneLine>
When its own UAs register using GRUU procedures, the SIP-PBX can then add whatever device identifier it feels appropriate in an "sg" parameter and present this value to its own UAs. For example, assume the UA associated with the AOR "+12145550102" sent the following "Contact" header field in its REGISTER request:
Gruu手順を使用して独自のUASレジスタを使用すると、SIP-PBXは「SG」パラメーターで適切だと思われるデバイス識別子を追加し、この値を独自のUASに追加できます。たとえば、AORに関連付けられているUAが「12145550102」に関連付けられていると仮定します。レジスタリクエストで次の「連絡先」ヘッダーフィールドが送信されます。
Contact: <sip:line-1@10.20.1.17>;
+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
The SIP-PBX will add an "sg" parameter to the pub-gruu it received from the SSP with a token that uniquely identifies the device (possibly the URN itself; possibly some other identifier), insert a user portion containing the fully qualified E.164 number associated with the UA, and return the result to the UA as its public GRUU. The resulting "Contact" header field sent from the SIP-PBX to the registering UA would look something like this:
SIP-PBXは、デバイス（おそらくurn自体、おそらく他の識別子）を一意に識別するトークンを使用してSSPから受信したPub-gruuに「SG」パラメーターを追加し、完全に適格なEを含むユーザー部分を挿入します。.164 UAに関連付けられた数字、および結果をその公開gruuとしてUAに返します。SIP-PBXから登録UAに送信される結果の「コンタクト」ヘッダーフィールドは、次のようになります。
<allOneLine>
Contact: <sip:line-1@10.20.1.17>;
pub-gruu="sip:+12145550102@ssp.example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6";
+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
;expires=3600
</allOneLine>
When an incoming request arrives at the SSP for a GRUU corresponding to a bulk number contact ("bnc"), the SSP performs slightly different processing for the GRUU than it would for a URI without a "bnc" parameter. When the GRUU is re-targeted to the registered bulk number contact, the SSP MUST copy the "sg" parameter from the GRUU to the new target. The SIP-PBX can then use this "sg" parameter to determine to which user agent the request should be routed. For example, the first line of an INVITE request that has been re-targeted to the SIP-PBX for the UA shown above would look like this:
バルク番号の接触（「BNC」）に対応するGRUUのSSPに着信要求が到着すると、SSPは「BNC」パラメーターのないURIとは異なる処理をGRUUに対してわずかに異なる処理を実行します。gruuが登録されたバルク番号の連絡先に再ターゲットされている場合、SSPはGruuから「SG」パラメーターを新しいターゲットにコピーする必要があります。SIP-PBXは、この「SG」パラメーターを使用して、リクエストをルーティングするユーザーエージェントを決定できます。たとえば、上記のUAのSIP-PBXに再ターゲットされた招待リクエストの最初の行は、次のようになります。
INVITE sip:+12145550102@198.51.100.3;sg=00:05:03:5e:70:a6 SIP/2.0
In order to provide support for privacy, the SSP SHOULD implement the temporary GRUU mechanism described in this section. Reasons for not doing so would include systems with an alternative privacy mechanism that maintains the integrity of public GRUUs (i.e., if public GRUUs are anonymized, then the anonymizer function would need to be capable of providing -- as the anonymized URI -- a globally routable URI that routes back only to the target identified by the original public GRUU).
プライバシーをサポートするために、SSPはこのセクションで説明する一時的なGruuメカニズムを実装する必要があります。そうしない理由には、パブリックグルーの整合性を維持する代替プライバシーメカニズムを備えたシステムが含まれます（つまり、パブリックグルーが匿名化されている場合、匿名の機能は匿名化されたURIとして、グローバルに提供する必要があります。元のPublic Gruuによって識別されたターゲットにのみ遡るルーティング可能なURI）。
Temporary GRUUs are used to provide anonymity for the party creating and sharing the GRUU. Being able to correlate two temporary GRUUs as having originated from behind the same SIP-PBX violates this principle of anonymity. Consequently, rather than relying upon a single, invariant identifier for the SIP-PBX in its UA's temporary GRUUs, we define a mechanism whereby the SSP provides the SIP-PBX with sufficient information for the SIP-PBX to mint unique temporary GRUUs. These GRUUs have the property that the SSP can correlate them to the proper SIP-PBX, but no other party can do so. To achieve this goal, we use a slight modification of the procedure described in Appendix A.2 of RFC 5627 [20].
一時的なグルーは、グルーを作成して共有するパーティーに匿名性を提供するために使用されます。同じSIP-PBXの背後から発生したため、2つの一時的なグルーを相関させることができることは、この匿名性の原則に違反します。したがって、UAの一時的なグルーのSIP-PBXの単一の不変識別子に依存するのではなく、SSPがSIP-PBXにSIP-PBXがユニークな一時グルーをミントするための十分な情報を提供するメカニズムを定義します。これらのグルーは、SSPが適切なSIP-PBXと相関させることができるという特性を持っていますが、他の当事者はそうすることはできません。この目標を達成するために、RFC 5627の付録A.2に記載されている手順のわずかな変更を使用します[20]。
The SIP-PBX needs to be able to construct a temp-gruu in a way that the SSP can decode. In order to ensure that the SSP can decode GRUUs, we need to standardize the algorithm for creation of temp-gruus at the SIP-PBX. This allows the SSP to reverse the algorithm in order to identify the registration entry that corresponds to the GRUU.
SIP-PBXは、SSPがデコードできる方法で温度を構築できる必要があります。SSPがGruusをデコードできるようにするために、SIP-PBXでTemp-gruusを作成するためのアルゴリズムを標準化する必要があります。これにより、SSPはアルゴリズムを逆転させて、Gruuに対応する登録エントリを識別できます。
It is equally important that no party other than the SSP be capable of decoding a temporary GRUU, including other SIP-PBXes serviced by the SSP. To achieve this property, an SSP that supports temporary GRUUs MUST create and store an asymmetric key pair: {K_e1,K_e2}. K_e1 is kept secret by the SSP, while K_e2 is shared with the SIP-PBXes via provisioning.
SSP以外のSSP以外の当事者が、SSPがサービスする他のSIP-PBXを含む一時的なGruuを解読することができないことも同様に重要です。このプロパティを実現するには、一時的なグルーをサポートするSSPは、非対称キーペアを作成および保存する必要があります：{k_e1、k_e2}。K_E1はSSPによって秘密にされ、K_E2はプロビジョニングを介してSIP-PBXEと共有されます。
All base64 encoding discussed in the following sections MUST use the character set and encoding defined in Section 4 of RFC 4648 [8], except that any trailing "=" characters are discarded on encoding and added as necessary to decode.
次のセクションで説明するすべてのBase64エンコードは、RFC 4648 [8]のセクション4で定義されている文字セットとエンコードを使用する必要があります。
The following sections make use of the term "HMAC-SHA256-80" to describe a particular Hashed Message Authentication Code (HMAC) algorithm. In this document, HMAC-SHA256-80 is defined as the application of the SHA-256 [24] secure hashing algorithm, truncating the results to 80 bits by discarding the trailing (least-significant) bits.
次のセクションでは、「HMAC-SHA256-80」という用語を使用して、特定のハッシュされたメッセージ認証コード（HMAC）アルゴリズムを記述します。このドキュメントでは、HMAC-SHA256-80は、SHA-256 [24]セキュアハッシュアルゴリズムの適用として定義され、トレーリング（最も重要な）ビットを破棄することにより結果を80ビットに切り捨てます。
An SSP that supports temporary GRUUs MUST include a "temp-gruu-cookie" parameter on all "Contact" header fields containing a "bnc" parameter in a 200-class REGISTER response. This "temp-gruu-cookie" MUST have the following properties:
一時的なグルーをサポートするSSPには、200クラスのレジスタ応答に「BNC」パラメーターを含むすべての「コンタクト」ヘッダーフィールドに「temp-gruu-cookie」パラメーターを含める必要があります。この「Temp-Gruu-Cookie」には、次の特性が必要です。
1. It can be used by the SSP to uniquely identify the registration to which it corresponds.
1. SSPがそれが対応する登録を一意に識別するために使用できます。
2. It is encoded using base64. This allows the SIP-PBX to decode it into as compact a form as possible for use in its calculations.
2. Base64を使用してエンコードされています。これにより、SIP-PBXは、計算で使用するために可能な限りコンパクトなフォームにデコードできます。
3. It is of a fixed length. This allows for its extraction once the SIP-PBX has concatenated a distinguisher onto it.
3. 固定された長さです。これにより、SIP-PBXが違いを連結した後、抽出が可能になります。
4. The temp-gruu-cookie MUST NOT be forgeable by any party. In other words, the SSP needs to be able to examine the cookie and validate that it was generated by the SSP.
4. Temp-Gruu-Cookieは、どんなパーティーでも忘れてはなりません。言い換えれば、SSPはCookieを調べ、SSPによって生成されたことを検証できる必要があります。
5. The temp-gruu-cookie MUST be invariant during the course of a registration, including any refreshes to that registration. This property is important, as it allows the SIP-PBX to examine the temp-gruu-cookie to determine whether the temp-gruus it has issued to its UAs are still valid.
5. Temp-Gruu-Cookieは、登録の過程で、その登録への更新を含む不変でなければなりません。SIP-PBXがTempgruu-Cookieを調べて、UASに発行した温度がまだ有効かどうかを判断できるため、このプロパティは重要です。
The above properties can be met using the following algorithm, which is non-normative. Implementors may chose to implement any algorithm of their choosing for generation of the temp-gruu-cookie, as long as it fulfills the five properties listed above.
上記のプロパティは、次のアルゴリズムを使用して満たすことができます。これは非規範的です。実装者は、上記の5つのプロパティを満たしている限り、Temp-Gruu-Cookieの生成のために選択のアルゴリズムを実装することを選択できます。
The registrar maintains a counter, I. This counter is 48 bits long and initialized to zero. This counter is persistently stored, using a back-end database or similar technique. When the registrar creates the first temporary GRUU for a particular SIP-PBX and instance ID (as defined by [20]), the registrar notes the current value of the counter, I_i, and increments the counter in the database. The registrar then maps I_i to the contact and instance ID using the database, a persistent hash-map, or similar technology. If the registration expires such that there are no longer any contacts with that particular instance ID bound to the GRUU, the registrar removes the mapping. Similarly, if the temporary GRUUs are invalidated due to a change in Call-ID, the registrar removes the current mapping from I_i to the AOR and instance ID, notes the current value of the counter I_j, and stores a mapping from I_j to the contact containing a "bnc" parameter and instance ID. Based on these rules, the hash-map will contain a single mapping for each contact containing a "bnc" parameter and instance ID for which there is a currently valid registration.
レジストラはカウンターを維持します。このカウンターは長さ48ビットで、初期化されています。このカウンターは、バックエンドデータベースまたは同様の手法を使用して、持続的に保存されています。レジストラが特定のSIP-PBXおよびインスタンスIDの最初の一時Gruuを作成すると（[20]で定義されている）、レジストラはカウンターの現在の値であるI_Iを指摘し、データベースのカウンターを増加させます。レジストラは、データベース、永続的なハッシュマップ、または同様のテクノロジーを使用して、I_Iを連絡先およびインスタンスIDにマッピングします。登録が期限切れになって、Gruuにバインドされた特定のインスタンスIDとの連絡先がなくなると、レジストラがマッピングを削除します。同様に、Call-IDの変更により一時のグルーが無効になっている場合、レジストラはi_iからAORおよびインスタンスIDへの現在のマッピングを削除し、カウンターI_Jの現在の値に注意し、i_Jからマッピングを連絡先に保存します「BNC」パラメーターとインスタンスIDを含む。これらのルールに基づいて、ハッシュマップには、現在有効な登録がある「BNC」パラメーターとインスタンスIDを含む各連絡先の単一のマッピングが含まれます。
The registrar maintains a symmetric key SK_a, which is regenerated every time the counter rolls over or is reset. When the counter rolls over or is reset, the registrar remembers the old value of SK_a for a while. To generate a temp-gruu-cookie, the registrar computes:
レジストラは、対称キーSK_Aを維持します。これは、カウンターがロールオーバーまたはリセットされるたびに再生されます。カウンターがロールオーバーまたはリセットされると、レジストラはしばらくの間SK_Aの古い値を覚えています。Temp-Gruu-Cookieを生成するには、レジストラが計算します。
SA = HMAC(SK_a, I_i)
temp-gruu-cookie = base64enc(I_i || SA)
where || denotes concatenation. "HMAC" represents any suitably strong HMAC algorithm; see RFC 2104 [1] for a discussion of HMAC algorithms. One suitable HMAC algorithm for this purpose is HMAC-SHA256-80.
ここで||連結を示します。「HMAC」は、適切に強力なHMACアルゴリズムを表しています。HMACアルゴリズムの議論については、RFC 2104 [1]を参照してください。この目的に適したHMACアルゴリズムの1つは、HMAC-SHA256-80です。
According to Section 3.2 of RFC 5627 [20], every registration refresh generates a new temp-gruu that is valid for as long as the contact remains registered. This property is both critical for the privacy properties of temp-gruu and is expected by UAs that implement the temp-gruu procedures. Nothing in this document should be construed as changing this fundamental temp-gruu property in any way. SIP-PBXes that implement temporary GRUUs MUST generate a new temp-gruu according to the procedures in this section for every registration or registration refresh from GRUU-supporting UAs attached to the SIP-PBX.
RFC 5627 [20]のセクション3.2によると、登録リフレッシュごとに、連絡先が登録されている限り有効な新しい温度が生成されます。このプロパティは、Temp-Gruuのプライバシープロパティにとって重要であり、Temp-Gruu手順を実装するUASによって予想されます。このドキュメントの何も、この基本的なTemp-Gruuプロパティを変更すると解釈されるべきではありません。一時的なGruusを実装するSIP-PBXEは、SIP-PBXに接続されたGruu-Supporting UASからの登録または登録のリフレッシュごとに、このセクションの手順に従って新しいTemp-Gruuを生成する必要があります。
Similarly, if the registration that a SIP-PBX has with its SSP expires or is terminated, then the temp-gruu cookie it maintains with the SSP will change. This change will invalidate all the temp-gruus the SIP-PBX has issued to its UAs. If the SIP-PBX tracks this information (e.g., to include <temp-gruu> elements in registration event bodies, as described in RFC 5628 [9]), it can determine that previously issued temp-gruus are invalid by observing a change in the temp-gruu-cookie provided to it by the SSP.
同様に、SIP-PBXがSSPを使用して登録されている登録が期限切れまたは終了した場合、SSPで維持されるTemp-Gruu Cookieが変更されます。この変更により、SIP-PBXがUASに発行したすべての温度が無効になります。SIP-PBXがこの情報を追跡している場合（例えば、RFC 5628 [9]に記載されている登録イベント機に<temp-gruu>要素を含めるため）、以前に発行されたTemp-gruusが変化を観察することにより無効であると判断できます。SSPから提供された温度gruu-cookie。
A SIP-PBX that issues temporary GRUUs to its UAs MUST maintain an HMAC key: PK_a. This value is used to validate that incoming GRUUs were generated by the SIP-PBX.
UASに一時的なグルーを発行するSIP-PBXは、HMACキーを維持する必要があります：PK_A。この値は、入ってくるグルーがSIP-PBXによって生成されたことを検証するために使用されます。
To generate a new temporary GRUU for use by its own UAs, the SIP-PBX MUST generate a random distinguisher value: D. The length of this value is up to implementors, but it MUST be long enough to prevent collisions among all the temporary GRUUs issued by the SIP-PBX. A size of 80 bits or longer is RECOMMENDED. See RFC 4086 [16] for further considerations on the generation of random numbers in a security context. After generating the distinguisher D, the SIP-PBX MUST calculate:
独自のUASが使用するための新しい一時的なグルーを生成するには、SIP-PBXはランダムな違いを生成する必要があります。D。SIP-PBXによって発行されました。80ビット以上のサイズが推奨されます。セキュリティコンテキストでの乱数の生成に関するさらなる考慮事項については、RFC 4086 [16]を参照してください。distinguisher Dを生成した後、SIP-PBXは次のことを計算する必要があります。
M = base64dec(SSP-cookie) || D
E = RSA-Encrypt(K_e2, M)
PA = HMAC(PK_a, E)
Temp-Gruu-userpart = "tgruu." || base64(E) || "." || base64(PA)
where || denotes concatenation. "HMAC" represents any suitably strong HMAC algorithm; see RFC 2104 [1] for a discussion of HMAC algorithms. One suitable HMAC algorithm for this purpose is HMAC-SHA256-80.
ここで||連結を示します。「HMAC」は、適切に強力なHMACアルゴリズムを表しています。HMACアルゴリズムの議論については、RFC 2104 [1]を参照してください。この目的に適したHMACアルゴリズムの1つは、HMAC-SHA256-80です。
Finally, the SIP-PBX adds a "gr" parameter to the temporary GRUU that can be used to uniquely identify the UA registration record to which the GRUU corresponds. The means of generation of the "gr" parameter are left to the implementor, as long as they satisfy the properties of a GRUU as described in RFC 5627 [20].
最後に、SIP-PBXは、Gruuが対応するUA登録レコードを一意に識別するために使用できる一時的なGruuに「GR」パラメーターを追加します。「GR」パラメーターの生成の手段は、RFC 5627 [20]に記載されているGruuの特性を満たす限り、実装者に任されます。
One valid approach for generation of the "gr" parameter is calculation of "E" and "A" as described in Appendix A.2 of RFC 5627 [20] and forming the "gr" parameter as:
「GR」パラメーターの生成に対する有効なアプローチの1つは、RFC 5627の付録A.2 [20]で説明されている「E」と「A」の計算であり、「GR」パラメーターを次のように形成します。
gr = base64enc(E) || base64enc(A)
Using this procedure may result in a temporary GRUU returned to the registering UA by the SIP-PBX that looks similar to this:
この手順を使用すると、SIP-PBXが登録UAに戻す一時的なGruuがこれに似ています。
<allOneLine>
Contact: <sip:line-1@10.20.1.17>
;temp-gruu="sip:tgruu.MQyaRiLEd78RtaWkcP7N8Q.5qVbsasdo2pkKw@
ssp.example.com;gr=YZGSCjKD42ccxO08pA7HwAM4XNDIlMSL0HlA"
;+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
;expires=3600
</allOneLine>
When the SSP proxy receives a request in which the user part begins with "tgruu.", it extracts the remaining portion and splits it at the "." character into E' and PA'. It discards PA'. It then computes E by performing a base64 decode of E'. Next, it computes:
SSPプロキシが「Tgruu」から始まるリクエストを受信すると、残りの部分を抽出し、「。」で分割します。e 'and Pa'へのキャラクター。それはpa 'を破棄します。次に、e 'のbase64デコードを実行してEを計算します。次に、それは計算します：
M = RSA-Decrypt(K_e1, E)
m = rsa-decrypt（k_e1、e）
The SSP proxy extracts the fixed-length temp-gruu-cookie information from the beginning of this M and discards the remainder (which will be the distinguisher added by the SIP-PBX). It then validates this temp-gruu-cookie. If valid, it uses it to locate the corresponding SIP-PBX registration record and routes the message appropriately.
SSPプロキシは、このMの最初から固定長の温度 - クッキー情報を抽出し、残りを破棄します（これはSIP-PBXによって追加された違いになります）。次に、このTemp-Gruu-Cookieを検証します。有効な場合、それを使用して対応するSIP-PBX登録レコードを見つけ、メッセージを適切にルーティングします。
If the non-normative, exemplary algorithm described in Section 7.1.2.1 is used to generate the temp-gruu-cookie, then this identification is performed by splitting the temp-gruu-cookie information into its 48-bit counter I and 80-bit HMAC. It validates that the HMAC matches the counter I and then uses counter I to locate the SIP-PBX registration record in its map. If the counter has rolled over or reset, this computation is performed with the current and previous SK_a.
セクション7.1.2.1で説明されている非規範的な例示的なアルゴリズムがTemp-gruu-Cookieを生成するために使用される場合、この識別は、Temp-Gruu-Cookie情報を48ビットカウンターIと80ビットに分割することによって実行されます。hmac。HMACがカウンターIと一致し、カウンターIを使用してマップ内のSIP-PBX登録レコードを見つけることを検証します。カウンターがロールオーバーまたはリセットされた場合、この計算は現在および以前のSK_Aで実行されます。
When the SIP-PBX receives a request in which the user part begins with "tgruu.", it extracts the remaining portion and splits it at the "." character into E' and PA'. It then computes E and PA by performing a base64 decode of E' and PA', respectively. Next, it computes:
SIP-PBXがユーザーパーツが「Tgruu」で始まるリクエストを受信すると、残りの部分を抽出し、「。」で分割します。e 'and Pa'へのキャラクター。次に、E 'とPA'のBase64デコードをそれぞれ実行してEとPAを計算します。次に、それは計算します：
PAc = HMAC(PK_a, E)
pac = hmac（pk_a、e）
where HMAC is the HMAC algorithm used for the steps in Section 7.1.2.2. If this computed value for PAc does not match the value of PA extracted from the GRUU, then the GRUU is rejected as invalid.
ここで、HMACはセクション7.1.2.2の手順に使用されるHMACアルゴリズムです。PACのこの計算値がGruuから抽出されたPAの値と一致しない場合、Gruuは無効として拒否されます。
The SIP-PBX then uses the value of the "gr" parameter to locate the UA registration to which the GRUU corresponds, and routes the message accordingly.
SIP-PBXは、「GR」パラメーターの値を使用して、GRUUが対応するUA登録を見つけ、それに応じてメッセージをルーティングします。
Neither the SSP nor the SIP-PBX is required to support the registration event package defined by RFC 3680 [12]. However, if they do support the registration event package, they MUST conform to the behavior described in this section and its subsections.
SSPもSIP-PBXも、RFC 3680 [12]で定義された登録イベントパッケージをサポートする必要はありません。ただし、登録イベントパッケージをサポートする場合、このセクションで説明されている動作とそのサブセクションに準拠する必要があります。
As this mechanism inherently deals with REGISTER transaction behavior, it is imperative to consider its impact on the registration event package defined by RFC 3680 [12]. In practice, there will be two main use cases for subscribing to registration data: learning about the overall registration state for the SIP-PBX and learning about the registration state for a single SIP-PBX AOR.
このメカニズムは本質的に登録トランザクションの動作を扱っているため、RFC 3680 [12]で定義された登録イベントパッケージへの影響を考慮することが不可欠です。実際には、登録データを購読するための2つの主要なユースケースがあります。SIP-PBXの全体的な登録状態について学び、単一のSIP-PBX AORの登録状態について学習します。
If the SIP-PBX (or another interested and authorized party) wishes to monitor or audit the registration state for all of the AORs currently registered to that SIP-PBX, it can subscribe to the SIP registration event package at the SIP-PBX's main URI -- that is, the URI used in the "To" header field of the REGISTER request.
SIP-PBX（または関心のある別の当事者）が、現在そのSIP-PBXに登録されているすべてのAORの登録状態を監視または監視または監査したい場合、SIP-PBXのメインURIのSIP登録イベントパッケージを購読できます - つまり、登録要求の「To」ヘッダーフィールドで使用されるURI。
The NOTIFY messages for such a subscription will contain a body that contains one record for each AOR associated with the SIP-PBX. The AORs will be in the format expected to be received by the SSP (e.g., "sip:+12145550105@ssp.example.com"), and the contacts will correspond to the mapped contact created by the registration (e.g., "sip:+12145550105@98.51.100.3").
このようなサブスクリプションのNotifyメッセージには、SIP-PBXに関連付けられた各AORに1つのレコードを含むボディが含まれます。AORは、SSPが受信すると予想される形式で（例： "sip：12145550105@ssp.example.com"）、連絡先は登録によって作成されたマッピングされた連絡先に対応します（例： "SIP：121455501055@98.51.100.3 "）。
In particular, the "bnc" parameter is forbidden from appearing in the body of a reg-event NOTIFY request unless the subscriber has indicated knowledge of the semantics of the "bnc" parameter. The means for indicating this support are out of scope of this document.
特に、サブスクライバーが「BNC」パラメーターのセマンティクスの知識を示していない限り、「BNC」パラメーターは、レグイベント通知要求の本文に表示されることを禁じられています。このサポートを示すための手段は、このドキュメントの範囲外です。
Because the SSP does not necessarily know which GRUUs have been issued by the SIP-PBX to its associated UAs, these records will not generally contain the <temp-gruu> or <pub-gruu> elements defined in RFC 5628 [9]. This information can be learned, if necessary, by subscribing to the individual AOR registration state, as described in Section 7.2.2.
SSPは、どのGruusが関連するUASに発行されたかを必ずしも知っているわけではないため、これらのレコードには通常、RFC 5628で定義された<Temp-Gruu>または<Pub-Gruu>要素が含まれていません[9]。セクション7.2.2で説明されているように、この情報は、必要に応じて、個々のAOR登録状態を購読することにより学ぶことができます。
As described in Section 6, the SSP will generally re-target all requests addressed to an AOR owned by a SIP-PBX to that SIP-PBX according to the mapping established at registration time. Although policy at the SSP may override this generally expected behavior, proper behavior of the registration event package requires that all
セクション6で説明されているように、SSPは通常、登録時に確立されたマッピングに従って、SIP-PBXが所有するAORに宛てられたすべての要求をそのSIP-PBXに再ターゲットします。SSPでのポリシーは、この一般的に予想される動作を無効にする可能性がありますが、登録イベントパッケージの適切な動作にはすべてが必要です
"reg" event SUBSCRIBE requests are processed by the SIP-PBX. As a consequence, the requirements on an SSP for processing registration event package SUBSCRIBE requests are not left to policy.
「REG」イベントサブスクライブリクエストは、SIP-PBXによって処理されます。結果として、登録イベントパッケージを処理するためのSSPの要件は、ポリシーに任されていません。
If the SSP receives a SUBSCRIBE request for the registration event package with a Request URI that indicates an AOR registered via the "Bulk Number Contact" mechanism defined in this document, then the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that it would proxy an INVITE bound for that AOR, unless the SSP has and can maintain a copy of complete, accurate, and up-to-date information from the SIP-PBX (e.g., through an active back-end subscription).
SSPが、このドキュメントで定義されている「バルク番号連絡先」メカニズムを介して登録されたAORを示すリクエストURIを使用して、登録イベントパッケージのサブスクライブリクエストを受信した場合、SSPはSIP-PBXを同じ方法で購読することをプロキシする必要があります。SSPがSIP-PBXからの完全で正確な、最新の情報のコピーを持っていて維持できない限り、そのaorに招待された招待をプロキシにすることを（例：アクティブなバックエンドサブスクリプションを介して）。
If the Request URI in a SUBSCRIBE request for the registration event package indicates a contact that is registered by more than one SIP-PBX, then the SSP proxy will fork the SUBSCRIBE request to all the applicable SIP-PBXes. Similarly, if the Request URI corresponds to a contact that is both implicitly registered by a SIP-PBX and explicitly registered directly with the SSP proxy, then the SSP proxy will semantically fork the SUBSCRIBE request to the applicable SIP-PBX or SIP-PBXes and to the registrar function (which will respond with registration data corresponding to the explicit registrations at the SSP). The forking in both of these cases can be avoided if the SSP has and can maintain a copy of up-to-date information from the PBXes.
登録イベントパッケージのサブスクライブリクエストのリクエストURIが、複数のSIP-PBXによって登録されている連絡先を示している場合、SSPプロキシは、該当するすべてのSIP-PBXEへの購読要求をフォークします。同様に、リクエストURIがSIP-PBXによって暗黙的に登録され、SSPプロキシに直接明示的に登録されている連絡先に対応する場合、SSPプロキシは、該当するSIP-PBXまたはSIP-PBXEおよびSIP-PBXEおよびSIP-PBXESおよびSSPプロキシを意味的にフォークします。レジストラ機能（SSPでの明示的な登録に対応する登録データに応答します）。これらの両方のケースのフォーキングは、SSPがPBXESから最新情報のコピーを持っている場合と維持できる場合、回避できます。
Section 4.9 of RFC 3680 [12] indicates that "a subscriber MUST NOT create multiple dialogs as a result of a single [registration event] subscription request". Consequently, subscribers who are not aware of the extension described by this document will accept only one dialog in response to such requests. In the case described in the preceding paragraph, this behavior will result in such clients receiving accurate but incomplete information about the registration state of an AOR. As an explicit change to the normative behavior of RFC 3680, this document stipulates that subscribers to the registration event package MAY create multiple dialogs as the result of a single subscription request. This will allow subscribers to create a complete view of an AOR's registration state.
RFC 3680 [12]のセクション4.9は、「サブスクライバーは、単一の[登録イベント]サブスクリプションリクエストの結果として複数のダイアログを作成してはならない」ことを示しています。したがって、このドキュメントで説明されている拡張機能を認識していない購読者は、そのような要求に応じて1つのダイアログのみを受け入れます。前の段落で説明されている場合、この動作により、そのようなクライアントは、AORの登録状態に関する正確ではあるが不完全な情報を受け取るようになります。RFC 3680の規範的な動作を明示的に変更すると、このドキュメントは、登録イベントパッケージのサブスクライバーが単一のサブスクリプションリクエストの結果として複数のダイアログを作成する可能性があることを規定しています。これにより、加入者はAORの登録状態の完全なビューを作成することができます。
Defining the behavior as described above is important, since the reg-event subscriber is interested in finding out about the comprehensive list of devices associated with the AOR. Only the SIP-PBX will have authoritative access to this information. For example, if the user has registered multiple UAs with differing capabilities, the SSP will not know about the devices or their capabilities. By contrast, the SIP-PBX will.
上記のように動作を定義することは重要です。なぜなら、登録イベントサブスクライバーはAORに関連付けられているデバイスの包括的なリストについて知ることに興味があるからです。SIP-PBXのみがこの情報に権威あるアクセスを行います。たとえば、ユーザーが異なる機能を備えた複数のUAを登録している場合、SSPはデバイスまたはその機能について知りません。対照的に、SIP-PBXはそうします。
If the SIP-PBX is not registered with the SSP when a registration event subscription for a contact that would be implicitly registered if the SIP-PBX were registered is received, then the SSP SHOULD accept the subscription and indicate that the user is not currently registered. Once the associated SIP-PBX is registered, the SSP SHOULD use the subscription migration mechanism defined in RFC 3265 [5] to migrate the subscription to the SIP-PBX.
SIP-PBXが登録された場合に暗黙的に登録される連絡先の登録イベントサブスクリプションの場合、SIP-PBXがSSPに登録されていない場合、SSPはサブスクリプションを受け入れ、ユーザーが現在登録されていないことを示す必要があります。関連するSIP-PBXが登録されると、SSPはRFC 3265 [5]で定義されたサブスクリプション移行メカニズムを使用して、SIP-PBXのサブスクリプションを移行する必要があります。
When a SIP-PBX receives a registration event subscription addressed to an AOR that has been registered using the bulk registration mechanism described in this document, then each resulting registration information document SHOULD contain an 'aor' attribute in its <registration/> element that corresponds to the AOR at the SSP.
SIP-PBXがこのドキュメントで説明されているバルク登録メカニズムを使用して登録されているAORに登録された登録イベントサブスクリプションを受信した場合、結果の各登録情報ドキュメントは、対応する<登録/>要素の「AOR」属性を含める必要があります。SSPのAORに。
For example, consider a SIP-PBX that has registered with an SSP that has a domain of "ssp.example.com". The SIP-PBX used a Contact URI of "sip:198.51.100.3:5060;bnc". After such registration is complete, a registration event subscription arriving at the SSP with a Request URI of "sip:+12145550102@ssp.example.com" will be re-targeted to the SIP-PBX, with a Request URI of "sip:+12145550102@198.51.100.3:5060". The resulting registration document created by the SIP-PBX would contain a <registration/> element with an "aor" attribute of "sip:+12145550102@ssp.example.com".
たとえば、「ssp.example.com」のドメインを持つSSPに登録されているSIP-PBXを検討してください。SIP-PBXは、「SIP：198.51.100.3：5060; BNC」の連絡先URIを使用しました。そのような登録が完了した後、「sip：12145550102@ssp.example.com」のリクエストでSSPに登録イベントサブスクリプションがsip-pbxに再ターゲットされ、「sip：121455501022のリクエストがあります。@198.51.100.3：5060 "。SIP-PBXによって作成された結果の登録文書には、「sip：12145550102@ssp.example.com」の「aor」属性を持つ<登録/>要素が含まれます。
This behavior ensures that subscribers external to the system (and unaware of GIN (generate implicit numbers) procedures) will be able to find the relevant information in the registration document (since they will be looking for the publicly visible AOR, not the address used for sending information from the SSP to the SIP-PBX).
この動作により、システムの外部のサブスクライバー（およびGIN（暗黙の数字を生成する）手順を認識していない）が、登録文書で関連情報を見つけることができるようになります（公開されているAORを探しているため、使用される住所ではなく、公開されているAORを探しているためSSPからSIP-PBXに情報を送信します）。
A SIP-PBX that supports both GRUU procedures and the registration event packages SHOULD implement the extension defined in RFC 5628 [9].
GRUU手順と登録イベントパッケージの両方をサポートするSIP-PBXは、RFC 5628で定義された拡張機能を実装する必要があります[9]。
RFC 5626 [19] defines a mechanism that allows UAs to establish long-lived TCP connections or UDP associations with a proxy in a way that allows bidirectional traffic between the proxy and the UA. This behavior is particularly important in the presence of NATs, and whenever TLS [18] security is required. Neither the SSP nor the SIP-PBX is required to support client-initiated connections.
RFC 5626 [19]は、UASがプロキシとUAの間の双方向トラフィックを可能にする方法で、UASがプロキシと長寿命のTCP接続またはUDP関連を確立できるようにするメカニズムを定義します。この動作は、NATの存在下で特に重要であり、TLS [18]セキュリティが必要なときはいつでも重要です。SSPもSIP-PBXも、クライアントが開始した接続をサポートする必要はありません。
Generally, the outbound mechanism works with the solution defined in this document, without any modifications. Implementors should note that the instance ID used between the SIP-PBX and the SSP's registrar identifies the SIP-PBX itself, and not any of the UAs registered with the SIP-PBX. As a consequence, any attempts to use caller preferences (defined in RFC 3841 [14]) to target a specific instance are likely to fail. This shouldn't be an issue, as the preferred mechanism for targeting specific instances of a user agent is GRUU (see Section 7.1).
一般に、アウトバウンドメカニズムは、変更なしに、このドキュメントで定義されているソリューションで動作します。実装者は、SIP-PBXとSSPのレジストラの間で使用されるインスタンスIDは、SIP-PBX自体を識別し、SIP-PBXに登録されているUASのいずれではないことに注意する必要があります。結果として、特定のインスタンスをターゲットにするために発信者の設定（RFC 3841 [14]で定義されている）を使用しようとする試みは失敗する可能性があります。ユーザーエージェントの特定のインスタンスをターゲットにするための好ましいメカニズムはGRUUであるため、これは問題ではないはずです（セクション7.1を参照）。
RFC 3327 [10] defines a means by which a registrar and its associated proxy can be informed of a route that is to be used between the proxy and the registered user agent. The scope of the route created by a "Path" header field is contact specific; if an AOR has multiple contacts associated with it, the routes associated with each contact may be different from each other. Support for non-adjacent contact registration is required in all SSPs and SIP-PBXes implementing the multiple-AOR-registration protocol described in this document.
RFC 3327 [10]は、レジストラとそれに関連するプロキシに、プロキシと登録ユーザーエージェントの間で使用されるルートを通知できる手段を定義します。「パス」ヘッダーフィールドによって作成されたルートの範囲は、接触固有です。AORにそれに関連する複数の接点がある場合、各接触に関連付けられたルートは互いに異なる場合があります。このドキュメントで説明されている多AOR登録プロトコルを実装するすべてのSSPおよびSIP-PBXEで、非隣接接触登録のサポートが必要です。
At registration time, any proxies between the user agent and the registrar may add themselves to the "Path" header field. By doing so, they request that any requests destined to the user agent as a result of the associated registration include them as part of the Route towards the user agent. Although the path mechanism does deliver the final path value to the registering UA, UAs typically ignore the value of the path.
登録時に、ユーザーエージェントとレジストラ間のプロキシは、「パス」ヘッダーフィールドに追加する場合があります。そうすることで、彼らは、関連する登録の結果としてユーザーエージェントに運命づけられているリクエストには、ユーザーエージェントへのルートの一部としてそれらを含めることを要求します。パスメカニズムは登録UAに最終パス値を提供しますが、UAは通常、パスの値を無視します。
To provide similar functionality in the opposite direction -- that is, to establish a route for requests sent by a registering UA -- RFC 3608 [11] defines a means by which a UA can be informed of a route that is to be used by the UA to route all outbound requests associated with the AOR used in the registration. This information is scoped to the AOR within the UA, and is not specific to the contact (or contacts) in the REGISTER request. Support of service route discovery is OPTIONAL in SSPs and SIP-PBXes.
同様の機能を反対方向に提供すること、つまり、登録UAによって送信されたリクエストのルートを確立するために、RFC 3608 [11]は、UAに使用されるルートを通知できる手段を定義します。登録で使用されているAORに関連付けられたすべてのアウトバウンドリクエストをルーティングするUA。この情報は、UA内のAORにスコープされており、レジスタリクエストの連絡先（または連絡先）に固有のものではありません。SSPSおよびSIP-PBXESでは、サービスルート発見のサポートはオプションです。
The registrar unilaterally generates the values of the service route using whatever local policy it wishes to apply. Although it is common to use the "Path" and/or "Route" header field information in the request in composing the service route, registrar behavior is not constrained in any way that requires it to do so.
レジストラは、適用したいローカルポリシーを使用して、サービスルートの値を一方的に生成します。サービスルートを作成する際にリクエストで「パス」および/または「ルート」ヘッダーフィールド情報を使用することは一般的ですが、レジストラの動作は、そうする必要がある方法で制約されません。
In considering the interaction between these mechanisms and the registration of multiple AORs in a single request, implementors of proxies, registrars, and intermediaries must keep in mind the following issues, which stem from the fact that GIN effectively registers multiple AORs and multiple contacts.
これらのメカニズム間の相互作用と単一の要求での複数のAORの登録を考慮する際に、プロキシ、レジストラ、および仲介者の実装者は、GINが複数のAORと複数の連絡先を効果的に登録するという事実に起因する次の問題に留意する必要があります。
First, all location service records that result from expanding a single Contact URI containing a "bnc" parameter will necessarily share a single path. Proxies will be unable to make policy decisions on a contact-by-contact basis regarding whether to include themselves in the path. Second, and similarly, all AORs on the SIP-PBX that are registered with a common REGISTER request will be forced to share a common service route.
まず、「BNC」パラメーターを含む単一の連絡先URIを拡張したことから生じるすべてのロケーションサービスレコードは、必然的に単一のパスを共有します。プロキシは、パスに自分自身を含めるかどうかに関して、接触ごとの接触ベースでポリシー決定を行うことができません。第二に、同様に、共通のレジスタリクエストに登録されているSIP-PBX上のすべてのAORは、共通のサービスルートを共有することを余儀なくされます。
One interesting technique that the path and service route mechanisms enable is the inclusion of a token or cookie in the user portion of the service route or path entries. This token or cookie may convey information to proxies about the identity, capabilities, and/or policies associated with the user. Since this information will be shared among several AORs and several contacts when multiple AOR registration is employed, care should be taken to ensure that doing so is acceptable for all AORs and all contacts registered in a single REGISTER request.
パスおよびサービスルートメカニズムが有効にするという興味深い手法の1つは、サービスルートまたはパスエントリのユーザー部分にトークンまたはCookieを含めることです。このトークンまたはCookieは、ユーザーに関連するアイデンティティ、機能、および/またはポリシーに関する情報をプロキシに伝える場合があります。この情報は、複数のAOR登録が採用されている場合、いくつかのAORといくつかの連絡先で共有されるため、1つのレジスタリクエストに登録されているすべてのAORとすべての連絡先に受け入れられるように注意する必要があります。
Note that the following examples elide any steps related to authentication. This is done for the sake of clarity. Actual deployments will need to provide a level of authentication appropriate to their system.
次の例は、認証に関連する手順を削除することに注意してください。これは明確にするために行われます。実際の展開は、システムに適したレベルの認証を提供する必要があります。
This example shows the message flows for a basic bulk REGISTER transaction, followed by an INVITE addressed to one of the registered UAs. Example messages are shown after the sequence diagram.
この例は、基本的なバルクレジスタトランザクションのメッセージフローを示し、その後、登録されたUASの1つに招待された招待状が続きます。例のメッセージは、シーケンス図の後に表示されます。
Internet SSP SIP-PBX
| | |
| |(1) REGISTER |
| |Contact:<sip:198.51.100.3;bnc> |
| |<--------------------------------|
| | |
| |(2) 200 OK |
| |-------------------------------->|
| | |
|(3) INVITE | |
|sip:+12145550105@ssp.example.com| |
|------------------------------->| |
| | |
| |(4) INVITE |
| |sip:+12145550105@198.51.100.3 |
| |-------------------------------->|
(1) The SIP-PBX registers with the SSP for a range of AORs.
REGISTER sip:ssp.example.com SIP/2.0
Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: <sip:pbx@ssp.example.com>
From: <sip:pbx@ssp.example.com>;tag=a23589
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Proxy-Require: gin
Require: gin
Supported: path
Contact: <sip:198.51.100.3:5060;bnc>
Expires: 7200
Content-Length: 0
(3) The SSP receives a request for an AOR assigned to the SIP-PBX.
(3) SSPは、SIP-PBXに割り当てられたAORのリクエストを受け取ります。
INVITE sip:+12145550105@ssp.example.com SIP/2.0
Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
Max-Forwards: 69
To: <sip:2145550105@some-other-place.example.net>
From: <sip:gsmith@example.org>;tag=456248
Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
CSeq: 24762 INVITE
Contact: <sip:line-1@192.0.2.178:2081>
Content-Type: application/sdp
Content-Length: ...
<sdp body here> (4) The SSP re-targets the incoming request according to the information received from the SIP-PBX at registration time.
<sdp body here>（4）SSPは、登録時にSIP-PBXから受け取った情報に従って、着信要求を再ターゲットします。
INVITE sip:+12145550105@198.51.100.3 SIP/2.0
Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
Max-Forwards: 68
To: <sip:2145550105@some-other-place.example.net>
From: <sip:gsmith@example.org>;tag=456248
Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
CSeq: 24762 INVITE
Contact: <sip:line-1@192.0.2.178:2081>
Content-Type: application/sdp
Content-Length: ...
<sdp body here>
<SDPボディはこちら>
This example shows a bulk REGISTER transaction with the SSP making use of the "Path" header field extension [10]. This allows the SSP to designate a domain on the incoming Request URI that does not necessarily resolve to the SIP-PBX when the SSP applies RFC 3263 procedures to it.
この例は、「パス」ヘッダーフィールド拡張[10]を使用して、SSPとのバルクレジスタトランザクションを示しています。これにより、SSPは、SSPがRFC 3263手順を適用した場合、必ずしもSIP-PBXに解決するとは限らない、着信要求URIのドメインを指定できます。
Internet SSP SIP-PBX
| | |
| |(1) REGISTER |
| |Path:<sip:pbx@198.51.100.3;lr> |
| |Contact:<sip:pbx.example;bnc> |
| |<--------------------------------|
| | |
| |(2) 200 OK |
| |-------------------------------->|
| | |
|(3) INVITE | |
|sip:+12145550105@ssp.example.com| |
|------------------------------->| |
| | |
| |(4) INVITE |
| |sip:+12145550105@pbx.example |
| |Route:<sip:pbx@198.51.100.3;lr> |
| |-------------------------------->|
(1) The SIP-PBX registers with the SSP for a range of AORs.
It includes the form of the URI it expects to receive in the
Request URI in its "Contact" header field, and it includes
information that routes to the SIP-PBX in the "Path" header
field.
REGISTER sip:ssp.example.com SIP/2.0
Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: <sip:pbx@ssp.example.com>
From: <sip:pbx@ssp.example.com>;tag=a23589
Call-ID: 326983936836068@998sdasdh09
CSeq: 1826 REGISTER
Proxy-Require: gin
Require: gin
Supported: path
Path: <sip:pbx@198.51.100.3:5060;lr>
Contact: <sip:pbx.example;bnc>
Expires: 7200
Content-Length: 0
(3) The SSP receives a request for an AOR assigned to the SIP-PBX.
(3) SSPは、SIP-PBXに割り当てられたAORのリクエストを受け取ります。
INVITE sip:+12145550105@ssp.example.com SIP/2.0
Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
Max-Forwards: 69
To: <sip:2145550105@some-other-place.example.net>
From: <sip:gsmith@example.org>;tag=456248
Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
CSeq: 24762 INVITE
Contact: <sip:line-1@192.0.2.178:2081>
Content-Type: application/sdp
Content-Length: ...
<sdp body here> (4) The SSP re-targets the incoming request according to the information received from the SIP-PBX at registration time. Per the normal processing associated with "Path", it will insert the "Path" value indicated by the SIP-PBX at registration time in a "Route" header field, and set the Request URI to the registered contact.
<sdp body here>（4）SSPは、登録時にSIP-PBXから受け取った情報に従って、着信要求を再ターゲットします。「パス」に関連付けられた通常の処理に従って、登録時に「ルート」ヘッダーフィールドでSIP-PBXによって示される「パス」値を挿入し、リクエストを登録された連絡先にリクエストを設定します。
INVITE sip:+12145550105@pbx.example SIP/2.0
Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
Route: <sip:pbx@198.51.100.3:5060;lr>
Max-Forwards: 68
To: <sip:2145550105@some-other-place.example.net>
From: <sip:gsmith@example.org>;tag=456248
Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
CSeq: 24762 INVITE
Contact: <sip:line-1@192.0.2.178:2081>
Content-Type: application/sdp
Content-Length: ...
<sdp body here>
<SDPボディはこちら>
This document registers a new SIP option tag to indicate support for the mechanism it defines, two new SIP URI parameters, and a "Contact" header field parameter. The process governing registration of these protocol elements is outlined in RFC 5727 [21].
このドキュメントは、定義するメカニズムのサポート、2つの新しいSIP URIパラメーター、および「コンタクト」ヘッダーフィールドパラメーターを示すために、新しいSIPオプションタグを登録します。これらのプロトコル要素の登録を管理するプロセスは、RFC 5727 [21]で概説されています。
This section defines a new SIP option tag per the guidelines in Section 27.1 of RFC 3261 [3].
このセクションでは、RFC 3261 [3]のセクション27.1のガイドラインに従って新しいSIPオプションタグを定義します。
Name: gin
名前：ジン
Description: This option tag is used to identify the extension that provides registration for Multiple Phone Numbers in SIP. When present in a "Require" or "Proxy-Require" header field of a REGISTER request, it indicates that support for this extension is required of registrars and proxies, respectively, that are a party to the registration transaction.
説明：このオプションタグは、SIPで複数の電話番号の登録を提供する拡張機能を識別するために使用されます。レジスタリクエストの「要求」または「プロキシリクイア」ヘッダーフィールドに存在する場合、登録取引の当事者であるレジストラとプロキシのサポートがそれぞれ必要であることを示します。
Reference: RFC 6140
参照：RFC 6140
This specification defines two new SIP URI parameters, as per the registry created by RFC 3969 [7].
この仕様では、RFC 3969 [7]によって作成されたレジストリに従って、2つの新しいSIP URIパラメーターを定義します。
Parameter Name: bnc
パラメーター名：BNC
Predefined Values: No (no values are allowed)
事前定義された値：いいえ（値は許可されていません）
Reference: RFC 6140
参照：RFC 6140
Parameter Name: sg
パラメーター名：SG
Predefined Values: No
事前定義された値：いいえ
Reference: RFC 6140
参照：RFC 6140
This section defines a new SIP header field parameter per the registry created by RFC 3968 [6].
このセクションでは、RFC 3968 [6]によって作成されたレジストリごとの新しいSIPヘッダーフィールドパラメーターを定義します。
Header field: Contact
ヘッダーフィールド：連絡先
Parameter name: temp-gruu-cookie
パラメーター名：Temp-Gruu-Cookie
Predefined values: No
事前定義された値：いいえ
Reference: RFC 6140
参照：RFC 6140
The change proposed for the mechanism described in this document takes the unprecedented step of extending the previously defined REGISTER method to apply to more than one AOR. In general, this kind of change has the potential to cause problems at intermediaries -- such as proxies -- that are party to the REGISTER transaction. In particular, such intermediaries may attempt to apply policy to the user indicated in the "To" header field (i.e., the SIP-PBX's identity), without any knowledge of the multiple AORs that are being implicitly registered.
このドキュメントで説明されているメカニズムについて提案された変更は、以前に定義されたレジスタメソッドを複数のAORに適用するために拡張するという前例のないステップを採用します。一般に、この種の変化は、登録取引の当事者である仲介者（プロキシなどの仲介者に問題を引き起こす可能性があります。特に、そのような仲介業者は、暗黙的に登録されている複数のAORの知識なしに、「To」ヘッダーフィールド（つまり、SIP-PBXのID）に示されているユーザーにポリシーを適用しようとする場合があります。
The mechanism defined by this document solves this issue by adding an option tag to a "Proxy-Require" header field in such REGISTER requests. Proxies that are unaware of this mechanism will not process the requests, preventing them from misapplying policy. Proxies that process requests with this option tag are clearly aware of the nature of the REGISTER request and can make reasonable policy decisions.
このドキュメントで定義されたメカニズムは、このようなレジスタリクエストで「プロキシリクイア」ヘッダーフィールドにオプションタグを追加することにより、この問題を解決します。このメカニズムに気付いていないプロキシは、要求を処理せず、ポリシーを誤用することを妨げます。このオプションタグを使用してプロセスリクエストのプロキシは、レジスタリクエストの性質を明確に認識しており、合理的なポリシー決定を行うことができます。
As noted in Section 7.4, intermediaries need to take care if they use a policy token in the path and service route mechanisms, as doing so will cause them to apply the same policy to all users serviced by the same SIP-PBX. This may frequently be the correct behavior, but circumstances can arise in which differentiation of user policy is required.
セクション7.4で述べたように、仲介者は、パスおよびサービスルートメカニズムでポリシートークンを使用する場合に注意する必要があります。これはしばしば正しい動作である可能性がありますが、ユーザーポリシーの差別化が必要な状況が発生する可能性があります。
Section 7.4 also notes that these techniques use a token or cookie in the "Path" and/or "Service-Route" header values, and that this value will be shared among all AORs associated with a single registration. Because this information will be visible to user agents under certain conditions, proxy designers using this mechanism in conjunction with the techniques described in this document need to take care that doing so does not leak sensitive information.
セクション7.4は、これらの手法では「パス」および/または「サービスルート」ヘッダー値でトークンまたはCookieを使用し、この値は単一の登録に関連付けられたすべてのAOR間で共有されることを示しています。この情報は特定の条件下でユーザーエージェントに表示されるため、このドキュメントで説明されている手法と組み合わせてこのメカニズムを使用するプロキシ設計者は、そうすることで機密情報が漏れないことに注意する必要があります。
One of the key properties of the outbound client connection mechanism discussed in Section 7.3 is the assurance that a single connection is associated with a single user and cannot be hijacked by other users. With the mechanism defined in this document, such connections necessarily become shared between users. However, the only entity in a position to hijack calls as a consequence is the SIP-PBX itself. Because the SIP-PBX acts as a registrar for all the potentially affected users, it already has the ability to redirect any such communications as it sees fit. In other words, the SIP-PBX must be trusted to handle calls in an appropriate fashion, and the use of the outbound connection mechanism introduces no additional vulnerabilities.
セクション7.3で説明したアウトバウンドクライアント接続メカニズムの重要なプロパティの1つは、単一の接続が単一のユーザーに関連付けられ、他のユーザーがハイジャックできないという保証です。このドキュメントで定義されているメカニズムにより、そのような接続は必然的にユーザー間で共有されます。ただし、結果として呼び出しをハイジャックする立場にある唯一のエンティティは、SIP-PBX自体です。SIP-PBXは、潜在的に影響を受けるすべてのユーザーのレジストラとして機能するため、適切と思われる通信をリダイレクトする能力がすでにあります。言い換えれば、SIP-PBXは適切な方法でコールを処理するために信頼される必要があり、アウトバウンド接続メカニズムの使用は追加の脆弱性を導入しません。
The ability to learn the identity and registration state of every user on the PBX (as described in Section 7.2.1) is invaluable for diagnostic and administrative purposes. For example, this allows the SIP-PBX to determine whether all its extensions are properly registered with the SSP. However, this information can also be highly sensitive, as many organizations may not wish to make their entire list of phone numbers available to external entities. Consequently, SSP servers are advised to use explicit (i.e., white-list) and configurable policies regarding who can access this information, with very conservative defaults (e.g., an empty access list or an access list consisting only of the PBX itself).
PBX上のすべてのユーザーの身元と登録状態を学習する機能（セクション7.2.1で説明）は、診断および管理目的で非常に貴重です。たとえば、これにより、SIP-PBXはすべての拡張機能がSSPに適切に登録されているかどうかを判断できます。ただし、多くの組織が電話番号のリスト全体を外部エンティティで利用できるようにすることを望んでいない場合があるため、この情報も非常に敏感です。その結果、SSPサーバーは、この情報にアクセスできる人に関する明示的な（つまり、ホワイトリスト）と構成可能なポリシーを使用することをお勧めします。
The procedure for the generation of temporary GRUUs requires the use of an HMAC to detect any tampering that external entities may attempt to perform on the contents of a temporary GRUU. The mention of HMAC-SHA256-80 in Section 7.1.2 is intended solely as an example of a suitable HMAC algorithm. Since all HMACs used in this document are generated and consumed by the same entity, the choice of an actual HMAC algorithm is entirely up to an implementation, provided that the cryptographic properties are sufficient to prevent third parties from spoofing GRUU-related information.
一時的なグルーの生成の手順では、HMACを使用して、外部エンティティが一時的なグルーの内容で実行しようとする改ざんを検出する必要があります。セクション7.1.2のHMAC-SHA256-80の言及は、適切なHMACアルゴリズムの例としてのみ意図されています。このドキュメントで使用されるすべてのHMACは同じエンティティによって生成および消費されているため、実際のHMACアルゴリズムの選択は、暗号化特性がグルー関連の情報をスプーフィングするのを防ぐのに十分な場合、実装に完全に依存しています。
The procedure for the generation of temporary GRUUs also requires the use of RSA keys. The selection of the proper key length for such keys requires careful analysis, taking into consideration the current and foreseeable speed of processing for the period of time during which GRUUs must remain anonymous, as well as emerging cryptographic analysis methods. The most recent guidance from RSA Laboratories [25] suggests a key length of 2048 bits for data that needs protection through the year 2030, and a length of 3072 bits thereafter.
一時的なグルーの生成の手順には、RSAキーの使用も必要です。このようなキーの適切なキー長を選択するには、Gruusが匿名のままでなければならない期間、および新たな暗号化分析方法の期間の現在および予見可能な処理速度を考慮して、慎重に分析する必要があります。RSA Laboratories [25]からの最新のガイダンスは、2030年を通じて保護が必要なデータの主要な長さ2048ビットと、その後3072ビットの長さを示唆しています。
Similarly, implementors are warned to take precautionary measures to prevent unauthorized disclosure of the private key used in GRUU generation. Any such disclosure would result in the ability to correlate temporary GRUUs to each other and, potentially, to their associated PBXes.
同様に、実装者は、Gruu世代で使用される秘密鍵の不正開示を防ぐために予防措置を講じることを警告されています。このような開示は、一時的なグルーを互いに、潜在的に関連するPBXEと相関させる能力をもたらします。
Further, the use of RSA decryption when processing GRUUs received from arbitrary parties can be exploited by Denial-of-Service (DoS) attackers to amplify the impact of an attack: because of the presence of a cryptographic operation in the processing of such messages, the CPU load may be marginally higher when the attacker uses (valid or invalid) temporary GRUUs in the messages employed by such an attack. Normal DoS mitigation techniques, such as rate-limiting processing of received messages, should help to reduce the impact of this issue as well.
さらに、任意の当事者から受け取ったgruusを処理する際のRSA復号化の使用は、攻撃の影響を増幅するために、サービス拒否（DOS）攻撃者によって悪用される可能性があります。そのようなメッセージの処理における暗号化操作の存在のため、攻撃者がそのような攻撃で採用されているメッセージで一時的なグルーを使用する（有効または無効な）場合、CPU負荷はわずかに高くなる場合があります。受信したメッセージのレート制限処理などの通常のDOS緩和手法は、この問題の影響を減らすのにも役立つはずです。
Finally, good security practices should be followed regarding the duration an RSA key is used. For implementors, this means that systems MUST include an easy way to update the public key provided to the SIP-PBX. To avoid immediately invalidating all currently issued temporary GRUUs, the SSP servers SHOULD keep the retired RSA key around for a grace period before discarding it. If decryption fails based on the new RSA key, then the SSP server can attempt to use the retired key instead. By contrast, the SIP-PBXes MUST discard the retired public key immediately and exclusively use the new public key.
最後に、RSAキーが使用される期間に関して、適切なセキュリティプラクティスに従う必要があります。実装者の場合、これはシステムがSIP-PBXに提供された公開キーを簡単に更新する簡単な方法を含める必要があることを意味します。現在発行されているすべての一時的なGruusをすぐに無効にするために、SSPサーバーは、廃棄する前に格差の期間、退職したRSAキーを維持する必要があります。新しいRSAキーに基づいて復号化が失敗した場合、SSPサーバーは代わりに廃止されたキーの使用を試みることができます。対照的に、SIP-PBXEは退職した公開キーを直ちに廃棄し、新しい公開キーを独占的に使用する必要があります。
This document represents the hard work of many people in the IETF MARTINI working group and the IETF RAI community as a whole. Particular thanks are owed to John Elwell for his requirements analysis of the mechanism described in this document, to Dean Willis for his analysis of the interaction between this mechanism and the "Path" and "Service-Route" extensions, to Cullen Jennings for his analysis of the interaction between this mechanism and the SIP Outbound extension, and to Richard Barnes for his detailed security analysis of the GRUU construction algorithm. Thanks to Eric Rescorla, whose text in the appendix of RFC 5627 was lifted directly to provide substantial portions of Section 7.1.2. Finally, thanks to Bernard Aboba, Francois Audet, Brian Carpenter, John Elwell, David Hancock, Ted Hardie, Martien Huysmans, Cullen Jennings, Alan Johnston, Hadriel Kaplan, Paul Kyzivat, and Radia Perlman for their careful reviews of and constructive feedback on this document.
このドキュメントは、IETF MartiniワーキンググループとIETF RAIコミュニティ全体の多くの人々の努力を表しています。このドキュメントに記載されているメカニズムの要件分析について、ジョン・エルウェル、このメカニズムと「パス」と「サービスルート」拡張機能との相互作用の分析について、ディーン・ウィリスに特に感謝しています。このメカニズムとSIPアウトバウンド拡張の間の相互作用、およびGruu構造アルゴリズムの詳細なセキュリティ分析のためのRichard Barnesとの相互作用の。Eric Rescorlaのおかげで、RFC 5627の付録のテキストが直接解除され、セクション7.1.2のかなりの部分を提供しました。最後に、バーナード・アボバ、フランソワ・オーデット、ブライアン・カーペンター、ジョン・エルウェル、デビッド・ハンコック、テッド・ハーディー、マルティエン・ホイスマン、カレン・ジェニングス、アラン・ジョンストン、ハドリエル・カプラン、ポール・キジバット、ラディア・ペルマンのおかげで資料。
[1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[1] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキードハッシング」、RFC 2104、1997年2月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INITIATION Protocol」、RFC 3261、2002年6月。
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[4] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）：SIPサーバーの位置」、RFC 3263、2002年6月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[6] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[6] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）のための数字権機関（IANA）ヘッダーフィールドパラメーターレジストリ」、BCP 98、RFC 3968、2004年12月。
[7] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[7] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）のための数字の権限（IANA）ユニフォームリソース識別子（URI）パラメーターレジストリ」、BCP 99、RFC 3969、2004年12月。
[8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[8] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[9] Kyzivat, P., "Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)", RFC 5628, October 2009.
[9] Kyzivat、P。、「セッション開始プロトコル（SIP）グローバルにルータブルユーザーエージェントURIS（Gruus）の登録イベントパッケージ拡張機能」、RFC 5628、2009年10月。
[10] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[10] Willis、D。およびB. Hoeneisen、「非隣接接点を登録するためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド」、RFC 3327、2002年12月。
[11] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003.
[11] Willis、D。およびB. Hoeneisen、「登録中のサービスルート発見のためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド」、RFC 3608、2003年10月。
[12] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[12] Rosenberg、J。、「登録のためのセッション開始プロトコル（SIP）イベントパッケージ」、RFC 3680、2004年3月。
[13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[13] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[14] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[14] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）に対する発信者の好み」、RFC 3841、2004年8月。
[15] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[15] Schulzrinne、H。、「電話番号のためのTel URI」、RFC 3966、2004年12月。
[16] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[16] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[17] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[17] Sparks、R.、Hawrylyshen、A.、Johnston、A.、Rosenberg、J。、およびH. Schulzrinne、「セッション開始プロトコル（SIP）拷問テストメッセージ」、RFC 4475、2006年5月。
[18] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[18] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[19] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[19] Jennings、C.、Mahy、R。、およびF. Audet、「セッション開始プロトコル（SIP）でのクライアント開始接続の管理」、RFC 5626、2009年10月。
[20] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[20] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェントURIS（Gruus）を取得および使用」、RFC 5627、2009年10月。
[21] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.
[21] Peterson、J.、Jennings、C。、およびR. Sparks、「セッション開始プロトコル（SIP）およびリアルタイムアプリケーションとインフラストラクチャエリアの変化プロセス」、BCP 67、RFC 5727、2010年3月。
[22] Elwell, J. and H. Kaplan, "Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)", RFC 5947, September 2010.
[22] Elwell、J。およびH. Kaplan、「セッション開始プロトコル（SIP）における複数のレコードアドレス（AOR）到達可能性情報の要件」、RFC 5947、2010年9月。
[23] Kaplan, H., "GIN with Literal AORs for SIP in SSPs (GLASS)", Work in Progress, November 2010.
[23] Kaplan、H。、「SSPS（Glass）のSIPのリテラルAORSを備えたジン」、2010年11月、進行中の作業。
[24] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008, <http:// csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf>.
[24] 国立標準技術研究所、「Secure Hash Standard（SHS）」、Fips Pub 180-3、2008年10月、<http：// csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf>。
[25] Kaliski, B., "TWIRL and RSA Key Size", May 2003.
[25] Kaliski、B。、「Twirl and RSAキーサイズ」、2003年5月。
The document "Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)" [22] contains a list of requirements and desired properties for a mechanism to register multiple AORs with a single SIP transaction. This section evaluates those requirements against the mechanism described in this document.
ドキュメント「セッション開始プロトコル（SIP）の複数のレコードアドレス（AOR）の到達可能性情報の要件」[22]には、単一のSIPトランザクションで複数のAORを登録するメカニズムの要件と目的のプロパティのリストが含まれています。このセクションでは、このドキュメントに記載されているメカニズムに対するこれらの要件を評価します。
REQ1 - The mechanism MUST allow a SIP-PBX to enter into a trunking arrangement with an SSP whereby the two parties have agreed on a set of telephone numbers assigned to the SIP-PBX.
REQ1-メカニズムにより、SIP-PBXがSSPを使用してトランキングアレンジメントに入ることを許可する必要があります。これにより、両当事者はSIP-PBXに割り当てられた一連の電話番号に同意しました。
The requirement is satisfied.
要件は満たされています。
REQ2 - The mechanism MUST allow a set of assigned telephone numbers to comprise E.164 numbers, which can be in contiguous ranges, discrete, or in any combination of the two.
REQ2-メカニズムは、割り当てられた電話番号のセットがE.164番号を含むことを許可する必要があります。
The requirement is satisfied. The Direct Inward Dialing (DID) numbers associated with a registration are established by bilateral agreement between the SSP and the SIP-PBX; they are not part of the mechanism described in this document.
要件は満たされています。登録に関連付けられた直接的な内向きのダイヤル（DID）数は、SSPとSIP-PBXの間の二国間契約によって確立されます。これらは、このドキュメントで説明されているメカニズムの一部ではありません。
REQ3 - The mechanism MUST allow a SIP-PBX to register reachability information with its SSP, in order to enable the SSP to route to the SIP-PBX inbound requests targeted at assigned telephone numbers.
REQ3-メカニズムは、SSPが割り当てられた電話番号をターゲットにしたSIP-PBXインバウンドリクエストにルーティングできるようにするために、SIP-PBXがSSPにリーチ性情報を登録できるようにする必要があります。
The requirement is satisfied.
要件は満たされています。
REQ4 - The mechanism MUST allow UAs attached to a SIP-PBX to register with the SIP-PBX for AORs based on assigned telephone numbers, in order to receive requests targeted at those telephone numbers, without needing to involve the SSP in the registration process.
REQ4-メカニズムにより、SIP-PBXに接続されたUASが、登録プロセスにSSPを関与させる必要なく、それらの電話番号を対象としたリクエストを受信するために、割り当てられた電話番号に基づいてAORSのSIP-PBXに登録することを許可する必要があります。
The requirement is satisfied; in the presumed architecture, SIP-PBX UAs register with the SIP-PBX and require no interaction with the SSP.
要件は満たされています。推定アーキテクチャでは、SIP-PBX UASがSIP-PBXに登録し、SSPとの相互作用を必要としません。
REQ5 - The mechanism MUST allow a SIP-PBX to handle requests originating at its own UAs and targeted at its assigned telephone numbers, without routing those requests to the SSP.
REQ5-メカニズムにより、SIP -PBXが独自のUASで発信され、割り当てられた電話番号をターゲットにしたリクエストを処理できるようにする必要があります。
The requirement is satisfied; SIP-PBXes may recognize their own DID numbers and GRUUs, and perform on-SIP-PBX routing without sending the requests to the SSP.
要件は満たされています。SIP-PBXEは、独自のDID番号とGruusを認識し、リクエストをSSPに送信せずにオン-SIP-PBXルーティングを実行する場合があります。
REQ6 - The mechanism MUST allow a SIP-PBX to receive requests to its assigned telephone numbers originating outside the SIP-PBX and arriving via the SSP, so that the SIP-PBX can route those requests onwards to its UAs, as it would for internal requests to those telephone numbers.
req6-メカニズムは、SIP-PBXがSIP-PBXの外側から発信され、SSPを介して到着する割り当てられた電話番号へのリクエストを受け取ることを許可する必要があります。これにより、SIP-PBXはそれらのリクエストをUASに内部と同様にルーティングできます。それらの電話番号へのリクエスト。
The requirement is satisfied
要件は満たされています
REQ7 - The mechanism MUST provide a means whereby a SIP-PBX knows which of its assigned telephone numbers an inbound request from its SSP is targeted at.
REQ7-メカニズムは、SIP -PBXが、SSPからのインバウンドリクエストの割り当てられた電話番号のどれを把握しているかを把握する手段を提供する必要があります。
The requirement is satisfied. For ordinary calls and calls using public GRUUs, the DID number is indicated in the user portion of the Request URI. For calls using Temp GRUUs constructed with the mechanism described in Section 7.1.2, the "gr" parameter provides a correlation token the SIP-PBX can use to identify to which UA the call should be routed.
要件は満たされています。Public Gruusを使用した通常の電話と電話の場合、DID番号はリクエストURIのユーザー部分に示されています。セクション7.1.2で説明されているメカニズムで構築されたTEMP Gruusを使用した呼び出しの場合、「GR」パラメーターは、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-メカニズムは、メカニズムを使用していないため、一方が片側を使用しないため、問題を回避する手段を提供する必要があります。
The requirement is satisfied through the 'gin' option tag and the 'bnc' Contact URI parameter.
要件は、「ジン」オプションタグと「BNC」に連絡するURIパラメーターを通じて満たされます。
REQ9 - The mechanism MUST observe SIP backwards compatibility principles.
REQ9-メカニズムは、SIP後方互換性の原則を観察する必要があります。
The requirement is satisfied through the 'gin' 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へのインバウンドリクエストのパスにある必要があります。
The requirement is satisfied through the use of the path mechanism defined in RFC 3327 [10]
要件は、RFC 3327で定義されているパスメカニズムの使用によって満たされます[10]
REQ11 - The mechanism MUST work when a SIP-PBX obtains its IP address dynamically.
REQ11 -SIP -PBXがIPアドレスを動的に取得したときにメカニズムが機能する必要があります。
The requirement is satisfied by allowing the SIP-PBX to use an IP address in the Bulk Number Contact URI contained in a REGISTER "Contact" header field.
この要件は、SIP-PBXがレジスタ「連絡先」ヘッダーフィールドに含まれるバルク番号のURIに連絡するIPアドレスを使用できるようにすることで満たされます。
REQ12 - The mechanism MUST work without requiring the SIP-PBX to have a domain name or the ability to publish its domain name in the DNS.
REQ12-メカニズムは、SIP -PBXにドメイン名またはDNSにドメイン名を公開する機能を必要とせずに機能する必要があります。
The requirement is satisfied by allowing the SIP-PBX to use an IP address in the Bulk Number Contact URI contained in a REGISTER "Contact" header field.
この要件は、SIP-PBXがレジスタ「連絡先」ヘッダーフィールドに含まれるバルク番号のURIに連絡するIPアドレスを使用できるようにすることで満たされます。
REQ13 - For a given SIP-PBX and its SSP, there MUST be no impact on other domains, which are expected to be able to use normal RFC 3263 procedures to route requests, including requests needing to be routed via the SSP in order to reach the SIP-PBX.
Req13-特定のSIP -PBXおよびそのSSPについては、他のドメインに影響を与える必要はありません。他のドメインは、通常のRFC 3263手順を使用してリクエストをルーティングできると予想されます。SIP-PBX。
The requirement is satisfied by allowing the domain name in the Request URI used by external entities to resolve to the SSP's servers via normal RFC 3263 resolution procedures.
この要件は、外部エンティティが使用するリクエストURIのドメイン名を、通常のRFC 3263解決手順を介してSSPのサーバーに解決できるようにすることで満たされます。
REQ14 - The mechanism MUST be able to operate over a transport that provides end-to-end integrity protection and confidentiality between the SIP-PBX and the SSP, e.g., using TLS as specified in [3].
REQ14-メカニズムは、[3]で指定されているTLSを使用して、SIP-PBXとSSPの間のエンドツーエンドの完全性の保護と機密性を提供する輸送上で動作させることができなければなりません。
The requirement is satisfied; nothing in the proposed mechanism prevents the use of TLS between the SSP and the SIP-PBX.
要件は満たされています。提案されたメカニズムには、SSPとSIP-PBXの間でTLSの使用を妨げるものはありません。
REQ15 - The mechanism MUST support authentication of the SIP-PBX by the SSP and vice versa, e.g., using SIP digest authentication plus TLS server authentication as specified in [3].
REQ15-メカニズムは、SSPによるSIP -PBXの認証をサポートする必要があり、その逆、たとえば、[3]で指定されているように、SIPダイジェスト認証とTLSサーバー認証を使用します。
The requirement is satisfied; SIP-PBXes may employ either SIP digest authentication or mutually authenticated TLS for authentication purposes.
要件は満たされています。SIP-PBXEは、認証目的でSIPダイジェスト認証または相互に認証されたTLSを使用する場合があります。
REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with public or temporary Globally Routable UA URIs (GRUUs) [20].
REQ16-メカニズムにより、SIP -PBXがUASに公共または一時的にルーティング可能なUA URI（Gruus）を提供する必要があります[20]。
The requirement is satisfied via the mechanisms detailed in Section 7.1.
要件は、セクション7.1で詳述されているメカニズムを介して満たされます。
REQ17 - The mechanism MUST work over any existing transport specified for SIP, including UDP.
REQ17-メカニズムは、UDPを含むSIP用に指定された既存の輸送で動作する必要があります。
The requirement is satisfied to the extent that UDP can be used for REGISTER requests in general. The application of certain extensions and/or network topologies may exceed UDP MTU sizes, but such issues arise both with and without the mechanism described in this document. This document does not exacerbate such issues.
この要件は、UDPを一般的に登録要求に使用できる限り、満たされます。特定の拡張トポロジーの適用は、UDP MTUサイズを超える可能性がありますが、このような問題は、このドキュメントで説明されているメカニズムの有無にかかわらず発生します。この文書は、そのような問題を悪化させません。
REQ18 - Documentation MUST give guidance or warnings about how authorization policies may be affected by the mechanism, to address the problems described in Section 3.3 [of RFC 5947].
REQ18-ドキュメントは、セクション3.3 [RFC 5947]に記載されている問題に対処するために、メカニズムによって認可ポリシーがどのように影響を受けるかについてガイダンスまたは警告を与える必要があります。
These issues are addressed at length in Section 10, as well as summarized in Section 7.4.
これらの問題は、セクション10で詳細に説明されており、セクション7.4で要約されています。
REQ19 - The mechanism MUST be extensible to allow a set of assigned telephone numbers to comprise local numbers as specified in RFC 3966 [15], which can be in contiguous ranges, discrete, or in any combination of the two.
REQ19-メカニズムは、割り当てられた電話番号のセットがRFC 3966 [15]で指定されているようにローカル番号を含むように拡張可能でなければなりません。
Assignment of telephone numbers to a registration is performed by the SSP's registrar, which is not precluded from assigning local numbers in any combination it desires.
登録への電話番号の割り当ては、SSPのレジストラによって実行されます。これは、必要な組み合わせでローカル番号を割り当てることを妨げられません。
REQ20 - The mechanism MUST be extensible to allow a set of arbitrarily assigned SIP URI's as specified in RFC 3261 [3], as opposed to just telephone numbers, without requiring a complete change of mechanism as compared to that used for telephone numbers.
REQ20-メカニズムは、電話番号の完全な変更を必要とせずに、電話番号のみとは対照的に、RFC 3261 [3]で指定されているarbitrarilyに割り当てられたSIP URIのセットを許可するために拡張可能でなければなりません。
The mechanism is extensible in such a fashion, as demonstrated by the document "GIN with Literal AoRs for SIP in SSPs (GLASS)" [23].
このメカニズムは、「SSPS（ガラス）のSIPのリテラルAORを含むジン」[23]で示されているように、このような方法で拡張可能です。
DES1 - The mechanism SHOULD allow an SSP to exploit its mechanisms for providing SIP service to normal UAs in order to provide a SIP trunking service to SIP-PBXes.
DES1-このメカニズムにより、SSPがSIPトランキングサービスをSIP -PBXEに提供するために、SPSサービスを通常のUASに提供するメカニズムを活用できるようにする必要があります。
The desired property is satisfied; the routing mechanism described in this document is identical to the routing performed for singly registered AORs.
望ましいプロパティが満たされています。このドキュメントで説明されているルーティングメカニズムは、単独で登録されたAORに対して実行されるルーティングと同じです。
DES2 - The mechanism SHOULD scale to SIP-PBXes of several thousand assigned telephone numbers.
DES2-メカニズムは、数千の割り当てられた電話番号のSIP -PBXEにスケーリングする必要があります。
The desired property is satisfied; nothing in this document precludes DID number pools of arbitrary size.
望ましいプロパティが満たされています。このドキュメントでは、任意のサイズの数のプールを排除することはありませんでした。
DES3 - The mechanism SHOULD scale to support several thousand SIP-PBX's on a single SSP.
DES3-メカニズムは、単一のSSPで数千個のSIP -PBXをサポートするように拡張する必要があります。
The desired property is satisfied; nothing in this document precludes an arbitrary number of SIP-PBXes from attaching to a single SSP.
望ましいプロパティが満たされています。このドキュメントには、任意の数のSIP-PBXが単一のSSPに付着することを妨げるものはありません。
Author's Address
著者の連絡先
Adam Roach Tekelec 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US
Adam Roach Tekelec 17210 Campbell Rd。スイート250ダラス、テキサス州75252 US
EMail: adam@nostrum.com