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)
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ユーザエージェント（UAS）のための電話を受信するSIPサービスプロバイダ（SSP）に登録できるメカニズムを定義します。適切に機能するために、この機構は、レコードのアドレスの各々（のAOR）は接触のユニークなセットにバルクマップに登録することを必要とします。電話番号は、完全修飾およびグローバルに一意であるため、この要件は、ドメインに関係なく電話番号を表すのAORによって満たされます。この文書では、したがって、このユースケースに焦点を当てています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6140.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6140で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. 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 REGISTER要求メッセージの使用は幾分RFC 3261によってREGISTERリクエストに対して定義された元の意味論を超えているが[3]、このアプローチは、特定の環境において有意な展開を見ています。特に、中小へのSIP-PBXサーバがE.164番号を使用して対処している展開はSIP-PBXサーバ用のDNSエントリまたは静的IPアドレスを維持する必要性を避けるために、このメカニズムを使用しています。
In recognition of the momentum that REGISTER-based approaches have seen in deployments, this document defines a REGISTER-based approach. Since E.164-addressed UAs are very common today in SIP-PBX environments, and since SIP URIs in which the user portion is an E.164 number are always globally unique, regardless of the domain, this document focuses on registration of SIP URIs in which the user portion is an E.164 number.
レジスタベースのアプローチが展開で見てきた勢いの認識では、この文書では、REGISTERベースのアプローチを定義します。 E.164アドレス指定のUAは、SIP-PBX環境で、今日は非常に一般的であり、SIP URIのため、ユーザ部分が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つの制約は、最も大きな影響を有する：（1）SIP-PBXがあると仮定することはできません静的IPアドレスを割り当てられました。 （2）無DNSエントリが一貫してSIP-PBXのIPアドレスに解決するために依拠することはできません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
用語「SIP-PBXは、」SIP構内交換機を示すために使用されている間また、「SSP」は「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レイアウト要件を満たすために、[17] RFC 4475に設立された<allOneLine />マークアップの規則を使用しています。完全を期すために、このマークアップを定義するテキスト（RFC 4475のセクション2.1 [17]）は、以下にその全体が再生されます。
Several of these examples contain unfolded lines longer than 72 characters. These are captured between <allOneLine/> tags. The single unfolded line is reconstructed by directly concatenating all lines appearing between the tags (discarding any line feeds or carriage returns). There will be no whitespace at the end of lines. Any whitespace appearing at a fold-point will appear at the beginning of a line.
これらの例のいくつかは、72文字よりも長い折り畳まれていない行が含まれています。これらは、<allOneLine />タグの間に捕捉されています。単一の折り畳まれていない行が直接タグ（任意の行を廃棄フィードやキャリッジリターン）との間に出現するすべての行を連結することによって再構成される。行の末尾に空白はありません。折り畳み点に現れる任意の空白行の先頭に表示されます。
The following represent the same string of bits:
以下は、同じビット列を表します。
Header-name: first value, reallylongsecondvalue, third value
ヘッダ名：最初の値、reallylongsecondvalue、第3の値
<allOneLine> Header-name: first value, reallylongsecondvalue , third value </allOneLine>
<allOneLine>ヘッダ名：最初の値、reallylongsecondvalue、第3の値</ allOneLine>
<allOneLine> Header-name: first value, reallylong second value, third value </allOneLine>
<allOneLine>ヘッダ名：第2の値をreallylong最初の値、第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を持つREGISTERリクエストを使用して達成されます。この文書はまた、レジストラと任意の媒体が本明細書に記載のメカニズムを理解することを確実にするために使用することができるオプションのタグを定義します。
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.
また、SSPによって割り当てられたパブリック、一時GRUUsの使用を許可するRFC 5627 [20]で定義されたグローバルにルーティング可能なUAのURI（GRUU）のメカニズムにはいくつかの軽量の拡張機能を定義します。
Aside from these extensions, the REGISTER request itself is processed by a registrar in the same way as normal registrations: by updating its location service with additional AOR-to-Contact bindings.
別にこれらの拡張機能から、REGISTERリクエスト自体は、通常の登録と同じようにレジストラによって処理されます。追加のAOR・ツー・コンタクトバインディングとそのロケーションサービスを更新することにより。
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.
複数のAORに登録するために、SIP-PBXは、SSPにREGISTER要求を送信します。このREGISTERリクエストには2つの重要な方法で、一般的なREGISTERリクエストごとに異なります。まず、それが「必要」ヘッダフィールドと「プロキシ要求」ヘッダフィールドの両方に「ジン」のオプションタグを含まなければなりません。 （オプションタグ「ジン」は、「暗黙的な数値を生成する」の頭字語である。）第二に、少なくとも1つの「連絡先」ヘッダフィールドに、それは「バルクを表し（「BNC」URIパラメータが含まれている連絡先URIを含まなければなりません数コンタクト」）およびNOユーザ部（したがって無ありません 『@』記号）。 「BNC」のパラメータを持つURIは、ユーザー部分を含めることはできません。 SIP URI「user」パラメータを除いて、この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.
代わりに、ロケーションサービスに単一のコンタクトURIの挿入を指示する、それは複数のURI（各関連AORに対して1つ）が挿入されるべきであることを示す「BNC」URIパラメータには、連絡先URIの特別な解釈が必要であることを示しています。
Any SIP-PBX implementing the registration mechanism defined in this document MUST also support the path mechanism defined by RFC 3327 [10], and MUST include a 'path' option tag in the "Supported" header field of the REGISTER request (which is a stronger requirement than imposed by the path mechanism itself). This behavior is necessary because proxies between the SIP-PBX and the registrar may need to insert "Path" header field values in the REGISTER request for this document's mechanism to function properly, and, per RFC 3327 [10], they can only do so if the User Agent Client (UAC) inserted the option tag in the "Supported" header field. In accordance with the procedures defined in RFC 3327 [10], the SIP-PBX is allowed to ignore the "Path" header fields returned in the REGISTER response.
任意のSIP-PBX本文書で定義されている登録メカニズムを実装はまた、RFC 3327 [10]で定義されたパスメカニズムをサポートしなければなりません、そしてあるREGISTER要求（の「サポート」ヘッダフィールドに「パス」オプションタグを含まなければなりませんパス機構自体によって課されるよりも強い要件）。 SIP-PBXとの間のプロキシおよびレジストラが正しく機能するには、この文書のメカニズムのREGISTERリクエストに「パス」ヘッダフィールド値を挿入する必要があるかもしれません、そして、RFC 3327 [10]あたり、彼らだけそうすることができるので、この動作は必要ですユーザエージェントクライアント（UAC）は、「サポート」ヘッダフィールドでオプションタグを挿入した場合。 RFC 3327で定義された手順[10]に従って、SIP-PBXは、「パス」ヘッダフィールドを無視することを許可されているREGISTER応答で返されます。
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」パラメータを有する少なくとも一つの「接触」ヘッダフィールドを含むREGISTERリクエストを受信すると、登録が要求されている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が、外部パーティ（例えば、「：+12145550102@ssp.example.com SIP」）から受信することを期待する形式になります。対応するコンタクトは、REGISTER要求のContact URIに（前の「+」記号を含む）完全修飾、E.164形式の番号を含むユーザ部分を追加し、「BNC」パラメータを除去することにより形成されます。別に初期「+」記号から、このE.164形式の番号は0から9までの数字で、もっぱらから成らなければなりませんし、明示的に任意の視覚的な区切り記号を含めることはできません（例えば、「 - 」「」、 『（』、または"）"）。 「接触」ヘッダフィールドは、URIが含まれている場合、例えば<：198.51.100.3：SIP 5060と、BNC>、その後、前述のAORと関連する接触値が<SIP 5060：+12145550102@198.51.100.3>あろう。
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にしようREGISTER要求が一括登録からその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を含むREGISTERリクエストを受信レジストラは、200-クラス（成功）応答を送ってはいけません。他のエラーが適用されない場合は、レジストラは、このエラー状態を示すために400（不正なリクエスト）応答を使用することができます。
Note that the preceding paragraph is talking about the user portion of a URI:
前項のURIのユーザー部分について話していることに注意してください：
sip:+12145550100@example.com ^^^^^^^^^^^^
SIP：+12145550100@example.com ^^^^^^^^^^^^
A registrar compliant with this document MUST support the path mechanism defined in RFC 3327 [10]. The rationale for support of this mechanism is given in Section 5.1.
本文書とレジストラ準拠は、RFC 3327 [10]で定義されたパスメカニズムをサポートしなければなりません。このメカニズムをサポートするための根拠は、セクション5.1で与えられています。
Aside from the "bnc" parameter, all URI parameters present on the Contact URI in the REGISTER request MUST be copied to the contact value stored in the location service.
別に「BNC」パラメータから、REGISTER要求の連絡先URIに存在するすべてのURIパラメータは、ロケーション・サービスに格納された接触値にコピーする必要があります。
If the SSP servers perform processing based on User Agent Capabilities (as defined in RFC 3840 [13]), they will treat any feature tags present on a "Contact" header field with a "bnc" parameter in its URI as applicable to all of the resulting AOR-to-Contact mappings. Similarly, any option tags present on the REGISTER request that indicate special handling for any subsequent requests are also applicable to all of the AOR-to-Contact mappings.
SSPサーバは、ユーザエージェントの能力に基づいて処理を行う場合（RFC 3840で定義されている[13]）、彼らはすべてに該当する場合、そのURIで「BNC」パラメータで「連絡先」ヘッダフィールド上に存在する任意の機能タグを扱いますその結果AORツー連絡先のマッピング。同様に、任意の後続の要求のための特別な処理を示すREGISTERリクエスト上に存在する任意のオプションタグも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.
この文書では、要求のURIの「user」パラメータを含めるために、[3] RFC 3261で指定された動作を変更しません。しかし、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は、SSPは、連絡先URIが「user」パラメータを含んではならないことを、「BNC」パラメータを含む連絡先URIを使用して登録します。 「BNC」パラメータと「user」パラメータの両方に接触URIを含むREGISTERリクエストを受信レジストラは200クラス（成功）応答を送ってはいけません。他のエラーが適用されない場合は、レジストラは、このエラー状態を示すために400（不正なリクエスト）応答を使用することができます。
Note that the preceding paragraph is talking about the "user" parameter of a URI:
前項のURIの「user」パラメータについて話していることに注意してください：
sip:+12145550100@example.com;user=phone ^^^^^^^^^^
SIP：+12145550100@example.com;ユーザー=電話^^^^^^^^^^
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.
「BNC」パラメータを含む連絡先URIを使用して登録SIP-PBXは、SSPからの要求を受信し、要求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の顧客のうちの1つに割り当てE.164番号を示す任意の着信SIP要求のために、これは一般的に[そのAORと関連する登録連絡先に設定された目標を設定し、RFC 3261のセクション16.6に記載されるようにリクエストの転送を行う含むであろう3]。 INVITE要求受信するためのこのような処理を実行し、「REG」イベントパッケージへの要求を登録する必要があり、この文書で定義されたメカニズムを使用して、SSP（セクション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によって定義された関連するREGISTER関連拡張子と相互作用する手段を記載しています。
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-で提供 - SIP-PBXの後ろのUAで動作するように高度なサービスを可能にするために、RFC 5627 [20]で定義されたGRUUメカニズムは、この文書で定義されたメカニズムで正常に動作することが重要ですPBXは、自分の使用するためGRUUsを取得して使用することができます。
Support of public GRUUs is OPTIONAL in SSPs and SIP-PBXes.
公共GRUUsのサポートのSSPとSIP-PBXではではオプションです。
When a SIP-PBX registers a Bulk Number Contact (a contact with a "bnc" parameter), and also invokes GRUU procedures for that contact during registration, then the SSP will assign a public GRUU to the SIP-PBX in the normal fashion. Because the URI being registered contains a "bnc" parameter, the GRUU will also contain a "bnc" parameter. In particular, this means that the GRUU will not contain a user portion.
SIP-PBXバルク番号との接触（「BNC」パラメータとの接触）を登録し、また登録時にその連絡先のGRUUプロシージャを呼び出したとき、次にSSPは、通常の方法でSIP-PBXにパブリックGRUUを割り当てます。登録されたURIが「BNC」のパラメータが含まれているため、GRUUも「BNC」のパラメータが含まれます。特に、これはGRUUは、ユーザー部分を含まないことを意味します。
When a UA registers a contact with the SIP-PBX using GRUU procedures, the SIP-PBX provides to the UA a public GRUU formed by adding an "sg" parameter to the GRUU parameter it received from the SSP. This "sg" parameter contains a disambiguation token that the SIP-PBX can use to route inbound requests to the proper UA.
UAがGRUUの手順を用いてSIP-PBXとの接触を登録すると、SIP-PBXは、UAには、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>"
連絡先：<SIP：198.51.100.3; BNC>; + sip.instance = "<壷：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:
独自のUAがGRUUの手順を使用して登録すると、SIP-PBXは、それは「SG」パラメータに適切な感じどのデバイス識別子を追加し、独自のUAにこの値を提示することができます。例えば、AOR「+12145550102」に関連付けられたUAを想定し、そのREGISTER要求に次の「接触」ヘッダフィールドを送りました。
Contact: <sip:line-1@10.20.1.17>; +sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
連絡先：<SIP：line-1@10.20.1.17>。 + sip.instance = "<壷：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:
完全修飾Eを含むユーザ部分を挿入し、（おそらくいくつかの他の識別子おそらくURN自体）SIP-PBXは、デバイスを一意に識別するトークンでSSPから受信パブ-GRUUに「SG」パラメータを追加します0.164番号はUAに関連付けられ、そしてその公開GRUUとしてUAに結果を返します。登録UAにSIP-PBXから送信された「連絡先」ヘッダフィールドは次のようになります。
<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に到着したとき、それは「BNC」パラメータを指定せずにURIの場合と比べて、SSPは、GRUUのためにわずかに異なる処理を行います。 GRUUが登録バルク番号の連絡先に再標的にされている場合、SSPは、新しいターゲットにGRUUから「SG」パラメータをコピーする必要があります。 SIP-PBXは、次にどのユーザエージェント要求がルーティングされるべきかを決定するために、この「SG」パラメータを使用することができます。例えば、上に示したUAのためのSIP-PBXに再標的化されたINVITEリクエストの最初の行は次のようになります。
INVITE sip:+12145550102@198.51.100.3;sg=00:05:03:5e:70:a6 SIP/2.0
SIPのINVITE：+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として - - グローバルそうしない理由は、公共GRUUsの整合性を維持し、代替のプライバシーメカニズム（公共GRUUsが匿名化されている場合、すなわち、その後、アノニマイザー機能が提供可能である必要があるとシステムが含まれるであろうその裏面のみ原公衆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].
一時的なGRUUsは、当事者がGRUUを作成し、共有するための匿名性を提供するために使用されています。同じSIP-PBXの後ろから発信したように2つの一時的なGRUUsを相関させることができれば、匿名性のこの原則に違反します。従って、むしろそのUAの一時GRUUsにおけるSIP-PBXのための単一の、不変の識別子に依存するよりも、我々は、SSPがミント一意の一時GRUUsにSIP-PBXのための十分な情報をSIP-PBXを提供するメカニズムを定義します。これらのGRUUsは、SSPが適切なSIP-PBXにそれらを関連付けることができますが、他の当事者がそうすることができない性質を持っています。この目標を達成するために、我々は、[20] RFC 5627の付録A.2で説明した手順のわずかな変更を使用します。
The SIP-PBX needs to be able to construct a temp-gruu in a way that the SSP can decode. In order to ensure that the SSP can decode GRUUs, we need to standardize the algorithm for creation of temp-gruus at the SIP-PBX. This allows the SSP to reverse the algorithm in order to identify the registration entry that corresponds to the GRUU.
SIP-PBXは、SSPが復号できるような方法でTEMP-GRUUを構築することができる必要があります。 SSPはGRUUsをデコードできることを確実にするために、我々は、SIP-PBXで一時-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によってサービス他のSIP-PBXを含む一時的なGRUUを、デコードが可能でないことも同様に重要です。 {K_e1、K_e2}：このプロパティを達成するために、一時的なGRUUsをサポートしてSSPは、非対称鍵ペアを作成して保存する必要があります。 K_e2をプロビジョニングを介してSIP-のPBXと共有されている間K_e1は、SSPによって秘密に保たれています。
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のセクション4で定義された文字セットとエンコーディングを使用する[8]、それ以外の任意の末尾「=」文字が符号化に廃棄し、復号化するために、必要に応じて追加されなければなりません。
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）アルゴリズムを説明するための用語「HMAC-SHA256-80」を利用します。この文書では、HMAC-SHA256-80は末尾（最下位）ビットを廃棄することにより80ビットの結果を切り捨て、SHA-256 [24]のセキュアハッシュアルゴリズムのアプリケーションとして定義されます。
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:
一時的GRUUsをサポートしているSSPは200クラスのREGISTER応答で「BNC」パラメータを含むすべての「連絡先」ヘッダフィールド上の「一時-GRUU-クッキー」パラメータを含まなければなりません。この「一時-GRUU-クッキー」とは、以下の性質を持っている必要があります。
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.一時-GRUU-cookieが当事者で偽造しているはずがありません。言い換えれば、SSPはクッキーを調べ、それが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.
前記TEMP-GRUU-クッキーは、その登録に任意のリフレッシュを含む、登録の過程で不変でなければなりません。このプロパティは、それがSIP-PBXは、それはそのUAのに発行したTEMP-gruusがまだ有効であるかどうかを判断するために一時-GRUU-クッキーを調べることができますよう、重要です。
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つのプロパティを果たすよう、一時-GRUU-クッキーの世代のために彼らが選んだの任意のアルゴリズムを実装するために選択することができます。
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ビット長でゼロに初期化されるカウンタIを維持します。このカウンタは、永続的バックエンドデータベースまたは同様の技術を用いて、記憶されています。レジストラは、特定のSIP-PBXおよびインスタンスID（[20]によって定義される）のための第1の仮GRUUを作成する場合、レジストラは、カウンタの現在の値を指摘I_I、及びデータベース内のカウンタをインクリメントします。レジストラは、データベース、永続的なハッシュマップ、または同様の技術を使用して接触し、インスタンスIDにI_Iをマッピングします。登録はGRUUにバインドされている特定のインスタンスIDを持つすべての連絡先は、もはや存在するように期限切れになった場合、レジストラはマッピングを削除します。一時GRUUsを伴うコールIDの変化に無効化されている場合、同様に、レジストラは、AORとインスタンスIDにI_Iから現在のマッピングを削除カウンタ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の古い値を記憶しています。一時-GRUU-クッキーを生成するために、レジストラは、計算します。
SA = HMAC(SK_a, I_i) temp-gruu-cookie = base64enc(I_i || SA)
SA = HMAC（SK_A、I_I）TEMP-GRUU-クッキー= 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]を参照。この目的に適した1つのHMACアルゴリズムはHMAC-SHA256-80です。
According to Section 3.2 of RFC 5627 [20], every registration refresh generates a new temp-gruu that is valid for as long as the contact remains registered. This property is both critical for the privacy properties of temp-gruu and is expected by UAs that implement the temp-gruu procedures. Nothing in this document should be construed as changing this fundamental temp-gruu property in any way. SIP-PBXes that implement temporary GRUUs MUST generate a new temp-gruu according to the procedures in this section for every registration or registration refresh from GRUU-supporting UAs attached to the SIP-PBX.
RFC 5627のセクション3.2 [20]によると、すべての登録の更新は限り接触が登録されたままとするために有効である新しい一時-GRUUを生成します。このプロパティは、一時-GRUUのプライバシーの性質のために重要なの両方で、一時-GRUUの手順を実装するUAが期待されます。本書の内容は、どのような方法で、この基本的な一時-GRUUプロパティを変更するものではありません。一時GRUUsを実装するSIP-のPBXは、SIP-PBXに取り付けGRUU支持のUAからのすべての登録又は登録の更新については、このセクションの手順に従って、新しい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クッキーが変化します。この変更は、SIP-PBXは、そのユーザエージェントに発行されたすべての一時-gruusが無効になります。 （RFC 5628に記載されているように[10]、登録イベント体で<TEMP-GRUU>要素を含むように、例えば）SIP-PBXは、この情報を追跡している場合、それは以前に発行されたTEMP-gruusが変化を観察することにより無効であると判定することができますSSPによってそれに与えられ、一時-GRUU-クッキー。
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.
そのUAの一時GRUUsを発行SIP-PBXは、HMACキーを維持しなければなりません：PK_Aを。この値は、着信GRUUsがSIP-PBXによって生成されたことを検証するために使用されます。
To generate a new temporary GRUU for use by its own UAs, the SIP-PBX MUST generate a random distinguisher value: D. The length of this value is up to implementors, but it MUST be long enough to prevent collisions among all the temporary GRUUs issued by the SIP-PBX. A size of 80 bits or longer is RECOMMENDED. See RFC 4086 [16] for further considerations on the generation of random numbers in a security context. After generating the distinguisher D, the SIP-PBX MUST calculate:
独自のユーザーエージェントで使用する新しい一時的なGRUUを生成するには、SIP-PBXは、ランダムな識別値を生成する必要がありますD.この値の長さは実装次第ですが、すべてのテンポラリGRUUs間の衝突を防ぐのに十分な長さでなければなりませんSIP-PBXによって発行されました。 80ビット以上のサイズが推奨されます。セキュリティコンテキストで乱数の生成に関する更なる考慮事項についてはRFC 4086 [16]を参照してください。識別器Dを生成した後、SIP-PBXは、計算しなければなりません。
M = base64dec(SSP-cookie) || D E = RSA-Encrypt(K_e2, M) PA = HMAC(PK_a, E)
M = base64dec（SSP-クッキー）|| D E = RSA暗号化（K_e2、M）PA = HMAC（PK_A、E）
Temp-Gruu-userpart = "tgruu." || base64(E) || "." || base64(PA)
TEMP-GRUU-userpart = "TGRUU。" || BASE64（E）|| "" || BASE64（PA）
where || denotes concatenation. "HMAC" represents any suitably strong HMAC algorithm; see RFC 2104 [1] for a discussion of HMAC algorithms. One suitable HMAC algorithm for this purpose is HMAC-SHA256-80.
どこ||連結を示しています。 「HMAC」は、任意の適切な強度HMACアルゴリズムを示します。 HMACアルゴリズムの議論のためにRFC 2104 [1]を参照。この目的に適した1つのHMACアルゴリズムはHMAC-SHA256-80です。
Finally, the SIP-PBX adds a "gr" parameter to the temporary GRUU that can be used to uniquely identify the UA registration record to which the GRUU corresponds. The means of generation of the "gr" parameter are left to the implementor, as long as they satisfy the properties of a GRUU as described in RFC 5627 [20].
最後に、SIP-PBX一意GRUUが対応するUA登録レコードを識別するために使用することができる一時的GRUUの「GR」パラメータを追加します。 RFC 5627 [20]に記載されているように、「GR」パラメータの生成手段は、それらが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:
RFC 5627の付録A.2に記載されているように、「GR」パラメータを生成するための一つの有効な手法は、「E」の計算および「A」である[20]として「GR」パラメータを形成します。
gr = base64enc(E) || base64enc(A)
GR = base64enc（E）|| base64enc（A）
Using this procedure may result in a temporary GRUU returned to the registering UA by the SIP-PBX that looks similar to this:
この手順を使用すると、一時的なGRUUになることがあり、これに似ていますSIP-PBXで登録UAに戻りました。
<allOneLine> Contact: <sip:line-1@10.20.1.17> ;temp-gruu="sip:tgruu.MQyaRiLEd78RtaWkcP7N8Q.5qVbsasdo2pkKw@ ssp.example.com;gr=YZGSCjKD42ccxO08pA7HwAM4XNDIlMSL0HlA" ;+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>" ;expires=3600 </allOneLine>
<allOneLine>連絡先：<SIP：line-1@10.20.1.17>;一時-GRUU = "一口：tgruu.MQyaRiLEd78RtaWkcP7N8Q.5qVbsasdo2pkKw @ ssp.example.com; GR = YZGSCjKD42ccxO08pA7HwAM4XNDIlMSL0HlA"; + sip.instance = "<壷： UUID：d0e2f290-104b-11df-8a39-0800200c9a66>」; = 3600 </ allOneLine>満了します
When the SSP proxy receives a request in which the user part begins with "tgruu.", it extracts the remaining portion and splits it at the "." character into E' and PA'. It discards PA'. It then computes E by performing a base64 decode of E'. Next, it computes:
SSPプロキシがユーザ部分が始まるたリクエスト受信した場合、「TGRUU」を、それが残りの部分を抽出し、でそれを分割します「」 Eに文字「とPA」。それはPAを破棄します。その後、Eのbase64でデコード」を実行することにより、Eを計算します。次に、計算します。
M = RSA-Decrypt(K_e1, E)
M = RSA-復号化（K_e1、E）
The SSP proxy extracts the fixed-length temp-gruu-cookie information from the beginning of this M and discards the remainder (which will be the distinguisher added by the SIP-PBX). It then validates this temp-gruu-cookie. If valid, it uses it to locate the corresponding SIP-PBX registration record and routes the message appropriately.
SSPプロキシは、このMの先頭から固定長TEMP-GRUU-Cookie情報を抽出し（SIP-PBXによって追加弁別あろう）、残りを破棄する。それは、この一時-GRUU-クッキーを検証します。有効な場合、それは適切に対応する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-クッキーを生成するために使用される場合、この識別は、48ビットカウンタIと80ビットにTEMP-GRUU-Cookie情報を分割することにより行われますHMAC。これは、HMACは、カウンタIと一致し、そのマップ内のSIP-PBXの登録レコードを見つけるためにIカウンタを使用していることを検証します。カウンタがロールオーバまたはリセットしている場合、この計算は、現在および前SK_A用いて行われます。
When the SIP-PBX receives a request in which the user part begins with "tgruu.", it extracts the remaining portion and splits it at the "." character into E' and PA'. It then computes E and PA by performing a base64 decode of E' and PA', respectively. Next, it computes:
SIP-PBXは、ユーザ部分が始まるたリクエスト受信した場合、「TGRUU」を、それが残りの部分を抽出し、でそれを分割します「」 Eに文字「とPA」。これは次に、それぞれ、E「及びPA」のBASE64のデコードを行うことにより、EおよびPAを算出します。次に、計算します。
PAc = HMAC(PK_a, E)
PAC = HMAC（PK_A、E）
where HMAC is the HMAC algorithm used for the steps in Section 7.1.2.2. If this computed value for PAc does not match the value of PA extracted from the GRUU, then the GRUU is rejected as invalid.
HMACは、セクション7.1.2.2の手順に使用するHMACアルゴリズムです。 PACのため、この計算値は、GRUUから抽出されたPAの値と一致しない場合には、GRUUは無効として拒否されます。
The SIP-PBX then uses the value of the "gr" parameter to locate the UA registration to which the GRUU corresponds, and routes the message accordingly.
SIP-PBXは、それに応じてメッセージをGRUUが対応するUA登録を検索する「GR」パラメータの値を使用して、経路。
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.
このメカニズムは、本質的にREGISTERトランザクションの振る舞いを扱うとして、RFC 3680 [12]で定義された登録イベントパッケージへの影響を考慮することが不可欠です。 SIP-PBXのための総合的な登録状態についての学習とシングルSIP-PBX AORの登録状態についての学習：実際には、登録データに加入するための2つの主な使用例があるでしょう。
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登録イベントパッケージに加入することができます - つまり、URIは、REGISTERリクエストの「へ」ヘッダフィールドで使用しました。
The NOTIFY messages for such a subscription will contain a body that contains one record for each AOR associated with the SIP-PBX. The AORs will be in the format expected to be received by the SSP (e.g., "sip:+12145550105@ssp.example.com"), and the contacts will correspond to the mapped contact created by the registration (e.g., "sip:+12145550105@98.51.100.3").
SIP-PBXに関連する各AORに1つのレコードが含まれて体が含まれています、このようなサブスクリプションのメッセージを通知します。 AORは、SSP（例えば、「SIP：+12145550105@ssp.example.com」）によって受信されることが予想形式になり、連絡先登録（例えば、「SIPによって作成されたマップされた連絡先に対応することになります。 +12145550105@98.51.100.3" ）。
In particular, the "bnc" parameter is forbidden from appearing in the body of a reg-event NOTIFY request unless the subscriber has indicated knowledge of the semantics of the "bnc" parameter. The means for indicating this support are out of scope of this document.
具体的には、「BNC」パラメータは、加入者が「BNC」パラメータの意味論の知識を示していない限り、NOTIFY要求REG-イベントの本体に表示され禁止されています。このサポートを示すための手段は、この文書の範囲外です。
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がその関連のUAにSIP-PBXによって発行されている知っていないため、これらのレコードは、一般的にRFC 5628で定義された<TEMP-GRUU>または<パブ-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にSIP-PBXが所有AOR宛う。 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」イベントSUBSCRIBEリクエストは、SIP-PBXによって処理されています。その結果、登録イベントパッケージを処理するためのSSP上の要件は、要求がポリシーに残されていないSUBSCRIBE。
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と登録イベントパッケージのSUBSCRIBEリクエストを受信した場合、その後、同じようにSIP-PBXにSUBSCRIBEのSSP MUSTプロキシ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-のPBXにSUBSCRIBEリクエストをフォークします。リクエストURIの両方が暗黙SIP-PBXによって登録及び明示的SSPプロキシに直接登録された連絡先に対応する場合、同様に、次にSSPプロキシは、意味的に適用可能なSIP-PBXまたはSIP-のPBXにSUBSCRIBEリクエストをフォークし、 （登録データは、SSPで明示的な登録に対応して応答します）レジストラ機能へ。これらの例の両方でフォークは、SSPがある場合は避けることができ、PBXをからの最新情報のコピーを維持することができます。
Section 4.9 of RFC 3680 [12] indicates that "a subscriber MUST NOT create multiple dialogs as a result of a single [registration event] subscription request". Consequently, subscribers who are not aware of the extension described by this document will accept only one dialog in response to such requests. In the case described in the preceding paragraph, this behavior will result in such clients receiving accurate but incomplete information about the registration state of an AOR. As an explicit change to the normative behavior of RFC 3680, this document stipulates that subscribers to the registration event package MAY create multiple dialogs as the result of a single subscription request. This will allow subscribers to create a complete view of an AOR's registration state.
RFC 3680 [12]のセクション4.9は、「加入者は、単一の[登録イベント]サブスクリプション要求の結果として、複数のダイアログを作成してはいけません」ということを示しています。そのため、この文書で説明した拡張子を認識していない加入者は、このような要求に応じてのみ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.
REG-イベントの加入者が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は、[5] SIP-PBXへのサブスクリプションを移行するRFC 3265で定義されたサブスクリプション・マイグレーション・メカニズムを使用すべきです。
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は、 "; BNC 5060：198.51.100.3 SIP" の連絡先URIを使用しました。そのような登録が完了すると、登録イベントサブスクリプションは、URIの要求とSSPに到着する「SIP：+12145550102@ssp.example.com」URI「SIPのリクエストで、SIP-PBXに再標的にされます。 +12145550102@198.51.100.3：5060" 。 SIP-PBXによって作成された登録文書は、「：+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を探していることになるので、ないために使用されたアドレスに関連する情報を見つけることができるようになりますことを保証しますSIP-PBX）にSSPから情報を送信します。
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] UAがプロキシとUA間の双方向のトラフィックを許可する方法で、プロキシと長寿命のTCP接続またはUDPアソシエーションを確立することを可能にするメカニズムを定義します。この現象は、NATの存在下で特に重要であり、いつでもTLS [18]セキュリティが要求されます。 SSPもSIP-PBXはいずれも、クライアントが開始した接続をサポートするために必要とされます。
Generally, the outbound mechanism works with the solution defined in this document, without any modifications. Implementors should note that the instance ID used between the SIP-PBX and the SSP's registrar 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に登録のUAのいずれか識別することに注意すべきです。その結果、特定のインスタンスを標的とする（RFC 3841 [14]で定義された）発呼者の選好を使用する任意の試みは失敗する可能性があります。ユーザーエージェントの特定のインスタンスをターゲットにするための好ましい機構は、GRUU（セクション7.1を参照）であるので、これは問題であってはなりません。
7.4. Non-Adjacent Contact Registration (Path) and Service-Route Discovery
7.4. 非隣接問い合わせ登録（パス）およびサービス経路探索
RFC 3327 [10] defines a means by which a registrar and its associated proxy can be informed of a route that is to be used between the proxy and the registered user agent. The scope of the route created by a "Path" header field is contact specific; if an AOR has multiple contacts associated with it, the routes associated with each contact may be different from each other. Support for non-adjacent contact registration is required in all SSPs and SIP-PBXes implementing the multiple-AOR-registration protocol described in this document.
RFC 3327 [10]レジストラとそれに関連するプロキシはプロキシと登録ユーザエージェントとの間で使用されるルートを通知することができる手段を定義します。 「パス」ヘッダフィールドによって作成されたルートの範囲は接触特異的です。 AORは、それに関連付けられた複数の接点を有する場合、各連絡先に関連付けられたルートは、互いに異なっていてもよいです。非隣接接触登録のサポートは、すべてのSSPに必要とされ、SIP-のPBXは、本書に記載の多AOR登録プロトコルを実装します。
At registration time, any proxies between the user agent and the registrar may add themselves to the "Path" header field. By doing so, they request that any requests destined to the user agent as a result of the associated registration include them as part of the Route towards the user agent. Although the path mechanism does deliver the final path value to the registering UA, UAs typically ignore the value of the path.
登録時には、ユーザーエージェントとレジストラ間の任意のプロキシは「パス」ヘッダフィールドに自分自身を追加することができます。そうすることによって、彼らは、関連する登録の結果として、ユーザエージェント宛てのすべての要求は、ユーザエージェントへのルートの一部としてそれらを含めることを要求します。パス機構が登録UAへの最終パス値を提供したが、UAは、典型的にパスの値を無視します。
To provide similar functionality in the opposite direction -- that is, to establish a route for requests sent by a registering UA -- RFC 3608 [11] defines a means by which a UA can be informed of a route that is to be used by the UA to route all outbound requests associated with the AOR used in the registration. This information is scoped to the AOR within the UA, and is not specific to the contact (or contacts) in the REGISTER request. Support of service route discovery is OPTIONAL in SSPs and SIP-PBXes.
登録UAによって送られたリクエストのルートを確立すること、である - - 逆方向に同様の機能を提供するために、RFC 3608を[11] UAにより使用されるルートを通知することができる手段を定義しますUA登録に使用AORに関連付けられているすべての発信要求をルーティングします。この情報は、UA内AORにスコープ、およびREGISTERリクエストに接触（または連絡先）に特異的ではありません。サービスルート発見のサポートのSSPとSIP-PBXではではオプションです。
The registrar unilaterally generates the values of the service route using whatever local policy it wishes to apply. Although it is common to use the "Path" and/or "Route" header field information in the request in composing the service route, registrar behavior is not constrained in any way that requires it to do so.
レジストラは、一方的にそれが適用することを希望する地元どんな政策使ってサービスルートの値を生成します。それはサービスルートを構成するには、「パス」および/またはリクエストの「Route」ヘッダフィールド情報を使用するのが一般的ですが、レジストラの行動は、それがそうする必要がどのような方法で制約されていません。
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を拡大から生じるすべてのロケーション・サービス・レコードは、必ずしも単一のパスを共有します。プロキシは、パスで自分自身を含めるかどうかについての接触によって接触基づいて政策決定を行うことができません。第二に、同様に、共通REGISTERリクエストに登録されている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つの興味深い技術は、サービスルートまたはパスエントリのユーザ部分にトークンまたはクッキーを含むことです。このトークンやクッキーは、ユーザーに関連付けられているアイデンティティ、能力、および/またはポリシーについてのプロキシに情報を伝えることができます。この情報は、いくつかのAORと複数AOR登録が用いられるいくつかの接点間で共有されるので、注意がそうすると、すべてのAORと単一REGISTERリクエストに登録されているすべての連絡先のために許容可能であることを保証するために注意しなければなりません。
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.
次の例では、認証に関連するすべての手順をElideのことに注意してください。これは、明瞭にするために行われます。実際の展開では、彼らのシステムに適切な認証のレベルを提供する必要があります。
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.
この例では、メッセージがINVITE登録のUAの一つ宛に続く基本的なバルクREGISTERトランザクションのために流れる示します。例えばメッセージは、シーケンス図の後に示されています。
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
ssp.example.com SIP / 2.0経由：SIP / 2.0 / UDP 198.51.100.3:5060;branch=z9hG4bKnashds7マックス・フォワード：70：<SIP：pbx@ssp.example.com>から<一口一口を登録します。 pbx@ssp.example.com>;タグは= a23589コールIDを：843817637684230 998sdasdh09 @のCSeq：1826 REGISTERプロキシが必要：ジンが必要：ジンはサポートされている：パスの連絡先：<SIP：198.51.100.3：5060; BNC>有効期限：7200をコンテンツの長さ：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: ...
+12145550105@ssp.example.com SIP / 2.0経由：SIP INVITE SIP / 2.0 / UDP foo.exampleを、ブランチ= z9hG4bKa0bc7a0131f0adマックス・フォワード：69：<SIP：2145550105@some-other-place.example.net> From：<SIP：gsmith@example.org>;タグ= 456248コールID：f7aecbfc374d557baf72d6352e1fbcd4のCSeq：24762連絡先をINVITE：<SIP：line-1@192.0.2.178：2081>のContent-Type：アプリケーション/ SDPコンテンツの長さ： ...
<sdp body here> (4) The SSP re-targets the incoming request according to the information received from the SIP-PBX at registration time.
（4）SSP再ターゲット着信要求登録時にSIP-PBXから受信した情報に応じて、<ここで、SDPボディ>。
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: ...
SIPのINVITE：+12145550105@198.51.100.3 SIP / 2.0経由：SIP / 2.0 / UDP ssp.example.com;ブランチ= z9hG4bKa45cd5c52a6dd50経由：SIP / 2.0 / UDP foo.example;ブランチ= z9hG4bKa0bc7a0131f0adマックス・フォワード：68：< SIP：2145550105@some-other-place.example.net>から<SIP：gsmith@example.org>;タグ= 456248コールID：f7aecbfc374d557baf72d6352e1fbcd4のCSeq：24762連絡先をINVITE：<SIP：line-1@192.0.2.178 ：2081>のContent-Type：アプリケーション/ SDPコンテンツの長さ：...
<sdp body here>
<ここSDPボディ>
This example shows a bulk REGISTER transaction with the SSP making use of the "Path" header field extension [10]. This allows the SSP to designate a domain on the incoming Request URI that does not necessarily resolve to the SIP-PBX when the SSP applies RFC 3263 procedures to it.
この例では、SSPが「パス」ヘッダフィールド拡張[10]を利用すると、バルクREGISTERトランザクションを示します。これは、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
ssp.example.com SIP / 2.0経由：SIP / 2.0 / UDP 198.51.100.3:5060;branch=z9hG4bKnashds7マックス・フォワード：70：<SIP：pbx@ssp.example.com>から<一口一口を登録します。 pbx@ssp.example.com>;タグ= a23589コールID：326983936836068 998sdasdh09 @のCSeq：1826 REGISTERプロキシが必要：GIN必要：GINサポート：パスのパス：<SIP：pbx@198.51.100.3：5060; LR>お問い合わせ：<SIP：pbx.example; BNC>有効期限：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: ...
+12145550105@ssp.example.com SIP / 2.0経由：SIP INVITE SIP / 2.0 / UDP foo.exampleを、ブランチ= z9hG4bKa0bc7a0131f0adマックス・フォワード：69：<SIP：2145550105@some-other-place.example.net> From：<SIP：gsmith@example.org>;タグ= 456248コールID：7ca24b9679ffe9aff87036a105e30d9bのCSeq：24762連絡先をINVITE：<SIP：line-1@192.0.2.178：2081>のContent-Type：アプリケーション/ SDPコンテンツの長さ： ...
<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.
（4）SSP再ターゲット着信要求登録時にSIP-PBXから受信した情報に応じて、<ここで、SDPボディ>。 「パス」に関連付けられた通常の処理ごとに、それは「Route」ヘッダフィールドに登録時にSIP-PBXによって示される「パス」値を挿入する、及び登録連絡先に要求URIを設定します。
INVITE sip:+12145550105@pbx.example SIP/2.0 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad Route: <sip:pbx@198.51.100.3:5060;lr> Max-Forwards: 68 To: <sip:2145550105@some-other-place.example.net> From: <sip:gsmith@example.org>;tag=456248 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b CSeq: 24762 INVITE Contact: <sip:line-1@192.0.2.178:2081> Content-Type: application/sdp Content-Length: ...
SIPのINVITE：SIP / 2.0を介して+12145550105@pbx.example：SIP / 2.0 / UDP ssp.example.com;ブランチ= z9hG4bKa45cd5c52a6dd50経由：SIP / 2.0 / UDP foo.example;ブランチ= z9hG4bKa0bc7a0131f0adルート：<SIP：pbx@198.51 .100.3：5060; LR>最大フォワード：68：<SIP：2145550105@some-other-place.example.net>から<SIP：gsmith@example.org>;タグ= 456248のCall-ID：7ca24b9679ffe9aff87036a105e30d9bのCSeq ：<SIP：line-1@192.0.2.178：2081>のContent-Type：アプリケーション/ SDPのContent-Length：24762連絡先を招待...
<sdp body here>
<ここSDPボディ>
This document registers a new SIP option tag to indicate support for the mechanism it defines, two new SIP URI parameters, and a "Contact" header field parameter. The process governing registration of these protocol elements is outlined in RFC 5727 [21].
この文書では、それが定義するメカニズム、二つの新しいSIP URIパラメータ、および「連絡先」ヘッダフィールドパラメータのサポートを示すために、新しいSIPオプションタグを登録します。これらのプロトコル要素の登録を管理するプロセスは、RFC 5727 [21]に概説されています。
This section defines a new SIP option tag per the guidelines in Section 27.1 of RFC 3261 [3].
このセクションでは、[3] RFC 3261のセクション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で複数の電話番号の登録を提供して拡張子を識別するために使用されます。ときに「要求」またはREGISTERリクエストの「プロキシは、要求」ヘッダフィールド内に存在する、それは、登録トランザクションの当事者であること、それぞれ、この拡張のサポートがレジストラとプロキシの必要とされることを示しています。
Reference: RFC 6140
参考：RFC 6140
This specification defines two new SIP URI parameters, as per the registry created by RFC 3969 [7].
この仕様は、RFC 3969によって作成されたレジストリの通り、二つの新しいSIP URIパラメータを定義する[7]。
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-クッキー
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に適用する以前に定義されたREGISTERメソッドを拡張する前例のないステップをとります。などのプロキシとして - - REGISTER取引の当事者であり、一般的には、この種の変更は、仲介者の問題を引き起こす可能性を秘めています。特に、そのような媒体は、暗黙的に登録されている複数のAORの知識なしに、「へ」ヘッダフィールド（すなわち、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.
このドキュメントによって定義されたメカニズムは、REGISTERリクエストで「プロキシ要求」ヘッダフィールドにオプションタグを追加することによって、この問題を解決します。このメカニズムの気づいていないプロキシは、ポリシーをmisapplyingからそれらを防ぐこと、要求を処理しません。このオプションタグ付き要求を処理プロキシは明らかにREGISTERリクエストの性質を認識しており、合理的な政策決定を行うことができます。
As noted in Section 7.4, intermediaries need to take care if they use a policy token in the path and service route mechanisms, as doing so will cause them to apply the same policy to all users serviced by the same SIP-PBX. This may frequently be the correct behavior, but circumstances can arise in which differentiation of user policy is required.
7.4節で述べたように、仲介は、彼らがパスとサービスルートメカニズムに方針トークンを使用している場合はそうすることが、同じSIP-PBXによってサービスのすべてのユーザーに同じポリシーを適用するためにそれらの原因となりますよう、世話をする必要があります。これはしばしば正しい動作であってもよいが、状況は、ユーザポリシーの分化が必要とされて生じ得ます。
Section 7.4 also notes that these techniques use a token or cookie in the "Path" and/or "Service-Route" header values, and that this value will be shared among all AORs associated with a single registration. Because this information will be visible to user agents under certain conditions, proxy designers using this mechanism in conjunction with the techniques described in this document need to take care that doing so does not leak sensitive information.
セクション7.4は、これらの技術は、「パス」および/または「サービス-Route」ヘッダ値のトークンまたはクッキーを使用することを指摘し、この値は、単一の登録に関連付けられているすべてのAORで共有されています。この情報は、一定の条件の下でユーザエージェントに表示されますので、この文書に記載された技術と併せて、このメカニズムを使用してプロキシ設計者は、そうすることが、機密情報を漏洩しないことに注意する必要があります。
One of the key properties of the outbound client connection mechanism discussed in Section 7.3 is the assurance that a single connection is associated with a single user and cannot be hijacked by other users. With the mechanism defined in this document, such connections necessarily become shared between users. However, the only entity in a position to hijack calls as a consequence is the SIP-PBX itself. Because the SIP-PBX acts as a registrar for all the potentially affected users, it already has the ability to redirect any such communications as it sees fit. In other words, the SIP-PBX must be trusted to handle calls in an appropriate fashion, and the use of the outbound connection mechanism introduces no additional vulnerabilities.
セクション7.3で説明したアウトバウンドクライアント接続機構の重要な特性の一つは、単一の接続を単一のユーザに関連付けられている他のユーザーによってハイジャックすることができないことの保証です。この文書で定義されたメカニズムでは、このような接続は、必ずしもユーザ間で共有となります。しかし、結果としてコールをハイジャックする位置における唯一のエンティティは、SIP-PBX自体です。 SIP-PBXは、すべての潜在的な影響を受けるユーザーのためのレジストラとして動作するので、それはすでにそれが適当と考えるような任意の通信をリダイレクトする能力を持っています。換言すれば、SIP-PBXは、適切な方法でコールを処理するために信頼されなければならない、とアウトバウンド接続機構の使用は、追加の脆弱性を導入しません。
The ability to learn the identity and registration state of every user on the PBX (as described in Section 7.2.1) is invaluable for diagnostic and administrative purposes. For example, this allows the SIP-PBX to determine whether all its extensions are properly registered with the SSP. However, this information can also be highly sensitive, as many organizations may not wish to make their entire list of phone numbers available to external entities. Consequently, SSP servers are advised to use explicit (i.e., white-list) and configurable policies regarding who can access this information, with very conservative defaults (e.g., an empty access list or an access list consisting only of the PBX itself).
PBX上のすべてのユーザーのIDと登録状態を学習する能力は、（7.2.1項で説明したように）診断および管理目的のために非常に貴重です。例えば、これは、SIP-PBXは、すべての拡張機能が正しくSSPに登録されているかどうかを決定することを可能にします。多くの組織は、外部エンティティへの電話番号の彼らの全体のリストを利用できるようにしたくないかもしれませんしかし、この情報はまた、非常に敏感である可能性があります。したがって、SSPサーバは非常に保守的なデフォルト値（例えば、空のアクセスリストのみPBX自体からなるアクセスリスト）を用いて、この情報にアクセスできるユーザーに関する明示的な（すなわち、ホワイトリスト）と設定ポリシーを使用することをお勧めします。
The procedure for the generation of temporary GRUUs requires the use of an HMAC to detect any tampering that external entities may attempt to perform on the contents of a temporary GRUU. The mention of HMAC-SHA256-80 in Section 7.1.2 is intended solely as an example of a suitable HMAC algorithm. Since all HMACs used in this document are generated and consumed by the same entity, the choice of an actual HMAC algorithm is entirely up to an implementation, provided that the cryptographic properties are sufficient to prevent third parties from spoofing GRUU-related information.
一時的GRUUsを生成するための手順は、任意の外部エンティティが一時的GRUUの内容に対して実行しようとしていること改ざんを検出するためにHMACを使用する必要があります。 7.1.2項でHMAC-SHA256-80の言及は、適切なHMACアルゴリズムの一例としてのみ意図されます。本書で使用されるすべてのHMACsが同じエンティティによって生成され、消費されるので、実際のHMACアルゴリズムの選択は、完全実装に任され、暗号化特性がGRUU関連情報をスプーフィングから第三者を防止するのに十分であることを条件とします。
The procedure for the generation of temporary GRUUs also requires the use of RSA keys. The selection of the proper key length for such keys requires careful analysis, taking into consideration the current and foreseeable speed of processing for the period of time during which GRUUs must remain anonymous, as well as emerging cryptographic analysis methods. The most recent guidance from RSA Laboratories [25] suggests a key length of 2048 bits for data that needs protection through the year 2030, and a length of 3072 bits thereafter.
一時的GRUUsを生成するための手順は、RSAキーを使用する必要があります。そのようなキーの適切なキーの長さの選択はGRUUsは匿名のままなければならない時間の期間だけでなく、新興の暗号解析手法のために考慮処理の現在及び予見可能な速度を取って、慎重な分析が必要です。 RSA研究所[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の生成に使用される秘密鍵の不正開示を防ぐために予防策を取るように警告しています。任意のそのような開示は、それらの関連のPBXに、潜在的に、互いに一時GRUUsを相関させる能力をもたらすであろう。
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）攻撃者によって利用することができる。なぜなら、このようなメッセージの処理における暗号演算の存在、 （有効または無効）する場合、攻撃者が使用するような攻撃が採用したメッセージの一時的GRUUs 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-PBXでははすぐに引退した公開鍵を破棄し、独占的に新しい公開鍵を使用しなければなりません。
This document represents the hard work of many people in the IETF MARTINI working group and the IETF RAI community as a whole. Particular thanks are owed to John Elwell for his requirements analysis of the mechanism described in this document, to Dean Willis for his analysis of the interaction between this mechanism and the "Path" and "Service-Route" extensions, to Cullen Jennings for his analysis of the interaction between this mechanism and the SIP Outbound extension, and to Richard Barnes for his detailed security analysis of the GRUU construction algorithm. Thanks to Eric Rescorla, whose text in the appendix of RFC 5627 was lifted directly to provide substantial portions of Section 7.1.2. Finally, thanks to Bernard Aboba, Francois Audet, Brian Carpenter, John Elwell, David Hancock, Ted Hardie, Martien Huysmans, Cullen Jennings, Alan Johnston, Hadriel Kaplan, Paul Kyzivat, and Radia Perlman for their careful reviews of and constructive feedback on this document.
この文書は、IETF MARTINIワーキンググループ全体としてIETF RAIコミュニティの多くの人々のハードワークを表します。特定の感謝は、彼の分析のためのカレン・ジェニングスに、このメカニズムと「パス」と「サービス・ルート」の拡張機能の間の相互作用の彼の分析のためにディーンウィリスに、このドキュメントで説明するメカニズムの彼の要求分析のために、ジョンエルウェルに負っていますGRUU構築アルゴリズムの彼の詳細なセキュリティ分析のために、このメカニズムとSIPアウトバウンド拡張、およびリチャード・バーンズとの間の相互作用の。テキストRFC 5627の付録のセクション7.1.2のかなりの部分を提供するために、直接解除されたエリックレスコラ、に感謝します。最後に、彼らの慎重なレビューと建設的なフィードバックのためのバーナードAboba、フランソワAudet、ブライアン・カーペンター、ジョンエルウェル、デビッド・ハンコック、テッドハーディー、Martien Huysmans、カレン・ジェニングス、アラン・ジョンストン、Hadrielカプラン、ポールKyzivat、およびラディア・パールマンのおかげで、この上資料。
[1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[1] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[4]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5]ローチ、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]キャマリロ、G.、BCP 98、RFC 3968、2004年12月 "セッション開始プロトコル（SIP）の番号機関（IANA）ヘッダーフィールドパラメータレジストリ割り当てインターネット"。
[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]カマリロ、G.、BCP 99、RFC 3969、2004年12月 "セッション開始プロトコル（SIP）のための番号機関（IANA）のURI（Uniform Resource Identifier）パラメータレジストリの割り当てインターネット"。
[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]、RFC 5628、2009年10月Kyzivat、P.、 "セッション開始プロトコル（SIP）グローバルにルーティング可能なユーザエージェントのURI（GRUUs）の登録イベントパッケージ拡張を"。
[10] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
"非隣接コンタクトを登録するためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド" [10]ウィリス、D.およびB. Hoeneisen、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]ウィリス、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]ローゼンバーグ、J.、 "Aセッション開始プロトコル（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]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェント能力を示します"。
[14] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[14]ローゼンバーグ、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]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、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]スパークス、R.、Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[19] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[19]ジェニングス、C.、マーイ、R.、およびF. Audet、RFC 5626、2009年10月 "セッション開始プロトコル（SIP）のクライアントが開始した接続を管理します"。
[20] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[20]ローゼンバーグ、J.、 "取得及び使用グローバルにルーティング可能なユーザエージェントのURI（GRUUs）セッション開始プロトコル（SIP）における"、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]ピーターソン、J.、ジェニングス、C.、およびR.スパークス、BCP 67、RFC 5727、2010年3月 "セッション開始プロトコル（SIP）とリアルタイムアプリケーションとインフラストラクチャ領域の変更処理"。
[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]エルウェル、J.及びH.カプラン、RFC 5947、2010年9月 "レコード（AOR）セッション開始プロトコル（SIP）で到達可能性情報の複数のアドレスのための要件"。
[23] Kaplan, H., "GIN with Literal AORs for SIP in SSPs (GLASS)", Work in Progress, November 2010.
[23]カプラン、H.、 "SSPの中のSIP（ガラス）のリテラルのAORとGIN"、進歩、2010年11月ワーク。
[24] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008, <http:// csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf>.
[24]米国国立標準技術研究所、 "セキュアハッシュ規格（SHS）"、FIPS PUB 180-3の、2008年10月、<のhttp：// csrc.nist.gov/publications/fips/fips180-3/fips180-3_final .PDF>。
[25] Kaliski, B., "TWIRL and RSA Key Size", May 2003.
[25] Kaliski、B.、 "TWIRLおよびRSAキーサイズ"、2003年5月。
Appendix A. Requirements Analysis
付録A.要件分析
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は、2人の当事者がSIP-PBXに割り当てられた電話番号のセットに合意したことにより、SSPとのトランキング配列内に入ることを可能にしなければなりません。
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 - 機構は、割り当てられた電話番号を対象SIP-PBX着信要求にルーティングするSSPを可能にするために、そのSSPで到達可能性情報をSIP-PBXを登録できるようにしなければなりません。
The requirement is satisfied.
要件が満たされています。
REQ4 - The mechanism MUST allow UAs attached to a SIP-PBX to register with the SIP-PBX for AORs based on assigned telephone numbers, in order to receive requests targeted at those telephone numbers, without needing to involve the SSP in the registration process.
REQ4 - メカニズムはSIP-PBXに取り付けられたUAが登録プロセス中SSPが関与することなく、これらの電話番号を対象の要求を受信するために、割り当てられた電話番号に基づいのAORの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 UAは、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は、SSPにそれらの要求をルーティングすることなく、独自のUAに発信し、その割り当てられた電話番号をターゲットに要求を処理することを可能にしなければなりません。
The requirement is satisfied; SIP-PBXes may recognize their own DID numbers and GRUUs, and perform on-SIP-PBX routing without sending the requests to the SSP.
要件が満たされています。 SIP-PBXではでは、独自のDID番号を認識し、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は、そのユーザエージェントへこれらの要求以降ルートできるように、内部の場合と、SIP-PBX外に発信し、SSPを介して到着その割り当てられた電話番号へのリクエストを受信することを可能にしなければなりませんこれらの電話番号への要求。
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.
要件が満たされています。パブリックGRUUsを用いた通常呼及び呼のために、DID番号は、Request URIのユーザ部分に示されています。セクション7.1.2で説明されたメカニズムを用いて構築一時GRUUsを使用してコールするために、「GR」パラメータは相関がSIP-PBXは、呼がルーティングされるべきUAれる識別するために使用できるトークンを提供します。
REQ8 - The mechanism MUST provide a means of avoiding problems due to one side using the mechanism and the other side not.
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エンティティが登録A中に示されている（すなわち、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は、REGISTER「接触」ヘッダフィールドに含まバルク番号接触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 - メカニズムは、ドメイン名やDNSにそのドメイン名を公開する機能を持っているSIP-PBXを必要とせずに動作する必要があります。
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は、REGISTER「接触」ヘッダフィールドに含まバルク番号接触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に到達するために、SSPを介してルーティングする必要が要求を含むルート要求に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.
要件は、通常のRFC 3263解決手続きを経てSSPのサーバーに解決するために外部のエンティティによって使用されるリクエストURIのドメイン名を許可することで満たされます。
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 - 機構[3]で指定されるようにSIPダイジェスト認証プラスTLSサーバー認証を使用して、例えば、SSPおよびその逆によってSIP-PBXの認証をサポートしなければなりません。
The requirement is satisfied; SIP-PBXes may employ either SIP digest authentication or mutually authenticated TLS for authentication purposes.
要件が満たされています。 SIP-のPBXは、認証のためにSIPダイジェスト認証または相互認証TLSのいずれかを使用することができます。
REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with public or temporary Globally Routable UA URIs (GRUUs) [20].
REQ16 - SIP-PBXは、公衆または一時的なグローバルにルーティング可能な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は、一般的にREGISTER要求のために使用することができる程度に満たされています。特定の拡張子及び/又はネットワークトポロジのアプリケーションは、UDP MTUサイズを超えてもよいが、そのような問題がで、この文書で説明機構なしの両方が生じます。この文書では、このような問題を悪化させていません。
REQ18 - Documentation MUST give guidance or warnings about how authorization policies may be affected by the mechanism, to address the problems described in Section 3.3 [of RFC 5947].
REQ18 - ドキュメント[RFC 5947の]認可ポリシーは、3.3節で説明した問題に対処するために、メカニズムによって影響を受ける可能性がある方法についての指導や警告を与える必要があります。
These issues are addressed at length in Section 10, as well as summarized in Section 7.4.
これらの問題は、セクション10の長さで対処だけでなく、7.4節にまとめられています。
REQ19 - The mechanism MUST be extensible to allow a set of assigned telephone numbers to comprise local numbers as specified in RFC 3966 [15], which can be in contiguous ranges, discrete, or in any combination of the two.
REQ19は、 - 連続する範囲、別個に、またはこれらの任意の組み合わせであり得る、RFC 3966 [15]で指定されるように機構がローカル番号を含むように割り当てられた電話番号のセットを可能にするために拡張可能でなければなりません。
Assignment of telephone numbers to a registration is performed by the SSP's registrar, which is not precluded from assigning local numbers in any combination it desires.
登録する電話番号の割り当ては、それが望む任意の組み合わせでローカル番号を割り当てることを妨げていないSSPのレジストラによって行われます。
REQ20 - The mechanism MUST be extensible to allow a set of arbitrarily assigned SIP URI's as specified in RFC 3261 [3], as opposed to just telephone numbers, without requiring a complete change of mechanism as compared to that used for telephone numbers.
REQ20 - 機構としてRFC 3261で指定された任意に割り当てられたSIP URIのセットを可能にするように拡張可能でなければなりません[3]は、電話番号のために使用されるものと比べて機構の完全な変更を必要とせず、単に電話番号とは対照的です。
The mechanism is extensible in such a fashion, as demonstrated by the document "GIN with Literal AoRs for SIP in SSPs (GLASS)" [23].
機構は、文書「のSSPにおけるSIPのリテラルのAORとGIN（GLASS）」[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-のPBXへのSIPトランキングサービスを提供するために、通常のUAにSIPサービスを提供するためのメカニズムを利用することを可能にするべきです。
The desired property is satisfied; the routing mechanism described in this document is identical to the routing performed for singly registered AORs.
所望の特性を満足しています。この文書に記載されたルーティングメカニズムは、単独で、登録のAORに対して実行ルーティングと同一です。
DES2 - The mechanism SHOULD scale to SIP-PBXes of several thousand assigned telephone numbers.
DES2 - メカニズムは数千割り当てられた電話番号の-PBXではをSIPに拡大すべきです。
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 - メカニズムは、数千のSIP-PBXのシングルSSP上をサポートするように拡張すべきです。
The desired property is satisfied; nothing in this document precludes an arbitrary number of SIP-PBXes from attaching to a single SSP.
所望の特性を満足しています。この文書に記載されているものは、単一のSSPに付着するSIP-PBXでは、任意の数を排除しません。
Author's Address
著者のアドレス
Adam Roach Tekelec 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US
アダムローチTekelec 17210キャンベルRdを。スイート250、ダラス、TX 75252米国
EMail: adam@nostrum.com
メールアドレス：adam@nostrum.com