[要約] RFC 8497は、SIPメッセージをログに記録するためのマーキング方法を提案しています。目的は、ネットワークトラブルシューティングやセキュリティ監査などの目的でSIPメッセージのログを容易にすることです。
Internet Engineering Task Force (IETF) P. Dawes
Request for Comments: 8497 Vodafone Group
Category: Standards Track C. Arunachalam
ISSN: 2070-1721 Cisco Systems
November 2018
Marking SIP Messages to Be Logged
ログに記録するSIPメッセージのマーク
Abstract
概要
SIP networks use signaling monitoring tools to diagnose user-reported problems and to perform regression testing if network or user agent (UA) software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents and therefore impractical to monitor SIP signaling end to end.
SIPネットワークは、信号監視ツールを使用して、ユーザーから報告された問題を診断し、ネットワークまたはユーザーエージェント（UA）ソフトウェアがアップグレードされている場合に回帰テストを実行します。トランジットネットワーク経由の接続を含め、ネットワークが成長して相互接続されるようになると、SIPシグナリングがユーザーエージェント間を通過するパスを予測することが現実的でなくなり、SIPシグナリングをエンドツーエンドで監視することが非現実的になります。
This document describes an indicator for the SIP protocol that can be used to mark signaling as being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and is not used in normal user agent signaling. Operators of all networks on the signaling path can agree to carry such marking end to end, including the originating and terminating SIP user agents, even if a session originates and terminates in different networks.
このドキュメントでは、ロギングに関心があるとしてシグナリングをマークするために使用できるSIPプロトコルのインジケータについて説明します。このようなマーキングは通常、ネットワークオペレーターによって制御されるネットワークテストの一部として適用され、通常のユーザーエージェントシグナリングでは使用されません。シグナリングパス上のすべてのネットワークのオペレーターは、セッションが異なるネットワークで開始および終了した場合でも、発信および終了のSIPユーザーエージェントを含め、このようなマーキングをエンドツーエンドで実行することに同意できます。
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 https://www.rfc-editor.org/info/rfc8497.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8497で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. "Log Me" Marking Protocol Aspects . . . . . . . . . . . . . . 4
3.1. Session-ID "logme" Parameter . . . . . . . . . . . . . . 4
3.2. Starting and Stopping Logging . . . . . . . . . . . . . . 5
3.3. Identifying Test Cases . . . . . . . . . . . . . . . . . 6
3.4. Passing the Marker . . . . . . . . . . . . . . . . . . . 6
3.4.1. To/From a User Device . . . . . . . . . . . . . . . . 6
3.4.2. To/From an External Network . . . . . . . . . . . . . 6
3.4.3. Across a Non-supporting SIP Intermediary . . . . . . 6
3.5. Logging Multiple Simultaneous Dialogs . . . . . . . . . . 6
3.6. Format of Logged Signaling . . . . . . . . . . . . . . . 7
3.7. Marking-Related Dialogs . . . . . . . . . . . . . . . . . 7
3.8. Forked Requests . . . . . . . . . . . . . . . . . . . . . 13
4. SIP Entity Behavior . . . . . . . . . . . . . . . . . . . . . 13
4.1. Scope of Marking . . . . . . . . . . . . . . . . . . . . 13
4.2. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. SIP Intermediaries Acting on Behalf of Endpoints . . . . 15
4.4. B2BUAs . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. "Log Me" Marker Processing by SIP Intermediaries . . . . 17
4.5.1. Stateless Processing . . . . . . . . . . . . . . . . 17
4.5.2. Stateful Processing . . . . . . . . . . . . . . . . . 17
4.5.2.1. "Log Me" Marking Not Supported by Originating UA 18
4.5.2.2. "Log Me" Marking Not Supported by Terminating UA 21
4.5.2.3. "Log Me" Marking Removed by Originating Network . 23
4.5.2.4. "Log Me" Marking Removed by Supporting
Terminating Network . . . . . . . . . . . . . . . 26
4.5.2.5. "Log Me" Marking Passed by Non-supporting
Terminating Network . . . . . . . . . . . . . . . 28
5. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. Error Cases . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1. Missing "Log Me" Marker Error Case . . . . . . . . . 31
5.1.2. "Log Me" Marker Appears Mid-dialog Error Case . . . . 35
5.2. Non-error Cases . . . . . . . . . . . . . . . . . . . . . 36
5.2.1. Missing "Log Me" Marker Non-error Case . . . . . . . 36
5.2.2. "Log Me" Marker Appears Mid-dialog Non-error Case . . 37
5.2.3. Combining Dialogs Non-error Case . . . . . . . . . . 37
5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 38
6. Augmented BNF for the "logme" Parameter . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 39
7.1. "Log Me" Authorization . . . . . . . . . . . . . . . . . 39
7.2. "Log Me" Marker Removal . . . . . . . . . . . . . . . . . 39
7.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 39
7.4. Data Protection . . . . . . . . . . . . . . . . . . . . . 40
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40
8.1. Personal Identifiers . . . . . . . . . . . . . . . . . . 40
8.2. Data Stored at SIP Intermediaries . . . . . . . . . . . . 41
8.3. Data Visible at Network Elements . . . . . . . . . . . . 41
8.4. Preventing Fingerprinting . . . . . . . . . . . . . . . . 41
8.5. Retaining Logs . . . . . . . . . . . . . . . . . . . . . 42
8.6. User Control of Logging . . . . . . . . . . . . . . . . . 42
8.7. Recommended Defaults . . . . . . . . . . . . . . . . . . 42
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
9.1. Registration of the "logme" Parameter . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.1. Normative References . . . . . . . . . . . . . . . . . . 43
10.2. Informative References . . . . . . . . . . . . . . . . . 45
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
When users experience problems with setting up sessions using SIP, enterprise or service provider network operators often have to identify the root cause by examining the SIP signaling. Also, when network or user agent (UA) software or hardware is upgraded, regression testing is needed. Such diagnostics apply to a small proportion of network traffic and can apply end to end, even if signaling crosses several networks possibly belonging to several different network operators. It may not be possible to predict the path through those networks in advance, therefore, a mechanism is needed to mark a session as being of interest so that SIP entities along the signaling path can provide diagnostic logging. [RFC8123] illustrates this motivating scenario. This document describes a solution that meets the requirements for such "log me" marking of SIP signaling also defined in [RFC8123].
ユーザーがSIPを使用してセッションを設定する際に問題が発生した場合、企業またはサービスプロバイダーのネットワークオペレーターは、SIPシグナリングを調べて根本的な原因を特定する必要があります。また、ネットワークまたはユーザーエージェント（UA）ソフトウェアまたはハードウェアをアップグレードする場合は、回帰テストが必要です。このような診断は、一部のネットワークトラフィックに適用され、シグナリングが複数の異なるネットワークオペレーターに属している可能性がある複数のネットワークを通過する場合でも、エンドツーエンドで適用できます。これらのネットワークを通るパスを事前に予測できない場合があるため、シグナリングパスに沿ったSIPエンティティが診断ログを提供できるように、セッションを対象としてマークするメカニズムが必要です。 [RFC8123]は、このやる気を起こさせるシナリオを示しています。このドキュメントでは、[RFC8123]でも定義されているSIPシグナリングのそのような「ログミー」マーキングの要件を満たすソリューションについて説明します。
This document also defines a new header field parameter, "logme", for the Session-ID header field [RFC7989]. Implementations of this document MUST implement [RFC7989].
このドキュメントでは、Session-IDヘッダーフィールド[RFC7989]の新しいヘッダーフィールドパラメータ「logme」も定義しています。このドキュメントの実装は[RFC7989]を実装しなければなりません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Logging for diagnostic purposes is most effective when it is applied end to end in a communication session. This ability requires a "log me" marker to be passed through SIP intermediaries. The Session-ID header field defined in [RFC7989] was chosen to carry the "log me" marker as a "logme" parameter since the session identifier is typically passed through SIP Back-to-Back User Agents (B2BUAs) (described in [RFC7092]) or other intermediaries, as per the Session-ID requirement REQ3 in [RFC7206]. The "logme" parameter shown in Figure 1 does not introduce any device-specific or user-specific information and MUST be passed unchanged with the Session-ID header field. There is an exception, however, for the cases specified in Section 3.4.2 where the "log me" marker may be removed at a network boundary.
診断目的のロギングは、通信セッションのエンドツーエンドで適用される場合に最も効果的です。この機能を使用するには、「ログミー」マーカーをSIP仲介経由で渡す必要があります。 [RFC7989]で定義されたSession-IDヘッダーフィールドは、「log me」マーカーを「logme」パラメーターとして運ぶために選択されました。これは、セッションIDが通常SIPバックツーバックユーザーエージェント（B2BUA）（[ RFC7092]）または他の仲介者、[RFC7206]のセッションID要件REQ3に従って。図1に示す「logme」パラメーターは、デバイス固有またはユーザー固有の情報を導入せず、Session-IDヘッダーフィールドで変更せずに渡す必要があります。ただし、3.4.2項で指定されている「log me」マーカーがネットワーク境界で削除される場合は例外です。
Alice Proxy Registrar
u1.example.com p1.example.com r1.example.com
| | |
|(1) INVITE | |
| Session-ID: ab30317f1a784dc48ff824d0d3715d86;
| remote=47755a9de7794ba387653f2099600ef2;logme
|----------------->| |
| | |
Figure 1: "Log Me" Marking Using the "logme" Session-ID Header Field Parameter
図1：「logme」セッションIDヘッダーフィールドパラメータを使用した「Log Me」マーキング
If a dialog is to be "log me" marked, then marking MUST start with the SIP request that initiates that dialog (dialog-initiating requests are described in Section 12.1 of [RFC3261]). For the most effective testing and troubleshooting, marking continues for the lifetime of the dialog, applies to each request and response in the dialog, and applies uninterrupted end to end (including user devices). The "log me" marking mechanism described in this document allows for parts of the signaling path to not be marked, e.g, because an endpoint does not support the "log me" marking mechanism (see Section 4.5.2) or because an endpoint or intermediary deliberately removes the "log me" marker (see Section 4.5.2.4). Also, marking errors can terminate marking before the dialog ends (see Section 5.3).
ダイアログに「ログミー」マークを付ける場合、そのダイアログを開始するSIPリクエストでマーキングを開始する必要があります（ダイアログ開始リクエストについては、[RFC3261]のセクション12.1で説明されています）。最も効果的なテストとトラブルシューティングのために、マーキングはダイアログの存続期間中継続し、ダイアログの各要求と応答に適用され、中断のないエンドツーエンド（ユーザーデバイスを含む）を適用します。このドキュメントで説明する「ログミー」マーキングメカニズムでは、たとえば、エンドポイントが「ログミー」マーキングメカニズムをサポートしていないため（セクション4.5.2を参照）、エンドポイントや仲介者は意図的に「ログミー」マーカーを削除します（セクション4.5.2.4を参照）。また、マーキングエラーにより、ダイアログが終了する前にマーキングが終了する場合があります（セクション5.3を参照）。
A UA or intermediary adds a "log me" marker in an unmarked request or response in two cases: first, because it is configured to add the marking to a dialog-creating request, or second, because it has received a dialog-creating request that is being "log me" marked causing it to maintain state to ensure that all requests and responses in the dialog are similarly "log me" marked. Once the "log me" marking is started for a dialog, all subsequent requests and responses in this dialog are "log me" marked. Marking is stopped when this dialog and its related dialogs end. It is considered an error (see Section 5.1.2) if "log me" marking is started in a mid-dialog request or response.
UAまたは仲介者は、マークされていない要求または応答に「ログミー」マーカーを追加します。1つは、ダイアログ作成要求にマークを追加するように構成されているため、もう1つは、ダイアログ作成要求を受信したためです。これは "ログミー"マークが付けられているため、ダイアログのすべての要求と応答が同様に "ログミー"マークが付けられるように状態が維持されます。ダイアログの「ログミー」マーキングが開始されると、このダイアログの後続のすべての要求と応答に「ログミー」マークが付けられます。このダイアログとそれに関連するダイアログが終了すると、マーキングは停止します。ダイアログの途中の要求または応答で「log me」マークが開始された場合、エラーと見なされます（セクション5.1.2を参照）。
For the first case, "log me" marking trigger condition configurations that define whether a UA or intermediary can initiate "log me" marking for a given dialog are out of scope of this document. As an example of trigger condition configurations, the UA or intermediary could be configured to add a "log me" marker for all dialogs initiated during a specific time period (e.g., 9:00 am - 10:00 am every day) or for specific dialogs that have a particular "User-Agent" header field value. They could also be configured to add a "log me" marker for a specific set of called party numbers for which users are experiencing call setup failures.
最初のケースでは、UAまたは仲介者が特定のダイアログに対して「ログミー」マーキングを開始できるかどうかを定義する「ログミー」マーキングトリガー条件設定は、このドキュメントの範囲外です。トリガー条件構成の例として、特定の期間（たとえば、毎日午前9時から午前10時）または特定の期間に開始されたすべてのダイアログに「ログミー」マーカーを追加するように、UAまたは仲介者を構成できます。特定の「User-Agent」ヘッダーフィールド値を持つダイアログ。また、ユーザーがコールセットアップの失敗を経験している特定の着信側番号のセットに「ログミー」マーカーを追加するように設定することもできます。
For the second case of a UA or intermediary detecting that a dialog-initiating request is being "log me" marked, the scope of such marking extends to the lifetime of the dialog. In addition, as discussed in Section 3.7, "log me" marked dialogs that create related dialogs (e.g., REFER) may transfer the marking to the related dialogs. In such cases, the entire "session", identified by the Session-ID header field, is "log me" marked.
UAまたは仲介者がダイアログ開始要求に「ログミー」マークが付けられていることを検出する2番目のケースでは、そのようなマーキングの範囲はダイアログの存続期間にまで及びます。さらに、セクション3.7で説明したように、関連するダイアログ（REFERなど）を作成する「ログミー」マーク付きダイアログは、関連するダイアログにマーキングを転送する場合があります。このような場合、Session-IDヘッダーフィールドで識別される「セッション」全体に「ログミー」マークが付けられます。
The local Universally Unique Identifier (UUID) portion of the Session-ID header field value [RFC7989] in the initial SIP request of a dialog is used as a random test case identifier (described in REQ 5 in [RFC8123]). This provides the ability to collate all logged SIP requests and responses to the initial SIP request in a dialog or standalone transaction.
ダイアログの最初のSIPリクエストのセッションIDヘッダーフィールド値[RFC7989]のローカルのUniversally Unique Identifier（UUID）部分は、ランダムなテストケース識別子として使用されます（[RFC8123]のREQ 5で説明）。これにより、ダイアログまたはスタンドアロントランザクションで、ログに記録されたすべてのSIP要求と最初のSIP要求への応答を照合する機能が提供されます。
When a user device inserts the "log me" marker, the marker MUST be passed unchanged in the Session-ID header field across an edge proxy or a B2BUA adjacent to the user device.
ユーザーデバイスが「ログミー」マーカーを挿入するとき、マーカーは変更せずに、ユーザーデバイスに隣接するエッジプロキシまたはB2BUA全体のセッションIDヘッダーフィールドに渡されます。
An external network is a peer network connected at a network boundary as defined in [RFC8123].
外部ネットワークは、[RFC8123]で定義されているネットワーク境界で接続されたピアネットワークです。
External networks may be connected directly or via a peering network, and such networks often have specific connection agreements. Whether "log me" marking is removed depends on the policy applied at the network-to-network interface. Troubleshooting and testing will be easier if peer networks endeavor to make agreements to pass "log me" marking unchanged. However, since a "log me" marker may cause a SIP entity to log the SIP header and body of a request or response, the "log me" marker MUST be removed at a network boundary if no agreement exists between peer networks.
外部ネットワークは、直接またはピアリングネットワークを介して接続できます。そのようなネットワークには、特定の接続許可書がよくあります。 「ログミー」マークが削除されるかどうかは、ネットワーク間インターフェースで適用されるポリシーによって異なります。ピアネットワークが「ログミー」マークを変更せずに通過することを合意するよう努めれば、トラブルシューティングとテストが容易になります。ただし、「ログミー」マーカーを使用すると、SIPエンティティが要求または応答のSIPヘッダーと本文をログに記録する可能性があるため、ピアネットワーク間に合意がない場合は、ネットワーク境界で「ログミー」マーカーを削除する必要があります。
"Log me" marking is most effective if passed end to end. However, intermediaries that do not comply with this document might pass the "log me" marker unchanged or even drop it entirely.
「ログミー」マークは、エンドツーエンドで渡される場合に最も効果的です。ただし、このドキュメントに準拠していない仲介者は、「log me」マーカーを変更せずに渡すか、完全に削除することさえできます。
Multiple SIP dialogs can be simultaneously logged by an originating UA, terminating UA, and SIP entities on the signaling path. These dialogs are differentiated by their test case identifier (the local UUID portion of the Session-ID header field value at the originating device).
複数のSIPダイアログは、シグナリングパス上の発信UA、着信UA、およびSIPエンティティによって同時にログに記録できます。これらのダイアログは、テストケース識別子（発信元デバイスのセッションIDヘッダーフィールド値のローカルUUID部分）によって区別されます。
The entire SIP message (SIP request line, response line, header fields, and message body) SHOULD be logged since troubleshooting might be difficult if information is missing. Logging SHOULD use common standard formats such as SIP Common Log Format (CLF) defined in [RFC6873] and Libpcap as defined in "vnd.tcpdump.pcap" in the Media Types registry [MEDIA-TYPES]. If SIP CLF is used, the entire message is logged using Vendor-ID = 00000000 and Tag = 02 in the <OptionalFields> portion of the SIP CLF record (see Section 4.4 of [RFC6873]). Header fields SHOULD be logged in the form in which they appear in the message; they SHOULD NOT be converted between long and compact forms described in Section 7.3.3 of [RFC3261].
情報が不足しているとトラブルシューティングが困難になる可能性があるため、SIPメッセージ全体（SIP要求行、応答行、ヘッダーフィールド、メッセージ本文）をログに記録する必要があります。ログは、[RFC6873]で定義されているSIP共通ログ形式（CLF）や、メディアタイプレジストリ[MEDIA-TYPES]の「vnd.tcpdump.pcap」で定義されているLibpcapなどの一般的な標準形式を使用する必要があります。 SIP CLFが使用されている場合、メッセージ全体は、SIP CLFレコードの<OptionalFields>部分のVendor-ID = 00000000およびTag = 02を使用して記録されます（[RFC6873]のセクション4.4を参照）。ヘッダーフィールドは、メッセージに表示される形式で記録する必要があります。 [RFC3261]のセクション7.3.3で説明されている長い形式とコンパクトな形式の間で変換するべきではありません。
"Log me" marking is done per dialog; typically, it begins at dialog creation and ends when the dialog ends. However, dialogs related to a "log me" marked dialog MAY also be "log me" marked for call control features such as call forward, transfer, park, and join. As described in Section 6 of [RFC7989], related dialogs can occur when an endpoint receives a 3xx message, a REFER that directs the endpoint to a different peer, an INVITE request with Replaces that also potentially results in communicating with a new peer, or an INVITE with a Join header field as described in [RFC3911]. An example is the call transfer feature described in Section 6.1 of [RFC5589]. The logged signaling for related dialogs can be correlated using Session-ID header field values as described in Section 10.9 of [RFC7989].
「ログミー」マークはダイアログごとに行われます。通常、ダイアログの作成時に開始し、ダイアログが終了すると終了します。ただし、「ログミー」とマークされたダイアログに関連するダイアログは、自動転送、転送、パーク、参加などの通話制御機能のために「ログミー」とマークされる場合があります。 [RFC7989]のセクション6で説明されているように、エンドポイントが3xxメッセージ、エンドポイントを別のピアに転送するREFER、新しいピアとの通信につながる可能性のあるReplacesを含むINVITEリクエストを受信すると、関連するダイアログが発生する可能性があります。 [RFC3911]で説明されているJoinヘッダーフィールドを持つINVITE。 [RFC5589]のセクション6.1で説明されている通話転送機能がその例です。 [RFC7989]のセクション10.9で説明されているように、関連ダイアログのログ信号は、Session-IDヘッダーフィールド値を使用して相関させることができます。
In the example shown in Figure 2, Alice has reported problems making call transfers. Her terminal is placed in debug mode in preparation for "log me" marked signaling from the network administrator, Bob. Bob's terminal is configured to "log me" mark and log signaling for calls originated during the troubleshooting session (e.g., for a duration of 15 minutes). Bob, who is troubleshooting the problem, arranges to make a call that Alice can attempt to transfer. Bob calls Alice, which creates initial dialog1, and then Alice transfers the call to connect Bob to Carol. Logged signaling is correlated using the test case identifier, which is the local UUID ab30317f1a784dc48ff824d0d3715d86 in the Session-ID header field of INVITE request F1. Logging by Alice's terminal begins when it receives and echoes the "log me" marker in INVITE F1 and ends when the last request or response in the dialog is sent or received (200 OK F7 of dialog1). Also during dialog1, Alice's terminal logs related REFER dialog2, which it initiates and terminates as part of the call transfer. Alice's terminal inserts a "log me" marker in the REFER request and 200 OK responses to NOTIFY requests in dialog2. Both dialog1 and dialog2 have the same test case identifier.
図2に示す例では、アリスがコール転送の実行に関する問題を報告しています。彼女の端末は、ネットワーク管理者であるボブからの「ログミー」とマークされたシグナリングに備えて、デバッグモードになります。ボブの端末は、トラブルシューティングセッション中に（たとえば、15分間）発信された通話の「ログミー」マークとシグナリングのログを記録するように構成されています。問題をトラブルシューティングしているボブは、アリスが転送を試みることができる電話をかけるように手配します。ボブはアリスに電話をかけて、最初のダイアログ1を作成します。その後、アリスはボブをキャロルに接続するために通話を転送します。ログに記録されたシグナリングは、INVITEリクエストF1のSession-IDヘッダーフィールドのローカルUUID ab30317f1a784dc48ff824d0d3715d86であるテストケース識別子を使用して関連付けられます。 Aliceの端末によるロギングは、INVITE F1の「log me」マーカーを受信してエコーするときに始まり、ダイアログ内の最後の要求または応答が送信または受信されたときに終了します（dialog1の200 OK F7）。また、dialog1の間、Aliceの端末は関連するREFER dialog2をログに記録します。これは、コール転送の一部として開始および終了します。アリスの端末は、REFER要求に「ログミー」マーカーを挿入し、dialog2のNOTIFY要求に対する200 OK応答を挿入します。 dialog1とdialog2の両方が同じテストケース識別子を持っています。
Logging by Bob's terminal begins when it sends INVITE F1, which includes the "log me" marker, and ends when dialog3, initiated by Bob, ends. Logging by Carol's terminal begins when it receives the INVITE F5 with the "log me" marker and ends when dialog3 ends.
Bobの端末によるロギングは、「log me」マーカーを含むINVITE F1を送信したときに始まり、Bobによって開始されたdialog3が終了したときに終了します。 Carolの端末によるロギングは、「log me」マーカー付きのINVITE F5を受信したときに始まり、dialog3が終了したときに終了します。
dialog3 is not logged by Alice's terminal; however, the test case identifier ab30317f1a784dc48ff824d0d3715d86 is also the test case identifier (local-uuid) in INVITE F5. Also, the test case identifier of dialog2, which is logged by Alice's terminal, can be linked to dialog1 and dialog3 because the remote-uuid component of dialog2 is the test case identifier ab30317f1a784dc48ff824d0d3715d86.
dialog3は、アリスの端末によってログに記録されません。ただし、テストケース識別子ab30317f1a784dc48ff824d0d3715d86は、INVITE F5のテストケース識別子（local-uuid）でもあります。また、dialice2のリモートuuidコンポーネントはテストケース識別子ab30317f1a784dc48ff824d0d3715d86であるため、Aliceの端末によってログに記録されるdialog2のテストケース識別子をdialog1およびdialog3にリンクできます。
Alice Bob Carol
Transferor Transferee Transfer
| | Target
| INVITE F1 | |
dialog1 |<-------------------| |
| 200 OK F2 | |
dialog1 |------------------->| |
| ACK | |
dialog1 |<-------------------| |
| INVITE (hold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| REFER F3 (Target-Dialog:1) |
dialog2 |------------------->| |
| 200 OK | |
dialog2 |<-------------------| |
| NOTIFY (100 Trying) F4 |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| | INVITE F5 |
dialog3 | |------------------->|
| | 200 OK |
dialog3 | |<-------------------|
| | ACK |
dialog3 | |------------------->|
| NOTIFY (200 OK) F6| |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| BYE | |
dialog1 |------------------->| |
| 200 OK F7 | |
dialog1 |<-------------------| |
| | BYE |
dialog3 | |<-------------------|
| | 200 OK |
dialog3 | |------------------->|
Figure 2: "Log Me" Marking Related Dialogs in Call Transfer
図2：コール転送の「ログミー」マーキング関連ダイアログ
F1: Bob's UA inserts the "logme" parameter in the Session-ID header field of the INVITE request that creates dialog1.
F1：ボブのUAは、dialog1を作成するINVITEリクエストのSession-IDヘッダーフィールドに「logme」パラメーターを挿入します。
F3: Alice's UA inserts the "logme" parameter in the Session-ID header field of the REFER request that creates dialog2, which is related to dialog1.
F3：AliceのUAは、dialog1に関連するdialog2を作成するREFERリクエストのSession-IDヘッダーフィールドに「logme」パラメーターを挿入します。
F5: Bob's UA inserts the "logme" parameter in the Session-ID header field of the INVITE request that creates dialog3, which is related to dialog1.
F5：ボブのUAは、dialog1に関連するdialog3を作成するINVITEリクエストのSession-IDヘッダーフィールドに「logme」パラメーターを挿入します。
F1 INVITE Transferee -> Transferor
F1 INVITE転送先->転送者
INVITE sips:transferor@atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000;logme
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transferor -> Transferee
F2 200 OK転送者->転送先
SIP/2.0 200 OK
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86;logme
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...
F3 REFER Transferor -> Transferee
F3 REFER Transferor-> Transferee
REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86;logme
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: tdialog
Refer-To: <sips:transfertarget@chicago.example.com>
Target-Dialog: 090459243588173445;local-tag=7553452
;remote-tag=31kdl4i3k
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Length: 0
F4 NOTIFY Transferee -> Transferor
F4 NOTIFY譲受人->譲渡人
NOTIFY sips:4889445d8kjtk3@atlanta.example.com
;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
;tag=a6c85cf
Call-ID: a84b4c76e66710
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2;logme
CSeq: 73 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: active;expires=60
Content-Type: message/sipfrag
Content-Length: ...
F5 INVITE Transferee -> Transfer Target
F5 INVITE転送先->転送先
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas41234
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferee@biloxi.example.com>;tag=j3kso3iqhq
Call-ID: 90422f3sd23m4g56832034
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000;logme
CSeq: 521 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...
F6 NOTIFY Transferee -> Transferor
F6 NOTIFY譲受人->譲渡人
NOTIFY sips:4889445d8kjtk3@atlanta.example.com
;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
;tag=a6c85cf
Call-ID: a84b4c76e66710
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2;logme
CSeq: 74 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
A SIP intermediary is required to copy the "log me" marker into forked requests. SIP request forking is discussed in Sections 4 and 16.6 of [RFC3261].
「log me」マーカーをフォークされたリクエストにコピーするには、SIP仲介者が必要です。 SIPリクエストフォークは[RFC3261]のセクション4と16.6で議論されています。
"Log me" marking is intended to be limited, in time period and number of dialogs marked, to the minimum needed to troubleshoot a particular problem or perform a particular test.
「ログミー」マークは、マークされたダイアログの期間と数において、特定の問題のトラブルシューティングまたは特定のテストの実行に必要な最小限に制限されることを目的としています。
o SIP entities MUST be configured to "log me" mark only dialogs needed for the current testing purpose, e.g., troubleshooting or regression testing. The mechanisms in this section ensure that "log me" marking begins at dialog creation and, other than cases of marking related dialogs or premature ending, ends when the dialog being "log me" marked ends.
o SIPエンティティは、現在のテストの目的（トラブルシューティングや回帰テストなど）に必要なダイアログのみを「ログに記録」するように構成する必要があります。このセクションのメカニズムは、「ログミー」のマークがダイアログの作成時に始まり、関連するダイアログのマークや早期終了の場合を除いて、「ログミー」のマークが付けられているダイアログが終了すると終了することを保証します。
o If a dialog is to be marked, the only way to initiate "log me" marking is at the dialog-creating request (e.g., SIP INVITE) sent by an originating endpoint or an intermediary that marks on behalf of the originating endpoint. Marking that appears mid-dialog is an error as described in Section 5.1.2. The final terminating endpoint, or intermediary that marks on behalf of the terminating endpoint, cannot initiate marking, but it takes action as defined in Sections 4.2 and 4.3 if it receives an incoming "log me" marker.
o ダイアログにマークを付ける場合、「ログミー」マーキングを開始する唯一の方法は、発信側エンドポイントまたは発信側エンドポイントに代わってマークを付ける仲介者によって送信されるダイアログ作成リクエスト（SIP INVITEなど）にあります。セクション5.1.2で説明されているように、ダイアログの途中で表示されるマークはエラーです。最後の終端エンドポイント、または終端エンドポイントに代わってマークを付ける仲介者は、マーキングを開始できませんが、着信「ログミー」マーカーを受信した場合、セクション4.2および4.3で定義されているアクションを実行します。
Note that the error cases described in Section 5.1 cause SIP entities to stop "log me" marking, and the requirements in Section 7 also place requirements on SIP entities, including allowing SIP entities to not log signaling based on local policies (see Section 8.6).
セクション5.1で説明されているエラーケースにより、SIPエンティティは「ログミー」マーキングを停止します。また、セクション7の要件は、SIPエンティティがローカルポリシーに基づいてシグナリングをログに記録できないようにするなど、SIPエンティティに要件を課します（セクション8.6を参照）。 。
A common scenario is to have both originating and terminating endpoints support "log me" marking with the originating endpoint configured to initiate "log me" marking. In this simplest use case, the originating UA inserts a "log me" marker in the dialog-creating SIP request and all subsequent SIP requests within that dialog. The "log me" marker is passed through the SIP intermediaries and arrives at the terminating UA, which echoes the "log me" marker in the corresponding responses. If the terminating UA sends an in-dialog request on a dialog that is being "log me" marked, it inserts a "log me" marker and the originating UA echoes the "log me" marker in responses. The terminating UA logs the "log me" marked SIP requests and responses if it is allowed as per policy defined in the terminating network. This basic use case suggests the following rules for originating and terminating UAs.
一般的なシナリオは、発信側と着信側の両方のエンドポイントで「ログミー」マーキングをサポートし、発信側のエンドポイントで「ログミー」マーキングを開始するように設定することです。この最も単純な使用例では、元のUAは、ダイアログを作成するSIPリクエストと、そのダイアログ内の後続のすべてのSIPリクエストに「ログミー」マーカーを挿入します。 「ログミー」マーカーはSIP仲介者を通過し、対応する応答で「ログミー」マーカーをエコーする終端UAに到達します。終了UAが「ログミー」マークが付けられているダイアログでダイアログ内要求を送信すると、「ログミー」マーカーが挿入され、元のUAが「ログミー」マーカーを応答にエコーします。着信側のUAは、「log me」とマークされたSIP要求と応答を、着信側のネットワークで定義されたポリシーに従って許可されている場合、ログに記録します。この基本的な使用例は、UAの開始と終了に関する次のルールを示唆しています。
For originating UAs:
元のUAの場合：
o The originating UA configured for "log me" marking MUST insert a "log me" marker into the dialog-creating SIP request and subsequent in-dialog SIP requests.
o 「ログミー」マーキング用に構成された元のUAは、「ログミー」マーカーをダイアログ作成SIPリクエストと後続のダイアログ内SIPリクエストに挿入する必要があります。
o The originating UA itself logs marked requests and responses.
o 元のUA自体は、マークされた要求と応答をログに記録します。
o The originating UA echoes, in responses, the "log me" marker received in in-dialog requests from the terminating side.
o 発信側UAは、応答として、着信側からのダイアログ内要求で受信した「ログミー」マーカーをエコーします。
o The originating UA logs the SIP responses that it sends in response to received "log me" marked in-dialog requests.
o 元のUAは、受信した「ログミー」とマークされたダイアログ内要求に応答して送信するSIP応答をログに記録します。
o The originating UA MAY also apply these rules to any subsequent related SIP dialogs as described in Section 3.7.
o 元のUAは、セクション3.7で説明されているように、後続の関連するSIPダイアログにもこれらのルールを適用できます（MAY）。
For terminating UAs:
UAを終了する場合：
o The terminating UA detects that a dialog is of interest to logging by the existence of a "log me" marker in an incoming dialog-creating SIP request.
o 着信UAは、着信ダイアログを作成するSIP要求に「ログミー」マーカーが存在することにより、ダイアログがロギングに関心があることを検出します。
o The terminating UA itself logs marked requests and corresponding marked responses if allowed as per policy.
o ポリシーに従って許可されている場合、終了するUA自体は、マークされた要求と対応するマークされた応答をログに記録します。
o The terminating UA MUST echo a "log me" marker in responses to a SIP request that included a "log me" marker.
o 終端UAは、「ログミー」マーカーを含むSIPリクエストへの応答で「ログミー」マーカーをエコーする必要があります。
o If the terminating UA has detected that a dialog is being "log me" marked, it MUST insert a "log me" marker in any in-dialog SIP requests that it sends.
o 終了しているUAは、ダイアログに "ログミー"マークが付いていることを検出した場合、送信するダイアログ内のSIP要求に "ログミー"マーカーを挿入する必要があります。
o The terminating UA itself logs any in-dialog SIP requests that it sends if allowed as per policy.
o 終端UA自体は、ポリシーに従って許可されている場合、それが送信するダイアログ内のSIPリクエストをログに記録します。
o The terminating UA MAY also apply these rules to any subsequent related SIP dialogs as described in Section 3.7.
o 終了するUAは、セクション3.7で説明されているように、後続の関連するSIPダイアログにもこれらのルールを適用できます（MAY）。
A network operator may know that some of the UAs connected to the network do not support "log me" marking. Subject to the authorizations in Section 7.1, a SIP intermediary close to the UA (e.g., edge proxy, B2BUA) on the originating and/or terminating sides inserts the "log me" marker instead in order to test sessions involving such UAs.
ネットワークオペレータは、ネットワークに接続されているUAの一部が「ログミー」マーキングをサポートしていないことを知っている場合があります。セクション7.1の承認に従い、発信側および/または着信側のUA（エッジプロキシ、B2BUAなど）に近いSIP仲介者は、そのようなUAを含むセッションをテストするために、代わりに「ログミー」マーカーを挿入します。
The originating and terminating SIP intermediaries are not identified by protocol means but are designated and explicitly configured by the network administrator to "log me" mark on behalf of endpoints. The intermediaries that are known to be closest to the terminals can be configured to "log me" mark on behalf of terminals that do not support "log me" marking. The originating SIP intermediary is the first one to be traversed by a SIP request sent by the originating endpoint. Similarly, the terminating SIP intermediary is the last intermediary traversed before the terminating endpoint is reached.
発信側と着信側のSIP仲介者はプロトコル手段では識別されませんが、エンドポイントに代わって「ログミー」マークを付けるようにネットワーク管理者によって指定および明示的に設定されます。端末に最も近いことがわかっている仲介者は、「ログミー」マーキングをサポートしていない端末に代わって「ログミー」マークを付けるように設定できます。発信元のSIP仲介者は、発信元のエンドポイントから送信されたSIP要求が最初に通過する仲介者です。同様に、終了するSIP仲介者は、終了するエンドポイントに到達する前に通過する最後の仲介者です。
The SIP intermediary at the originating side is configured to insert the "log me" marker on behalf of the originating endpoint. If the terminating UA does not echo the "log me" marker in responses to a marked request, then the SIP intermediary closest to the terminating UA, if configured to mark on behalf of the terminating UA, inserts a "log me" marker in responses to the request. Likewise, if the terminating UA sends an in-dialog request, the SIP intermediary at the terminating side inserts a "log me" marker and the SIP intermediary at the originating side echoes the "log me" marker in responses to that request. Originating and terminating intermediaries that are configured for "log me" marking on behalf of the endpoint must also mark dialog-creating requests that contain Target-Dialog [RFC4538], Join [RFC3911], and Replaces [RFC3891] header fields and corresponding responses. The SIP intermediaries at the originating and terminating sides log the "log me" marked SIP requests and responses if it is allowed as per policy defined in the originating and terminating networks. This scenario suggests the following rules when a SIP intermediary is configured to initiate or handle "log me" marking on behalf of a UA.
発信側のSIP仲介者は、発信エンドポイントの代わりに「ログミー」マーカーを挿入するように設定されています。終了したUAがマークされた要求への応答で「ログミー」マーカーをエコーしない場合、終了したUAに最も近いSIP仲介者が、終了したUAに代わってマークするように構成されている場合、「ログミー」マーカーを応答に挿入します。リクエストに。同様に、着信側UAがダイアログ内要求を送信すると、着信側のSIP仲介者が「ログミー」マーカーを挿入し、発信側のSIP仲介者がその要求に応じて「ログミー」マーカーをエコーします。エンドポイントに代わって "ログミー"マーキングを行うように構成された発信および終端の仲介者は、Target-Dialog [RFC4538]、Join [RFC3911]、およびReplaces [RFC3891]ヘッダーフィールドと対応する応答を含むダイアログ作成リクエストもマークする必要があります。発信側と終端側のSIP仲介者は、発信側と終端側のネットワークで定義されたポリシーに従って許可されている場合、「log me」とマークされたSIP要求と応答をログに記録します。このシナリオは、UAに代わって「ログミー」マーキングを開始または処理するようにSIP仲介が構成されている場合に、次のルールを提案します。
For the originating SIP intermediary:
元のSIP仲介者の場合：
o The originating SIP intermediary configured for "log me" marking MUST insert a "log me" marker into the dialog-creating SIP request and subsequent in-dialog SIP requests.
o "ログミー"マーキング用に構成された発信元のSIP仲介者は、ダイアログを作成するSIPリクエストと後続のダイアログ内SIPリクエストに "ログミー"マーカーを挿入する必要があります。
o The originating SIP intermediary itself logs marked requests and responses.
o 発信元のSIP中間体自体が、マークされた要求と応答をログに記録します。
o The originating SIP intermediary detects the "log me" marker received in in-dialog requests and echoes the "log me" marker in the corresponding SIP responses.
o 発信元のSIP仲介者は、ダイアログ内の要求で受信した「ログミー」マーカーを検出し、対応するSIP応答で「ログミー」マーカーをエコーします。
o The originating SIP intermediary logs the SIP responses that it sends in response to "log me" marked in-dialog requests.
o 発信元のSIP仲介者は、「log me」とマークされたダイアログ内リクエストに応じて送信するSIP応答をログに記録します。
o The originating SIP intermediary MAY also apply these rules to any subsequent related SIP dialogs as described in Section 3.7.
o 発信元のSIP仲介者は、セクション3.7で説明されているように、後続の関連するSIPダイアログにもこれらのルールを適用できます（MAY）。
For the terminating SIP intermediary:
終端SIP仲介者の場合：
o The terminating SIP intermediary detects that a dialog is of interest to logging by the existence of a "log me" marker in an incoming dialog-creating SIP request.
o 着信側のSIP仲介者は、ダイアログを作成する着信SIPリクエストに「ログミー」マーカーが存在することにより、ダイアログがロギングに関心があることを検出します。
o The terminating SIP intermediary itself logs marked requests and corresponding responses if allowed as per policy.
o ポリシーに従って許可されている場合、終了するSIP仲介者自体が、マークされた要求と対応する応答をログに記録します。
o The terminating SIP intermediary MUST echo a "log me" marker in responses to a SIP request that included a "log me" marker.
o 終了するSIP仲介者は、「ログミー」マーカーを含むSIPリクエストへの応答で「ログミー」マーカーをエコーする必要があります。
o If the terminating SIP intermediary has detected that a dialog is being "log me" marked, it MUST insert a "log me" marker in any in-dialog SIP requests from the terminating UA.
o 終了するSIP仲介者が、ダイアログに "ログミー"マークが付けられていることを検出した場合は、終了するUAからのダイアログ内SIP要求に "ログミー"マーカーを挿入する必要があります。
o The terminating SIP intermediary itself logs any in-dialog SIP requests that it sends if allowed as per policy.
o 終了するSIP仲介者自体は、ポリシーに従って許可されている場合、送信するダイアログ内のSIPリクエストをログに記録します。
o The terminating SIP intermediary MAY also apply these rules to any subsequent related SIP dialogs as described in Section 3.7.
o 終了するSIP仲介者は、セクション3.7で説明されているように、後続の関連するSIPダイアログにもこれらのルールを適用してもよい（MAY）。
B2BUA "log me" behavior is specified based on its different signaling plane roles described in [RFC7092].
B2BUAの「ログミー」動作は、[RFC7092]で説明されているさまざまなシグナリングプレーンの役割に基づいて指定されます。
A Proxy-B2BUA SHOULD copy "log me" marking in requests and responses from its terminating side to the originating side without needing explicit configuration to do so.
Proxy-B2BUAは、明示的な構成を必要とせずに、要求と応答の「ログミー」マーキングをその終端側から発信側にコピーする必要があります（SHOULD）。
A dialog on one "side" of the B2BUA may or may not be coupled to a related dialog on the other "side" for "log me" purposes. To allow end-to-end troubleshooting of user problems and regression testing, a signaling-only and SDP-modifying signaling-only B2BUA [RFC7092] SHOULD couple related dialogs for "log me" marking purposes and pass on the received "log me" parameter from the originating side to the terminating side and vice versa. For example, a SIP B2BUA handling an end-to-end session between an external caller and an agent in a contact center environment can couple the dialog between itself and an agent with the dialog between itself and the external caller. It can pass on the "log me" marking from the originating side to the terminating side to enable end-to-end logging of specific sessions of interest.
B2BUAの一方の「サイド」のダイアログは、「ログミー」の目的で、もう一方の「サイド」の関連ダイアログに結合されている場合とされていない場合があります。ユーザーの問題と回帰テストのエンドツーエンドのトラブルシューティングを可能にするために、シグナリングのみとSDPを変更するシグナリングのみのB2BUA [RFC7092]は、「ログミー」マーキングの目的で関連ダイアログを結合し、受信した「ログミー」を渡す必要があります。発信側から着信側へのパラメータ、およびその逆。たとえば、コンタクトセンター環境で外部発信者とエージェント間のエンドツーエンドセッションを処理するSIP B2BUAは、自身とエージェント間のダイアログを、自身と外部発信者間のダイアログに結合できます。 「log me」マーキングを発信側から着信側に渡し、特定の対象セッションのエンドツーエンドのロギングを有効にすることができます。
For dialogs that are being "log me" marked, all B2BUAs MUST "log me" mark in-dialog SIP requests that they generate on their own, without needing explicit configuration to do so. This rule applies to both the originating and terminating sides of a B2BUA.
"ログミー"マークが付けられているダイアログの場合、すべてのB2BUAは、明示的な構成を必要とせずに、独自に生成するダイアログ内SIP要求を "ログミー"マークする必要があります。このルールは、B2BUAの発信側と着信側の両方に適用されます。
Typically, "log me" marking will be done by an originating UA and echoed by a terminating UA. SIP intermediaries on the signaling path between these UAs that do not perform the tasks described in Sections 4.3 or 4.4 MUST simply log any request or response that contains a "log me" marker in a stateless manner, if it is allowed per local policy.
通常、「ログミー」マーキングは、元のUAによって行われ、終了UAによってエコーされます。ローカルポリシーで許可されている場合、セクション4.3または4.4で説明されているタスクを実行しないこれらのUA間のシグナリングパス上のSIP仲介者は、「ログミー」マーカーを含む要求または応答をステートレスな方法でログに記録する必要があります。
The originating and terminating SIP intermediaries that "log me" mark on behalf of endpoints and SIP intermediaries that remove "log me" marking at the network boundary must maintain state to enable "log me" marking. Applicable scenarios are as follows:
エンドポイントに代わって「ログミー」マークを付ける発信元と終端のSIP仲介者、およびネットワーク境界で「ログミー」マーキングを削除するSIP仲介者は、「ログミー」マーキングを有効にする状態を維持する必要があります。該当するシナリオは次のとおりです。
o The originating UA does not support "log me" marking. This scenario was described in Section 4.3 and requires support by the originating SIP intermediary. "Log me" marker processing is illustrated in Section 4.5.2.1.
o 元のUAは「ログミー」マーキングをサポートしていません。このシナリオはセクション4.3で説明されており、発信元のSIP仲介者によるサポートが必要です。 「ログミー」マーカーの処理については、4.5.2.1節で説明しています。
o The terminating UA does not support "log me" marking. This scenario was described in Section 4.3 and requires support by the terminating SIP intermediary. "Log me" marker processing is illustrated in Section 4.5.2.2.
o 終端UAは「ログミー」マーキングをサポートしていません。このシナリオはセクション4.3で説明されており、終了するSIP仲介者によるサポートが必要です。 「ログ・ミー」マーカー処理は、セクション4.5.2.2に示されています。
o The originating network ensures that it does not pass marking outside its boundaries in order to not impact any external networks. The originating network removes "log me" marking from SIP requests and responses before forwarding them from its network boundary to external networks, but it adds marking back to any incoming SIP requests and responses belonging to any "log me" marked dialog. This scenario requires support by the SIP intermediary at the originating network boundary. "Log me" marker processing is illustrated in Section 4.5.2.3.
o発信元ネットワークは、外部ネットワークに影響を与えないように、境界の外側にマーキングを渡さないようにします。発信元ネットワークは、SIP要求と応答から「ログミー」マーキングを削除してから、ネットワーク境界から外部ネットワークに転送しますが、「ログミー」マークが付いたダイアログに属するすべての着信SIP要求と応答にマーキングを追加します。このシナリオでは、発信元のネットワーク境界でSIP仲介者によるサポートが必要です。 「ログミー」マーカーの処理については、4.5.2.3項を参照してください。
o The terminating network ensures that it does not allow "log me" marking from external networks to pass through its boundary to its internal entities. The terminating network removes "log me" marking from SIP requests and responses before forwarding them internally, but it adds marking back to any outgoing SIP requests and responses belonging to any "log me" marked dialog. This scenario requires support by the SIP intermediary at the terminating network boundary. "Log me" marker processing is illustrated in Section 4.5.2.4.
o 終端ネットワークは、外部ネットワークからの「ログミー」マーキングが境界を通過して内部エンティティに到達することを許可しないことを保証します。終端ネットワークは、SIP要求と応答から内部で転送する前に「ログミー」マークを削除しますが、「ログミー」マークが付いたダイアログに属するすべての発信SIPリクエストと応答にマーキングを追加します。このシナリオでは、終端ネットワーク境界でSIP仲介者によるサポートが必要です。 「ログ・ミー」マーカー処理は、セクション4.5.2.4に示されています。
o The terminating network does not support "log me" marking and does not echo marking that it receives. The originating network adds marking back to any incoming SIP requests and responses belonging to the "log me" marked dialog. This scenario requires support by the SIP intermediary at the originating network boundary and "log me" marker processing is illustrated in Section 4.5.2.5.
o 終端ネットワークは「ログミー」マーキングをサポートせず、受信したマーキングをエコーしません。発信元ネットワークは、「ログミー」とマークされたダイアログに属するすべての着信SIPリクエストと応答にマーキングを追加します。このシナリオでは、発信元のネットワーク境界でSIP仲介者によるサポートが必要であり、「ログミー」マーカー処理はセクション4.5.2.5に示されています。
SIP intermediary behavior in these scenarios is illustrated using [RFC3665] example call flow "Session Establishment Through Two Proxies".
これらのシナリオでのSIP中間動作は、[RFC3665]のサンプルコールフロー「2つのプロキシを介したセッションの確立」を使用して示されています。
Alice's UA does not support "log me" marking; hence, Proxy 1, which is the SIP intermediary closest to Alice, is configured to act on behalf of Alice's UA to "log me" mark specific dialogs of interest that are created by Alice for troubleshooting purposes.
アリスのUAは「ログミー」マーキングをサポートしていません。そのため、Aliceに最も近いSIP仲介者であるProxy 1は、AliceのUAに代わって動作し、トラブルシューティングの目的でAliceによって作成された特定のダイアログを「ログに記録」するように構成されています。
In Figure 3, Proxy 1 in the originating network maintains state of which dialogs are being logged in order to "log me" mark all SIP requests and responses that it receives from Alice's UA before forwarding them to Proxy 2.
図3では、発信元ネットワークのプロキシ1は、ログに記録されているダイアログの状態を維持し、プロキシ2に転送する前に、AliceのUAから受信するすべてのSIP要求と応答を「ログに記録」します。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (no logme) | | |
|--------------->| | |
| | INVITE F2 | |
| | (logme) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | INVITE F4 |
| (logme) | | (logme) |
|<---------------| 100 F5 |--------------->|
| | (logme) | |
| |<---------------| |
| | | 180 F6 |
| | | (logme) |
| | 180 F7 |<---------------|
| | (logme) | |
| 180 F8 |<---------------| |
| (logme) | | |
|<---------------| | 200 F9 |
| | | (logme) |
| | 200 F10 |<---------------|
| | (logme) | |
| 200 F11 |<---------------| |
| (logme) | | |
|<---------------| | |
| ACK F12 | | |
| (no logme) | | |
|--------------->| | |
| | | |
| | ACK F13 | |
| | (logme) | |
| |--------------->| |
| | | |
| | | ACK F14 |
| | | (logme) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (logme) |
| | BYE F16 |<---------------|
| | (logme) | |
| BYE F17 |<---------------| |
| (logme) | | |
|<---------------| | |
| 200 F18 | | |
| (no logme) | | |
|--------------->| | |
| | 200 F19 | |
| | (logme) | |
| |--------------->| |
| | | |
| | | 200 F20 |
| | | (logme) |
| | |--------------->|
| | | |
Figure 3: The Originating UA Does Not Support "Log Me" Marking
図3：元のUAは "Log Me"マーキングをサポートしていません
F1: Alice's UA does not insert a "log me" marker in the dialog-creating INVITE request F1. Nevertheless, Proxy 1 is configured to initiate logging on behalf of Alice. Proxy 1 logs INVITE request F1 and maintains state that this dialog is being logged.
F1：アリスのUAは、ダイアログを作成するINVITEリクエストF1に「ログミー」マーカーを挿入しません。それにもかかわらず、プロキシ1は、アリスの代わりにロギングを開始するように構成されています。プロキシ1はINVITEリクエストF1を記録し、このダイアログが記録されている状態を維持します。
F2: Proxy 1 inserts a "log me" marker in INVITE request F2 before forwarding it to Proxy 2. Proxy 1 logs this request.
F2：プロキシ1は、INVITEリクエストF2に「ログミー」マーカーを挿入してから、プロキシ2に転送します。プロキシ1は、このリクエストをログに記録します。
F3: Proxy 1 inserts a "log me" marker in 100 response F3 before forwarding it to Alice's UA since this is a response sent on a dialog that is being "log me" marked. Proxy 1 logs this response.
F3：プロキシ1は、100の応答F3に「ログミー」マーカーを挿入してから、アリスのUAに転送します。これは、「ログミー」とマークされているダイアログで送信される応答であるためです。プロキシ1はこの応答を記録します。
F4: "Bob's UA detects the "log me" marker and logs the INVITE request F4 if allowed as per policy.
F4：「ボブのUAは、「ログミー」マーカーを検出し、ポリシーに従って許可されている場合は、INVITEリクエストF4をログに記録します。
F6: Bob's UA echoes the "log me" marker in INVITE request F4 into 180 response F6. It logs this response if allowed as per policy.
F6：ボブのUAは、INVITEリクエストF4の「ログミー」マーカーを180レスポンスF6にエコーします。ポリシーで許可されている場合は、この応答をログに記録します。
F7 and F8: Proxy 1 logs the received "180" response F7 and passes the "log me" marker to Alice's UA in F8.
F7およびF8：プロキシ1は受信した "180"応答F7をログに記録し、 "log me"マーカーをF8のアリスのUAに渡します。
F12: Proxy 1 receives ACK with no "log me" marker. It doesn't consider this an error since it is configured to "log me" mark on behalf of Alice's UA.
F12：プロキシ1は、「ログミー」マーカーのないACKを受信します。 AliceのUAに代わって「私にログを記録」するように構成されているため、これはエラーとは見なされません。
F13: Proxy 1 inserts a "log me" marker in ACK request F13 before forwarding it to Proxy 2. Proxy 1 logs this request.
F13：プロキシ1は、ACK要求F13に「ログミー」マーカーを挿入してから、プロキシ2に転送します。プロキシ1は、この要求を記録します。
F15: Bob's UA inserts a "log me" marker in the in-dialog BYE request and this "log me" marker is carried back to Alice's UA in F16 and F17. Bob's UA logs this request if allowed as per policy.
F15：ボブのUAは、ダイアログのBYEリクエストに「ログミー」マーカーを挿入し、この「ログミー」マーカーは、F16およびF17でアリスのUAに戻されます。ポリシーに従って許可されている場合、BobのUAはこの要求をログに記録します。
F18: Alice's UA does not echo the "log me" marker from BYE request F17 into 200 response F18.
F18：アリスのUAは、BYEリクエストF17から「ログミー」マーカーを200レスポンスF18にエコーしません。
F19: Proxy 1 inserts a "log me" marker in 200 response F19 before forwarding it to Proxy 2. Proxy 1 logs this response.
F19：プロキシ1は、200応答F19に「ログミー」マーカーを挿入してから、プロキシ2に転送します。プロキシ1は、この応答をログに記録します。
In Figure 4, Bob's UA does not support "log me" marking, so Proxy 2 in the terminating network maintains state to ensure "log me" marking of SIP requests and responses from Bob's UA.
図4では、ボブのUAは「ログミー」マーキングをサポートしていないため、終端ネットワークのプロキシ2は状態を維持して、ボブのUAからのSIP要求と応答の「ログミー」マーキングを確実にします。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | | |
| | | |
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (no log me) |
| | 200 F10 |<---------------|
| | (log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (log me) | |
| |--------------->| ACK F14 |
| | | (log me) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (no log me) |
| | BYE F16 |<---------------|
| | (log me) | |
| BYE F17 |<---------------| |
| (log me) | | |
|<---------------| | |
| 200 F18 | | |
| (log me) | | |
|--------------->| | |
| | 200 F19 | |
| | (log me) | |
| |--------------->| 200 F20 |
| | | (log me) |
| | |--------------->|
| | | |
Figure 4: The Terminating UA Does Not Support "Log Me" Marking.
図4：終端UAは「ログミー」マーキングをサポートしていません
F1: Alice's UA inserts a "log me" marker in the dialog-creating INVITE request F1.
F1：アリスのUAは、ダイアログを作成するINVITEリクエストF1に「ログミー」マーカーを挿入します。
F2: INVITE F2 is "log me" marked; therefore, Proxy 2 maintains state that this dialog is to be logged. Proxy 2 logs the request and responses of this dialog if allowed per policy.
F2：INVITE F2には「ログミー」というマークが付けられます。したがって、プロキシ2は、このダイアログがログに記録される状態を維持します。プロキシ2は、ポリシーごとに許可されている場合、このダイアログの要求と応答をログに記録します。
F5: Proxy 2 inserts a "log me" marker in the 100 response it sends to Proxy 1.
F5：プロキシ2は、プロキシ1に送信する100応答に「ログミー」マーカーを挿入します。
F6: Bob's UA does not support "log me" marking; therefore, the 180 response to the INVITE request doesn't have a "log me" marker.
F6：ボブのUAは「ログミー」マーキングをサポートしていません。したがって、INVITEリクエストに対する180応答には「ログミー」マーカーがありません。
F7: Proxy 2 inserts a "log me" marker in the 180 response on behalf of Bob's UA before forwarding it. The same applies to response F10 and the BYE request in F16.
F7：プロキシ2は、ボブのUAに代わって180応答に「ログミー」マーカーを挿入してから転送します。同じことが応答F10とF16のBYE要求に適用されます。
If network A in Figure 5 is performing testing independently of network B, then network A removes "log me" marking from SIP requests and responses forwarded to network B to prevent triggering unintended logging in network B. Proxy 1 removes "log me" marking from requests and responses that it forwards to Proxy 2 and maintains state of which dialogs are being "log me" marked in order to "log me" mark requests and responses that it forwards from Proxy 2 to Alice's UA. For troubleshooting purposes, Proxy 1 MAY also log the requests and responses sent to or received from Proxy 2 even though it removed "log me" marker prior to forwarding the messages to Proxy 2.
図5のネットワークAがネットワークBとは独立してテストを実行している場合、ネットワークAは、ネットワークBに転送されたSIP要求および応答から「ログミー」マーキングを削除して、ネットワークBで意図しないロギングがトリガーされるのを防ぎます。プロキシ1は、「ログミー」マーキングを削除します。プロキシ2に転送する要求と応答。プロキシ2からアリスのUAに転送する要求と応答に「ログミー」マークを付けるために、どのダイアログが「ログミー」にマークされているかを維持します。トラブルシューティングの目的で、プロキシ1は、メッセージをプロキシ2に転送する前に「ログミー」マーカーを削除した場合でも、プロキシ2との間で送受信された要求と応答をログに記録する場合があります。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (logme) | | |
|--------------->| | |
| | INVITE F2 | |
| | (no logme) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (logme) | | INVITE F4 |
| | | (no logme) |
|<---------------| 100 F5 |--------------->|
| | (no logme) | |
| |<---------------| |
| | | 180 F6 |
| | | (no logme) |
| | 180 F7 |<---------------|
| | (no logme) | |
| 180 F8 |<---------------| |
| (logme) | | |
|<---------------| | 200 F9 |
| | | (no logme) |
| | 200 F10 |<---------------|
| | (no logme) | |
| 200 F11 |<---------------| |
| (logme) | | |
|<---------------| | |
| ACK F12 | | |
| (logme) | | |
|--------------->| | |
| | | |
| | ACK F13 | |
| | (no logme) | |
| |--------------->| |
| | | |
| | | ACK F14 |
| | | (no logme) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (no logme) |
| | BYE F16 |<---------------|
| | (no logme) | |
| BYE F17 |<---------------| |
| (logme) | | |
|<---------------| | |
| 200 F18 | | |
| (logme) | | |
|--------------->| | |
| | 200 F19 | |
| | (no logme) | |
| |--------------->| |
| | | |
| | | 200 F20 |
| | | (no logme) |
| | |--------------->|
| | | |
Figure 5: The Originating Network Removes "Log Me" Marking from Outgoing SIP Messages at its Network Edge.
図5：発信元ネットワークは、ネットワークエッジで発信SIPメッセージから「ログミー」マークを削除します。
F1: Alice's UA inserts a "log me" marker in the dialog-creating INVITE request, and Proxy 1 therefore maintains state that this dialog is to be logged.
F1：アリスのUAは、ダイアログを作成するINVITEリクエストに「ログミー」マーカーを挿入します。したがって、プロキシ1は、このダイアログがログに記録される状態を維持します。
F2: Proxy 1 removes "log me" marking from INVITE request before forwarding it to Proxy 2. Proxy 1 logs INVITE request F2.
F2：プロキシ1は、INVITEリクエストから「ログミー」マーキングを削除してから、プロキシ2に転送します。プロキシ1は、INVITEリクエストF2をログに記録します。
F3: Proxy 1 inserts a "log me" marker in the 100 response sent to Alice's UA. Proxy 1 logs this response.
F3：プロキシ1は、アリスのUAに送信された100応答に「ログミー」マーカーを挿入します。プロキシ1はこの応答を記録します。
F8: Proxy 1 inserts a "log me" marker in the 180 response before forwarding it to Alice's UA. Proxy 1 logs this response. The same applies to responses F11 and F17.
F8：プロキシ1は、180応答に「ログミー」マーカーを挿入してから、アリスのUAに転送します。プロキシ1はこの応答を記録します。同じことが応答F11およびF17にも適用されます。
F13: Proxy 1 removes "log me" marking from the ACK request. Proxy 1 logs this request before forwarding it to Proxy 2.
F13：プロキシ1はACKリクエストから「ログミー」マークを削除します。プロキシ1はこのリクエストをログに記録してから、プロキシ2に転送します。
F19: Proxy 1 removes "log me" marking from the 200 response of the BYE request. Proxy 1 logs this response before forwarding it to Proxy 2.
F19：プロキシ1は、BYEリクエストの200応答から「ログミー」マークを削除します。プロキシ1はこの応答をログに記録してから、プロキシ2に転送します。
In Figure 6, Proxy 2 removes "log me" marking from all SIP requests and responses entering network B. However, Proxy 2 supports maintaining the marking state of the dialog and "log me" marks requests and responses that it sends towards Proxy 1. For troubleshooting purposes, Proxy 2 MAY also log the requests and responses received from or sent to Bob even though it removed the "log me" marker prior to forwarding the messages to Bob. This scenario might be used for troubleshooting a signaling path between two enterprise or carrier networks, or across a transit network, with minimal logging (i.e., only at the network boundaries).
図6では、プロキシ2はネットワークBに入るすべてのSIP要求と応答から「ログミー」マーキングを削除します。ただし、プロキシ2はダイアログのマーキング状態の維持をサポートし、「ログミー」はプロキシ1に送信する要求と応答にマークを付けます。トラブルシューティングの目的で、プロキシ2は、メッセージをボブに転送する前に「ログミー」マーカーを削除した場合でも、ボブから受信またはボブに送信された要求と応答をログに記録する場合があります。このシナリオは、最小限のロギング（つまり、ネットワーク境界でのみ）を使用して、2つのエンタープライズネットワークまたはキャリアネットワーク間の、またはトランジットネットワーク全体のシグナリングパスのトラブルシューティングに使用できます。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (no log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (no log me) |
| | 200 F10 |<---------------|
| | (log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (log me) | |
| |--------------->| ACK F14 |
| | | (no log me) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (no log me) |
| | BYE F16 |<---------------|
| | (log me) | |
| BYE F17 |<---------------| |
| (log me) | | |
|<---------------| | |
| 200 F18 | | |
| (log me) | | |
|--------------->| | |
| | 200 F19 | |
| | (log me) | |
| |--------------->| 200 F20 |
| | | (no log me) |
| | |--------------->|
| | | |
Figure 6: The terminating network removes "log me" marking from incoming SIP messages at its network edge.
図6：終端ネットワークは、ネットワークエッジで着信SIPメッセージから「ログミー」マーキングを削除します。
F1: Alice's UA inserts a "log me" marker in the dialog-creating INVITE request F1. Proxy 1 detects the "log me" marker, logs the request, and maintains state that this dialog is to be logged.
F1：アリスのUAは、ダイアログを作成するINVITEリクエストF1に「ログミー」マーカーを挿入します。プロキシ1は「ログミー」マーカーを検出し、リクエストをログに記録し、このダイアログをログに記録する状態を維持します。
F2: Proxy 2 removes the "log me" marker in the INVITE request F2 before forwarding it as F4. The same applies to responses F13 and F19.
F2：プロキシ2は、F4として転送する前に、INVITEリクエストF2の「ログミー」マーカーを削除します。同じことが応答F13およびF19にも適用されます。
F6: Proxy 2 inserts a "log me" marker in the 180 response to the INVITE request and logs the request before forwarding it as F7. The same applies to response F9 and the BYE request in F15.
F6：プロキシ2は、INVITE要求への180応答に「ログミー」マーカーを挿入し、F7として転送する前に要求をログに記録します。同じことが応答F9とF15のBYE要求に適用されます。
In Figure 6, Proxy 2 is not "log me" aware and therefore passes marking in all SIP requests and responses entering network B according to the rules in Sections 16.6 and 16.7 of [RFC3261]. Proxy 2 does not log requests and responses in the dialog. Proxy 1 supports maintaining the marking state of the dialog. When Proxy 1 observes that requests and responses received from Proxy 2 are not marked, it adds the marking.
図6では、プロキシ2は「ログミー」に対応していないため、[RFC3261]のセクション16.6と16.7のルールに従って、ネットワークBに入るすべてのSIP要求と応答でマーキングを渡します。 Proxy 2は、ダイアログに要求と応答を記録しません。 Proxy 1は、ダイアログのマーキング状態の維持をサポートしています。プロキシ1は、プロキシ2から受信した要求と応答がマークされていないことを確認すると、マーキングを追加します。
For troubleshooting purposes, Proxy 1 MAY also log the requests and responses received from or sent to Proxy 2 even though Proxy 2 didn't add "log me" to messages sent to Proxy 1.
トラブルシューティングの目的で、Proxy 2がProxy 1に送信されたメッセージに「log me」を追加していなくても、Proxy 1はProxy 2との間で送受信された要求と応答をログに記録する場合があります。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (no log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | 180 F7 | |
| | (no log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (no log me) |
| | 200 F10 |<---------------|
| | (no log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (log me) | |
| |--------------->| ACK F14 |
| | | (log me) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (no log me) |
| | BYE F16 |<---------------|
| | (no log me) | |
| BYE F17 |<---------------| |
| (log me) | | |
|<---------------| | |
| 200 F18 | | |
| (log me) | | |
|--------------->| | |
| | 200 F19 | |
| | (log me) | |
| |--------------->| 200 F20 |
| | | (log me) |
| | |--------------->|
| | | |
Figure 7: The Terminating Network Removes "Log Me" Marking from Incoming SIP Messages at its Network Edge.
図7：終端ネットワークは、そのネットワークエッジで受信SIPメッセージから「ログミー」マークを削除します。
F1: Alice's UA inserts a "log me" marker in the dialog-creating INVITE request F1. Proxy 1 detects the "log me" marker, logs the request, and maintains state that this dialog is to be logged.
F1：アリスのUAは、ダイアログを作成するINVITEリクエストF1に「ログミー」マーカーを挿入します。プロキシ1は「ログミー」マーカーを検出し、リクエストをログに記録し、このダイアログをログに記録する状態を維持します。
F2: Proxy 2 passes the "log me" marker in the INVITE request F2 before forwarding it as F4. The same applies to request F13 and response F19.
F2：プロキシ2は、F4として転送する前に、INVITEリクエストF2の「ログミー」マーカーを渡します。リクエストF13とレスポンスF19についても同様です。
F6: Bob's UA does not support "log me" marking and does not echo the "log me" marker in response F6. The same applies to response F9 and the BYE request F15.
F6：ボブのUAは「ログミー」マーキングをサポートせず、F6の応答で「ログミー」マーカーをエコーしません。同じことが応答F9とBYE要求F15にも当てはまります。
F7: Proxy 1 inserts a "log me" marker in the 180 response of the INVITE request before forwarding it as F8. The same applies to response F10 and the BYE request F16.
F7：プロキシ1は、F8として転送する前に、INVITE要求の180応答に「ログミー」マーカーを挿入します。同じことが応答F10とBYE要求F16にも当てはまります。
The following error cases are possible for "log me" marking:
「ログミー」マーキングでは、次のエラーが発生する可能性があります。
1. A "log me" marker is unexpectedly missing from a dialog that is being logged.
1. ログに記録されているダイアログから「ログミー」マーカーが予期せず失われる。
2. A "log me" marker unexpectedly appears in a dialog that is not being logged.
2. ログに記録されていないダイアログに、「ログ記録」マーカーが予期せず表示されます。
3. A "log me" marker unexpectedly disappears and then reappears in a dialog being logged. This is treated in the same way as case 1.
3. 「私をログに記録」マーカーが予期せずに消え、ログに記録されているダイアログに再び表示されます。これは、ケース1と同じ方法で処理されます。
4. A "log me" marker is unexpectedly missing from a retransmission in a dialog being logged. This is treated in the same way as case 1.
4. ログに記録されているダイアログの再送信から「ログミー」マーカーが予期せず失われる。これは、ケース1と同じ方法で処理されます。
These cases apply to any request or response sent by any entity and in any direction in a dialog being "log me" marked. Detection of these error cases is described in this section.
これらのケースは、エンティティによって送信されたすべての要求または応答に適用されます。このセクションでは、これらのエラーケースの検出について説明します。
Since "log me" marking is per-dialog, if a dialog is being marked and marking is missing from a request or response then this is an error.
「私をログに記録する」マーキングはダイアログごとなので、ダイアログがマークされていて、リクエストまたは応答にマーキングがない場合、これはエラーです。
However, detecting such errors is not as simple as checking for missing markers because of cases such as non-supporting terminals where it is normal that marking is not done.
ただし、サポートされていない端末などでマーキングが行われないのが正常な場合があるため、このようなエラーの検出はマーカーの欠落のチェックほど簡単ではありません。
Detecting errors must be evaluated separately for each neighbor. It is an error if a particular neighbor has previously sent "log me" in the dialog and then stops, independently of what has been happening with other neighbors.
エラーの検出は、ネイバーごとに個別に評価する必要があります。特定のネイバーが以前にダイアログに「ログミー」を送信してから停止した場合、他のネイバーで何が起こっていたかに関係なく、エラーになります。
UAs and intermediaries that are stateless with respect to "log me" marking are not able detect such errors. User agents and intermediaries that are stateful with respect to "log me" marking are able to detect that a marker is missing from a dialog that has previously been "log me" marked. Error cases are illustrated in this section, and non-error cases in Section 5.2.1.
「ログミー」マーキングに関してステートレスなUAおよび仲介者は、このようなエラーを検出できません。 「ログミー」マークに関してステートフルなユーザーエージェントと仲介者は、以前に「ログミー」マークが付けられたダイアログからマーカーが欠落していることを検出できます。エラーケースはこのセクションで説明されており、エラー以外のケースはセクション5.2.1で説明されています。
The following figures illustrate missing "log me" marker errors.
次の図は、「ログミー」マーカーの欠落エラーを示しています。
Figure 8 shows an error detected at Proxy 1, where an expected "log me" marker is missing.
図8は、Proxy 1で検出されたエラーを示しています。この場合、予期される「ログミー」マーカーがありません。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | INVITE F2 | |
|--------------->| (log me) | INVITE F3 |
| |--------------->| (log me) |
| | |--------------->|
| | | |
| | | 200 F4 |
| | 200 F5 | (log me) |
| 200 F6 | (log me) |<---------------|
| (log me) |<---------------| |
|<---------------| | |
| | | |
| ACK F7 | | |
| (no log me) | | |
|--------------->| | |
| | ACK F8 | |
| | (no log me) | |
| |--------------->| |
| | | ACK F9 |
| | | (no log me) |
| | |--------------->|
Figure 8: Error Case: Missing "Log Me" Marker
図8：エラーケース：「Log Me」マーカーがありません
F1: Proxy 1 detects the "log me" marker and maintains state that this dialog is to be logged.
F1：プロキシ1は「ログミー」マーカーを検出し、このダイアログをログに記録する状態を維持します。
F7: Proxy 1 detects that the expected "log me" marker is missing, considers it to be an error, and stops "log me" marking in subsequent requests and responses in this dialog.
F7：プロキシー1は、予期される「ログミー」マーカーが欠落していることを検出し、それをエラーと見なして、このダイアログの後続の要求および応答で「ログミー」マーキングを停止します。
Figure 9 shows an error detected at both Proxy 2 and Bob's UA.
図9は、Proxy 2とBobのUAの両方で検出されたエラーを示しています。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (log me) |
| | |<---------------|
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (log me) |
| | 200 F10 |<---------------|
| | (log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (no log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (no log me) | |
| |--------------->| ACK F14 |
| | | (no log me) |
| | |--------------->|
Figure 9: Error Case: Missing "Log Me" Marker
図9：エラーケース：「ログミー」マーカーがありません
F2: Proxy 2 detects the "log me" marker and maintains state that this dialog is to be logged.
F2：プロキシ2は「ログミー」マーカーを検出し、このダイアログをログに記録する状態を維持します。
F4: Bob's UA detects the "log me" marker and maintains state that this dialog is to be logged.
F4：ボブのUAは「ログミー」マーカーを検出し、このダイアログをログに記録する状態を維持します。
F12: Proxy 1 detects that the expected "log me" marker is missing, considers it to be an error, and stops "log me" marking in subsequent requests and responses in this dialog. Hence, it does not insert a "log me" marker in F13.
F12：プロキシー1は、予期される「ログ・ミー」マーカーが欠落していることを検出し、それをエラーと見なして、このダイアログの後続の要求および応答で「ログ・ミー」マーキングを停止します。したがって、F13に「ログミー」マーカーは挿入されません。
F13: Proxy 2 detects that the expected "log me" marker is missing, considers it to be an error, and stops "log me" marking in subsequent requests and responses in this dialog.
F13：プロキシー2は、予期される「ログミー」マーカーが欠落していることを検出し、それをエラーと見なして、このダイアログの後続の要求および応答で「ログミー」マーキングを停止します。
F14: Proxy 2 does not insert a "log me" marker because it has stopped "log me" marking due to an error observed in F13. Bob's UA detects that the expected "log me" marker is missing, considers it to be an error, and stops "log me" marking in subsequent requests and responses in this dialog.
F14：Proxy 2は、F13で観察されたエラーのために「ログミー」マーキングを停止したため、「ログミー」マーカーを挿入しません。 BobのUAは、予期される「ログミー」マーカーが欠落していることを検出し、それをエラーと見なして、このダイアログの後続の要求および応答で「ログミー」マーキングを停止します。
SIP endpoints, intermediaries acting on behalf of endpoints, and B2BUAs that can perform "log me" marking are stateful. Such entities will expect a "log me" marker only for dialogs where the initial dialog-creating request was "log me" marked, either by themselves or by an upstream entity. "Log me" marking that subsequently begins mid-dialog is an error.
SIPエンドポイント、エンドポイントに代わって機能する仲介者、および「ログミー」マーキングを実行できるB2BUAはステートフルです。そのようなエンティティは、最初のダイアログ作成リクエストがそれ自体または上流のエンティティによって「ログミー」とマークされたダイアログに対してのみ「ログミー」マーカーを期待します。ダイアログの途中で始まる「ログミー」マークはエラーです。
Figure 10 illustrates a "log me" marking error observed in the middle of a dialog. Alice's UA supports "log me" marking but the call is not initially marked for logging, i.e., INVITE F1 is not "log me" marked. But Alice's UA starts to "log me" mark at the ACK request F7. Proxy 1 supports "log me" marking at the originating network boundary and therefore detects the error, does not log signaling, and removes the "log me" marker before forwarding the ACK request F8.
図10は、ダイアログの途中で観察された「ログミー」マーキングエラーを示しています。アリスのUAは「ログミー」マーキングをサポートしていますが、コールは最初にロギング用にマークされていません。つまり、INVITE F1は「ログミー」マークされていません。しかし、アリスのUAはACKリクエストF7で「ログミー」マークを開始します。プロキシ1は、発信元のネットワーク境界で「ログミー」マーキングをサポートしているため、エラーを検出し、シグナリングをログに記録せず、ACKリクエストF8を転送する前に「ログミー」マーカーを削除します。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (no log me) | INVITE F2 | |
|--------------->| (no log me) | INVITE F3 |
| |--------------->| (no log me) |
| | |--------------->|
| | | |
| | | 200 F4 |
| | 200 F5 | (no log me) |
| 200 F6 | (no log me) |<---------------|
| (no log me) |<---------------| |
|<---------------| | |
| | | |
| ACK F7 | | |
| (log me) | | |
|--------------->| | |
| | ACK F8 | |
| | (no log me) | |
| |--------------->| |
| | | ACK F9 |
| | | (log me) |
| | |--------------->|
Figure 10: Error Case: "Log Me" Marker Begins Mid-dialog
図10：エラーケース：「ログミー」マーカーがダイアログの途中で始まる
The following figure illustrates a non-error case.
次の図は、エラー以外のケースを示しています。
Figure 11 shows Proxy 2 receiving a response with no "log me" marker that is not an error case. Proxy 2 is configured by network B to perform "log me" marking on behalf of Bob's UA, which does not support "log me" marking. Proxy 2 does not therefore expect responses from Bob to include a "log me" marker.
図11は、エラーケースではない「ログミー」マーカーのない応答を受信したProxy 2を示しています。プロキシ2は、BobのUAに代わって「ログミー」マーキングを実行するようにネットワークBによって構成されています。これは、「ログミー」マーキングをサポートしていません。したがって、プロキシ2は、ボブからの応答に「ログミー」マーカーが含まれることを期待していません。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| 180 F8 | | |
| (log me) | | |
|<---------------| | |
Figure 11: Non-error Case: Missing "Log Me" Marker
図11：エラー以外のケース：「ログミー」マーカーがない
F2: Proxy 2 detects the "log me" marker and maintains state that this dialog is to be logged. Proxy 2 inserts "log me" markers on behalf of Bob's user agent, such as in F7.
F2：プロキシ2は「ログミー」マーカーを検出し、このダイアログをログに記録する状態を維持します。プロキシ2は、F7などのボブのユーザーエージェントに代わって「ログミー」マーカーを挿入します。
F6: Proxy 2 detects that the "log me" marker is missing from the response but considers "log me" marking to be ongoing as a marker was not expected.
F6：プロキシー2は、「ログ・ミー」マーカーが応答から欠落していることを検出しますが、マーカーが予期されていなかったため、「ログ・ミー」マーキングが進行中であると見なします。
F7: Proxy 2 continues to "log me" mark requests and responses on behalf of Bob's UA.
F7：プロキシ2は、ボブのUAに代わって要求と応答に「ログミー」マークを付け続けます。
A SIP intermediary that can perform "log me" marking on behalf of an endpoint MAY optionally mark a request or response towards a non-supporting endpoint, such as the 100 response F3 in Figure 3. In this case, the endpoint will receive a "log me" marker mid-dialog, and this is not considered an error.
エンドポイントに代わって「ログミー」マーキングを実行できるSIP仲介者は、図3の100応答F3など、サポートされていないエンドポイントへの要求または応答にオプションでマークを付けることができます（MAY）。この場合、エンドポイントは「ダイアログの途中に「私をログに記録」マーカーを付けます。これはエラーとは見なされません。
Another use case is a network in which some (but not all) endpoints support "log me" marking and that wants to avoid treating endpoints differently by always managing "log me" marking at a SIP intermediary. In this case, the endpoint that supports "log me" is not configured to mark a dialog; instead, the SIP intermediary is configured to perform "log me" marking on behalf of that endpoint. This case still requires authorization as described in Section 7.1. This SIP intermediary MAY optionally mark a request or response towards the endpoint, such as the 100 response F3 in Figure 3. The endpoint will receive a "log me" marker mid-dialog, which is not considered an error.
もう1つの使用例は、一部（すべてではない）のエンドポイントが「ログミー」マーキングをサポートし、SIP仲介で常に「ログミー」マーキングを管理することでエンドポイントの扱いを変えたくないネットワークです。この場合、「log me」をサポートするエンドポイントは、ダイアログをマークするように構成されていません。代わりに、SIP仲介者は、そのエンドポイントに代わって「ログミー」マーキングを実行するように構成されています。この場合でも、セクション7.1で説明するように承認が必要です。このSIP仲介者は、オプションで、図3の100応答F3などのエンドポイントへの要求または応答にマークを付けることができます（MAY）。エンドポイントは、エラーとは見なされないダイアログの「ログミー」マーカーを受け取ります。
When troubleshooting call flows that involve the SIP Join header field specified in [RFC3911], the ideal scenario is to have "log me" marking enabled on all UAs and intermediaries participating in the end-to-end session. If the ideal scenario is not feasible, the following rules apply:
[RFC3911]で指定されたSIP結合ヘッダーフィールドに関連するコールフローのトラブルシューティングを行う場合、理想的なシナリオは、エンドツーエンドセッションに参加するすべてのUAおよび仲介者で「ログミー」マーキングを有効にすることです。理想的なシナリオが実現可能でない場合は、次のルールが適用されます。
o If an endpoint or an intermediary that is "log me" aware and is already "log me" marking a dialog receives a SIP INVITE with a Join header field and without a "log me" marker, it MUST NOT "log me" mark responses and requests exchanged within the new dialog established as a result of processing the SIP INVITE.
o 「ログミー」を認識し、ダイアログをすでに「ログミー」しているエンドポイントまたは中間者が、「ログミー」マーカーのない、JoinヘッダーフィールドのあるSIP招待を受信した場合、「ログミー」の応答をマークしてはなりません。また、SIP INVITEの処理の結果として確立された新しいダイアログ内で交換された要求。
o If an endpoint or an intermediary that is "log me" aware and is not "log me" marking a dialog receives a SIP INVITE with a Join header field and with a "log me" marker, it MUST "log me" mark responses and requests exchanged within the new dialog established as a result of processing the SIP INVITE as per Section 4 of this document.
o 「ログして」認識し、「ログして」いないエンドポイントまたは仲介者がダイアログにマークを付けていない場合、Joinヘッダーフィールドと「ログして」マーカーが付いたSIP INVITEを受信すると、応答を「ログして」マークしなければなりません。このドキュメントのセクション4に従ってSIP INVITEを処理した結果として確立された新しいダイアログ内で交換された要求。
The two error types that SIP entities must handle are defined in Section 5.1: a missing marker error and an error of "log me" marking that begins mid-dialog. Section 5.2 gives exceptions that have marking that begins mid-dialog or a missing marker but are not errors.
SIPエンティティが処理する必要のある2つのエラータイプは、セクション5.1で定義されています。マーカーが見つからないエラーと、ダイアログの途中で始まる「ログミー」マークのエラーです。セクション5.2では、ダイアログの途中で始まるマーキングまたはマーカーの欠落はあるがエラーではない例外を示しています。
If a missing marker error is detected by a UA, SIP intermediary, or B2BUA, it SHOULD consider this to be an error condition in the "log me" functionality. It MUST NOT mark subsequent requests and responses, and it MUST stop logging messages in the same dialog. Any previously logged messages SHOULD be retained, for the time period defined in Section 8.5, and not deleted.
マーカーの欠落エラーがUA、SIP仲介、またはB2BUAによって検出された場合、これは「ログミー」機能のエラー状態であると考えるべきです。それは後続の要求と応答をマークしてはならず（MUST NOT）、同じダイアログでのメッセージのロギングを停止しなければなりません（MUST）。以前にログに記録されたメッセージは、セクション8.5で定義された期間保持され、削除されるべきではありません（SHOULD）。
If a "log me" marking that begins mid-dialog error is detected by a UA, SIP intermediary, or B2BUA, it SHOULD consider this to be an error condition in the "log me" functionality. It MUST NOT forward the "log me" marker, and it MUST NOT log the message. It MUST NOT mark subsequent requests and responses, and it MUST NOT log subsequent messages in the same dialog.
中間ダイアログエラーを開始する「ログミー」マークがUA、SIP仲介、またはB2BUAによって検出された場合、これを「ログミー」機能のエラー状態と見なす必要があります。 「log me」マーカーを転送してはならず、またメッセージをログに記録してはなりません。後続のリクエストとレスポンスをマークしてはならず、同じダイアログに後続のメッセージを記録してはなりません。
"Log me" marking errors can be detected and handled only by supporting UAs or B2BUAs. A SIP proxy as defined in [RFC3261] cannot detect or handle marking errors and will simply forward any "log me" marker it receives.
"Log me"マーキングエラーは、UAまたはB2BUAをサポートすることによってのみ検出および処理できます。 [RFC3261]で定義されているSIPプロキシは、マーキングエラーを検出または処理できず、受信した「ログミー」マーカーを転送するだけです。
ABNF is described in [RFC5234]. This document introduces a new "logme" parameter for the Session-ID header field defined in Section 5 of [RFC7989].
ABNFは[RFC5234]で説明されています。このドキュメントでは、[RFC7989]のセクション5で定義されているセッションIDヘッダーフィールドの新しい「logme」パラメータを紹介します。
sess-id-param =/ logme-param
sess-id-param = / logme-param
logme-param = "logme"
Figure 12: Augmented BNF for the "logme" Parameter
図12：「logme」パラメーターの拡張BNF
"Log me" marking MUST be disabled by default both at the endpoints and intermediaries and MUST be enabled only by authorized users. For example, an end user or network administrator must give permission for a terminal that supports "log me" marking in order to initiate marking. Similarly, a network administrator must enable a configuration at the SIP intermediary to perform "log me" marking on behalf of a terminal that does not support "log me" marking. The permission MUST be limited to only specific calls of interest that are originated in a given time duration.
「ログミー」のマーキングは、エンドポイントと仲介者の両方でデフォルトで無効にする必要があり、許可されたユーザーのみが有効にする必要があります。たとえば、エンドユーザーまたはネットワーク管理者は、マーキングを開始するために、「ログミー」マーキングをサポートする端末に許可を与える必要があります。同様に、ネットワーク管理者は、「ログミー」マーキングをサポートしていない端末に代わって「ログミー」マーキングを実行するために、SIP中間で構成を有効にする必要があります。許可は、特定の期間内に発信された特定の関心のある呼び出しのみに制限する必要があります。
Activating a debug mode affects the operation of a terminal; therefore, the debugging configuration MUST be supplied by an authorized party to an authorized terminal through a secure communication channel.
デバッグモードをアクティブにすると、端末の操作に影響します。したがって、デバッグ構成は、安全な通信チャネルを介して、許可された端末から許可された端末に提供する必要があります。
The "log me" marker is not sensitive information, though it will sometimes be inserted because a particular device is experiencing problems.
「ログミー」マーカーは機密情報ではありませんが、特定のデバイスで問題が発生しているために挿入されることがあります。
The presence of a "log me" marker will cause some SIP entities to log signaling messages. Therefore, this marker MUST be removed at the earliest opportunity if it has been incorrectly inserted, such as appearing mid-dialog in a dialog that was not being logged or outside the configured start and stop of logging.
「ログミー」マーカーがあると、一部のSIPエンティティがシグナリングメッセージをログに記録します。したがって、このマーカーは、ログに記録されていないダイアログのダイアログの途中や、構成されたログの開始と停止の外に表示されるなど、誤って挿入された場合は、できるだけ早く削除する必要があります。
If SIP requests and responses are exchanged with an external network with which there is no agreement to pass "log me" marking, then the "log me" marking is removed as mandated in Section 3.4.2. This behavior applies to incoming and outgoing requests and responses.
「ログミー」マーキングを渡すことに同意していない外部ネットワークとSIP要求および応答が交換される場合、「ログミー」マーキングはセクション3.4.2で義務付けられているように削除されます。この動作は、着信および発信の要求と応答に適用されます。
Maliciously configuring a large number of terminals to simultaneously mark dialogs with a "log me" marker will cause high processor load on SIP entities that are logging signaling. Since "log me" marking is for the small number of dialogs subject to troubleshooting or regression testing, the number of dialogs that can be simultaneously logged can be statically limited without adversely affecting the usefulness of "log me" marking. Also, the SIP intermediary closest to the terminal and SIP intermediary at network edge (e.g., Session Border Controllers) can be configured to screen-out "log me" markers when troubleshooting or regression testing is not in progress.
「ログミー」マーカーでダイアログを同時にマークするように多数の端末を悪意を持って設定すると、シグナリングをログに記録しているSIPエンティティでプロセッサの負荷が高くなります。 「ログミー」マーキングはトラブルシューティングまたは回帰テストの対象となる少数のダイアログ用であるため、「ログミー」マーキングの有用性に悪影響を与えることなく、同時にログ記録できるダイアログの数を静的に制限できます。また、トラブルシューティングまたは回帰テストが進行中でない場合、「ログミー」マーカーをスクリーンアウトするように、端末に最も近いSIP仲介者およびネットワークエッジ（たとえば、セッションボーダーコントローラー）のSIP仲介者を構成できます。
A SIP entity that has logged information MUST protect the logs. Storage of the log files are subject to the security considerations specified in [RFC6872].
情報を記録したSIPエンティティは、ログを保護する必要があります。ログファイルの保存は、[RFC6872]で指定されているセキュリティの考慮事項の対象となります。
Logging includes all SIP header fields. The SIP privacy mechanisms defined in [RFC3323] can be used to ensure that logs do not divulge personal identity information in the core SIP header fields specified in [RFC3261].
ロギングには、すべてのSIPヘッダーフィールドが含まれます。 [RFC3323]で定義されているSIPプライバシーメカニズムを使用して、ログが[RFC3261]で指定されているコアSIPヘッダーフィールドの個人識別情報を漏らさないようにすることができます。
Privacy mechanisms might also need to be applied to header fields defined by SIP extensions and for managing the confidentiality of the Request-URI and SIP header fields and bodies.
プライバシーメカニズムは、SIP拡張機能によって定義されたヘッダーフィールドに適用され、Request-URIおよびSIPヘッダーフィールドと本文の機密性を管理する必要がある場合もあります。
"Log me" marking is defined for the SIP protocol, and SIP has header fields such as From, Contact, and P-Asserted-Identity that can carry personal identifiers. Different protocol interactions can be correlated using the Session-ID and Call-ID header fields, but such correlation is limited to a single end-to-end session.
「ログミー」マーキングはSIPプロトコルに定義されており、SIPには、個人識別子を運ぶことができるFrom、Contact、P-Asserted-Identityなどのヘッダーフィールドがあります。 Session-IDおよびCall-IDヘッダーフィールドを使用して、さまざまなプロトコルの相互作用を相関させることができますが、そのような相関は単一のエンドツーエンドセッションに限定されます。
In order to protect user privacy during logging, privacy settings can be enabled or requested by the terminal used by the end user. [RFC3323] suggests two mechanisms:
ロギング中にユーザーのプライバシーを保護するために、プライバシー設定は、エンドユーザーが使用する端末で有効化または要求できます。 [RFC3323]は2つのメカニズムを提案しています：
o By using the value "anonymous" in the From header field
o Fromヘッダーフィールドで値 "anonymous"を使用する
o By requesting header-level and session-level privacy from SIP intermediaries using the Privacy header
o プライバシーヘッダーを使用してSIP仲介者にヘッダーレベルとセッションレベルのプライバシーを要求する
Endpoints that support Globally Routable User Agent URIs (GRUUs) can use a temporary GRUU (see Section 3.1.2 of [RFC5627]) assigned by the Registrar in order to protect user privacy as discussed in Section 10.3 of [RFC5627].
グローバルにルーティング可能なユーザーエージェントURI（GRUU）をサポートするエンドポイントは、[RFC5627]のセクション10.3で説明されているように、ユーザーのプライバシーを保護するために、レジストラーによって割り当てられた一時的なGRUU（[RFC5627]のセクション3.1.2を参照）を使用できます。
Intermediaries that perform "log me" marking on behalf of the endpoints (see Section 4.3) may also be configured to apply privacy (as defined in Section 3.3 of [RFC3323]) on messages that belong to a dialog that is "log me" marked.
エンドポイント（セクション4.3を参照）に代わって「ログミー」マーキングを実行する仲介者は、「ログミー」マークが付いたダイアログに属するメッセージにプライバシー（[RFC3323]のセクション3.3で定義）を適用するように構成することもできます。 。
Complete anonymization (e.g., the Request-URI and the "username" field in the "o=" parameter of an SDP body) may not be possible in all circumstances; therefore, administrators of the originating and terminating networks should consider how privacy will be ensured when providing consent for "log me" marking.
完全な匿名化（たとえば、Request-URIおよびSDP本文の "o ="パラメータの "username"フィールド）は、すべての状況で可能であるとは限りません。したがって、発信元ネットワークと着信側ネットワークの管理者は、「ログミー」のマーキングに同意を与えるときにプライバシーをどのように確保するかを検討する必要があります。
"Log me" marking is typically used for troubleshooting and regression testing; in some cases, a service-provider-owned device with a dummy account can be used instead of a customer device. In such cases, no personal identifiers are included in the logged signaling messages.
「Log me」マークは通常、トラブルシューティングと回帰テストに使用されます。場合によっては、顧客のデバイスの代わりに、ダミーアカウントを持つサービスプロバイダー所有のデバイスを使用できます。そのような場合、ログに記録されたシグナリングメッセージに個人識別子は含まれません。
SIP endpoints and intermediaries that honor the "log me" request store all the SIP messages that are exchanged within a given dialog. SIP messages can contain the personal identifiers listed in Section 8.1 and additionally a user identity, calling party number, IP address, hostname, and other user-related or device-related items. The SIP message bodies describe the kind of session being set up by the identified end user and device.
「log me」リクエストを受け入れるSIPエンドポイントと仲介者は、特定のダイアログ内で交換されるすべてのSIPメッセージを保存します。 SIPメッセージには、セクション8.1に記載されている個人IDに加えて、ユーザーID、発呼者番号、IPアドレス、ホスト名、およびその他のユーザー関連またはデバイス関連のアイテムを含めることができます。 SIPメッセージ本文は、識別されたエンドユーザーとデバイスによってセットアップされているセッションの種類を示します。
"Log me" marking does not introduce any additional user or device data to SIP but might indicate that a specific user is experiencing a problem.
「ログミー」マークは、SIPに追加のユーザーまたはデバイスデータを導入しませんが、特定のユーザーに問題が発生していることを示す場合があります。
If the SIP SDP parameters [SDP-PARAMETERS] contain sensitive security information (e.g., encryption keys) such as "crypto" [RFC4568], 3GPP-Integrity-Key, or 3GPP-SRTP-Config [RFC6064] attributes, then the attribute value MUST be masked with a dummy value prior to storing the message in a log file. For example, the attribute value can be replaced with a string of special characters like "X", "*", and "#" as shown in the example below.
SIP SDPパラメータ[SDP-PARAMETERS]に「crypto」[RFC4568]、3GPP-Integrity-Key、または3GPP-SRTP-Config [RFC6064]属性などの機密セキュリティ情報（暗号化キーなど）が含まれている場合、属性値メッセージをログファイルに保存する前に、ダミー値でマスクする必要があります。たとえば、属性値は、以下の例に示すように、「X」、「*」、「＃」などの特殊文字の文字列で置き換えることができます。
a=crypto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXX
a = crypto：XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXX
SIP messages that are logged due to "log me" requests are stored only by the SIP initiators, intermediaries, and recipients. Enablers as defined in Section 3.1 of [RFC6973], such as firewalls and DNS servers, do not log messages due to the "log me" marking.
「log me」要求によりログに記録されたSIPメッセージは、SIPの開始者、仲介者、および受信者のみが保存します。ファイアウォールやDNSサーバーなど、[RFC6973]のセクション3.1で定義されているイネーブラーは、「ログミー」マークが付いているため、メッセージをログに記録しません。
"Log me" functionality is typically used to troubleshoot a given problem and, hence, can be used as a method to identify users and devices that are experiencing issues. The best way to prevent fingerprinting of users is to enable or request SIP privacy for the logged dialog.
「ログミー」機能は通常、特定の問題のトラブルシューティングに使用されるため、問題が発生しているユーザーとデバイスを特定する方法として使用できます。ユーザーのフィンガープリントを防ぐ最善の方法は、ログに記録されたダイアログのSIPプライバシーを有効にするか要求することです。
The lifetime of "log me" marking is equivalent to the lifetime of the dialog that initiated the "log me" request. When "log me" is extended to related dialogs, the lifetime is extended until there is no remaining related dialog for the end-to-end session.
「ログミー」マーキングの存続期間は、「ログミー」要求を開始したダイアログの存続期間と同じです。 「ログミー」が関連ダイアログに拡張されると、エンドツーエンドセッションの関連ダイアログがなくなるまで、存続時間が延長されます。
"Log me" automatically expires at the end of the dialog, and there is no explicit mechanism to turn off logging within a dialog.
「Log me」はダイアログの最後で自動的に期限切れになり、ダイアログ内のロギングをオフにする明示的なメカニズムはありません。
The scope of "log me" marking is limited, i.e., a user or the network administrator has to enable it on a per-session basis or for a specific time period. This minimizes the risk of exposing user data for an indefinite time.
「ログミー」マーキングの範囲は制限されています。つまり、ユーザーまたはネットワーク管理者は、セッションごとに、または特定の期間にそれを有効にする必要があります。これにより、ユーザーデータが無期限に公開されるリスクが最小限に抑えられます。
The retention time period for logged messages SHOULD be the minimum needed for each particular troubleshooting or testing case. The retention period is configured based on the data-retention policies of service providers and enterprises.
ログに記録されたメッセージの保持期間は、特定のトラブルシューティングまたはテストケースごとに最低限必要です。保存期間は、サービスプロバイダーおよび企業のデータ保存ポリシーに基づいて設定されます。
Consent to turn on "log me" marking for a given session MUST be provided by the end user or by the network administrator. It is handled outside of the protocol through user interface or application programming interfaces at the endpoint, call control elements, and network management systems.
特定のセッションの「ログミー」マークをオンにすることへの同意は、エンドユーザーまたはネットワーク管理者が提供する必要があります。これは、エンドポイントのユーザーインターフェイスまたはアプリケーションプログラミングインターフェイス、呼制御要素、およびネットワーク管理システムを通じて、プロトコルの外部で処理されます。
Originating and terminating endpoints that are "log me" aware and have a user interface MUST indicate (using text, icon, etc.) to the user that a session is being logged.
「ログ・ミー」を認識し、ユーザー・インターフェースを持つ発信および終了エンドポイントは、セッションがログに記録されていることをユーザーに（テキスト、アイコンなどを使用して）示す必要があります。
SIP entities across the communication path MAY be configured to pass through the "log me" marking but not honor the request, i.e., not log the data based on local policies.
通信パス全体のSIPエンティティは、「ログミー」マーキングを通過するように構成されても、要求を受け入れないように設定できます（つまり、ローカルポリシーに基づいてデータをログに記録しません）。
The recommended defaults for "log me" marking are:
「ログミー」マーキングの推奨デフォルトは次のとおりです。
o Turn on SIP privacy as described in Section 8 or use a device that is service provider owned with a dummy user identity for test calls.
o セクション8の説明に従ってSIPプライバシーをオンにするか、テストコール用にダミーのユーザーIDを所有するサービスプロバイダーであるデバイスを使用します。
o Use the local UUID portion of the Session-ID header field value at the originating device as the test case identifier as described in Section 3.3.
o セクション3.3で説明されているように、発信元デバイスのセッションIDヘッダーフィールド値のローカルUUID部分をテストケース識別子として使用します。
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 | Parameter | Predefined Values | Reference |
| Field | Name | | |
+-------------+---------------+-------------------------+-----------+
| Session-ID | logme | No (no values are | [RFC8497] |
| | | allowed) | |
+-------------+---------------+-------------------------+-----------+
Table 1
表1
[MEDIA-TYPES] IANA, "Media Types", <https://www.iana.org/assignments/media-types/>.
[MEDIA-TYPES] IANA、「メディアタイプ」、<https://www.iana.org/assignments/media-types/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://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, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <https://www.rfc-editor.org/info/rfc3323>.
[RFC3323] Peterson、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、DOI 10.17487 / RFC3323、2002年11月、<https://www.rfc-editor.org/info/rfc3323> 。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, DOI 10.17487/RFC3891, September 2004, <https://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月、<https：// www。 rfc-editor.org/info/rfc3891>。
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, DOI 10.17487/RFC3911, October 2004, <https://www.rfc-editor.org/info/rfc3911>.
[RFC3911] Mahy、R。およびD. Petrie、「The Session Initiation Protocol（SIP） "Join" Header」、RFC 3911、DOI 10.17487 / RFC3911、2004年10月、<https://www.rfc-editor.org/ info / rfc3911>。
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, DOI 10.17487/RFC4538, June 2006, <https://www.rfc-editor.org/info/rfc4538>.
[RFC4538] Rosenberg、J。、「Session Initiation Protocol（SIP）のダイアログ識別によるリクエストの承認」、RFC 4538、DOI 10.17487 / RFC4538、2006年6月、<https://www.rfc-editor.org/info/ rfc4538>。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, <https://www.rfc-editor.org/info/rfc4568>.
[RFC4568]アンドレアセン、F。、バウアー、M。、およびD.ウィング、「メディアストリームのセッション記述プロトコル（SDP）セキュリティ記述」、RFC 4568、DOI 10.17487 / RFC4568、2006年7月、<https：// www。 rfc-editor.org/info/rfc4568>。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, <https://www.rfc-editor.org/info/rfc5627>.
[RFC5627] Rosenberg、J。、「Session Initiation Protocol（SIP）でグローバルにルーティング可能なユーザーエージェントURI（GRUU）を取得して使用する」、RFC 5627、DOI 10.17487 / RFC5627、2009年10月、<https：//www.rfc- editor.org/info/rfc5627>。
[RFC6064] Westerlund, M. and P. Frojdh, "SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service", RFC 6064, DOI 10.17487/RFC6064, January 2011, <https://www.rfc-editor.org/info/rfc6064>.
[RFC6064] Westerlund、M。およびP. Frojdh、「3GPPパケット交換ストリーミングサービスおよびマルチメディアブロードキャスト/マルチキャストサービス用に定義されたSDPおよびRTSP拡張」、RFC 6064、DOI 10.17487 / RFC6064、2011年1月、<https：// www .rfc-editor.org / info / rfc6064>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc6872>。
[RFC6873] Salgueiro, G., Gurbani, V., and A. Roach, "Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)", RFC 6873, DOI 10.17487/RFC6873, February 2013, <https://www.rfc-editor.org/info/rfc6873>.
[RFC6873] Salgueiro、G.、Gurbani、V。、およびA. Roach、「Session Initiation Protocol（SIP）Common Log Format（CLF）」、RFC 6873、DOI 10.17487 / RFC6873、2013年2月、<https： //www.rfc-editor.org/info/rfc6873>。
[RFC7989] Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End-to-End Session Identification in IP-Based Multimedia Communication Networks", RFC 7989, DOI 10.17487/RFC7989, October 2016, <https://www.rfc-editor.org/info/rfc7989>.
[RFC7989] Jones、P.、Salgueiro、G.、Pearce、C。、およびP. Giralt、「IPベースのマルチメディア通信ネットワークにおけるエンドツーエンドのセッション識別」、RFC 7989、DOI 10.17487 / RFC7989、2016年10月、<https://www.rfc-editor.org/info/rfc7989>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[SDP-PARAMETERS] IANA, "Session Description Protocol (SDP) Parameters", <https://www.iana.org/assignments/sdp-parameters/>.
[SDP-PARAMETERS] IANA、「Session Description Protocol（SDP）Parameters」、<https://www.iana.org/assignments/sdp-parameters/>。
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, December 2003, <https://www.rfc-editor.org/info/rfc3665>.
[RFC3665] Johnston、A.、Donovan、S.、Sparks、R.、Cunningham、C。、およびK. Summers、「Session Initiation Protocol（SIP）Basic Call Flow Examples」、BCP 75、RFC 3665、DOI 10.17487 / RFC3665、2003年12月、<https://www.rfc-editor.org/info/rfc3665>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[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, <https://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月、<https ：//www.rfc-editor.org/info/rfc5589>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<https://www.rfc-editor.org/info/rfc6973>。
[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, <https://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月、<https：//www.rfc -editor.org/info/rfc7092>。
[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, <https://www.rfc-editor.org/info/rfc7206>.
[RFC7206]ジョーンズ、P。、サルゲイロ、G。、ポーク、J。、リース、L。、およびH.カプラン、「IPベースのマルチメディア通信ネットワークにおけるエンドツーエンドセッション識別の要件」、RFC 7206 、DOI 10.17487 / RFC7206、2014年5月、<https://www.rfc-editor.org/info/rfc7206>。
[RFC8123] Dawes, P. and C. Arunachalam, "Requirements for Marking SIP Messages to be Logged", RFC 8123, DOI 10.17487/RFC8123, March 2017, <https://www.rfc-editor.org/info/rfc8123>.
[RFC8123] Dawes、P。およびC. Arunachalam、「ログに記録するSIPメッセージをマークするための要件」、RFC 8123、DOI 10.17487 / RFC8123、2017年3月、<https://www.rfc-editor.org/info/rfc8123 >。
Acknowledgments
謝辞
The authors wish to thank Paul Giralt, Paul Kyzivat, Jorgen Axell, Christer Holmberg, Vijay Gurbani, Ben Campbell, Gonzalo Salgueiro, Francesca Palombini, Adam Roach, Mirja Kuhlewind, Benjamin Kaduk, Eric Rescorla, Alissa Cooper, Warren Kumari, and Alexey Melnikov for their constructive review comments and guidance while developing this document.
著者は、Paul Giralt、Paul Kyzivat、Jorgen Axell、Christer Holmberg、Vijay Gurbani、Ben Campbell、Gonzalo Salgueiro、Francesca Palombini、Adam Roach、Mirja Kuhlewind、Benjamin Kaduk、Eric Rescorla、Alissa Cooper、Warren Kumari、およびAlexey Melnikovに感謝しますこのドキュメントを作成する際の建設的なレビューコメントとガイダンスに感謝します。
Authors' Addresses
著者のアドレス
Peter Dawes Vodafone Group The Connection Newbury, Berkshire RG14 2FN United Kingdom
Peter Dawes Vodafone Group The Connectionニューベリー、バークシャーRG14 2FNイギリス
Phone: +44 7717 275009
Email: peter.dawes@vodafone.com
Chidambaram Arunachalam Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America
Chidambaram Arunachalam Cisco Systems 7200-12 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
Email: carunach@cisco.com