[要約] RFC 7329は、SIPセッションの識別子を定義し、セッションの管理と追跡を容易にするための方法を提供します。このRFCの目的は、SIPベースの通信システムの効率と信頼性を向上させることです。
Internet Engineering Task Force (IETF) H. Kaplan
Request for Comments: 7329 Oracle
Category: Informational August 2014
ISSN: 2070-1721
A Session Identifier for the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）のセッション識別子
Abstract
概要
There is a need for having a globally unique session identifier for the same SIP session that can be consistently maintained across SIP Proxies, Back-to-Back User Agents (B2BUAs), and other SIP middleboxes, for the purpose of troubleshooting. This document proposes a new SIP header to carry such a value: Session-ID.
トラブルシューティングの目的で、SIPプロキシ、バックツーバックユーザーエージェント（B2BUA）、およびその他のSIPミドルボックス全体で一貫して維持できる、同じSIPセッションのグローバルに一意のセッションIDが必要です。このドキュメントはそのような値を運ぶために新しいSIPヘッダーを提案します：セッションID。
The mechanism defined in this document has been widely deployed, and is being followed in a backward-compatible fashion for a new Standards Track document produced by the INSIPID Working Group.
このドキュメントで定義されているメカニズムは広く展開されており、INSIPIDワーキンググループによって作成された新しいStandards Trackドキュメントに対して下位互換性のある方法でフォローされています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7329.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7329で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements ...............................................4
2. Terminology .....................................................4
3. Overview of Operation ...........................................4
4. Session-ID Behavior .............................................5
4.1. Generating a Session-ID Value ..............................5
4.2. UAC Behavior ...............................................6
4.3. UAS Behavior ...............................................6
4.4. Proxy Behavior .............................................6
4.5. B2BUA Behavior .............................................7
4.5.1. B2BUA Generation of New Session-ID ..................8
4.5.2. B2BUA Insertion of Saved Session-ID .................8
5. Handling SIP Transfer Scenarios .................................8
5.1. Out-of-Dialog REFER ........................................9
5.2. Refer-To URI ...............................................9
5.3. Out-of-Dialog INVITE with Replaces .........................9
6. Session-ID Migration and Failure Scenarios .....................10
7. New 'Session-ID' Header ........................................11
7.1. Augmented BNF Definitions .................................11
8. Example Exchange ...............................................11
9. Security Considerations ........................................11
9.1. Security Considerations for Administrators ................12
9.2. Security Considerations for Session-ID Extensions .........12
10. IANA Considerations ...........................................13
11. Acknowledgments ...............................................13
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................14
Appendix A. Use Cases Not in Scope for Session-ID .................15
A.1. Dialog Correlation for SIP ................................15
This RFC, which contains the text of an individual Internet-Draft that was submitted originally to the DISPATCH Working Group, is being published now as an Informational document to provide a reference for later RFCs. The mechanism defined in this document has been widely deployed and is being followed in a backward-compatible fashion for a new Standards Track document produced by the INSIPID Working Group.
DISPATCHワーキンググループに最初に提出された個々のインターネットドラフトのテキストを含むこのRFCは、後のRFCのリファレンスを提供する情報ドキュメントとして現在公開されています。このドキュメントで定義されているメカニズムは広く展開されており、INSIPIDワーキンググループによって作成された新しいStandards Trackドキュメントに対して下位互換性のある方法でフォローされています。
The SIP [RFC3261] Call-ID header value is a globally unique identifier, which is mandatory in all requests/responses and identifies SIP messages belonging to the same dialog or registration. It provides a portion of the SIP message dialog-matching criteria and is used in such things as "Replaces" headers [RFC3891] and dialog-event packages [RFC4235] for matching to dialogs, and in SIP Identity [RFC4474] and Connected Identity [RFC4916] as one of the inputs for signing.
SIP [RFC3261] Call-IDヘッダー値は、グローバルに一意の識別子です。これは、すべての要求/応答で必須であり、同じダイアログまたは登録に属するSIPメッセージを識別します。これは、SIPメッセージのダイアログ一致基準の一部を提供し、ダイアログに一致するための「置換」ヘッダー[RFC3891]やダイアログイベントパッケージ[RFC4235]などで使用されます。また、SIP ID [RFC4474]および接続ID [ RFC4916]を署名の入力の1つとして使用します。
In practice, the Call-ID is often changed by SIP Back-to-Back User Agents (B2BUAs) and other such middleboxes in the logical end-to-end message path. A B2BUA logically represents a SIP User Agent Server (UAS) and User Agent Client (UAC), and as such generates a new Call-ID value for the dialog it creates on its UAC side; in fact, for some B2BUA scenarios the Call-ID *must* be changed for SIP to function properly.
実際には、Call-IDは多くの場合、SIPバックツーバックユーザーエージェント（B2BUA）および論理的なエンドツーエンドのメッセージパス内の他のミドルボックスによって変更されます。 B2BUAは、SIPユーザーエージェントサーバー（UAS）とユーザーエージェントクライアント（UAC）を論理的に表し、UAC側で作成するダイアログの新しいCall-ID値を生成します。実際、一部のB2BUAシナリオでは、SIPが正しく機能するようにCall-IDを変更する必要があります。
At the same time, there is a need for a unique, common, consistent end-to-end identifier to help troubleshoot SIP sessions and message flows as they cross SIP nodes. Troubleshooting is more complicated if multiple legs of the session are on different sides of B2BUAs, due to the lack of a common identifier such as a Call-ID to tie the legs together. Proprietary mechanisms are currently used to achieve this goal.
同時に、SIPセッションとメッセージフローがSIPノードを通過するときのトラブルシューティングに役立つ、一意で共通の一貫したエンドツーエンドの識別子が必要です。セッションの複数のレッグがB2BUAの異なる側にある場合、レッグを結合するためのCall-IDなどの一般的な識別子がないため、トラブルシューティングはさらに複雑になります。現在、この目的を達成するために独自のメカニズムが使用されています。
Therefore, in order to provide an identifier that will not be modified/replaced by B2BUAs, this document proposes a new SIP Header "Session-ID" and mandatory rules for the value of such a header. The rules are designed to be such that the value in the Session-ID header is not considered unsafe or private and does not have any property that would cause B2BUAs to change it. The goal of this document is to enable troubleshooting by providing a unique identifier for a given session that can successfully cross B2BUAs, such as Application Servers, softswitches, Private Branch Exchanges (PBXs), Session Border Controllers (SBCs), feature servers, etc.
したがって、B2BUAによって変更または置換されない識別子を提供するために、このドキュメントでは、新しいSIPヘッダー「Session-ID」とそのようなヘッダーの値の必須ルールを提案します。ルールは、Session-IDヘッダーの値が安全ではない、またはプライベートであると見なされず、B2BUAに値を変更させるプロパティがないように設計されています。このドキュメントの目的は、アプリケーションサーバー、ソフトスイッチ、構内交換機（PBX）、セッションボーダーコントローラー（SBC）、機能サーバーなど、B2BUAを正常に通過できる特定のセッションに一意の識別子を提供することにより、トラブルシューティングを可能にすることです。
The following requirements drive the need for Session-ID:
以下の要件により、Session-IDが必要になります。
REQ1: It must be possible for an administrator to use the identifier to identify a set of dialogs that have a direct correlation with each other such that they represent the same SIP session, with as high a probability as possible.
REQ1：管理者が識別子を使用して、可能な限り高い確率で同じSIPセッションを表すように互いに直接相関しているダイアログのセットを識別することが可能でなければなりません。
REQ2: It must be possible to pass the identifier through SIP B2BUAs, with as high a probability as possible. This requirement drives the following requirements:
REQ2：可能な限り高い確率で、SIP B2BUAを通じて識別子を渡すことが可能でなければなりません。この要件により、次の要件が発生します。
REQ2a: The identifier must not reveal any information related to any SIP device or domain identity, including IP address, port, hostname, domain name, username, Address-of-Record (AoR), MAC address, IP address family, transport type, etc.
REQ2a：識別子は、IPアドレス、ポート、ホスト名、ドメイン名、ユーザー名、レコードのアドレス（AoR）、MACアドレス、IPアドレスファミリー、トランスポートタイプなど、SIPデバイスまたはドメインIDに関連する情報を明らかにしてはなりません。等
REQ2b: The identifier must not reveal to the receiver of it that the Call-ID, tags, or any other SIP header or body portion have been changed by middleboxes, with as high a probability as possible.
REQ2b：識別子は、Call-ID、タグ、またはその他のSIPヘッダーまたは本文の部分がミドルボックスによって変更された可能性が高いことを受信者に明らかにしてはなりません。
REQ2c: The identifier must not be used for anything at a SIP layer to change the behavior of the SIP protocol.
REQ2c：SIPプロトコルの動作を変更するために、SIP層で何にも識別子を使用しないでください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses the terms "header field" and "header field value" following the definition of those terms in [RFC3261]; they are not interchangeable. The "header field" is the entire SIP header's contents, including any parameters. The "header field value" is only the field-value portion, which does not include header parameters.
このドキュメントでは、[RFC3261]での用語の定義に従って、「ヘッダーフィールド」および「ヘッダーフィールド値」という用語を使用しています。互換性はありません。 「ヘッダーフィールド」は、パラメータを含むSIPヘッダーの内容全体です。 「ヘッダーフィールド値」はフィールド値の部分のみで、ヘッダーパラメーターは含まれません。
The general concept is that the UAC generating an out-of-dialog request generates a new, pseudorandom, unique value that remains constant for the duration of the transaction, any dialog created from that request, or for a registration. The value is inserted in a new Session-ID header field defined in this document. The UAC and UAS then reflect this header field value in all messages for the duration of the dialog. In other words, the Session-ID provides a value similar in nature to Call-ID, except one that crosses B2BUAs and that has no sensitive information in it.
一般的な概念は、ダイアログ外の要求を生成するUACは、トランザクション、その要求から作成されたダイアログ、または登録の間、一定の新しい疑似ランダムな一意の値を生成することです。値は、このドキュメントで定義されている新しいセッションIDヘッダーフィールドに挿入されます。 UACとUASは、ダイアログの期間中、すべてのメッセージにこのヘッダーフィールド値を反映します。言い換えると、Session-IDは、B2BUAを通過し、機密情報を持たないものを除いて、Call-IDと本質的に同じ値を提供します。
To aid in migration of deployments, a B2BUA or Proxy MAY also generate and/or insert the value on behalf of a UAC or UAS, if one or the other does not support this document's mechanism.
デプロイメントの移行を支援するために、B2BUAまたはプロキシは、どちらかがこのドキュメントのメカニズムをサポートしていない場合、UACまたはUASに代わって値を生成または挿入する場合があります。
Although the Session-ID concept is similar to that of Call-ID, it is not used for message dialog-matching rules in RFC 3261, nor does it change the Call-ID usage, nor does it replace the Call-ID value. Instead, this new header field provides an identifier for troubleshooting uses only.
セッションIDの概念はコールIDの概念と似ていますが、RFC 3261のメッセージダイアログマッチングルールには使用されません。また、コールIDの使用法を変更したり、コールID値を置き換えたりすることもありません。代わりに、この新しいヘッダーフィールドは、トラブルシューティング用の識別子のみを提供します。
The format of the Session-ID value is restricted, both to avoid detection of the system type that generated it and to keep it a hexadecimal representation such that it can be stored as a 128-bit binary value in log records.
セッションID値の形式は、それを生成したシステムタイプの検出を回避するため、およびログレコードに128ビットのバイナリ値として格納できるように16進表記を維持するために制限されています。
This document proposes the Session-ID header value be generated based on a defined hash mechanism for creating a 128-bit pseudorandom value and be encoded as its lowercase hex representation. The reason for specifying the mechanism is twofold: to make it impossible to determine the manufacturer of the device that generated it by looking at its format or value, and to allow devices to generate the same value if they have the same private key.
このドキュメントでは、128ビットの疑似ランダム値を作成するために定義されたハッシュメカニズムに基づいて生成され、小文字の16進表記としてエンコードされるセッションIDヘッダー値を提案しています。メカニズムを指定する理由は2つあります。フォーマットまたは値を見て、それを生成したデバイスの製造元を判別できないようにすることと、デバイスが同じ秘密鍵を持っている場合、デバイスが同じ値を生成できるようにすることです。
The Session-ID value is generated by taking the Call-ID header value and SHA-1 hashing it based on HMAC (as defined in [RFC2104]) using a locally generated pseudorandom 128-bit system secret key to create a 128-bit resultant HMAC value. The secret key makes the resultant HMAC value not re-creatable by other parties; this is necessary to prevent detection of Call-IDs being changed, as required by REQ2b. Otherwise, middleboxes may have motivation to remove the Session-ID in order to hide the fact that they changed the Call-ID.
セッションID値は、ローカルで生成された疑似ランダム128ビットシステムの秘密鍵を使用してHMAC（[RFC2104]で定義）に基づいてCall-IDヘッダー値とSHA-1ハッシュを取得することにより生成され、128ビットの結果を作成します。 HMAC値。秘密鍵は、結果のHMAC値を他の関係者が再作成できないようにします。これは、REQ2bで要求されているように、変更されているCall-IDの検出を防ぐために必要です。そうでない場合、ミドルボックスは、Call-IDを変更したという事実を隠すために、Session-IDを削除する動機を持っている可能性があります。
Per [RFC2104], the algorithm is thus HMAC-SHA-1-128(Call-ID_value, secret_key), and the 128-bit result is encoded using lowercase alphanumeric hex representation, as defined in Section 7.1 ("Augmented BNF Definitions").
[RFC2104]に従って、アルゴリズムはHMAC-SHA-1-128（Call-ID_value、secret_key）であり、128ビットの結果は、セクション7.1（「拡張BNF定義」）で定義されている小文字の英数字16進表記を使用してエンコードされます。 。
In order to enable troubleshooting of in-dialog messages, a generator needs to remember or re-create the same Session-ID value for the duration of a given dialog(s). This is described in more detail in the subsequent sections of this document.
ダイアログ内メッセージのトラブルシューティングを可能にするために、ジェネレーターは、特定のダイアログの期間中、同じSession-ID値を記憶または再作成する必要があります。これについては、このドキュメントの後続のセクションで詳しく説明します。
The rules for when a UAC generates a new Session-ID value are similar as those for Call-ID value: a UAC supporting this document's mechanism MUST generate a new unique Session-ID value when it generates an out-of-dialog request or when there is a new Registration. The exception to this rule is for out-of-dialog REFER requests or for an INVITE with a Replaces header field (see [RFC3891]), as described in Section 5.
UACが新しいSession-ID値を生成するときの規則は、Call-ID値の規則と同様です。このドキュメントのメカニズムをサポートするUACは、ダイアログ外の要求を生成するとき、または新しい登録があります。このルールの例外は、セクション5で説明されているように、ダイアログ外のREFERリクエスト、またはReplacesヘッダーフィールドを持つINVITE（[RFC3891]を参照）の場合です。
The UAC MUST reuse the same Session-ID value for in-dialog messages as that of the original dialog-creating request, and for any out-of-dialog request that it retransmits or re-generates in response to a 3xx that it reformulates due to failure responses. This follows the rules in [RFC3261] for Call-ID generation.
UACは、元のダイアログ作成要求と同じダイアログID値、および3xxに応じて再送信または再生成するダイアログ外要求に対して、再フォーマットする必要がある同じセッションID値を再利用する必要があります（MUST）失敗応答へ。これは、[RFC3261]のCall-ID生成の規則に従います。
Session-ID values in Registration "refreshes" -- REGISTER requests that are used to update the expiry time but not to register a new contact -- MUST use the same Session-ID value as previous REGISTER requests. New Registrations, which add or change the Contact URI for the AoR, but do not simply delete them, MUST use a new Session-ID value. This follows the behavior of Call-ID per RFC 3261; it is reiterated here because some devices incorrectly change their Call-ID value for every re-Registration, and they MUST NOT do the same to the Session-ID.
Registration "refreshes"のSession-ID値-有効期限の更新に使用されるが、新しい連絡先の登録には使用されないREGISTERリクエスト-以前のREGISTERリクエストと同じSession-ID値を使用する必要があります。 AoRの連絡先URIを追加または変更するが、単に削除するだけではない新しい登録では、新しいSession-ID値を使用する必要があります。これはRFC 3261のCall-IDの動作に従います。一部のデバイスは再登録ごとにCall-ID値を誤って変更し、Session-IDに対して同じことを行ってはならないため、ここで繰り返します。
The UAC MUST include the Session-ID header field in every SIP message it transmits.
UACは、送信するすべてのSIPメッセージにセッションIDヘッダーフィールドを含める必要があります。
A UAS compliant with this document MUST copy a Session-ID header field (received in a request) into responses and subsequent upstream requests sent within the dialog.
このドキュメントに準拠するUASは、Session-IDヘッダーフィールド（リクエストで受信）を、ダイアログ内で送信される応答および後続のアップストリームリクエストにコピーする必要があります。
If an out-of-dialog request is received without a Session-ID header field, the UAS SHOULD generate a new one for subsequent use in the transaction and dialog, as defined for a UAC, and use the same value in all responses and upstream in-dialog requests for the same dialog.
Session-IDヘッダーフィールドなしでダイアログ外リクエストが受信された場合、UASは、UACに定義されているように、トランザクションおよびダイアログでの後続の使用のために新しいリクエストを生成し、すべての応答とアップストリームで同じ値を使用する必要があります（SHOULD）同じダイアログのダイアログ内リクエスト。
A Proxy MUST NOT remove or modify the Session-ID header field it receives, if one is in the message. By definition, a Proxy that is compliant with RFC 3261 would not modify or remove such a header.
プロキシは、メッセージ内にある場合、受信するSession-IDヘッダーフィールドを削除または変更してはなりません（MUST NOT）。定義上、RFC 3261に準拠するプロキシは、このようなヘッダーを変更または削除しません。
If the Proxy forks a request, it MUST copy the same Session-ID header field into all the forked request copies. If the Proxy recurses requests due to 3xx redirection, or regenerates requests due to failures, it MUST use the same Session-ID header field as the original request, just as the UAC does.
プロキシがリクエストをフォークする場合、同じセッションIDヘッダーフィールドをすべてのフォークされたリクエストコピーにコピーする必要があります。プロキシが3xxリダイレクションのために要求を再帰する場合、または障害のために要求を再生成する場合、UACと同様に、元の要求と同じSession-IDヘッダーフィールドを使用する必要があります。
If the Proxy locally generates any response or request based on a received request, including 100 Trying, it MUST insert any received Session-ID header field from the original request into the response message it locally creates. This is necessary for troubleshooting purposes.
プロキシは、100回の試行を含め、受信した要求に基づいて応答または要求をローカルで生成する場合、受信したセッションIDヘッダーフィールドを元の要求からローカルで作成する応答メッセージに挿入する必要があります。これはトラブルシューティングのために必要です。
A Proxy compliant with this document MAY generate a new Session-ID or insert a previously saved one if and only if none existed in a received message, following the rules for doing so as a B2BUA as defined in Section 4.5.
このドキュメントに準拠するプロキシは、セクション4.5で定義されているB2BUAとしてのルールに従って、受信したメッセージに何も存在しない場合にのみ、新しいセッションIDを生成するか、以前に保存されたものを挿入する場合があります。
A B2BUA compliant with this document MUST copy:
このドキュメントに準拠するB2BUAは、以下をコピーする必要があります。
- the Session-ID header field it receives in requests as a UAS into the related requests it generates as a UAC, and
- UASとしてリクエストで受信するSession-IDヘッダーフィールドと、UACとして生成する関連リクエスト
- any Session-ID header field it receives in responses as a UAC into the correlated responses it generates as a UAS.
- UASとして生成する相関応答へのUACとして応答で受信する任意のセッションIDヘッダーフィールド。
If the B2BUA forks or creates multiple requests as a UAC, from a request it received as a UAS, the B2BUA MUST copy the same Session-ID header field it received into all the forks/requests. If the B2BUA recurses on 3xx responses, or regenerates requests due to failures, it MUST use the same Session-ID field, just as the UAC does.
B2BUAがUACとして複数のリクエストをフォークまたは作成する場合、UASとして受信したリクエストから、B2BUAは受信した同じセッションIDヘッダーフィールドをすべてのフォーク/リクエストにコピーする必要があります。 B2BUAが3xx応答で再帰する場合、または障害のために要求を再生成する場合は、UACと同じように、同じSession-IDフィールドを使用する必要があります。
If the B2BUA locally generates any response or request based on a received request, including 100 Trying, it MUST insert any received Session-ID field from the original request into the response message it locally creates.
B2BUAが100トライイングを含む受信した要求に基づいて応答または要求をローカルで生成する場合、元の要求から受信したセッションIDフィールドをローカルで作成する応答メッセージに挿入する必要があります。
A B2BUA MAY remember the received Session-ID value for the duration of the transaction and dialog, for the purpose of reinsertion, in case the far end does not support this document.
B2BUAは、遠端がこのドキュメントをサポートしていない場合に備えて、再挿入の目的で、トランザクションおよびダイアログの期間中に受信したSession-ID値を記憶する場合があります。
In all cases, if the SIP message received by a B2BUA contains a Session-ID header field, a B2BUA compliant with this document MUST NOT remove, modify, or replace it as it "forwards" the message on the other logical UA "side" of itself.
すべての場合において、B2BUAによって受信されたSIPメッセージにSession-IDヘッダーフィールドが含まれている場合、このドキュメントに準拠するB2BUAは、他の論理UAの「サイド」でメッセージを「転送」するため、これを削除、変更、または置き換えてはなりません（MUST NOT）。それ自体の。
If an out-of-dialog request is received by a B2BUA compliant with this document, and the request does *not* contain a Session-ID header field, the B2BUA MAY generate a new one. The new Session-ID value MUST be calculated based on the received Call-ID of the received request, even if the B2BUA uses a different Call-ID value for requests generated on its other "side(s)". It MUST then insert the new Session-ID in any requests or responses it generates, as if it had actually received the new Session-ID from the UAC, following the rules previously defined for a B2BUA. This allows for a B2BUA to provide a migration to Session-ID deployment, on behalf of upstream nodes that do not yet support it.
このドキュメントに準拠したB2BUAがダイアログ外のリクエストを受信し、そのリクエストにSession-IDヘッダーフィールドが*含まれていない*場合、B2BUAは新しいフィールドを生成してもよい（MAY）。 B2BUAが他の「サイド」で生成されたリクエストに異なるCall-ID値を使用している場合でも、新しいセッションID値は、受信したリクエストの受信したCall-IDに基づいて計算する必要があります。次に、B2BUAに対して以前に定義された規則に従って、UACから新しいセッションIDを実際に受信したかのように、生成するすべての要求または応答に新しいセッションIDを挿入する必要があります。これにより、B2BUAは、まだサポートしていない上流ノードに代わって、Session-IDデプロイメントへの移行を提供できます。
As defined previously, if any received message already had a Session-ID, a B2BUA compliant with this document would not replace it.
以前に定義したように、受信したメッセージにすでにセッションIDが含まれている場合、このドキュメントに準拠するB2BUAはそれを置き換えません。
If a Session-ID was received in an out-of-dialog request, or the B2BUA locally generated one because none existed, the B2BUA SHOULD insert the same Session-ID field into all responses and upstream in-dialog requests if and only if a Session-ID is not already in them. This allows for a B2BUA to provide a migration to Session-ID deployment on behalf of downstream nodes that do not yet support it.
ダイアログ外リクエストでセッションIDが受信された場合、またはB2BUAが存在しないためにローカルで生成された場合、B2BUAは、すべての応答とアップストリームのダイアログリクエストに同じセッションIDフィールドを挿入する必要があります。セッションIDはまだ含まれていません。これにより、B2BUAは、まだサポートしていないダウンストリームノードに代わって、Session-ID展開への移行を提供できます。
The transfer or movement of SIP sessions represents a complication for a mechanism like Session-ID. On the one hand, the replacement SIP session represents a new one and could reasonably be expected to use a new Session-ID value; on the other hand, from a troubleshooting and human-user perspective, it is clearly related to, if not just a continuation of, the previous session. Since the purpose of this document's mechanism is to aid monitoring and troubleshooting, and it's not used for actual SIP protocol mechanics, the behavior defined in this section is to reuse the same Session-ID value for the replacement SIP session.
SIPセッションの転送または移動は、Session-IDのようなメカニズムの複雑さを表しています。一方では、置換SIPセッションは新しいものを表しており、新しいSession-ID値を使用することが合理的に期待できます。一方、トラブルシューティングと人間のユーザーの観点から、それは明らかに、前のセッションの継続ではなくても、前のセッションに関連しています。このドキュメントのメカニズムの目的は監視とトラブルシューティングを支援することであり、実際のSIPプロトコルメカニズムでは使用されないため、このセクションで定義されている動作は、置換SIPセッションに同じSession-ID値を再利用することです。
In order to do so, the Session-ID of the "original" session is transferred as well, in the Refer-To URI of a REFER request as described in [RFC3515]. Furthermore, out-of-dialog REFER and INVITE with Replaces requests as described in [RFC3891] use the appropriate Session-ID values. This assumes, of course, that the UAs involved support the Session-ID mechanism. If they do not, then it is possible for the Session-ID to not be "carried forward" to the new SIP dialog. Unfortunately, this means troubleshooting such dialogs is not improved or aided by this document's mechanism; but, it would not "break" anything at a SIP layer.
そうするために、「元の」セッションのSession-IDも、[RFC3515]で説明されているように、REFERリクエストのRefer-To URIで転送されます。さらに、[RFC3891]で説明されているように、ダイアログ外のREFERおよびINVITE with Replacesリクエストは、適切なSession-ID値を使用します。もちろん、これは、関与するUAがセッションIDメカニズムをサポートしていることを前提としています。そうでない場合、Session-IDが新しいSIPダイアログに「持ち越されない」可能性があります。残念ながら、これは、このようなダイアログのトラブルシューティングが、このドキュメントのメカニズムによって改善または支援されていないことを意味します。ただし、SIPレイヤーでは何も「破壊」されません。
It should also be noted that using the same Session-ID for the transferred-to dialog means the same Session-ID now exists in two independent dialogs, because the original one may well continue due to the implicit Subscription usage created by a REFER. That implicit Subscription-based usage will continue to use the same Session-ID as the new dialog created to the transferred-to party.
転送先ダイアログに同じセッションIDを使用すると、REFERによって作成された暗黙的なサブスクリプションの使用により、元のダイアログが継続する可能性があるため、2つの独立したダイアログに同じセッションIDが存在するようになることにも注意してください。その暗黙のサブスクリプションベースの使用は、転送先に作成された新しいダイアログと同じセッションIDを引き続き使用します。
In the following subsections, the term "UA" is used for User Agent. The language applies to the SIP device that creates the request, whether it be a UA or B2BUA.
以下のサブセクションでは、「UA」という用語はユーザーエージェントに使用されます。言語は、UAであろうとB2BUAであろうと、要求を作成するSIPデバイスに適用されます。
A UA compliant with this document MUST use the same Session-ID header field value for an out-of-dialog REFER request it generates, as the original dialog the REFER is targeted to (i.e., as if the REFER had been in-dialog). For example, if UA Bob has a SIP dialog X to Alice, and Bob sends an out-of-dialog REFER to Alice to refer her to Charlie, the Session-ID header field value of the REFER request would be the same as that used in dialog X.
このドキュメントに準拠するUAは、REFERが対象とする元のダイアログとして（つまり、REFERがダイアログ内にあるかのように）、それが生成するダイアログ外REFERリクエストに対して同じSession-IDヘッダーフィールド値を使用する必要があります（MUST） 。たとえば、UA BobがSIPダイアログXをAliceに持ち、Bobがダイアログ外のREFERをAliceに送信して彼女をCharlieに参照させる場合、REFER要求のSession-IDヘッダーフィールド値は、使用されているものと同じになります。ダイアログXで
A UA compliant with this document MUST add the Session-ID header field as an embedded header in the Refer-To header field URI of any REFER request it generates, using the value of the session it is referring to. For example, if UA Bob has a SIP dialog X to Alice and dialog Y to Charlie, and Bob sends a REFER request to Alice to refer her to Charlie, the Session-ID header field value embedded in the Refer-To URI of the REFER request would be the same as that used in dialog Y.
このドキュメントに準拠するUAは、参照しているセッションの値を使用して、生成するすべてのREFERリクエストのRefer-ToヘッダーフィールドURIに埋め込みヘッダーとしてSession-IDヘッダーフィールドを追加する必要があります。たとえば、UAボブにSIPダイアログXからアリスおよびダイアログYからチャーリーがあり、ボブがREFER要求をアリスに送信して彼女をチャーリーに紹介する場合、REFERのRefer-To URIに埋め込まれたセッションIDヘッダーフィールド値リクエストはダイアログYで使用されるリクエストと同じになります。
When generating an out-of-dialog INVITE with a Replaces header field as described in [RFC3891], a UA compliant with this document MUST use the same Session-ID header field value for the INVITE request as that used for the dialog it is replacing, if it knows the value. Typically, the UA would know the value by having received it in the Refer-To header field of a REFER, as described previously. For example, if UA Bob has a SIP dialog X to Alice and dialog Y to Charlie, and Bob sends a REFER request to Alice to refer her to Charlie, the Session-ID header field value embedded in the Refer-To URI of the REFER request would be the one used in dialog Y, which Alice would use as the Session-ID header field value for her INVITE to Charlie.
[RFC3891]で説明されているように、Replacesヘッダーフィールドを使用してダイアログ外のINVITEを生成する場合、このドキュメントに準拠するUAは、置換するダイアログに使用されるものと同じSession-IDヘッダーフィールド値をINVITEリクエストに使用する必要があります。 、値がわかっている場合。通常、UAは、前述のように、REFERのRefer-Toヘッダーフィールドで値を受信することで値を認識します。たとえば、UAボブにSIPダイアログXからアリスおよびダイアログYからチャーリーがあり、ボブがREFER要求をアリスに送信して彼女をチャーリーに紹介する場合、REFERのRefer-To URIに埋め込まれたセッションIDヘッダーフィールド値リクエストはダイアログYで使用されるリクエストであり、アリスは彼女のINVITEからチャーリーへのセッションIDヘッダーフィールド値として使用します。
If the UA does not know the Session-ID of the dialog it is replacing, for example, because it is not embedded in the Refer-To URI of a received REFER, then it MUST use a new Session-ID value, calculated using the mechanism as defined in Section 4.1 with the Call-ID of the INVITE.
たとえば、受け取ったREFERのRefer-To URIに埋め込まれていないなど、UAが置き換えるダイアログのSession-IDをUAが認識していない場合、UAは、次を使用して計算された新しいSession-ID値を使用する必要があります。 INVITEのCall-IDを使用してセクション4.1で定義されているメカニズム。
SIP is already widely deployed on the Internet, and it is impractical to expect all UAs to be upgraded to support this document's mechanism in the near future. A solution for gradual migration is necessary and is provided by this document by allowing B2BUAs or Proxies to perform the Session-ID generator and inserter role. Even within those device types, it is impractical to expect all B2BUAs to support this mechanism all at once or any time in the near future. Therefore, it is expected that some B2BUAs and/or UAs will support generating and inserting Session-ID, while others will not support Session-ID at all.
SIPはすでにインターネット上で広く展開されており、近い将来にすべてのUAがこのドキュメントのメカニズムをサポートするようにアップグレードされることを期待することは現実的ではありません。段階的な移行のためのソリューションが必要であり、B2BUAまたはプロキシがセッションIDジェネレーターとインサーターの役割を実行できるようにすることで、このドキュメントによって提供されます。これらのデバイスタイプ内でも、すべてのB2BUAがこのメカニズムを一度に、または近い将来いつでもサポートすることを期待することは現実的ではありません。したがって、一部のB2BUAやUAはSession-IDの生成と挿入をサポートしますが、他のB2BUAはSession-IDをまったくサポートしません。
Due to the varying types of B2BUAs (such as PBXs, SBCs, Application Servers, feature servers, and softswitches of various flavors) and the numerous SIP deployment models in use, there are going to be cases in which Session-ID will fail to be a consistent value for all related dialogs or fail to successfully match. The goal of this document is to improve troubleshooting of current deployments as much as possible -- and, in this author's opinion, that is the best that can be done given the constraints.
さまざまな種類のB2BUA（PBX、SBC、アプリケーションサーバー、機能サーバー、さまざまなフレーバーのソフトスイッチなど）と多数のSIP配置モデルが使用されているため、Session-IDが失敗する場合があります関連するすべてのダイアログに一貫した値があるか、正常に一致しない。このドキュメントの目的は、現在の展開のトラブルシューティングを可能な限り改善することです。そして、この著者の意見では、これは制約を前提として実行できる最善の方法です。
One example is for forked requests: if a UAC that does not support this mechanism sends a request to a Proxy or B2BUA that also does not support this mechanism, each fork could reach B2BUAs or UASs that *do* support this mechanism. In such a case, each of those forked-to B2BUA/UAS will generate unique Session-IDs and put them in their responses, temporarily leading to multiple, different Session-ID values for the same related early dialogs. Typically, the UAC would eventually only accept one of the dialogs, and only one Session-ID would remain.
1つの例はフォークされたリクエストの場合です。このメカニズムをサポートしないUACがこのメカニズムもサポートしないプロキシまたはB2BUAにリクエストを送信すると、各フォークはこのメカニズムをサポートするB2BUAまたはUASに到達できます。そのような場合、B2BUA / UASに分岐されたそれぞれが一意のセッションIDを生成してそれらを応答に入れ、一時的に、同じ関連する初期ダイアログの複数の異なるセッションID値につながります。通常、UACは最終的に1つのダイアログのみを受け入れ、1つのセッションIDのみが残ります。
This document adds the "Session-ID" token to the definition of the element "message-header" in the SIP message grammar. The Session-ID header is a single-instance header.
このドキュメントでは、SIPメッセージ文法の要素「message-header」の定義に「Session-ID」トークンを追加しています。 Session-IDヘッダーは単一インスタンスのヘッダーです。
Session-ID = "Session-ID" HCOLON sess-id
*( SEMI generic-param )
sess-id = 32(DIGIT / %x61-66) ; 32 chars of [0-9a-f]
NOTE: The sess-id value is technically case-INSENSITIVE, but only lowercase characters are allowed.
注：sess-id値は技術的には大文字小文字を区別しませんが、使用できるのは小文字のみです。
See the Security Considerations section for discussion about using header parameters in Session-ID header fields.
セッションIDヘッダーフィールドでヘッダーパラメーターを使用する方法については、「セキュリティに関する考慮事項」セクションをご覧ください。
In the following example, Alice initiates a call to Bob. Alice generates a Session-ID header in the out-of-dialog INVITE.
次の例では、アリスがボブへの通話を開始します。アリスは、out-of-dialog INVITEにSession-IDヘッダーを生成します。
Alice generates the following. (Note: much has been left out for simplicity.)
アリスは以下を生成します。 （注：簡略化のため、多くは省略されています。）
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
From: Alice <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>
Call-Id: 123456mcmxcix@1.2.3.4
Session-ID: f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 1 INVITE
Contact: <sip:alice@192.168.1.1>
There are several security considerations surrounding this document's mechanism.
このドキュメントのメカニズムを取り巻くセキュリティ上の考慮事項がいくつかあります。
The Session-ID generation algorithm should provide a reasonably random 32-character Session-ID value to avoid collisions and should not let one re-create the original Call-ID.
セッションID生成アルゴリズムは、衝突を回避するために合理的にランダムな32文字のセッションID値を提供し、元のコールIDを再作成させないようにする必要があります。
There is no known security issue with viewing or modifying the Session-ID, other than to hamper troubleshooting efforts.
トラブルシューティング作業を妨げることを除いて、Session-IDの表示または変更に関する既知のセキュリティ問題はありません。
The requirement for the Session-ID is to be an identifier which cannot be used by a recipient to identify if the Call-ID has been changed by middleboxes. As such, a UAS/UAC cannot detect the original Call-ID, nor whether it has been changed; thus, administrators should not be concerned if the Session-ID header field is "passed through".
セッションIDの要件は、ミドルボックスによってコールIDが変更されたかどうかを識別するために受信者が使用できない識別子であることです。そのため、UAS / UACは元のCall-IDを検出できず、変更されているかどうかも検出できません。したがって、管理者は、Session-IDヘッダーフィールドが「パススルー」されているかどうかを気にする必要はありません。
The Session-ID's value is created from the Call-ID using a hashing mechanism based on [RFC2104], using SHA-1 and a secret key known only to the system generating the Session-ID. Because the algorithm is defined in this document, it should be fairly secure from detecting the generator of the Session-ID, in terms of manufacturer or code base.
セッションIDの値は、[RFC2104]に基づくハッシュメカニズムを使用し、SHA-1とセッションIDを生成するシステムだけが知っている秘密鍵を使用して、コールIDから作成されます。アルゴリズムはこのドキュメントで定義されているため、製造元またはコードベースの観点から、Session-IDの生成元を検出することからかなり安全でなければなりません。
The Session-ID generation algorithm should provide a reasonably random 128-bit Session-ID value, to avoid collisions, and should not let one re-create the original Call-ID. The secret key MUST only be used for the Session-ID mechanism, in case a weakness is found that reveals the key. One such weakness may be that a UAC generates one or more Call-IDs that have a property that makes determining the key more likely.
セッションID生成アルゴリズムは、衝突を回避するために合理的にランダムな128ビットセッションID値を提供し、元のCall-IDを再作成させないようにする必要があります。秘密鍵は、鍵を明らかにする脆弱性が見つかった場合にのみ、Session-IDメカニズムに使用する必要があります。そのような弱点の1つは、UACが、キーを決定する可能性を高めるプロパティを持つ1つ以上のCall-IDを生成することです。
In general, B2BUA behavior cannot be dictated by standards. They do whatever their owners/operators wish them to do, or whatever is necessary to make their applications work. This document attempts to normatively specify some B2BUA behavior, by creating a SIP header value for which the properties are such that B2BUAs should have no legitimate reason to interfere. This effectively creates a "promise" that future uses of this Session-ID header field, including its value *and* any future defined parameters, maintain this benign property. Any future extensions to the Session-ID mechanism and header field MUST maintain this property, or else B2BUAs will begin to modify it again or remove it, and its value will be lost.
一般に、B2BUAの動作は標準で規定することはできません。彼らは、所有者/オペレーターが望んでいること、またはアプリケーションを機能させるために必要なことを何でもします。このドキュメントでは、B2BUAが干渉する正当な理由がないようなプロパティを持つSIPヘッダー値を作成することにより、B2BUAの動作を規範的に指定しようとしています。これにより、このSession-IDヘッダーフィールドの将来の使用（その値と将来の定義済みパラメーターを含む）がこの無害なプロパティを維持するという「約束」が効果的に作成されます。今後、Session-IDメカニズムとヘッダーフィールドの拡張では、このプロパティを維持する必要があります。そうしないと、B2BUAが再度変更または削除を開始し、その値が失われます。
Manufacturers of SIP devices should note that a B2BUA may inspect the Session-ID header field and may remove it if it does not comply with this document's value restrictions. Any Session-ID header parameters MUST be registered with IANA and documented in RFCs from the IETF stream, pursuant to the requirements of [RFC3968].
SIPデバイスの製造元は、B2BUAがSession-IDヘッダーフィールドを検査し、このドキュメントの値の制限に準拠していない場合は削除する場合があることに注意する必要があります。 [RFC3968]の要件に従って、Session-IDヘッダーパラメータはすべてIANAに登録し、IETFストリームからRFCに文書化する必要があります。
IANA has registered a new SIP header field named 'Session-ID', pursuant to the registration policies for such in [RFC5727]. This is a single-instance header field and is appropriate for any SIP message, of any Method type, in any request or response.
IANAは、[RFC5727]の登録ポリシーに従って、「Session-ID」という名前の新しいSIPヘッダーフィールドを登録しました。これは単一インスタンスのヘッダーフィールドであり、任意の要求または応答内の任意のメソッドタイプの任意のSIPメッセージに適しています。
The ABNF rules [RFC5234] for this new header allow for header parameters; however, they must be registered following the rules of [RFC3968], as required by [RFC5727].
この新しいヘッダーのABNFルール[RFC5234]では、ヘッダーパラメーターが許可されています。ただし、[RFC5727]で要求されているように、[RFC3968]の規則に従って登録する必要があります。
This registration is intended to be temporary. The author expects that a Standards Track definition of Session-ID will be published at a future date. Assuming such a document is published, it will replace this registration with a reference to itself, at which point this document will no longer be referenced by IANA.
この登録は一時的なものです。著者は、Session-IDのStandards Track定義が将来公開されることを期待しています。そのようなドキュメントが公開されると仮定すると、この登録はそれ自体への参照に置き換えられます。その時点で、このドキュメントはIANAによって参照されなくなります。
Thanks to Raphael Coeffic, Bob Penfield, Dale Worley, Paul Kyzivat, Ian Elz, Marco Stura, Martin Dolly, Martin Huelsemann, Laura Liess, and Adam Roach for their input.
Raphael Coeffic、Bob Penfield、Dale Worley、Paul Kyzivat、Ian Elz、Marco Stura、Martin Dolly、Martin Huelsemann、Laura Liess、Adam Roachの各氏に感謝します。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「Session Initiation Protocol（SIP）Refer Method」、RFC 3515、2003年4月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891] Mahy、R.、Biggs、B。、およびR. Dean、「Session Initiation Protocol（SIP） "Replaces" Header」、RFC 3891、2004年9月。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[RFC3968] Camarillo、G。、「セッション開始プロトコル（SIP）のインターネット割り当て番号機関（IANA）ヘッダーフィールドパラメータレジストリ」、BCP 98、RFC 3968、2004年12月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5727] 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.
[RFC5727] Peterson、J.、Jennings、C。、およびR. Sparks、「Session Initiation Protocol（SIP）およびReal-time Applications and Infrastructure Areaの変更プロセス」、BCP 67、RFC 5727、2010年3月。
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[RFC4235] Rosenberg、J.、Schulzrinne、H。、およびR. Mahy、編、「セッション開始プロトコル（SIP）のINVITEで開始されるダイアログイベントパッケージ」、RFC 4235、2005年11月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J.およびC. Jennings、「Enhancements for Authenticated Identity Management in the Session Initiation Protocol（SIP）」、RFC 4474、2006年8月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916] Elwell、J。、「Connected Identity in the Session Initiation Protocol（SIP）」、RFC 4916、2007年6月。
It is very tempting to use a header field value such as that provided by Session-ID, for other purposes than troubleshooting. In a previous document for this same Session-ID concept, the proposal included other uses; however, these were removed because any use case other than troubleshooting can easily lead to a B2BUA needing to change the value, in certain cases. That would defeat the troubleshooting value of Session-ID. This section discusses such use cases and explains why they are potentially harmful.
トラブルシューティング以外の目的で、Session-IDによって提供されるようなヘッダーフィールド値を使用するのは非常に魅力的です。この同じセッションIDの概念に関する以前の文書では、提案には他の用途が含まれていました。ただし、トラブルシューティング以外のユースケースでは、B2BUAが値を変更しなければならない場合があるため、これらは削除されました。これは、Session-IDのトラブルシューティング値を無効にします。このセクションでは、そのような使用例について説明し、それらが潜在的に有害である理由を説明します。
Although Session-ID does provide a means to correlate separate SIP dialogs, messages, and transactions, it does so at a higher layer than SIP. It does not replace the mechanics of SIP using the Call-ID and To/From tags of SIP messages to correlate SIP dialogs, nor in other uses such as Replaces headers or dialog-event packages. It is tempting, however, to use it for exactly that purpose in certain cases.
セッションIDは、個別のSIPダイアログ、メッセージ、およびトランザクションを関連付ける手段を提供しますが、SIPよりも上位の層で関連付けます。 SIPメッセージのCall-IDタグとTo / Fromタグを使用してSIPダイアログを相互に関連付けたり、Replacesヘッダーやダイアログイベントパッケージなどの他の用途でSIPのメカニズムを置き換えたりすることはありません。ただし、場合によっては、まさにその目的で使用するのが魅力的です。
For example, suppose a call transfer case where Alice calls Bob through B2BUA-1. Bob then calls Charlie and sends Charlie a REFER with embedded Replaces to make Charlie send an INVITE with a Replaces header to Alice, to replace the Alice-Bob session. If Charlie uses a different B2BUA-2 to reach Alice, the INVITE with Replaces will fail because the Call-ID/tags won't match anything B2BUA-2 or Alice knows about.
たとえば、アリスがB2BUA-1を介してボブにコールするコール転送ケースを想定します。次に、ボブはチャーリーを呼び出し、チャーリーに置換を埋め込んだREFERを送信して、チャーリーに置換ヘッダーを含むINVITEをアリスに送信させ、アリスボブセッションを置き換えます。 Charlieが別のB2BUA-2を使用してアリスに到達する場合、Call-ID /タグがB2BUA-2またはAliceが認識しているものと一致しないため、INVITE with Replacesは失敗します。
+-----+ +-------+ +-------+ +-----+ +-------+
|Alice| |B2BUA-1| |B2BUA-2| | Bob | |Charlie|
+-----+ +-------+ +-------+ +-----+ +-------+
| | | | |
|INVITE | | | |
|callid:1a |callid:1b | | |
|----------->|----------------------->|INVITE |
|sessid:1 |sessid:1 | |callid:2a |
| | | |----------->|
| | | |sessid:2 |
| | | | |
| | | |REFER |
| | | |referto:1b |
| | | |----------->|
| | | | |
| | | | INVITE|
| | | | replaces:1b|
| | X<-----------------------|
| | INVITE| | sessid:1|
| | replaces:1b| | |
X<------------------------| | |
| | sessid:1| | |
Example 1: Call Transfer Case
例1：電話転送のケース
If, on the other hand, Alice were to use the Session-ID value for correlation, she would see it matches her dialog with Bob (assuming the Session-ID were passed along in the Refer-To and Replaces info).
一方、アリスがセッションID値を相関に使用する場合、ボリスとのダイアログと一致することがわかります（セッションIDが参照先と置換情報で渡されたと想定）。
There are problems with this approach, however. The first problem is, by not sending the INVITE with Replaces to B2BUA-1, B2BUA-1 is in an incorrect state; the dialog is getting replaced, and the B2BUA doesn't know it.
ただし、このアプローチには問題があります。最初の問題は、B2BUA-1への置換を伴うINVITEを送信しないことにより、B2BUA-1が誤った状態になっていることです。ダイアログは置き換えられ、B2BUAはそれを認識しません。
A second issue is the Session-ID doesn't identify enough information to replace a dialog. Imagine there were a third B2BUA, such as a softswitch, between Alice and B2BUA-1 and B2BUA-2, and the INVITE with Replaces reached the softswitch before Alice. The softswitch won't know which "side" the INVITE is replacing. The To/From tags no longer match anything the softswitch knows about, so it can't figure out if the INVITE with Replaces is replacing the dialog from softswitch to Alice, or the one to Bob. If we try to fix this by creating a tag-type value pair for Session-ID, we're back to devices changing those tag values and defeating the matching property.
2番目の問題は、セッションIDがダイアログを置き換えるのに十分な情報を識別しないことです。 AliceとB2BUA-1とB2BUA-2の間にソフトスイッチなどの3番目のB2BUAがあり、INVITE with ReplacesがAliceの前にソフトスイッチに到達したとします。ソフトスイッチは、INVITEがどの「サイド」に置き換わるかを認識しません。 To / Fromタグは、ソフトスイッチが認識しているものと一致しなくなったため、INVITE with ReplacesがダイアログをソフトスイッチからAliceに、またはBobに置き換えているかどうかを判断できません。 Session-IDのタグと値のペアを作成してこれを修正しようとすると、デバイスに戻ってそれらのタグの値を変更し、一致するプロパティを無効にします。
Another example is based on 3GPP 24.605 Annex A.2.2. Alice has a call with Bob through multiple B2BUAs and an Application Server. The dialogs of that call all have the same Session-ID, but unique Call-ID/tags.
別の例は、3GPP 24.605 Annex A.2.2に基づいています。アリスは、複数のB2BUAとアプリケーションサーバーを介してボブと通話します。その呼び出しのダイアログはすべて同じセッションIDを持っていますが、一意の呼び出しID /タグを持っています。
Alice wants to invoke a third-party conference facility in the AS and to reference the call she has with Bob for that. In this particular 3GPP scenario, to do that Alice sends a new INVITE to the AS with a resource-list body (a la RFC 5366) containing the call information for the original call. This is the "RL<sessid:1>" piece in the diagram. It has the Call-ID/tags as well, but they'll be wrong when received at the AS.
アリスは、ASでサードパーティの会議施設を呼び出し、ボブとの通話を参照したいと考えています。この特定の3GPPシナリオでは、そのために、アリスは、元のコールのコール情報を含むリソースリスト本文（RFC 5366を含む）を含む新しいINVITEをASに送信します。これは、図の「RL <sessid：1>」の部分です。 Call-ID /タグも含まれていますが、ASで受信すると正しくありません。
The AS processes that list, can't match the Call-ID/tags in the resource-lit but does match the Session-ID, and sends a re-INVITE to party B within the original call's dialog.
ASはそのリストを処理し、resource-lit内のCall-ID /タグとは一致しませんが、Session-IDとは一致し、元の通話のダイアログ内でパーティBにre-INVITEを送信します。
+-----+ +-------+ +----+ +-------+ +-----+
|Alice| |B2BUA-1| | AS | |B2BUA-2| | Bob |
+-----+ +-------+ +----+ +-------+ +-----+
| | | | |
|INVITE | | | |
|callid:1a |callid:1b |callid:1c |callid:1d |
|----------->|----------->|---------->|----------->|
|sessid:1 |sessid:1 |sessid:1 |sessid:1 |
| | | | |
|INVITE | | | |
|callid:2a |callid:2b | | |
|----------->|----------->| | |
|sessid:2 |sessid:2 |re-INVITE | |
|RL<sessid:1>|RL<sessid:1>|callid:1c |callid:1d |
| | |---------->|----------->|
| | |sessid:1 |sessid:1 |
| | | | |
Example 2: Resource List
例2：リソースリスト
Author's Address
著者のアドレス
Hadriel Kaplan Oracle EMail: hadrielk@yahoo.com
ハドリエルカプランオラクルメール：hadrielk@yahoo.com