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
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工作组为会话启动协议（SIP）服务器定义了通用日志格式（CLF）框架。此CLF模仿了Apache等知名web服务器和Squid等web代理中的成功事件日志记录格式。本文档为SIP CLF提出了一种索引文本编码格式，该格式保留了基于文本的格式的主要优点，同时与纯基于文本的实现相比显著提高了处理性能。此文件格式遵循SIP CLF信息模型，并为SIP CLF记录中出现的所有必填字段和可选字段提供有效的编码方案。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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通用日志格式（CLF）的广泛采用促使为会话启动协议（SIP）[RFC3261]开发了类似的事件日志机制。为SIP实现日志记录方案是一个相当大的挑战。部分原因是，与HTTP实体相比，SIP实体的行为更加复杂。此外，纯基于文本的HTTP CLF还存在一些缺点，需要加以解决，以便能够实时检查SIP日志文件[RFC6872]。ApacheCLF的经验表明，处理大量日志数据可能需要非常密集的处理器，因为这样做必然需要读取和解析感兴趣的日志文件中的每个字节。
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.
[RFC6872]中定义了SIP CLF的独立于实现的框架。本备忘录描述了一种索引文本文件格式，用于记录SIP客户端、服务器和代理接收和发送的SIP消息，符合[RFC6872]第8节中介绍的信息模型。本文档定义了一种格式，该格式与标准（即，非索引）文本日志格式相比，日志实体生成该格式并不困难，但处理速度要快得多。特别是，该格式针对快速扫描日志记录和快速定位常用数据字段进行了优化。
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.
此外，本文提出的格式保留了人类可读性的关键优势，并且能够使用各种Unix文本处理工具（如sed、awk、perl、cut和grep）进行处理。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
“应该”、“不应该”、“建议”和“不建议”适用于已知或似乎存在一般要求的有效例外情况，并且列举所有这些例外情况是不可行或不切实际的。然而，它们不应被解释为允许实现者在这种失败将导致互操作性失败时未能实现一般需求。
[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".
[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、第三个值
<allOneLine> Header-name: first value, reallylongsecondvalue , third value </allOneLine>
<allOneLine>标题名称：第一个值、reallylongsecondvalue、第三个值
<allOneLine> Header-name: first value, reallylong second value, third value </allOneLine>
<allOneLine>标题名称：第一个值、reallylong第二个值、第三个值
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.
会话启动协议[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
+-----------+-----------+-----------+-----------+
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 |
+-----------+
| 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中显示的格式用于单个SIP CLF日志条目。虽然在实践中没有实际的细分，但该格式在逻辑上可以细分为以下三个不同的组成部分：
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. 索引指针：此格式的前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. 必填字段：此格式的下一个逻辑分组是以制表符分隔（0x09）的必填字段列表，如[RFC6872]第8.1节所述，并按照<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>
<IndexPointers>
<MandatoryFields>
<OptionalFields>
Figure 2: Logical Structure of the SIP CLF Record
图2:SIPCLF记录的逻辑结构
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>元数据位于一行，而实际数据如<MandatoryFields>和<OptionalFields>（如果存在）位于另一行。
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"
在以下章节中，请注意，“十六进制编码”的指示表示始终无符号的值，并将使用UTF-8字符0x30至0x39（“0”至“9”）和0x41至0x46（“A”至“F”）以人类可读的base-16数字写出。同样，“十进制编码”的指示
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.
指示要使用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.
sipclf记录的<IndexPointers>部分（如图3所示）是一个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
+-----------+-----------+-----------+-----------+
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版本值由IANA通过[RFC5226]中描述的标准操作方法分配（第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字节）：此日志记录的十六进制编码总长度，以“版本”八位字节开始，以终止换行符结束。
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包含十六进制编码的指针，这些指针指向每个可变长度必填字段的起始位置。字节56到59包含一个十六进制编码的指针，该指针指向SIP CLF记录的可选字段部分的起始位置。请注意，这些指针值之间没有分隔符——它们被打包为一个52个字符的十六进制编码字符串。“指针”字段表示记录中的绝对字节值，因此>=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.
可选字段开始指针：最后一个指针指示SIP CLF记录中<OptionalFields>的可选组开始（如果存在）的位置。“可选字段开始指针”指向<OptionalFields>部分中第一个条目的UTF-8制表符（0x09）字符。如果未实现可选的<OptionalFields>，则“OptionalFields 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) |
| |
| |
+-----------+-----------+-----------+-----------+
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>中的指针之后，对两个固定长度字段进行编码，以指定日志项的确切时间。如前所述，所有字段都已完全填充，根据需要使用“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日午夜起的秒数，GMT）。
Fractional Seconds (3 bytes): Decimal encoded fractional seconds portion of the Timestamp field to millisecond accuracy.
分数秒（3字节）：时间戳字段的十进制编码分数秒部分，精确到毫秒。
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.
时间戳和小数秒字段组合在日志文件中表示为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、DTL等）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:
“时间戳”、“分数秒”和“标志”字段后是[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：起始行中的请求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]以“点十进制”表示。IPv6地址使用[RFC5952]第4节详述的十六进制表示法（或[RFC5952]第5节详述的特殊情况混合十六进制和十进制表示法）表示，并用方括号（“[”和“]”）括起来。
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]以“点十进制”表示。IPv6地址使用[RFC5952]第4节详述的十六进制表示法（或[RFC5952]第5节详述的特殊情况混合十六进制和十进制表示法）表示，并用方括号（“[”和“]”）括起来。
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 Tag：From标头字段中标记参数（如果存在）的值。
Call-Id: The value of the Call-ID header field.
Call Id：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.)
服务器事务标识码（服务器Txn）：与服务器事务关联的事务标识符。实现可以重用服务器事务标识符（传入请求的最顶层分支id，带或不带magic cookie），也可以为服务器事务生成唯一的标识字符串（该标识符只需在本地对服务器唯一）。此标识符用于将确认和取消与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.)
客户端事务标识码（客户端Txn）：此字段用于将客户端事务与用于分叉代理或B2BUA的服务器事务相关联。分叉后，实现可以重用通过标头的分支参数插入到最顶端的值，或者为客户端事务生成唯一的标识字符串。（有关用法，请参见[RFC6872]第9节。）
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.
注意：服务器Txn和客户端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>中列出的顺序显示，并且每个字段都必须存在。字段的最大SIP CLF字段大小为4096字节，详见[RFC6872]第8节。
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头中没有标准化地使用制表符来传达除空格以外的任何其他含义。选项卡可能出现在消息正文中，如果正文被记录，则从相应的日志条目重建正文时，向空间的转换可能会导致问题。决定用空格字符替换制表符的两个后果是：（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记录中。在这种情况下，如果[RFC6872]第4.2节和第8.1节中规定的给定必填字段不存在，则该空字段必须编码为单个水平划线（“-”）。如果字段解析失败，则必须将其编码为单个问号（“？”）。如果这些字符是其他字符序列的一部分，则不存在歧义。如果正在记录的字段仅包含一个字符，并且该字符是文本“-”，则实现应在SIP CLF记录中为该字段插入转义的%2D。类似地，如果该字段仅包含一个字符，且该字符为文字“？”，则实现应在SIP CLF记录中为该字段插入转义的%3F。
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）。由于SIP标头字段值中不允许存在裸CRLF序列，因此在记录时，必填字段不得包含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 CLF格式，SIP解析器不可能完全解析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消息相关的信息丢失。日志读取器永远不应该取消SIP CLF记录中的任何内容，因为它们将使用文本工具（如grep和awk）进行机器处理。日志读取器后面的人类用户可能需要推断原始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) | /
| |/
+-----------+-----------+-----------+-----------+
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>部分之后，有一个可选的<OptionalFields>组（如图5所示），它可能出现零次或多次。此<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:
必须按照图5所示的格式记录任何可选的SIP元素。SIP CLF记录中<OptionalFields>的开始位置由<IndexPointers>中的“可选字段开始指针”字段指示。在图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）由两个字节的标记和八个字节的供应商ID（均为十进制编码）组成，由“@”字符（0x40）分隔。这将唯一标识正在记录的可选字段。该标识符的格式松散地模仿了syslog协议[RFC5424]使用的专用选项（注：这是[RFC5424]第6.3.2节中详述的第二种格式）。它使用私有企业编号（PEN），该编号通过全局唯一的名称空间[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编码字节（BEB）是一个布尔值，用于指示正在记录的可选元素是否为Base64编码。正在记录的可选元素的值字段如果有任何“无法打印”的字符，则必须采用Base64编码。在本文件中，我们将“不可打印”定义为一组八位字节：（a）包含一个值范围为0到31（包括0到31）的八位字节；（b） 包含一个值为127的八位字节；或（c）包含大于或等于128的任何八位字节序列，这些八位字节不构成[UNICODE]指定的有效UTF-8序列。如果正在记录的可选元素是Base64编码的，则BEB=0x01；如果它不是Base64编码的，则BEB=0x00。
Optional fields are logged according to the following two syntax rules:
根据以下两种语法规则记录可选字段：
(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:
供应商ID为零用于记录整个SIP消息、消息正文、原因短语或不属于[RFC6872]第8.1节详述的必填字段列表一部分的任何SIP头字段。以下标记值用于标识正在记录哪些可选元素：
Tag = 00 - Log SIP Header Field or Reason-Phrase
Tag=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.
因为响应中的原因短语是状态行的一部分，并且没有用字段名标识，所以它是一种特殊情况。在本例中，关联的“值”字段必须由名称“原因短语”填充，后跟冒号（：”）以及冒号和记录的原因短语值之间的单个空格（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，根据SIP头字段值是否包含任何“不可打印”字符来设置BEB。如果没有，则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
如果可选字段在SIP消息中出现不止一次（例如，联系人、路由、记录路由等），则每次出现都必须使用与SIP CLF记录中的不同可选字段条目相同的标记值（即标记=00）进行记录。这些重复的可选记录的头字段必须保留重复头字段在SIP头中的顺序位置。例如，SIP头包含两个Via头字段，在SIP头中具有以下顺序位置：V1、V2。如果有选择地记录这些头字段，它们将作为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 CLF记录的其余部分）：
00@00000000,len_V1,00,Via: V1 00@00000000,len_V2,00,Via: V2
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）。由于SIP标头字段值中不允许存在裸CRLF序列，因此，在记录时，使用Tag=00记录的可选SIP标头字段不得包含CRLF，因此不需要转义机制。
Tag = 01 - Log message body
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.
可以选择使用Tag=01记录所有类型的SIP消息体。如果记录了消息正文，则必须遵守SIP CLF字段的最大大小限制4096字节，详见[RFC6872]第8节。与Tag=00不同，Tag=01的SIP CLF记录中只能有一个条目。当可选地记录消息正文时，如果超过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）时，关联的“Value”字段将填充内容类型本身以及用空格分隔的SIP消息正文。通过这种方式，与为每个主体类型枚举单独的标记相比，SIP消息主体的所有内容都是使用单个标记进行自我描述的。此外，相应的“长度”字段包括SIP消息正文、嵌入内容类型的长度以及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，则后面的消息正文完全是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
如果可选记录的SIP消息正文包含任何CRLF，则必须使用URI编码的等效值“%0D%0A”对其进行转义。此转义机制适用于所有车身类型。因此，我们在治疗中对各种可能的身体类型没有任何区别。如果记录的消息正文具有BEB=01，则必须在任何字符转义之前对其进行Base64编码。因此，如果记录了二进制体（如图像），则
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.
将首先进行Base64编码，并且Base64字符流不能包含“%0D%0A”的CRLF转义序列，因为“%”不是有效的Base64字符。
Tag = 02 - Log entire SIP message
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.
可以选择使用标记=02记录整个SIP消息（即SIP头和消息体）。记录整个SIP消息必须符合SIP CLF字段4096字节的最大大小限制，详见[RFC6872]第8节。与Tag=00不同，Tag=02的SIP CLF记录中只能有一个条目。当可选地记录整个SIP消息时，如果超过4096字节的最大SIP CLF字段大小，则必须截断正在记录的整个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）时，在解码之前不知道内容类型。
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.
必须使用URI编码的等效值“%0D%0A”对CRLF的所有实例（无论它们出现在SIP头中还是SIP消息正文中）进行转义。如果记录的SIP消息具有BEB=01，则必须在任何字符转义之前对其进行Base64编码。
(2) Vendor-ID = PEN
(2) 供应商ID=笔
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
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),
长度字段（4字节）：表示该可选记录元素的“值”字段的长度（如图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.
十六进制编码。该长度仅对应于“Value”字段的长度，不得包括图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
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:
联系人标题字段将以以下方式记录为可选字段：
00@00000000,001C,00,Contact: <sip:bob@192.0.2.4>
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响应，原因短语将以以下方式记录为可选字段：
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=IP4 host.example.com中的alice 2890844526 2890844526 s=-c=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字节，包括所有换行符。记录此正文时，“值”字段由内容类型和正文组成，正文之间用空格分隔，这使其组合长度为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>
<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.
请注意，正文实际上记录在一行上，因此在<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节中所示的多部分/mime SIP消息的第二个正文部分是二进制编码正文（以十六进制表示），如果记录，则BEB=01，需要Base64编码。该二进制体经过Base64编码后将产生六行输出。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>
<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.
请注意，正文实际上记录在一行上，因此在<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
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
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:
供应商可以选择记录SIP消息元素，例如来自SDP主体的编解码器信息。此供应商指定的SIP元素将以以下方式记录为可选字段：
03@00032473,0014,00,a=rtpmap:0 PCMU/8000
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
07@00032473，0016,001877 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].
这意味着这是来自peering partner example.com的1877条消息。请注意，前两个示例显示了可选记录的供应商指定的SIP元素，使用私有企业编号为32473的供应商ID。IANA已根据[RFC5612]保留该值，用作文档中的示例笔。
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
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
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约定，此日志条目被分成五行，而不是实际出现在日志文件中的两行；制表符已经用空格填充，以模拟它们在文本终端中的外观。
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>
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== ====
begin-base64 644 clf_record QTAwMDEwMCwwMDUzMDA1QzAwNUUwMDZEMDA3RDAwOEYwMDlFMDBBMDAwQkEwMEM3MDBF QjAwRjcwMTAwCjEzMjg4MjExNTMuMDEwCVJPUlVVCTEgSU5WSVRFCS0Jc2lwOjE5Mi4w LjIuMTAJMTkyLjAuMi4xMDo1MDYwCTE5Mi4wLjIuMjAwOjU2NDg1CXNpcDoxOTIuMC4y LjEwCS0Jc2lwOjEwMDFAZXhhbXBsZS5jb206NTA2MAlETDg4MzYwZmE1ZmMJREw3MGRm ZjU5MGMxLTEwNzkwNTE1NTRAZXhhbXBsZS5jb20JUzE3ODE3NjEtODgJQzY3NjUxLTEx Cg== ====translate error, please retry
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);
#!/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]*)/.
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.
为了保护SIP CLF文件中包含的敏感信息，[RFC6872]注意到，在域之间交换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版本值”和“SIP CLF传输标志值”。本规范为两个子注册中心定义了初始条目。在“会话启动协议（SIP）通用日志格式（CLF）参数”注册表中添加任何新的子注册表时，应使用[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] |
+------------+----------------------+-----------+
+------------+----------------------+-----------+
| 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“传输标志”定义为SIP CLF记录的标志字段中的第四个字节。运输标志的格式和值见第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] |
+-------+--------------------+-----------+
+-------+--------------------+-----------+
| 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：会话启动协议”，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，“私营企业编号”，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，“互联网号码”，RFC1166，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.，和H.Schulzrinne，“会话启动协议（SIP）酷刑测试消息”，RFC 4475，2006年5月。
[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，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年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.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[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联盟，“UNICODE标准，版本6.2.0”，（加利福尼亚州山景城：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思科系统7200-12美国北卡罗来纳州Kit Creek Road研究三角公园，邮编27709
EMail: gsalguei@cisco.com
EMail: gsalguei@cisco.com
Vijay Gurbani Bell Labs, Alcatel-Lucent 1960 Lucent Lane Rm 9C-533 Naperville, IL 60563 US
Vijay Gurbani Bell实验室，阿尔卡特朗讯1960朗讯巷，美国伊利诺伊州纳珀维尔9C-533室，邮编60563
EMail: vkg@bell-labs.com
EMail: vkg@bell-labs.com
Adam Roach Mozilla Dallas, TX US
美国德克萨斯州达拉斯的亚当·罗奇·莫兹拉
EMail: adam@nostrum.com
EMail: adam@nostrum.com