[要約] 要約： RFC 7206は、IPベースのマルチメディア通信ネットワークにおけるエンドツーエンドのセッション識別の要件について説明しています。目的： このRFCの目的は、マルチメディア通信ネットワークにおいてセッションを一意に識別するための要件を定義することです。
Internet Engineering Task Force (IETF) P. Jones
Request for Comments: 7206 G. Salgueiro
Category: Informational J. Polk
ISSN: 2070-1721 Cisco Systems
L. Liess
Deutsche Telekom
H. Kaplan
Oracle
May 2014
Requirements for an End-to-End Session Identifier in IP-Based Multimedia Communication Networks
IPベースのマルチメディア通信ネットワークにおけるエンドツーエンドセッション識別子の要件
Abstract
概要
This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains.
このドキュメントでは、IPベースのマルチメディア通信ネットワークにおけるエンドツーエンドのセッション識別子の要件について説明します。この識別子により、エンドポイント、中間デバイス、および管理システムと監視システムは、複数のSIPデバイス、ホップ、および管理ドメインにまたがるエンドツーエンドのセッションを識別できます。
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/rfc7206.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7206で入手できます。
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
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................4
3.1. What Does the Session Identifier Identify? .................4
3.2. Communication Session ......................................5
3.3. End-to-End .................................................6
4. Session Identifier Use Cases ....................................6
4.1. End-to-End Identification of a Communication Session .......6
4.2. Protocol Interworking ......................................6
4.3. Traffic Monitoring .........................................7
4.4. Tracking Transferred Sessions ..............................7
4.5. Session Signal Logging .....................................8
4.6. Identifier Syntax ..........................................8
4.7. 3PCC Use Case ..............................................9
5. Requirements for the End-to-End Session Identifier ..............9
6. Related Work in Other Standards Organizations ..................10
6.1. Coordination with the ITU-T ...............................10
6.2. Requirements within 3GPP ..................................11
7. Security Considerations ........................................11
8. Acknowledgments ................................................12
9. Contributors ...................................................12
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
IP-based multimedia communication systems like SIP [1] and H.323 [2] have the concept of a "call identifier" that is globally unique. The identifier is intended to represent an end-to-end communication session from the originating device to the terminating device. Such an identifier is useful for troubleshooting, session tracking, and so forth.
SIP [1]やH.323 [2]などのIPベースのマルチメディア通信システムには、グローバルに一意の「コール識別子」という概念があります。識別子は、発信デバイスから終端デバイスへのエンドツーエンドの通信セッションを表すことを目的としています。このような識別子は、トラブルシューティング、セッション追跡などに役立ちます。
Unfortunately, there are a number of factors that mean that the current call identifiers defined in SIP and H.323 are not suitable for end-to-end session identification. Perhaps most significant is the fact that the syntax for the call identifier in SIP and H.323 is different between the two protocols. This important fact makes it impossible for call identifiers to be exchanged end-to-end when a network uses both of these session protocols.
残念ながら、SIPおよびH.323で定義されている現在のコール識別子がエンドツーエンドのセッション識別には適さないことを意味するいくつかの要因があります。おそらく最も重要なのは、SIPとH.323のコール識別子の構文が2つのプロトコル間で異なるという事実です。この重要な事実により、ネットワークがこれらのセッションプロトコルの両方を使用している場合、コール識別子をエンドツーエンドで交換することが不可能になります。
Another reason why the current call identifiers are not suitable to identify the session end-to-end is that in real-world deployments, devices like Back-to-Back User Agents (B2BUAs) often change the values as the session signaling passes through. This is true even when a single session protocol is employed and is not a byproduct of protocol interworking.
現在のコール識別子がセッションをエンドツーエンドで識別するのに適していないもう1つの理由は、実際の展開では、バックツーバックユーザーエージェント（B2BUA）などのデバイスが、セッションシグナリングが通過するときに値を変更することが多いためです。これは、単一セッションプロトコルが採用されている場合でも当てはまり、プロトコルインターワーキングの副産物ではありません。
Lastly, identifiers that might have been used to identify a session end-to-end fail to meet that need when sessions are manipulated through supplementary service interactions. For example, when a session is transferred or if a private branch exchange (PBX) joins or merges two communication sessions together locally, the end-to-end properties of currently defined identifiers are lost.
最後に、セッションをエンドツーエンドで識別するために使用された可能性のある識別子は、セッションが補足的なサービスの相互作用を通じて操作される場合、そのニーズを満たすことができません。たとえば、セッションが転送されるとき、または構内交換機（PBX）が2つの通信セッションをローカルで結合またはマージする場合、現在定義されている識別子のエンドツーエンドのプロパティは失われます。
This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains.
このドキュメントでは、IPベースのマルチメディア通信ネットワークにおけるエンドツーエンドのセッション識別子の要件について説明します。この識別子により、エンドポイント、中間デバイス、および管理システムと監視システムは、複数の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 RFC 2119 [3] when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [3]に記載されているとおりに解釈され、すべて大文字で表示されます。これらの単語は、規範的な意味がなければ、このドキュメントでは小文字でプレーンな英語の単語として表示されることもあります。
The identifier on which this document places requirements, the session identifier, identifies a set of signaling messages associated with exactly two endpoints that, from each endpoint's perspective, are related to a single invocation of a communication application.
このドキュメントが要件とする識別子であるセッション識別子は、各エンドポイントの観点から、通信アプリケーションの1回の呼び出しに関連する2つのエンドポイントに関連付けられたシグナリングメッセージのセットを識別します。
How the endpoints determine which signaling messages share a given identifier (that is, what constitutes a single invocation of a communication application) is intentionally left loosely defined.
エンドポイントが特定の識別子を共有するシグナリングメッセージを決定する方法（つまり、通信アプリケーションの単一の呼び出しを構成するもの）は、意図的に大まかに定義されたままになっています。
The term "call" is often used as an example of such an invocation for voice and video communication, but different protocols and deployments define the scope of a "call" in different ways. For instance, some systems would associate all of the activity between all three parties involved in a transfer as a single "call".
「通話」という用語は、音声およびビデオ通信のこのような呼び出しの例としてよく使用されますが、プロトコルと配置が異なると、「通話」の範囲が異なる方法で定義されます。たとえば、一部のシステムでは、転送に関与する3者すべての間のすべてのアクティビティを1つの「呼び出し」として関連付けます。
Similarly, the term "session" is often used as an example of such an invocation, but this term is overloaded to describe both signaling and media-level interaction. A single invocation of the communication application, as described above, may involve multiple RTP "sessions" as described by RFC 3550 [4], and possibly even multiple concurrent sessions.
同様に、「セッション」という用語は、そのような呼び出しの例としてよく使用されますが、この用語は、シグナリングとメディアレベルの相互作用の両方を説明するために多用されています。上記のように、通信アプリケーションの1回の呼び出しには、RFC 3550 [4]で説明されている複数のRTP「セッション」が含まれ、場合によっては複数の同時セッションが含まれることもあります。
In this document, unless otherwise qualified, the term "communication session", or simply "session", will refer only to the set of signaling messages identified by the common session identifier. That is, a "session" is a set of signaling messages associated with exactly two endpoints that, from each endpoint's perspective, are related to a single invocation of a communication application.
このドキュメントでは、特に限定されない限り、「通信セッション」または単に「セッション」という用語は、共通のセッション識別子によって識別されるシグナリングメッセージのセットのみを指します。つまり、「セッション」は、各エンドポイントの観点から、通信アプリケーションの1回の呼び出しに関連する、厳密に2つのエンドポイントに関連付けられた一連のシグナリングメッセージです。
The requirements in this document put some constraints on what an endpoint will consider the same, or a different, invocation of a communication session. They also ensure that related sessions (as this document is using the term) can be correlated using only the session identifiers for each session. Again, what constitutes a "related" session is intentionally left loosely defined.
このドキュメントの要件は、エンドポイントが通信セッションの同じまたは異なる呼び出しを検討する際にいくつかの制約を課します。また、関連するセッション（このドキュメントではこの用語を使用しているため）は、各セッションのセッション識別子のみを使用して相互に関連付けることができます。繰り返しますが、「関連する」セッションを構成するものは、意図的に大まかに定義されたままです。
The definition considers messages associated with exactly two endpoints instead of messages sent between two endpoints to allow for intermediaries that create messages on an endpoint's behalf. It is possible that an endpoint may not see all of the messages in a session (as this document is using the term) associated with it.
この定義では、エンドポイントの代わりにメッセージを作成する仲介者を考慮に入れて、2つのエンドポイント間で送信されるメッセージではなく、厳密に2つのエンドポイントに関連付けられたメッセージを考慮します。エンドポイントに関連付けられているセッション（このドキュメントではこの用語を使用しているため）内のすべてのメッセージがエンドポイントに表示されない可能性があります。
This definition, along with the constraints imposed by the requirements in this document, facilitates specifying an identifier that allows the two endpoints to use two entirely different protocols (and hence to potentially have different ideas of what a single invocation means) or use two applications that have a different idea of what a single invocation means.
この定義は、このドキュメントの要件によって課せられる制約とともに、2つのエンドポイントが2つの完全に異なるプロトコルを使用できるように（したがって、単一の呼び出しが何を意味するかについて異なる考えを持つ可能性がある）、または2つのアプリケーションを使用できるようにする識別子の指定を容易にします単一の呼び出しが何を意味するかについて異なる考えを持っています。
A communication session may exist between two SIP User Agents (UAs) and may pass through one or more intermediary devices, including B2BUAs or SIP proxies. For example:
通信セッションは2つのSIPユーザーエージェント（UA）間に存在し、B2BUAまたはSIPプロキシを含む1つ以上の中間デバイスを通過します。例えば：
UA A Middlebox(es) UA B
UA Aミドルボックス（es）UA B
SIP message(s) -------[]---[]-------> SIP message(s)
SIP message(s) <-----[]---[]------- SIP message(s)
Figure 1: Communication Session through Middlebox(es)
図1：Middleboxを介した通信セッション
The following are examples of acceptable communication sessions as described in Section 3.1 and are not exhaustive:
以下は、セクション3.1で説明されている許容可能な通信セッションの例であり、網羅的なものではありません。
o A call directly between two user agents
o 2つのユーザーエージェント間の直接の呼び出し
o A call between two user agents with one or more SIP middleboxes in the signaling path
o シグナリングパスに1つ以上のSIPミドルボックスを持つ2つのユーザーエージェント間の通話
o A call between two user agents that was initiated using third-party call control (3PCC) [5]
o サードパーティコールコントロール（3PCC）を使用して開始された2つのユーザーエージェント間のコール[5]
o A call between two user agents (e.g., between Alice and Carol) that results from a different communication session (e.g., Alice and Bob) wherein one of those user agents (Alice) is transferred to another user agent (Carol) using a REFER request or a re-INVITE request
o 2つのユーザーエージェント間の（たとえば、アリスとキャロルの間の）異なる通信セッション（たとえば、アリスとボブ）から生じるコールで、それらのユーザーエージェントの1つ（アリス）がREFER要求を使用して別のユーザーエージェント（キャロル）に転送されるまたはre-INVITEリクエスト
The following are not considered communication sessions:
以下は通信セッションとは見なされません。
o A call between any two user agents wherein two or more user agents are engaged in a conference call via a conference focus:
o 2つ以上のユーザーエージェントが会議フォーカスを介して電話会議に参加している任意の2つのユーザーエージェント間の通話：
- each call between the user agent and the conference focus would be a communication session, and
- ユーザーエージェントと会議のフォーカスの間の各呼び出しは通信セッションになります。
- each of these is a distinct communication session.
- これらはそれぞれ別個の通信セッションです。
o A call between three user agents (e.g., Alice, Bob, and Carol) wherein the first user agent (Alice) ad hoc conferences the other two user agents (Bob and Carol):
o 3つのユーザーエージェント（Alice、Bob、Carolなど）間の通話。最初のユーザーエージェント（Alice）が他の2つのユーザーエージェント（BobとCarol）をアドホック会議します。
- The call between Alice and Bob would be one communication session.
- アリスとボブの間の通話は、1つの通信セッションになります。
- The call between Alice and Carol would be a different communication session.
- アリスとキャロル間の通話は別の通信セッションになります。
The term "end-to-end" in this document means the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It is recognized that legacy devices may not support the end-to-end session identifier. Since such an endpoint will not create a session identifier, an intermediary device that supports this identifier can inject an identifier into the session signaling.
このドキュメントの「エンドツーエンド」という用語は、起点から任意の数の仲介者を通過して、最終的な終点までの通信セッションを意味します。レガシーデバイスはエンドツーエンドのセッション識別子をサポートしない可能性があることが認識されています。このようなエンドポイントはセッション識別子を作成しないため、この識別子をサポートする中間デバイスは、セッションシグナリングに識別子を挿入できます。
For SIP messaging that either does not involve SIP servers or only involves SIP proxies, the Call-ID header field value sufficiently identifies each SIP message within a transaction (see Section 17 of [1]) or dialog (see Section 12 of [1]). This is not the case when either B2BUAs or Session Border Controllers (SBCs) [6] are in the signaling path between User Agents (UAs). Therefore, we need the ability to identify each communication session through a single SIP header field, regardless of which types of SIP servers are in the signaling path between UAs. For messages that create a dialog, each message within the same dialog MUST use the same session identifier.
SIPサーバーを含まないか、SIPプロキシのみを含むSIPメッセージングの場合、Call-IDヘッダーフィールド値は、トランザクション（[1]のセクション17を参照）またはダイアログ（[1]のセクション12を参照）内の各SIPメッセージを十分に識別します。 ）。これは、B2BUAまたはセッションボーダーコントローラー（SBC）[6]がユーザーエージェント（UA）間のシグナリングパスにある場合には当てはまりません。したがって、UA間のシグナリングパスにあるSIPサーバーのタイプに関係なく、単一のSIPヘッダーフィールドを通じて各通信セッションを識別する機能が必要です。ダイアログを作成するメッセージの場合、同じダイアログ内の各メッセージは同じセッション識別子を使用する必要があります。
Derived Requirements: All Requirements in Section 5.
派生要件：セクション5のすべての要件
A communication session might originate on an H.323 [2] endpoint and pass through an SBC before ultimately reaching a terminating SIP user agent. Likewise, a call might originate on a SIP user agent and terminate on an H.323 endpoint. It MUST be possible to identify such sessions end-to-end across the plurality of devices, networks, or administrative domains.
通信セッションはH.323 [2]エンドポイントで開始され、最終的に終端のSIPユーザーエージェントに到達する前にSBCを通過する場合があります。同様に、コールはSIPユーザーエージェントで発信され、H.323エンドポイントで終了する場合があります。そのようなセッションを、複数のデバイス、ネットワーク、または管理ドメインにわたってエンドツーエンドで識別できるようにする必要があります。
It is anticipated that the ITU-T will define protocol elements for H.323 to make the end-to-end signaling possible.
ITU-TはH.323のプロトコル要素を定義して、エンドツーエンドのシグナリングを可能にすることが期待されています。
Derived Requirements: REQ5, REQ7 (Section 5).
派生要件：REQ5、REQ7（セクション5）。
UA A and UA B communicate using SIP messaging with a SIP B2BUA acting as a middlebox that belongs to a SIP service provider. For privacy reasons, the B2BUA changes the SIP header fields that reveal information related to the SIP users, devices, or domain identities. The service provider uses an external device to monitor and log all SIP traffic coming to and from the B2BUA. In the case of failures reported by the customer or when security issues arise (e.g., theft of service), the service provider has to analyze the logs from the past several days or weeks and then correlates those messages that were messages for a single end-to-end SIP session.
UA AとUA Bは、SIPメッセージングを使用して、SIPサービスプロバイダーに属するミドルボックスとして機能するSIP B2BUAと通信します。プライバシー上の理由から、B2BUAはSIPヘッダーフィールドを変更して、SIPユーザー、デバイス、またはドメインIDに関連する情報を公開します。サービスプロバイダーは、外部デバイスを使用して、B2BUAとの間で送受信されるすべてのSIPトラフィックを監視および記録します。顧客から報告された障害の場合、またはセキュリティの問題（サービスの盗難など）が発生した場合、サービスプロバイダーは過去数日または数週間のログを分析し、シングルエンドのメッセージであったメッセージを関連付ける必要があります。 SIPセッションを終了します。
For this scenario, we must consider three particular use cases:
このシナリオでは、3つの特定のユースケースを考慮する必要があります。
a) UAs A and B support the end-to-end session identifier.
a) UA AおよびBは、エンドツーエンドセッション識別子をサポートします。
Derived Requirements: REQ1, REQ3, REQ4, REQ6.
派生要件：REQ1、REQ3、REQ4、REQ6。
b) Only UA A supports the end-to-end session identifier; UA B does not.
b) UA Aのみがエンドツーエンドセッション識別子をサポートします。 UA Bではありません。
Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6.
派生要件：REQ1、REQ3、REQ4、REQ5、REQ6。
c) UAs A and B do not support the end-to-end session identifier.
c) UA AおよびBは、エンドツーエンドセッション識別子をサポートしていません。
Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6.
派生要件：REQ1、REQ3、REQ4、REQ5、REQ6。
It is difficult to track which SIP messages were involved in the same call across transactions, especially when invoking supplementary services such as call transfer or call join. There exists a need for the ability to track communication sessions as they are transferred, one side at a time, until completion of the session (i.e., until a BYE is sent).
特にコール転送やコール参加などの補足サービスを呼び出す場合、トランザクション間でどのSIPメッセージが同じコールに関係していたかを追跡することは困難です。通信セッションが転送されるときに、セッションが完了するまで（つまり、BYEが送信されるまで）通信セッションを一度に1つずつ追跡する機能が必要です。
Derived Requirements: REQ1, REQ2, REQ9.
派生要件：REQ1、REQ2、REQ9。
An after-the-fact search of SIP messages to determine which messages were part of the same transaction or call is difficult when B2BUAs and SBCs are involved in the signaling between UAs. Mapping more than one Call-ID together can be challenging because all of the values in SIP header fields on one side of the B2BUA or SBC will likely be different than those on the other side. If multiple B2BUAs and/or SBCs are in the signaling path, more than two sets of header field values will exist, creating more of a challenge. Creating a common header field value through all SIP entities will greatly reduce any challenge for the purposes of debugging, communication tracking (such as for security purposes in case of theft of service), etc.
B2BUAとSBCがUA間のシグナリングに関与している場合、同じメッセージまたはコールの一部であったメッセージを特定するためのSIPメッセージの事後検索は困難です。 B2BUAまたはSBCの片側のSIPヘッダーフィールドのすべての値が反対側の値と異なる可能性があるため、複数のCall-IDを一緒にマッピングすることは困難な場合があります。複数のB2BUAやSBCがシグナリングパスにある場合、ヘッダーフィールド値のセットが3つ以上存在するため、さらに多くの課題が発生します。すべてのSIPエンティティで共通のヘッダーフィールド値を作成すると、デバッグ、通信追跡（サービスの盗難の場合のセキュリティ上の目的など）のための課題が大幅に減少します。
Derived Requirements: REQ1, REQ3, REQ5, REQ6.
派生要件：REQ1、REQ3、REQ5、REQ6。
A syntax that is too lax (e.g., one that allows special characters or a very long identifier) would make it difficult to encode the identifier in other protocols. Therefore, the syntax of the identifier should be reasonably constrained.
構文が厳しすぎると（特殊文字や非常に長い識別子を許可する構文など）、他のプロトコルで識別子をエンコードすることが難しくなります。したがって、識別子の構文は合理的に制約されるべきです。
Derived Requirement: REQ8.
派生要件：REQ8。
Third-party call control refers to the ability of an entity to create a call in which communication is actually between two or more parties other than the one setting up the call. For example, a B2BUA acting as a third-party controller could establish a call between two SIP UAs using 3PCC procedures as described in Section 4.1 of RFC 3725 [5], the flow for which is reproduced below.
サードパーティの通話制御とは、通話を設定する当事者以外の2人以上の通話者間で実際に通信が行われる通話を作成するエンティティの機能を指します。たとえば、サードパーティのコントローラとして機能するB2BUAは、RFC 3725 [5]のセクション4.1で説明されているように、3PCC手順を使用して2つのSIP UA間の通話を確立できます。そのフローを以下に示します。
A Controller B
|(1) INVITE no SDP | |
|<------------------| |
|(2) 200 offer1 | |
|------------------>| |
| |(3) INVITE offer1 |
| |------------------>|
| |(4) 200 OK answer1 |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) ACK answer1 | |
|<------------------| |
|(7) RTP | |
|.......................................|
Figure 2: Session Identifier 3PCC Scenario
図2：セッション識別子3PCCシナリオ
Such a flow must result in a single session identifier being used for the communication session between UA A and UA B. This use case does not extend to three SIP UAs.
このようなフローでは、UA AとUA B間の通信セッションに単一のセッションIDが使用される必要があります。この使用例は、3つのSIP UAには適用されません。
Derived Requirement: REQ9.
派生要件：REQ9。
The following requirements are derived from the use cases and additional constraints regarding the construction of the identifier.
以下の要件は、識別子の構築に関するユースケースと追加の制約から派生しています。
REQ1: It MUST be possible for an administrator or an external device that monitors the SIP traffic to use the identifier to identify those dialogs, transactions, and messages that were at some point in time components of a single end-to-end SIP session (e.g., parts of the same call).
REQ1：管理者またはSIPトラフィックを監視する外部デバイスが、識別子を使用して、ある時点で単一のエンドツーエンドSIPセッションのコンポーネントであったダイアログ、トランザクション、およびメッセージを識別することが可能でなければなりません（たとえば、同じ呼び出しの一部）。
REQ2: It MUST be possible to correlate two end-to-end sessions when a session is transferred or if two different sessions are joined together via an intermediary (e.g., a PBX).
REQ2：セッションが転送されるとき、または2つの異なるセッションが仲介者（PBXなど）を介して結合される場合、2つのエンドツーエンドセッションを関連付けることが可能でなければなりません（MUST）。
REQ3: The solution MUST require that the identifier, if present, pass unchanged through SIP B2BUAs or other intermediaries.
REQ3：ソリューションでは、IDが存在する場合は、SIP B2BUAまたは他の仲介者を介して変更せずに渡す必要があります（MUST）。
REQ4: The identifier MUST NOT reveal any information related to any SIP user, device, or domain identity. Additionally, it MUST NOT be possible to correlate a set of session identifiers produced over a period of time with one another, or with a particular user or device. This includes any IP address, port, hostname, domain name, username, Address-of-Record, Media Access Control (MAC) address, IP address family, transport type, subscriber ID, Call-ID, tags, or other SIP header field or body parts.
REQ4：識別子は、SIPユーザー、デバイス、またはドメインIDに関連する情報を公開してはなりません（MUST NOT）。さらに、ある期間にわたって生成されたセッション識別子のセットを相互に、または特定のユーザーやデバイスと関連付けることはできません。これには、IPアドレス、ポート、ホスト名、ドメイン名、ユーザー名、レコードのアドレス、メディアアクセス制御（MAC）アドレス、IPアドレスファミリー、トランスポートタイプ、サブスクライバーID、コールID、タグ、またはその他のSIPヘッダーフィールドが含まれますまたは体の部分。
REQ5: It MUST be possible to identify SIP traffic with an end-to-end session identifier from and to end devices that do not support this new identifier, such as by allowing an intermediary to inject an identifier into the session signaling.
REQ5：仲介者がセッションシグナリングに識別子を挿入できるようにするなどして、この新しい識別子をサポートしないエンドデバイスとの間のエンドツーエンドセッション識別子でSIPトラフィックを識別できる必要があります。
REQ6: The identifier SHOULD be unique in time and space, similar to the Call-ID.
REQ6：Call-IDと同様に、識別子は時間と空間で一意である必要があります（SHOULD）。
REQ7: The identifier SHOULD be constructed in such a way as to make it suitable for transmission in SIP [1] and H.323 [2].
REQ7：識別子は、SIP [1]およびH.323 [2]での送信に適した方法で構築する必要があります（SHOULD）。
REQ8: The identifier SHOULD use a restricted syntax and length so as to allow the identifier to be used in other protocols.
REQ8：識別子は、識別子を他のプロトコルで使用できるように、制限された構文と長さを使用する必要があります（SHOULD）。
REQ9: It MUST be possible to correlate two end-to-end sessions when the sessions are created by a third-party controller using 3PCC procedures as shown in Figure 1 of RFC 3725 [5].
REQ9：RFC 3725 [5]の図1に示されているように、セッションが3PCC手順を使用してサードパーティのコントローラーによって作成される場合、2つのエンドツーエンドセッションを関連付けることが可能でなければなりません（MUST）。
IP multimedia networks are often comprised of a mix of session protocols like SIP [1] and H.323 [2]. A benefit of the session identifier is that it uniquely identifies a communication session end-to-end across session protocol boundaries. Therefore, the need for coordinated standardization activities across Standards Development Organizations (SDOs) is imperative.
IPマルチメディアネットワークは、多くの場合、SIP [1]やH.323 [2]などのセッションプロトコルの組み合わせで構成されています。セッション識別子の利点は、セッションプロトコルの境界を越えてエンドツーエンドで通信セッションを一意に識別することです。したがって、標準化開発組織（SDO）全体で調整された標準化活動の必要性が不可欠です。
To facilitate this, a parallel effort is underway in the ITU-T to introduce the session identifier for H.323 in such a way as to be interoperable with the procedures defined by the IETF.
これを容易にするために、ITFで定義された手順と相互運用できるように、H.323のセッション識別子を導入するための並行作業がITU-Tで進行中です。
The Third Generation Partnership Project (3GPP) identified in their Release 9 the need for a session identifier for operation and maintenance purposes to correlate flows in an end-to-end communication session. 3GPP TS24.229 [7] points to the fact that the session identifier can be used to correlate SIP messages belonging to the same session. In the case where signaling passes through SIP entities like B2BUAs, the end-to-end session identifier indicates that these dialogs belong to the same end-to-end SIP communication session.
リリース9で特定された第3世代パートナーシッププロジェクト（3GPP）は、エンドツーエンドの通信セッションのフローを相互に関連付けるための運用および保守の目的でのセッション識別子の必要性を識別しました。 3GPP TS24.229 [7]は、セッション識別子を使用して、同じセッションに属するSIPメッセージを関連付けることができることを示しています。シグナリングがB2BUAなどのSIPエンティティを通過する場合、エンドツーエンドセッション識別子は、これらのダイアログが同じエンドツーエンドSIP通信セッションに属していることを示します。
The security vulnerabilities, attacks, and threat models affecting other similar SIP identifiers are well documented in RFC 3261 [1] and are equally applicable to the end-to-end session identifier and subject to the same mitigating security best practices. Further, storage of the session identifier in a log file is also subject to the security considerations specified in RFC 6872 [8].
他の同様のSIP識別子に影響を与えるセキュリティの脆弱性、攻撃、および脅威のモデルは、RFC 3261 [1]で十分に文書化されており、エンドツーエンドのセッション識別子に等しく適用され、同じセキュリティのベストプラクティスを軽減します。さらに、ログファイルへのセッション識別子の格納も、RFC 6872 [8]で指定されているセキュリティの考慮事項の対象となります。
An end-to-end identifier, if not properly constructed, could provide confidential information that would allow one to identify the individual, device, or domain initiating or terminating a communication session. In adhering to REQ4, the solution produced in accordance with these requirements MUST take appropriate measures to properly secure and obfuscate sensitive or private information that might allow one to identify a person, device, or domain. This means that the end-to-end session identifier MUST NOT reveal information elements such as the MAC address or IP address. It is outside the scope of this document to specify the implementation details of such security and privacy measures. Those details may vary with the specific construction mechanism selected for the end-to-end session identifier and therefore will be discussed in the document specifying the actual end-to-end identifier.
エンドツーエンドの識別子は、適切に構成されていない場合、通信セッションを開始または終了する個人、デバイス、またはドメインを識別できる機密情報を提供する可能性があります。 REQ4に準拠する場合、これらの要件に従って作成されたソリューションは、個人、デバイス、またはドメインの識別を可能にする可能性のある機密情報またはプライベート情報を適切に保護および難読化するための適切な手段を講じる必要があります。これは、エンドツーエンドセッション識別子がMACアドレスやIPアドレスなどの情報要素を公開してはならないことを意味します。このようなセキュリティおよびプライバシー対策の実装の詳細を指定することは、このドキュメントの範囲外です。これらの詳細は、エンドツーエンドセッションIDに選択された特定の構築メカニズムによって異なる場合があるため、実際のエンドツーエンドIDを指定するドキュメントで説明します。
A key security consideration is to ensure that an attacker cannot surreptitiously spoof the identifier and effectively render it useless to diagnostic equipment that cannot properly correlate signaling messages due to the duplicate session identifiers that exist in the same space and time. In accordance with REQ6, this end-to-end identifier MUST be sufficiently long and random to prevent it from being guessable as well as avoid collision with another identifier. The secure transport of the identifier, need for authentication, encryption, etc. should be appropriately evaluated based on the network infrastructure, transport domain, and usage scenarios for the end-to-end session identifier.
重要なセキュリティ上の考慮事項は、攻撃者が識別子を不正にスプーフィングできず、同じ時間と同じ時間に存在する重複したセッション識別子が原因でシグナリングメッセージを適切に関連付けることができない診断機器に対して事実上役に立たないようにすることです。 REQ6に従って、このエンドツーエンドの識別子は、他の識別子との衝突を回避するだけでなく、それが推測されないようにするために十分に長くランダムである必要があります。識別子の安全なトランスポート、認証、暗号化の必要性などは、エンドツーエンドセッション識別子のネットワークインフラストラクチャ、トランスポートドメイン、および使用シナリオに基づいて適切に評価する必要があります。
The authors would like to acknowledge Paul Kyzivat, Christer Holmberg, Charles Eckel, Andy Hutton, Salvatore Loreto, Keith Drage, and Chris Pearce for their contribution and collaboration in developing this document.
著者は、このドキュメントの開発に協力してくれたPaul Kyzivat、Christer Holmberg、Charles Eckel、Andy Hutton、Salvatore Loreto、Keith Drage、およびChris Pearceに感謝します。
Roland Jesske and Parthasarathi Ravindran provided substantial contributions to this document during its initial creation.
Roland JesskeとParthasarathi Ravindranは、最初の作成時にこのドキュメントに多大な貢献をしました。
[1] 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.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」、RFC 3261 、2002年6月。
[2] Recommendation ITU-T H.323, "Packet-based multimedia communications systems", December 2009.
[2] 勧告ITU-T H.323、「パケットベースのマルチメディア通信システム」、2009年12月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[4] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[5] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[5] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「Session Initiation Protocol（SIP）におけるサードパーティコール制御（3pcc）のベストプラクティス」、BCP 85、RFC 3725、2004年4月。
[6] Hautakorpi, J., Ed., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[6] Hautakorpi、J.、Ed。、Camarillo、G.、Penfield、R.、Hawrylyshen、A.、and M. Bhatia、 "Requirements from Session Initiation Protocol（SIP）Session Border Control（SBC）Deployments"、RFC 5853、April 2010。
[7] 3GPP TS 24.229, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
[7] 3GPP TS 24.229、「セッション開始プロトコル（SIP）およびセッション記述プロトコル（SDP）に基づくIPマルチメディアコール制御プロトコル、ステージ3」。
[8] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, H., and O. Festor, "The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model", RFC 6872, February 2013.
[8] Gurbani、V.、Ed。、Burger、E.、Ed。、Anjali、T.、Abdelnur、H.、O. Festor、 "The Common Log Format（CLF）for the Session Initiation Protocol（SIP）：Framework and情報モデル」、RFC 6872、2013年2月。
Authors' Addresses
著者のアドレス
Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA
Paul E. Jones Cisco Systems、Inc. 7025 Kit Creek Rd。 Research Triangle Park、NC 27709 USA
Phone: +1 919 476 2048
EMail: paulej@packetizer.com
IM: xmpp:paulej@packetizer.com
Gonzalo Salgueiro Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA
Gonzalo Salgueiro Cisco Systems、Inc. 7025 Kit Creek Rd。Research Triangle Park、NC 27709 USA
Phone: +1 919 392 3266
EMail: gsalguei@cisco.com
IM: xmpp:gsalguei@cisco.com
James Polk Cisco Systems, Inc. 3913 Treemont Circle Colleyville, TX USA
James Polk Cisco Systems、Inc. 3913 Treemont Circle米国テキサス州コリービル
Phone: +1 817 271 3552
EMail: jmpolk@cisco.com
IM: xmpp:jmpolk@cisco.com
Laura Liess Deutsche Telekom NP 64295 Darmstadt Heinrich-Hertz-Str. 3-7 Germany
Laura Liess Deutsche Telekom NP 64295 Darmstadt Heinrich-Hertz-Str。 3-7ドイツ
Phone: +49 6151 268 2761 EMail: laura.liess.dt@gmail.com Hadriel Kaplan Oracle 71 Third Ave. Burlington, MA 01803 USA
電話：+49 6151 268 2761メール：laura.liess.dt@gmail.com Hadriel Kaplan Oracle 71 Third Ave. Burlington、MA 01803 USA
EMail: hadriel.kaplan@oracle.com