[要約] RFC 6872は、SIPのための共通ログ形式（CLF）のフレームワークと情報モデルを提供する。その目的は、SIPセッションのログデータを一貫性のある形式で収集・分析するためのガイドラインを提供することである。
Internet Engineering Task Force (IETF) V. Gurbani, Ed.
Request for Comments: 6872 Bell Laboratories, Alcatel-Lucent
Category: Standards Track E. Burger, Ed.
ISSN: 2070-1721 Georgetown University
T. Anjali
Illinois Institute of Technology
H. Abdelnur
O. Festor
INRIA
February 2013
The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model
セッション開始プロトコル（SIP）の共通ログ形式（CLF）：フレームワークと情報モデル
Abstract
概要
Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de facto standard formats are invaluable to system administrators for troubleshooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and, as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of a SIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents.
Apacheなどのよく知られたWebサーバーやSquidなどのWebプロキシは、一般的なログ形式を使用したイベントログをサポートしています。これらの事実上の標準形式を使用して生成されたログは、システム管理者がサーバーやツールの作成者をトラブルシューティングして、ログファイルをマイニングしてレポートやトレンドを生成するツールを作成する際に非常に役立ちます。さらに、これらのログファイルは、異常検出システムのトレーニングやセキュリティイベント管理システムへのイベントのフィードにも使用できます。セッション開始プロトコル（SIP）には共通のログ形式がないため、各サーバーは個別のログ形式をサポートしているため、傾向分析やセキュリティ検出を行うツールの作成が不必要に複雑になります。このドキュメントでは、既存のアプローチの要件と分析を含むフレームワークについて説明し、ユーザーエージェント、プロキシ、レジストラ、リダイレクトサーバー、およびバックアップ先で均一に使用できるSIP共通ログファイル形式の開発に関する情報モデルを指定します-backユーザーエージェント。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6872.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6872で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Problem Statement ...............................................4
4. What SIP CLF Is and What It Is Not ..............................5
5. Alternative Approaches to SIP CLF ...............................5
5.1. SIP CLF and Call Detail Records ............................6
5.2. SIP CLF and Packet Capture Tools ...........................6
5.3. SIP CLF and Syslog .........................................7
5.4. SIP CLF and IPFIX ..........................................8
6. Motivation and Use Cases ........................................8
7. Challenges in Establishing a SIP CLF ...........................10
8. Information Model ..............................................11
8.1. SIP CLF Mandatory Fields ..................................11
8.2. Mandatory Fields and SIP Entities .........................13
9. Examples .......................................................14
9.1. UAC Registration ..........................................15
9.2. Direct Call between Alice and Bob .........................17
9.3. Single Downstream Branch Call .............................20
9.4. Forked Call ...............................................25
10. Security Considerations .......................................35
11. Operational Guidance ..........................................37
12. Acknowledgments ...............................................37
13. References ....................................................37
13.1. Normative References .....................................37
13.2. Informative References ...................................38
Servers executing on Internet hosts produce log records as part of their normal operations. Some log records are, in essence, a summary of an application-layer protocol data unit (PDU) that captures, in precise terms, an event that was processed by the server. These log records serve many purposes including analysis and troubleshooting.
インターネットホストで実行されているサーバーは、通常の操作の一部としてログレコードを生成します。一部のログレコードは、本質的には、サーバーによって処理されたイベントを正確にキャプチャするアプリケーション層プロトコルデータユニット（PDU）の概要です。これらのログレコードは、分析やトラブルシューティングなど、多くの目的に役立ちます。
Well-known web servers such as Apache and web proxies like Squid support event logging using a Common Log Format (CLF), the common structure for logging requests and responses serviced by the web server. It can be argued that a good part of the success of Apache has been its CLF because it allowed third parties to produce tools that analyzed the data and generated traffic reports and trends. The Apache CLF has been so successful that not only did it become the de facto standard in producing logging data for web servers but also many commercial web servers can be configured to produce logs in this format. An example of the Apache CLF is depicted next:
Apacheなどのよく知られているWebサーバーやSquidなどのWebプロキシは、共通ログ形式（CLF）を使用したイベントログをサポートしています。データを分析してトラフィックレポートと傾向を生成するツールをサードパーティが作成できるようになったため、Apacheの成功のかなりの部分はそのCLFであったと主張できます。 Apache CLFは非常に成功しているため、Webサーバーのロギングデータを生成する際の事実上の標準となっただけでなく、多くの商用Webサーバーもこの形式でログを生成するように構成できます。 Apache CLFの例を次に示します。
%h %l %u %t \"%r\" %s %b remotehost rfc931 authuser [date] request status bytes
％h％l％u％t \ "％r \"％s％bリモートホストrfc931 authuser [日付]リクエストステータスバイト
remotehost: Remote hostname (or IP number if DNS hostname is not available or if DNSLookup is Off.
remotehost：リモートホスト名（DNSホスト名が使用できない場合、またはDNSLookupがオフの場合はIP番号）。
rfc931: The remote logname of the user.
rfc931：ユーザーのリモートログ名。
authuser: The username by which the user has authenticated himself.
authuser：ユーザーが自分自身を認証したユーザー名。
[date]: Date and time of the request.
[date]：リクエストの日時。
request: The request line exactly as it came from the client.
request：クライアントからのリクエストライン。
status: The HTTP status code returned to the client.
status：クライアントに返されるHTTPステータスコード。
bytes: The content-length of the document transferred.
バイト：転送されたドキュメントのコンテンツ長。
The inspiration for the SIP CLF is the Apache CLF. However, the state machinery for an HTTP transaction is much simpler than that of the SIP transaction (as evidenced in Section 7). The SIP CLF needs to do considerably more.
SIP CLFのインスピレーションはApache CLFです。ただし、HTTPトランザクションの状態機構は、SIPトランザクションの状態機構よりもはるかに単純です（セクション7を参照）。 SIP CLFはさらに多くのことを行う必要があります。
This document outlines the problem statement that argues for a SIP CLF. In addition, it provides an information model pertaining to the minimum set of SIP headers and fields that must be logged. This document does not prescribe a specific representation format for the SIP CLF record and, instead, allows other documents to define a representation format. [RFC6873] is an example of a representation format that provides a UTF-8-based logging scheme.
このドキュメントでは、SIP CLFを主張する問題の説明を概説します。さらに、ログに記録する必要のあるSIPヘッダーとフィールドの最小セットに関する情報モデルも提供します。このドキュメントでは、SIP CLFレコードの特定の表現形式を規定せず、代わりに他のドキュメントで表現形式を定義できるようにします。 [RFC6873]は、UTF-8ベースのロギングスキームを提供する表現形式の例です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
RFC 3261 [RFC3261] defines additional terms used in this document
that are specific to the SIP domain such as "proxy"; "registrar";
"redirect server"; "user agent server" or "UAS"; "user agent client"
or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog";
"transaction"; "server transaction".
This document uses the term "SIP server" that is defined to include the following SIP entities: user agent server, registrar, redirect server, a SIP proxy in the role of user agent server, and a B2BUA in the role of a user agent server.
このドキュメントでは、次のSIPエンティティを含むように定義されている「SIPサーバー」という用語を使用します。ユーザーエージェントサーバー、レジストラ、リダイレクトサーバー、ユーザーエージェントサーバーの役割のSIPプロキシ、およびユーザーエージェントサーバーの役割のB2BUA 。
The Session Initiation Protocol (SIP) [RFC3261] is an Internet multimedia session signaling protocol. A typical deployment of SIP in an enterprise will consist of SIP entities from multiple vendors. Each SIP entity produces logs using a proprietary format. The result of multiplicity of the log file formats is the inability of the support staff to easily trace a call from one entity to another or even to craft common tools that will perform trend analysis, debugging and troubleshooting problems uniformly across the SIP entities from multiple vendors.
セッション開始プロトコル（SIP）[RFC3261]は、インターネットマルチメディアセッションシグナリングプロトコルです。企業におけるSIPの一般的な展開は、複数のベンダーのSIPエンティティで構成されます。各SIPエンティティは、独自の形式を使用してログを生成します。ログファイル形式の多様性の結果、サポートスタッフは、あるエンティティから別のエンティティへのコールを簡単に追跡できず、複数のベンダーのSIPエンティティ全体で傾向分析、デバッグ、およびトラブルシューティングを実行する一般的なツールを作成することさえできません。 。
Furthermore, the log file must be easily accessible by command-line tools for simple text processing. This allows ad hoc queries against the elements in the log file to retrieve a log record. Furthermore, the log file must be in a format that allows for rapid searches of a particular log record (or records). Because of the large number of records expected in the log file, the records must be in a format that allows for rapid scanning and ease of skipping records that do not match a search criterion. Finally, the generation of the log file must not impose undue burden on the SIP implementation in the form of additional libraries that may not be uniformly available on different platforms and operating environments where a SIP entity generating a log file record may be found.
さらに、単純なテキスト処理のために、コマンドラインツールからログファイルに簡単にアクセスできる必要があります。これにより、ログファイルの要素に対するアドホッククエリでログレコードを取得できます。さらに、ログファイルは、特定のログレコード（または複数のレコード）をすばやく検索できる形式である必要があります。ログファイルには多数のレコードが想定されるため、レコードは、迅速なスキャンを可能にし、検索条件に一致しないレコードをスキップしやすい形式である必要があります。最後に、ログファイルの生成は、ログファイルレコードを生成するSIPエンティティが見つかる可能性があるさまざまなプラットフォームや動作環境で均一に利用できない可能性がある追加ライブラリの形でSIP実装に過度の負担を課してはなりません。
SIP does not currently have a common log format, and this document serves to provide the rationale to establish a SIP CLF and identifies the required minimal information that must appear in any SIP CLF record.
SIPには現在、共通のログ形式がありません。このドキュメントは、SIP CLFを確立する根拠を提供し、SIP CLFレコードに表示する必要がある最小限の情報を識別します。
The SIP CLF is a standardized manner of producing a log file. This format can be used by SIP clients, SIP servers, proxies, and B2BUAs. The SIP CLF is simply an easily digestible log of currently occurring events and past transactions. It contains enough information to allow humans and automata to derive relationships between discrete transactions handled at a SIP entity or to search for a certain dialog or a related set of transactions.
SIP CLFは、ログファイルを生成する標準化された方法です。この形式は、SIPクライアント、SIPサーバー、プロキシ、およびB2BUAで使用できます。 SIP CLFは、現在発生しているイベントと過去のトランザクションの簡単に消化できるログです。人間とオートマトンがSIPエンティティで処理される個別のトランザクション間の関係を導出したり、特定のダイアログまたは関連するトランザクションセットを検索したりするのに十分な情報が含まれています。
The SIP CLF is amenable to quick parsing (i.e., well-delimited fields), and it is platform and operating system neutral.
SIP CLFは、迅速な解析（つまり、適切に区切られたフィールド）が可能であり、プラットフォームおよびオペレーティングシステムに依存しません。
Due to the structure imposed by delimited fields, the SIP CLF is amenable to easy parsing and lends itself well to creating other innovative tools such as logfile parsers and trend analytic engines.
区切られたフィールドによって課される構造のため、SIP CLFは簡単な解析が可能で、ログファイルパーサーやトレンド分析エンジンなどの他の革新的なツールの作成に適しています。
The SIP CLF is not a billing tool. It is not expected that enterprises will bill customers based on SIP CLF. The SIP CLF records events at the signaling layer only and does not attempt to correlate the veracity of these events with the media layer. Thus, it cannot be used to trigger customer billing.
SIP CLFは請求ツールではありません。企業がSIP CLFに基づいて顧客に請求することは想定されていません。 SIP CLFは、イベントをシグナリングレイヤーでのみ記録し、これらのイベントの信憑性をメディアレイヤーと関連付けようとはしません。したがって、顧客請求のトリガーには使用できません。
The SIP CLF is not a quality of service (QoS) measurement tool. If QoS is defined as measuring the mean opinion score (MOS) of the received media, then SIP CLF does not aid in this task since it does not summarize events at the media layer.
SIP CLFは、サービス品質（QoS）測定ツールではありません。 QoSが受信メディアの平均オピニオンスコア（MOS）の測定として定義されている場合、SIP CLFはメディアレイヤーでイベントを要約しないため、このタスクには役立ちません。
Finally, the SIP CLF is not a tool for supporting lawful intercept.
最後に、SIP CLFは合法的傍受をサポートするためのツールではありません。
The sipclf working group discussed four alternative approaches to determine whether they fill the requirements of what is desired of a SIP CLF outlined in Section 3. We conclude that while every scheme discussed below comes with its advantages, its disadvantages may preclude it from being used as a SIP CLF. However, we stress that the information model contained in this document can be used to develop alternative representation formats when desired. Currently, [RFC6873] is an example of a representation format that provides a UTF-8-based logging scheme that meets all the requirements of Section 3.
sipclfワーキンググループは、セクション3で概説されているSIP CLFに必要な要件を満たすかどうかを判断するための4つの代替アプローチについて議論しました。以下で説明するすべてのスキームには利点がある一方で、その欠点により、 SIP CLF。ただし、このドキュメントに含まれている情報モデルを使用して、必要に応じて別の表現形式を開発できることを強調します。現在、[RFC6873]は、セクション3のすべての要件を満たすUTF-8ベースのロギングスキームを提供する表現形式の例です。
Call Detail Records (CDRs) are used in operator networks widely and with the adoption of SIP, standardization bodies such as the Third Generation Partnership Project (3GPP) have subsequently defined SIP-related CDRs as well. Today, CDRs are used to implement the functionality approximated by SIP CLF; however, there are important differences.
通話詳細記録（CDR）は事業者ネットワークで広く使用されており、SIPの採用により、第3世代パートナーシッププロジェクト（3GPP）などの標準化団体がSIP関連のCDRも定義しています。現在、CDRはSIP CLFによって概算される機能を実装するために使用されています。ただし、重要な違いがあります。
First, SIP CLF operates natively at the transaction layer and maintains enough information in the information elements being logged that dialog-related data can be subsequently derived from the transaction logs. Thus, esoteric SIP fields and parameters like the To header (including tags), the From header (including tags), the Command Sequence (CSeq) number, etc., are logged in SIP CLF. By contrast, a CDR is used mostly for charging and thus saves information to facilitate that very aspect. A CDR will most certainly log the public user identification of a party requesting a service (which may not correspond to the From header) and the public user identification of the party called party (which may not correspond to the To header). Furthermore, the sequence numbers maintained by the CDR may not correspond to the SIP CSeq header. Thus, it will be hard to piece together the state of a dialog through a sequence of CDR records.
まず、SIP CLFはトランザクションレイヤーでネイティブに動作し、ログに記録される情報要素に十分な情報を保持します。これにより、ダイアログ関連のデータをトランザクションログから後で取得できます。したがって、Toヘッダー（タグを含む）、Fromヘッダー（タグを含む）、コマンドシーケンス（CSeq）番号などの難解なSIPフィールドとパラメーターがSIP CLFに記録されます。対照的に、CDRは主に課金に使用されるため、情報を保存してその側面を促進します。 CDRは、サービスを要求するパーティのパブリックユーザーID（Fromヘッダーに対応しない場合がある）と、着呼側パーティのパブリックユーザーID（Toヘッダーに対応しない場合がある）を確実にログに記録します。さらに、CDRによって維持されるシーケンス番号は、SIP CSeqヘッダーに対応しない場合があります。したがって、一連のCDRレコードを通じてダイアログの状態をつなぎ合わせるのは困難です。
Second, a CDR record will, in all probability, be generated at a SIP entity performing some form of proxy-like functionality of a B2BUA providing some service. By contrast, SIP CLF is lightweight enough that it can be generated by a canonical SIP user agent server and user agent client as well, including those that execute on resource constrained devices (mobile phones).
第2に、CDRレコードは、おそらく何らかのサービスを提供するB2BUAの何らかのプロキシのような機能を実行するSIPエンティティで生成されます。対照的に、SIP CLFは十分に軽量であるため、リソースが制限されたデバイス（携帯電話）で実行されるものを含め、正規のSIPユーザーエージェントサーバーおよびユーザーエージェントクライアントでも生成できます。
Finally, SIP is also being deployed outside of operator-managed Voice over IP (VoIP) networks. Universities, research laboratories, and small-to medium-sized companies are deploying SIP-based VoIP solutions on networks owned and managed by them. Many of the latter constituencies will not have an interest in generating CDRs, but they will like to have a concise representation of the messages being handled by the SIP entities in a common format.
最後に、SIPは事業者が管理するVoice over IP（VoIP）ネットワークの外部にも配備されています。大学、研究所、および中小規模の企業が、SIPベースのVoIPソリューションを、それらが所有および管理するネットワークに展開しています。後者のConstituencyの多くは、CDRの生成には関心がありませんが、SIPエンティティによって処理されるメッセージを共通の形式で簡潔に表現したいと考えています。
Wireshark and tcpdump are popular raw packet capture tools. Wireshark even contains filters that can understand SIP at the protocol level and break down a captured message into its individual header components. While packet capture tools are appropriate to capture and view discrete SIP messages, they do not suffice to serve in the same capacity as SIP CLF for the following reasons: o Using packet capturing tools will not eliminate the need for agreeing to a common set of fields to represent a SIP CLF record. This common understanding is important for interoperability to allow one implementation to read a log file written by a different implementation.
Wiresharkとtcpdumpは、一般的な未加工パケットキャプチャツールです。 Wiresharkには、プロトコルレベルでSIPを理解し、キャプチャしたメッセージを個々のヘッダーコンポーネントに分解できるフィルターも含まれています。パケットキャプチャツールは個別のSIPメッセージをキャプチャして表示するのに適していますが、次の理由により、SIP CLFと同じ容量で機能するには不十分です。oパケットキャプチャツールを使用しても、共通のフィールドセットに同意する必要がなくなるわけではありません。 SIP CLFレコードを表します。この共通の理解は、ある実装が別の実装によって書き込まれたログファイルを読み取れるようにする相互運用性にとって重要です。
o The packet capture from these tools is not easily searchable by simple command-line tools for text processing.
o これらのツールからのパケットキャプチャは、テキスト処理用の単純なコマンドラインツールでは簡単に検索できません。
o Using packet capture tools requires that the underlying libraries related to packet capture be available for all platforms on which a SIP server or a SIP client can execute. Given the different platforms on which a SIP client or server runs --- mobile, fixed host, tablet, etc. --- this may become an inhibiting factor when compared to the SIP client or server producing a SIP CLF record natively (the SIP client or server has already parsed the SIP message for operation on it; therefore, it seems reasonable to have it write the parsed tokens out to persistent store in an agreed upon format).
o パケットキャプチャツールを使用するには、SIPサーバーまたはSIPクライアントが実行できるすべてのプラットフォームで、パケットキャプチャに関連する基本的なライブラリを使用できる必要があります。 SIPクライアントまたはサーバーが実行されるさまざまなプラットフォーム---モバイル、固定ホスト、タブレットなど-があると、SIP CLFレコードをネイティブに生成するSIPクライアントまたはサーバー（SIPクライアントまたはサーバーは、SIPメッセージを操作するためにすでに解析しているため、解析済みのトークンを合意された形式で永続ストアに書き込むことは妥当であるように思われます）。
o If SIP messages are exchanged over a secure transport (TLS) packet, capture tools will be unable to decrypt them and render them as individual SIP headers.
o セキュアトランスポート（TLS）パケットを介してSIPメッセージが交換される場合、キャプチャツールはメッセージを復号化して個別のSIPヘッダーとしてレンダリングできません。
o Using such tools and related packet capture libraries may imposes a dependency on a third-party library.
o このようなツールと関連するパケットキャプチャライブラリを使用すると、サードパーティのライブラリに依存する可能性があります。
The syslog protocol [RFC5424] conveys event notification messages from an originator to a collector. While the syslog protocol provides a packet format and transport mechanism, it does not describe any storage format for syslog messages. Pragmatically, while the syslog protocol itself does not describe a storage format, the collector will write the arriving messages into a disk file. A new problem arises due to the general nature of syslog: the disk file will contain log messages from many originators, not just SIP entities. This imposes an additional burden of discarding all extraneous records when analyzing the disk file for SIP CLF records of interest. SIP CLF records are best stored in a log file that is easily searchable by command-line tools.
syslogプロトコル[RFC5424]は、発信者からコレクターにイベント通知メッセージを伝達します。 syslogプロトコルはパケット形式とトランスポートメカニズムを提供しますが、syslogメッセージのストレージ形式については説明していません。実際には、syslogプロトコル自体はストレージ形式を記述しませんが、コレクターは到着したメッセージをディスクファイルに書き込みます。 syslogの一般的な性質により、新しい問題が発生します。ディスクファイルには、SIPエンティティだけでなく、多くの発信者からのログメッセージが含まれます。これにより、対象のSIP CLFレコードのディスクファイルを分析するときに、すべての無関係なレコードを破棄するという追加の負担がかかります。 SIP CLFレコードは、コマンドラインツールで簡単に検索できるログファイルに保存するのが最適です。
Other drawbacks of using syslog include the unavailability of the collector under certain scenarios (a mobile SIP phone may be unable to find a collector to which it should send the messages), and the need to have syslog-specific libraries available for each platform on which the SIP server or the SIP client can execute. Finally, because of the frequency and size of SIP log messages, it is not desirable to send every SIP CLF log message to the collector. Instead, a judicious use of syslog could be that only certain events -- those that are pertinent from a network situational awareness perspective, or those that include a periodic statistical summary of the messages processed -- are sent to the collector.
syslogを使用する他の欠点には、特定のシナリオでコレクターが使用できない（モバイルSIP電話がメッセージの送信先のコレクターを見つけられない場合がある）、および各プラットフォームでsyslog固有のライブラリーを使用できる必要があるSIPサーバーまたはSIPクライアントが実行できます。最後に、SIPログメッセージの頻度とサイズのため、すべてのSIP CLFログメッセージをコレクタに送信することは望ましくありません。代わりに、syslogの賢明な使用法は、特定のイベント（ネットワークの状況認識の観点から関連するイベント、または処理されたメッセージの定期的な統計要約を含むイベント）のみがコレクターに送信されることです。
The IP Flow Information Export (IPFIX) protocol [RFC5101] allows network administrators to aggregate IP packets characterized by some commonality (similar packet header fields, one or more characteristics of the packet itself) into a flow that can be subsequently collected and sent to other elements for analysis and monitoring. However, IPFIX is not a logging format and does not produce a log file that can be examined by ad hoc text processing tools.
IPフロー情報エクスポート（IPFIX）プロトコル[RFC5101]を使用すると、ネットワーク管理者は、いくつかの共通点（類似したパケットヘッダーフィールド、パケット自体の1つ以上の特性）によって特徴付けられるIPパケットをフローに集約し、後で収集して他に送信できます。分析と監視のための要素。ただし、IPFIXはログ形式ではなく、アドホックテキスト処理ツールで検査できるログファイルを生成しません。
As SIP becomes pervasive in multiple business domains and ubiquitous in academic and research environments, it is beneficial to establish a CLF for the following reasons:
SIPが複数のビジネスドメインで普及し、学術および研究環境でユビキタスになるにつれ、次の理由でCLFを確立することが有益です。
Common reference for interpreting events: In a laboratory environment or an enterprise service offering, there will typically be SIP entities from multiple vendors participating in routing requests. Absent a common log format, each entity will produce output records in a native format, making it hard to establish commonality for tools that operate on the log file.
イベントを解釈するための一般的なリファレンス：ラボ環境またはエンタープライズサービスオファリングでは、通常、ルーティングリクエストに参加する複数のベンダーのSIPエンティティが存在します。共通のログ形式がない場合、各エンティティはネイティブ形式で出力レコードを生成するため、ログファイルを操作するツールの共通性を確立することが難しくなります。
Writing common tools: A common log format allows independent tool providers to craft tools and applications that interpret the CLF data to produce insightful trend analysis and detailed traffic reports. The format should be such that it retains the ability to be read by humans and processed using traditional Unix text processing tools.
共通ツールの作成：共通ログ形式により、独立したツールプロバイダーは、CLFデータを解釈して洞察に富んだ傾向分析と詳細なトラフィックレポートを生成するツールとアプリケーションを作成できます。この形式は、人間が読み取ったり、従来のUnixテキスト処理ツールを使用して処理したりできる機能を保持する必要があります。
Session correlation across diverse processing elements: In operational SIP networks, a request will typically be processed by more than one SIP server. A SIP CLF will allow the network operator to trace the progression of the request (or a set of requests) as they traverse through the different servers to establish a concise diagnostic trail of a SIP session.
さまざまな処理要素間のセッション相関：運用SIPネットワークでは、要求は通常、複数のSIPサーバーによって処理されます。 SIP CLFを使用すると、ネットワークオペレーターは、要求（または一連の要求）が異なるサーバーを通過するときに、その進行状況を追跡して、SIPセッションの簡潔な診断証跡を確立できます。
Note that tracing the request through a set of servers is considerably less challenging if all the servers belong to the same administrative domain.
すべてのサーバーが同じ管理ドメインに属している場合、一連のサーバーを介して要求をトレースすることは、それほど難しくありません。
Message correlation across transactions: A SIP CLF can enable a quick lookup of all messages that comprise a transaction (e.g., "Find all messages corresponding to server transaction X, including all forked branches.").
トランザクション間のメッセージ相関：SIP CLFは、トランザクションを構成するすべてのメッセージのクイックルックアップを可能にします（たとえば、「フォークされたすべてのブランチを含む、サーバートランザクションXに対応するすべてのメッセージを検索します」）。
Message correlation across dialogs: A SIP CLF can correlate transactions that comprise a dialog (e.g., "Find all messages for dialog created by Call-ID C, From tag F and To tag T.").
ダイアログ間のメッセージ相関：SIP CLFは、ダイアログを構成するトランザクションを相関させることができます（たとえば、「Call-ID C、FromタグFおよびToタグTによって作成されたダイアログのすべてのメッセージを検索します」）。
Trend analysis: A SIP CLF allows an administrator to collect data and spot patterns or trends in the information (e.g., "What is the domain where the most sessions are routed to between 9:00 AM and 1:00 PM?").
傾向分析：SIP CLFにより、管理者はデータを収集し、情報のパターンまたは傾向を特定できます（たとえば、「ほとんどのセッションが午前9時から午後1時にルーティングされるドメインは何ですか？」）。
Train anomaly detection systems: A SIP CLF will allow for the training of anomaly detection systems that once trained can monitor the CLF file to trigger an alarm on the subsequent deviations from accepted patterns in the data set. Currently, anomaly detection systems monitor the network and parse raw packets that comprise a SIP message -- a process that is unsuitable for anomaly detection systems [rieck2008]. With all the necessary event data at their disposal, network operations managers and information technology operation managers are in a much better position to correlate, aggregate, and prioritize log data to maintain situational awareness.
異常検出システムのトレーニング：SIP CLFを使用すると、異常検出システムのトレーニングが可能になります。トレーニングが完了すると、CLFファイルを監視して、データセット内の受け入れられたパターンからの後続の逸脱に関するアラームをトリガーできます。現在、異常検出システムはネットワークを監視し、SIPメッセージを構成する生のパケットを解析します。このプロセスは異常検出システムには適していません[rieck2008]。必要なすべてのイベントデータを自由に利用できるので、ネットワーク運用マネージャーと情報技術運用マネージャーは、状況認識を維持するために、ログデータを相互に関連付け、集約し、優先順位を付けることができます。
Testing: A SIP CLF allows for automatic testing of SIP equipment by writing tools that can parse a SIP CLF file to ensure behavior of a device under test.
テスト：SIP CLFは、SIP CLFファイルを解析してテスト中のデバイスの動作を確認できるツールを作成することにより、SIP機器の自動テストを可能にします。
Troubleshooting: A SIP CLF can enable cursory troubleshooting of a SIP entity (e.g., "How long did it take to generate a final response for the INVITE associated with Call-ID X?").
トラブルシューティング：SIP CLFは、SIPエンティティの大まかなトラブルシューティングを可能にします（たとえば、「Call-ID Xに関連付けられたINVITEの最終応答を生成するのにどれくらいの時間がかかりましたか？」）。
Offline analysis: A SIP CLF allows for offline analysis of the data gathered. Once a SIP CLF file has been generated, it can be transported (subject to the security considerations in Section 10) to a host with appropriate computing resources to perform subsequent analysis.
オフライン分析：SIP CLFは、収集されたデータのオフライン分析を可能にします。 SIP CLFファイルが生成されると、その後の分析を実行するために、適切なコンピューティングリソースを持つホストに（セクション10のセキュリティに関する考慮事項に従って）転送できます。
Real-time monitoring: A SIP CLF allows administrators to visually notice the events occurring at a SIP entity in real-time providing accurate situational awareness.
リアルタイムの監視：SIP CLFにより、管理者はSIPエンティティで発生するイベントをリアルタイムで視覚的に確認し、正確な状況認識を提供できます。
Establishing a CLF for SIP is a challenging task. The behavior of a SIP entity is more complex when compared to the equivalent HTTP entity.
SIPのCLFを確立することは困難な作業です。 SIPエンティティの動作は、同等のHTTPエンティティと比較するとより複雑です。
Base protocol services such as parallel or serial forking elicit multiple final responses. Ensuing delays between sending a request and receiving a final response all add complexity when considering what fields should comprise a CLF and in what manner. Furthermore, unlike HTTP, SIP groups multiple discrete transactions into a dialog, and these transactions may arrive at a varying inter-arrival rate at a proxy. For example, the BYE transaction usually arrives much after the corresponding INVITE transaction was received, serviced, and expunged from the transaction list. Nonetheless, it is advantageous to relate these transactions such that automata or a human monitoring the log file can construct a set consisting of related transactions.
パラレルまたはシリアルフォークなどの基本プロトコルサービスは、複数の最終応答を引き出します。要求を送信してから最終応答を受信するまでの間に遅延が発生すると、どのフィールドがどのようにCLFを構成するかを検討するときに複雑さが増します。さらに、HTTPとは異なり、SIPは複数の個別のトランザクションを1つのダイアログにグループ化し、これらのトランザクションはプロキシでさまざまな到着間隔で到着する場合があります。たとえば、BYEトランザクションは通常、対応するINVITEトランザクションが受信され、サービスが提供され、トランザクションリストから消去された後、ずっと後に到着します。それでも、ログファイルを監視するオートマトンまたは人間が、関連するトランザクションで構成されるセットを構築できるように、これらのトランザクションを関連付けると有利です。
ACK requests in SIP need careful consideration as well. In SIP, an ACK is a special method that is associated with an INVITE only. It does not require a response; furthermore, if it is acknowledging a non-2xx response, then the ACK is considered part of the original INVITE transaction. If it is acknowledging a 2xx-class response, then the ACK is a separate transaction consisting of a request only (i.e., there is not a response for an ACK request). CANCEL is another method that is tied to an INVITE transaction, but unlike ACK, the CANCEL request elicits a final response.
SIPでのACK要求にも注意が必要です。 SIPでは、ACKはINVITEにのみ関連付けられる特別な方法です。応答は必要ありません。さらに、2xx以外の応答を確認している場合、ACKは元のINVITEトランザクションの一部と見なされます。 2xxクラスの応答を確認している場合、ACKは要求のみで構成される個別のトランザクションです（つまり、ACK要求に対する応答はありません）。 CANCELは、INVITEトランザクションに関連付けられている別の方法ですが、ACKとは異なり、CANCEL要求は最終応答を引き出します。
While most requests elicit a response immediately, the INVITE request in SIP can remain in a pending state at a proxy as it forks branches downstream or at a user agent server while it alerts the user. [RFC3261] instructs the server transaction to send a 1xx-class provisional response if a final response is delayed for more than 200 ms. A SIP CLF log file needs to include such provisional responses because they help train automata associated with anomaly detection systems and provide some positive feedback for a human observer monitoring the log file.
ほとんどの要求はすぐに応答を引き出しますが、SIPのINVITE要求は、ユーザーに警告している間、プロキシがダウンストリームまたはユーザーエージェントサーバーでブランチをフォークするため、保留状態のままになります。 [RFC3261]は、最終応答が200ミリ秒を超えて遅延した場合に、1xxクラスの暫定応答を送信するようサーバートランザクションに指示します。 SIP CLFログファイルは、異常検出システムに関連するオートマトンのトレーニングを支援し、ログファイルを監視する人間の観測者に肯定的なフィードバックを提供するため、このような暫定的な応答を含める必要があります。
Finally, beyond supporting native SIP actors such as proxies, registrars, redirect servers, and user agent servers (UASs), it is beneficial to derive a common log format that supports B2BUA behavior, which may vary considerably depending on the specific nature of the B2BUA.
最後に、プロキシ、レジストラ、リダイレクトサーバー、ユーザーエージェントサーバー（UAS）などのネイティブSIPアクターをサポートする以外に、B2BUAの動作をサポートする共通のログ形式を導出することは有益です。 。
This document defines the mandatory fields that MUST occur in a SIP CLF record. The maximum size (in number of bytes) for a SIP CLF field is 4096 bytes. This limit is the same regardless of whether the SIP CLF field is a meta-field (see "Timestamp" and "Directionality" defined below) or a normal SIP header. If the body of the SIP message is to be logged, it MUST conform to this limit as well.
このドキュメントでは、SIP CLFレコードで発生する必要がある必須フィールドを定義します。 SIP CLFフィールドの最大サイズ（バイト数）は4096バイトです。この制限は、SIP CLFフィールドがメタフィールド（下記の「タイムスタンプ」と「方向性」を参照）であるか、通常のSIPヘッダーであるかに関係なく同じです。 SIPメッセージの本文をログに記録する場合は、この制限にも準拠する必要があります。
SIP bodies may contain characters that do not form a valid UTF-8 sequence. As such, the logging of bodies requires understanding trade-offs with respect to a specific logging format to determine if the body can be logged as is or some encoding will be required. The specific syntax and semantics used to log SIP bodies MUST be defined by the specific representation format document used to generate the SIP CLF record.
SIPボディには、有効なUTF-8シーケンスを形成しない文字が含まれている可能性があります。そのため、ボディのロギングでは、ボディをそのままロギングできるか、または何らかのエンコーディングが必要かどうかを判断するために、特定のロギングフォーマットに関するトレードオフを理解する必要があります。 SIP本体のログに使用される特定の構文とセマンティクスは、SIP CLFレコードの生成に使用される特定の表現形式ドキュメントによって定義される必要があります。
The information model supports extensibility by providing the capability to log "optional fields". Optional fields are those SIP header fields (or field components) that are not mandatory (see Section 8.1 for the mandatory field list). Optional fields may contain SIP headers or other elements present in a SIP message (for example, the Reason-Phrase element from the Status-Line production rule in RFC 3261 [RFC3261]). Optional fields may also contain additional information that a particular vendor desires to log. The specific syntax and semantics to be accorded to optional fields MUST be defined by the specific representation format used to generate the SIP CLF record.
情報モデルは、「オプションフィールド」をログに記録する機能を提供することにより、拡張性をサポートします。オプションのフィールドは、必須ではないSIPヘッダーフィールド（またはフィールドコンポーネント）です（必須フィールドのリストについては、セクション8.1を参照）。オプションのフィールドには、SIPヘッダーまたはSIPメッセージに存在するその他の要素（たとえば、RFC 3261 [RFC3261]のStatus-LineプロダクションルールのReason-Phrase要素）を含めることができます。オプションのフィールドには、特定のベンダーがログに記録したい追加情報が含まれる場合もあります。オプションのフィールドに対応する特定の構文とセマンティクスは、SIP CLFレコードの生成に使用される特定の表現形式によって定義する必要があります。
The following SIP CLF fields are defined as the minimal information that MUST appear in any SIP CLF record:
次のSIP CLFフィールドは、SIP CLFレコードに表示する必要がある最小限の情報として定義されています。
Timestamp: Date and time of the request or response represented as the number of seconds and milliseconds since the Unix epoch.
タイムスタンプ：Unixエポックからの秒数とミリ秒数で表されるリクエストまたはレスポンスの日時。
Message type: An indicator of whether the SIP message is a request or a response. The allowable values for this field are 'R' (for Request) and 'r' (for response).
メッセージタイプ：SIPメッセージが要求であるか応答であるかを示すインジケータ。このフィールドに使用できる値は、 'R'（要求の場合）および 'r'（応答の場合）です。
Directionality: An indicator of whether the SIP message is received by the SIP entity or sent by the SIP entity. The allowable values for this field are 's' (for message sent) and 'r' (for message received).
方向性：SIPメッセージがSIPエンティティによって受信されるか、SIPエンティティによって送信されるかを示すインジケータ。このフィールドに使用できる値は、 's'（メッセージ送信の場合）および 'r'（メッセージ受信の場合）です。
Transport: The transport over which a SIP message is sent or received. The allowable values for the transport are governed by the "transport" production rule in Section 25.1 of RFC 3261 [RFC3261].
トランスポート：SIPメッセージが送信または受信されるトランスポート。トランスポートの許容値は、RFC 3261 [RFC3261]のセクション25.1の「トランスポート」プロダクションルールによって管理されます。
Source-address: The IPv4 or IPv6 address of the sender of the SIP message.
送信元アドレス：SIPメッセージの送信者のIPv4またはIPv6アドレス。
Source-port: The source port number of the sender of the SIP message.
送信元ポート：SIPメッセージの送信者の送信元ポート番号。
Destination-address: The IPv4 or IPv6 address of the recipient of the SIP message.
宛先アドレス：SIPメッセージの受信者のIPv4またはIPv6アドレス。
Destination-port: The port number of the recipient of the SIP message.
Destination-port：SIPメッセージの受信者のポート番号。
From: The From URI. For the sake of brevity, URI parameters should not be logged.
From：From URI。簡潔にするために、URIパラメータはログに記録しないでください。
From tag: The tag parameter of the From header.
Fromタグ：Fromヘッダーのタグパラメータ。
To: The To URI. For the sake of brevity, URI parameters should not be logged.
To：To URI。簡潔にするために、URIパラメータはログに記録しないでください。
To tag: The tag parameter of the To header. Note that the tag parameter will be absent in the initial request that forms a dialog.
Toタグ：Toヘッダーのtagパラメータ。ダイアログを形成する最初のリクエストでは、タグパラメータは存在しないことに注意してください。
Callid: The Call-ID.
Callid：Call-ID。
CSeq-Method: The method from the CSeq header.
CSeq-Method：CSeqヘッダーのメソッド。
CSeq-Number: The number from the CSeq header.
CSeq-Number：CSeqヘッダーからの番号。
R-URI: The Request-URI, including any URI parameters.
R-URI：URIパラメータを含むRequest-URI。
Status: The SIP response status code.
ステータス：SIP応答ステータスコード。
SIP proxies may fork, creating several client transactions that correlate to a single server transaction. Responses arriving on these client transactions or new requests (CANCEL, ACK) sent on the client transaction need log file entries that correlate with a server transaction. Similarly, a B2BUA may create one or more client transactions in response to an incoming request. These transactions will require correlation as well. The last two information model elements provide this correlation.
SIPプロキシが分岐し、単一のサーバートランザクションに関連するいくつかのクライアントトランザクションを作成する場合があります。これらのクライアントトランザクションに到着する応答、またはクライアントトランザクションで送信される新しい要求（CANCEL、ACK）には、サーバートランザクションと相関するログファイルエントリが必要です。同様に、B2BUAは着信要求に応答して1つ以上のクライアントトランザクションを作成できます。これらのトランザクションには、相関関係も必要です。最後の2つの情報モデル要素は、この相関関係を提供します。
Server-Txn: Server transaction identification code - the transaction identifier associated with the server transaction. Implementations can reuse the server transaction identifier (the topmost branch-id of the incoming request, with or without the magic cookie), or they could generate a unique identification string for a server transaction (this identifier needs to be locally unique to the server only). This identifier is used to correlate ACKs and CANCELs to an INVITE transaction; it is also used to aid in forking as explained later in this section. (See Section 9 for usage.)
Server-Txn：サーバートランザクション識別コード-サーバートランザクションに関連付けられたトランザクション識別子。実装では、サーバートランザクション識別子（マジックCookieの有無にかかわらず、着信要求の最上位のブランチID）を再利用できます。また、サーバートランザクションの一意の識別文字列を生成することもできます（この識別子は、ローカルでサーバーにのみ一意である必要があります） ）。この識別子は、ACKとCANCELをINVITEトランザクションに関連付けるために使用されます。また、このセクションで後述するように、フォークを支援するためにも使用されます。 （使用方法については、セクション9を参照してください。）
Client-Txn: Client transaction identification code - this field is used to associate client transactions with a server transaction for forking proxies or B2BUAs. Upon forking, implementations can reuse the value they inserted into the topmost Via header's branch parameter, or they can generate a unique identification string for the client transaction. (See Section 9 for usage.)
Client-Txn：クライアントトランザクション識別コード-このフィールドは、クライアントトランザクションを、forkプロキシまたはB2BUAのサーバートランザクションに関連付けるために使用されます。フォークすると、実装は最上位のViaヘッダーのブランチパラメーターに挿入した値を再利用するか、クライアントトランザクションの一意の識別文字列を生成できます。 （使用方法については、セクション9を参照してください。）
This information model applies to all SIP entities --- a UAC, UAS,
proxy, B2BUA, registrar, and redirect server. The SIP CLF fields
prescribed for a proxy are equally applicable to the B2BUA.
Similarly, the SIP CLF fields prescribed for a UAS are equally
applicable to registrars and redirect servers.
The next section specifies the individual SIP CLF information model elements that form a log record for specific instances of a SIP entity. It is understood that a SIP CLF record is extensible using extension mechanisms appropriate to the specific representation used to generate the SIP CLF record. This document, however, does not prescribe a specific representation format, and it limits the discussion to the mandatory data elements described above.
次のセクションでは、SIPエンティティの特定のインスタンスのログレコードを形成する個々のSIP CLF情報モデル要素を指定します。 SIP CLFレコードは、SIP CLFレコードの生成に使用される特定の表現に適した拡張メカニズムを使用して拡張可能であることが理解されます。ただし、このドキュメントでは特定の表現形式を規定しておらず、前述の必須データ要素に限定して説明しています。
Each SIP CLF record must contain all the mandatory information model elements outlined in Section 8.1. This document does not specify a representation of a logging format; it is expected that other documents will do so.
各SIP CLFレコードには、セクション8.1で概説されているすべての必須情報モデル要素が含まれている必要があります。このドキュメントでは、ログ形式の表現を指定していません。他のドキュメントがそうすることが期待されます。
An element may not always have an appropriate value to provide for one of these fields, for example, the R-URI field is not applicable when logging a response, the Status field is not applicable when logging a request, the To tag is not known when a request is first sent out, etc. As all the mandatory fields are required to appear in the SIP CLF record, the representation document MUST define how to indicate a field that is not applicable in the context that the SIP CLF record was generated. Similarly, to handle parsing errors in a field, the representation document MUST define a means to indicate that a field cannot be parsed.
要素には、これらのフィールドの1つを提供するための適切な値が常にあるとは限りません。たとえば、R-URIフィールドは、応答のログには適用されません。Statusフィールドは、要求のログには適用されません。Toタグは不明です。リクエストが最初に送信されるときなど。すべての必須フィールドはSIP CLFレコードに表示される必要があるため、表現ドキュメントは、SIP CLFレコードが生成されたコンテキストで適用できないフィールドを示す方法を定義する必要があります。同様に、フィールドの解析エラーを処理するには、表現ドキュメントはフィールドを解析できないことを示す手段を定義しなければなりません（MUST）。
The Client-Txn field is always applicable to a UAC. The Server-Txn field does not apply to a UAC unless the element is also acting as a UAS, and the message associated to this log record corresponds to a message handled by that UAS. For instance, a proxy forwarding a request will populate both the Client-Txn and Server-Txn fields in the record corresponding to the forwarded request.
Client-Txnフィールドは常にUACに適用されます。要素がUASとしても機能しており、このログレコードに関連付けられているメッセージがそのUASによって処理されるメッセージに対応している場合を除き、Server-TxnフィールドはUACに適用されません。たとえば、リクエストを転送するプロキシは、転送されたリクエストに対応するレコードにClient-TxnフィールドとServer-Txnフィールドの両方を入力します。
The Server-Txn field is always applicable to a UAS. The Client-Txn field does not apply to a UAS unless the element is also acting as a UAC, and the message associated to this log record corresponds to a message handled by that UAC. For instance, a proxy forwarding a response will populate both the Server-Txn and Client-Txn fields in the record corresponding to the forwarded response. However, a proxy would only populate the Client-Txn field when creating a log record corresponding to a request.
Server-Txnフィールドは常にUASに適用されます。要素がUACとしても機能しており、このログレコードに関連付けられているメッセージがそのUACによって処理されるメッセージに対応している場合を除き、Client-TxnフィールドはUASに適用されません。たとえば、応答を転送するプロキシは、転送された応答に対応するレコードのServer-TxnフィールドとClient-Txnフィールドの両方を設定します。ただし、プロキシは、リクエストに対応するログレコードを作成するときにのみClient-Txnフィールドに入力します。
The examples use only the mandatory data elements defined in Section 8.1. Extension elements are not considered and neither are SIP bodies. When a given mandatory field is not applicable to a SIP entity, we use the horizontal dash ("-") to represent it.
例では、セクション8.1で定義された必須のデータ要素のみを使用しています。拡張要素は考慮されず、SIP本体も考慮されません。特定の必須フィールドがSIPエンティティに適用できない場合、水平ダッシュ（ "-"）を使用してそれを表します。
There are five principals in the examples below. They are the following: Alice, the initiator of requests. Alice's user agent uses IPv4 address 198.51.100.1, port 5060. P1 is a proxy that Alice's request traverse on their way to Bob, the recipient of the requests. P1 also acts as a registrar to Alice. P1 uses an IPv4 address of 198.51.100.10, port 5060. Bob has two instances of his user agent running on different hosts. The first instance uses an IPv4 address of 203.0.113.1, port 5060 and the second instance uses an IPv6 address of 2001:db8::9, port 5060. P2 is a proxy responsible for Bob's domain. Table 1 summarizes these addresses.
以下の例には5つのプリンシパルがあります。それらは次のとおりです。アリス、要求の開始者。アリスのユーザーエージェントは、IPv4アドレス198.51.100.1、ポート5060を使用します。P1は、アリスの要求が、要求の受信者であるボブに向かう途中で通過するプロキシです。 P1は、アリスのレジストラとしても機能します。 P1は198.51.100.10、ポート5060のIPv4アドレスを使用します。ボブは自分のユーザーエージェントの2つのインスタンスを異なるホストで実行しています。最初のインスタンスはIPv4アドレス203.0.113.1、ポート5060を使用し、2番目のインスタンスはIPv6アドレス2001：db8 :: 9、ポート5060を使用します。P2はボブのドメインを担当するプロキシです。表1に、これらのアドレスを要約します。
+-------------------+--------------------+-------------------+
| Principal | IP:port | Host/Domain name |
+-------------------+--------------------+-------------------+
| Alice | 198.51.100.1:5060 | alice.example.com |
| P1 | 198.51.100.10:5060 | p1.example.com |
| P2 | 203.0.113.200:5060 | p2.example.net |
| Bob UA instance 1 | 203.0.113.1:5060 | bob1.example.net |
| Bob UA instance 2 | [2001:db8::9]:5060 | bob2.example.net |
+-------------------+--------------------+-------------------+
Principal to IP Address Assignment
プリンシパルからIPアドレスへの割り当て
Table 1
表1
Illustrative examples of SIP CLF follow.
SIP CLFの例を以下に示します。
Alice sends a registration registrar P1 and receives a 2xx-class response. The register requests causes Alice's UAC to produce a log record shown below.
アリスは登録レジストラP1を送信し、2xxクラスの応答を受信します。登録要求により、アリスのUACは以下に示すログレコードを生成します。
Timestamp: 1275930743.699
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 1
CSeq-Method: REGISTER
R-URI: sip:example.com
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:example.com
To tag: -
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f81-d4-f6@example.com
Status: -
Server-Txn: -
Client-Txn: c-tr-1
After some time, Alice's UAC will receive a response from the registrar. The response causes Alice's agent to produce a log record shown below.
しばらくすると、アリスのUACはレジストラから応答を受け取ります。この応答により、Aliceのエージェントは以下に示すログレコードを生成します。
Timestamp: 1275930744.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 1
CSeq-Method: REGISTER
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:example.com
To tag: reg-1-xtr
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f81-d4-f6@example.com
Status: 100
Server-Txn: -
Client-Txn: c-tr-1
In this example, Alice sends a session initiation request directly to Bob's agent (instance 1). Bob's agent accepts the session invitation. We first present the SIP CLF logging from the vantage point of Alice's UAC. In line 1, Alice's user agent sends out the INVITE. Shortly, it receives a "180 Ringing" (line 2), followed by a "200 OK" response (line 3). Upon the receipt of the 2xx-class response, Alice's user agent sends out an ACK request (line 4).
この例では、アリスはセッション開始要求をボブのエージェント（インスタンス1）に直接送信します。ボブのエージェントがセッションへの招待を受け入れます。まず、アリスのUACから見たSIP CLFロギングを紹介します。 1行目では、AliceのユーザーエージェントがINVITEを送信します。まもなく、「180 Ringing」（行2）を受信し、「200 OK」応答（行3）が続きます。 2xxクラスの応答を受信すると、AliceのユーザーエージェントはACK要求を送信します（4行目）。
Timestamp: 1275930743.699
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 32
CSeq-Method: INVITE
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@bob1.example.net
To tag: -
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: -
Server-Txn: -
Client-Txn: c-1-xt6
Timestamp: 1275930745.002
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 32
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b-in6-iu
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: 180
Server-Txn: -
Client-Txn: c-1-xt6
Timestamp: 1275930746.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 32
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b-in6-iu
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: 200
Server-Txn: -
Client-Txn: c-1-xt6
Timestamp: 1275930746.120
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 32
CSeq-Method: ACK
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: b-in6-iu
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: -
Server-Txn: -
Client-Txn: c-1-xt6
In this example, Alice sends a session invitation request to Bob through proxy P1, which inserts a Record-Route header causing subsequent requests between Alice and Bob to traverse the proxy. The SIP CLF log records appears from the vantage point of P1. The line numbers below refer to Figure 1.
この例では、アリスはプロキシP1を介してセッション招待リクエストをボブに送信します。プロキシP1はRecord-Routeヘッダーを挿入して、アリスとボブの間の後続のリクエストがプロキシを通過するようにします。 SIP CLFログレコードは、P1の視点から表示されます。以下の行番号は、図1を参照しています。
Alice P1 Bob
+---INV--------->| | Line 1
| | |
|<---------100---+ | Line 2
| | |
| +---INV-------->| Line 3
| | |
| |<--------100---+ Line 4
| | |
| |<--------180---+ Line 5
| | |
|<---------180---+ | Line 6
| | |
| |<--------200---+ Line 7
| | |
|<---------200---+ | Line 8
| | |
+---ACK--------->| | Line 9
| | |
| |---ACK-------->| Line 10
Figure 1: Simple Proxy-Aided Call Flow
図1：単純なプロキシ支援コールフロー
1 Timestamp: 1275930743.699
Message Type: R
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@example.net
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: -
Note that, at this point, P1 has created a server transaction identification code and populated the SIP CLF field Server-Txn with it. P1 has not yet created a client transaction identification code; thus, Client-Txn contains a "-".
この時点で、P1がサーバートランザクション識別コードを作成し、SIP CLFフィールドServer-Txnに入力したことに注意してください。 P1はまだクライアントトランザクション識別コードを作成していません。したがって、Client-Txnには「-」が含まれます。
2 Timestamp: 1275930744.001
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 100
Server-Txn: s-x-tr
Client-Txn: -
In line 3 below, P1 has created a client transaction identification code for the downstream branch and populated the SIP CLF field Client-Txn.
以下の3行目で、P1はダウンストリームブランチのクライアントトランザクション識別コードを作成し、SIP CLFフィールドClient-Txnに入力しました。
3 Timestamp: 1275930744.998
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: c-x-tr
4 Timestamp: 1275930745.200
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 100
Server-Txn: s-x-tr
Client-Txn: c-x-tr
5 Timestamp: 1275930745.800
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 180
Server-Txn: s-x-tr
Client-Txn: c-x-tr
6 Timestamp: 1275930746.009
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 180
Server-Txn: s-x-tr
Client-Txn: c-x-tr
7 Timestamp: 1275930747.120
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 200
Server-Txn: s-x-tr
Client-Txn: c-x-tr
8 Timestamp: 1275930747.300
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 200
Server-Txn: s-x-tr
Client-Txn: c-x-tr
9 Timestamp: 1275930749.100
Message Type: R
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: ACK
R-URI: sip:bob@example.net
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: c-x-tr
10 Timestamp: 1275930749.100
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: ACK
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: c-x-tr
In this example, Alice sends a session invitation to Bob's proxy, P2. P2 forks the session invitation request to two registered endpoints corresponding to Bob's address-of-record. Both endpoints respond with provisional responses. Shortly thereafter, one of Bob's user agent instances accepts the call, causing P2 to send a CANCEL request to the second user agent. P2 does not Record-Route; therefore, the subsequent ACK request from Alice to Bob's user agent does not traverse through P2 (and is not shown below).
この例では、アリスがセッション招待をボブのプロキシP2に送信します。 P2は、Bobのレコードのアドレスに対応する2つの登録済みエンドポイントにセッション招待リクエストをフォークします。両方のエンドポイントが暫定応答で応答します。その後まもなく、ボブのユーザーエージェントインスタンスの1つが呼び出しを受け入れ、P2がCANCELリクエストを2番目のユーザーエージェントに送信します。 P2はRecord-Routeを行いません。したがって、アリスからボブのユーザーエージェントへの後続のACK要求は、P2を通過しません（以下には表示されません）。
Figure 2 depicts the call flow.
Bob Bob
Alice P2 (Instance 1) (Instance 2)
+---INV--->| | | Line 1
| | | |
|<---100---+ | | Line 2
| | | |
| +---INV--->| | Line 3
| | | |
| +---INV----+-------->| Line 4
| | | |
| |<---100---+ | Line 5
| | | |
| |<---------+---100---+ Line 6
| | | |
| |<---180---+---------+ Line 7
| | | |
|<---180---+ | | Line 8
| | | |
| |<---180---+ | Line 9
| | | |
|<---180---+ | | Line 10
| | | |
| |<---200---+ | Line 11
| | | |
|<---200---+ | | Line 12
| | | |
| +---CANCEL-+-------->| Line 13
| | | |
| |<---------+---487---+ Line 14
| | | |
| +---ACK----+-------->| Line 15
| | | |
| |<---------+---200---+ Line 16
Figure 2: Forked Call Flow
図2：分岐したコールフロー
The SIP CLF log appears from the vantage point of P2. The fields logged are shown below; the line numbers refer to Figure 2.
SIP CLFログは、P2の視点から表示されます。ログに記録されるフィールドを以下に示します。行番号は図2を参照してください。
1 Timestamp: 1275930743.699
Message Type: R
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@example.net
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: -
2 Timestamp: 1275930744.001
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 100
Server-Txn: s-1-tr
Client-Txn: -
3 Timestamp: 1275930744.998
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-1-tr
4 Timestamp: 1275930745.500
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@bob2.example.net
Destination-address: [2001:db8::9]
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-2-tr
5 Timestamp: 1275930745.800
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1=-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com 100
Status: 100
Server-Txn: s-1-tr
Client-Txn: c-1-tr
6 Timestamp: 1275930746.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 100
Server-Txn: s-1-tr
Client-Txn: c-2-tr
7 Timestamp: 1275930746.700
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-2-tr
8 Timestamp: 1275930746.990
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-2-tr
9 Timestamp: 1275930747.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com 100
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-1-tr
10 Timestamp: 1275930747.300
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-2-tr
11 Timestamp: 1275930747.800
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com 100
Status: 200
Server-Txn: s-1-tr
Client-Txn: c-1-tr
12 Timestamp: 1275930748.000
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 200
Server-Txn: s-1-tr
Client-Txn: c-1-tr
13 Timestamp: 1275930748.201
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: CANCEL
R-URI: sip:bob@bob2.example.net
Destination-address: [2001:db8::9]
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-2-tr
14 Timestamp: 1275930748.300
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 487
Server-Txn: s-1-tr
Client-Txn: c-2-tr
15 Timestamp: 1275930748.355
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: ACK
R-URI: sip:bob@bob2.example.net
Destination-address: [2001:db8::9]
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-2-tr
16 Timestamp: 1275930748.698
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: CANCEL
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 200
Server-Txn: s-1-tr
Client-Txn: c-2-tr
The above SIP CLF log makes it easy to search for a specific transaction or a state of the session. Searching for the string "c-1-tr" on the log records will readily yield the information that an INVITE was sent to sip:bob@bob1.example.com, it elicited a 100 followed by a 180 and then a 200. Because the ACK request in this case would be exchanged end-to-end, this element does not see (and therefore will not log) the ACK.
上記のSIP CLFログを使用すると、特定のトランザクションまたはセッションの状態を簡単に検索できます。ログレコードで文字列「c-1-tr」を検索すると、INVITEがsip：bob@bob1.example.comに送信されたという情報がすぐに得られ、100の後に180が続き、次に200が続きます。この場合のACK要求はエンドツーエンドで交換され、この要素はACKを認識しません（したがって、ログに記録しません）。
Searching for "c-2-tr" yields a more complex scenario of sending an INVITE to sip:bob@bob2.example.net, receiving 100 and 180. However, the log makes it apparent that the request to sip:bob@bob2.example.net was subsequently CANCEL'ed before a final response was generated, and that the pending INVITE returned a 487. The ACK to the final non-2xx response and a 200 to the CANCEL request complete the exchange on that branch.
「c-2-tr」を検索すると、INVITEをsip：bob@bob2.example.netに送信し、100と180を受信するという、より複雑なシナリオが生成されます。ただし、ログから、sip：bob @ bob2へのリクエストが.example.netはその後、最終的な応答が生成される前にCANCELされ、保留中のINVITEが487を返しました。最後の非2xx応答に対するACKおよびCANCEL要求に対する200は、そのブランチでの交換を完了します。
A log file by its nature reveals both the state of the entity producing it and the nature of the information being logged. To the extent that this state should not be publicly accessible and that the information is to be considered private, appropriate file and directory permissions attached to the log file SHOULD be used. It is outside the scope of this document to specify how to protect the log file while it is stored on disk; however, certain precautions can be taken. Operators SHOULD consider using common administrative features such as disk encryption and securing log files [schneier-1]. Operators SHOULD also consider hardening the machine on which the log file is stored by restricting physical access to the host as well as restricting access to the file itself. Depending on the specific operating system and environment, the file and directory permissions SHOULD be set to be most restrictive such that the file is not publicly readable and writable and the directory where the file is stored is not publicly accessible.
ログファイルはその性質から、それを生成するエンティティの状態とログに記録される情報の性質の両方を明らかにします。この状態が公にアクセス可能であってはならず、情報が非公開であると見なされる範囲で、ログファイルに添付された適切なファイルおよびディレクトリのアクセス許可を使用する必要があります（SHOULD）。ディスクに保存されているログファイルを保護する方法を指定することは、このドキュメントの範囲外です。ただし、特定の予防策を講じることができます。オペレーターは、ディスクの暗号化やログファイルの保護など、一般的な管理機能の使用を検討する必要があります[schneier-1]。オペレーターは、ホストへの物理アクセスを制限するだけでなく、ファイル自体へのアクセスを制限することによって、ログファイルが保存されているマシンを強化することも検討する必要があります。特定のオペレーティングシステムと環境に応じて、ファイルとディレクトリのアクセス許可は、ファイルがパブリックに読み取りおよび書き込み可能ではなく、ファイルが格納されているディレクトリにパブリックにアクセスできないように、最も制限的に設定する必要があります。
The following threats may be considered for the log file while it is stored:
ログファイルが保存されている間、次の脅威が考慮される可能性があります。
o An attacker may gain access to view the log file, or may surreptitiously make a copy of the log file for later viewing.
o 攻撃者は、ログファイルを表示するためのアクセス権を取得したり、後で表示するためにログファイルのコピーを不正に作成したりする可能性があります。
o An attacker who is unable to eavesdrop on real-time SIP traffic on the network, but, nonetheless, can access the log file, is able to easily mount replay attack or other attacks that result from channel eavesdropping. Encrypting SIP traffic does not help here because the SIP entity generating the log file would have decrypted the message for processing and subsequent logging.
o ネットワーク上のリアルタイムのSIPトラフィックを盗聴することはできないが、それでもログファイルにアクセスできる攻撃者は、チャネルの盗聴に起因するリプレイ攻撃やその他の攻撃を簡単に仕掛けることができます。ログファイルを生成するSIPエンティティは、処理とその後のログ記録のためにメッセージを復号化するため、SIPトラフィックの暗号化はここでは役に立ちません。
o An attacker may delete parts of --- or indeed, the whole --- file.
o 攻撃者は---ファイルの一部、または実際には---ファイル全体を削除する可能性があります。
Public access to the SIP log file creates more of a privacy leak when compared to an adversary eavesdropping cleartext SIP traffic on the network. If all SIP traffic on a network segment is encrypted, then as noted above, special attention must be directed to the file and directory permissions associated with the log file to preserve privacy such that only a privileged user can access the contents of the log file.
SIPログファイルへのパブリックアクセスは、ネットワーク上での攻撃者による盗聴されたクリアテキストSIPトラフィックと比較すると、プライバシーリークをさらに引き起こします。ネットワークセグメント上のすべてのSIPトラフィックが暗号化されている場合は、前述のように、特権ユーザーだけがログファイルの内容にアクセスできるようにプライバシーを保護するために、ログファイルに関連付けられたファイルとディレクトリの権限に特別な注意を向ける必要があります。
Transporting SIP CLF files across the network pose special challenges as well. The following threats may be considered for transferring log files or while transferring individual log records:
ネットワークを介してSIP CLFファイルを転送するには、特別な課題もあります。次の脅威は、ログファイルを転送する場合、または個々のログレコードを転送する場合に考慮される可能性があります。
o An attacker may view the records;
o 攻撃者はレコードを表示する可能性があります。
o An attacker may modify the records in transit or insert previously captured records into the stream;
o 攻撃者は、送信中のレコードを変更したり、以前にキャプチャしたレコードをストリームに挿入したりできます。
o An attacker may remove records in transit, or may stage a man-in-the-middle attack to deliver a partially or entirely falsified log file.
o 攻撃者は、転送中にレコードを削除するか、中間者攻撃を仕掛けて、部分的または全体的に改ざんされたログファイルを配信する可能性があります。
It is also outside the scope of this document to specify protection methods for log files or log records that are being transferred between hosts; however, certain precautions can be taken. Operators SHOULD require mutual authentication, channel confidentiality, and channel integrity while transferring the log file. The use of a secure shell transport layer protocol [RFC4253] or TLS [RFC5246] accomplishes this.
ホスト間で転送されるログファイルまたはログレコードの保護方法を指定することも、このドキュメントの範囲外です。ただし、特定の予防策を講じることができます。オペレーターは、ログファイルの転送中に相互認証、チャネルの機密性、チャネルの整合性を要求する必要があります（SHOULD）。セキュアシェルトランスポート層プロトコル[RFC4253]またはTLS [RFC5246]を使用すると、これを実現できます。
Even with such care, sensitive information can be leaked during or after the transfer. SIP CLF fields like IP addresses and URIs contain potentially sensitive information. Before transferring the log file across domains, operators SHOULD ensure that any fields that contain sensitive information are appropriately anonymized or obfuscated. A specification for a format that describes which fields are obfuscated and with what characteristics (e.g., what correlations still work) is needed to allow interoperable but privacy-friendly exchange of SIP CLF between administrative domains. Such a specification is not attempted here, but is for further study.
このような注意を払っても、転送中または転送後に機密情報が漏洩する可能性があります。 IPアドレスやURIなどのSIP CLFフィールドには、機密情報が含まれる可能性があります。ドメイン間でログファイルを転送する前に、オペレーターは機密情報を含むすべてのフィールドが適切に匿名化または難読化されていることを確認する必要があります。管理ドメイン間でのSIP CLFの相互運用可能だがプライバシーに配慮した交換を可能にするには、難読化されるフィールドと、どの特性（どの相関がまだ機能するかなど）を記述するフォーマットの仕様が必要です。そのような仕様はここでは試みられていませんが、さらなる研究のためです。
The SIP CLF represents the minimum fields that lend themselves to trend analysis and serve as information that may be deemed useful. Other formats can be defined that include more headers (and the body) from Section 8.1. However, where to draw a judicial line regarding the inclusion of non-mandatory headers can be challenging. Clearly, the more information a SIP entity logs, the longer time the logging process will take, the more disk space the log entry will consume, and the more potentially sensitive information could be breached. Therefore, adequate trade-offs should be taken in account when logging more fields than the ones recommended in Section 8.1.
SIP CLFは、傾向分析に役立つ最小限のフィールドを表し、役立つと思われる情報として機能します。セクション8.1から、より多くのヘッダー（および本文）を含む他のフォーマットを定義できます。ただし、必須ではないヘッダーを含めることに関して司法上の境界線をどこに引くかは、困難な場合があります。明らかに、SIPエンティティがログに記録する情報が多いほど、ログプロセスにかかる時間が長くなり、ログエントリが消費するディスク領域が増え、機密情報が漏洩する可能性が高くなります。したがって、セクション8.1で推奨されているフィールドよりも多くのフィールドをログに記録する場合は、適切なトレードオフを考慮する必要があります。
Implementers need to pay particular attention to buffer handling when reading or writing log files. SIP CLF entries can be unbounded in length. It would be reasonable for a full dump of a SIP message to be thousands of octets long. This is of particular importance to CLF log parsers, as a SIP CLF log writers may add one or more extension fields to the message to be logged.
実装者は、ログファイルを読み書きするときのバッファ処理に特に注意する必要があります。 SIP CLFエントリの長さは無制限にすることができます。 SIPメッセージの完全なダンプが数千オクテットの長さであることが妥当です。これは、CLFログパーサーにとって特に重要です。SIPCLFログライターは、ログに記録されるメッセージに1つ以上の拡張フィールドを追加する場合があるためです。
SIP CLF log files will take up a substantial amount of disk space depending on traffic volume at a processing entity and the amount of information being logged. As such, any organization using SIP CLF should establish operational procedures for file rollovers and periodic retrieval of logs before rollover as appropriate to the needs of the organization.
SIP CLFログファイルは、処理エンティティのトラフィック量とログに記録される情報の量に応じて、かなりの量のディスク領域を占有します。そのため、SIP CLFを使用する組織は、組織のニーズに応じて、ファイルのロールオーバーの操作手順と、ロールオーバー前のログの定期的な取得を確立する必要があります。
Listing such operational guidelines in this document is out of scope for this work.
このような運用ガイドラインをこのドキュメントに記載することは、この作業の範囲外です。
Members of the sipping, dispatch, ipfix, and syslog working groups provided invaluable input to the formulation of the document. These include Benoit Claise, Spencer Dawkins, John Elwell, David Harrington, Christer Holmberg, Hadriel Kaplan, Atsushi Kobayashi, Jiri Kuthan, Scott Lawrence, Chris Lonvick, Peter Musgrave, Simon Perreault, Adam Roach, Dan Romascanu, Robert Sparks, Brian Trammell, Dale Worley, Theo Zourzouvillys, and others that we have undoubtedly, but inadvertently, missed.
sipping、dispatch、ipfix、syslogワーキンググループのメンバーは、ドキュメントの作成に非常に貴重な情報を提供しました。これらには、ブノワ・クレイズ、スペンサー・ドーキンス、ジョン・エルウェル、デビッド・ハリントン、クリスター・ホルムバーグ、ハドリエル・カプラン、小林淳、ジリ・クサン、スコット・ローレンス、クリス・ロンヴィック、ピーター・マスグレイブ、サイモン・ペロー、アダム・ローチ、ダン・ローマスカヌ、ロバート・スパークス、ブライアン・トラメル、 Dale Worley、Theo Zourzouvillys、そして私たちが間違いなく、うっかりして見逃してしまったその他の人々。
Rainer Gerhards, David Harrington, Cullen Jennings, and Gonzalo Salgueiro helped tremendously in discussions related to arriving at the beginnings of an information model.
Rainer Gerhards、David Harrington、Cullen Jennings、およびGonzalo Salgueiroは、情報モデルの最初にたどり着くまでの議論を大いに助けました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）Transport Layer Protocol」、RFC 4253、2006年1月。
[RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B。、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards、R。、「Syslogプロトコル」、RFC 5424、2009年3月。
[RFC6873] Salgueiro, G., Gurbani, V., and A. B. Roach, "Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)", RFC 6873, February 2013.
[RFC6873] Salgueiro、G.、Gurbani、V。、およびA. B. Roach、「Session Initiation Protocol（SIP）Common Log Format（CLF）」のフォーマット、RFC 6873、2013年2月。
[rieck2008] Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. Muller, "A Self-learning System for Detection of Anomalous SIP Messages", Principles, Systems and Applications of IP Telecommunications Services and Security for Next Generation Networks (IPTComm), LNCS 5310, pp. 90-106, 2008.
[rieck2008] Rieck、K.、Wahl、S.、Laskov、P.、Domschitz、P。、およびK-R。 Muller、「異常なSIPメッセージを検出するための自己学習システム」、IP通信サービスの原理、システムおよびアプリケーションと次世代ネットワーク（IPTComm）のセキュリティ、LNCS 5310、pp。90-106、2008。
[schneier-1] Schneier, B. and J. Kelsey, "Secure audit logs to support computer forensics", ACM Transactions on Information and System Security (TISSEC), 2(2), pp. 159,176, May 1999.
[schneier-1] Schneier、B.およびJ. Kelsey、「コンピューターフォレンジックをサポートするための安全な監査ログ」、ACM Transactions on Information and System Security（TISSEC）、2（2）、pp。159、176、1999年5月。
Authors' Addresses
著者のアドレス
Vijay K. Gurbani (editor) Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane Naperville, IL 60566 USA
Vijay K. Gurbani（編集者）Bell Laboratories、アルカテル-ルーセント1960 Lucent Lane Naperville、IL 60566 USA
EMail: vkg@bell-labs.com
Eric W. Burger (editor) Georgetown University USA
エリックW.バーガー（編集者）ジョージタウン大学アメリカ合衆国
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
Tricha Anjali Illinois Institute of Technology 316 Siegel Hall Chicago, IL 60616 USA
Tricha Anjali Illinois Institute of Technology 316 Siegel Hall Chicago、IL 60616 USA
EMail: tricha@ece.iit.edu
Humberto Abdelnur INRIA INRIA - Nancy Grant Est Campus Scientifique 54506, Vandoeuvre-les-Nancy Cedex France
Humberto Abdelnur INRIA INRIA-ナンシーグラントエストキャンパスサイエンティフィック54506、ヴァンドゥーヴルレナンシーセデックスフランス
EMail: humbol@gmail.com
Olivier Festor INRIA INRIA - Nancy Grant Est Campus Scientifique 54506, Vandoeuvre-les-Nancy Cedex France
Olivier Festor INRIA INRIA-ナンシーグラントイーストサイエンティフィックキャンパス54506、ヴァンドゥーヴルレナンシーセデックスフランス
EMail: Olivier.Festor@loria.fr