summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6872.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6872.txt')
-rw-r--r--doc/rfc/rfc6872.txt2187
1 files changed, 2187 insertions, 0 deletions
diff --git a/doc/rfc/rfc6872.txt b/doc/rfc/rfc6872.txt
new file mode 100644
index 0000000..a024890
--- /dev/null
+++ b/doc/rfc/rfc6872.txt
@@ -0,0 +1,2187 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+ 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.
+
+
+
+
+Gurbani, et al. Standards Track [Page 1]
+
+RFC 6872 SIP CLF February 2013
+
+
+Copyright Notice
+
+ Copyright (c) 2013 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+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
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 2]
+
+RFC 6872 SIP CLF February 2013
+
+
+1. Introduction
+
+ 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.
+
+ 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:
+
+ %h %l %u %t \"%r\" %s %b
+ remotehost rfc931 authuser [date] request status bytes
+
+ remotehost: Remote hostname (or IP number if DNS hostname is not
+ available or if DNSLookup is Off.
+
+ rfc931: The remote logname of the user.
+
+ authuser: The username by which the user has authenticated
+ himself.
+
+ [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.
+
+ 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.
+
+ 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
+
+
+
+
+Gurbani, et al. Standards Track [Page 3]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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.
+
+2. Terminology
+
+ 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 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.
+
+3. Problem Statement
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 4]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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.
+
+4. What SIP CLF Is and What It Is Not
+
+ 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.
+
+ The SIP CLF is amenable to quick parsing (i.e., well-delimited
+ fields), and it is platform and operating system neutral.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ Finally, the SIP CLF is not a tool for supporting lawful intercept.
+
+5. Alternative Approaches to 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.
+
+
+
+
+Gurbani, et al. Standards Track [Page 5]
+
+RFC 6872 SIP CLF February 2013
+
+
+5.1. SIP CLF and Call Detail Records
+
+ 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.
+
+ 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.
+
+ 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).
+
+ 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.
+
+5.2. SIP CLF and Packet Capture Tools
+
+ 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:
+
+
+
+Gurbani, et al. Standards Track [Page 6]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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 The packet capture from these tools is not easily searchable by
+ simple command-line tools for text processing.
+
+ 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 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 Using such tools and related packet capture libraries may imposes
+ a dependency on a third-party library.
+
+5.3. SIP CLF and Syslog
+
+ 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.
+
+ 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
+
+
+
+Gurbani, et al. Standards Track [Page 7]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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.
+
+5.4. SIP CLF and IPFIX
+
+ 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.
+
+6. Motivation and Use Cases
+
+ 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:
+
+ 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.
+
+ 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.
+
+ 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.
+
+ Note that tracing the request through a set of servers is
+ considerably less challenging if all the servers belong to
+ the same administrative domain.
+
+
+
+
+Gurbani, et al. Standards Track [Page 8]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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.").
+
+ 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.").
+
+ 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?").
+
+ 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.
+
+ 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.
+
+ 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?").
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 9]
+
+RFC 6872 SIP CLF February 2013
+
+
+7. Challenges in Establishing a SIP CLF
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 10]
+
+RFC 6872 SIP CLF February 2013
+
+
+8. Information Model
+
+ 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 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.
+
+ 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.
+
+8.1. SIP CLF Mandatory Fields
+
+ The following SIP CLF fields are defined as the minimal information
+ that MUST appear in any SIP CLF record:
+
+ Timestamp: Date and time of the request or response represented as
+ the number of seconds and milliseconds since the Unix epoch.
+
+ 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).
+
+ 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).
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 11]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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].
+
+ Source-address: The IPv4 or IPv6 address of the sender of the SIP
+ message.
+
+ Source-port: The source port number of the sender of the SIP
+ message.
+
+ Destination-address: The IPv4 or IPv6 address of the recipient of
+ the SIP message.
+
+ Destination-port: The port number of the recipient of the SIP
+ message.
+
+ From: The From URI. For the sake of brevity, URI parameters should
+ not be logged.
+
+ From tag: The tag parameter of the From header.
+
+ To: The To URI. For the sake of brevity, URI parameters should not
+ be logged.
+
+ 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.
+
+ Callid: The Call-ID.
+
+ CSeq-Method: The method from the CSeq header.
+
+ CSeq-Number: The number from the CSeq header.
+
+ R-URI: The Request-URI, including any URI parameters.
+
+ Status: The SIP response status code.
+
+ 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.
+
+
+
+
+Gurbani, et al. Standards Track [Page 12]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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.)
+
+ 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.)
+
+ 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.
+
+8.2. Mandatory Fields and SIP Entities
+
+ 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.
+
+ 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
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 13]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+9. Examples
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 14]
+
+RFC 6872 SIP CLF February 2013
+
+
+ +-------------------+--------------------+-------------------+
+ | 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
+
+ Table 1
+
+ Illustrative examples of SIP CLF follow.
+
+9.1. UAC Registration
+
+ 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.
+
+ 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
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 15]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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.
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 16]
+
+RFC 6872 SIP CLF February 2013
+
+
+9.2. Direct Call between Alice and Bob
+
+ 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).
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 17]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 18]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 19]
+
+RFC 6872 SIP CLF February 2013
+
+
+9.3. Single Downstream Branch Call
+
+ 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
+ +---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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 20]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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 "-".
+
+ 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: -
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 21]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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 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
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 22]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 23]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 24]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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
+
+9.4. Forked Call
+
+ 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
+
+
+
+Gurbani, et al. Standards Track [Page 25]
+
+RFC 6872 SIP CLF February 2013
+
+
+ subsequent ACK request from Alice to Bob's user agent does not
+ traverse through P2 (and is not shown below).
+
+ 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
+
+ The SIP CLF log appears from the vantage point of P2. The fields
+ logged are shown below; the line numbers refer to Figure 2.
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 26]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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: -
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 27]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 28]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 29]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 30]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 31]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 32]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 33]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 15 Timestamp: 1275930748.355
+ Message Type: R
+ Directionality: s
+ Transport: udp
+ CSeq-Number: 43
+ CSeq-Method: ACK
+ R-URI: sip:bob@bob2.example.net
+ Destination-address: [2001:db8::9]
+ Destination-port: 5060
+ Source-address: 203.0.113.200
+ Source-port: 5060
+ To: sip:bob@example.net
+ To tag: b2-2
+ From: sip:alice@example.com
+ From tag: a1-1
+ Call-ID: tr-88h@example.com
+ Status: -
+ Server-Txn: s-1-tr
+ Client-Txn: c-2-tr
+
+ 16 Timestamp: 1275930748.698
+ Message Type: r
+ Directionality: r
+ Transport: udp
+ CSeq-Number: 43
+ CSeq-Method: CANCEL
+ R-URI: -
+ Destination-address: 203.0.113.200
+ Destination-port: udp
+ Source-address: [2001:db8::9]
+ Source-port: 5060
+ To: sip:bob@example.net
+ To tag: b2-2
+ From: sip:alice@example.com
+ From tag: a1-1
+ Call-ID: tr-88h@example.com
+ Status: 200
+ Server-Txn: s-1-tr
+ Client-Txn: c-2-tr
+
+ The above SIP CLF log makes it easy to search for a specific
+ transaction or a state of the session. Searching for the string
+ "c-1-tr" on the log records will readily yield the information that
+ an INVITE was sent to sip:bob@bob1.example.com, it elicited a 100
+ followed by a 180 and then a 200. Because the ACK request in this
+ case would be exchanged end-to-end, this element does not see (and
+ therefore will not log) the ACK.
+
+
+
+
+Gurbani, et al. Standards Track [Page 34]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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.
+
+10. Security Considerations
+
+ 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.
+
+ 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 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 An attacker may delete parts of --- or indeed, the whole --- file.
+
+ 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
+
+
+
+
+Gurbani, et al. Standards Track [Page 35]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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:
+
+ o An attacker may view the records;
+
+ o An attacker may modify the records in transit or insert previously
+ captured records into the stream;
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 36]
+
+RFC 6872 SIP CLF February 2013
+
+
+ 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.
+
+11. Operational Guidance
+
+ 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.
+
+ Listing such operational guidelines in this document is out of scope
+ for this work.
+
+12. Acknowledgments
+
+ 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.
+
+ Rainer Gerhards, David Harrington, Cullen Jennings, and Gonzalo
+ Salgueiro helped tremendously in discussions related to arriving at
+ the beginnings of an information model.
+
+13. References
+
+13.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [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.
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 37]
+
+RFC 6872 SIP CLF February 2013
+
+
+13.2. Informative References
+
+ [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
+ Transport Layer Protocol", RFC 4253, January 2006.
+
+ [RFC5101] Claise, B., "Specification of the IP Flow Information
+ Export (IPFIX) Protocol for the Exchange of IP Traffic
+ Flow Information", RFC 5101, January 2008.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
+
+ [RFC6873] Salgueiro, G., Gurbani, V., and A. B. Roach, "Format for
+ the Session Initiation Protocol (SIP) Common Log Format
+ (CLF)", RFC 6873, February 2013.
+
+ [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.
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 38]
+
+RFC 6872 SIP CLF February 2013
+
+
+Authors' Addresses
+
+ Vijay K. Gurbani (editor)
+ Bell Laboratories, Alcatel-Lucent
+ 1960 Lucent Lane
+ Naperville, IL 60566
+ USA
+
+ EMail: vkg@bell-labs.com
+
+
+ Eric W. Burger (editor)
+ Georgetown University
+ USA
+
+ EMail: eburger@standardstrack.com
+ URI: http://www.standardstrack.com
+
+
+ Tricha Anjali
+ Illinois Institute of Technology
+ 316 Siegel Hall
+ Chicago, IL 60616
+ USA
+
+ EMail: tricha@ece.iit.edu
+
+
+ Humberto Abdelnur
+ INRIA
+ INRIA - Nancy Grant Est
+ Campus Scientifique
+ 54506, Vandoeuvre-les-Nancy Cedex
+ France
+
+ EMail: humbol@gmail.com
+
+
+ Olivier Festor
+ INRIA
+ INRIA - Nancy Grant Est
+ Campus Scientifique
+ 54506, Vandoeuvre-les-Nancy Cedex
+ France
+
+ EMail: Olivier.Festor@loria.fr
+
+
+
+
+
+Gurbani, et al. Standards Track [Page 39]
+