Internet Engineering Task Force (IETF) V. Gurbani, Ed.
Request for Comments: 6872 Bell Laboratories, Alcatel-Lucent
Category: Standards Track E. Burger, Ed.
ISSN: 2070-1721 Georgetown University
T. Anjali
Illinois Institute of Technology
H. Abdelnur
O. Festor
INRIA
February 2013
Internet Engineering Task Force (IETF) V. Gurbani, Ed.
Request for Comments: 6872 Bell Laboratories, Alcatel-Lucent
Category: Standards Track E. Burger, Ed.
ISSN: 2070-1721 Georgetown University
T. Anjali
Illinois Institute of Technology
H. Abdelnur
O. Festor
INRIA
February 2013
The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model
会话启动协议（SIP）的通用日志格式（CLF）：框架和信息模型
Abstract
摘要
Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de facto standard formats are invaluable to system administrators for troubleshooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and, as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of a SIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents.
众所周知的web服务器（如Apache）和web代理（如Squid）支持使用通用日志格式记录事件。使用这些事实上的标准格式生成的日志对于系统管理员来说是非常宝贵的，可以帮助他们对服务器进行故障排除，也可以帮助工具编写者制作工具来挖掘日志文件并生成报告和趋势。此外，这些日志文件还可用于培训异常检测系统，并将事件提供给安全事件管理系统。会话启动协议（SIP）没有通用的日志格式，因此，每个服务器都支持不同的日志格式，这使得生成用于进行趋势分析和安全检测的工具变得不必要的复杂。本文档描述了一个框架，包括对现有方法的需求和分析，并指定了用于开发SIP通用日志文件格式的信息模型，该格式可由用户代理、代理、注册器和重定向服务器以及背对背用户代理统一使用。
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/rfc6872.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6872.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（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 .....................................................4
3. Problem Statement ...............................................4
4. What SIP CLF Is and What It Is Not ..............................5
5. Alternative Approaches to SIP CLF ...............................5
5.1. SIP CLF and Call Detail Records ............................6
5.2. SIP CLF and Packet Capture Tools ...........................6
5.3. SIP CLF and Syslog .........................................7
5.4. SIP CLF and IPFIX ..........................................8
6. Motivation and Use Cases ........................................8
7. Challenges in Establishing a SIP CLF ...........................10
8. Information Model ..............................................11
8.1. SIP CLF Mandatory Fields ..................................11
8.2. Mandatory Fields and SIP Entities .........................13
9. Examples .......................................................14
9.1. UAC Registration ..........................................15
9.2. Direct Call between Alice and Bob .........................17
9.3. Single Downstream Branch Call .............................20
9.4. Forked Call ...............................................25
10. Security Considerations .......................................35
11. Operational Guidance ..........................................37
12. Acknowledgments ...............................................37
13. References ....................................................37
13.1. Normative References .....................................37
13.2. Informative References ...................................38
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Problem Statement ...............................................4
4. What SIP CLF Is and What It Is Not ..............................5
5. Alternative Approaches to SIP CLF ...............................5
5.1. SIP CLF and Call Detail Records ............................6
5.2. SIP CLF and Packet Capture Tools ...........................6
5.3. SIP CLF and Syslog .........................................7
5.4. SIP CLF and IPFIX ..........................................8
6. Motivation and Use Cases ........................................8
7. Challenges in Establishing a SIP CLF ...........................10
8. Information Model ..............................................11
8.1. SIP CLF Mandatory Fields ..................................11
8.2. Mandatory Fields and SIP Entities .........................13
9. Examples .......................................................14
9.1. UAC Registration ..........................................15
9.2. Direct Call between Alice and Bob .........................17
9.3. Single Downstream Branch Call .............................20
9.4. Forked Call ...............................................25
10. Security Considerations .......................................35
11. Operational Guidance ..........................................37
12. Acknowledgments ...............................................37
13. References ....................................................37
13.1. Normative References .....................................37
13.2. Informative References ...................................38
Servers executing on Internet hosts produce log records as part of their normal operations. Some log records are, in essence, a summary of an application-layer protocol data unit (PDU) that captures, in precise terms, an event that was processed by the server. These log records serve many purposes including analysis and troubleshooting.
作为正常操作的一部分，在Internet主机上执行的服务器会生成日志记录。某些日志记录本质上是应用层协议数据单元（PDU）的摘要，它准确地捕获了服务器处理的事件。这些日志记录有很多用途，包括分析和故障排除。
Well-known web servers such as Apache and web proxies like Squid support event logging using a Common Log Format (CLF), the common structure for logging requests and responses serviced by the web server. It can be argued that a good part of the success of Apache has been its CLF because it allowed third parties to produce tools that analyzed the data and generated traffic reports and trends. The Apache CLF has been so successful that not only did it become the de facto standard in producing logging data for web servers but also many commercial web servers can be configured to produce logs in this format. An example of the Apache CLF is depicted next:
众所周知的web服务器（如Apache）和web代理（如Squid）支持使用公共日志格式（CLF）记录事件，这是用于记录由web服务器服务的请求和响应的公共结构。可以说，Apache的成功很大一部分在于它的CLF，因为它允许第三方生成分析数据并生成流量报告和趋势的工具。ApacheCLF非常成功，它不仅成为为web服务器生成日志数据的事实标准，而且许多商业web服务器也可以配置为以这种格式生成日志。下面将描述Apache CLF的一个示例：
%h %l %u %t \"%r\" %s %b remotehost rfc931 authuser [date] request status bytes
%h%l%u%t\%r\%s%b远程主机rfc931身份验证用户[日期]请求状态字节
remotehost: Remote hostname (or IP number if DNS hostname is not available or if DNSLookup is Off.
remotehost：远程主机名（如果DNS主机名不可用或如果DNSLookup关闭，则为IP号）。
rfc931: The remote logname of the user.
rfc931:用户的远程日志名。
authuser: The username by which the user has authenticated himself.
authuser：用户对自己进行身份验证的用户名。
[date]: Date and time of the request.
[日期]：请求的日期和时间。
request: The request line exactly as it came from the client.
请求：请求行与来自客户端的请求行完全相同。
status: The HTTP status code returned to the client.
状态：返回给客户端的HTTP状态代码。
bytes: The content-length of the document transferred.
字节：传输的文档的内容长度。
The inspiration for the SIP CLF is the Apache CLF. However, the state machinery for an HTTP transaction is much simpler than that of the SIP transaction (as evidenced in Section 7). The SIP CLF needs to do considerably more.
SIPCLF的灵感来自ApacheCLF。然而，HTTP事务的状态机制比SIP事务的状态机制简单得多（如第7节所示）。SIP CLF需要做更多的工作。
This document outlines the problem statement that argues for a SIP CLF. In addition, it provides an information model pertaining to the minimum set of SIP headers and fields that must be logged. This document does not prescribe a specific representation format for the
本文档概述了支持SIP CLF的问题陈述。此外，它还提供了与必须记录的最小SIP头和字段集相关的信息模型。本文件未规定本文件的具体表述格式
SIP CLF record and, instead, allows other documents to define a representation format. [RFC6873] is an example of a representation format that provides a UTF-8-based logging scheme.
SIPCLF记录，并允许其他文档定义表示格式。[RFC6873]是提供基于UTF-8的日志记录方案的表示格式的示例。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
RFC 3261 [RFC3261] defines additional terms used in this document
that are specific to the SIP domain such as "proxy"; "registrar";
"redirect server"; "user agent server" or "UAS"; "user agent client"
or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog";
"transaction"; "server transaction".
RFC 3261 [RFC3261] defines additional terms used in this document
that are specific to the SIP domain such as "proxy"; "registrar";
"redirect server"; "user agent server" or "UAS"; "user agent client"
or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog";
"transaction"; "server transaction".
This document uses the term "SIP server" that is defined to include the following SIP entities: user agent server, registrar, redirect server, a SIP proxy in the role of user agent server, and a B2BUA in the role of a user agent server.
本文档使用术语“SIP服务器”，该术语定义为包括以下SIP实体：用户代理服务器、注册器、重定向服务器、扮演用户代理服务器角色的SIP代理以及扮演用户代理服务器角色的B2BUA。
The Session Initiation Protocol (SIP) [RFC3261] is an Internet multimedia session signaling protocol. A typical deployment of SIP in an enterprise will consist of SIP entities from multiple vendors. Each SIP entity produces logs using a proprietary format. The result of multiplicity of the log file formats is the inability of the support staff to easily trace a call from one entity to another or even to craft common tools that will perform trend analysis, debugging and troubleshooting problems uniformly across the SIP entities from multiple vendors.
会话发起协议（SIP）[RFC3261]是一种因特网多媒体会话信令协议。企业中SIP的典型部署将由来自多个供应商的SIP实体组成。每个SIP实体使用专有格式生成日志。日志文件格式的多样性导致支持人员无法轻松地跟踪从一个实体到另一个实体的呼叫，甚至无法设计通用工具，以便在多个供应商的SIP实体中统一执行趋势分析、调试和故障排除。
Furthermore, the log file must be easily accessible by command-line tools for simple text processing. This allows ad hoc queries against the elements in the log file to retrieve a log record. Furthermore, the log file must be in a format that allows for rapid searches of a particular log record (or records). Because of the large number of records expected in the log file, the records must be in a format that allows for rapid scanning and ease of skipping records that do not match a search criterion. Finally, the generation of the log file must not impose undue burden on the SIP implementation in the form of additional libraries that may not be uniformly available on different platforms and operating environments where a SIP entity generating a log file record may be found.
此外，日志文件必须易于通过命令行工具访问，以便进行简单的文本处理。这允许对日志文件中的元素进行特殊查询以检索日志记录。此外，日志文件的格式必须允许快速搜索特定日志记录。由于日志文件中预期会有大量记录，因此记录的格式必须允许快速扫描和轻松跳过与搜索条件不匹配的记录。最后，日志文件的生成不得以附加库的形式对SIP实现施加不适当的负担，这些附加库可能无法在不同的平台和操作环境中统一使用，其中可能会找到生成日志文件记录的SIP实体。
SIP does not currently have a common log format, and this document serves to provide the rationale to establish a SIP CLF and identifies the required minimal information that must appear in any SIP CLF record.
SIP目前没有通用的日志格式，本文件旨在提供建立SIP CLF的基本原理，并确定任何SIP CLF记录中必须出现的最低限度的信息。
The SIP CLF is a standardized manner of producing a log file. This format can be used by SIP clients, SIP servers, proxies, and B2BUAs. The SIP CLF is simply an easily digestible log of currently occurring events and past transactions. It contains enough information to allow humans and automata to derive relationships between discrete transactions handled at a SIP entity or to search for a certain dialog or a related set of transactions.
SIP CLF是生成日志文件的标准化方式。此格式可由SIP客户端、SIP服务器、代理和B2BUA使用。SIPCLF只是当前发生的事件和过去事务的易于理解的日志。它包含足够的信息，使人类和自动机能够导出SIP实体处理的离散事务之间的关系，或搜索特定对话框或相关事务集。
The SIP CLF is amenable to quick parsing (i.e., well-delimited fields), and it is platform and operating system neutral.
SIP CLF适合于快速解析（即，分隔良好的字段），并且与平台和操作系统无关。
Due to the structure imposed by delimited fields, the SIP CLF is amenable to easy parsing and lends itself well to creating other innovative tools such as logfile parsers and trend analytic engines.
由于分隔字段所施加的结构，SIP CLF易于解析，并适合创建其他创新工具，如日志文件解析器和趋势分析引擎。
The SIP CLF is not a billing tool. It is not expected that enterprises will bill customers based on SIP CLF. The SIP CLF records events at the signaling layer only and does not attempt to correlate the veracity of these events with the media layer. Thus, it cannot be used to trigger customer billing.
SIP CLF不是计费工具。预计企业不会根据SIP CLF向客户计费。SIP CLF仅在信令层记录事件，不尝试将这些事件的准确性与媒体层关联。因此，它不能用于触发客户账单。
The SIP CLF is not a quality of service (QoS) measurement tool. If QoS is defined as measuring the mean opinion score (MOS) of the received media, then SIP CLF does not aid in this task since it does not summarize events at the media layer.
SIP CLF不是服务质量（QoS）测量工具。如果QoS定义为测量所接收媒体的平均意见分数（MOS），则SIP CLF不帮助执行此任务，因为它不汇总媒体层的事件。
Finally, the SIP CLF is not a tool for supporting lawful intercept.
最后，SIP CLF不是支持合法拦截的工具。
The sipclf working group discussed four alternative approaches to determine whether they fill the requirements of what is desired of a SIP CLF outlined in Section 3. We conclude that while every scheme discussed below comes with its advantages, its disadvantages may preclude it from being used as a SIP CLF. However, we stress that the information model contained in this document can be used to develop alternative representation formats when desired. Currently, [RFC6873] is an example of a representation format that provides a UTF-8-based logging scheme that meets all the requirements of Section 3.
sipclf工作组讨论了四种备选方法，以确定它们是否满足第3节所述SIP CLF的要求。我们的结论是，虽然下面讨论的每个方案都有其优点，但其缺点可能会阻止其用作SIP CLF。然而，我们强调，本文档中包含的信息模型可用于在需要时开发替代表示格式。目前，[RFC6873]是一种表示格式的示例，它提供了一种基于UTF-8的日志记录方案，满足第3节的所有要求。
Call Detail Records (CDRs) are used in operator networks widely and with the adoption of SIP, standardization bodies such as the Third Generation Partnership Project (3GPP) have subsequently defined SIP-related CDRs as well. Today, CDRs are used to implement the functionality approximated by SIP CLF; however, there are important differences.
呼叫详细记录（CDR）在运营商网络中广泛使用，随着SIP的采用，诸如第三代合作伙伴计划（3GPP）等标准化机构随后也定义了与SIP相关的CDR。如今，CDR被用来实现SIP CLF近似的功能；然而，也有重要的区别。
First, SIP CLF operates natively at the transaction layer and maintains enough information in the information elements being logged that dialog-related data can be subsequently derived from the transaction logs. Thus, esoteric SIP fields and parameters like the To header (including tags), the From header (including tags), the Command Sequence (CSeq) number, etc., are logged in SIP CLF. By contrast, a CDR is used mostly for charging and thus saves information to facilitate that very aspect. A CDR will most certainly log the public user identification of a party requesting a service (which may not correspond to the From header) and the public user identification of the party called party (which may not correspond to the To header). Furthermore, the sequence numbers maintained by the CDR may not correspond to the SIP CSeq header. Thus, it will be hard to piece together the state of a dialog through a sequence of CDR records.
首先，SIP CLF在事务层进行本机操作，并在记录的信息元素中维护足够的信息，以便随后可以从事务日志中导出与对话框相关的数据。因此，诸如To报头（包括标记）、From报头（包括标记）、命令序列（CSeq）号等深奥的SIP字段和参数记录在SIP CLF中。相比之下，CDR主要用于充电，因此可以保存信息以方便这方面的工作。CDR肯定会记录请求服务的一方的公共用户标识（可能不对应于From报头）和被叫方的公共用户标识（可能不对应于to报头）。此外，由CDR维护的序列号可能不对应于SIP CSeq报头。因此，很难通过一系列CDR记录拼凑出对话框的状态。
Second, a CDR record will, in all probability, be generated at a SIP entity performing some form of proxy-like functionality of a B2BUA providing some service. By contrast, SIP CLF is lightweight enough that it can be generated by a canonical SIP user agent server and user agent client as well, including those that execute on resource constrained devices (mobile phones).
第二，CDR记录很可能在执行提供某种服务的B2BUA的某种形式的代理功能的SIP实体处生成。相比之下，SIP CLF足够轻量级，可以由规范的SIP用户代理服务器和用户代理客户端（包括在资源受限设备（移动电话）上执行的客户端）生成。
Finally, SIP is also being deployed outside of operator-managed Voice over IP (VoIP) networks. Universities, research laboratories, and small-to medium-sized companies are deploying SIP-based VoIP solutions on networks owned and managed by them. Many of the latter constituencies will not have an interest in generating CDRs, but they will like to have a concise representation of the messages being handled by the SIP entities in a common format.
最后，SIP也部署在运营商管理的IP语音（VoIP）网络之外。大学、研究实验室和中小型公司正在其拥有和管理的网络上部署基于SIP的VoIP解决方案。后一类用户中的许多人对生成CDR不感兴趣，但他们希望以通用格式简洁地表示SIP实体正在处理的消息。
Wireshark and tcpdump are popular raw packet capture tools. Wireshark even contains filters that can understand SIP at the protocol level and break down a captured message into its individual header components. While packet capture tools are appropriate to capture and view discrete SIP messages, they do not suffice to serve in the same capacity as SIP CLF for the following reasons:
Wireshark和tcpdump是流行的原始数据包捕获工具。Wireshark甚至包含可以在协议级别理解SIP的过滤器，并将捕获的消息分解为单独的头组件。虽然数据包捕获工具适用于捕获和查看离散的SIP消息，但由于以下原因，它们不足以以与SIP CLF相同的容量提供服务：
o Using packet capturing tools will not eliminate the need for agreeing to a common set of fields to represent a SIP CLF record. This common understanding is important for interoperability to allow one implementation to read a log file written by a different implementation.
o 使用数据包捕获工具不会消除同意一组公共字段来表示SIP CLF记录的需要。这种共识对于互操作性非常重要，它允许一个实现读取由另一个实现编写的日志文件。
o The packet capture from these tools is not easily searchable by simple command-line tools for text processing.
o 从这些工具捕获的数据包不容易被用于文本处理的简单命令行工具搜索。
o Using packet capture tools requires that the underlying libraries related to packet capture be available for all platforms on which a SIP server or a SIP client can execute. Given the different platforms on which a SIP client or server runs --- mobile, fixed host, tablet, etc. --- this may become an inhibiting factor when compared to the SIP client or server producing a SIP CLF record natively (the SIP client or server has already parsed the SIP message for operation on it; therefore, it seems reasonable to have it write the parsed tokens out to persistent store in an agreed upon format).
o 使用数据包捕获工具要求与数据包捕获相关的底层库可用于SIP服务器或SIP客户端可以执行的所有平台。考虑到SIP客户机或服务器运行的不同平台（移动、固定主机、平板电脑等），与本机生成SIP CLF记录的SIP客户机或服务器相比，这可能成为一个抑制因素（SIP客户端或服务器已经解析了SIP消息，以便对其进行操作；因此，让它以约定的格式将解析后的令牌写入持久存储似乎是合理的）。
o If SIP messages are exchanged over a secure transport (TLS) packet, capture tools will be unable to decrypt them and render them as individual SIP headers.
o 如果SIP消息通过安全传输（TLS）数据包交换，则捕获工具将无法解密它们并将其呈现为单个SIP头。
o Using such tools and related packet capture libraries may imposes a dependency on a third-party library.
o 使用这些工具和相关的包捕获库可能会对第三方库产生依赖。
The syslog protocol [RFC5424] conveys event notification messages from an originator to a collector. While the syslog protocol provides a packet format and transport mechanism, it does not describe any storage format for syslog messages. Pragmatically, while the syslog protocol itself does not describe a storage format, the collector will write the arriving messages into a disk file. A new problem arises due to the general nature of syslog: the disk file will contain log messages from many originators, not just SIP entities. This imposes an additional burden of discarding all extraneous records when analyzing the disk file for SIP CLF records of interest. SIP CLF records are best stored in a log file that is easily searchable by command-line tools.
系统日志协议[RFC5424]将事件通知消息从发起者传送到收集器。虽然syslog协议提供了数据包格式和传输机制，但它没有描述syslog消息的任何存储格式。实际上，虽然syslog协议本身并不描述存储格式，但收集器会将到达的消息写入磁盘文件。由于syslog的一般性质，出现了一个新问题：磁盘文件将包含来自许多发起者的日志消息，而不仅仅是SIP实体。在分析磁盘文件中感兴趣的SIP CLF记录时，这增加了丢弃所有无关记录的额外负担。SIP CLF记录最好存储在日志文件中，该日志文件可以通过命令行工具轻松搜索。
Other drawbacks of using syslog include the unavailability of the collector under certain scenarios (a mobile SIP phone may be unable to find a collector to which it should send the messages), and the need to have syslog-specific libraries available for each platform on which the SIP server or the SIP client can execute. Finally, because of the frequency and size of SIP log messages, it is not desirable to
使用syslog的其他缺点包括收集器在某些情况下不可用（移动SIP电话可能无法找到它应该向其发送消息的收集器），以及需要为SIP服务器或SIP客户端可以执行的每个平台提供syslog特定的库。最后，由于SIP日志消息的频率和大小，不希望
send every SIP CLF log message to the collector. Instead, a judicious use of syslog could be that only certain events -- those that are pertinent from a network situational awareness perspective, or those that include a periodic statistical summary of the messages processed -- are sent to the collector.
将每个SIP CLF日志消息发送到收集器。相反，明智地使用syslog可以是只将某些事件（从网络态势感知的角度来看是相关的事件，或者包括所处理消息的定期统计摘要的事件）发送到收集器。
The IP Flow Information Export (IPFIX) protocol [RFC5101] allows network administrators to aggregate IP packets characterized by some commonality (similar packet header fields, one or more characteristics of the packet itself) into a flow that can be subsequently collected and sent to other elements for analysis and monitoring. However, IPFIX is not a logging format and does not produce a log file that can be examined by ad hoc text processing tools.
IP流信息导出（IPFIX）协议[RFC5101]允许网络管理员将具有某些共性（类似的数据包头字段、数据包本身的一个或多个特征）的IP数据包聚合到一个流中，该流随后可以被收集并发送到其他元素进行分析和监控。但是，IPFIX不是一种日志格式，也不会生成可由特殊文本处理工具检查的日志文件。
As SIP becomes pervasive in multiple business domains and ubiquitous in academic and research environments, it is beneficial to establish a CLF for the following reasons:
随着SIP在多个业务领域中的普及以及在学术和研究环境中的普遍存在，出于以下原因建立CLF是有益的：
Common reference for interpreting events: In a laboratory environment or an enterprise service offering, there will typically be SIP entities from multiple vendors participating in routing requests. Absent a common log format, each entity will produce output records in a native format, making it hard to establish commonality for tools that operate on the log file.
解释事件的通用参考：在实验室环境或企业服务产品中，通常会有来自多个供应商的SIP实体参与路由请求。如果没有通用的日志格式，每个实体将以本机格式生成输出记录，因此很难为操作日志文件的工具建立通用性。
Writing common tools: A common log format allows independent tool providers to craft tools and applications that interpret the CLF data to produce insightful trend analysis and detailed traffic reports. The format should be such that it retains the ability to be read by humans and processed using traditional Unix text processing tools.
编写通用工具：通用日志格式允许独立的工具提供商编写解释CLF数据的工具和应用程序，以生成深入的趋势分析和详细的流量报告。该格式应确保它能够被人读取并使用传统的Unix文本处理工具进行处理。
Session correlation across diverse processing elements: In operational SIP networks, a request will typically be processed by more than one SIP server. A SIP CLF will allow the network operator to trace the progression of the request (or a set of requests) as they traverse through the different servers to establish a concise diagnostic trail of a SIP session.
跨不同处理元素的会话关联：在可操作的SIP网络中，请求通常由多个SIP服务器处理。SIP CLF将允许网络运营商在请求（或一组请求）穿过不同服务器时跟踪其进程，以建立SIP会话的简明诊断线索。
Note that tracing the request through a set of servers is considerably less challenging if all the servers belong to the same administrative domain.
请注意，如果所有服务器都属于同一管理域，则通过一组服务器跟踪请求的难度要小得多。
Message correlation across transactions: A SIP CLF can enable a quick lookup of all messages that comprise a transaction (e.g., "Find all messages corresponding to server transaction X, including all forked branches.").
跨事务的消息关联：SIP CLF可以快速查找组成事务的所有消息（例如，“查找与服务器事务X对应的所有消息，包括所有分叉分支”）。
Message correlation across dialogs: A SIP CLF can correlate transactions that comprise a dialog (e.g., "Find all messages for dialog created by Call-ID C, From tag F and To tag T.").
跨对话框的消息关联：SIP CLF可以关联组成对话框的事务（例如，“查找由调用ID C创建的对话框的所有消息，从标记F到标记T”）。
Trend analysis: A SIP CLF allows an administrator to collect data and spot patterns or trends in the information (e.g., "What is the domain where the most sessions are routed to between 9:00 AM and 1:00 PM?").
趋势分析：SIP CLF允许管理员收集数据并发现信息中的模式或趋势（例如，“上午9:00到下午1:00之间最多会话路由到哪个域？”）。
Train anomaly detection systems: A SIP CLF will allow for the training of anomaly detection systems that once trained can monitor the CLF file to trigger an alarm on the subsequent deviations from accepted patterns in the data set. Currently, anomaly detection systems monitor the network and parse raw packets that comprise a SIP message -- a process that is unsuitable for anomaly detection systems [rieck2008]. With all the necessary event data at their disposal, network operations managers and information technology operation managers are in a much better position to correlate, aggregate, and prioritize log data to maintain situational awareness.
列车异常检测系统：SIP CLF将允许对异常检测系统进行培训，一旦培训后，该系统可以监控CLF文件，从而在数据集中接受模式的后续偏差上触发警报。目前，异常检测系统监控网络并解析包含SIP消息的原始数据包——这一过程不适用于异常检测系统[rieck2008]。网络运营经理和信息技术运营经理掌握了所有必要的事件数据，因此能够更好地关联、聚合日志数据并确定其优先级，以保持态势感知。
Testing: A SIP CLF allows for automatic testing of SIP equipment by writing tools that can parse a SIP CLF file to ensure behavior of a device under test.
测试：SIP CLF允许通过编写能够解析SIP CLF文件的工具来自动测试SIP设备，以确保被测设备的行为。
Troubleshooting: A SIP CLF can enable cursory troubleshooting of a SIP entity (e.g., "How long did it take to generate a final response for the INVITE associated with Call-ID X?").
疑难解答：SIP CLF可以对SIP实体进行粗略的疑难解答（例如，“为与呼叫ID X关联的邀请生成最终响应需要多长时间？”）。
Offline analysis: A SIP CLF allows for offline analysis of the data gathered. Once a SIP CLF file has been generated, it can be transported (subject to the security considerations in Section 10) to a host with appropriate computing resources to perform subsequent analysis.
离线分析：SIPCLF允许对收集的数据进行离线分析。生成SIP CLF文件后，可以将其传输（根据第10节中的安全注意事项）到具有适当计算资源的主机，以执行后续分析。
Real-time monitoring: A SIP CLF allows administrators to visually notice the events occurring at a SIP entity in real-time providing accurate situational awareness.
实时监控：SIP CLF允许管理员实时直观地注意到SIP实体发生的事件，从而提供准确的态势感知。
Establishing a CLF for SIP is a challenging task. The behavior of a SIP entity is more complex when compared to the equivalent HTTP entity.
为SIP建立CLF是一项具有挑战性的任务。与等效HTTP实体相比，SIP实体的行为更加复杂。
Base protocol services such as parallel or serial forking elicit multiple final responses. Ensuing delays between sending a request and receiving a final response all add complexity when considering what fields should comprise a CLF and in what manner. Furthermore, unlike HTTP, SIP groups multiple discrete transactions into a dialog, and these transactions may arrive at a varying inter-arrival rate at a proxy. For example, the BYE transaction usually arrives much after the corresponding INVITE transaction was received, serviced, and expunged from the transaction list. Nonetheless, it is advantageous to relate these transactions such that automata or a human monitoring the log file can construct a set consisting of related transactions.
诸如并行或串行分叉之类的基本协议服务会引发多个最终响应。发送请求和接收最终响应之间的延迟增加了考虑哪些字段应构成CLF以及以何种方式构成CLF的复杂性。此外，与HTTP不同，SIP将多个离散事务分组到一个对话框中，这些事务可能在代理上以不同的到达速率到达。例如，BYE事务通常在相应的INVITE事务被接收、服务并从事务列表中删除之后到达。尽管如此，将这些事务关联起来是有利的，这样，监控日志文件的自动机或人工可以构建一个由相关事务组成的集合。
ACK requests in SIP need careful consideration as well. In SIP, an ACK is a special method that is associated with an INVITE only. It does not require a response; furthermore, if it is acknowledging a non-2xx response, then the ACK is considered part of the original INVITE transaction. If it is acknowledging a 2xx-class response, then the ACK is a separate transaction consisting of a request only (i.e., there is not a response for an ACK request). CANCEL is another method that is tied to an INVITE transaction, but unlike ACK, the CANCEL request elicits a final response.
SIP中的ACK请求也需要仔细考虑。在SIP中，ACK是一种仅与INVITE关联的特殊方法。它不需要回答；此外，如果它正在确认非2xx响应，则ACK被视为原始INVITE事务的一部分。如果确认2xx类响应，则ACK是一个单独的事务，仅包含一个请求（即，没有对ACK请求的响应）。CANCEL是另一个绑定到INVITE事务的方法，但与ACK不同，CANCEL请求会引发最终响应。
While most requests elicit a response immediately, the INVITE request in SIP can remain in a pending state at a proxy as it forks branches downstream or at a user agent server while it alerts the user. [RFC3261] instructs the server transaction to send a 1xx-class provisional response if a final response is delayed for more than 200 ms. A SIP CLF log file needs to include such provisional responses because they help train automata associated with anomaly detection systems and provide some positive feedback for a human observer monitoring the log file.
虽然大多数请求都会立即引发响应，但SIP中的INVITE请求可以在代理上保持挂起状态，因为它会在下游分支，或者在用户代理服务器上提醒用户。[RFC3261]指示服务器事务在最终响应延迟超过200 ms时发送1xx类临时响应。SIP CLF日志文件需要包含此类临时响应，因为它们有助于训练与异常检测系统相关的自动机，并为监控日志文件的人工观察者提供一些积极反馈。
Finally, beyond supporting native SIP actors such as proxies, registrars, redirect servers, and user agent servers (UASs), it is beneficial to derive a common log format that supports B2BUA behavior, which may vary considerably depending on the specific nature of the B2BUA.
最后，除了支持本机SIP参与者（如代理、注册器、重定向服务器和用户代理服务器（UAS））之外，还可以派生一种支持B2BUA行为的通用日志格式，该格式可能因B2BUA的特定性质而有很大差异。
This document defines the mandatory fields that MUST occur in a SIP CLF record. The maximum size (in number of bytes) for a SIP CLF field is 4096 bytes. This limit is the same regardless of whether the SIP CLF field is a meta-field (see "Timestamp" and "Directionality" defined below) or a normal SIP header. If the body of the SIP message is to be logged, it MUST conform to this limit as well.
本文档定义了SIP CLF记录中必须出现的必填字段。SIP CLF字段的最大大小（字节数）为4096字节。无论SIP CLF字段是元字段（参见下文定义的“时间戳”和“方向性”）还是普通SIP头，该限制都是相同的。如果要记录SIP消息的主体，它也必须符合此限制。
SIP bodies may contain characters that do not form a valid UTF-8 sequence. As such, the logging of bodies requires understanding trade-offs with respect to a specific logging format to determine if the body can be logged as is or some encoding will be required. The specific syntax and semantics used to log SIP bodies MUST be defined by the specific representation format document used to generate the SIP CLF record.
SIP正文可能包含不构成有效UTF-8序列的字符。因此，实体的日志记录需要了解特定日志记录格式的权衡，以确定实体是否可以按原样记录，或者是否需要某种编码。用于记录SIP主体的特定语法和语义必须由用于生成SIP CLF记录的特定表示格式文档定义。
The information model supports extensibility by providing the capability to log "optional fields". Optional fields are those SIP header fields (or field components) that are not mandatory (see Section 8.1 for the mandatory field list). Optional fields may contain SIP headers or other elements present in a SIP message (for example, the Reason-Phrase element from the Status-Line production rule in RFC 3261 [RFC3261]). Optional fields may also contain additional information that a particular vendor desires to log. The specific syntax and semantics to be accorded to optional fields MUST be defined by the specific representation format used to generate the SIP CLF record.
信息模型通过提供记录“可选字段”的功能来支持可扩展性。可选字段是那些非强制性的SIP头字段（或字段组件）（强制性字段列表见第8.1节）。可选字段可能包含SIP头或SIP消息中存在的其他元素（例如，RFC 3261[RFC3261]中状态行生成规则中的原因短语元素）。可选字段还可能包含特定供应商希望记录的其他信息。要赋予可选字段的特定语法和语义必须由用于生成SIP CLF记录的特定表示格式定义。
The following SIP CLF fields are defined as the minimal information that MUST appear in any SIP CLF record:
以下SIP CLF字段定义为任何SIP CLF记录中必须出现的最小信息：
Timestamp: Date and time of the request or response represented as the number of seconds and milliseconds since the Unix epoch.
Timestamp：请求或响应的日期和时间，表示为自Unix纪元以来的秒数和毫秒数。
Message type: An indicator of whether the SIP message is a request or a response. The allowable values for this field are 'R' (for Request) and 'r' (for response).
消息类型：指示SIP消息是请求还是响应的指示器。此字段的允许值为“R”（用于请求）和“R”（用于响应）。
Directionality: An indicator of whether the SIP message is received by the SIP entity or sent by the SIP entity. The allowable values for this field are 's' (for message sent) and 'r' (for message received).
方向性：SIP消息是由SIP实体接收还是由SIP实体发送的指示符。此字段的允许值为“s”（对于已发送的消息）和“r”（对于已接收的消息）。
Transport: The transport over which a SIP message is sent or received. The allowable values for the transport are governed by the "transport" production rule in Section 25.1 of RFC 3261 [RFC3261].
传输：发送或接收SIP消息的传输。运输的允许值受RFC 3261[RFC3261]第25.1节中“运输”生成规则的约束。
Source-address: The IPv4 or IPv6 address of the sender of the SIP message.
源地址：SIP消息发送方的IPv4或IPv6地址。
Source-port: The source port number of the sender of the SIP message.
源端口：SIP消息发送方的源端口号。
Destination-address: The IPv4 or IPv6 address of the recipient of the SIP message.
目标地址：SIP消息收件人的IPv4或IPv6地址。
Destination-port: The port number of the recipient of the SIP message.
目标端口：SIP消息收件人的端口号。
From: The From URI. For the sake of brevity, URI parameters should not be logged.
From:From URI。为简洁起见，不应记录URI参数。
From tag: The tag parameter of the From header.
From标记：From标头的标记参数。
To: The To URI. For the sake of brevity, URI parameters should not be logged.
To:To-URI。为简洁起见，不应记录URI参数。
To tag: The tag parameter of the To header. Note that the tag parameter will be absent in the initial request that forms a dialog.
To tag：To标头的tag参数。请注意，在形成对话框的初始请求中，tag参数将不存在。
Callid: The Call-ID.
Callid:电话号码。
CSeq-Method: The method from the CSeq header.
CSeq方法：来自CSeq头的方法。
CSeq-Number: The number from the CSeq header.
CSeq编号：CSeq标题中的编号。
R-URI: The Request-URI, including any URI parameters.
R-URI：请求URI，包括任何URI参数。
Status: The SIP response status code.
状态：SIP响应状态代码。
SIP proxies may fork, creating several client transactions that correlate to a single server transaction. Responses arriving on these client transactions or new requests (CANCEL, ACK) sent on the client transaction need log file entries that correlate with a server transaction. Similarly, a B2BUA may create one or more client transactions in response to an incoming request. These transactions will require correlation as well. The last two information model elements provide this correlation.
SIP代理可以分叉，创建多个与单个服务器事务相关的客户端事务。到达这些客户端事务的响应或在客户端事务上发送的新请求（取消、确认）需要与服务器事务相关的日志文件条目。类似地，B2BUA可响应传入请求创建一个或多个客户端事务。这些交易也需要关联。最后两个信息模型元素提供了这种相关性。
Server-Txn: Server transaction identification code - the transaction identifier associated with the server transaction. Implementations can reuse the server transaction identifier (the topmost branch-id of the incoming request, with or without the magic cookie), or they could generate a unique identification string for a server transaction (this identifier needs to be locally unique to the server only). This identifier is used to correlate ACKs and CANCELs to an INVITE transaction; it is also used to aid in forking as explained later in this section. (See Section 9 for usage.)
服务器Txn：服务器事务标识码-与服务器事务关联的事务标识符。实现可以重用服务器事务标识符（传入请求的最顶层分支id，带或不带magic cookie），也可以为服务器事务生成唯一的标识字符串（该标识符只需在本地对服务器唯一）。此标识符用于将确认和取消与INVITE事务关联；如本节后面所述，它还用于帮助分叉。（有关用法，请参见第9节。）
Client-Txn: Client transaction identification code - this field is used to associate client transactions with a server transaction for forking proxies or B2BUAs. Upon forking, implementations can reuse the value they inserted into the topmost Via header's branch parameter, or they can generate a unique identification string for the client transaction. (See Section 9 for usage.)
客户端Txn：客户端事务标识码-此字段用于将客户端事务与用于分叉代理或B2BUA的服务器事务相关联。分叉后，实现可以重用通过标头的分支参数插入到最顶端的值，或者为客户端事务生成唯一的标识字符串。（有关用法，请参见第9节。）
This information model applies to all SIP entities --- a UAC, UAS,
proxy, B2BUA, registrar, and redirect server. The SIP CLF fields
prescribed for a proxy are equally applicable to the B2BUA.
Similarly, the SIP CLF fields prescribed for a UAS are equally
applicable to registrars and redirect servers.
This information model applies to all SIP entities --- a UAC, UAS,
proxy, B2BUA, registrar, and redirect server. The SIP CLF fields
prescribed for a proxy are equally applicable to the B2BUA.
Similarly, the SIP CLF fields prescribed for a UAS are equally
applicable to registrars and redirect servers.
The next section specifies the individual SIP CLF information model elements that form a log record for specific instances of a SIP entity. It is understood that a SIP CLF record is extensible using extension mechanisms appropriate to the specific representation used to generate the SIP CLF record. This document, however, does not prescribe a specific representation format, and it limits the discussion to the mandatory data elements described above.
下一节指定形成SIP实体特定实例的日志记录的各个SIP CLF信息模型元素。可以理解，SIP CLF记录可以使用适合于用于生成SIP CLF记录的特定表示的扩展机制来扩展。然而，本文件并未规定具体的表示格式，其讨论仅限于上述强制性数据元素。
Each SIP CLF record must contain all the mandatory information model elements outlined in Section 8.1. This document does not specify a representation of a logging format; it is expected that other documents will do so.
每个SIP CLF记录必须包含第8.1节中概述的所有强制性信息模型元素。本文件未规定记录格式的表示形式；预计其他文件也会这样做。
An element may not always have an appropriate value to provide for one of these fields, for example, the R-URI field is not applicable when logging a response, the Status field is not applicable when logging a request, the To tag is not known when a request is first sent out, etc. As all the mandatory fields are required to appear in the SIP CLF record, the representation document MUST define how to indicate a field that is not applicable in the context that the SIP
元素可能并不总是具有适当的值来为这些字段之一提供，例如，记录响应时R-URI字段不适用，记录请求时状态字段不适用，首次发送请求时to标记未知，等等。由于所有必填字段都必须出现在SIP CLF记录中，因此表示文件必须定义如何指示在SIP CLF记录的上下文中不适用的字段
CLF record was generated. Similarly, to handle parsing errors in a field, the representation document MUST define a means to indicate that a field cannot be parsed.
已生成CLF记录。类似地，为了处理字段中的解析错误，表示文档必须定义一种方法来指示无法解析字段。
The Client-Txn field is always applicable to a UAC. The Server-Txn field does not apply to a UAC unless the element is also acting as a UAS, and the message associated to this log record corresponds to a message handled by that UAS. For instance, a proxy forwarding a request will populate both the Client-Txn and Server-Txn fields in the record corresponding to the forwarded request.
客户端Txn字段始终适用于UAC。服务器Txn字段不适用于UAC，除非该元素也充当UAS，并且与此日志记录关联的消息对应于该UAS处理的消息。例如，转发请求的代理将填充与转发请求对应的记录中的客户端Txn和服务器Txn字段。
The Server-Txn field is always applicable to a UAS. The Client-Txn field does not apply to a UAS unless the element is also acting as a UAC, and the message associated to this log record corresponds to a message handled by that UAC. For instance, a proxy forwarding a response will populate both the Server-Txn and Client-Txn fields in the record corresponding to the forwarded response. However, a proxy would only populate the Client-Txn field when creating a log record corresponding to a request.
服务器Txn字段始终适用于UAS。客户端Txn字段不适用于UAS，除非该元素也充当UAC，并且与此日志记录关联的消息对应于该UAC处理的消息。例如，转发响应的代理将填充与转发响应对应的记录中的服务器Txn和客户端Txn字段。但是，在创建与请求相对应的日志记录时，代理将仅填充客户端Txn字段。
The examples use only the mandatory data elements defined in Section 8.1. Extension elements are not considered and neither are SIP bodies. When a given mandatory field is not applicable to a SIP entity, we use the horizontal dash ("-") to represent it.
示例仅使用第8.1节中定义的强制性数据元素。不考虑扩展元素，也不考虑SIP主体。当给定的必填字段不适用于SIP实体时，我们使用水平虚线（“-”）来表示它。
There are five principals in the examples below. They are the following: Alice, the initiator of requests. Alice's user agent uses IPv4 address 198.51.100.1, port 5060. P1 is a proxy that Alice's request traverse on their way to Bob, the recipient of the requests. P1 also acts as a registrar to Alice. P1 uses an IPv4 address of 198.51.100.10, port 5060. Bob has two instances of his user agent running on different hosts. The first instance uses an IPv4 address of 203.0.113.1, port 5060 and the second instance uses an IPv6 address of 2001:db8::9, port 5060. P2 is a proxy responsible for Bob's domain. Table 1 summarizes these addresses.
下面的例子中有五个原则。他们是：Alice，请求的发起人。Alice的用户代理使用IPv4地址198.51.100.1端口5060。P1是Alice的请求在到达请求接收者Bob的途中经过的代理。P1还担任Alice的注册员。P1使用的IPv4地址为198.51.100.10，端口为5060。Bob有两个在不同主机上运行的用户代理实例。第一个实例使用IPv4地址203.0.113.1，端口5060，第二个实例使用IPv6地址2001:db8:：9，端口5060。P2是负责Bob域的代理。表1总结了这些地址。
+-------------------+--------------------+-------------------+
| Principal | IP:port | Host/Domain name |
+-------------------+--------------------+-------------------+
| Alice | 198.51.100.1:5060 | alice.example.com |
| P1 | 198.51.100.10:5060 | p1.example.com |
| P2 | 203.0.113.200:5060 | p2.example.net |
| Bob UA instance 1 | 203.0.113.1:5060 | bob1.example.net |
| Bob UA instance 2 | [2001:db8::9]:5060 | bob2.example.net |
+-------------------+--------------------+-------------------+
+-------------------+--------------------+-------------------+
| Principal | IP:port | Host/Domain name |
+-------------------+--------------------+-------------------+
| Alice | 198.51.100.1:5060 | alice.example.com |
| P1 | 198.51.100.10:5060 | p1.example.com |
| P2 | 203.0.113.200:5060 | p2.example.net |
| Bob UA instance 1 | 203.0.113.1:5060 | bob1.example.net |
| Bob UA instance 2 | [2001:db8::9]:5060 | bob2.example.net |
+-------------------+--------------------+-------------------+
Principal to IP Address Assignment
主体到IP地址分配
Table 1
表1
Illustrative examples of SIP CLF follow.
下面是SIP-CLF的示例。
Alice sends a registration registrar P1 and receives a 2xx-class response. The register requests causes Alice's UAC to produce a log record shown below.
Alice发送注册注册器P1并接收2xx类响应。注册请求导致Alice的UAC生成如下所示的日志记录。
Timestamp: 1275930743.699
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 1
CSeq-Method: REGISTER
R-URI: sip:example.com
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:example.com
To tag: -
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f81-d4-f6@example.com
Status: -
Server-Txn: -
Client-Txn: c-tr-1
Timestamp: 1275930743.699
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 1
CSeq-Method: REGISTER
R-URI: sip:example.com
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:example.com
To tag: -
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f81-d4-f6@example.com
Status: -
Server-Txn: -
Client-Txn: c-tr-1
After some time, Alice's UAC will receive a response from the registrar. The response causes Alice's agent to produce a log record shown below.
一段时间后，Alice的UAC将收到注册官的回复。该响应导致Alice的代理生成如下所示的日志记录。
Timestamp: 1275930744.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 1
CSeq-Method: REGISTER
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:example.com
To tag: reg-1-xtr
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f81-d4-f6@example.com
Status: 100
Server-Txn: -
Client-Txn: c-tr-1
Timestamp: 1275930744.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 1
CSeq-Method: REGISTER
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:example.com
To tag: reg-1-xtr
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f81-d4-f6@example.com
Status: 100
Server-Txn: -
Client-Txn: c-tr-1
In this example, Alice sends a session initiation request directly to Bob's agent (instance 1). Bob's agent accepts the session invitation. We first present the SIP CLF logging from the vantage point of Alice's UAC. In line 1, Alice's user agent sends out the INVITE. Shortly, it receives a "180 Ringing" (line 2), followed by a "200 OK" response (line 3). Upon the receipt of the 2xx-class response, Alice's user agent sends out an ACK request (line 4).
在本例中，Alice直接向Bob的代理发送会话启动请求（实例1）。Bob的代理接受会话邀请。我们首先从Alice的UAC的有利位置介绍SIP CLF日志记录。在第1行中，Alice的用户代理发出邀请。很快，它会收到一个“180响”（第2行），然后是一个“200 OK”响应（第3行）。收到2xx类响应后，Alice的用户代理发送ACK请求（第4行）。
Timestamp: 1275930743.699
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 32
CSeq-Method: INVITE
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@bob1.example.net
To tag: -
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: -
Server-Txn: -
Client-Txn: c-1-xt6
Timestamp: 1275930743.699
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 32
CSeq-Method: INVITE
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@bob1.example.net
To tag: -
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: -
Server-Txn: -
Client-Txn: c-1-xt6
Timestamp: 1275930745.002
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 32
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b-in6-iu
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: 180
Server-Txn: -
Client-Txn: c-1-xt6
Timestamp: 1275930745.002
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 32
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b-in6-iu
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: 180
Server-Txn: -
Client-Txn: c-1-xt6
Timestamp: 1275930746.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 32
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b-in6-iu
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: 200
Server-Txn: -
Client-Txn: c-1-xt6
Timestamp: 1275930746.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 32
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b-in6-iu
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: 200
Server-Txn: -
Client-Txn: c-1-xt6
Timestamp: 1275930746.120
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 32
CSeq-Method: ACK
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: b-in6-iu
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: -
Server-Txn: -
Client-Txn: c-1-xt6
Timestamp: 1275930746.120
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 32
CSeq-Method: ACK
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: b-in6-iu
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: -
Server-Txn: -
Client-Txn: c-1-xt6
In this example, Alice sends a session invitation request to Bob through proxy P1, which inserts a Record-Route header causing subsequent requests between Alice and Bob to traverse the proxy. The SIP CLF log records appears from the vantage point of P1. The line numbers below refer to Figure 1.
在本例中，Alice通过代理P1向Bob发送会话邀请请求，代理P1插入记录路由头，导致Alice和Bob之间的后续请求遍历代理。SIP CLF日志记录从P1的有利位置出现。下面的行号参考图1。
Alice P1 Bob
+---INV--------->| | Line 1
| | |
|<---------100---+ | Line 2
| | |
| +---INV-------->| Line 3
| | |
| |<--------100---+ Line 4
| | |
| |<--------180---+ Line 5
| | |
|<---------180---+ | Line 6
| | |
| |<--------200---+ Line 7
| | |
|<---------200---+ | Line 8
| | |
+---ACK--------->| | Line 9
| | |
| |---ACK-------->| Line 10
Alice P1 Bob
+---INV--------->| | Line 1
| | |
|<---------100---+ | Line 2
| | |
| +---INV-------->| Line 3
| | |
| |<--------100---+ Line 4
| | |
| |<--------180---+ Line 5
| | |
|<---------180---+ | Line 6
| | |
| |<--------200---+ Line 7
| | |
|<---------200---+ | Line 8
| | |
+---ACK--------->| | Line 9
| | |
| |---ACK-------->| Line 10
Figure 1: Simple Proxy-Aided Call Flow
图1：简单的代理辅助调用流
1 Timestamp: 1275930743.699
Message Type: R
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@example.net
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: -
1 Timestamp: 1275930743.699
Message Type: R
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@example.net
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: -
Note that, at this point, P1 has created a server transaction identification code and populated the SIP CLF field Server-Txn with it. P1 has not yet created a client transaction identification code; thus, Client-Txn contains a "-".
注意，此时P1已经创建了一个服务器事务标识码，并用它填充SIP CLF现场服务器Txn。P1尚未创建客户交易识别码；因此，客户端Txn包含一个“-”。
2 Timestamp: 1275930744.001
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 100
Server-Txn: s-x-tr
Client-Txn: -
2 Timestamp: 1275930744.001
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 100
Server-Txn: s-x-tr
Client-Txn: -
In line 3 below, P1 has created a client transaction identification code for the downstream branch and populated the SIP CLF field Client-Txn.
在下面的第3行中，P1为下游分支创建了一个客户端事务标识码，并填充了SIP CLF字段客户端Txn。
3 Timestamp: 1275930744.998
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: c-x-tr
3 Timestamp: 1275930744.998
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: c-x-tr
4 Timestamp: 1275930745.200
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 100
Server-Txn: s-x-tr
Client-Txn: c-x-tr
4 Timestamp: 1275930745.200
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 100
Server-Txn: s-x-tr
Client-Txn: c-x-tr
5 Timestamp: 1275930745.800
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 180
Server-Txn: s-x-tr
Client-Txn: c-x-tr
5 Timestamp: 1275930745.800
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 180
Server-Txn: s-x-tr
Client-Txn: c-x-tr
6 Timestamp: 1275930746.009
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 180
Server-Txn: s-x-tr
Client-Txn: c-x-tr
6 Timestamp: 1275930746.009
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 180
Server-Txn: s-x-tr
Client-Txn: c-x-tr
7 Timestamp: 1275930747.120
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 200
Server-Txn: s-x-tr
Client-Txn: c-x-tr
7 Timestamp: 1275930747.120
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 200
Server-Txn: s-x-tr
Client-Txn: c-x-tr
8 Timestamp: 1275930747.300
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 200
Server-Txn: s-x-tr
Client-Txn: c-x-tr
8 Timestamp: 1275930747.300
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 200
Server-Txn: s-x-tr
Client-Txn: c-x-tr
9 Timestamp: 1275930749.100
Message Type: R
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: ACK
R-URI: sip:bob@example.net
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: c-x-tr
9 Timestamp: 1275930749.100
Message Type: R
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: ACK
R-URI: sip:bob@example.net
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: c-x-tr
10 Timestamp: 1275930749.100
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: ACK
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: c-x-tr
10 Timestamp: 1275930749.100
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: ACK
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: c-x-tr
In this example, Alice sends a session invitation to Bob's proxy, P2. P2 forks the session invitation request to two registered endpoints corresponding to Bob's address-of-record. Both endpoints respond with provisional responses. Shortly thereafter, one of Bob's user agent instances accepts the call, causing P2 to send a CANCEL request to the second user agent. P2 does not Record-Route; therefore, the
在本例中，Alice向Bob的代理P2发送会话邀请。P2将会话邀请请求分叉到两个注册端点，对应于Bob的记录地址。两个端点都用临时响应进行响应。此后不久，Bob的一个用户代理实例接受调用，导致P2向第二个用户代理发送取消请求。P2不记录路由；因此,
subsequent ACK request from Alice to Bob's user agent does not traverse through P2 (and is not shown below).
Alice向Bob的用户代理发出的后续ACK请求不会穿过P2（下面未显示）。
Figure 2 depicts the call flow.
Bob Bob
Alice P2 (Instance 1) (Instance 2)
+---INV--->| | | Line 1
| | | |
|<---100---+ | | Line 2
| | | |
| +---INV--->| | Line 3
| | | |
| +---INV----+-------->| Line 4
| | | |
| |<---100---+ | Line 5
| | | |
| |<---------+---100---+ Line 6
| | | |
| |<---180---+---------+ Line 7
| | | |
|<---180---+ | | Line 8
| | | |
| |<---180---+ | Line 9
| | | |
|<---180---+ | | Line 10
| | | |
| |<---200---+ | Line 11
| | | |
|<---200---+ | | Line 12
| | | |
| +---CANCEL-+-------->| Line 13
| | | |
| |<---------+---487---+ Line 14
| | | |
| +---ACK----+-------->| Line 15
| | | |
| |<---------+---200---+ Line 16
Figure 2 depicts the call flow.
Bob Bob
Alice P2 (Instance 1) (Instance 2)
+---INV--->| | | Line 1
| | | |
|<---100---+ | | Line 2
| | | |
| +---INV--->| | Line 3
| | | |
| +---INV----+-------->| Line 4
| | | |
| |<---100---+ | Line 5
| | | |
| |<---------+---100---+ Line 6
| | | |
| |<---180---+---------+ Line 7
| | | |
|<---180---+ | | Line 8
| | | |
| |<---180---+ | Line 9
| | | |
|<---180---+ | | Line 10
| | | |
| |<---200---+ | Line 11
| | | |
|<---200---+ | | Line 12
| | | |
| +---CANCEL-+-------->| Line 13
| | | |
| |<---------+---487---+ Line 14
| | | |
| +---ACK----+-------->| Line 15
| | | |
| |<---------+---200---+ Line 16
Figure 2: Forked Call Flow
图2：分叉调用流
The SIP CLF log appears from the vantage point of P2. The fields logged are shown below; the line numbers refer to Figure 2.
SIP CLF日志从P2的有利位置出现。记录的字段如下所示；行号参考图2。
1 Timestamp: 1275930743.699
Message Type: R
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@example.net
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: -
1 Timestamp: 1275930743.699
Message Type: R
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@example.net
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: -
2 Timestamp: 1275930744.001
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 100
Server-Txn: s-1-tr
Client-Txn: -
2 Timestamp: 1275930744.001
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 100
Server-Txn: s-1-tr
Client-Txn: -
3 Timestamp: 1275930744.998
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-1-tr
3 Timestamp: 1275930744.998
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-1-tr
4 Timestamp: 1275930745.500
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@bob2.example.net
Destination-address: [2001:db8::9]
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-2-tr
4 Timestamp: 1275930745.500
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@bob2.example.net
Destination-address: [2001:db8::9]
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-2-tr
5 Timestamp: 1275930745.800
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1=-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com 100
Status: 100
Server-Txn: s-1-tr
Client-Txn: c-1-tr
5 Timestamp: 1275930745.800
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1=-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com 100
Status: 100
Server-Txn: s-1-tr
Client-Txn: c-1-tr
6 Timestamp: 1275930746.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 100
Server-Txn: s-1-tr
Client-Txn: c-2-tr
6 Timestamp: 1275930746.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 100
Server-Txn: s-1-tr
Client-Txn: c-2-tr
7 Timestamp: 1275930746.700
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-2-tr
7 Timestamp: 1275930746.700
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-2-tr
8 Timestamp: 1275930746.990
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-2-tr
8 Timestamp: 1275930746.990
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-2-tr
9 Timestamp: 1275930747.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com 100
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-1-tr
9 Timestamp: 1275930747.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com 100
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-1-tr
10 Timestamp: 1275930747.300
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-2-tr
10 Timestamp: 1275930747.300
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-2-tr
11 Timestamp: 1275930747.800
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com 100
Status: 200
Server-Txn: s-1-tr
Client-Txn: c-1-tr
11 Timestamp: 1275930747.800
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com 100
Status: 200
Server-Txn: s-1-tr
Client-Txn: c-1-tr
12 Timestamp: 1275930748.000
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 200
Server-Txn: s-1-tr
Client-Txn: c-1-tr
12 Timestamp: 1275930748.000
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 200
Server-Txn: s-1-tr
Client-Txn: c-1-tr
13 Timestamp: 1275930748.201
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: CANCEL
R-URI: sip:bob@bob2.example.net
Destination-address: [2001:db8::9]
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-2-tr
13 Timestamp: 1275930748.201
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: CANCEL
R-URI: sip:bob@bob2.example.net
Destination-address: [2001:db8::9]
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-2-tr
14 Timestamp: 1275930748.300
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 487
Server-Txn: s-1-tr
Client-Txn: c-2-tr
14 Timestamp: 1275930748.300
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 487
Server-Txn: s-1-tr
Client-Txn: c-2-tr
15 Timestamp: 1275930748.355
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: ACK
R-URI: sip:bob@bob2.example.net
Destination-address: [2001:db8::9]
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-2-tr
15 Timestamp: 1275930748.355
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: ACK
R-URI: sip:bob@bob2.example.net
Destination-address: [2001:db8::9]
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-2-tr
16 Timestamp: 1275930748.698
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: CANCEL
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 200
Server-Txn: s-1-tr
Client-Txn: c-2-tr
16 Timestamp: 1275930748.698
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: CANCEL
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 200
Server-Txn: s-1-tr
Client-Txn: c-2-tr
The above SIP CLF log makes it easy to search for a specific transaction or a state of the session. Searching for the string "c-1-tr" on the log records will readily yield the information that an INVITE was sent to sip:bob@bob1.example.com, it elicited a 100 followed by a 180 and then a 200. Because the ACK request in this case would be exchanged end-to-end, this element does not see (and therefore will not log) the ACK.
上面的SIPCLF日志使搜索特定事务或会话状态变得容易。在日志记录上搜索字符串“c-1-tr”将很容易得到INVITE已发送到sip的信息：bob@bob1.example.com之后是180，然后是200。由于本例中的ACK请求将端到端交换，因此该元素不会看到（因此不会记录）ACK。
Searching for "c-2-tr" yields a more complex scenario of sending an INVITE to sip:bob@bob2.example.net, receiving 100 and 180. However, the log makes it apparent that the request to sip:bob@bob2.example.net was subsequently CANCEL'ed before a final response was generated, and that the pending INVITE returned a 487. The ACK to the final non-2xx response and a 200 to the CANCEL request complete the exchange on that branch.
搜索“c-2-tr”会产生一个更复杂的场景，即向sip发送邀请：bob@bob2.example.net，接收100和180。但是，日志表明，对sip的请求：bob@bob2.example.net随后在生成最终响应之前被取消，并且挂起的邀请返回了487。对最终非2xx响应的确认和对取消请求的200完成该分支上的交换。
A log file by its nature reveals both the state of the entity producing it and the nature of the information being logged. To the extent that this state should not be publicly accessible and that the information is to be considered private, appropriate file and directory permissions attached to the log file SHOULD be used. It is outside the scope of this document to specify how to protect the log file while it is stored on disk; however, certain precautions can be taken. Operators SHOULD consider using common administrative features such as disk encryption and securing log files [schneier-1]. Operators SHOULD also consider hardening the machine on which the log file is stored by restricting physical access to the host as well as restricting access to the file itself. Depending on the specific operating system and environment, the file and directory permissions SHOULD be set to be most restrictive such that the file is not publicly readable and writable and the directory where the file is stored is not publicly accessible.
日志文件按其性质显示生成它的实体的状态和正在记录的信息的性质。如果此状态不应公开访问，且信息被视为私有，则应使用附加到日志文件的适当文件和目录权限。当日志文件存储在磁盘上时，指定如何保护日志文件超出了本文档的范围；但是，可以采取某些预防措施。操作员应该考虑使用常见的管理特性，如磁盘加密和安全日志文件[SnNIER1]。操作员还应该考虑通过限制对主机的物理访问以及限制对文件本身的访问来硬化存储日志文件的机器。根据特定的操作系统和环境，文件和目录权限应设置为最严格的限制，以便文件不可公开读写，并且存储文件的目录不可公开访问。
The following threats may be considered for the log file while it is stored:
存储日志文件时，可能会考虑以下威胁：
o An attacker may gain access to view the log file, or may surreptitiously make a copy of the log file for later viewing.
o 攻击者可能获得查看日志文件的权限，或者可能会秘密复制日志文件以供以后查看。
o An attacker who is unable to eavesdrop on real-time SIP traffic on the network, but, nonetheless, can access the log file, is able to easily mount replay attack or other attacks that result from channel eavesdropping. Encrypting SIP traffic does not help here because the SIP entity generating the log file would have decrypted the message for processing and subsequent logging.
o 如果攻击者无法窃听网络上的实时SIP流量，但仍然可以访问日志文件，则能够轻松发起重播攻击或其他由通道窃听导致的攻击。加密SIP通信在这里没有帮助，因为生成日志文件的SIP实体将解密消息以进行处理和后续日志记录。
o An attacker may delete parts of --- or indeed, the whole --- file.
o 攻击者可以删除文件的一部分，甚至整个文件。
Public access to the SIP log file creates more of a privacy leak when compared to an adversary eavesdropping cleartext SIP traffic on the network. If all SIP traffic on a network segment is encrypted, then as noted above, special attention must be directed to the file and directory permissions associated with the log file to preserve
与窃听网络上明文SIP流量的对手相比，公开访问SIP日志文件会造成更多的隐私泄漏。如果网段上的所有SIP通信都已加密，则如上所述，必须特别注意与要保留的日志文件关联的文件和目录权限
privacy such that only a privileged user can access the contents of the log file.
隐私，只有特权用户才能访问日志文件的内容。
Transporting SIP CLF files across the network pose special challenges as well. The following threats may be considered for transferring log files or while transferring individual log records:
通过网络传输SIP CLF文件也带来了特殊的挑战。传输日志文件或传输单个日志记录时，可能会考虑以下威胁：
o An attacker may view the records;
o 攻击者可以查看记录；
o An attacker may modify the records in transit or insert previously captured records into the stream;
o 攻击者可以修改传输中的记录或将以前捕获的记录插入流中；
o An attacker may remove records in transit, or may stage a man-in-the-middle attack to deliver a partially or entirely falsified log file.
o 攻击者可能会删除传输中的记录，或者发动中间人攻击以传递部分或全部伪造的日志文件。
It is also outside the scope of this document to specify protection methods for log files or log records that are being transferred between hosts; however, certain precautions can be taken. Operators SHOULD require mutual authentication, channel confidentiality, and channel integrity while transferring the log file. The use of a secure shell transport layer protocol [RFC4253] or TLS [RFC5246] accomplishes this.
为主机之间传输的日志文件或日志记录指定保护方法也不在本文件的范围之内；但是，可以采取某些预防措施。传输日志文件时，操作员应要求相互身份验证、通道机密性和通道完整性。使用安全外壳传输层协议[RFC4253]或TLS[RFC5246]可以实现这一点。
Even with such care, sensitive information can be leaked during or after the transfer. SIP CLF fields like IP addresses and URIs contain potentially sensitive information. Before transferring the log file across domains, operators SHOULD ensure that any fields that contain sensitive information are appropriately anonymized or obfuscated. A specification for a format that describes which fields are obfuscated and with what characteristics (e.g., what correlations still work) is needed to allow interoperable but privacy-friendly exchange of SIP CLF between administrative domains. Such a specification is not attempted here, but is for further study.
即使如此小心，敏感信息也可能在传输期间或之后泄露。IP地址和URI等SIP CLF字段包含潜在的敏感信息。在跨域传输日志文件之前，操作员应确保包含敏感信息的任何字段都经过适当的匿名化或模糊处理。一种格式规范，描述了在管理域之间允许SIP CLF的可互操作但对隐私友好的交换所需的混淆字段和特征（例如，哪些关联仍然有效）。这里不尝试这样的规范，但有待进一步研究。
The SIP CLF represents the minimum fields that lend themselves to trend analysis and serve as information that may be deemed useful. Other formats can be defined that include more headers (and the body) from Section 8.1. However, where to draw a judicial line regarding the inclusion of non-mandatory headers can be challenging. Clearly, the more information a SIP entity logs, the longer time the logging process will take, the more disk space the log entry will consume, and the more potentially sensitive information could be breached. Therefore, adequate trade-offs should be taken in account when logging more fields than the ones recommended in Section 8.1.
SIP CLF表示用于趋势分析的最小字段，并用作可能被认为有用的信息。可以定义其他格式，包括第8.1节中的更多标题（和正文）。然而，在何处划定非强制性标题的司法界限可能具有挑战性。显然，SIP实体记录的信息越多，记录过程所需的时间就越长，日志项消耗的磁盘空间就越大，并且可能破坏的敏感信息也就越多。因此，当记录比第8.1节中建议的更多字段时，应考虑充分的权衡。
Implementers need to pay particular attention to buffer handling when reading or writing log files. SIP CLF entries can be unbounded in length. It would be reasonable for a full dump of a SIP message to be thousands of octets long. This is of particular importance to CLF log parsers, as a SIP CLF log writers may add one or more extension fields to the message to be logged.
在读取或写入日志文件时，实现人员需要特别注意缓冲区处理。SIP CLF条目的长度可以是无限的。SIP消息的完整转储长度为数千个八位字节是合理的。这对于CLF日志解析器特别重要，因为SIP CLF日志编写器可能会向要记录的消息添加一个或多个扩展字段。
SIP CLF log files will take up a substantial amount of disk space depending on traffic volume at a processing entity and the amount of information being logged. As such, any organization using SIP CLF should establish operational procedures for file rollovers and periodic retrieval of logs before rollover as appropriate to the needs of the organization.
SIP CLF日志文件将占用大量磁盘空间，具体取决于处理实体的通信量和记录的信息量。因此，任何使用SIP CLF的组织都应根据组织的需要制定文件滚动和滚动前定期检索日志的操作程序。
Listing such operational guidelines in this document is out of scope for this work.
在本文件中列出此类操作指南超出了本工作范围。
Members of the sipping, dispatch, ipfix, and syslog working groups provided invaluable input to the formulation of the document. These include Benoit Claise, Spencer Dawkins, John Elwell, David Harrington, Christer Holmberg, Hadriel Kaplan, Atsushi Kobayashi, Jiri Kuthan, Scott Lawrence, Chris Lonvick, Peter Musgrave, Simon Perreault, Adam Roach, Dan Romascanu, Robert Sparks, Brian Trammell, Dale Worley, Theo Zourzouvillys, and others that we have undoubtedly, but inadvertently, missed.
SIPING、dispatch、ipfix和syslog工作组的成员为文档的制定提供了宝贵的投入。这些人包括贝诺特·克莱斯、斯宾塞·道金斯、约翰·埃尔威尔、大卫·哈灵顿、克里斯特·霍姆伯格、哈德里尔·卡普兰、小林尊、吉里·库坦、斯科特·劳伦斯、克里斯·隆维克、彼得·马斯格雷夫、西蒙·佩雷尔特、亚当·罗奇、丹·罗马斯库、罗伯特·斯帕克斯、布莱恩·特拉梅尔、戴尔·沃利、西奥·佐维利，以及我们毫无疑问拥有的其他人，但不经意间，错过了。
Rainer Gerhards, David Harrington, Cullen Jennings, and Gonzalo Salgueiro helped tremendously in discussions related to arriving at the beginnings of an information model.
Rainer Gerhards、David Harrington、Cullen Jennings和Gonzalo Salgueiro在与信息模型开始相关的讨论中提供了巨大帮助。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253]Ylonen，T.和C.Lonvick，“安全外壳（SSH）传输层协议”，RFC 4253，2006年1月。
[RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101]Claise，B.，“用于交换IP流量信息的IP流量信息导出（IPFIX）协议规范”，RFC 5101，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[RFC6873] Salgueiro, G., Gurbani, V., and A. B. Roach, "Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)", RFC 6873, February 2013.
[RFC6873]Salgueiro，G.，Gurbani，V.和A.B.Roach，“会话启动协议（SIP）通用日志格式（CLF）的格式”，RFC 6873，2013年2月。
[rieck2008] Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. Muller, "A Self-learning System for Detection of Anomalous SIP Messages", Principles, Systems and Applications of IP Telecommunications Services and Security for Next Generation Networks (IPTComm), LNCS 5310, pp. 90-106, 2008.
[rieck2008]Rieck，K.，Wahl，S.，Laskov，P.，Domschitz，P.，和K-R.Muller，“用于检测异常SIP消息的自学习系统”，下一代网络IP电信服务和安全（IPTComm）的原理、系统和应用，LNCS 5310，第90-106页，2008年。
[schneier-1] Schneier, B. and J. Kelsey, "Secure audit logs to support computer forensics", ACM Transactions on Information and System Security (TISSEC), 2(2), pp. 159,176, May 1999.
[schneier-1]schneier，B.和J.Kelsey，“保护审计日志以支持计算机取证”，ACM信息和系统安全交易（TISSEC），2（2），第159176页，1999年5月。
Authors' Addresses
作者地址
Vijay K. Gurbani (editor) Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane Naperville, IL 60566 USA
Vijay K.Gurbani（编辑）贝尔实验室，阿尔卡特朗讯1960朗讯莱恩纳珀维尔，伊利诺伊州60566
EMail: vkg@bell-labs.com
EMail: vkg@bell-labs.com
Eric W. Burger (editor) Georgetown University USA
Eric W.Burger（编辑）美国乔治敦大学
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
Tricha Anjali Illinois Institute of Technology 316 Siegel Hall Chicago, IL 60616 USA
Tricha Anjali伊利诺伊理工学院美国伊利诺伊州芝加哥西格尔大厅316号，邮编60616
EMail: tricha@ece.iit.edu
EMail: tricha@ece.iit.edu
Humberto Abdelnur INRIA INRIA - Nancy Grant Est Campus Scientifique 54506, Vandoeuvre-les-Nancy Cedex France
Humberto Abdelnur INRIA INRIA-Nancy Grant东校区科学馆54506，法国Nancy Cedex范德福酒店
EMail: humbol@gmail.com
EMail: humbol@gmail.com
Olivier Festor INRIA INRIA - Nancy Grant Est Campus Scientifique 54506, Vandoeuvre-les-Nancy Cedex France
Olivier Festor INRIA INRIA-Nancy Grant东校区科学馆54506，法国南希塞德克斯市万多维尔
EMail: Olivier.Festor@loria.fr
EMail: Olivier.Festor@loria.fr