[要約] RFC 7989は、IPベースのマルチメディア通信ネットワークにおけるエンドツーエンドのセッション識別に関する要約です。このRFCの目的は、セッション識別のための標準化された手法を提供し、ネットワーク上のセッション管理を向上させることです。
Internet Engineering Task Force (IETF) P. Jones
Request for Comments: 7989 G. Salgueiro
Obsoletes: 7329 C. Pearce
Category: Standards Track P. Giralt
ISSN: 2070-1721 Cisco Systems, Inc.
October 2016
End-to-End Session Identification in IP-Based Multimedia Communication Networks
IPベースのマルチメディア通信ネットワークにおけるエンドツーエンドのセッション識別
Abstract
概要
This document describes an end-to-end session identifier for use in IP-based multimedia communication systems that enables endpoints, intermediary devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. While the identifier is intended to work across multiple protocols, this document describes its usage in the Session Initiation Protocol (SIP).
このドキュメントでは、エンドポイント、中間デバイス、および管理システムがセッションをエンドツーエンドで識別し、複数のエンドポイントを特定のマルチポイント会議に関連付け、追跡できるようにするIPベースのマルチメディア通信システムで使用するエンドツーエンドセッション識別子について説明しますリダイレクトされたときの通信セッション。1つ以上のメディアフローを特定の通信セッションに関連付けます。識別子は複数のプロトコルで機能することを目的としていますが、このドキュメントでは、セッション開始プロトコル（SIP）での使用について説明します。
This document also describes a backwards-compatibility mechanism for an existing session identifier implementation (RFC 7329) that is sufficiently different from the procedures defined in this document.
このドキュメントでは、このドキュメントで定義されている手順とは十分に異なる、既存のセッション識別子実装（RFC 7329）の下位互換性メカニズムについても説明します。
This document obsoletes RFC 7329.
このドキュメントはRFC 7329を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc7989.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7989で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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 ....................................................4
2. Conventions Used in This Document ...............................5
3. Session Identifier Definitions, Requirements, and Use Cases .....5
4. Constructing and Conveying the Session Identifier ...............5
4.1. Constructing the Session Identifier ........................5
4.2. Conveying the Session Identifier ...........................6
5. The Session-ID Header Field .....................................8
6. Endpoint Behavior ...............................................9
7. Processing by Intermediaries ...................................11
8. Handling of Remote UUID Changes ................................14
9. Associating Endpoints in a Multipoint Conference ...............16
10. Examples of Various Call Flow Operations ......................17
10.1. Basic Call with Two UUIDs ................................18
10.2. Basic Call Transfer Using REFER ..........................22
10.3. Basic Call Transfer Using Re-INVITE ......................24
10.4. Single Focus Conferencing ................................26
10.5. Single Focus Conferencing Using a Web-Based
Conference Service .......................................28
10.6. Cascading Conference Bridges .............................30
10.6.1. Establishing a Cascaded Conference ................30
10.6.2. Calling Into Cascaded Conference Bridges ..........31
10.7. Basic 3PCC for Two UAs ...................................33
10.8. Handling in 100 Trying SIP Response and CANCEL Request ...33
10.8.1. Handling in a 100 Trying SIP Response .............34
10.8.2. Handling a CANCEL SIP Request .....................35
10.9. Out-of-Dialog REFER Transaction ..........................36
11. Compatibility with a Previous Implementation ..................37
12. Security and Privacy Considerations ...........................39
13. IANA Considerations ...........................................40
13.1. Registration of the "Session-ID" Header Field ............40
13.2. Registration of the "remote" Parameter ...................40
14. References ....................................................41
14.1. Normative References .....................................41
14.2. Informative References ...................................42
Acknowledgements ..................................................44
Dedication ........................................................44
Authors' Addresses ................................................45
IP-based multimedia communication systems, such as Session Initiation Protocol (SIP) [RFC3261] and [H.323], 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）[RFC3261]や[H.323]などのIPベースのマルチメディア通信システムには、グローバルに一意の「コール識別子」という概念があります。識別子は、発信デバイスから終端デバイスへのエンドツーエンドの通信セッションを表すことを目的としています。このような識別子は、トラブルシューティング、セッション追跡などに役立ちます。
For several reasons, however, the current call identifiers defined in SIP and H.323 are not suitable for end-to-end session identification. A fundamental issue in protocol interworking is the fact that the syntax for the call identifier in SIP and H.323 is different. Thus, if both protocols are used in a call, it is impossible to exchange the call identifier end-to-end.
ただし、いくつかの理由により、SIPおよびH.323で定義されている現在のコール識別子は、エンドツーエンドのセッション識別には適していません。プロトコルインターワーキングの基本的な問題は、SIPとH.323のコールIDの構文が異なることです。したがって、コールで両方のプロトコルが使用されている場合、エンドツーエンドでコール識別子を交換することは不可能です。
Another reason why the current call identifiers are not suitable to identify a session end-to-end is that, in real-world deployments, devices such as session border controllers [RFC7092] often change the session signaling, including the value of the call identifier, as it passes through the device. While this is deliberate and useful, it makes it very difficult to track a session end-to-end.
現在のコール識別子がセッションをエンドツーエンドで識別するのに適していないもう1つの理由は、実際の展開では、セッションボーダーコントローラー[RFC7092]などのデバイスが、コール識別子の値を含むセッションシグナリングを変更することが多いためです。 、デバイスを通過するとき。これは意図的で有用ですが、セッションをエンドツーエンドで追跡することが非常に困難になります。
This document defines a new identifier, referred to as the "session identifier", that is intended to overcome the issues that exist with the currently defined call identifiers used in SIP and other IP-based communication systems. The identifier defined here has been adopted by the ITU ([H.460.27]) for use in H.323-based systems, allowing for the ability to trace a session end-to-end for sessions traversing both SIP and H.323-based systems. This document defines its use in SIP.
このドキュメントでは、「セッション識別子」と呼ばれる新しい識別子を定義します。これは、SIPおよびその他のIPベースの通信システムで使用される現在定義されている呼び出し識別子に存在する問題を克服することを目的としています。ここで定義された識別子は、H.323ベースのシステムで使用するためにITU（[H.460.27]）によって採用されており、SIPとH.323の両方を通過するセッションのセッションをエンドツーエンドで追跡することができます。ベースのシステム。このドキュメントでは、SIPでの使用について定義しています。
The procedures specified in this document attempt to comply with the requirements specified in [RFC7206]. The procedures also specify capabilities not mentioned in [RFC7206], shown in the call flows in Section 10. Additionally, this specification attempts to account for a previous, pre-standard version of a SIP session identifier header [RFC7329], specifying a backwards-compatibility approach in Section 11.
このドキュメントで指定された手順は、[RFC7206]で指定された要件に準拠することを試みます。この手順では、[RFC7206]に記載されていない機能も指定します。これは、セクション10のコールフローに示されています。さらに、この仕様では、SIPセッション識別子ヘッダー[RFC7329]の以前の先行標準バージョンを考慮して、後方を指定しています。セクション11の互換性アプローチ。
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] when they appear in ALL CAPS. These words may also appear in this document in lowercase, absent their normative meanings.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、それらがすべて大文字で現れる場合、[RFC2119]で説明されているように解釈されます。これらの単語は、規範的な意味がなければ、このドキュメントでは小文字で表示される場合もあります。
The term "session identifier" refers to the value of the identifier, whereas "Session-ID" refers to the header field used to convey the identifier. The session identifier is a set of two Universally Unique Identifiers (UUIDs) and each element of that set is simply referred to herein as a "UUID".
「セッション識別子」という用語は識別子の値を指し、「セッションID」は識別子を伝えるために使用されるヘッダーフィールドを指します。セッション識別子は、2つのUniversally Unique Identifier（UUID）のセットであり、そのセットの各要素は、ここでは単に「UUID」と呼ばれます。
Throughout this document, the term "endpoint" refers to a SIP User Agent (UA) that either initiates or terminates a SIP session, such as a user's mobile phone or a conference server, but excludes entities such as Back-to-Back User Agents (B2BUAs) that are generally located along the call-signaling path between endpoints. The term "intermediary" refers to any entity along the call-signaling path between the aforementioned endpoints, including B2BUAs and SIP proxies. In certain scenarios, intermediaries are allowed to originate and terminate SIP messages without an endpoint being part of the session or transaction. An intermediary may be performing interworking between different protocols (e.g., SIP and H.323) that support the session identifier defined in this document.
このドキュメント全体で、「エンドポイント」という用語は、ユーザーの携帯電話や会議サーバーなどのSIPセッションを開始または終了するSIPユーザーエージェント（UA）を指しますが、バックツーバックユーザーエージェントなどのエンティティは除外します（B2BUA）一般に、エンドポイント間のコールシグナリングパスに沿って配置されます。 「中間」という用語は、B2BUAやSIPプロキシを含む、前述のエンドポイント間のコールシグナリングパスに沿ったエンティティを指します。特定のシナリオでは、エンドポイントがセッションまたはトランザクションの一部でなくても、仲介者がSIPメッセージを発信および終了できます。仲介者は、このドキュメントで定義されているセッション識別子をサポートする異なるプロトコル（SIPやH.323など）間のインターワーキングを実行している可能性があります。
Requirements and use cases for the end-to-end session identifier, along with the definition of "session identifier", "communication session", and "end-to-end" can be found in [RFC7206]. Throughout this document, the term "session" refers to a "communication session" as defined in [RFC7206].
エンドツーエンドセッション識別子の要件と使用例、および「セッション識別子」、「通信セッション」、および「エンドツーエンド」の定義は、[RFC7206]にあります。このドキュメント全体を通して、「セッション」という用語は、[RFC7206]で定義されている「通信セッション」を指します。
As mentioned in Section 6.1 of [RFC7206], the ITU-T undertook a parallel effort to define compatible procedures for an H.323 session identifier. They are documented in [H.460.27].
[RFC7206]のセクション6.1で述べたように、ITU-TはH.323セッション識別子の互換性のある手順を定義するために並行して取り組みました。それらは[H.460.27]で文書化されています。
The session identifier comprises two UUIDs [RFC4122], with each UUID representing one of the endpoints participating in the session.
セッション識別子は2つのUUID [RFC4122]で構成され、各UUIDはセッションに参加しているエンドポイントの1つを表します。
The version number in the UUID indicates the manner in which the UUID is generated, such as using random values or using the Media Access Control (MAC) address of the endpoint. To satisfy the requirement that no user or device information be conveyed, endpoints MUST generate version 4 (random) or version 5 (SHA-1) UUIDs to address privacy concerns related to the use of MAC addresses in UUIDs.
UUIDのバージョン番号は、ランダムな値を使用したり、エンドポイントのメディアアクセス制御（MAC）アドレスを使用したりするなど、UUIDが生成される方法を示します。ユーザーまたはデバイス情報が伝達されないという要件を満たすために、エンドポイントはバージョン4（ランダム）またはバージョン5（SHA-1）UUIDを生成して、UUIDでのMACアドレスの使用に関連するプライバシーの問題に対処する必要があります。
When generating a version 5 UUID, endpoints or intermediaries MUST utilize the procedures defined in Section 4.3 of [RFC4122] and employ the following "namespace ID":
バージョン5のUUIDを生成する場合、エンドポイントまたは仲介者は[RFC4122]のセクション4.3で定義された手順を使用し、次の「名前空間ID」を使用する必要があります。
uuid_t NameSpace_SessionID = {
/* a58587da-c93d-11e2-ae90-f4ea67801e29 */
0xa58587da,
0xc93d,
0x11e2,
0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
};
Further, the "name" to utilize for version 5 UUIDs is the concatenation of the Call-ID header-value and the "tag" parameter that appears on the "From" or "To" line associated with the device for which the UUID is created. Once an endpoint generates a UUID for a session, the UUID never changes, even if values originally used as input into its construction change over time.
さらに、バージョン5のUUIDに使用する「名前」は、Call-IDヘッダー値と、UUIDが存在するデバイスに関連付けられている「From」または「To」行に表示される「tag」パラメーターを連結したものです。作成した。エンドポイントがセッションのUUIDを生成すると、その構成への入力として最初に使用された値が時間とともに変化しても、UUIDは決して変更されません。
Stateless intermediaries that insert a Session-ID header field into a SIP message on behalf of an endpoint MUST utilize version 5 UUIDs to ensure that UUIDs for the communication session are consistently generated. If a stateless intermediary does not know the tag value for the endpoint (e.g., a new INVITE request without a To: tag value or an older SIP implementation [RFC2543] that did not include a "tag" parameter), the intermediary MUST NOT attempt to generate a UUID for that endpoint. Note that, if an intermediary is stateless and the endpoint on one end of the call is replaced with another endpoint due to some service interaction, the values used to create the UUID should change and, if so, the intermediary will compute a different UUID.
エンドポイントに代わってSIPメッセージにSession-IDヘッダーフィールドを挿入するステートレス仲介者は、バージョン5 UUIDを使用して、通信セッションのUUIDが一貫して生成されるようにする必要があります。ステートレスな仲介者がエンドポイントのタグ値を知らない場合（たとえば、「タグ」パラメータを含まないTo：タグ値または古いSIP実装[RFC2543]のない新しいINVITEリクエスト）、仲介者は試みてはいけません（MUST NOT）そのエンドポイントのUUIDを生成します。仲介者がステートレスであり、サービスの相互作用により、通話の一端のエンドポイントが別のエンドポイントに置き換えられた場合、UUIDの作成に使用される値が変更されます。変更された場合、仲介者は別のUUIDを計算します。
The SIP User Agent (UA) initiating a new session by transmitting a SIP request ("Alice"), i.e., a User Agent Client (UAC), MUST create a new, previously unused UUID and transmit that to the ultimate destination UA ("Bob"). Likewise, the destination UA ("Bob"), i.e., a User Agent Server (UAS), MUST create a new, previously unused UUID and transmit that to the first UA ("Alice"). These two distinct UUIDs form what is referred to as the "session identifier" and is represented in this document in set notation of the form {A,B}, where "A" is UUID value created by UA "Alice" and "B" is the UUID value created by UA "Bob". The session identifier {A,B} is equal to the session identifier {B,A}. Section 6 describes how the UUIDs selected by the source and destination UAs persist for the duration of the session.
SIPユーザーエージェント（UA）は、SIPリクエスト（ "Alice"）を送信して新しいセッションを開始します。つまり、ユーザーエージェントクライアント（UAC）は、以前に未使用の新しいUUIDを作成し、それを最終的な宛先UA（ "ボブ"）。同様に、宛先UA（ "Bob"）、つまりユーザーエージェントサーバー（UAS）は、以前に未使用の新しいUUIDを作成し、それを最初のUA（ "Alice"）に送信する必要があります。これら2つの異なるUUIDは、「セッション識別子」と呼ばれるものを形成し、このドキュメントでは{A、B}の形式のセット表記で表されます。ここで、「A」はUA「Alice」および「B」によって作成されたUUID値です。 UA "Bob"によって作成されたUUID値です。セッション識別子{A、B}は、セッション識別子{B、A}と同じです。セクション6では、ソースUAと宛先UAによって選択されたUUIDがセッションの間どのように存続するかについて説明します。
In the case where only one UUID is known, such as when a UA first initiates a potentially dialog-initiating SIP request, the session identifier would be {A,N}, where "A" represents the UUID value transmitted by the UA "Alice", and "N" is what is referred to as the "nil UUID" [RFC4122] (see Section 5 of this document).
UAがダイアログを開始する可能性のあるSIPリクエストを最初に開始するときなど、UUIDが1つしかわからない場合、セッション識別子は{A、N}になります。ここで、「A」はUAによって送信されたUUID値を表します"、および" N "は" nil UUID "[RFC4122]と呼ばれるものです（このドキュメントのセクション5を参照）。
Since SIP sessions are subject to any number of service interactions, SIP INVITE requests might be forked as sessions are established, and since conferences might be established or expanded with endpoints calling in or the conference focus calling out, the construction of the session identifier as a set of UUIDs is important.
SIPセッションは任意の数のサービスの相互作用の影響を受けるため、セッションが確立されるとSIP INVITE要求が分岐する可能性があります。また、エンドポイントの呼び出しまたは会議のフォーカスの呼び出しで会議が確立または拡張される可能性があるため、セッション識別子の構築はUUIDのセットは重要です。
To understand this better, consider that an endpoint participating in a communication session might be replaced with another, such as the case where two "legs" of a call are joined together by a Private Branch Exchange (PBX). Suppose "Alice" and "Bob" both call UA "C" ("Carol"). There would be two distinctly identifiable session identifiers, namely {A,C} and {B,C}. Then, suppose that "Carol" uses a local PBX function to join the call between herself and "Alice" with the call between herself and "Bob", resulting in a single remaining call between "Alice" and "Bob". This merged call can be identified using two UUID values assigned by each entity in the communication session, namely {A,B} in this example.
これをよりよく理解するには、通話の2つの「レッグ」が構内交換機（PBX）によって結合されている場合など、通信セッションに参加しているエンドポイントが別のエンドポイントに置き換えられる可能性があることを考慮してください。 「アリス」と「ボブ」の両方がUAを「C」（「キャロル」）と呼ぶとします。 2つの明確に識別可能なセッション識別子、つまり{A、C}と{B、C}があります。次に、「キャロル」がローカルPBX機能を使用して、自分と「アリス」の間の通話を自分と「ボブ」の間の通話に参加させ、「アリス」と「ボブ」の間の通話が1つ残ったとします。このマージされたコールは、通信セッションの各エンティティ、つまりこの例では{A、B}によって割り当てられた2つのUUID値を使用して識別できます。
In the case of forking, "Alice" might send an INVITE request that gets forked to several different endpoints. A means of identifying each of these separate communication sessions is needed; since each of the destination UAs will create its own UUID, each communication session would be uniquely identified by the values {A, B1}, {A, B2}, {A, B3}, and so on, where each of the Bn values refers to the UUID created by the different UAs to which the SIP session is forked.
分岐の場合、「Alice」は分岐したINVITEリクエストをいくつかの異なるエンドポイントに送信する場合があります。これらの個別の通信セッションのそれぞれを識別する手段が必要です。各宛先UAは独自のUUIDを作成するため、各通信セッションは{A、B1}、{A、B2}、{A、B3}などの値によって一意に識別され、各Bn値はSIPセッションがフォークされるさまざまなUAによって作成されたUUIDを指します。
For conferencing scenarios, it is also useful to have a two-part session identifier where the conference focus specifies the same UUID for each conference participant. This allows for correlation among the participants in a single conference. For example, in a conference with three participants, the session identifiers might be {A,M}, {B,M}, and {C,M}, where "M" is assigned by the conference focus. Only a conference focus will purposely utilize the same UUID for more than one SIP session and, even then, such reuse MUST be restricted to the participants in the same conference.
会議シナリオでは、会議のフォーカスが各会議参加者に同じUUIDを指定する2部構成のセッションIDを持つことも役立ちます。これにより、1つの会議の参加者間の相関が可能になります。たとえば、3人の参加者がいる会議の場合、セッションIDは{A、M}、{B、M}、および{C、M}で、会議のフォーカスによって「M」が割り当てられます。会議のフォーカスのみが意図的に同じUUIDを複数のSIPセッションに利用し、その場合でも、そのような再利用は同じ会議の参加者に制限する必要があります。
How a device acting on session identifiers processes or utilizes the session identifier is outside the scope of this document. However, devices storing a session identifier in a log file SHOULD follow the security considerations outlined in [RFC6872]. Note that the primary intent of a session identifier is for troubleshooting; therefore, it should be included in logs at rest that will be used for troubleshooting purposes.
セッション識別子に作用するデバイスがセッション識別子を処理または利用する方法は、このドキュメントの範囲外です。ただし、ログファイルにセッション識別子を格納するデバイスは、[RFC6872]で概説されているセキュリティの考慮事項に従う必要があります（SHOULD）。セッション識別子の主な目的はトラブルシューティングのためであることに注意してください。したがって、トラブルシューティングの目的で使用される保存中のログに含める必要があります。
This document replaces the definition of the "Session-ID" token that was added to the definition of the element "message-header" in the SIP message grammar by [RFC7329]. The Session-ID header is a single-instance header.
このドキュメントは、[RFC7329]によってSIPメッセージ文法の要素「message-header」の定義に追加された「Session-ID」トークンの定義を置き換えます。 Session-IDヘッダーは単一インスタンスのヘッダーです。
Each endpoint participating in a communication session has a distinct, preferably locally generated UUID associated with it. The endpoint's UUID value remains unchanged throughout the duration of the communication session. Multipoint conferences can bridge sessions from multiple endpoints and impose unique requirements defined in Section 9. An intermediary MAY generate a UUID on behalf of an endpoint that did not include a UUID of its own.
通信セッションに参加している各エンドポイントには、個別の、できればローカルで生成されたUUIDが関連付けられています。エンドポイントのUUID値は、通信セッションの間中、変更されません。マルチポイント会議は、複数のエンドポイントからのセッションをブリッジし、セクション9で定義された固有の要件を課すことができます。中間者は、独自のUUIDを含まないエンドポイントに代わってUUIDを生成できます。
The UUID values for each endpoint are inserted into the Session-ID header field of all transmitted SIP messages. The Session-ID header field has the following ABNF [RFC5234] syntax:
各エンドポイントのUUID値は、送信されるすべてのSIPメッセージのSession-IDヘッダーフィールドに挿入されます。 Session-IDヘッダーフィールドには、次のABNF [RFC5234]構文があります。
session-id = "Session-ID" HCOLON session-id-value
session-id = "Session-ID" HCOLON session-id-value
session-id-value = local-uuid *(SEMI sess-id-param)
セッションID値= local-uuid *（SEMI sess-id-param）
local-uuid = sess-uuid / nil
remote-uuid = sess-uuid / nil
sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f]
sess-id-param = remote-param / generic-param
remote-param = "remote" EQUAL remote-uuid
remote-param = "remote" EQUAL remote-uuid
nil = 32("0")
nil = 32（ "0"）
The productions "SEMI", "EQUAL", and "generic-param" are defined in [RFC3261]. The production DIGIT is defined in [RFC5234].
プロダクション「SEMI」、「EQUAL」、および「generic-param」は、[RFC3261]で定義されています。プロダクションDIGITは[RFC5234]で定義されています。
The Session-ID header field MUST NOT have more than one "remote" parameter. In the case where an entity compliant with this specification is interworking with an entity that implemented a session identifier as defined in [RFC7329], the "remote" parameter may be absent; otherwise, the "remote" parameter MUST be present. The details under which those conditions apply are described in Section 11. Except for backwards compatibility with [RFC7329], the "remote" parameter MUST be present.
Session-IDヘッダーフィールドには、複数の「リモート」パラメーターを含めることはできません。この仕様に準拠するエンティティが、[RFC7329]で定義されているセッション識別子を実装したエンティティと相互作用している場合、「リモート」パラメータが存在しない場合があります。それ以外の場合は、「リモート」パラメータが存在する必要があります。これらの条件が適用される詳細は、セクション11で説明されています。[RFC7329]との下位互換性を除いて、「リモート」パラメーターが存在しなければなりません（MUST）。
A special nil UUID value composed of 32 zeros is required in certain situations. A nil UUID is expected as the "remote-uuid" of every initial standard SIP request since the initiating endpoint would not initially know the UUID value of the remote endpoint. This nil value will get replaced by the ultimate destination UAS when that UAS generates a response message. One caveat is explained in Section 11 for a possible backwards-compatibility case. A nil UUID value is also returned by some intermediary devices that send provisional or other responses as the "local-uuid" component of the Session-ID header field value, as described in Section 7.
特定の状況では、32個のゼロで構成される特別なnil UUID値が必要です。開始エンドポイントは最初にリモートエンドポイントのUUID値を知らないため、nil UUIDはすべての初期標準SIPリクエストの「リモートuuid」として予期されます。このnil値は、そのUASが応答メッセージを生成するときに、最終的な宛先UASに置き換えられます。後方互換性の可能性のあるケースについては、セクション11で1つの警告が説明されています。セクション7で説明するように、暫定応答またはその他の応答をSession-IDヘッダーフィールド値の「local-uuid」コンポーネントとして送信する一部の中間デバイスからも、nil UUID値が返されます。
The "local-uuid" in the Session-ID header field represents the UUID value of the endpoint transmitting a message and the "remote-uuid" in the Session-ID header field represents the UUID of the endpoint's peer. For example, a Session-ID header field might appear like this:
Session-IDヘッダーフィールドの「local-uuid」は、メッセージを送信するエンドポイントのUUID値を表し、Session-IDヘッダーフィールドの「remote-uuid」は、エンドポイントのピアのUUIDを表します。たとえば、Session-IDヘッダーフィールドは次のようになります。
Session-ID: ab30317f1a784dc48ff824d0d3715d86;
remote=47755a9de7794ba387653f2099600ef2
While this is the general form of the Session-ID header field, exceptions to syntax and procedures are detailed in subsequent sections.
これはSession-IDヘッダーフィールドの一般的な形式ですが、構文と手順の例外については、後続のセクションで詳しく説明します。
The UUID values are presented as strings of lowercase hexadecimal characters, with the most significant octet of the UUID appearing first.
UUID値は小文字の16進文字のストリングとして提示され、UUIDの最上位オクテットが最初に表示されます。
To comply with this specification, endpoints (non-intermediaries) MUST include a Session-ID header field value in all SIP messages transmitted as a part of a communication session. The locally generated UUID of the transmitter of the message MUST appear in the "local-uuid" portion of the Session-ID header field value. The UUID of the peer device, if known, MUST appear as the "remote" parameter following the transmitter's UUID. The nil UUID value MUST be used if the peer device's UUID is not known.
この仕様に準拠するために、エンドポイント（中間ではない）は、通信セッションの一部として送信されるすべてのSIPメッセージにSession-IDヘッダーフィールド値を含める必要があります。メッセージの送信者のローカルで生成されたUUIDは、Session-IDヘッダーフィールド値の「local-uuid」部分に表示される必要があります。ピアデバイスのUUIDがわかっている場合は、トランスミッターのUUIDに続く「リモート」パラメーターとして表示する必要があります。ピアデバイスのUUIDが不明な場合は、nil UUID値を使用する必要があります。
Once an endpoint allocates a UUID value for a communication session, the endpoint originating the request MUST NOT change that UUID value for the duration of the session, including when:
エンドポイントが通信セッションにUUID値を割り当てると、リクエストを発信したエンドポイントは、次の場合を含め、セッションの期間中そのUUID値を変更してはなりません（MUST NOT）。
o communication attempts are retried due to receipt of 4xx messages or request timeouts;
o 4xxメッセージの受信または要求のタイムアウトにより、通信の試行が再試行されます。
o the session is redirected in response to a 3xx message;
o セッションは3xxメッセージに応答してリダイレクトされます。
o a session is transferred via a REFER message [RFC3515]; or
o セッションは、REFERメッセージ[RFC3515]を介して転送されます。または
o a SIP dialog is replaced via an INVITE request with Replaces [RFC3891].
o SIPダイアログは、INVITEリクエストによってReplaces [RFC3891]に置き換えられます。
An endpoint that receives a Session-ID header field MUST take note of any non-nil "local-uuid" value that it receives and assume that is the UUID of the peer endpoint within that communication session. Endpoints MUST include this received UUID value as the "remote" parameter when transmitting subsequent messages, making sure not to change this UUID value in the process of moving the value internally from the "local-uuid" field to the "remote-uuid" field.
セッションIDヘッダーフィールドを受信するエンドポイントは、受信するnil以外の「local-uuid」値に注意し、その通信セッション内のピアエンドポイントのUUIDであると想定する必要があります。エンドポイントは、後続のメッセージを送信するときに、この受信したUUID値を「リモート」パラメーターとして含めなければならず、値を「local-uuid」フィールドから「remote-uuid」フィールドに内部的に移動するプロセスでこのUUID値を変更しないようにします。 。
If an endpoint receives a 3xx message, a REFER that directs the endpoint to a different peer, or an INVITE request with Replaces that also potentially results in communicating with a new peer, the endpoint MUST complete any message exchanges with its current peer using the existing session identifier, but it MUST NOT use the current peer's UUID value when sending the first message to what it believes may be a new peer endpoint (even if the exchange results in communicating with the same physical or logical entity). The endpoint MUST retain its own UUID value, however, as described above.
エンドポイントが3xxメッセージ、エンドポイントを別のピアに送信するREFER、または新しいピアとの通信にもつながる可能性のあるReplacesを含むINVITE要求を受信した場合、エンドポイントは既存のピアを使用して現在のピアとのメッセージ交換を完了する必要があります。セッション識別子。ただし、最初のメッセージを新しいピアエンドポイントであると考えられるものに送信するときに、現在のピアのUUID値を使用してはなりません（交換によって同じ物理エンティティまたは論理エンティティと通信する場合でも）。ただし、前述のように、エンドポイントは独自のUUID値を保持する必要があります。
It should be noted that messages received by an endpoint might contain a "local-uuid" value that does not match what the endpoint expected its peer's UUID to be. It is also possible for an endpoint to receive a "remote-uuid" value that does not match its generated UUID for the session. Either might happen as a result of service interactions by intermediaries and MUST NOT affect how the endpoint processes the session; however, the endpoint may log this event for troubleshooting purposes.
エンドポイントが受信したメッセージには、エンドポイントがピアのUUIDであると予測したものと一致しない「local-uuid」値が含まれている可能性があることに注意してください。エンドポイントが、セッション用に生成されたUUIDと一致しない「remote-uuid」値を受け取る可能性もあります。仲介者によるサービスの相互作用の結果として発生する可能性があり、エンドポイントがセッションを処理する方法に影響を与えてはなりません。ただし、エンドポイントはトラブルシューティングの目的でこのイベントを記録する場合があります。
An endpoint MUST assume that the UUID value of the peer endpoint may change at any time due to service interactions. Section 8 discusses how endpoints must handle remote UUID changes.
エンドポイントは、サービスの相互作用により、ピアエンドポイントのUUID値がいつでも変更される可能性があると想定する必要があります。セクション8では、エンドポイントがリモートUUIDの変更を処理する方法について説明します。
It is also important to note that if an intermediary in the network forks a session, the endpoint initiating a session may receive multiple responses back from different endpoints, each of which contains a different UUID ("local-uuid") value. Endpoints MUST ensure that the correct UUID value is returned in the "remote" parameter when interacting with each endpoint. The one exception is when the endpoint sends a CANCEL request, in which case the Session-ID header field value MUST be identical to the Session-ID header field value sent in the original request.
また、ネットワークの仲介者がセッションをフォークした場合、セッションを開始するエンドポイントは、それぞれが異なるUUID（ "local-uuid"）値を含む異なるエンドポイントから複数の応答を受信する場合があることに注意することも重要です。エンドポイントは、各エンドポイントと対話するときに、「リモート」パラメーターで正しいUUID値が返されることを確認する必要があります。 1つの例外は、エンドポイントがCANCEL要求を送信する場合です。この場合、Session-IDヘッダーフィールドの値は、元の要求で送信されたSession-IDヘッダーフィールドの値と同じである必要があります。
If an endpoint receives a message that does not contain a Session-ID header field, that message must have no effect on what the endpoint believes is the UUID value of the remote endpoint. That is, the endpoint MUST NOT change the internally maintained "remote-uuid" value for the peer.
エンドポイントがセッションIDヘッダーフィールドを含まないメッセージを受信した場合、そのメッセージは、エンドポイントがリモートエンドポイントのUUID値であると信じていることに影響を与えてはなりません。つまり、エンドポイントは、ピアに対して内部的に維持されている「remote-uuid」値を変更してはなりません（MUST NOT）。
If an endpoint receives a SIP response with a non-nil "local-uuid" that is not 32 octets long, this response comes from a misbehaving implementation, and its Session-ID header field MUST be discarded. That said, the response might still be valid according to the rules within SIP [RFC3261], and it SHOULD be checked further.
エンドポイントが32オクテットではないnil以外の「local-uuid」を含むSIP応答を受信した場合、この応答は動作が正しくない実装からのものであり、そのSession-IDヘッダーフィールドは破棄する必要があります。そうは言っても、応答はSIP [RFC3261]内のルールに従って依然として有効である可能性があり、さらに確認する必要があります。
A Multipoint Control Unit (MCU) is a special type of conferencing endpoint and is discussed in Section 9.
マルチポイントコントロールユニット（MCU）は特別なタイプの会議エンドポイントであり、セクション9で説明します。
The following applies only to an intermediary that wishes to comply with this specification and does not impose a conformance requirement on intermediaries that elect not to provide any special treatment for the Session-ID header field. Intermediaries that do not comply with this specification might pass the header unchanged or drop it entirely.
以下は、この仕様に準拠することを希望する仲介者にのみ適用され、Session-IDヘッダーフィールドに特別な処理を提供しないことを選択する仲介者に適合要件を課しません。この仕様に準拠しない仲介者は、ヘッダーを変更せずに渡すか、完全に削除する可能性があります。
The Call-ID often reveals personal, device, domain, or other sensitive information associated with a user, which is one reason why intermediaries, such as session border controllers, sometimes alter the Call-ID. In order to ensure the integrity of the end-to-end session identifier, it is constructed in a way that does not reveal such information, removing the need for intermediaries to alter it.
Call-IDは、ユーザーに関連付けられた個人情報、デバイス、ドメイン、またはその他の機密情報を明らかにすることがよくあります。これが、セッションボーダーコントローラーなどの仲介者がCall-IDを変更する理由の1つです。エンドツーエンドのセッション識別子の整合性を確保するために、そのような情報を公開しない方法で構築され、仲介者が情報を変更する必要がなくなります。
When an intermediary receives messages from one endpoint in a communication session that causes the transmission of one or more messages toward the second endpoint in a communication session, the intermediary MUST include the Session-ID header field in the transmitted messages with the same UUID values found in the received message, except as outlined in this section and in Section 8.
仲介者が通信セッションの2番目のエンドポイントに向けて1つ以上のメッセージを送信する通信セッションの1つのエンドポイントからメッセージを受信する場合、仲介者は同じUUID値が見つかった送信メッセージにセッションIDヘッダーフィールドを含める必要がありますこのセクションとセクション8で概説されている場合を除き、受信したメッセージ内。
If the intermediary aggregates several responses from different endpoints, as described in Section 16.7 of [RFC3261], the intermediary MUST set the local-uuid field to the nil UUID value when forwarding the aggregated response to the endpoint since the true UUID value of the peer is undetermined at that point. Note that an intermediary that does not implement this specification might forward a non-nil value, resulting in the originating endpoint receiving different UUID values in the responses. It is possible for this to result in the endpoint temporarily using the wrong remote UUID. Subsequent messages in the dialog should resolve the temporary mismatch as long as the endpoint follows the rules outlined in Section 8 dealing with the handling of remote UUID changes.
[RFC3261]のセクション16.7で説明されているように、仲介者が異なるエンドポイントからいくつかの応答を集約する場合、ピアの真のUUID値以降、仲介者は集約された応答をエンドポイントに転送するときにlocal-uuidフィールドをnil UUID値に設定する必要がありますその時点では未定です。この仕様を実装していない仲介者は、nil以外の値を転送する可能性があることに注意してください。その結果、元のエンドポイントは、応答で異なるUUID値を受け取ります。これにより、エンドポイントが一時的に誤ったリモートUUIDを使用する可能性があります。ダイアログの後続のメッセージは、エンドポイントがリモートUUIDの変更の処理を扱うセクション8で概説されているルールに従う限り、一時的な不一致を解決する必要があります。
Intermediary devices that transfer a call, such as by joining together two different "call legs", MUST properly construct a Session-ID header field that contains the UUID values associated with the endpoints involved in the joined session and correct placement of those values. As described in Section 6, the endpoint receiving a message transmitted by the intermediary will assume that the first UUID value belongs to its peer endpoint.
2つの異なる「コールレッグ」を結合するなどして、コールを転送する中間デバイスは、結合されたセッションに関係するエンドポイントに関連付けられたUUID値を含むSession-IDヘッダーフィールドを適切に構築し、それらの値を正しく配置する必要があります。セクション6で説明したように、中間者によって送信されたメッセージを受信するエンドポイントは、最初のUUID値がそのピアエンドポイントに属していると想定します。
If an intermediary receives a SIP message without a Session-ID header field or valid header field value from an endpoint for which the intermediary is not storing a "remote-uuid" value, the intermediary MAY assign a "local-uuid" value to represent that endpoint and, having done so, MUST insert that assigned value into all signaling messages on behalf of the endpoint for that dialog. In effect, the intermediary becomes dialog-stateful, and it MUST follow the endpoint procedures in Section 6 with respect to Session-ID header field value treatment with itself acting as the endpoint (for the purposes of the Session-ID header field) for which it inserted a component into the Session-ID header field value. If the intermediary is aware of the UUID value that identifies the endpoint to which a message is directed, it MUST insert that UUID value into the Session-ID header field value as the "remote-uuid" value. If the intermediary is unaware of the UUID value that identifies the receiving endpoint, it MUST use the nil UUID value as the "remote-uuid" value.
仲介者が "remote-uuid"値を格納していないエンドポイントから、Session-IDヘッダーフィールドまたは有効なヘッダーフィールド値のないSIPメッセージを受信した場合、仲介者は "local-uuid"値を割り当てて、そのエンドポイント、そしてそうした場合、そのダイアログのエンドポイントに代わって、割り当てられた値をすべてのシグナリングメッセージに挿入する必要があります。事実上、仲介者はダイアログステートフルになり、それ自体が（Session-IDヘッダーフィールドの目的で）エンドポイントとして機能するSession-IDヘッダーフィールド値の処理に関して、セクション6のエンドポイント手順に従う必要があります。コンポーネントをSession-IDヘッダーフィールド値に挿入しました。仲介者がメッセージの送信先のエンドポイントを識別するUUID値を認識している場合は、そのUUID値を「リモートuuid」値としてSession-IDヘッダーフィールド値に挿入する必要があります。仲介者が受信エンドポイントを識別するUUID値を認識していない場合は、「リモートUUID」値としてnil UUID値を使用する必要があります。
If an intermediary receives a SIP message without a Session-ID header field or a valid Session-ID header field value from an endpoint for which the intermediary has previously received a Session-ID and is storing a "remote-uuid" value for that endpoint, the lack of a Session-ID must have no effect on what the intermediary believes is the UUID value of the endpoint. That is, the intermediary MUST NOT change the internally maintained "remote-uuid" value for the peer.
仲介者がSession-IDヘッダーフィールドまたは有効なSession-IDヘッダーフィールド値のないSIPメッセージを、仲介者が以前にSession-IDを受信し、そのエンドポイントの「remote-uuid」値を格納しているエンドポイントから受信した場合、Session-IDの欠如は、仲介者がエンドポイントのUUID値であると信じていることに影響を与えてはなりません。つまり、仲介者は内部的に維持されているピアの "remote-uuid"値を変更してはなりません（MUST NOT）。
When an intermediary originates a response, such as a provisional response or a response to a CANCEL request, the "remote-uuid" field will contain the UUID value of the receiving endpoint. When the UUID of the peer endpoint is known, the intermediary MUST insert the UUID of the peer endpoint in the "local-uuid" field of the header value.
仲介者が暫定応答やCANCEL要求への応答などの応答を発信すると、「remote-uuid」フィールドには受信側エンドポイントのUUID値が含まれます。ピアエンドポイントのUUIDがわかっている場合、仲介者は、ヘッダー値の「local-uuid」フィールドにピアエンドポイントのUUIDを挿入する必要があります。
Otherwise, the intermediary MAY set the "local-uuid" field of the header value to the "nil" UUID value.
それ以外の場合、仲介者はヘッダー値の「local-uuid」フィールドを「nil」のUUID値に設定できます（MAY）。
When an intermediary originates a request message without first having received a SIP message that triggered the transmission of the message (e.g., sending a BYE message to terminate a call for policy reasons), the intermediary MUST, if it has knowledge of the UUID values for the two communicating endpoints, insert a Session-ID header field with the "remote-uuid" field of the header value set to the UUID value of the receiving endpoint and the "local-uuid" field of the header value set to the UUID value of the other endpoint. When the intermediary does not have knowledge of the UUID value of an endpoint in the communication session, the intermediary SHOULD set the unknown UUID value(s) to the "nil" UUID value. (If both are unknown, the Session-ID header value SHOULD NOT be included at all, since it would have no practical value.)
仲介者が最初にメッセージの送信をトリガーしたSIPメッセージを受信せずに要求メッセージを発信した場合（たとえば、ポリシー上の理由でBYEメッセージを送信して通話を終了する）、仲介者は、UUID値の知識がある場合通信する2つのエンドポイント。ヘッダー値の「remote-uuid」フィールドを受信側エンドポイントのUUID値に設定し、ヘッダー値の「local-uuid」フィールドをUUID値に設定したSession-IDヘッダーフィールドを挿入します。他のエンドポイントの。仲介者が通信セッションのエンドポイントのUUID値を認識していない場合、仲介者は不明なUUID値を「nil」のUUID値に設定する必要があります（SHOULD）。 （両方とも不明な場合、実用的な値がないため、Session-IDヘッダー値を含めないでください。）
With respect to the previous two paragraphs, note that if an intermediary transmits a "nil" UUID value, the receiving endpoint might use that value in subsequent messages it sends. This effectively violates the requirement of maintaining an end-to-end session identifier value for the communication session if a UUID for the peer endpoint had been previously conveyed. Therefore, an intermediary MUST only send the "nil" UUID when the intermediary has not communicated with the peer endpoint to learn its UUID. This means that intermediaries SHOULD maintain state related to the UUID values for both ends of a communication session if it intends to originate messages (versus merely conveying messages). An intermediary that does not maintain this state and that originates a message as described in the previous two paragraphs MUST NOT insert a Session-ID header field in order to avoid unintended, incorrect reassignment of a UUID value.
前の2つの段落に関して、中間者が「nil」のUUID値を送信する場合、受信側エンドポイントは、送信する後続のメッセージでその値を使用する可能性があることに注意してください。これは、ピアエンドポイントのUUIDが以前に伝達されていた場合、通信セッションのエンドツーエンドセッション識別子の値を維持するという要件に実質的に違反しています。したがって、仲介者がUUIDを学習するためにピアエンドポイントと通信していない場合にのみ、仲介者は「nil」のUUIDを送信する必要があります。これは、仲介者が（単にメッセージを伝達するのではなく）メッセージを発信する場合、通信セッションの両端のUUID値に関連する状態を維持する必要があることを意味します。この状態を維持せず、前の2つの段落で説明したようにメッセージを発信する仲介者は、UUID値の意図しない誤った再割り当てを回避するために、Session-IDヘッダーフィールドを挿入してはなりません（MUST NOT）。
The Session-ID header field value included in a CANCEL request MUST be identical to the Session-ID header field value included in the corresponding request being cancelled.
CANCELリクエストに含まれるSession-IDヘッダーフィールド値は、キャンセルされる対応するリクエストに含まれるSession-IDヘッダーフィールド値と同一である必要があります。
If a SIP intermediary initiates a dialog between two endpoints in a third-party call control (3PCC [RFC3725]) scenario, the initial INVITE request will have a non-nil, locally fabricated "local-uuid" value; call this temporary UUID "X". The request will still have a nil "remote-uuid" value; call this value "N". The SIP server MUST be transaction-stateful. The UUID pair in the INVITE request will be {X,N}. A 1xx or 2xx response will have a UUID pair {A,X}. This transaction-stateful, dialog-initiating SIP server MUST replace its own UUID, i.e.,"X", with a nil UUID (i.e., {A,N}) in the INVITE request sent towards the other UAS as expected (see Section 10.7 for an example).
SIP仲介者がサードパーティコール制御（3PCC [RFC3725]）シナリオで2つのエンドポイント間のダイアログを開始する場合、最初のINVITEリクエストには、nil以外のローカルで作成された「local-uuid」値があります。この一時的なUUIDを「X」と呼びます。リクエストにはまだnil "remote-uuid"値があります。この値を「N」と呼びます。 SIPサーバーはトランザクションステートフルである必要があります。 INVITEリクエストのUUIDペアは{X、N}になります。 1xxまたは2xx応答には、UUIDペア{A、X}があります。このトランザクションステートフルでダイアログを開始するSIPサーバーは、他のUASに向けて送信されたINVITEリクエストで、自身のUUID、つまり「X」をnil UUID（つまり、{A、N}）に置き換える必要があります（セクション10.7を参照）。例）。
Intermediaries that manipulate messages containing a Session-ID header field SHOULD be aware of what UUID values it last sent towards an endpoint and, following any kind of service interaction initiated or affected by the intermediary, what UUID values the receiving endpoint should have knowledge of to ensure that both endpoints in the session have the correct and same UUID values. If an intermediary can determine that an endpoint might not have received a current, correct Session-ID field, the intermediary SHOULD attempt to provide the correct Session-ID header field to the endpoint such as by sending a re-INVITE request. Failure to take such measures may make troubleshooting more difficult because of the mismatched identifiers; therefore, it is strongly advised that intermediaries attempt to provide the correct session identifier if able to do so.
Session-IDヘッダーフィールドを含むメッセージを操作する仲介者は、エンドポイントに向けて最後に送信したUUID値を認識している必要があり、仲介者によって開始または影響を受けたあらゆる種類のサービス相互作用に続いて、受信エンドポイントが知っている必要があるUUID値セッションの両方のエンドポイントが正しい同じUUID値を持っていることを確認してください。エンドポイントが現在の正しいSession-IDフィールドを受信していない可能性があると中間者が判断できる場合、中間者は、re-INVITEリクエストを送信するなどして、正しいSession-IDヘッダーフィールドをエンドポイントに提供する必要があります（SHOULD）。このような対策を講じないと、識別子が一致しないため、トラブルシューティングが困難になる可能性があります。したがって、可能であれば、仲介者が正しいセッション識別子を提供しようとすることを強くお勧めします。
If an intermediary receives a SIP response with a non-nil "local-uuid" that is not 32 octets long, this response comes from a misbehaving implementation, and its Session-ID header field MUST be discarded. That said, the response might still be valid according to the rules within SIP [RFC3261], and it SHOULD be checked further.
仲介者が32オクテットではない非nilの「local-uuid」を含むSIP応答を受信した場合、この応答は動作が正しくない実装からのものであり、そのSession-IDヘッダーフィールドは破棄する必要があります。そうは言っても、応答はSIP [RFC3261]内のルールに従って依然として有効である可能性があり、さらに確認する必要があります。
An intermediary MUST assume that the UUID value of session peers may change at any time due to service interactions and MAY itself change UUID values for sessions under its control to ensure that end-to-end session identifiers are consistent for all participants in a session. Section 8 discusses how intermediaries must handle remote UUID changes if they maintain state of the session identifier.
仲介者は、サービスインタラクションによりセッションピアのUUID値がいつでも変更される可能性があると想定し、エンドツーエンドのセッション識別子がセッションのすべての参加者に対して一貫していることを保証するために、その制御下にあるセッションのUUID値を変更する必要があります。セクション8では、仲介者がセッションIDの状態を維持している場合に、仲介者がリモートUUIDの変更を処理する方法について説明します。
An intermediary may perform protocol interworking between different IP-based communications systems, e.g., interworking between H.323 and SIP. If the intermediary supports the session identifier for both protocols for which it is interworking, it SHOULD pass the identifier between the two call legs to maintain an end-to-end identifier, regardless of protocol.
中間者は、異なるIPベースの通信システム間のプロトコルインターワーキング、たとえばH.323とSIP間のインターワーキングを実行できます。仲介者が相互作用している両方のプロトコルのセッション識別子をサポートする場合、プロトコルに関係なく、エンドツーエンドの識別子を維持するために、2つのコールレッグ間で識別子を渡す必要があります（SHOULD）。
It is desirable to have all endpoints and intermediaries involved in a session agree upon the current session identifier when these changes occur. Due to race conditions or certain interworking scenarios, it is not always possible to guarantee session identifier consistency; however, in an attempt to ensure the highest likelihood of consistency, all endpoints and intermediaries involved in a session MUST accept a peer's new UUID under the following conditions: o When an endpoint or intermediary receives a mid-dialog request containing a new UUID from a peer, all responses to that request MUST contain the new UUID value as the "remote" parameter unless a subsequent successful transaction (for example, an UPDATE) contains a different UUID, in which case, the newest UUID MUST be used.
これらの変更が発生した場合、セッションに関与するすべてのエンドポイントと仲介者が現在のセッション識別子に同意することが望ましいです。競合状態や特定のインターワーキングシナリオにより、セッションIDの一貫性を保証できるとは限りません。ただし、一貫性の最も高い可能性を確保するために、セッションに関与するすべてのエンドポイントと仲介者は、次の条件下でピアの新しいUUIDを受け入れる必要があります。oエンドポイントまたは仲介者が新しいUUIDを含むダイアログ中のリクエストをピア、その要求に対するすべての応答には、後続の正常なトランザクション（たとえば、UPDATE）に異なるUUIDが含まれていない限り、「リモート」パラメーターとして新しいUUID値を含める必要があります。この場合、最新のUUIDを使用する必要があります。
o If an endpoint or intermediary sends a successful (2xx) or redirection (3xx) response to the request containing the new UUID value, the endpoint or intermediary MUST accept the peer's UUID and include this new UUID as the "remote" parameter for any subsequent messages unless the UUID from a subsequent transaction has already been accepted. The one exception is a CANCEL request, as outlined below.
o エンドポイントまたは仲介者が新しいUUID値を含むリクエストに成功（2xx）またはリダイレクト（3xx）応答を送信する場合、エンドポイントまたは仲介者はピアのUUIDを受け入れ、この新しいUUIDを後続のメッセージの「リモート」パラメータとして含める必要があります。後続のトランザクションからのUUIDがすでに受け入れられていない限り。 1つの例外は、以下に概説するCANCELリクエストです。
o If the endpoint or intermediary sends a failure (4xx, 5xx, or 6xx) response, it MUST NOT accept the new UUID value and any subsequent messages MUST contain the previously stored UUID value in the "remote" parameter for any subsequent message. Note that the failure response itself will contain the new UUID value from the request in the "remote" parameter.
o エンドポイントまたは仲介者が失敗（4xx、5xx、または6xx）応答を送信する場合、それは新しいUUID値を受け入れてはならず（MUST NOT）、後続のメッセージは後続のメッセージの「リモート」パラメーターに以前に格納されたUUID値を含まなければなりません（MUST）。失敗の応答自体には、「リモート」パラメーターの要求からの新しいUUID値が含まれることに注意してください。
o When an endpoint or intermediary receives an ACK for a successful (2xx) or redirection (3xx) response with a new UUID value, it MUST accept the peer's new UUID value and include this new UUID as the "remote" parameter for any subsequent messages. If the ACK is for a failure (4xx, 5xx, or 6xx) response, the new value MUST NOT be used.
o エンドポイントまたは仲介者が成功した（2xx）またはリダイレクト（3xx）応答のACKを新しいUUID値で受信した場合、ピアの新しいUUID値を受け入れ、この新しいUUIDを後続のメッセージの「リモート」パラメーターとして含める必要があります。 ACKが失敗（4xx、5xx、または6xx）応答に対するものである場合、新しい値を使用してはなりません（MUST NOT）。
o As stated in Sections 6 and 7, the Session-ID header field value included in a CANCEL request MUST be identical to the Session-ID header field value included in the corresponding INVITE request. Upon receiving a CANCEL request, an endpoint or intermediary would normally send a 487 Request Terminated response (see Section 15.1.2 of [RFC3261]) which, by the rules outlined above, would result in the endpoint or intermediary not storing any UUID value contained in the CANCEL request. Section 3.8 of [RFC6141] specifies conditions where a CANCEL request can result in a 2xx response. Because a CANCEL request is not passed end-to-end and will always contain the UUID from the original INVITE request, retaining a new UUID value received in a CANCEL request may result in inconsistency with the Session-ID value stored on the endpoints and intermediaries involved in the session. To avoid this situation, an endpoint or intermediary MUST NOT accept the new UUID value received in a CANCEL request and any subsequent messages MUST contain the previously stored UUID value in the
o セクション6および7で述べたように、CANCELリクエストに含まれるSession-IDヘッダーフィールド値は、対応するINVITEリクエストに含まれるSession-IDヘッダーフィールド値と同一でなければなりません。 CANCELリクエストを受信すると、エンドポイントまたは仲介者は通常、487 Request Terminatedレスポンス（[RFC3261]のセクション15.1.2を参照）を送信します。これにより、上記のルールにより、エンドポイントまたは仲介者は含まれているUUID値を保存しなくなります。 CANCELリクエストで。 [RFC6141]のセクション3.8は、CANCELリクエストが2xx応答をもたらす可能性がある条件を指定しています。 CANCELリクエストはエンドツーエンドで渡されず、常に元のINVITEリクエストからのUUIDが含まれるため、CANCELリクエストで受信した新しいUUID値を保持すると、エンドポイントと仲介者に保存されているセッションID値との不整合が生じる可能性がありますセッションに関与。この状況を回避するために、エンドポイントまたは仲介者はCANCELリクエストで受信した新しいUUID値を受け入れてはならず（MUST）、後続のメッセージは以前に保存されたUUID値を
"remote" parameter". Note that the response to the CANCEL request will contain the UUID value from the CANCEL request in the "remote" parameter.
「リモート」パラメーター」。CANCEL要求への応答には、「リモート」パラメーターのCANCEL要求からのUUID値が含まれることに注意してください。
o When an endpoint or intermediary receives a response containing a new UUID from a peer, the endpoint or intermediary MUST accept the new UUID as the peer's UUID and include this new UUID as the "remote" parameter for any subsequent messages.
o エンドポイントまたは仲介者がピアから新しいUUIDを含む応答を受信した場合、エンドポイントまたは仲介者は新しいUUIDをピアのUUIDとして受け入れ、この新しいUUIDを後続のメッセージの「リモート」パラメータとして含める必要があります。
When an intermediary accepts a new UUID from a peer, the intermediary SHOULD attempt to provide the correct Session-ID header field to other endpoints involved in the session, for example, by sending a re-INVITE request. If an intermediary receives a message with a "remote" parameter in the session identifier that does not match the updated UUID, the intermediary MUST update the "remote" parameter with the latest stored UUID.
仲介者がピアから新しいUUIDを受け入れると、仲介者は、たとえばre-INVITEリクエストを送信するなどして、セッションに関係する他のエンドポイントに正しいSession-IDヘッダーフィールドを提供しようとします（SHOULD）。仲介者が、更新されたUUIDと一致しないセッションIDの「リモート」パラメーターを含むメッセージを受信した場合、仲介者は、「リモート」パラメーターを最新の保存済みUUIDで更新する必要があります。
If an intermediary is performing interworking between two different protocols that both support the session identifier defined in this document (e.g., SIP to H.323), UUID changes SHOULD be communicated between protocols to maintain the end-to-end session identifier.
仲介者がこのドキュメントで定義されているセッション識別子をサポートする2つの異なるプロトコル間でインターワーキングを実行している場合（SIPからH.323など）、エンドツーエンドのセッション識別子を維持するために、プロトコル間でUUIDの変更を伝達する必要があります（SHOULD）。
Multipoint Control Units (MCUs) group two or more sessions into a single multipoint conference and have a conference focus responsible for maintaining the dialogs connected to it [RFC4353]. MCUs, including cascaded MCUs, MUST utilize the same UUID value ("local-uuid" portion of the Session-ID header field value) with all participants in the conference. In so doing, each individual session in the conference will have a unique session identifier (since each endpoint will create a unique UUID of its own), but will also have one UUID in common with all other participants in the conference.
マルチポイントコントロールユニット（MCU）は、2つ以上のセッションを1つのマルチポイント会議にグループ化し、それに接続されたダイアログの維持を担当する会議フォーカスを持ちます[RFC4353]。カスケードされたMCUを含むMCUは、会議のすべての参加者と同じUUID値（Session-IDヘッダーフィールド値の「local-uuid」部分）を使用する必要があります。そうすることで、会議の各セッションは一意のセッション識別子を持ちます（各エンドポイントが独自の一意のUUIDを作成するため）が、会議の他のすべての参加者と共通の1つのUUIDも持ちます。
When creating a cascaded conference, an MCU MUST convey the UUID value to be utilized for a conference via the "local-uuid" portion of the Session-ID header field value in an INVITE request to a second MCU when using SIP to establish the cascaded conference. A conference bridge, or MCU, needs a way to identify itself when contacting another MCU. [RFC4579] defines the "isfocus" Contact header field value parameter just for this purpose. The initial MCU MUST include the UUID of that particular conference in the "local-uuid" of an INVITE request to the other MCU(s) participating in that conference. Also included in this INVITE request is an "isfocus" Contact header field value parameter identifying that this INVITE request is coming from an MCU, and that this UUID is to be given out in all responses from endpoints into those MCUs participating in this same conference. This ensures that a single UUID is common across all participating MCUs of the same conference, but that it is unique between different conferences.
カスケードされた会議を作成するとき、MCUは、SIPを使用してカスケードされた会議を確立するときに、2番目のMCUへのINVITE要求のSession-IDヘッダーフィールド値の「local-uuid」部分を介して会議に利用されるUUID値を伝達する必要があります会議。会議ブリッジ、つまりMCUには、別のMCUに接続するときに自身を識別する方法が必要です。 [RFC4579]は、この目的のためだけに「isfocus」Contactヘッダーフィールド値パラメーターを定義します。最初のMCUは、その会議に参加している他のMCUへのINVITE要求の「local-uuid」に、その特定の会議のUUIDを含める必要があります。このINVITE要求には、このINVITE要求がMCUから送信されたこと、およびこのUUIDがエンドポイントからこの同じ会議に参加しているMCUへのすべての応答で送信されることを識別する「isfocus」Contactヘッダーフィールド値パラメーターも含まれています。これにより、同じ会議に参加しているすべてのMCUで単一のUUIDが確実に共通になりますが、異なる会議間では一意になります。
In the case where two existing conferences are joined, there should be a session between the two MCUs where the session identifier is comprised of the UUID values of the two conferences. This session identifier can be used to correlate the sessions between participants in the joined conference. This specification does not impose any additional requirements when two existing conferences are joined.
2つの既存の会議が参加している場合、2つのMCUの間にセッションがあり、セッションIDは2つの会議のUUID値で構成されます。このセッション識別子を使用して、参加した会議の参加者間のセッションを関連付けることができます。この仕様では、2つの既存の会議に参加するときに追加の要件は課されません。
Intermediary devices or network-diagnostic equipment might assume that when they see two or more sessions with different session identifiers but with one UUID in common, the sessions are part of the same conference. However, the assumption that two sessions having one common UUID being part of the same conference is not always correct. In a SIP-forking scenario, for example, there might also exist what appears to be multiple sessions with a shared UUID value; this is intended. The desire is to allow for the association of related sessions, regardless of whether a session is forked or part of a conference.
中間デバイスまたはネットワーク診断機器は、異なるセッションIDを持つが、1つのUUIDが共通する2つ以上のセッションを見ると、それらのセッションは同じ会議の一部であると想定する場合があります。ただし、同じ会議の一部である1つの共通のUUIDを持つ2つのセッションが常に正しいとは限りません。たとえば、SIP分岐シナリオでは、共有UUID値を持つ複数のセッションのように見えるものも存在する可能性があります。これは意図されています。セッションがforkされているか、会議の一部であるかに関係なく、関連するセッションの関連付けを可能にすることが望まれます。
Seeing something frequently makes understanding easier. With that in mind, this section includes several call flow examples with the initial UUID and the complete session identifier indicated per message, as well as examples of when the session identifier changes according to the rules within this document during certain operations/functions.
何かを頻繁に見ると理解が容易になります。このことを念頭に置いて、このセクションには、メッセージごとに示される初期UUIDと完全なセッションIDを含むいくつかのコールフローの例と、特定の操作/機能中にこのドキュメント内のルールに従ってセッションIDが変更される例が含まれます。
This section is for illustrative purposes only and is non-normative. In the following flows, "RTP" refers to the Real-time Transport Protocol [RFC3550].
このセクションは例示のみを目的としており、規範的ではありません。以下のフローでは、「RTP」はリアルタイム転送プロトコル[RFC3550]を指します。
In the examples in this section, "N" represents a nil UUID and other letters represent the unique UUID values corresponding to endpoints or MCUs.
このセクションの例では、「N」はnil UUIDを表し、他の文字はエンドポイントまたはMCUに対応する一意のUUID値を表します。
Session-ID
--- Alice B2BUA Bob Carol
{A,N} |---INVITE F1--->| |
{A,N} | |---INVITE F2--->|
{B,A} | |<---200 OK F3---|
{B,A} |<---200 OK F4---| |
{A,B} |-----ACK F5---->| |
{A,B} | |-----ACK F6---->|
|<==============RTP==============>|
Figure 1: Session-ID Creation When Alice Calls Bob
図1：アリスがボブを呼び出したときのセッションIDの作成
General operation of this example:
この例の一般的な操作：
o UA-Alice populates the "local-uuid" portion of the Session-ID header field value.
o UA-Aliceは、Session-IDヘッダーフィールド値の「local-uuid」部分を入力します。
o UA-Alice sends its UUID in the SIP INVITE request and populates the "remote" parameter with a nil value (32 zeros).
o UA-Aliceは、そのUUIDをSIP INVITE要求で送信し、「リモート」パラメーターにnil値（32個のゼロ）を設定します。
o The B2BUA receives an INVITE request with both a "local-uuid" portion of the Session-ID header field value from UA-Alice as well as the nil "remote-uuid" value and transmits the INVITE request towards UA-Bob with an unchanged Session-ID header field value.
o B2BUAは、UA-AliceからのSession-IDヘッダーフィールド値の「local-uuid」部分とnil「remote-uuid」値の両方を含むINVITEリクエストを受信し、変更されていない状態でUA-BobにINVITEリクエストを送信しますセッションIDヘッダーフィールドの値。
o UA-Bob receives the Session-ID and generates its "local-uuid" portion of the Session-ID header field value UUID to construct the whole/complete Session-ID header field value, at the same time transferring UA-Alice's UUID unchanged to the "remote-uuid" portion of the Session-ID header field value in the 200 OK SIP response.
o UA-BobはセッションIDを受信し、セッションIDヘッダーフィールド値UUIDの「local-uuid」部分を生成して、完全な/完全なセッションIDヘッダーフィールド値を構築すると同時に、UA-AliceのUUIDを変更せずに転送します200 OK SIP応答のSession-IDヘッダーフィールド値の「remote-uuid」部分。
o The B2BUA receives the 200 OK response with a complete Session-ID header field value from UA-Bob and transmits the 200 OK response towards UA-Alice with an unchanged Session-ID header field value.
o B2BUAは、UA-Bobから完全なセッションIDヘッダーフィールド値を持つ200 OK応答を受信し、変更されていないセッションIDヘッダーフィールド値を持つ200 OK応答をUA-Aliceに送信します。
o UA-Alice, upon reception of the 200 OK from the B2BUA, transmits the ACK towards the B2BUA. The construction of the Session-ID header field in this ACK is that of UA-Alice's UUID is the "local-uuid", and UA-Bob's UUID populates the "remote-uuid" portion of the header-value.
o UA-Aliceは、B2BUAから200 OKを受信すると、ACKをB2BUAに送信します。このACKのSession-IDヘッダーフィールドの構成は、UA-AliceのUUIDが「local-uuid」であり、UA-BobのUUIDがヘッダー値の「remote-uuid」部分に入力されます。
o The B2BUA receives the ACK with a complete Session-ID header field from UA-Alice and transmits the ACK towards UA-Bob with an unchanged Session-ID header field value.
o B2BUAは、UA-Aliceから完全なSession-IDヘッダーフィールドを持つACKを受信し、変更されていないSession-IDヘッダーフィールド値を持つUA-Bobに向けてACKを送信します。
Below is a SIP message exchange illustrating proper use of the Session-ID header field. For the sake of brevity, non-essential headers and message bodies are omitted.
以下は、Session-IDヘッダーフィールドの適切な使用を示すSIPメッセージ交換です。簡潔にするために、必須ではないヘッダーとメッセージ本文は省略されています。
F1 INVITE Alice -> B2BUA
F1 INVITEアリス-> B2BUA
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown) F2 INVITE B2BUA -> Bob
（アリスのSDPは表示されていません）F2 INVITE B2BUA-> Bob
INVITE sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/UDP server10.biloxi.example.com
;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds;received=10.1.3.33
Max-Forwards: 69
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.example.com>
Record-Route: <sip:server10.biloxi.example.com;lr>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
（アリスのSDPは表示されていません）
F3 200 OK Bob -> B2BUA
F3 200 OKボブ-> B2BUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.example.com
;branch=z9hG4bK4b43c2ff8.1;received=192.168.10.1
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds;received=10.1.3.33
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Record-Route: <sip:server10.biloxi.example.com;lr>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown) F4 200 OK B2BUA -> Alice
（ボブのSDPは表示されていません）F4 200 OK B2BUA->アリス
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds;received=10.1.3.33
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Record-Route: <sip:server10.biloxi.example.com;lr>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
（ボブのSDPは表示されていません）
F5 ACK Alice -> B2BUA
F5 ACKアリス-> B2BUA
ACK sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bKnashds8
Route: <sip:server10.biloxi.example.com;lr>
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2
CSeq: 314159 ACK
Content-Length: 0
F6 ACK B2BUA -> Bob
ACK sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/UDP server10.biloxi.example.com
;branch=z9hG4bK4b43c2ff8.2
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bKnashds8;received=10.1.3.33
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2
CSeq: 314159 ACK
Content-Length: 0
The remaining examples in this section do not display the complete SIP message exchange. Instead, they simply use the set notation described in Section 4.2 to show the session identifier exchange throughout the particular call flow being illustrated.
このセクションの残りの例は、完全なSIPメッセージ交換を示していません。代わりに、セクション4.2で説明されているセット表記を使用して、図示されている特定のコールフロー全体でのセッション識別子の交換を示します。
From the example built within Section 10.1, we proceed to this 'Basic Call Transfer using REFER' example. Note that this is a mid-dialog REFER in contrast with the out-of-dialog REFER in Section 10.9.
10.1節で作成した例から、この「REFERを使用した基本的なコール転送」の例に進みます。これは、セクション10.9のダイアログ外のREFERとは対照的に、ダイアログ中のREFERであることに注意してください。
Session-ID
--- Alice B2BUA Bob Carol
| | | |
|<==============RTP==============>| |
{B,A} | |<---re-INVITE---| |
{B,A} |<---re-INVITE---| (puts Alice on Hold) |
{A,B} |-----200 OK---->| | |
{A,B} | |-----200 OK---->| |
{B,A} | |<-----ACK-------| |
{B,A} |<-----ACK-------| | |
| | | |
{B,A} | |<----REFER------| |
{B,A} |<----REFER------| | |
{A,B} |-----200 OK---->| | |
{A,B} | |-----200 OK---->| |
{A,B} |-----NOTIFY---->| | |
{A,B} | |-----NOTIFY---->| |
{B,A} | |<----200 OK-----| |
{B,A} |<----200 OK-----| | |
| | | |
{A,N} |-----INVITE---->| |
{A,N} | |-----INVITE-------------------->|
{C,A} | |<----200 OK---------------------|
{C,A} |<----200 OK-----| |
{A,C} |------ACK------>| |
{A,C} | |------ACK---------------------->|
| | | |
|<======================RTP======================>|
| | | |
{A,B} |-----NOTIFY---->| | |
{A,B} | |-----NOTIFY---->| |
{B,A} | |<----200 OK-----| |
{B,A} |<----200 OK-----| | |
{B,A} | |<-----BYE-------| |
{B,A} |<-----BYE-------| | |
{A,B} |-----200 OK---->| | |
{A,B} | |-----200 OK---->| |
| | | |
Figure 2: Call Transfer Using REFER
図2：REFERを使用したコール転送
General operation of this example:
この例の一般的な操作：
Starting from the existing Alice/Bob call described in Figure 1 of this document, which established an existing Session-ID header field value:
このドキュメントの図1で説明されている、既存のSession-IDヘッダーフィールド値を確立した既存のAlice / Bob呼び出しから始めます。
o UA-Bob requests Alice to call Carol, using a REFER transaction, as described in [RFC3515]. UA-Alice is initially put on hold, then told in the REFER who to contact with a new INVITE, in this case UA-Carol. This Alice-to-Carol dialog will have a new Call-ID; therefore, it requires a new Session-ID header field value. The wrinkle here is we can, and will, use Alice's UUID from her existing dialog with Bob in the new INVITE request to Carol.
o UA-Bobは、[RFC3515]で説明されているように、REFERトランザクションを使用してCarolを呼び出すようにAliceに要求します。 UA-Aliceは最初に保留にされ、次にREFERで新しいINVITE（この場合はUA-Carol）に連絡する人に通知されます。このAlice-to-Carolダイアログには、新しいCall-IDがあります。したがって、新しいSession-IDヘッダーフィールド値が必要です。ここでのしわは、Carolへの新しいINVITEリクエストでBobとの彼女の既存のダイアログからのAliceのUUIDを使用できること、そして使用することです。
o UA-Alice retains her UUID from the Alice-to-Bob call {A} when requesting a call with UA-Carol. This is placed in the "local-uuid" portion of the Session-ID header field value, at the same time inserting a nil "remote-uuid" value (because Carol's UA has not yet received the UUID value). This same UUID traverses the B2BUA unchanged.
o UA-Aliceは、UA-Carolでの呼び出しを要求するときに、AliceからBobへの呼び出し{A}からのUUIDを保持します。これは、Session-IDヘッダーフィールド値の「local-uuid」部分に配置されると同時に、nilの「remote-uuid」値が挿入されます（CarolのUAがまだUUID値を受け取っていないため）。これと同じUUIDがB2BUAを変更せずに通過します。
o UA-Carol receives the INVITE request with a session identifier UUID {A,N}, replaces the "A" UUID value into the "remote-uuid" portion of the Session-ID header field value and creates its own UUID {C}, and places this value in the "local-uuid" portion of the Session-ID header field value, thereby removing the "N" (nil) value altogether. This combination forms a full session identifier {C,A} in the 200 OK to the INVITE. This Session-ID header field traverses the B2BUA unchanged towards UA-Alice.
o UA-Carolは、セッション識別子UUID {A、N}を含むINVITEリクエストを受信し、 "A" UUID値をSession-IDヘッダーフィールド値の "remote-uuid"部分に置き換え、独自のUUID {C}を作成します。この値をSession-IDヘッダーフィールド値の「local-uuid」部分に配置することで、「N」（nil）値を完全に削除します。この組み合わせにより、200 OK to INVITEの完全なセッション識別子{C、A}が形成されます。このセッションIDヘッダーフィールドは、UA-Aliceに向けてB2BUAを変更せずに通過します。
o UA-Alice receives the 200 OK with the session identifier {C,A} and responds to UA-Carol with an ACK (just as in Figure 1, this switches the places of the two UUID fields), and generates a NOTIFY request to Bob with a session identifier {A,B} indicating that the call transfer was successful.
o UA-AliceはセッションID {C、A}で200 OKを受信し、ACKでUA-Carolに応答し（図1のように、2つのUUIDフィールドの場所を切り替えます）、BobにNOTIFY要求を生成しますコール転送が成功したことを示すセッション識別子{A、B}を使用します。
o It does not matter which UA terminates the Alice-to-Bob call; Figure 2 shows UA-Bob terminating the call.
o どのUAがAlice-to-Bob呼び出しを終了するかは関係ありません。図2は、コールを終了するUA-Bobを示しています。
From the example built within Section 10.1, we proceed to this 'Basic Call Transfer using re-INVITE' example.
セクション10.1で作成した例から、この「re-INVITEを使用した基本的なコール転送」の例に進みます。
Alice is talking to Bob. Bob pushes a button on his phone to transfer Alice to Carol via the B2BUA (using re-INVITE).
アリスはボブに話しかけています。ボブは自分の電話のボタンを押して、B2BUAを介してアリスをキャロルに転送します（re-INVITEを使用）。
Session-ID
--- Alice B2BUA Bob Carol
| | | |
|<==============RTP==============>| |
| | | |
| | <--- (non-standard signaling) |
{A,B} | |---re-INVITE--->| |
{B,A} | |<-----200 OK----| |
{A,B} | |-----ACK------->| |
| | | |
{A,N} | |-----INVITE-------------------->|
{C,A} | |<----200 OK---------------------|
{A,C} | |------ACK---------------------->|
| | | |
|<======================RTP======================>|
| | | |
{A,B} | |------BYE------>| |
{B,A} | |<----200 OK-----| |
| | | |
{C,A} |<--re-INVITE----| | |
{A,C} |----200 OK----->| | |
{C,A} |<-----ACK-------| | |
| (Suppose Alice modifies the session) |
{A,C} |---re-INVITE--->| | |
{A,C} | |---re-INVITE------------------->|
{C,A} | |<---200 OK----------------------|
{C,A} |<---200 OK------| | |
{A,C} |------ACK------>| | |
{A,C} | |------ACK---------------------->|
| | | |
Figure 3: Call Transfer Using Re-INVITE
図3：Re-INVITEを使用したコール転送
General operation of this example:
この例の一般的な操作：
o We assume the call between Alice and Bob from Section 10.1 is operational with session identifier {A,B}.
o セクション10.1からのアリスとボブの間のコールは、セッション識別子{A、B}で動作可能であると想定しています。
o Bob uses non-standard signaling to the B2BUA to initiate a call transfer from Alice to Carol. This could also be initiated via a REFER message from Bob, but the signaling that follows might still be similar to the above flow. In either case, Alice is completely unaware of the call transfer until a future point in time when Alice receives a message from Carol.
o ボブは、B2BUAへの非標準のシグナリングを使用して、アリスからキャロルへのコール転送を開始します。これはボブからのREFERメッセージを介して開始することもできますが、その後のシグナリングは上記のフローと同様である可能性があります。どちらの場合でも、アリスは、アリスがキャロルからメッセージを受信する将来の時点まで、コール転送を完全に認識していません。
o The B2BUA sends a re-INVITE request with the session identifier {"local-uuid" = "A", "remote-uuid" = "B"} to renegotiate the session with Bob.
o B2BUAは、セッション識別子{"local-uuid" = "A"、 "remote-uuid" = "B"}を含むre-INVITE要求を送信して、ボブとのセッションを再ネゴシエートします。
o The B2BUA sends a new INVITE request with Alice's UUID {"local-uuid" = "A"} to Carol.
o B2BUAは、アリスのUUID {"local-uuid" = "A"}を含む新しいINVITEリクエストをキャロルに送信します。
o Carol receives the INVITE request and accepts the request and adds her UUID {C} to the session identifier for this session {"local-uuid" = "C", "remote-uuid" = "A"}.
o CarolはINVITEリクエストを受信し、リクエストを受け入れて、自分のUUID {C}をこのセッションのセッション識別子に追加します{"local-uuid" = "C"、 "remote-uuid" = "A"}。
o The B2BUA then terminates the call to Bob with a BYE using the session identifier {"local-uuid" = "A", "remote-uuid" = "B"}.
o 次にB2BUAは、セッション識別子{"local-uuid" = "A"、 "remote-uuid" = "B"}を使用してBYEでBobへのコールを終了します。
o The B2BUA sends a re-INVITE request to Alice to update Alice's view of the session identifier.
o B2BUAはre-INVITE要求をアリスに送信して、アリスのセッション識別子のビューを更新します。
o When Alice later attempts to modify the session with a re-INVITE, Alice will send "remote-uuid" = "C" toward Carol because it had previously received the updated UUID in the re-INVITE request from the B2BUA. The B2BUA maintains the session identifier {"local-uuid" = "A", "remote-uuid" = "C"}. Carol replies with the "local-uuid" = "C", "remote-uuid" = "A" to reflect what was received in the INVITE request (which Carol already knew from previous exchanges with the B2BUA). Alice then includes "remote-uuid" = "C" in the subsequent ACK message.
o Aliceが後でre-INVITEを使用してセッションを変更しようとすると、B2BUAからのre-INVITE要求で更新されたUUIDを以前に受信したため、AliceはCarolに "remote-uuid" = "C"を送信します。 B2BUAは、セッション識別子{"local-uuid" = "A"、 "remote-uuid" = "C"}を維持します。 Carolは "local-uuid" = "C"、 "remote-uuid" = "A"で応答し、INVITEリクエストで受信したものを反映します（これは、CarolがB2BUAとの以前の交換ですでに知っていました）。その後、アリスは後続のACKメッセージに「remote-uuid」=「C」を含めます。
Multiple users call into a conference server (for example, an MCU) to attend one of many conferences hosted on or managed by that server. Each user has to identify which conference they want to join, but this information is not necessarily in the SIP messaging. It might be done by having a dedicated address for the conference or via an Interactive Voice Response (IVR), as assumed in this example and depicted with the use of M1, M2, and M3. Each user in this example goes through a two-step process of signaling to gain entry onto their conference call, which the conference focus identifies as "M".
複数のユーザーが会議サーバー（MCUなど）を呼び出して、そのサーバーでホストまたは管理されている多くの会議の1つに参加します。各ユーザーは参加する会議を識別する必要がありますが、この情報は必ずしもSIPメッセージングに含まれているとは限りません。これは、この例で想定され、M1、M2、およびM3を使用して示されているように、会議専用のアドレスを持つことによって、またはインタラクティブ音声応答（IVR）を介して行われる場合があります。この例の各ユーザーは、シグナリングの2段階のプロセスを経て、会議のフォーカスを「M」と識別して、電話会議に参加します。
Session-ID Conference
--- Alice Focus Bob Carol
| | | |
| | | |
{A,N} |----INVITE----->| | |
{M1,A} |<---200 OK------| | |
{A,M1} |-----ACK------->| | |
|<====RTP=======>| | |
{M',A} |<---re-INVITE---| | |
{A,M'} |-----200 OK---->| | |
{M',A} |<-----ACK-------| | |
| | | |
| | | |
{B,N} | |<----INVITE-----| |
{M2,B} | |-----200 OK---->| |
{B,M2} | |<-----ACK-------| |
| |<=====RTP======>| |
{M',B} | |---re-INVITE--->| |
{B,M'} | |<----200 OK-----| |
{M',B} | |------ACK------>| |
| | | |
| | | |
{C,N} | |<--------------------INVITE-----|
{M3,C} | |---------------------200 OK---->|
{C,M3} | |<---------------------ACK-------|
| |<=====================RTP======>|
{M',C} | |-------------------re-INVITE--->|
{C,M'} | |<--------------------200 OK-----|
{M',C} | |----------------------ACK------>|
Figure 4: Single Focus Conference Bridge
図4：単焦点会議ブリッジ
General operation of this example:
この例の一般的な操作：
Alice calls into a conference server to attend a certain conference. This is a two-step operation since Alice cannot include the conference ID at this time and/or any passcode in the INVITE request. The first step is Alice's UA calling another UA to participate in a session. This will appear to be similar as the call flow in Figure 1 (in Section 10.1). What is unique about this call is the second step: the conference server sends a re-INVITE request with its second UUID, but maintaining the UUID Alice sent in the first INVITE. This subsequent UUID from the conference server will be the same for each UA that calls into this conference server participating in this same conference bridge/call, which is generated once Alice typically authenticates and identifies which bridge she wants to participate on.
アリスは、特定の会議に参加するために会議サーバーを呼び出します。 Aliceは現時点では会議IDやパスコードをINVITEリクエストに含めることができないため、これは2段階の操作です。最初のステップは、アリスのUAがセッションに参加するために別のUAを呼び出すことです。これは、図1（セクション10.1）のコールフローと同様に表示されます。この呼び出しのユニークな点は2番目のステップです。会議サーバーは、2番目のUUIDを使用してre-INVITE要求を送信しますが、最初のINVITEで送信されたUUIDアリスを維持します。会議サーバーからのこの後続のUUIDは、この会議ブリッジ/呼び出しに参加しているこの会議サーバーに呼び出す各UAと同じです。これは、Aliceが通常認証し、参加したいブリッジを識別すると生成されます。
o Alice sends an INVITE request to the conference server with her UUID {A} and a "remote-uuid" = "N".
o アリスは自分のUUID {A}と "remote-uuid" = "N"を指定してINVITE要求を会議サーバーに送信します。
o The conference server responds with a 200 OK response, which replaces the "N" UUID with a temporary UUID ("M1") as the "local-uuid" and a "remote-uuid" = "A".
o 会議サーバーは200 OK応答で応答し、「N」UUIDを「local-uuid」および「remote-uuid」=「A」として一時的なUUID（「M1」）に置き換えます。
NOTE: this 'temporary' UUID is a real UUID; it is only temporary to the conference server because it knows that it is going to generate another UUID to replace the one just sent in the 200 OK response.
注：この「一時的な」UUIDは実際のUUIDです。 200 OK応答で送信されたばかりのUUIDを置き換える別のUUIDを生成することがわかっているため、これは会議サーバーにとって一時的なものです。
o Once Alice, the user, gains access to the IVR for this conference server, she enters a specific conference ID and whatever passcode (if needed) to enter a specific conference call.
o ユーザーのアリスは、この会議サーバーのIVRにアクセスすると、特定の会議IDと、必要に応じてパスコードを入力し、特定の電話会議に参加します。
o Once the conference server is satisfied Alice has identified which conference she wants to attend (including any passcode verification), the conference server re-INVITEs Alice to the specific conference and includes the Session-ID header field value component "local-uuid" = "M'" (and "remote-uuid" = "A") for that conference. All valid participants in the same conference will receive this same UUID for identification purposes and to better enable monitoring and tracking functions.
o 会議サーバーが満足すると、アリスは参加したい会議（パスコード検証を含む）を識別し、会議サーバーはアリスを特定の会議に再度招待し、Session-IDヘッダーフィールド値のコンポーネント "local-uuid" = "を含めますその会議のM '"（および" remote-uuid "=" A "）。同じ会議のすべての有効な参加者は、識別と監視および追跡機能をより有効にするために、この同じUUIDを受け取ります。
o Bob goes through this two-step process of an INVITE transaction, followed by a re-INVITE transaction to get this same UUID ("M'") for the conference.
o ボブは、このINVITEトランザクションの2つのステップのプロセスを実行し、続いてre-INVITEトランザクションを実行して、会議の同じUUID（ "M '"）を取得します。
o In this example, Carol (and each additional user) goes through the same procedures as Alice and Bob to get on this same conference.
o この例では、キャロル（および追加の各ユーザー）は、アリスとボブと同じ手順でこの同じ会議に参加します。
Alice, Bob, and Carol call into the same web-based conference. Note that this is one of many ways of implementing this functionality, and it should not be construed as the preferred way of establishing a web-based conference.
アリス、ボブ、キャロルは、同じWebベースの会議に電話をかけます。これは、この機能を実装する多くの方法の1つであり、Webベースの会議を確立するための好ましい方法として解釈されるべきではないことに注意してください。
Session-ID Conference
--- Alice Focus Bob Carol
| | | |
|<** HTTPS *****>| | |
| Transaction | | |
| | | |
{M,N} |<----INVITE-----| | |
{A,M} |-----200 OK---->| | |
{M,A} |<-----ACK-------| | |
|<=====RTP======>| | |
| | | |
| |<** HTTPS *****>| |
| | Transaction | |
| | | |
{M,N} | |-----INVITE---->| |
{B,M} | |<----200 OK-----| |
{M,B} | |------ACK------>| |
| |<=====RTP======>| |
| | | |
| |<****************** HTTPS *****>|
| | Transaction |
| | | |
{M,N} | |--------------------INVITE----->|
{C,M} | |<-------------------200 OK------|
{M,C} | |---------------------ACK------->|
| |<====================RTP=======>|
Figure 5: Single Focus Web-Based Conference
図5：単焦点のWebベースの会議
General operation of this example:
この例の一般的な操作：
o Alice communicates with the web server that she wants to join a certain meeting by using a meeting number and including UA-Alice's contact information (phone number, URI, and/or IP address, etc.) for each device she wants for this conference call. For example, the audio and video (A/V) play-out devices could be separate units.
o アリスは、会議番号を使用し、この電話会議に希望する各デバイスのUA-Aliceの連絡先情報（電話番号、URI、IPアドレスなど）を含めることにより、特定の会議に参加したいWebサーバーと通信します。 。たとえば、オーディオとビデオ（A / V）の再生デバイスを別々のユニットにすることができます。
o The Conference Focus server sends the INVITE request (Session-ID header field value components "local-uuid" = "M" and a remote UUID of "N", where "M" equals the "local-uuid" for each participant on this conference bridge) to UA-Alice to start a session with that server for this A/V conference call.
o Conference Focusサーバーは、INVITEリクエストを送信します（Session-IDヘッダーフィールドの値のコンポーネント "local-uuid" = "M"および "N"のリモートUUID。ここで、 "M"は、これに関する各参加者の "local-uuid"に等しい会議ブリッジ）をUA-Aliceに送信して、このA / V電話会議のためにそのサーバーとのセッションを開始します。
o Upon receiving the INVITE request from the conference focus server, Alice responds with a 200 OK. Her UA moves the "local-uuid" unchanged into the "remote-uuid" field, generates her own UUID, and places that into the "local-uuid" field to complete the Session-ID construction.
o 会議フォーカスサーバーからINVITE要求を受信すると、アリスは200 OKで応答します。彼女のUAは「local-uuid」を変更せずに「remote-uuid」フィールドに移動し、独自のUUIDを生成して「local-uuid」フィールドに配置し、Session-IDの構築を完了します。
o Bob and Carol perform same function to join this same A/V conference call as Alice.
o ボブとキャロルは同じ機能を実行して、アリスと同じA / V電話会議に参加します。
Expanding conferencing capabilities requires cascading conference bridges. A conference bridge, or MCU, needs a way to identify itself when contacting another MCU. [RFC4579] defines the "isfocus" Contact header field value parameter just for this purpose.
会議機能を拡張するには、会議ブリッジをカスケードする必要があります。会議ブリッジ、つまりMCUには、別のMCUに接続するときに自身を識別する方法が必要です。 [RFC4579]は、この目的のためだけに「isfocus」Contactヘッダーフィールド値パラメーターを定義します。
Session-ID
--- MCU-1 MCU-2 MCU-3 MCU-4
| | | |
{M',N} |----INVITE----->| | |
{J,M'} |<---200 OK------| | |
{M',J} |-----ACK------->| | |
Figure 6: MCUs Communicating Session Identifier UUID for Bridge
図6：ブリッジのセッション識別子UUIDを通信するMCU
Regardless of which MCU (1 or 2) a UA contacts for this conference, once the above exchange has been received and acknowledged, the UA will get the same {M',N} UUID pair from the MCU for the complete session identifier.
この会議のUAがどのMCU（1または2）に連絡するかに関係なく、上記の交換が受信されて確認されると、UAはMCUから同じ{M '、N} UUIDペアを取得して、完全なセッション識別子を取得します。
A more complex form would be a series of MCUs all being informed of the same UUID to use for a specific conference. This series of MCUs can be informed in one of two ways:
より複雑な形式は、特定の会議に使用する同じUUIDがすべて通知される一連のMCUです。この一連のMCUは、次の2つの方法のいずれかで通知されます。
o All by one MCU (that initially generates the UUID for the conference).
o すべて1つのMCU（最初に会議のUUIDを生成）。
o The MCU that generates the UUID informs one or several MCUs of this common UUID, and then they inform downstream MCUs of this common UUID that each will be using for this one conference.
o UUIDを生成するMCUは、1つまたは複数のMCUにこの共通UUIDを通知し、次に、これらがこの1つの会議に使用するこの共通UUIDをダウンストリームMCUに通知します。
Session-ID
--- MCU-1 MCU-2 MCU-3 MCU-4
| | | |
{M',N} |----INVITE----->| | |
{J,M'} |<---200 OK------| | |
{M',J} |-----ACK------->| | |
| | | |
{M',N} |---------------------INVITE----->| |
{K,M'} |<--------------------200 OK------| |
{M',K} |----------------------ACK------->| |
| | | |
{M',N} |-------------------------------------INVITE----->|
{L,M'} |<------------------------------------200 OK------|
{M',L} |--------------------------------------ACK------->|
Figure 7: MCU Communicating Session Identifier UUID to More Than One MCU
図7：複数のMCUにセッション識別子UUIDを通信するMCU
General operation of this example:
この例の一般的な操作：
o The MCU generating the session identifier UUID communicates this in a separate INVITE, having a Contact header with the "isfocus" Contact header field value parameter. This will identify the MCU as what [RFC4579] calls a "conference-aware" SIP entity.
o セッション識別子UUIDを生成するMCUは、これを別のINVITEで通信し、 "isfocus" Contactヘッダーフィールド値パラメーターを持つContactヘッダーを持ちます。これにより、[RFC4579]が「会議認識」SIPエンティティと呼ぶものとしてMCUが識別されます。
o An MCU that receives this {M',N} UUID pair in an inter-MCU transaction can communicate the M' UUID in a manner in which it was received to construct a hierarchical cascade (though this time this second MCU would be the UAC MCU).
o MCU間トランザクションでこの{M '、N} UUIDペアを受信するMCUは、階層カスケードを構築するために受信された方法でM' UUIDを通信できます（今回は、この2番目のMCUはUAC MCUになります） ）。
o Once the conference is terminated, the cascaded MCUs will receive a BYE message to terminate the cascade.
o 会議が終了すると、カスケードされたMCUはBYEメッセージを受信して、カスケードを終了します。
Here is an example of how a UA, Robert for example, calls into a cascaded conference focus. Because MCU-1 has already contacted MCU-3 (the MCU where Robert is going to join the conference), MCU-3 already has the Session-ID (M') for this particular conference call.
これは、たとえばロバートなどのUAがカスケードされた会議のフォーカスを呼び出す方法の例です。 MCU-1はすでにMCU-3（Robertが会議に参加しようとしているMCU）に連絡しているため、MCU-3はすでにこの特定の電話会議のセッションID（M '）を持っています。
Session-ID
--- MCU-1 MCU-2 MCU-3 Robert
| | | |
{M',N} |----INVITE----->| | |
{J,M'} |<---200 OK------| | |
{M',J} |-----ACK------->| | |
| | | |
{M',N} |---------------------INVITE----->| |
{K,M'} |<--------------------200 OK------| |
{M',K} |----------------------ACK------->| |
| | | |
{R,N} | | |<---INVITE-----|
(M',R} | | |----200 OK---->|
{R,M'} | | |<----ACK-------|
Figure 8: A UA Calling Into a Cascaded MCU UUID
図8：カスケードされたMCU UUIDを呼び出すUA
General operation of this example:
この例の一般的な操作：
o The UA, Robert in this case, INVITEs the MCU to join a particular conference call. Robert's UA does not know anything about whether this is the main MCU of the conference call or a cascaded MCU. Robert likely does not know MCUs can be cascaded, he just wants to join a particular call. As is the case with any standard implementation, he includes a nil "remote-uuid".
o UA、この場合はロバートは、特定の電話会議に参加するようにMCUを招待します。 RobertのUAは、これが電話会議のメインMCUであるかカスケードMCUであるかについては何も知りません。ロバートは、MCUをカスケードできることを知らない可能性が高く、特定の通話に参加したいだけです。標準の実装と同様に、彼はnil "remote-uuid"を含めます。
o The cascaded MCU, upon receiving this INVITE request from Robert, replaces the nil UUID with the UUID value communicated from MCU-1 for this conference call as the "local-uuid" in the SIP response, thus moving Robert's UUID "R" to the "remote-uuid" value.
o カスケードされたMCUは、RobertからこのINVITE要求を受信すると、nil UUIDを、SIP応答の「local-uuid」としてこの電話会議のMCU-1から通信されたUUID値に置き換え、RobertのUUID "R"を「remote-uuid」値。
o The ACK has the Session-ID {R,M'}, completing the three-way handshake for this call establishment. Robert has now joined the conference call originated from MCU-1.
o ACKにはセッションID {R、M '}があり、このコール確立のための3ウェイハンドシェイクを完了します。 RobertはMCU-1から発信された電話会議に参加しました。
o Once the conference is terminated, the cascaded MCUs will receive a BYE message to terminate the cascade.
o 会議が終了すると、カスケードされたMCUはBYEメッセージを受信して、カスケードを終了します。
An external entity sets up calls to both Alice and Bob for them to talk to each other.
外部エンティティは、アリスとボブの両方がお互いに話すための呼び出しをセットアップします。
Session-ID
--- Alice B2BUA Bob Carol
| | |
{X,N} |<----INVITE-----| |
{A,X} |-----200 OK---->| |
{A,N} | |----INVITE----->|
{B,A} | |<---200 OK------|
{B,A} |<-----ACK-------| |
{A,B} | |------ACK------>|
|<==============RTP==============>|
Figure 9: 3PCC-Initiated Call between Alice and Bob
図9：アリスとボブの間の3PCCで開始されたコール
General operation of this example:
この例の一般的な操作：
o Some out-of-band procedure directs a B2BUA (or other SIP server) to have Alice and Bob talk to each other. In this case, the SIP server has to be transaction stateful, if not dialog stateful.
o 一部の帯域外手順では、B2BUA（または他のSIPサーバー）に、アリスとボブが互いに対話するように指示します。この場合、ダイアログステートフルでない場合でも、SIPサーバーはトランザクションステートフルである必要があります。
o The SIP server INVITEs Alice to a session and uses a temporary UUID {X} and a nil UUID pairing.
o SIPサーバーはAliceをセッションに招待し、一時的なUUID {X}とnil UUIDのペアを使用します。
o Alice receives and accepts this call setup and replaces the nil UUID with her UUID {A} in the session identifier, now {A,X}.
o アリスはこのコールセットアップを受信して受け入れ、セッション識別子のnil UUIDを彼女のUUID {A}に置き換えます。現在は{A、X}になっています。
o The transaction-stateful SIP server receives Alice's UUID {A} in the local UUID portion and keeps it there; and it discards its own UUID {X}, replacing this with a nil UUID value in the INVITE request to Bob as if this came from Alice originally.
o トランザクションステートフルSIPサーバーは、ローカルUUID部分でアリスのUUID {A}を受信し、そこに保持します。また、独自のUUID {X}を破棄し、これをボブへのINVITEリクエストでnil UUID値に置き換えます。これは、これが元々アリスから来たかのようです。
o Bob receives and accepts this INVITE request and adds his own UUID {B} to the session identifier, now {B,A}, for the response.
o ボブはこのINVITE要求を受信して受け入れ、自分のUUID {B}をセッション識別子（現在は{B、A}）に追加して応答します。
o The session is established.
o セッションが確立されます。
The following two subsections show examples of the session identifier for a 100 Trying response and a CANCEL request in a single call flow.
次の2つのサブセクションは、単一のコールフローにおける100 Trying応答とCANCEL要求のセッション識別子の例を示しています。
The following 100 Trying response is taken from [RFC5359], Section 2.9 ("Call Forwarding - No Answer").
次の100 Trying応答は、[RFC5359]のセクション2.9（「自動転送-応答なし」）から取得されます。
Session-ID Alice SIP Server Bob-1 Bob-2
| | | |
{A,N} |----INVITE----->| | |
{A,N} | |---INVITE---->| |
{N,A} |<--100 Trying---| | |
{B1,A} | |<-180 Ringing-| |
{B1,A} |<--180 Ringing--| | |
| | | |
| *Request Timeout* |
| | | |
{A,N} | |---CANCEL---->| |
{B1,A} | |<--200 OK-----| |
{B1,A} | |<---487-------| |
{A,B1} | |---- ACK ---->| |
| | | |
{N,A} |<-181 Call Fwd--| | |
| | | |
{A,N} | |------------------INVITE------>|
{B2,A} | |<----------------180 Ringing---|
{B2,A} |<-180 Ringing---| | |
{B2,A} | |<-----------------200 OK ------|
{B2,A} |<--200 OK-------| | |
{A,B2} |----ACK-------->| | |
{A,B2} | |------------------ACK--------->|
| | | |
|<=========== Both way RTP Established =========>|
| | | |
{A,B2} |----BYE-------->| | |
{A,B2} | |--------------------BYE------->|
{B2,A} | |<------------------200 OK------|
{B2,A} |<--200 OK-------| | |
| | | |
Figure 10: Session Identifier in the 100 Trying and CANCEL Messaging
図10：100回試行してキャンセルのメッセージングのセッション識別子
Below is the explanatory text from RFC 5359, Section 2.9, detailing what the desired behavior is in the above call flow (i.e., what the call flow is attempting to achieve).
以下は、RFC 5359のセクション2.9の説明文で、上記のコールフローの望ましい動作（コールフローが達成しようとしていること）の詳細を示しています。
Bob wants calls to B1 forwarded to B2 if B1 is not answered (information is known to the SIP server). Alice calls B1, and no one answers. The SIP server then places the call to B2.
Bobは、B1が応答されない場合（情報がSIPサーバーに認識されている場合）、B1へのコールをB2に転送することを望んでいます。アリスはB1に電話をかけ、誰も答えません。次に、SIPサーバーはB2に通話を発信します。
General operation of this example:
この例の一般的な操作：
o Alice generates an INVITE request because she wants to invite Bob to join her session. She creates a UUID as described in Section 10.1, and she places that value in the "local-uuid" field of the Session-ID header field value. Alice also generates a "remote-uuid" of nil and sends this along with the "local-uuid".
o アリスはボブをセッションに招待するため、INVITEリクエストを生成します。 10.1項の説明に従ってUUIDを作成し、その値をSession-IDヘッダーフィールド値の「local-uuid」フィールドに配置します。 Aliceはnilの「remote-uuid」も生成し、これを「local-uuid」と共に送信します。
o The SIP server (imagine this is a B2BUA), upon receiving Alice's INVITE request, generates the optional provisional response 100 Trying. Since the SIP server has no knowledge of Bob's UUID for his part of the session identifier value, it cannot include his "local-uuid". Rather, any 100 Trying response includes Alice's UUID in the "remote-uuid" portion of the Session-ID header-value with a nil "local-uuid" value in the response. This is consistent with what Alice's UA expects to receive in any SIP response containing this UUID.
o SIPサーバー（これがB2BUAであると想定）は、アリスのINVITE要求を受信すると、オプションの暫定応答100 Tryingを生成します。 SIPサーバーは、セッション識別子の値の一部であるボブのUUIDを認識していないため、 "local-uuid"を含めることはできません。むしろ、100 Trying応答には、Session-IDヘッダー値の「remote-uuid」部分にアリスのUUIDが含まれ、応答には「local-uuid」値が含まれません。これは、アリスのUAがこのUUIDを含むSIP応答で受信することを期待するものと一致しています。
In the same call flow example as the 100 Trying response is a CANCEL request. Please refer to Figure 10 for the CANCEL request example.
100 Trying応答と同じコールフローの例では、CANCEL要求です。 CANCELリクエストの例については、図10を参照してください。
General operation of this example:
この例の一般的な操作：
o In Figure 10 above, Alice generates an INVITE request with her UUID value in the Session-ID header field.
o 上記の図10では、アリスは、Session-IDヘッダーフィールドにUUID値を含むINVITEリクエストを生成します。
o Bob-1 responds to this INVITE request with a 180 Ringing. In that response, he includes his UUID in the Session-ID header field value (i.e., {B1,A}); thus completing the Session-ID header field for this session, even though no final response has been generated by any of Bob's UAs.
o Bob-1はこのINVITEリクエストに180 Ringingで応答します。その応答で、彼はセッションIDヘッダーフィールド値（つまり、{B1、A}）に自分のUUIDを含めます。したがって、BobのUAによって最終応答が生成されていなくても、このセッションのSession-IDヘッダーフィールドが完成します。
o While this means that if the SIP server were to generate a SIP request within this session it could include the complete SessionID, the server sends a CANCEL request and a CANCEL request always uses the same Session-ID header field as the original INVITE request. Thus, the CANCEL request would have a session identifier with the "local-uuid" = "A", and the "remote-uuid" = "N".
o つまり、SIPサーバーがこのセッション内でSIP要求を生成する場合、完全なSessionIDを含めることができますが、サーバーはCANCEL要求を送信し、CANCEL要求は常に元のINVITE要求と同じSession-IDヘッダーフィールドを使用します。したがって、CANCELリクエストには、「local-uuid」=「A」、および「remote-uuid」=「N」のセッション識別子があります。
o As it happens with this CANCEL, the SIP server intends to invite another UA of Bob's (i.e., B2) for Alice to communicate with.
o このキャンセルで発生するように、SIPサーバーは、アリスが通信するボブの別のUA（つまりB2）を招待する予定です。
o In this example call flow, taken from RFC 5359, Section 2.9, a 181 Call is Being Forwarded response is sent to Alice. Since the SIP server generated this SIP request, and has no knowledge of Bob-2's UUID value, it cannot include that value in this 181. Thus, and for the exact reasons the 100 Trying including the session identifier value, only Alice's UUID is included in the remote-uuid component of the Session-ID header field value, with a nil UUID present in the "local-uuid" component.
oこのサンプルコールフローでは、RFC 5359のセクション2.9から抜粋して、181 Call is Being Forwarded応答がAliceに送信されます。 SIPサーバーはこのSIPリクエストを生成し、Bob-2のUUID値を認識していないため、この値をこの181に含めることはできません。したがって、正確な理由により、100試行にはセッション識別子の値が含まれ、アリスのUUIDのみが含まれますSession-IDヘッダーフィールド値のremote-uuidコンポーネントで、 "local-uuid"コンポーネントにnil UUIDが存在する。
The following call flow was extracted from Section 6.1 of [RFC5589] ("Successful Transfer"), with the only changes being the names of the UAs to maintain consistency within this document.
次のコールフローは、[RFC5589]のセクション6.1（「成功した転送」）から抽出されたものであり、このドキュメント内の一貫性を維持するためのUAの名前のみが変更されています。
Alice is the transferee Bob is the transferer and Carol is the transfer-target
アリスは譲受人、ボブは譲受人、キャロルは譲受人
Session-ID Bob Alice Carol
| | |
{A,N} |<-----INVITE--------| |
{B,A} |------200 OK------->| |
{A,B} |<------ACK----------| |
| | |
{B,A} |--INVITE {hold}---->| |
{A,B} |<-200 OK------------| |
{B,A} |--- ACK ----------->| |
| | |
{B,A} |--REFER------------>|(Refer-To:Carol) |
{A,B} |<-202 Accepted------| |
| | |
{A,B} |<NOTIFY {100 Trying}| |
{B,A} |-200 OK------------>| |
| | |
{A,N} | |--INVITE------------>|
{C,A} | |<-200 OK-------------|
{A,C} | |---ACK-------------->|
| | |
{A,B} |<--NOTIFY {200 OK}--| |
{B,A} |---200 OK---------->| |
| | |
{B,A} |--BYE-------------->| |
{A,B} |<-200 OK------------| |
{C,A} | |<------------BYE-----|
{A,C} | |-------------200 OK->|
Figure 11: Out-Of-Dialog Call Transfer
図11：ダイアログ外のコール転送
General operation of this example:
この例の一般的な操作：
o Just as in Section 10.2, Figure 2, Alice invites Bob to a session, and Bob eventually transfers Alice to communicate with Carol.
o セクション10.2、図2と同様に、アリスはボブをセッションに招待し、ボブは最終的にアリスを転送してキャロルと通信します。
o What is different about the call flow in Figure 11 is that Bob's REFER is not in-dialog. Even so, this is treated as part of the same communication session and, thus, the session identifier in those messages is {A,B}.
o 図11のコールフローの違いは、BobのREFERがダイアログ内にないことです。それでも、これは同じ通信セッションの一部として扱われるため、これらのメッセージのセッション識別子は{A、B}です。
o Alice will use her existing UUID and the nil UUID ({A,N}) in the INVITE request towards Carol (who generates UUID "C" for this session), thus maintaining the common UUID within the session identifier for this new Alice-to-Carol session.
o アリスは彼女の既存のUUIDとnil UUID（{A、N}）をキャロル（このセッションのUUID "C"を生成する）へのINVITEリクエストで使用するため、この新しいアリスのセッション識別子内に共通のUUIDを維持します。 -キャロルセッション。
There is a much earlier document that specifies the use of a Session-ID header field (namely, [RFC7329]) that we will herewith attempt to achieve backwards compatibility. Neither Session-ID header field has any versioning information, so merely adding that this document describes "version 2" is insufficient. This section contains the set of rules for compatibility between the two specifications. Although the previous version was never standardized, it has been heavily implemented and adopted by other standards development organizations. For the purposes of this discussion, we will label the pre-standard specification of the Session-ID as the "old" version and this specification as the "new" version of the Session-ID.
Session-IDヘッダーフィールド（つまり、[RFC7329]）の使用を指定するはるか以前のドキュメントがあり、これを使用して後方互換性を達成しようとしています。どちらのSession-IDヘッダーフィールドにもバージョン情報がないため、このドキュメントで「バージョン2」について説明していることを追加するだけでは不十分です。このセクションには、2つの仕様間の互換性に関する一連の規則が含まれています。以前のバージョンは標準化されたことはありませんが、他の標準開発組織によって大幅に実装および採用されています。この議論のために、セッションIDの先行標準仕様を「古い」バージョンとしてラベル付けし、この仕様をセッションIDの「新しい」バージョンとしてラベル付けします。
The previous (i.e., "old") version only has a single UUID value as a Session-ID header field value, but has a generic-parameter value that can be of use.
以前の（つまり、「古い」）バージョンには、Session-IDヘッダーフィールド値として単一のUUID値しかありませんが、役立つ一般的なパラメーター値があります。
In order to have an "old" version talk to an "old" version implementation, nothing needs to be done as far as the IETF is concerned.
「古い」バージョンを「古い」バージョンの実装と通信させるために、IETFに関する限り、何もする必要はありません。
In order to have a "new" version talk to a "new" version implementation, both implementations need to follow this document (to the letter) and everything should be just fine.
「新しい」バージョンが「新しい」バージョンの実装と通信するためには、両方の実装がこの文書に（手紙に従って）従う必要があり、すべてがうまくいくはずです。
For this "new" implementation to work with the "old" implementation and an "old" implementation to work with "new" implementations, there needs to be a set of rules that all "new" implementations MUST follow if the "new" implementation will be communicating with devices that have implemented the "old" implementation.
この「新しい」実装が「古い」実装で動作し、「古い」実装が「新しい」実装で動作するためには、「新しい」実装がすべての「新しい」実装が従わなければならない一連の規則が必要です。 「古い」実装を実装したデバイスと通信します。
o Since no option tags or feature tags are to be used for distinguishing versions, the presence and order of any "remote-uuid" value within the Session-ID header field value is to be used to distinguish implementation versions.
o バージョンを区別するためにオプションタグや機能タグは使用されないため、実装バージョンを区別するために、Session-IDヘッダーフィールド値内の「remote-uuid」値の存在と順序が使用されます。
o If a SIP request has a "remote-uuid" value, this comes from a standard implementation, and not a pre-standard one.
o SIP要求に「remote-uuid」値がある場合、これは標準実装からのものであり、先行標準のものではありません。
o If a SIP request has no "remote-uuid" value, this comes from a pre-standard implementation, and not a standard one. In this case, one UUID is used to identify this dialog, even if the responder is a standard implementor of this specification.
o SIPリクエストに「remote-uuid」値がない場合、これは先行標準実装ではなく、標準実装からのものです。この場合、レスポンダーがこの仕様の標準実装者であっても、このダイアログを識別するために1つのUUIDが使用されます。
o If a SIP response has a non-nil "local-uuid" that is 32 octets long and differs from the endpoint's own UUID value, this response comes from a standard implementation.
o SIP応答に、32オクテットでnil以外の「local-uuid」があり、エンドポイント自体のUUID値とは異なる場合、この応答は標準実装からのものです。
o If a SIP response arrives that has the same value of Session-ID UUIDs in the same order as was sent, this comes from a pre-standard implementation and MUST NOT be discarded even though the "remote-uuid" may be nil. In this case, any new transaction within this dialog MUST preserve the order of the two UUIDs within all Session-ID header fields, including the ACK, until this dialog is terminated.
o 送信されたのと同じ順序で同じ値のSession-ID UUIDを持つSIP応答が到着した場合、これは先行標準の実装からのものであり、「remote-uuid」がnilの場合でも破棄してはなりません。この場合、このダイアログ内の新しいトランザクションは、このダイアログが終了するまで、ACKを含むすべてのSession-IDヘッダーフィールド内の2つのUUIDの順序を保持する必要があります。
o If a SIP response only contains the "local-uuid" that was sent originally, this comes from a pre-standard implementation and MUST NOT be discarded for removing the nil "remote-uuid". In this case, all future transactions within this dialog MUST contain only the UUID received in the first SIP response. Any new transaction starting a new dialog from the standard Session-ID implementation MUST include a "local-uuid" and a nil "remote-uuid", even if that new dialog is between the same two UAs.
o SIP応答に最初に送信された「local-uuid」のみが含まれている場合、これは先行標準の実装によるものであり、nilの「remote-uuid」を削除するために破棄してはなりません。この場合、このダイアログ内の以降のすべてのトランザクションには、最初のSIP応答で受信したUUIDのみが含まれている必要があります。新しいセッションが同じ2つのUAの間にある場合でも、標準のSession-ID実装から新しいダイアログを開始する新しいトランザクションには、「local-uuid」とnil「remote-uuid」を含める必要があります。
o Standard implementations should not expect pre-standard implementations to be consistent in their implementation, even within the same dialog. For example, perhaps the first, third, and tenth responses contain a "remote-uuid", but all the others do not. This behavior MUST be allowed by implementations of this specification.
o 標準実装は、同じダイアログ内であっても、先行標準実装が実装で一貫していることを期待すべきではありません。たとえば、1番目、3番目、10番目の応答には「remote-uuid」が含まれている可能性がありますが、他のすべての応答には含まれていません。この動作は、この仕様の実装で許可されている必要があります。
o The foregoing does not apply to other, presently unknown parameters that might be defined in the future. They are ignored for the purposes of interoperability with previous implementations.
o 上記は、将来定義される可能性のある現在不明な他のパラメーターには適用されません。以前の実装との相互運用性のため、これらは無視されます。
The session identifier MUST be constructed in such a way that does not convey any user or device information as outlined in Section 4.1. This ensures that the data contained in the session identifier itself does not convey user or device information; however, the session identifier may reveal relationships between endpoints that might not be revealed by messages without a session identifier.
セッション識別子は、セクション4.1で概説されているように、ユーザーまたはデバイスの情報を伝えない方法で構築する必要があります。これにより、セッション識別子自体に含まれるデータがユーザーまたはデバイスの情報を伝えないことが保証されます。ただし、セッション識別子は、セッション識別子のないメッセージでは明らかにできないエンドポイント間の関係を明らかにする場合があります。
Section 4.2 requires that a UA always generate a new, previously unused UUID when transmitting a request to initiate a new session. This ensures that two unrelated sessions originating from the same UA will never have the same UUID value, thereby removing the ability for an attacker to use the session identifier to identify the two unrelated sessions as being associated with the same user.
セクション4.2では、新しいセッションを開始する要求を送信するときに、UAが常に以前に未使用の新しいUUIDを生成する必要があります。これにより、同じUAから発信された2つの無関係なセッションが同じUUID値を持つことはなくなり、攻撃者がセッション識別子を使用して、2つの無関係なセッションを同じユーザーに関連付けられていると識別できなくなります。
Because of the inherent property that session identifiers are conveyed end-to-end and remain unchanged by a UA for the duration of a session, the session identifier could be misused to discover relationships between two or more parties when multiple parties are involved in the same session such as the case of a redirect, transfer, or conference. For example, suppose that Alice calls Bob and Bob, via his PBX (acting as a B2BUA), forwards or transfers the call to Carol. Without use of the session identifier, an unauthorized third party that is observing the communications between Alice and Bob might not know that Alice is actually communicating with Carol. If Alice, Bob, and Carol include the session identifier as a part of the signaling messages, it is possible for the third party to observe that the UA associated with Bob changed to some other UA. If the third party also has access to signaling messages between Bob and Carol, the third party can then discover that Alice is communicating with Carol. This would be true even if all other information relating to the session is changed by the PBX, including both signaling information and media address information. That said, the session identifier would not reveal the identity of Alice, Bob, or Carol. It would only reveal the fact that those endpoints were associated with the same session.
セッション識別子はエンドツーエンドで伝達され、セッション中にUAによって変更されないという固有の特性のため、複数のパーティが同じ関係にある場合、セッション識別子が誤用されて2つ以上のパーティ間の関係が発見される可能性があります。リダイレクト、転送、会議などのセッション。たとえば、アリスが自分のPBX（B2BUAとして機能）を介してボブとボブに電話をかけ、コールをキャロルに転送または転送するとします。セッション識別子を使用しないと、アリスとボブの間の通信を監視している無許可の第三者は、アリスが実際にキャロルと通信していることを知らない可能性があります。アリス、ボブ、およびキャロルがシグナリングメッセージの一部としてセッションIDを含む場合、ボブに関連付けられたUAが他のUAに変更されたことを第三者が観察する可能性があります。サードパーティもボブとキャロル間のシグナリングメッセージにアクセスできる場合、サードパーティはアリスがキャロルと通信していることを発見できます。これは、シグナリング情報とメディアアドレス情報の両方を含む、セッションに関連する他のすべての情報がPBXによって変更された場合でも当てはまります。とはいえ、セッション識別子はアリス、ボブ、キャロルの身元を明らかにしません。これらのエンドポイントが同じセッションに関連付けられているという事実だけが明らかになります。
This document allows for additional parameters (generic-param) to be included in the Session-ID header. This is done to allow for future extensions while preserving backward compatibility with this document. To protect privacy, the data for any generic-param included in the Session-ID header value MUST NOT include any user or device information. Additionally, any information conveyed through an additional parameter MUST NOT persist beyond the current session, and therefore MUST NOT be reused between unrelated sessions. Additional parameters MAY be used by future extensions of this document to correlate related communication sessions that cannot already be correlated by the procedures described in this document as long as the requirements regarding privacy and persistence defined above are followed.
このドキュメントでは、追加のパラメーター（generic-param）をSession-IDヘッダーに含めることができます。これは、このドキュメントとの下位互換性を維持しながら、将来の拡張を可能にするために行われます。プライバシーを保護するために、Session-IDヘッダー値に含まれるgeneric-paramのデータには、ユーザーまたはデバイスの情報を含めてはなりません。さらに、追加のパラメーターを介して伝えられる情報は、現在のセッションを超えて存続してはならないため（MUST NOT）、したがって、無関係なセッション間で再利用してはなりません（MUST NOT）。上記で定義されたプライバシーと永続性に関する要件が満たされている限り、このドキュメントで説明されている手順ではすでに関連付けられていない関連通信セッションを関連付けるために、このドキュメントの将来の拡張で追加のパラメータを使用できます。
An intermediary implementing a privacy service that provides user privacy as per Section 5.3 of [RFC3323] MAY choose to consider the Session-ID header as being a nonessential informational header with the understanding that doing so will impair the ability to use the session identifier for troubleshooting purposes.
[RFC3323]のセクション5.3に従ってユーザーのプライバシーを提供するプライバシーサービスを実装する仲介者は、トラブルシューティングにセッション識別子を使用する機能を損なうことを理解した上で、Session-IDヘッダーを重要でない情報ヘッダーと見なすことを選択できます。目的。
The following is the registration for the Session-ID header field to the "Header Name" registry at
以下は、「ヘッダー名」レジストリへのセッションIDヘッダーフィールドの登録です。
<http://www.iana.org/assignments/sip-parameters>:
＜ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／しｐーぱらめてｒｓ＞：
RFC number: RFC 7989
RFC番号：RFC 7989
Header name: 'Session-ID'
ヘッダー名： 'Session-ID'
Compact form: none
コンパクトな形：なし
Note: This document replaces the Session-ID header originally registered via [RFC7329].
注：このドキュメントは、[RFC7329]を介して最初に登録されたSession-IDヘッダーを置き換えます。
The following parameter has been added to the "Header Field Parameters and Parameter Values" section of the "Session Initiation Protocol (SIP) Parameters" registry:
次のパラメータが、「セッション開始プロトコル（SIP）パラメータ」レジストリの「ヘッダーフィールドパラメータとパラメータ値」セクションに追加されました。
+--------------+----------------+-------------------+-----------+
| Header Field | Parameter Name | Predefined Values | Reference |
+--------------+----------------+-------------------+-----------+
| Session-ID | remote | No | [RFC7989] |
+--------------+----------------+-------------------+-----------+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, <http://www.rfc-editor.org/info/rfc3515>.
[RFC3515] Sparks、R。、「Session Initiation Protocol（SIP）Refer Method」、RFC 3515、DOI 10.17487 / RFC3515、2003年4月、<http://www.rfc-editor.org/info/rfc3515>。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, DOI 10.17487/RFC3891, September 2004, <http://www.rfc-editor.org/info/rfc3891>.
[RFC3891] Mahy、R.、Biggs、B。、およびR. Dean、「Session Initiation Protocol（SIP） "Replaces" Header」、RFC 3891、DOI 10.17487 / RFC3891、2004年9月、<http：// www。 rfc-editor.org/info/rfc3891>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「A Universally Unique Identifier（UUID）URN Namespace」、RFC 4122、DOI 10.17487 / RFC4122、2005年7月、<http：//www.rfc- editor.org/info/rfc4122>。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, DOI 10.17487/RFC4579, August 2006, <http://www.rfc-editor.org/info/rfc4579>.
[RFC4579] Johnston、A.およびO. Levin、「Session Initiation Protocol（SIP）Call Control-Conferencing for User Agents」、BCP 119、RFC 4579、DOI 10.17487 / RFC4579、2006年8月、<http：//www.rfc -editor.org/info/rfc4579>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC7206] Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. Kaplan, "Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks", RFC 7206, DOI 10.17487/RFC7206, May 2014, <http://www.rfc-editor.org/info/rfc7206>.
[RFC7206]ジョーンズ、P。、サルゲイロ、G。、ポーク、J。、リース、L。、およびH.カプラン、「IPベースのマルチメディア通信ネットワークにおけるエンドツーエンドセッション識別の要件」、RFC 7206 、DOI 10.17487 / RFC7206、2014年5月、<http://www.rfc-editor.org/info/rfc7206>。
[H.323] International Telecommunications Union, "Packet-based multimedia communications systems", ITU-T Recommendation H.323, December 2009.
[H.323]国際電気通信連合、「パケットベースのマルチメディア通信システム」、ITU-T勧告H.323、2009年12月。
[H.460.27] International Telecommunications Union, "End-to-End Session Identifier for H.323 Systems", ITU-T Recommendation H.460.27, November 2015.
[H.460.27] International Telecommunications Union、「End-to-End Session Identifier for H.323 Systems」、ITU-T Recommendation H.460.27、2015年11月。
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, DOI 10.17487/RFC2543, March 1999, <http://www.rfc-editor.org/info/rfc2543>.
[RFC2543] Handley、M.、Schulzrinne、H.、Scholarer、E.、J。Rosenberg、「SIP：Session Initiation Protocol」、RFC 2543、DOI 10.17487 / RFC2543、1999年3月、<http：//www.rfc -editor.org/info/rfc2543>。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <http://www.rfc-editor.org/info/rfc3323>.
[RFC3323] Peterson、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、DOI 10.17487 / RFC3323、2002年11月、<http://www.rfc-editor.org/info/rfc3323> 。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC3725] 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, DOI 10.17487/RFC3725, April 2004, <http://www.rfc-editor.org/info/rfc3725>.
[RFC3725] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「Session Initiation Protocol（SIP）でのサードパーティコール制御（3pcc）のベストプラクティス」、BCP 85、RFC 3725 、DOI 10.17487 / RFC3725、2004年4月、<http://www.rfc-editor.org/info/rfc3725>。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, <http://www.rfc-editor.org/info/rfc4353>.
[RFC4353] Rosenberg、J。、「セッション開始プロトコル（SIP）との会議のフレームワーク」、RFC 4353、DOI 10.17487 / RFC4353、2006年2月、<http://www.rfc-editor.org/info/rfc4353 >。
[RFC5359] Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, DOI 10.17487/RFC5359, October 2008, <http://www.rfc-editor.org/info/rfc5359>.
[RFC5359] Johnston、A.、Ed。、Sparks、R.、Cunningham、C.、Donovan、S.、and K. Summers、 "Session Initiation Protocol Service Examples"、BCP 144、RFC 5359、DOI 10.17487 / RFC5359、 2008年10月、<http://www.rfc-editor.org/info/rfc5359>。
[RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, <http://www.rfc-editor.org/info/rfc5589>.
[RFC5589] Sparks、R.、Johnston、A.、Ed。、およびD. Petrie、「Session Initiation Protocol（SIP）Call Control-Transfer」、BCP 149、RFC 5589、DOI 10.17487 / RFC5589、2009年6月、<http ：//www.rfc-editor.org/info/rfc5589>。
[RFC6141] Camarillo, G., Ed., Holmberg, C., and Y. Gao, "Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)", RFC 6141, DOI 10.17487/RFC6141, March 2011, <http://www.rfc-editor.org/info/rfc6141>.
[RFC6141] Camarillo、G.、Ed。、Holmberg、C.、Y. Gao、 "Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol（SIP）"、RFC 6141、DOI 10.17487 / RFC6141、March 2011、<http://www.rfc-editor.org/info/rfc6141>。
[RFC6872] 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, DOI 10.17487/RFC6872, February 2013, <http://www.rfc-editor.org/info/rfc6872>.
[RFC6872] Gurbani、V.、Ed。、Burger、E.、Ed。、Anjali、T.、Abdelnur、H.、and O. Festor、 "The Common Log Format（CLF）for the Session Initiation Protocol（SIP） ：フレームワークと情報モデル」、RFC 6872、DOI 10.17487 / RFC6872、2013年2月、<http://www.rfc-editor.org/info/rfc6872>。
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <http://www.rfc-editor.org/info/rfc7092>.
[RFC7092] Kaplan、H。およびV. Pascual、「A Taxonomy of Session Initiation Protocol（SIP）Back-to-Back User Agents」、RFC 7092、DOI 10.17487 / RFC7092、2013年12月、<http：//www.rfc -editor.org/info/rfc7092>。
[RFC7329] Kaplan, H., "A Session Identifier for the Session Initiation Protocol (SIP)", RFC 7329, DOI 10.17487/RFC7329, August 2014, <http://www.rfc-editor.org/info/rfc7329>.
[RFC7329] Kaplan、H。、「A Session Identifier for the Session Initiation Protocol（SIP）」、RFC 7329、DOI 10.17487 / RFC7329、2014年8月、<http://www.rfc-editor.org/info/rfc7329> 。
Acknowledgements
謝辞
The authors would like to thank Robert Sparks, Hadriel Kaplan, Christer Holmberg, Paul Kyzivat, Brett Tate, Keith Drage, Mary Barnes, Charles Eckel, Peter Dawes, Andrew Hutton, Arun Arunachalam, Adam Gensler, Roland Jesske, and Faisal Siyavudeen for their invaluable comments during the development of this document.
著者は、Robert Sparks、Hadriel Kaplan、Christer Holmberg、Paul Kyzivat、Brett Tate、Keith Drage、Mary Barnes、Charles Eckel、Peter Dawes、Andrew Hutton、Arun Arunachalam、Adam Gensler、Roland Jesske、およびFaisal Siyavudeenに感謝します。このドキュメントの開発中の貴重なコメント。
Dedication
献身
This document is dedicated to the memory of James Polk, a long-time friend and colleague. James made important contributions to this specification, including being one of its primary editors. The IETF global community mourns his loss, and he will be missed dearly.
このドキュメントは、長年の友人であり同僚でもあるジェームスポークの思い出に捧げられています。 Jamesは、その主要な編集者の1人であることを含め、この仕様に重要な貢献をしました。 IETFのグローバルコミュニティは彼の損失を悼み、彼は心から惜しまれるでしょう。
Authors' Addresses
著者のアドレス
Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 United States of America
Paul E. Jones Cisco Systems、Inc. 7025 Kit Creek Rd。 Research Triangle Park、NC 27709アメリカ合衆国
Phone: +1 919 476 2048
Email: paulej@packetizer.com
Gonzalo Salgueiro Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 United States of America
Gonzalo Salgueiro Cisco Systems、Inc. 7025 Kit Creek Rd。 Research Triangle Park、NC 27709アメリカ合衆国
Phone: +1 919 392 3266
Email: gsalguei@cisco.com
Chris Pearce Cisco Systems, Inc. 2300 East President George Bush Highway Richardson, TX 75082 United States of America
Chris Pearce Cisco Systems、Inc. 2300 East President George Bush Highway Richardson、TX 75082アメリカ合衆国
Phone: +1 972 813 5123
Email: chrep@cisco.com
Paul Giralt Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 United States of America
ポールジラルトシスコシステムズ社7025キットクリークロード。 Research Triangle Park、NC 27709アメリカ合衆国
Phone: +1 919 991 5644
Email: pgiralt@cisco.com