[要約] RFC 6873は、SIP Common Log Format（CLF）のフォーマットに関するものです。このRFCの目的は、SIPサーバーのログファイルの一貫性と相互運用性を確保するための標準化です。
Internet Engineering Task Force (IETF) G. Salgueiro
Request for Comments: 6873 Cisco Systems
Category: Standards Track V. Gurbani
ISSN: 2070-1721 Bell Labs, Alcatel-Lucent
A. B. Roach
Mozilla
February 2013
Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)
セッション開始プロトコル（SIP）の共通ログ形式（CLF）の形式
Abstract
概要
The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers. This CLF mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP CLF that retains the key advantages of a text-based format while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record.
SIPCLFワーキンググループは、Session Initiation Protocol（SIP）サーバー用のCommon Log Format（CLF）フレームワークを定義しています。このCLFは、Apacheなどの有名なWebサーバーやSquidなどのWebプロキシで見られる成功したイベントログ形式を模倣しています。このドキュメントでは、テキストベースの形式の主な利点を維持しながら、純粋にテキストベースの実装よりも処理パフォーマンスを大幅に向上させるSIP CLFのインデックス付きテキストエンコーディング形式を提案します。このファイル形式はSIP CLF情報モデルに準拠しており、SIP CLFレコードに表示されるすべての必須フィールドとオプションフィールドに効果的なエンコードスキームを提供します。
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/rfc6873.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6873で入手できます。
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 .....................................................3
3. Document Conventions ............................................4
4. Format ..........................................................5
4.1. Index Pointers .............................................8
4.2. Mandatory Fields ..........................................10
4.3. SIP CLF Encoding and Character Escaping Requirements ......13
4.4. Optional Fields ...........................................14
5. Example SIP CLF Record .........................................22
6. Text Tool Considerations .......................................24
7. Security Considerations ........................................24
8. Operational Guidance ...........................................25
9. IANA Considerations ............................................25
9.1. SIP CLF Version ...........................................25
9.2. SIP CLF Transport Flag ....................................26
10. Acknowledgments ...............................................26
11. References ....................................................27
11.1. Normative References .....................................27
11.2. Informative References ...................................27
The extensive list of benefits and the widespread adoption of the Apache Common Log Format (CLF) has prompted the development of an analogous event logging mechanism for the Session Initiation Protocol (SIP) [RFC3261]. Implementing a logging scheme for SIP is a considerable challenge. In part, this is due to the fact that the behavior of a SIP entity is more complex as compared to an HTTP entity. Additionally, there are shortcomings to the purely text-based HTTP CLF that need to be addressed in order to allow for real-time inspection of SIP log files [RFC6872]. Experience with Apache CLF has shown that dealing with large quantities of log data can be very processor intensive, as doing so necessarily requires reading and parsing every byte in the log file(s) of interest.
利点の広範なリストとApache Common Log Format（CLF）の広範な採用により、Session Initiation Protocol（SIP）[RFC3261]の類似のイベントロギングメカニズムの開発が促進されました。 SIPのロギングスキームを実装することは、大きな課題です。一部には、これは、SIPエンティティの動作がHTTPエンティティと比較して複雑であることによるものです。さらに、SIPログファイルのリアルタイム検査を可能にするために対処する必要がある純粋にテキストベースのHTTP CLFの欠点があります[RFC6872]。 Apache CLFの経験から、大量のログデータを処理するには非常に多くのプロセッサが必要になる可能性があることがわかりました。これを行うには、対象となるログファイルのすべてのバイトを読み取り、解析する必要があるからです。
An implementation-independent framework for the SIP CLF has been defined in [RFC6872]. This memo describes an indexed text file format for logging SIP messages received and sent by SIP clients, servers, and proxies that adheres to the information model presented in Section 8 of [RFC6872]. This document defines a format that is no more difficult to generate by logging entities than standard (i.e., non-indexed) text log formats, while being radically faster to process. In particular, the format is optimized for both rapidly scanning through log records and quickly locating commonly accessed data fields.
SIP CLFの実装に依存しないフレームワークは、[RFC6872]で定義されています。このメモは、[RFC6872]のセクション8に示されている情報モデルに準拠するSIPクライアント、サーバー、プロキシによって送受信されたSIPメッセージをログに記録するためのインデックス付きテキストファイル形式について説明しています。このドキュメントでは、エンティティをログに記録することで生成するのが標準の（つまり、インデックス付けされていない）テキストログ形式よりも難しくない形式を定義していますが、処理は大幅に高速です。特に、このフォーマットは、ログレコードをすばやくスキャンし、一般的にアクセスされるデータフィールドをすばやく見つけるために最適化されています。
Further, the format proposed by this document retains the key advantage of being human readable and able to be processed using the various Unix text processing tools, such as sed, awk, perl, cut, and grep.
さらに、このドキュメントで提案されている形式は、人間が読める形式であり、sed、awk、perl、cut、grepなどのさまざまなUnixテキスト処理ツールを使用して処理できるという主要な利点を保持しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are appropriate when valid exceptions to a general requirement are known to exist or appear to exist, and it is infeasible or impractical to enumerate all of them. However, they should not be interpreted as permitting implementers to fail to implement the general requirement when such failure would result in interoperability failure.
「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、および「NOT RECOMMENDED」は、一般的な要件に対する有効な例外が存在する、または存在すると思われる場合に適切であり、それらをすべて列挙することは実行不可能または非実用的です。ただし、そのような失敗が相互運用性の失敗につながる場合に、実装者が一般的な要件の実装に失敗することを許可すると解釈してはなりません。
[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 reader is expected to be familiar with the terminology and concepts defined in [RFC6872].
読者は、[RFC6872]で定義されている用語と概念に精通していることが求められます。
This document defines the logging syntax for the SIP CLF. This syntax is demonstrated through the use of various examples. The formatting described here does not permit these examples to be unambiguously rendered due to the constraints imposed by the formatting rules for RFCs. To avoid ambiguity and to meet the RFC layout requirements, this document uses the <allOneLine/> markup convention established in [RFC4475].
このドキュメントでは、SIP CLFのロギング構文を定義します。この構文は、さまざまな例を使用して示されています。ここで説明するフォーマットでは、RFCのフォーマットルールによって課せられる制約のため、これらの例を明確にレンダリングすることはできません。あいまいさを回避し、RFCレイアウト要件を満たすために、このドキュメントでは、[RFC4475]で確立された<allOneLine />マークアップ規則を使用します。
For the sake of clarity and completeness, the entire text defining this markup convention from Section 2.1 of [RFC4475] is quoted below:
明確かつ完全にするために、[RFC4475]のセクション2.1のこのマークアップ規則を定義するテキスト全体を以下に引用します。
Several of these examples contain unfolded lines longer than 72 characters. These are captured between <allOneLine/> tags. The single unfolded line is reconstructed by directly concatenating all lines appearing between the tags (discarding any line feeds or carriage returns). There will be no whitespace at the end of lines. Any whitespace appearing at a fold-point will appear at the beginning of a line.
これらの例のいくつかには、72文字を超える展開された行が含まれています。これらは<allOneLine />タグ間でキャプチャされます。タグの間にあるすべての行を直接連結することにより、単一の展開された行が再構築されます（改行またはキャリッジリターンは破棄されます）。行末に空白はありません。折り返し点にある空白は、行の先頭に表示されます。
The following represent the same string of bits:
以下は、同じビット文字列を表しています。
Header-name: first value, reallylongsecondvalue, third value
ヘッダー名：最初の値、reallylongsecondvalue、3番目の値
<allOneLine> Header-name: first value, reallylongsecondvalue , third value </allOneLine>
<allOneLine>ヘッダー名：最初の値、reallylongsecondvalue、3番目の値</ allOneLine>
<allOneLine> Header-name: first value, reallylong second value, third value </allOneLine>
<allOneLine>ヘッダー名：最初の値、実際に長い2番目の値、3番目の値</ allOneLine>
Note that this is NOT SIP header-line folding, where different strings of bits have equivalent meaning.
これはSIPヘッダー行折りたたみではなく、ビットの異なる文字列が同等の意味を持つことに注意してください。
The IP addresses used in the examples in this document correspond to the documentation address block 192.0.2.0/24 (TEST-NET-1) as described in [RFC5737].
このドキュメントの例で使用されているIPアドレスは、[RFC5737]で説明されているドキュメントアドレスブロック192.0.2.0/24（TEST-NET-1）に対応しています。
The CLF for the Session Initiation Protocol [RFC6872] defines an information model to which this logging format adheres, and Section 8.1 of that document defines all the mandatory information model elements.
Session Initiation Protocol [RFC6872]のCLFは、このログ形式が準拠する情報モデルを定義し、そのドキュメントのセクション8.1は、すべての必須の情報モデル要素を定義しています。
This document defines the format of SIP CLF records as follows:
このドキュメントでは、SIP CLFレコードの形式を次のように定義しています。
0 7 8 15 16 23 24 31
+-----------+-----------+-----------+-----------+
| Version | Record Length | 0 - 3
+-----------+-----------+-----------+-----------+
| Record Length (cont) | 0x2C | 4 - 7
+-----------+-----------+-----------+-----------+
| CSeq Pointer (Hex) | 8 - 11
+-----------+-----------+-----------+-----------+
| Response Status-Code Pointer (Hex) | 12 - 15
+-----------+-----------+-----------+-----------+
| R-URI Pointer (Hex) | 16 - 19
+-----------+-----------+-----------+-----------+
| Destination IP address:port Pointer (Hex) | 20 - 23
+-----------+-----------+-----------+-----------+
| Source IP address:port Pointer (Hex) | 24 - 27
+-----------+-----------+-----------+-----------+
| To URI Pointer (Hex) | 28 - 31
+-----------+-----------+-----------+-----------+
| To Tag Pointer (Hex) | 32 - 35
+-----------+-----------+-----------+-----------+
| From URI Pointer (Hex) | 36 - 39
+-----------+-----------+-----------+-----------+
| From Tag Pointer (Hex) | 40 - 43
+-----------+-----------+-----------+-----------+
| Call-Id Pointer (Hex) | 44 - 47
+-----------+-----------+-----------+-----------+
| Server-Txn Pointer (Hex) | 48 - 51
+-----------+-----------+-----------+-----------+
| Client-Txn Pointer (Hex) | 52 - 55
+-----------+-----------+-----------+-----------+
| Optional Fields Start Pointer (Hex) | 56 - 59
+-----------+-----------+-----------+-----------+
| 0x0A | | 60 - 63
+-----------+ +
| Timestamp | 64 - 67
+ +-----------+
| | 0x2E | 68 - 71
+-----------+-----------+-----------+-----------+
| Fractional Seconds | 0x09 | 72 - 75
+-----------+-----------+-----------+-----------+
| Flags Field | 76 - 79
+-----------+-----------+-----------+-----------+
|Flag (cont)| 0x09 | | 80 - 83
|-----------+-----------+ |
| |
| |
| Mandatory Fields (variable length) |
| |
| |
+-----------+-----------+-----------+-----------+
| 0x09 | Tag | 0x40 |\
+-----------+-----------+-----------+-----------+ \
| Vendor-ID | \
+-----------+-----------+-----------+-----------+ \
| Vendor-ID (cont) | \ Repeated
+-----------+-----------+-----------+-----------+ \ as many
| 0x2C | Length (Hex) | > times as
+-----------+-----------+-----------+-----------+ / necessary
| Len (cont)| 0x2C | BEB | 0x2C | /
+-----------+-----------+-----------------------| /
| | /
| Value (variable length) | /
| |/
+-----------+-----------+-----------+-----------+
| 0x0A |
+-----------+
Figure 1: SIP Common Log Format
図1：SIP共通ログ形式
The format presented in Figure 1 is for a single SIP CLF log entry. While there is no actual subdivision in practice, this format can be logically subdivided into the following three distinct components: 1. Index Pointers: The first 60 bytes of this format. This portion is metadata, primarily composed of a list of pointers that indicate the beginning of both the variable-length mandatory and optional fields that are logged as part of this record. These pointers are implemented as a mechanism to improve processing of these records and to allow a reader to expeditiously skip directly to the desired field without unnecessarily going through the entire record. This logical subdivision within the SIP CLF format will be referenced in this document with the <IndexPointers> tag. A 0x0A (LF character) delimits <IndexPointers> from the next logical grouping.
図1に示す形式は、単一のSIP CLFログエントリ用です。実際にはサブディビジョンはありませんが、このフォーマットは論理的に次の3つの異なるコンポーネントに細分できます。1.インデックスポインター：このフォーマットの最初の60バイト。この部分はメタデータであり、主に、このレコードの一部としてログに記録される可変長の必須フィールドとオプションフィールドの両方の開始を示すポインターのリストで構成されています。これらのポインターは、これらのレコードの処理を改善し、リーダーがレコード全体を不必要に経由することなく、目的のフィールドに直接迅速にスキップできるようにするメカニズムとして実装されます。 SIP CLFフォーマット内のこの論理サブディビジョンは、このドキュメントでは<IndexPointers>タグで参照されます。 0x0A（LF文字）は、<IndexPointers>を次の論理グループから区切ります。
2. Mandatory Fields: The next logical grouping in this format is a Tab-delimited (0x09) listing of the mandatory fields as described in Section 8.1 of [RFC6872] and in the order listed in <IndexPointers>. This logical subdivision within the SIP CLF format will be referenced in this document with the <MandatoryFields> tag.
2. 必須フィールド：この形式の次の論理グループは、[RFC6872]のセクション8.1で説明されている必須フィールドのタブ区切り（0x09）リストであり、<IndexPointers>にリストされている順序です。 SIP CLF形式内のこの論理サブディビジョンは、このドキュメントでは<MandatoryFields>タグで参照されます。
3. Optional Fields: The last logical component MAY be present as it is an OPTIONAL extension to the SIP CLF format. Its purpose is to provide flexibility to the developer of this SIP CLF to log any desired fields not included in <MandatoryFields>. This includes SIP bodies and any vendor-specific extensions. This logical subdivision within the SIP CLF format will be referenced in this document with the <OptionalFields> tag.
3. オプションのフィールド：最後の論理コンポーネントは、SIP CLFフォーマットのオプションの拡張であるため、存在する場合があります。その目的は、このSIP CLFの開発者が<MandatoryFields>に含まれていない必要なフィールドをログに記録できるように柔軟性を提供することです。これには、SIP本体とベンダー固有の拡張機能が含まれます。 SIP CLFフォーマット内のこの論理サブディビジョンは、このドキュメントでは<OptionalFields>タグで参照されます。
This logical structure of the SIP CLF record format can be graphically represented as shown in Figure 2 below:
SIP CLFレコードフォーマットのこの論理構造は、下の図2に示すようにグラフィカルに表すことができます。
<IndexPointers>
<MandatoryFields>
<OptionalFields>
Figure 2: Logical Structure of the SIP CLF Record
図2：SIP CLFレコードの論理構造
Note that Figures 1 and 2 plus the terminating line-feed (0x0A) at the end of the SIP CLF record are different representations of the same format but are functionally equivalent. The representation of this format is a two-line record where the <IndexPointers> metadata is on one line and the actual data like <MandatoryFields> and <OptionalFields> (if present) is on another.
図1と図2、およびSIP CLFレコードの末尾の終端改行（0x0A）は、同じ形式の異なる表現ですが、機能的には同じであることに注意してください。この形式の表現は、<IndexPointers>メタデータが1行にあり、<MandatoryFields>や<OptionalFields>（存在する場合）などの実際のデータが別の行にある2行のレコードです。
In the following sections note that indications of "hexadecimal encoded" indicate values that are always unsigned and are to be written out in human-readable base-16 numbers using the UTF-8 characters 0x30 through 0x39 ('0' through '9') and 0x41 through 0x46 ('A' through 'F'). Similarly, indications of "decimal encoded" indicate that the value is to be written out in human-readable base-10 numbers using the UTF-8 characters 0x30 through 0x39 ('0' through '9'). In both encodings, numbers always take up the number of bytes indicated and are padded on the left with UTF-8 '0' (zero) characters to fill the entire space.
次のセクションでは、「16進数でエンコード」の表示は常に符号なしで、UTF-8文字0x30から0x39（ '0'から '9'）を使用して人間が読めるbase-16番号で書き出される値を示していることに注意してください。 0x41〜0x46（ 'A'〜 'F'）。同様に、「10進数でエンコード」の表示は、値がUTF-8文字0x30から0x39（ '0'から '9'）を使用して、人間が読めるbase-10数値で書き出されることを示しています。どちらのエンコーディングでも、数値は常に指定されたバイト数を占め、スペース全体を埋めるために左側にUTF-8 '0'（ゼロ）文字が埋め込まれます。
The <IndexPointers> portion of the SIP CLF record (shown in Figure 3) is a 60-byte header that indicates metadata about the record.
SIP CLFレコード（図3を参照）の<IndexPointers>部分は、レコードに関するメタデータを示す60バイトのヘッダーです。
0 7 8 15 16 23 24 31
+-----------+-----------+-----------+-----------+
| Version | Record Length | 0 - 3
+-----------+-----------+-----------+-----------+
| Record Length (cont) | 0x2C | 4 - 7
+-----------+-----------+-----------+-----------+
| CSeq Pointer (Hex) | 8 - 11
+-----------+-----------+-----------+-----------+
| Response Status-Code Pointer (Hex) | 12 - 15
+-----------+-----------+-----------+-----------+
| R-URI Pointer (Hex) | 16 - 19
+-----------+-----------+-----------+-----------+
| Destination IP address:port Pointer (Hex) | 20 - 23
+-----------+-----------+-----------+-----------+
| Source IP address:port Pointer (Hex) | 24 - 27
+-----------+-----------+-----------+-----------+
| To URI Pointer (Hex) | 28 - 31
+-----------+-----------+-----------+-----------+
| To Tag Pointer (Hex) | 32 - 35
+-----------+-----------+-----------+-----------+
| From URI Pointer (Hex) | 36 - 39
+-----------+-----------+-----------+-----------+
| From Tag Pointer (Hex) | 40 - 43
+-----------+-----------+-----------+-----------+
| Call-Id Pointer (Hex) | 44 - 47
+-----------+-----------+-----------+-----------+
| Server-Txn Pointer (Hex) | 48 - 51
+-----------+-----------+-----------+-----------+
| Client-Txn Pointer (Hex) | 52 - 55
+-----------+-----------+-----------+-----------+
| Optional Fields Start Pointer (Hex) | 56 - 59
+-----------+-----------+-----------+-----------+
Figure 3: Index Pointers
図3：インデックスポインター
The fields that make up <IndexPointers> are described below:
<IndexPointers>を構成するフィールドについて、以下で説明します。
Version (1 byte): UTF-8 encoded version for the SIP CLF record. Range of valid values for the Version is from 'A' (0x41) to 'Z' (0x5A). This document uses a Version value of "0x41" ('A').
バージョン（1バイト）：SIP CLFレコードのUTF-8エンコードバージョン。バージョンの有効な値の範囲は、 'A'（0x41）〜 'Z'（0x5A）です。このドキュメントでは、バージョン値「0x41」（「A」）を使用します。
The value of the SIP CLF Version MUST be incremented for any new SIP CLF specification that changes any part of the SIP CLF record format. The SIP CLF Version values are IANA-assigned (Section 9.1) via the Standards Action method described in [RFC5226].
SIP CLFレコードフォーマットの一部を変更する新しいSIP CLF仕様では、SIP CLFバージョンの値をインクリメントする必要があります。 SIP CLFバージョンの値は、[RFC5226]で説明されている標準アクションメソッドを介してIANAによって割り当てられます（セクション9.1）。
Since the version is specified per record, it is possible that a SIP CLF log file could contain records with different versions. Under normal operating conditions, this is an unlikely occurrence and SHOULD be avoided if possible.
バージョンはレコードごとに指定されるため、SIP CLFログファイルに異なるバージョンのレコードが含まれる可能性があります。通常の動作条件では、これは起こりそうもないことであり、可能であれば回避する必要があります。
Record Length (6 bytes): Hexadecimal encoded total length of this log record, beginning with the "Version" octet and ending with the terminating line-feed.
レコード長（6バイト）：このログレコードの16進数でエンコードされた全長。「バージョン」オクテットで始まり、終了改行で終わります。
Bytes 8 through 55 contain hexadecimal encoded pointers that point to the starting location of each of the variable-length mandatory fields. Bytes 56 through 59 contain a hexadecimal encoded pointer that points to the starting location of the optional fields portion of the SIP CLF record. Note that there are no delimiters between these pointer values -- they are packed together as a single, 52- character hexadecimal encoded string. The "Pointer" fields indicate absolute byte values within the record, and are therefore >=82. They point to the start of the corresponding value within the <MandatoryFields> portion. A description of each of the mandatory fields that these pointer values point to can be found in Section 4.2.
バイト8から55には、可変長の各必須フィールドの開始位置を指す16進数でエンコードされたポインターが含まれています。バイト56から59には、SIP CLFレコードのオプションのフィールド部分の開始位置を指す16進数でエンコードされたポインターが含まれています。これらのポインター値の間に区切り文字がないことに注意してください。これらは、単一の52文字の16進数でエンコードされた文字列として一緒にパックされます。 「ポインタ」フィールドは、レコード内の絶対バイト値を示すため、82以上です。これらは、<MandatoryFields>部分内の対応する値の開始を指します。これらのポインタ値が指す各必須フィールドの説明は、セクション4.2にあります。
Optional Fields Start Pointer: This final pointer indicates the location within the SIP CLF record where the OPTIONAL group of <OptionalFields> begin, if present. The "Optional Fields Start Pointer" points to the UTF-8 Tab (0x09) character for the first entry in the <OptionalFields> portion. If the OPTIONAL group of <OptionalFields> are not implemented, then the "Optional Fields Start Pointer" field MUST point to the terminating line-feed (0x0A) at the end of the SIP CLF record.
オプションフィールドの開始ポインター：この最後のポインターは、<OptionalFields>のOPTIONALグループが存在する場合、開始するSIP CLFレコード内の場所を示します。 "Optional Fields Start Pointer"は、<OptionalFields>部分の最初のエントリのUTF-8タブ（0x09）文字を指します。 <OptionalFields>のOPTIONALグループが実装されていない場合、「Optional Fields Start Pointer」フィールドは、SIP CLFレコードの終わりにある終端改行（0x0A）を指している必要があります。
The <MandatoryFields> portion of the SIP CLF record is shown below:
SIP CLFレコードの<MandatoryFields>部分を以下に示します。
0 7 8 15 16 23 24 31
+-----------+-----------+-----------+-----------+
| 0x0A | | 60 - 63
+-----------+ +
| Timestamp | 64 - 67
+ +-----------+
| | 0x2E | 68 - 71
+-----------+-----------+-----------+-----------+
| Fractional Seconds | 0x09 | 72 - 75
+-----------+-----------+-----------+-----------+
| Flags Field | 76 - 79
+-----------+-----------+-----------+-----------+
|Flag (cont)| 0x09 | | 80 - 83
|-----------+-----------+ |
| |
| |
| Mandatory Fields (variable length) |
| |
| |
+-----------+-----------+-----------+-----------+
Figure 4: Mandatory Fields
図4：必須フィールド
Following the pointers in <IndexPointers>, two fixed-length fields are encoded to specify the exact time of the log entry. As before, all fields are completely filled, pre-pending values with '0' characters as necessary.
<IndexPointers>のポインターに続いて、2つの固定長フィールドがエンコードされ、ログエントリの正確な時間を指定します。以前と同様に、すべてのフィールドは完全に入力され、必要に応じて「0」の文字が前に付加されます。
Timestamp (10 bytes): Decimal encoded date and time of the request or response represented as the number of seconds since the Unix epoch (i.e., seconds since midnight, January 1st, 1970, GMT).
タイムスタンプ（10バイト）：Unixエポックからの秒数（1970年1月1日午前0時からの秒数）として表される、要求または応答の10進数でエンコードされた日時。
Fractional Seconds (3 bytes): Decimal encoded fractional seconds portion of the Timestamp field to millisecond accuracy.
小数秒（3バイト）：タイムスタンプフィールドの10進数でエンコードされた小数秒部分。ミリ秒の精度。
The combined Timestamp and Fractional Seconds fields are represented in the log file as a UTF-8 encoded string representing the date and time of the request or response represented as the number of seconds and milliseconds since the Unix epoch. The number of milliseconds is separated by a "." (UTF-8 character 0x2E) from the number of seconds.
TimestampフィールドとFractional Secondsフィールドを組み合わせると、ログファイルでは、要求または応答の日時を表すUTF-8エンコードされた文字列として、Unixエポックからの秒数とミリ秒数で表されます。ミリ秒数は「。」で区切られます。 （UTF-8文字0x2E）秒数。
Flags Field (5 bytes):
フラグフィールド（5バイト）：
byte 1 - Request/Response Flag
バイト1-要求/応答フラグ
R = Request r = Response
R =リクエストr =レスポンス
byte 2 - Retransmission Flag
バイト2-再送信フラグ
O = Original transmission D = Duplicate transmission S = Server is stateless [i.e., retransmissions are not detected]
O =元の送信D =重複した送信S =サーバーはステートレスです（つまり、再送信は検出されません）
byte 3 - Sent/Received Flag
バイト3-送信済み/受信済みフラグ
S = Sent message R = Received message
S =送信済みメッセージR =受信済みメッセージ
byte 4 - Transport Flag
バイト4-トランスポートフラグ
The Transport Flag values are IANA-assigned (Section 9.2) via the IETF Review method described in [RFC5226]. Currently, registered values are:
トランスポートフラグの値は、[RFC5226]で説明されているIETFレビューメソッドを介してIANAによって割り当てられます（セクション9.2）。現在、登録されている値は次のとおりです。
U = UDP T = TCP S = SCTP
U = UDP T = TCP S = SCTP
byte 5 - Encryption Flag
バイト5-暗号化フラグ
E = Encrypted message (TLS, DTLS, etc.) U = Unencrypted message
E =暗号化されたメッセージ（TLS、DTLSなど）U =暗号化されていないメッセージ
After the "Timestamp", "Fractional Seconds", and the "Flags" fields are the values for the mandatory fields specified in Section 8.1 of [RFC6872], which are described below:
「Timestamp」、「Fractional Seconds」、および「Flags」フィールドの後は、[RFC6872]のセクション8.1で指定されている必須フィールドの値であり、以下で説明します。
CSeq: The Command Sequence header field, including the CSeq number and method name.
CSeq：CSeq番号とメソッド名を含むコマンドシーケンスヘッダーフィールド。
Response Status-Code: Set to the value of the SIP response status code for responses. Set to a single UTF-8 dash (0x2D) for requests.
応答ステータスコード：応答のSIP応答ステータスコードの値に設定します。リクエストに対して単一のUTF-8ダッシュ（0x2D）に設定します。
R-URI: The Request-URI in the start line (mandatory in request), including any URI parameters.
R-URI：開始行のRequest-URI（リクエストでは必須）。URIパラメーターを含みます。
Destination IP address:port: The IP address of the downstream server and the port number, separated by a single ':'. IPv4 addresses are represented in "dotted decimal" notation as per [RFC1166]. IPv6 addresses are represented using the hexadecimal notation detailed in Section 4 of [RFC5952] (or the special-case mixed hexadecimal and decimal notation detailed in Section 5 of [RFC5952]) and enclosed in square brackets ('[' and ']').
宛先IPアドレス：ポート：単一の「：」で区切られたダウンストリームサーバーのIPアドレスとポート番号。 IPv4アドレスは、[RFC1166]に従って「ドット付き10進」表記で表されます。 IPv6アドレスは、[RFC5952]のセクション4で詳述されている16進表記（または[RFC5952]のセクション5で詳述されている特殊なケースの16進表記と10進表記）を使用して表され、角括弧（ '['および ']'）で囲まれています。 。
Source IP address:port: The IP address of the upstream client and the port number over which the SIP message was received, separated by a single ':'. IPv4 addresses are represented in "dotted decimal" notation as per [RFC1166]. IPv6 addresses are represented using the hexadecimal notation detailed in Section 4 of [RFC5952] (or the special-case mixed hexadecimal and decimal notation detailed in Section 5 of [RFC5952]) and enclosed in square brackets ('[' and ']').
送信元IPアドレス：ポート：単一の '：'で区切られた、アップストリームクライアントのIPアドレスとSIPメッセージが受信されたポート番号。 IPv4アドレスは、[RFC1166]に従って「ドット付き10進」表記で表されます。 IPv6アドレスは、[RFC5952]のセクション4で詳述されている16進表記（または[RFC5952]のセクション5で詳述されている特殊なケースの16進表記と10進表記）を使用して表され、角括弧（ '['および ']'）で囲まれています。 。
To URI: Value of the URI in the To header field.
To URI：ToヘッダーフィールドのURIの値。
To Tag: Value of the tag parameter (if present) in the To header field.
To Tag：Toヘッダーフィールドのタグパラメータ（存在する場合）の値。
From URI: Value of the URI in the From header field.
From URI：FromヘッダーフィールドのURIの値。
From Tag: Value of the tag parameter (if present) in the From header field.
Fromタグ：Fromヘッダーフィールドのタグパラメータの値（存在する場合）。
Call-Id: The value of the Call-ID header field.
Call-Of：Call-IDヘッダーフィールドの値。
Server transaction identification code (Server-Txn): 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 tracking forking. (See Section 9 of [RFC6872] for usage.)
サーバートランザクション識別コード（Server-Txn）：サーバートランザクションに関連付けられたトランザクション識別子。実装では、サーバートランザクション識別子（マジックCookieの有無にかかわらず、着信要求の最上位のブランチID）を再利用できます。また、サーバートランザクションの一意の識別文字列を生成することもできます（この識別子は、ローカルでサーバーにのみ一意である必要があります） ）。この識別子は、ACKとCANCELをINVITEトランザクションに関連付けるために使用されます。フォークの追跡を支援するためにも使用されます。 （使用方法については、[RFC6872]のセクション9をご覧ください）。
Client transaction identification code (Client-Txn): 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 of [RFC6872] for usage.) Note: The definitions of the Server-Txn and Client-Txn are taken directly from [RFC6872] and are provided here only as a convenience to the implementer. The definitions specified in [RFC6872] should be considered authoritative in the event of a conflict.
クライアントトランザクション識別コード（Client-Txn）：このフィールドは、クライアントトランザクションをフォークプロキシまたはB2BUAのサーバートランザクションに関連付けるために使用されます。フォークすると、実装は最上位のViaヘッダーのブランチパラメーターに挿入した値を再利用するか、クライアントトランザクションの一意の識別文字列を生成できます。 （使用方法については、[RFC6872]のセクション9を参照してください。）注：Server-TxnおよびClient-Txnの定義は[RFC6872]から直接取得され、ここでは実装者の便宜のためにのみ提供されています。 [RFC6872]で指定されている定義は、矛盾が生じた場合に信頼できると見なされるべきです。
This data MUST appear in the order listed in <IndexPointers>, and each field MUST be present. Fields are subject the maximum SIP CLF field size of 4096 bytes as detailed in Section 8 of [RFC6872].
このデータは、<IndexPointers>にリストされている順序で出現する必要があり、各フィールドが存在する必要があります。 [RFC6872]のセクション8で詳述されているように、フィールドには最大4096バイトのSIP CLFフィールドサイズが適用されます。
The mandatory fields in a SIP CLF record are separated by a single UTF-8 Tab character (0x09). Any Tab characters present in the data to be written will be replaced by a UTF-8 space character (0x20) prior to being logged.
SIP CLFレコードの必須フィールドは、単一のUTF-8タブ文字（0x09）で区切られています。書き込まれるデータに存在するタブ文字は、ログに記録される前にUTF-8スペース文字（0x20）に置き換えられます。
The decision to replace tabs with spaces was based on there being no standardized use of tabs in SIP headers to convey any other meaning than whitespace. Tabs may appear in message bodies, and in the event that the bodies are logged, the conversion to space may cause problems when reconstructing the body from the corresponding log entry. Two consequences of the decision to replace Tab with a space character are: (a) it will become impossible to reconstruct a signature over the logged field that matches the signature over fields in the original SIP message, and (b) any future SIP header fields that include tabs with a different semantic meaning than simply signifying whitespace will lose this meaning when logged. Finally, the tabs-to-spaces substitution MUST occur when logging mandatory fields and optional SIP Header Field or Reason-Phrase (Tag=00); it MUST also occur when optionally logging either the entire message (Tag=02) or simply a SIP body (Tag=01) as described in Section 4.4.
タブをスペースで置き換えるという決定は、空白以外の意味を伝えるためにSIPヘッダーでタブの標準化された使用法がないことに基づいていました。タブがメッセージ本文に表示される場合があり、本文がログに記録される場合、対応するログエントリから本文を再構築するときにスペースへの変換によって問題が発生することがあります。タブをスペース文字に置き換える決定の2つの結果は次のとおりです。（a）元のSIPメッセージのフィールドの署名と一致するログフィールドの署名を再構築できなくなり、（b）今後のSIPヘッダーフィールド空白を示すだけではなく、意味的に異なるタブが含まれている場合、ログに記録するとこの意味が失われます。最後に、必須フィールドとオプションのSIPヘッダーフィールドまたは理由フレーズ（Tag = 00）をログに記録するときに、タブからスペースへの置換が発生する必要があります。セクション4.4で説明されているように、オプションでメッセージ全体（Tag = 02）または単にSIP本文（Tag = 01）のいずれかをログに記録するときにも発生する必要があります。
An element will not always have an appropriate value to provide for one of these fields, even when the field is required to appear in the SIP CLF record. In such circumstances, when a given mandatory field from Section 4.2 and specified in Section 8.1 of [RFC6872]) is not present, then that empty field MUST be encoded as a single horizontal dash ("-"). In the event that a field failed to parse, it MUST be encoded as a single question mark ("?"). If these characters are part of a sequence of other characters, then there is no ambiguity. If the field being logged contains only one character, and that character is the literal "-", the implementation SHOULD insert an escaped %2D for that field in the SIP CLF record. Similarly, if the field contains only one character, and that character is the literal "?", the implementation SHOULD insert an escaped %3F for that field in the SIP CLF record.
フィールドがSIP CLFレコードに表示される必要がある場合でも、要素には、これらのフィールドの1つを提供するための適切な値が常にあるとは限りません。そのような状況では、セクション4.2の[RFC6872]のセクション8.1で指定された必須フィールドが存在しない場合、その空のフィールドは単一の水平ダッシュ（ "-"）としてエンコードする必要があります。フィールドの解析に失敗した場合は、単一の疑問符（ "？"）としてエンコードする必要があります。これらの文字が他の文字のシーケンスの一部である場合、あいまいさはありません。ログに記録されるフィールドに1文字しか含まれておらず、その文字がリテラル「-」である場合、実装はSIP CLFレコードのそのフィールドにエスケープされた％2Dを挿入する必要があります（SHOULD）。同様に、フィールドに1文字しか含まれておらず、その文字がリテラル「？」である場合、実装はSIP CLFレコードのそのフィールドにエスケープされた％3Fを挿入する必要があります（SHOULD）。
The terminating carriage return line feed (CRLF) after a given header field value MUST NOT be logged. Since a bare CRLF sequence is not permitted within a SIP header field value, mandatory fields MUST NOT contain a CRLF when logged and consequently no escaping mechanism is required for it.
特定のヘッダーフィールド値の後の終了キャリッジリターンラインフィード（CRLF）はログに記録してはなりません（MUST NOT）。裸のCRLFシーケンスはSIPヘッダーフィールド値内で許可されていないため、ログに記録するときに必須フィールドにCRLFを含めてはならず、そのため、エスケープメカニズムは必要ありません。
Clearly, a SIP parser could not possibly successfully parse a SIP CLF record in its entirety given the SIP CLF format described in this document. It is possible to parse individual fields in the SIP CLF record if they are extracted and given to a SIP parser that would normally parse those sequence of strings. It should be noted that any field value that is modified by the escaping mechanisms defined in this document before logging ('-','?', and CRLF) is likely no longer well-formed SIP and will fail when given to such a parser.
明らかに、SIPパーサーは、このドキュメントで説明されているSIP CLF形式を前提として、SIP CLFレコード全体を正常に解析できなかった可能性があります。 SIP CLFレコードの個々のフィールドを抽出して、それらの文字列のシーケンスを通常は解析するSIPパーサーに渡すと、それらを解析することができます。ログの前にこのドキュメントで定義されているエスケープメカニズムによって変更されたフィールド値（ '-'、 '？'、およびCRLF）はおそらく整形式のSIPではなく、そのようなパーサーに渡されると失敗することに注意してください。 。
The intent of logging using SIP CLF is not to faithfully recreate the bit-exact SIP message being logged. In fact, the formatting rules, encoding, and character escaping requirements preclude this and may introduce information loss relative to the original SIP message. A log reader should never unescape anything in the SIP CLF record since they are intended to be machine processed using text tools such as grep and awk. The human user behind the log reader may be required to infer more semantics about any differences between the original SIP message and its SIP CLF representation.
SIP CLFを使用してログを記録する目的は、ログ記録されるビット厳密なSIPメッセージを忠実に再現することではありません。実際、フォーマットルール、エンコーディング、文字エスケープの要件により、これが不可能になり、元のSIPメッセージと比較して情報が失われる可能性があります。ログリーダーは、grepやawkなどのテキストツールを使用して機械処理されることを目的としているため、SIP CLFレコードのエスケープを解除しないでください。ログリーダーの背後にいる人間のユーザーは、元のSIPメッセージとそのSIP CLF表現の違いについて、より多くのセマンティクスを推測する必要がある場合があります。
The <OptionalFields> portion of the SIP CLF record is shown below:
SIP CLFレコードの<OptionalFields>部分を以下に示します。
0 7 8 15 16 23 24 31
+-----------+-----------+-----------+-----------+
| 0x09 | Tag | 0x40 |\
+-----------+-----------+-----------+-----------+ \
| Vendor-ID | \
+-----------+-----------+-----------+-----------+ \
| Vendor-ID (cont) | \ Repeated
+-----------+-----------+-----------+-----------+ \ as many
| 0x2C | Length (Hex) | > times as
+-----------+-----------+-----------+-----------+ / necessary
| Len (cont)| 0x2C | BEB | 0x2C | /
+-----------+-----------+-----------------------| /
| | /
| Value (variable length) | /
| |/
+-----------+-----------+-----------+-----------+
Figure 5: Optional Fields
図5：オプションのフィールド
Optional fields are those SIP message elements that are not a part of the mandatory fields list detailed in Section 8.1 of [RFC6872]. After the <MandatoryFields> section, there is an OPTIONAL <OptionalFields> group (shown in Figure 5) that MAY appear zero or more times. This <OptionalFields> group provides extensibility to the SIP CLF. It allows SIP CLF implementers the flexibility to extend the logging capability of this indexed text representation beyond just the mandatory log elements described in Section 8.1 of [RFC6872].
オプションのフィールドは、[RFC6872]のセクション8.1に詳述されている必須フィールドリストの一部ではないSIPメッセージ要素です。 <MandatoryFields>セクションの後には、OPTIONAL <OptionalFields>グループ（図5に示す）があり、0回以上表示される場合があります。この<OptionalFields>グループは、SIP CLFに拡張性を提供します。 SIP CLFの実装者は、[RFC6872]のセクション8.1で説明されている必須のログ要素だけでなく、このインデックス付きテキスト表現のロギング機能を拡張できる柔軟性を備えています。
Logging any optional SIP elements MUST be done according to the format shown in Figure 5. The location of the start of <OptionalFields> within the SIP CLF record is indicated by the "Optional Fields Start Pointer" field in <IndexPointers>. After the initial Tab delimiter byte (0x09) shown in Figure 5, the optional field being logged is generally represented by the notation:
オプションのSIP要素のロギングは、図5に示すフォーマットに従って実行する必要があります。SIPCLFレコード内の<OptionalFields>の開始位置は、<IndexPointers>の「Optional Fields Start Pointer」フィールドで示されます。図5に示す最初のタブ区切りバイト（0x09）の後、ログに記録されるオプションのフィールドは通常、次の表記で表されます。
Tag@Vendor-ID,Length,BEB,Value
Tag @ Vendor-ID、長さ、BEB、値
The optional field identifier (Tag@Vendor-ID) is composed of a two-byte Tag and an eight-byte Vendor-ID (both decimal encoded) separated by an "@" character (0x40). This uniquely identifies the optional field being logged. The format for this identifier is loosely modeled after the private use option used by the syslog protocol [RFC5424] (Note: this is the second format detailed in Section 6.3.2 of [RFC5424]). It makes use of the Private Enterprise Number (PEN), which provides an identifier through a globally unique name space [PEN]. This syntax provides the necessary extensibility to SIP CLF to allow logging of any SIP header, body, as well as any vendor-specified SIP element.
オプションのフィールド識別子（Tag @ Vendor-ID）は、 "@"文字（0x40）で区切られた2バイトのタグと8バイトのベンダーID（両方とも10進数でエンコード）で構成されます。これは、ログに記録されるオプションのフィールドを一意に識別します。この識別子の形式は、syslogプロトコル[RFC5424]で使用される私的使用オプションに基づいて大まかにモデル化されています（注：これは、[RFC5424]のセクション6.3.2で説明されている2番目の形式です）。グローバルに一意の名前空間[PEN]を通じて識別子を提供するPrivate Enterprise Number（PEN）を利用します。この構文は、SIP CLFに必要な拡張性を提供し、任意のSIPヘッダー、ボディ、およびベンダー指定のSIP要素のロギングを可能にします。
The Base64 Encoded Byte (BEB) is a boolean that is used to indicate whether or not the optional element being logged is Base64 encoded. The Value field for the optional element being logged MUST be Base64 encoded if it has any characters that are 'unprintable'. For the purposes of this document, we define 'unprintable' to mean a string of octets that: (a) contains an octet with a value in the range of 0 to 31, inclusive; (b) contains an octet with a value of 127; or (c) contains any series of octets greater than or equal to 128 that do not form a valid UTF-8 sequence, as specified by [UNICODE]. If the optional element being logged is Base64 encoded, then BEB=0x01; if it is not Base64 encoded, then BEB=0x00.
Base64 Encoded Byte（BEB）は、ログに記録されるオプションの要素がBase64エンコードされているかどうかを示すために使用されるブール値です。ログに記録されるオプションの要素の値フィールドには、「印刷できない」文字が含まれている場合、Base64でエンコードする必要があります。このドキュメントでは、「印刷不可」を以下のオクテットの文字列を意味するように定義します。（a）0〜31の範囲の値を持つオクテットを含む。 （b）値が127のオクテットを含む。または（c）[UNICODE]で指定されているように、有効なUTF-8シーケンスを形成しない128以上の一連のオクテットが含まれている。ログに記録されるオプションの要素がBase64でエンコードされている場合、BEB = 0x01。 Base64エンコードされていない場合は、BEB = 0x00です。
Optional fields are logged according to the following two syntax rules:
オプションのフィールドは、次の2つの構文規則に従ってログに記録されます。
(1) Vendor-ID = 00000000
（1）ベンダーID = 00000000
A Vendor-ID of zero is used to log the entire SIP message, message body, Reason-Phrase, or any SIP header fields that are not a part of the mandatory fields list detailed in Section 8.1 of [RFC6872]. The following Tag values are used to identify which of these optional elements are being logged:
Vendor-IDがゼロの場合、SIPメッセージ全体、メッセージ本文、Reason-Phrase、または[RFC6872]のセクション8.1に詳述されている必須フィールドリストの一部ではないSIPヘッダーフィールドがログに記録されます。次のタグ値は、これらのオプション要素のどれがログに記録されているかを識別するために使用されます。
Tag = 00 - Log SIP Header Field or Reason-Phrase
タグ= 00-ログSIPヘッダーフィールドまたは理由フレーズ
When logging a SIP Header Field (Tag=00), the associated "Value" field MUST be populated by the entire header field being logged. That is, the field-name, the associated colon (":"), and the field-value. This mechanism provides the capability to optionally log any SIP header field by identifying the field being logged within the "Value" field.
SIPヘッダーフィールド（Tag = 00）をログに記録する場合、関連する「値」フィールドには、ログに記録されるヘッダーフィールド全体が入力される必要があります。つまり、フィールド名、関連付けられたコロン（ "："）、およびフィールド値です。このメカニズムは、「値」フィールド内でログに記録されているフィールドを識別することにより、オプションで任意のSIPヘッダーフィールドを記録する機能を提供します。
Because the Reason-Phrase in a response is part of the Status-Line and is not identified with a field-name, it is a special case. In this instance, the associated "Value" field MUST be populated by the name "Reason-Phrase" followed by a colon (":") and a single space (SP) between the colon and the logged Reason-Phrase value.
応答のReason-PhraseはStatus-Lineの一部であり、field-nameで識別されないため、これは特殊なケースです。この場合、関連付けられた「値」フィールドには、「Reason-Phrase」という名前の後にコロン（「：」）が続き、コロンとログに記録されたReason-Phrase値の間に1つのスペース（SP）が続く必要があります。
The corresponding "Length" field includes the length of the entire "Value" field. This includes the field-name, the colon, and any linear whitespace (LWS) separator. For Tag=00, the BEB is set according to whether the SIP Header Field value contains any 'unprintable' characters. If it does not, the BEB=00; if it does, the BEB=01. If BEB=01, then only the field-value MUST be Base64 encoded; the field-name, the associated colon, and any LWS separator MUST retain their original encoding.
対応する「長さ」フィールドには、「値」フィールド全体の長さが含まれます。これには、フィールド名、コロン、および任意の線形空白（LWS）セパレータが含まれます。 Tag = 00の場合、BEBはSIPヘッダーフィールド値に「印刷できない」文字が含まれているかどうかに応じて設定されます。そうでない場合、BEB = 00。含まれている場合、BEB = 01。 BEB = 01の場合、フィールド値のみをBase64でエンコードする必要があります。フィールド名、関連付けられたコロン、およびLWSセパレータは、元のエンコーディングを保持する必要があります。
If an optional field occurs more than once in a SIP message (e.g., Contact, Route, Record-Route, etc.), then each occurrence MUST be logged with the same Tag value (i.e., Tag=00) as a distinct optional field entry in the SIP CLF record. These repeated optionally logged header fields MUST preserve the ordinal position of the repeated header fields in the SIP header. For example, a SIP header containing two Via header fields with the following ordinal positions within the SIP header: V1,V2. If optionally logging these header fields, they would occur as the following entries in the SIP CLF record. (Note: For the sake of brevity, this example only shows how these optional header fields would be logged and omits the remainder of the SIP CLF record):
オプションのフィールドがSIPメッセージで2回以上発生する場合（例：連絡先、ルート、レコードルートなど）、それぞれの発生は、別個のオプションフィールドとして同じタグ値（つまり、Tag = 00）で記録する必要があります。 SIP CLFレコードのエントリ。これらの繰り返しオプションでログに記録されるヘッダーフィールドは、SIPヘッダーの繰り返しヘッダーフィールドの順序位置を保持する必要があります。たとえば、SIPヘッダー内の順序位置がV1、V2の2つのViaヘッダーフィールドを含むSIPヘッダー。これらのヘッダーフィールドをオプションでログに記録すると、SIP CLFレコードの次のエントリとして発生します。 （注：簡潔にするため、この例では、これらのオプションのヘッダーフィールドがログに記録される方法のみを示し、SIP CLFレコードの残りを省略しています）：
00@00000000,len_V1,00,Via: V1 00@00000000,len_V2,00,Via: V2
The terminating carriage return line feed (CRLF) after a given header field value MUST NOT be logged. Since a bare CRLF sequence is not permitted within a SIP header field value, optional SIP header fields logged with Tag=00 MUST NOT contain a CRLF when logged and consequently no escaping mechanism is required for it.
特定のヘッダーフィールド値の後の終了キャリッジリターンラインフィード（CRLF）はログに記録してはなりません（MUST NOT）。ベアCRLFシーケンスはSIPヘッダーフィールド値内では許可されないため、Tag = 00でログに記録されたオプションのSIPヘッダーフィールドには、ログが記録されたときにCRLFを含めてはならず、そのためエスケープメカニズムは必要ありません。
Tag = 01 - Log message body
SIP message bodies of all types can be optionally logged using Tag=01. If the message body is logged it MUST adhere to the maximum size limitation of 4096 bytes for a SIP CLF field, as detailed in Section 8 of [RFC6872]. Unlike with Tag=00, there can only be a single entry in the SIP CLF record with Tag=01. When optionally logging the message body, if the maximum SIP CLF field size of 4096 bytes is exceeded, the message body being logged MUST be truncated to meet these size limitations.
すべてのタイプのSIPメッセージ本文は、Tag = 01を使用してオプションでログに記録できます。 [RFC6872]のセクション8で説明されているように、メッセージ本文がログに記録される場合は、SIP CLFフィールドの最大サイズ制限である4096バイトを遵守する必要があります。 Tag = 00とは異なり、SIP CLFレコードにはTag = 01の単一のエントリしか存在できません。オプションでメッセージ本文をログに記録するときに、4096バイトの最大SIP CLFフィールドサイズを超えた場合、これらのサイズ制限を満たすために、ログに記録されるメッセージ本文を切り捨てる必要があります。
When logging a message body (Tag=01), the associated "Value" field is populated with the Content-Type itself plus the SIP message body separated with a space. In this manner, everything about the SIP message body is self-described using a single tag as compared to enumerating a separate tag for each body type. Additionally, the corresponding "Length" field includes the SIP message body, the length of the embedded Content-Type, and the space separator between the MIME type and the body content.
メッセージ本文（Tag = 01）をログに記録すると、関連する「値」フィールドには、Content-Type自体と、スペースで区切られたSIPメッセージ本文が入力されます。このように、SIPメッセージボディに関するすべては、ボディタイプごとに個別のタグを列挙するのと比較して、単一のタグを使用して自己記述されます。さらに、対応する「長さ」フィールドには、SIPメッセージの本文、埋め込まれたContent-Typeの長さ、およびMIMEタイプと本文のコンテンツの間のスペース区切りが含まれます。
For an optionally logged message body (Tag=01), the BEB is set according to whether the message body contains any 'unprintable' characters. If it does not, the BEB=00; if it does, the BEB=01. If BEB=01, then the message body that follows is entirely Base64 encoded except the prepended Content-Type as described in the previous paragraph.
オプションでログに記録されるメッセージ本文（Tag = 01）の場合、BEBはメッセージ本文に「印刷できない」文字が含まれているかどうかに従って設定されます。そうでない場合、BEB = 00。含まれている場合、BEB = 01。 BEB = 01の場合、後続のメッセージ本文は、前の段落で説明したように先頭に付加されたContent-Typeを除いて、完全にBase64でエンコードされます。
If an optionally logged SIP message body contains any CRLFs, they MUST be escaped by using the URI encoded equivalent value of "%0D%0A". This escaping mechanism applies to all body types. So we don't make any distinction in treatment between the various possible body types. If a logged message body has BEB=01, then it MUST be Base64 encoded prior to any character escaping. Thus, if a binary body (like an image) is logged, it will be Base64 encoded first and that Base64 character stream could never include the CRLF escape sequence of "%0D%0A" because "%" is not a valid Base64 character.
オプションでログに記録されたSIPメッセージ本文にCRLFが含まれている場合は、URIエンコードされた同等の値「％0D％0A」を使用してエスケープする必要があります。このエスケープメカニズムは、すべてのボディタイプに適用されます。だから私たちは、様々な可能な身体の種類の間で治療を区別しません。ログに記録されたメッセージ本文にBEB = 01がある場合、文字がエスケープする前に、Base64でエンコードする必要があります。したがって、バイナリボディ（画像など）がログに記録されると、最初にBase64でエンコードされ、「％」は有効なBase64文字ではないため、Base64文字ストリームに「％0D％0A」のCRLFエスケープシーケンスを含めることはできません。
Tag = 02 - Log entire SIP message
The entire SIP message (i.e., SIP header and message body) can be optionally logged using a Tag=02. Logging the entire SIP message MUST conform to the maximum size limitation of 4096 bytes for a SIP CLF field, as detailed in Section 8 of [RFC6872]. Unlike with Tag=00, there can only be a single entry in the SIP CLF record with Tag=02. When optionally logging the entire SIP message if the maximum SIP CLF field size of 4096 bytes is exceeded the entire SIP message being logged MUST be truncated to meet these size limitations.
SIPメッセージ全体（つまり、SIPヘッダーとメッセージ本文）は、Tag = 02を使用してオプションでログに記録できます。 [RFC6872]のセクション8で詳述されているように、SIPメッセージ全体のロギングは、SIP CLFフィールドの最大サイズ制限である4096バイトに準拠する必要があります。 Tag = 00とは異なり、SIP CLFレコードにはTag = 02の単一のエントリしか存在できません。オプションでSIPメッセージ全体をログに記録するときに、最大SIP CLFフィールドサイズが4096バイトを超えている場合、ログに記録されているSIPメッセージ全体を切り捨てて、これらのサイズ制限を満たす必要があります。
When optionally logging an entire SIP message (Tag=02), the BEB is set according to whether the message body portion contains any 'unprintable' characters. If it does not, the BEB=00; if it does, the BEB=01. If BEB=01, then the entire SIP message is Base64 encoded (not just the message body). Note that unlike the case of Tag=01, when logging an entire SIP message (Tag=02) with 'unprintable' characters (BEB=01), the Content-Type would not be known prior to decode.
オプションでSIPメッセージ全体（Tag = 02）をログに記録する場合、メッセージ本文の部分に「印刷できない」文字が含まれているかどうかに応じてBEBが設定されます。そうでない場合、BEB = 00。含まれている場合、BEB = 01。 BEB = 01の場合、SIPメッセージ全体（メッセージ本文だけでなく）がBase64でエンコードされます。 Tag = 01の場合とは異なり、「印刷できない」文字（BEB = 01）でSIPメッセージ全体（Tag = 02）をログに記録する場合、デコードする前にContent-Typeが認識されないことに注意してください。
All instances of CRLFs, whether they appear in the SIP headers or the SIP message body, MUST be escaped by using the URI encoded equivalent value of "%0D%0A". If a logged SIP message has BEB=01 then it MUST be Base64 encoded prior to any character escaping.
CRLFのすべてのインスタンスは、SIPヘッダーまたはSIPメッセージ本文のどちらに表示されるかに関係なく、 "％0D％0A"のURIエンコードされた同等の値を使用してエスケープする必要があります。ログに記録されたSIPメッセージにBEB = 01がある場合、文字がエスケープされる前に、Base64でエンコードする必要があります。
(2) Vendor-ID = PEN
（2）ベンダーID = PEN
A Vendor-ID set to a vendor's own private enterprise number from the complete current list of private enterprise numbers maintained by IANA [PEN] is used to log any other vendor-specified optional element of a SIP header or body. The value of the Tag is set at the discretion of the implementer:
IANA [PEN]によって管理されているプライベートエンタープライズ番号の完全な現在のリストからベンダー独自のプライベートエンタープライズ番号に設定されたベンダーIDは、SIPヘッダーまたはボディの他のベンダー指定のオプション要素をログに記録するために使用されます。タグの値は、実装者の裁量で設定されます。
Tag = Vendor-specified tag
The definition of the various values of the optional field identifier (Tag@Vendor-ID) are the basis of how optional elements are logged in the SIP CLF. For the sake of completeness, the remaining fields in the format shown in Figure 5 are also defined below:
オプションのフィールド識別子（Tag @ Vendor-ID）のさまざまな値の定義は、オプションの要素がSIP CLFに記録される方法の基礎となります。完全を期すために、図5に示す形式の残りのフィールドも以下に定義されています。
Length Field (4 bytes): Indicates the length of only the "Value" field of this optionally logged element (as shown in Figure 5), hexadecimal encoded. This length corresponds to the length of the "Value" field only and MUST NOT include any of the other elements shown in Figure 5.
長さフィールド（4バイト）：このオプションでログに記録された要素（図5に示す）の「値」フィールドのみの長さを、16進数でエンコードして示します。この長さは「値」フィールドの長さにのみ対応し、図5に示す他の要素を含めてはなりません。
Base64 Encoded Byte (BEB) Field (1 byte): Indicates whether or not the subsequent Value Field of the optionally logged element is Base64 encoded. The Value field for the optional element being logged MUST be Base64 encoded if it contains any character that is deemed 'unprintable' according to the definition given previously in this section. If the optional element being logged is Base64 encoded, then BEB=0x01; if it is not Base64 encoded, then BEB=0x00.
Base64エンコード済みバイト（BEB）フィールド（1バイト）：オプションでログに記録された要素の後続の値フィールドがBase64エンコードされているかどうかを示します。ログに記録されるオプション要素の値フィールドは、このセクションで前述した定義に従って「印刷できない」と見なされる文字が含まれている場合、Base64でエンコードする必要があります。ログに記録されるオプションの要素がBase64でエンコードされている場合、BEB = 0x01。 Base64エンコードされていない場合は、BEB = 0x00です。
Value Field (0 to 4096 bytes): Contains the actual value of this optional field. As with the mandatory fields, UTF-8 Tab characters (0x09) are replaced with UTF-8 space characters (0x20).
値フィールド（0〜4096バイト）：このオプションフィールドの実際の値が含まれます。必須フィールドと同様に、UTF-8タブ文字（0x09）はUTF-8スペース文字（0x20）に置き換えられます。
The following are examples of optionally logged SIP elements using the syntax described in this section. All these examples only show the <OptionalFields> portion of the SIP CLF record. The mandatory <IndexPointers> and <MandatoryFields> portions of the SIP CLF are intentionally omitted for the sake of brevity. Note that all of these examples of optionally logged fields begin with a leading Tab delimiter byte (0x09) that is not apparent here.
以下は、このセクションで説明する構文を使用してオプションでログに記録されるSIP要素の例です。これらの例はすべて、SIP CLFレコードの<OptionalFields>部分のみを示しています。 SIP CLFの必須の<IndexPointers>と<MandatoryFields>の部分は、簡潔にするために意図的に省略されています。オプションでログに記録されるフィールドのこれらの例はすべて、ここでは明らかではない先頭のタブ区切りバイト（0x09）で始まることに注意してください。
(1) Contact header field logged as an optional field:
（1）オプションフィールドとして記録される連絡先ヘッダーフィールド：
Consider the SIP response:
SIP応答について考えます。
SIP/2.0 180 Ringing
<allOneLine>
Via: SIP/2.0/UDP host.example.com;
branch=z9hG4bKnashds8;received=192.0.2.1
</allOneLine>
To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: 0
The Contact header field would be logged as an optional field in the following manner:
Contactヘッダーフィールドは、次の方法でオプションフィールドとして記録されます。
00@00000000,001C,00,Contact: <sip:bob@192.0.2.4>
(2) Reason-Phrase logged as an optional field:
（2）オプションフィールドとして記録される理由フレーズ：
For the same SIP response the Reason-Phrase would be logged as an optional field in the following manner:
同じSIP応答の場合、Reason-Phraseは次の方法でオプションフィールドとして記録されます。
00@00000000,0016,00,Reason-Phrase: Ringing
00 @ 00000000,0016,00、理由フレーズ：呼び出し中
(3) SDP body to be logged as an optional field:
（3）オプションフィールドとして記録されるSDP本文：
v=0 o=alice 2890844526 2890844526 IN IP4 host.example.com s=- c=IN IP4 host.example.com t=0 0 m=audio 49170 RTP/AVP 0 8 97
v = 0 o = alice 2890844526 2890844526 IN IP4 host.example.com s =-c = IN IP4 host.example.com t = 0 0 m = audio 49170 RTP / AVP 0 8 97
This body has a Content-Type of application/sdp and has a length of 123 bytes including all the line-feeds. When logging this body the "Value" field is composed of the Content-Type and the body separated by a space, which gives it a combined length of 139 (0x008B) bytes. This SIP body would be logged as an optional field in the following manner:
この本文のコンテンツタイプはapplication / sdpで、長さはすべての改行を含めて123バイトです。この本文をログに記録する場合、「値」フィールドは、スペースで区切られたContent-Typeと本文で構成されます。これにより、結合された長さは139（0x008B）バイトになります。このSIP本文は、次の方法でオプションフィールドとしてログに記録されます。
<allOneLine>
01@00000000,008B,00,application/sdp v=0%0D%0Ao=alice 2890844526
2890844526 IN IP4 host.example.com%0D%0As=-%0D%0A
c=IN IP4 host.example.com%0D%0At=0 0%0D%0A
m=audio 49170 RTP/AVP 0 8 97%0D%0A
</allOneLine>
Note that the body is actually logged on a single line and is thus captured between <allOneLine/> tags. The line-feeds are escaped using %0D%0A to delimit the various lines in the message body.
本文は実際には1行で記録されるため、<allOneLine />タグ間でキャプチャされることに注意してください。改行は、％0D％0Aを使用してエスケープされ、メッセージ本文のさまざまな行が区切られます。
(4) binary body to be logged as an optional field:
（4）オプションのフィールドとして記録されるバイナリボディ：
The second body part of the multipart/mime SIP message shown in Section 3.1.1.11 of RFC 4475 is a binary encoded body (represented in hex) and if logged would have BEB=01 and would require Base64 encoding. That binary body would produce six lines of output after being Base64 encoded. Subsequent escaping of the CRLF characters would produce an optionally logged body that would look like the following:
RFC 4475のセクション3.1.1.11に示されているmultipart / mime SIPメッセージの2番目のボディパートはバイナリエンコードされたボディ（16進数で表現）であり、ログに記録される場合、BEB = 01となり、Base64エンコーディングが必要になります。そのバイナリボディは、Base64エンコードされた後、6行の出力を生成します。後続のCRLF文字のエスケープにより、オプションでログに記録される本文が生成され、次のようになります。
<allOneLine>
01@00000000,0216,01,multipart/mixed;boundary=7a9cbec02ceef655 MI
IBUgYJKoZIhvcNAQcCoIIBQzCCAT8CAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBw
ExggEgMIIB%0D%0AHAIBATB8MHAxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp
Zm9ybmlhMREwDwYDVQQHEwhTYW4g%0D%0ASm9zZTEOMAwGA1UEChMFc2lwaXQxKT
AnBgNVBAsTIFNpcGl0IFRlc3QgQ2VydGlmaWNhdGUgQXV0%0D%0AaG9yaXR5AggB
lQBxAjMBEzAHBgUrDgMCGjANBgkqhkiG9w0BAQEFAASBgI70ZvlI8FIt0uWXjp2V
%0D%0Aquny/hWgZllxYpLo2iqo2DUKaM7/rjy9K/8Wdd3VZI5ZPdZHKPJiIPfpQX
SeMw2aFe2r25PRDEIQ%0D%0ALntyidKcwMmuLvvHwM/5Fy87An5PwCfhVG3ktqo6
uz5mzMtd1sZLg4MUnLjm/xgtlE/le2W8mdAF%0D%0A
</allOneLine>
Note that the body is actually logged on a single line and is thus captured between <allOneLine/> tags. The line-feeds are escaped using %0D%0A to delimit the various lines in the Base64 encoded binary body.
本文は実際には1行で記録されるため、<allOneLine />タグ間でキャプチャされることに注意してください。改行は、％0D％0Aを使用してエスケープされ、Base64でエンコードされたバイナリ本体のさまざまな行を区切ります。
(5) Codec information from the SDP body logged as an optional field:
（5）オプションフィールドとして記録されるSDP本体からのコーデック情報：
Consider the SIP message:
SIPメッセージについて考えてみましょう。
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8
To: Bob <bob@example.com>
From: Alice <alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@host.example.com>
Content-Type: application/sdp
Content-Length: 147
v=0
o=UserA 2890844526 2890844526 IN IP4 example.com
s=Session SDP
c=IN IP4 host.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
A vendor may choose to log a SIP message element such as the codec information from the SDP body. This vendor-specified SIP element would be logged as an optional field in the following manner:
ベンダーは、SDP本体からのコーデック情報などのSIPメッセージ要素をログに記録することを選択できます。このベンダー指定のSIP要素は、次の方法でオプションフィールドとして記録されます。
03@00032473,0014,00,a=rtpmap:0 PCMU/8000
(6) N-th message received from a particular peer logged as an optional field:
（6）オプションフィールドとして記録された特定のピアから受信したN番目のメッセージ：
Perhaps a vendor wants to log that this message is the n-th message received from a peering partner. To do so for the SIP message shown above, the vendor would log this information as:
おそらくベンダーは、このメッセージがピアリングパートナーから受信したn番目のメッセージであることをログに記録したいと考えています。上記のSIPメッセージに対してこれを行うには、ベンダーはこの情報を次のように記録します。
07@00032473,0016,00,1877 example.com
０７＠０００３２４７３、００１６、００、１８７７ えぁｍｐぇ。こｍ
Which would signify that this is the 1,877th message from the peering partner example.com. Note that the previous two examples showing an optionally logged vendor-specified SIP element use a Vendor-ID with a Private Enterprise Number of 32473. This value has been reserved by IANA to be used as an example PEN in documentation according to [RFC5612].
これは、これがピアリングパートナーexample.comからの1,877番目のメッセージであることを示します。オプションでログに記録されたベンダー指定のSIP要素を示す前の2つの例は、プライベートエンタープライズ番号32473のベンダーIDを使用していることに注意してください。この値は、[RFC5612]によるドキュメントでPENの例として使用するためにIANAによって予約されています。
The following SIP message is an INVITE request sent by a SIP client:
次のSIPメッセージは、SIPクライアントによって送信されたINVITEリクエストです。
INVITE sip:192.0.2.10 SIP/2.0
To: <sip:192.0.2.10>
Call-ID: DL70dff590c1-1079051554@example.com
<allOneLine>
From: "Alice" <sip:1001@example.com:5060>;
tag=DL88360fa5fc;epid=0x34619b0
</allOneLine>
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2012 15:02:03 GMT
<allOneLine>
Via: SIP/2.0/TCP 192.0.2.200:5060;
branch=z9hG4bK-1f6be070c4-DL
</allOneLine>
Contact: "1001" <sip:1001@192.0.2.200:5060>
Content-Type: application/sdp
Content-Length: 418
v=0
o=1001 1456139204 0 IN IP4 192.0.2.200
s=Session SDP
c=IN IP4 192.0.2.200
b=AS:2048
t=0 0
m=audio 13756 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
Shown below is approximately how this message would appear as a single record in a SIP CLF logging file if encoded according to the syntax described in this document. Due to RFC conventions, this log entry has been split into five lines, instead of the two lines that actually appear in a log file; and the Tab characters have been padded out using spaces to simulate their appearance in a text terminal.
このドキュメントで説明されている構文に従ってエンコードされた場合、このメッセージがSIP CLFロギングファイルの単一レコードとしてどのように表示されるかを以下に示します。 RFC規則により、このログエントリは、実際にログファイルに表示される2行ではなく、5行に分割されています。また、タブ文字は、テキスト端末での外観をシミュレートするためにスペースを使用して埋め込まれています。
A000100,0053005C005E006D007D008F009E00A000BA00C700EB00F70100
<allOneLine>
1328821153.010 RORUU 1 INVITE - sip:192.0.2.10
192.0.2.10:5060 192.0.2.200:56485 sip:192.0.2.10 -
sip:1001@example.com:5060 DL88360fa5fc
DL70dff590c1-1079051554@example.com S1781761-88 C67651-11
</allOneLine>
A bit-exact version of the actual log entry is provided here, Base64 encoded.
実際のログエントリのビット完全バージョンがBase64エンコードでここに提供されます。
begin-base64 644 clf_record QTAwMDEwMCwwMDUzMDA1QzAwNUUwMDZEMDA3RDAwOEYwMDlFMDBBMDAwQkEwMEM3MDBF QjAwRjcwMTAwCjEzMjg4MjExNTMuMDEwCVJPUlVVCTEgSU5WSVRFCS0Jc2lwOjE5Mi4w LjIuMTAJMTkyLjAuMi4xMDo1MDYwCTE5Mi4wLjIuMjAwOjU2NDg1CXNpcDoxOTIuMC4y LjEwCS0Jc2lwOjEwMDFAZXhhbXBsZS5jb206NTA2MAlETDg4MzYwZmE1ZmMJREw3MGRm ZjU5MGMxLTEwNzkwNTE1NTRAZXhhbXBsZS5jb20JUzE3ODE3NjEtODgJQzY3NjUxLTEx Cg== ====
開始-BASE64 644 clf_record QTAwMDEwMCwwMDUzMDA1QzAwNUUwMDZEMDA3RDAwOEYwMDlFMDBBMDAwQkEwMEM3MDBF QjAwRjcwMTAwCjEzMjg4MjExNTMuMDEwCVJPUlVVCTEgSU5WSVRFCS0Jc2lwOjE5Mi4w LjIuMTAJMTkyLjAuMi4xMDo1MDYwCTE5Mi4wLjIuMjAwOjU2NDg1CXNpcDoxOTIuMC4y LjEwCS0Jc2lwOjEwMDFAZXhhbXBsZS5jb206NTA2MAlETDg4MzYwZmE1ZmMJREw3MGRm ZjU5MGMxLTEwNzkwNTE1NTRAZXhhbXBsZS5jb20JUzE3ODE3NjEtODgJQzY3NjUxLTExのCg == ====
To recover the unencoded file, the Base64 text above may be passed as input to the following perl script (the output should be redirected to a file).
エンコードされていないファイルを復元するには、上記のBase64テキストを次のperlスクリプトへの入力として渡すことができます（出力はファイルにリダイレクトする必要があります）。
<CODE BEGINS>
<コード開始>
#!/usr/bin/perl
use strict;
my $bdata = "";
use MIME::Base64;
while(<>)
{
if (/begin-base64 644 clf_record/ .. /-- ==== --/)
{
if ( m/^\s*[^\s]+\s*$/)
{
$bdata = $bdata . $_;
}
}
}
print decode_base64($bdata);
<CODE ENDS>
<コード終了>
This format has been designed to allow text tools to easily process logs without needing to understand the indexing format. Index lines may be rapidly discarded by checking the first character of the line: index lines will always start with an alphabetical character, while field lines will start with a numerical character.
このフォーマットは、テキストツールがインデックスのフォーマットを理解する必要なくログを簡単に処理できるように設計されています。インデックス行は、行の最初の文字をチェックすることですばやく破棄できます。インデックス行は常にアルファベット文字で始まり、フィールド行は数字で始まります。
Within a field line, script tools can quickly split fields at the Tab
characters. The first 12 fields are positional, and the meaning of
any subsequent fields can be determined by checking the first four
characters of the field. Alternately, these non-positional fields
can be located using a regular expression. For example, the "Contact
value" in a request can be found by searching for the perl regex
/\t0000,....,([^\t]*)/.
This document does not introduce any new security considerations beyond those discussed in [RFC6872].
このドキュメントでは、[RFC6872]で説明されているものを超える新しいセキュリティの考慮事項を紹介していません。
In the interest of protecting the sensitive information contained in a SIP CLF file, [RFC6872] notes that values might need to be obfuscated for privacy reasons when SIP CLF files are exchanged between domains. If a Base64 encoded string contains the non-obfuscated value, then that would also need to be obfuscated before Base64 encoding.
[RFC6872]は、SIP CLFファイルに含まれる機密情報を保護するために、ドメイン間でSIP CLFファイルが交換される場合、プライバシー上の理由から値を難読化する必要があるかもしれないと述べています。 Base64エンコードされた文字列に難読化されていない値が含まれている場合は、Base64エンコードの前に難読化する必要もあります。
SIP CLF log files will take up a substantive amount of disk space depending on traffic volume at a processing entity and the amount of information being logged. As such, any enterprise using SIP CLF should establish operational procedures for file rollovers 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.
このような運用ガイドラインをこのドキュメントに記載することは、この作業の範囲外です。
This specification establishes a new "Session Initiation Protocol (SIP) Common Log Format (CLF) Parameters" registry, which contains two new sub-registries: "SIP CLF Version Values" and "SIP CLF Transport Flag Values". Initial entries are defined by this specification for both sub-registries. Addition of any new sub-registry to the "Session Initiation Protocol (SIP) Common Log Format (CLF) Parameters" registry is to be done using the IETF Review registration policy detailed in [RFC5226].
この仕様は、「SIP CLFバージョン値」と「SIP CLFトランスポートフラグ値」という2つの新しいサブレジストリを含む、新しい「セッション開始プロトコル（SIP）共通ログ形式（CLF）パラメータ」レジストリを確立します。初期エントリは、両方のサブレジストリについてこの仕様で定義されています。 [Session Initiation Protocol（SIP）Common Log Format（CLF）Parameters]レジストリへの新しいサブレジストリの追加は、[RFC5226]で詳述されているIETFレビュー登録ポリシーを使用して行われます。
This document defines the SIP CLF "Version" field in Section 4.1. IANA has created a registry of Version values entitled "SIP CLF Version Values". Version numbers MUST be incremented for any new SIP CLF protocol specification that changes any part of the SIP CLF record format. Changes include addition or removal of fields or a change of syntax or semantics of existing fields.
このドキュメントでは、セクション4.1のSIP CLF「バージョン」フィールドを定義しています。 IANAは、「SIP CLFバージョン値」というタイトルのバージョン値のレジストリを作成しました。 SIP CLFレコードフォーマットの一部を変更する新しいSIP CLFプロトコル仕様では、バージョン番号をインクリメントする必要があります。変更には、フィールドの追加または削除、または既存のフィールドの構文またはセマンティクスの変更が含まれます。
Version numbers must be registered via the Standards Action method described in [RFC5226]. IANA has registered the Versions shown in Table 1 below.
バージョン番号は、[RFC5226]で説明されている標準アクションメソッドを介して登録する必要があります。 IANAは、以下の表1に示すバージョンを登録しています。
+------------+----------------------+-----------+
| Version | FORMAT | Reference |
+------------+----------------------+-----------+
| 0x41 ('A') | Defined in [RFC6873] | [RFC6873] |
+------------+----------------------+-----------+
Table 1: IANA-Registered SIP CLF Version Values
表1：IANAに登録されたSIP CLFバージョンの値
This document defines the SIP CLF "Transport Flag" as fourth byte in the Flags field of the SIP CLF record. The format and values of the Transport Flag are described in Section 4.2. IANA has created a registry of SIP CLF Transport Flag values titled "SIP CLF Transport Flag Values".
このドキュメントでは、SIP CLF "Transport Flag"をSIP CLFレコードのFlagsフィールドの4番目のバイトとして定義しています。トランスポートフラグの形式と値については、セクション4.2で説明します。 IANAは、「SIP CLFトランスポートフラグ値」というタイトルのSIP CLFトランスポートフラグ値のレジストリを作成しました。
SIP CLF Transport Flag values must be registered via the IETF Review method described in [RFC5226]. IANA has registered the Transport Flag values shown in Table 2 below.
SIP CLFトランスポートフラグの値は、[RFC5226]で説明されているIETFレビューメソッドを介して登録する必要があります。 IANAは、以下の表2に示すトランスポートフラグ値を登録しています。
+-------+--------------------+-----------+
| Value | Transport Protocol | Reference |
+-------+--------------------+-----------+
| U | UDP | [RFC6873] |
| T | TCP | [RFC6873] |
| S | SCTP | [RFC6873] |
+-------+--------------------+-----------+
Table 2: IANA-Registered SIP CLF Transport Flag
表2：IANAに登録されたSIP CLFトランスポートフラグ
The authors of this document would like to acknowledge and thank Peter Musgrave (the chair of the SIPCLF working group) and Robert Sparks (the assigned Area Director) for their support, guidance, and continued invaluable feedback.
このドキュメントの作成者は、サポート、ガイダンス、および継続的な非常に貴重なフィードバックを提供してくれたPeter Musgrave（SIPCLFワーキンググループの議長）とRobert Sparks（担当エリアディレクター）に謝意を表します。
This work benefited from the discussions and invaluable input by the various members of the SIPCLF working group. These include Brian Trammell, Eric Burger, Cullen Jennings, Benoit Claise, Saverio Niccolini, and Dan Burnett. Special thanks to Hadriel Kaplan, Chris Lonvick, Paul E. Jones, John Elwell, Claudio Allocchio, and Joe Clarke for their constructive comments, suggestions, and reviews that were critical to the formulation and refinement of this document.
この作業は、SIPCLFワーキンググループのさまざまなメンバーによる議論と貴重な意見の恩恵を受けました。ブライアントラメル、エリックバーガー、カレンジェニングス、ブノワクレイズ、サヴェリオニコリーニ、ダンバーネットなどです。このドキュメントの作成と改良に不可欠な建設的なコメント、提案、レビューを提供してくれたHadriel Kaplan、Chris Lonvick、Paul E. Jones、John Elwell、Claudio Allocchio、およびJoe Clarkeに特に感謝します。
Thanks to Anders Nygren for his early implementation, insight, and reviews of the SIP CLF format.
Anders NygrenのSIP CLFフォーマットの初期の実装、洞察、レビューに感謝します。
[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月。
[RFC6872] Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O. Festor, "The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model", RFC 6872, February 2013.
[RFC6872] Gurbani、V.、Burger、E.、Anjali、T.、Abdelnur、H。、およびO. Festor、「セッション開始プロトコル（SIP）の共通ログ形式（CLF）：フレームワークと情報モデル」 、RFC 6872、2013年2月。
[PEN] IANA, "Private Enterprise Numbers", 2009, <http://www.iana.org/assignments/enterprise-numbers>.
[PEN] IANA、「Private Enterprise Numbers」、2009、<http://www.iana.org/assignments/enterprise-numbers>。
[RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, July 1990.
[RFC1166] Kirkpatrick、S.、Stahl、M。、およびM. Recker、「インターネット番号」、RFC 1166、1990年7月。
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[RFC4475] Sparks、R.、Hawrylyshen、A.、Johnston、A.、Rosenberg、J.、and H. Schulzrinne、 "Session Initiation Protocol（SIP）Torture Test Messages"、RFC 4475、May 2006。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards、R。、「Syslogプロトコル」、RFC 5424、2009年3月。
[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, August 2009.
[RFC5612] Eronen、P。およびD. Harrington、「ドキュメント使用のためのエンタープライズ番号」、RFC 5612、2009年8月。
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010.
[RFC5737] Arkko、J.、Cotton、M。、およびL. Vegoda、「ドキュメント用に予約されたIPv4アドレスブロック」、RFC 5737、2010年1月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、August 2010。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 6.2.0", (Mountain View, CA: ISBN 978-1-936213-07-8), 2012, <http://www.unicode.org/versions/Unicode6.2.0/>.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard、Version 6.2.0 "、（Mountain View、CA：ISBN 978-1-936213-07-8）、2012、<http://www.unicode.org/versions /Unicode6.2.0/>。
Authors' Addresses
著者のアドレス
Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park、NC 27709 US
EMail: gsalguei@cisco.com
Vijay Gurbani Bell Labs, Alcatel-Lucent 1960 Lucent Lane Rm 9C-533 Naperville, IL 60563 US
Vijay Gurbani Bell Labs、Alcatel-Lucent 1960 Lucent Lane Rm 9C-533 Naperville、IL 60563 US
EMail: vkg@bell-labs.com
Adam Roach Mozilla Dallas, TX US
アダムローチモジラダラス、TX US
EMail: adam@nostrum.com