< draft-ietf-sipclf-format-05.txt   draft-ietf-sipclf-format-06.txt >
SIPCLF G. Salgueiro SIPCLF G. Salgueiro
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track V. Gurbani Intended status: Standards Track V. Gurbani
Expires: June 19, 2012 Bell Labs, Alcatel-Lucent Expires: September 13, 2012 Bell Labs, Alcatel-Lucent
A. B. Roach A. B. Roach
Tekelec Tekelec
December 17, 2011 March 12, 2012
Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)
draft-ietf-sipclf-format-05 draft-ietf-sipclf-format-06
Abstract Abstract
The SIPCLF Workgroup has defined a common log format framework for The SIPCLF Workgroup has defined a common log format framework for
Session Initiation Protocol (SIP) servers. This common log format Session Initiation Protocol (SIP) servers. This common log format
mimics the successful event logging format found in well-known web mimics the successful event logging format found in well-known web
servers like Apache and web proxies like Squid. This document servers like Apache and web proxies like Squid. This document
proposes an indexed text encoding format for the SIP Common Log proposes an indexed text encoding format for the SIP Common Log
Format (CLF) that retains the key advantages of a text-based format, Format (CLF) that retains the key advantages of a text-based format,
while significantly increasing processing performance over a purely while significantly increasing processing performance over a purely
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 19, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Document Conventions . . . . . . . . . . . . . . . . . . . . . 4 3. Document Conventions . . . . . . . . . . . . . . . . . . . . . 4
4. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Index Pointers . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Index Pointers . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Mandatory Fields . . . . . . . . . . . . . . . . . . . . . 11 4.2. Mandatory Fields . . . . . . . . . . . . . . . . . . . . . 10
4.3. Optional Fields . . . . . . . . . . . . . . . . . . . . . 15 4.3. Optional Fields . . . . . . . . . . . . . . . . . . . . . 15
5. Example SIP CLF Record . . . . . . . . . . . . . . . . . . . . 22 5. Example SIP CLF Record . . . . . . . . . . . . . . . . . . . . 22
6. Text Tool Considerations . . . . . . . . . . . . . . . . . . . 24 6. Text Tool Considerations . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Operational Guidance . . . . . . . . . . . . . . . . . . . . . 24 8. Operational Guidance . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1. SIP CLF Version . . . . . . . . . . . . . . . . . . . . . 24
9.2. SIP CLF Transport Flag . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The extensive list of benefits and the widespread adoption of the The extensive list of benefits and the widespread adoption of the
Apache Common Log Format (CLF) has prompted the development of a Apache Common Log Format (CLF) has prompted the development of an
functionally equivalent event logging mechanism for the Session analogous event logging mechanism for the Session Initiation Protocol
Initiation Protocol [RFC3261] (SIP). Implementing a logging scheme [RFC3261] (SIP). Implementing a logging scheme for SIP is a
for SIP is a considerable challenge. This is due in part to the fact considerable challenge. This is due in part to the fact that the
that the behavior of a SIP entity is more complex as compared to an behavior of a SIP entity is more complex as compared to an HTTP
HTTP entity. Additionally, there are shortcomings to the purely entity. Additionally, there are shortcomings to the purely text-
text-based HTTP Common Log Format that need to be addressed in order based HTTP Common Log Format that need to be addressed in order to
to allow for real-time inspection of SIP log files allow for real-time inspection of SIP log files
[I-D.ietf-sipclf-problem-statement]. Experience with Apache Common [I-D.ietf-sipclf-problem-statement]. Experience with Apache Common
Log Format has shown that dealing with large quantities of log data Log Format has shown that dealing with large quantities of log data
can be very processor intensive, as doing so necessarily requires can be very processor intensive, as doing so necessarily requires
reading and parsing every byte in the log file(s) of interest. reading and parsing every byte in the log file(s) of interest.
An implementation independent framework for the SIP CLF has been An implementation independent framework for the SIP CLF has been
defined in [I-D.ietf-sipclf-problem-statement]. This memo describes defined in [I-D.ietf-sipclf-problem-statement]. This memo describes
an indexed text file format for logging SIP messages received and an indexed text file format for logging SIP messages received and
sent by SIP clients, servers, and proxies that adheres to the data sent by SIP clients, servers, and proxies that adheres to the data
model presented in Section 8 of [I-D.ietf-sipclf-problem-statement]. model presented in Section 8 of [I-D.ietf-sipclf-problem-statement].
This document defines a format that is no more difficult to generate This document defines a format that is no more difficult to generate
by logging entities, while being radically faster to process. In by logging entities than standard (i.e., non-indexed) text log
particular, the format is optimized for both rapidly scanning through formats, while being radically faster to process. In particular, the
log records, as well as quickly locating commonly accessed data format is optimized for both rapidly scanning through log records, as
fields. well as quickly locating commonly accessed data fields.
Further, the format proposed by this document retains the key Further, the format proposed by this document retains the key
advantage of being human readable and able to be processed using the advantage of being human readable and able to be processed using the
various Unix text processing tools, such as sed, awk, perl, cut, and various Unix text processing tools, such as sed, awk, perl, cut, and
grep. grep.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are
appropriate when valid exceptions to a general requirement are known
to exist or appear to exist, and it is infeasible or impractical to
enumerate all of them. However, they should not be interpreted as
permitting implementors to fail to implement the general requirement
when such failure would result in interoperability failure.
[RFC3261] defines additional terms used in this document that are [RFC3261] defines additional terms used in this document that are
specific to the SIP domain such as "proxy"; "registrar"; "redirect specific to the SIP domain such as "proxy"; "registrar"; "redirect
server"; "user agent server" or "UAS"; "user agent client" or "UAC"; server"; "user agent server" or "UAS"; "user agent client" or "UAC";
"back-to-back user agent" or "B2BUA"; "dialog"; "transaction"; "back-to-back user agent" or "B2BUA"; "dialog"; "transaction";
"server transaction". "server transaction".
This document uses the term "SIP Server" that is defined to include This document uses the term "SIP Server" that is defined to include
the following SIP entities: user agent server, registrar, redirect the following SIP entities: user agent server, registrar, redirect
server, a SIP proxy in the role of user agent server, and a B2BUA in server, a SIP proxy in the role of user agent server, and a B2BUA in
the role of a user agent server. the role of a user agent server.
The reader is expected to be familiar with the terminology and The reader is expected to be familiar with the terminology and
concepts defined in [I-D.ietf-sipclf-problem-statement]. concepts defined in [I-D.ietf-sipclf-problem-statement].
3. Document Conventions 3. Document Conventions
This document defines the logging syntax for the SIP CLF. This This document defines the logging syntax for the SIP CLF. This
syntax is demonstrated through the use of various examples. The syntax is demonstrated through the use of various examples. The
formatting described here does not permit these examples to be formatting described here does not permit these examples to be
unambiguously rendered due to the constraints imposed by the unambiguously rendered due to the constraints imposed by the
formatting rules for Internet-Drafts. To avoid ambiguity and to meet formatting rules for RFCs. To avoid ambiguity and to meet the RFC
the Internet-Draft layout requirements this document uses the layout requirements this document uses the <allOneLine/> markup
<allOneLine/> markup convention established in [RFC4475]. convention established in [RFC4475].
For the sake of clarity and completeness, the entire text defining For the sake of clarity and completeness, the entire text defining
this markup convention from Section 2.1 of [RFC4475] is quoted below: this markup convention from Section 2.1 of [RFC4475] is quoted below:
Several of these examples contain unfolded lines longer than 72 Several of these examples contain unfolded lines longer than 72
characters. These are captured between <allOneLine/> tags. The characters. These are captured between <allOneLine/> tags. The
single unfolded line is reconstructed by directly concatenating single unfolded line is reconstructed by directly concatenating
all lines appearing between the tags (discarding any line feeds or all lines appearing between the tags (discarding any line feeds or
carriage returns). There will be no whitespace at the end of carriage returns). There will be no whitespace at the end of
lines. Any whitespace appearing at a fold-point will appear at lines. Any whitespace appearing at a fold-point will appear at
skipping to change at page 8, line 7 skipping to change at page 8, line 7
Note that Figure 1 and Figure 2 plus the terminating line-feed (0x0A) Note that Figure 1 and Figure 2 plus the terminating line-feed (0x0A)
at the end of the SIP CLF record are different representations of the at the end of the SIP CLF record are different representations of the
same format but are functionally equivalent. The representation of same format but are functionally equivalent. The representation of
this format is a two line record where the <IndexPointers> metadata this format is a two line record where the <IndexPointers> metadata
is on one line and the actual data like <MandatoryFields> and is on one line and the actual data like <MandatoryFields> and
<OptionalFields> (if present) is on another. <OptionalFields> (if present) is on another.
In the following sections note that indications of "hexadecimal In the following sections note that indications of "hexadecimal
encoded" indicate that the value is to be written out in human- encoded" indicate that the value is to be written out in human-
readable base-16 numbers using the ASCII characters 0x30 through 0x39 readable base-16 numbers using the UTF-8 characters 0x30 through 0x39
('0' through '9') and 0x41 through 0x46 ('A' through 'F'). ('0' through '9') and 0x41 through 0x46 ('A' through 'F').
Similarly, indications of "decimal encoded" indicate that the value Similarly, indications of "decimal encoded" indicate that the value
is to be written out in human readable base-10 number using the ASCII is to be written out in human readable base-10 number using the UTF-8
characters 0x30 through 0x39 ('0' through '9'). In both encodings, characters 0x30 through 0x39 ('0' through '9'). In both encodings,
numbers always take up the number of bytes indicated, and are padded numbers always take up the number of bytes indicated, and are padded
on the left with ASCII '0' (zero) characters to fill the entire on the left with UTF-8 '0' (zero) characters to fill the entire
space. space.
4.1. Index Pointers 4.1. Index Pointers
The <IndexPointers> portion of the SIP CLF record (shown in Figure 3) The <IndexPointers> portion of the SIP CLF record (shown in Figure 3)
is a 60-byte header that indicates metadata about the record. is a 60-byte header that indicates metadata about the record.
0 7 8 15 16 23 24 31 0 7 8 15 16 23 24 31
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| Version | Record Length | 0 - 3 | Version | Record Length | 0 - 3
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| Record Length (cont) | 0x2C | 4 - 7 | Record Length (cont) | 0x2C | 4 - 7
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| CSeq Pointer (Hex) | 8 - 11 | CSeq Pointer (Hex) | 8 - 11
skipping to change at page 10, line 7 skipping to change at page 9, line 44
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| Client-Txn Pointer (Hex) | 52 - 55 | Client-Txn Pointer (Hex) | 52 - 55
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| Optional Fields Start Pointer (Hex) | 56 - 59 | Optional Fields Start Pointer (Hex) | 56 - 59
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
Figure 3: Index Pointers Figure 3: Index Pointers
The fields that make up <IndexPointers> are described below: The fields that make up <IndexPointers> are described below:
Version (1 byte): 0x41 for this document; hexadecimal encoded. Version (1 byte): UTF-8 encoded version for the SIP CLF record.
Range of valid values for the Version is from 'A' (0x41) to 'Z'
(0x5A). This document uses a Version value of "0x41" ('A').
The value of the SIP CLF Version MUST be incremented for any new
SIP CLF specification that changes any part of the SIP CLF record
format. The SIP CLF Version values are IANA-assigned
(Section 9.1) via the Standards Action method as described in
[RFC5226].
Since the version is specified per record it is possible that a
SIP CLF log file could contain records with different versions.
Under normal operating conditions this is an unlikely occurrence
and SHOULD be avoided if possible.
Record Length (6 bytes): Hexadecimal encoded total length of this Record Length (6 bytes): Hexadecimal encoded total length of this
log record, including "Version", "Record Length", "Flags" fields log record, beginning with the "Version" octet and ending with the
and terminating line-feed. terminating line-feed.
Bytes 8 through 55 contain hexadecimal encoded pointers that point to Bytes 8 through 55 contain hexadecimal encoded pointers that point to
the starting location of each of the variable-length mandatory the starting location of each of the variable-length mandatory
fields. Note that there are no delimiters between these pointer fields. Bytes 56 through 59 contain hexadecimal encoded pointer that
values -- they are packed together as a single, 52-character points to the starting location of the optional fields portion of the
SIP CLF record. Note that there are no delimiters between these
pointer values -- they are packed together as a single, 52-character
hexadecimal encoded string. The "Pointer" fields indicate absolute hexadecimal encoded string. The "Pointer" fields indicate absolute
byte values within the record, and MUST be >=82. They point to the byte values within the record, and MUST be >=82. They point to the
start of the corresponding value within the <MandatoryFields> start of the corresponding value within the <MandatoryFields>
portion. A description of each of the mandatory fields that these portion. A description of each of the mandatory fields that these
pointer values point to can be found in Section 4.2. pointer values point to can be found in Section 4.2.
Optional Fields Start Pointer: This final pointer indicates the Optional Fields Start Pointer: This final pointer indicates the
location within the SIP CLF record where the OPTIONAL group of location within the SIP CLF record where the OPTIONAL group of
<OptionalFields> begin, if present. The "Optional Fields Start <OptionalFields> begin, if present. The "Optional Fields Start
Pointer" points to the ASCII Tab (0x09) character for the first Pointer" points to the UTF-8 Tab (0x09) character for the first
entry in the <OptionalFields> portion. If the OPTIONAL group of entry in the <OptionalFields> portion. If the OPTIONAL group of
<OptionalFields> are not implemented, then the "Optional Fields <OptionalFields> are not implemented, then the "Optional Fields
Start Pointer" field MUST point to the terminating line-feed Start Pointer" field MUST point to the terminating line-feed
(0x0A) at the end of the SIP CLF record. (0x0A) at the end of the SIP CLF record.
4.2. Mandatory Fields 4.2. Mandatory Fields
The <MandatoryFields> portion of the SIP CLF record is shown below: The <MandatoryFields> portion of the SIP CLF record is shown below:
0 7 8 15 16 23 24 31 0 7 8 15 16 23 24 31
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| 0x0A | | 60 - 63 | 0x0A | | 60 - 63
+-----------+ + +-----------+ +
| Timestamp | 64 - 67 | Timestamp | 64 - 67
+ +-----------+ + +-----------+
| | 0x2E | 68 - 71 | | 0x2E | 68 - 71
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
skipping to change at page 11, line 39 skipping to change at page 11, line 36
Figure 4: Mandatory Fields Figure 4: Mandatory Fields
Following the pointers in <IndexPointers>, two fixed-length fields Following the pointers in <IndexPointers>, two fixed-length fields
are encoded to specify the exact time of the log entry. As before, are encoded to specify the exact time of the log entry. As before,
all fields are completely filled, pre-pending values with '0' all fields are completely filled, pre-pending values with '0'
characters as necessary. characters as necessary.
Timestamp (10 bytes): Date and time of the request or response Timestamp (10 bytes): Date and time of the request or response
represented as the number of seconds since the Unix epoch (i.e. represented as the number of seconds since the Unix epoch (i.e.
seconds since midnight, January 1st, 1970, GMT). Represented in seconds since midnight, January 1st, 1970, GMT).
big-endian fashion with most significant octet first from zero
starting at the left, or high-order, position. Decimal encoded.
Fractional Seconds (3 bytes): Fractional seconds portion of the Fractional Seconds (3 bytes): Fractional seconds portion of the
Timestamp field to millisecond accuracy. Represented in big- Timestamp field to millisecond accuracy.
endian fashion with most significant octet first from zero
starting at the left, or high-order, position. Decimal encoded. The combined Timestamp and Fractional Seconds fields are
represented in the log file as a UTF-8 encoded string representing
the date and time of the request or response represented as the
number of seconds and milliseconds since the Unix epoch. The
number of milliseconds MUST be separated by a "." (UTF-8
character 0x2E) from the number of seconds.
Flags Field (5 bytes): Flags Field (5 bytes):
byte 1 - Request/Response flag byte 1 - Request/Response Flag
R = Request R = Request
r = Response r = Response
byte 2 - Retransmission flag byte 2 - Retransmission Flag
O = Original transmission O = Original transmission
D = Duplicate transmission D = Duplicate transmission
S = Server is stateless [i.e., retransmissions are not S = Server is stateless [i.e., retransmissions are not
detected] detected]
byte 3 - Sent/Received flag byte 3 - Sent/Received Flag
S = Sent mesage S = Sent mesage
R = Received mesage R = Received mesage
byte 4 - Transport flag byte 4 - Transport Flag
The Transport Flag values are IANA-assigned (Section 9.2) via
the IETF Review method as described in [RFC5226]. Currently
registered values are:
U = UDP U = UDP
T = TCP T = TCP
S = SCTP S = SCTP
byte 5 - Encryption flag byte 5 - Encryption Flag
E = Encrytpted mesage (TLS, DTLS, etc.) E = Encrytpted mesage (TLS, DTLS, etc.)
U = Unencrypted mesage U = Unencrypted mesage
After the "Timestamp", "Fractional Seconds" and the "Flags" fields After the "Timestamp", "Fractional Seconds" and the "Flags" fields
are the actual values for the mandatory fields specified in Section are the values for the mandatory fields specified in Section 8.1 of
8.1 of [I-D.ietf-sipclf-problem-statement], which are described [I-D.ietf-sipclf-problem-statement], which are described below:
below:
CSeq: The Command Sequence header field, including the CSeq number CSeq: The Command Sequence header field, including the CSeq number
and method name. and method name.
Response Status-Code: Set to the value of the SIP response status Response Status-Code: Set to the value of the SIP response status
code for responses. Set to a single ASCII dash (0x2D) for code for responses. Set to a single UTF-8 dash (0x2D) for
requests. requests.
R-URI: The Request-URI in the start line (mandatory in request), R-URI: The Request-URI in the start line (mandatory in request),
including any URI parameters. including any URI parameters.
Destination IP address:port The IP address of the downstream server, Destination IP address:port The IP address of the downstream server,
including the port number. For IPv4 addresses the port number including the port number. For IPv4 addresses the port number
MUST be separated from the IP address by a single ':'. IPv6 MUST be separated from the IP address by a single ':'. IPv6
addresses are represented using the bracket notation detailed in addresses are represented using the bracket notation detailed in
Section 6 of [RFC5952]. That is, the IPv6 address enclosed in Section 6 of [RFC5952]. That is, the IPv6 address enclosed in
skipping to change at page 13, line 30 skipping to change at page 13, line 33
To URI: Value of the URI in the To header field. To URI: Value of the URI in the To header field.
To Tag: Value of the tag parameter (if present) in the To header To Tag: Value of the tag parameter (if present) in the To header
field. field.
From URI: Value of the URI in the From header field. From URI: Value of the URI in the From header field.
From Tag: Value of the tag parameter in the From header field. From Tag: Value of the tag parameter in the From header field.
Whilst one may question the value of the From URI in light of
[RFC4474], the From URI, nonetheless, imparts some information. For
one, the From tag is important and, in the case of a REGISTER
request, the From URI can provide information on whether this was a
third-party registration or a first-party one.
Call-Id: The value of the Call-ID header field. Call-Id: The value of the Call-ID header field.
Server-Txn: Server transaction identification code - the transaction Server-Txn: Server transaction identification code - the transaction
identifier associated with the server transaction. identifier associated with the server transaction.
Implementations can reuse the server transaction identifier (the Implementations can reuse the server transaction identifier (the
topmost branch-id of the incoming request, with or without the topmost branch-id of the incoming request, with or without the
magic cookie), or they could generate a unique identification magic cookie), or they could generate a unique identification
string for a server transaction (this identifier needs to be string for a server transaction (this identifier needs to be
locally unique to the server only.) This identifier is used to locally unique to the server only.) This identifier is used to
correlate ACKs and CANCELs to an INVITE transaction; it is also correlate ACKs and CANCELs to an INVITE transaction; it is also
used to aid in forking. (See Section 9.4 of used to aid in forking. (See Section 9.4 of
[I-D.ietf-sipclf-problem-statement] for usage.) [I-D.ietf-sipclf-problem-statement] for usage.)
Client-Txn: Client transaction identification code - this field is Client-Txn: Client transaction identification code - this field is
used to associate client transactions with a server transaction used to associate client transactions with a server transaction
for forking proxies or B2BUAs. Upon forking, implementations can for forking proxies or B2BUAs. Upon forking, implementations can
reuse the value they inserted into the topmost Via header's branch reuse the value they inserted into the topmost Via header's branch
parameter, or they can generate a unique identification string for parameter, or they can generate a unique identification string for
the client transaction. (See Section 9.4 of the client transaction. (See Section 9.4 of
[I-D.ietf-sipclf-problem-statement] for usage.) [I-D.ietf-sipclf-problem-statement] for usage.)
Note: The definitions of the Server-Txn and Client-Txn are taken
directly from [I-D.ietf-sipclf-problem-statement] and are provided
here only as a convenience to the implementer. The definitions
specified in [I-D.ietf-sipclf-problem-statement] should be
considered authoritative in the event of a conflict.
This data MUST appear in the order listed in <IndexPointers>, and This data MUST appear in the order listed in <IndexPointers>, and
each field MUST be present. Fields are subject the maximum SIP CLF each field MUST be present. Fields are subject the maximum SIP CLF
field size of 4096 bytes as detailed in Section 8 of field size of 4096 bytes as detailed in Section 8 of
[I-D.ietf-sipclf-problem-statement] and are separated by a single [I-D.ietf-sipclf-problem-statement] and are separated by a single
ASCII Tab character (0x09). Any Tab characters present in the data UTF-8 Tab character (0x09). Any Tab characters present in the data
to be written will be replaced by an ASCII space character (0x20) to be written will be replaced by a UTF-8 space character (0x20)
prior to being logged. prior to being logged.
The decision to replace tabs with spaces was based on there being no
known use of tabs in SIP messages to convey any other meaning than
whitespace. Two consequences of the decision to replace tab with a
space character are: (a) it will become impossible to reconstruct a
signature over the logged field that matches the signature over
fields in the original SIP message, and (b) any future SIP header
fields that include tabs with a different semantic meaning than
simply signifying whitespace will lose this meaning when logged. And
finally, the tabs to spaces substitution MUST occur when logging
mandatory fields and optional SIP Header Field or Reason-Phrase
(Tag=00); it SHOULD occur when when optionally logging either the
entire message (Tag=02) or simply a SIP body (Tag=01) as described in
Section 4.3.
An element will not always have an appropriate value to provide for An element will not always have an appropriate value to provide for
one of these fields, even when the field is required to appear in the one of these fields, even when the field is required to appear in the
SIP CLF record. In such circumstances, when a given mandatory field SIP CLF record. In such circumstances, when a given mandatory field
is not present then that empty field MUST be encoded as a single is not present then that empty field MUST be encoded as a single
horizontal dash ("-"). horizontal dash ("-").
In the event that a field failed to parse it MUST be encoded as a In the event that a field failed to parse it MUST be encoded as a
single question mark ("?"). If these characters are part of a single question mark ("?"). If these characters are part of a
sequence of other characters, then there is no ambiguity. If the sequence of other characters, then there is no ambiguity. If the
field being logged contains only one character, and that character is field being logged contains only one character, and that character is
the literal "-", the implementation SHOULD insert an escaped %2D for the literal "-", the implementation SHOULD insert an escaped %2D for
that field in the SIP CLF record. Similarly, if the field contains that field in the SIP CLF record. Similarly, if the field contains
only one character, and that character is the literal "?", the only one character, and that character is the literal "?", the
implementation SHOULD insert an escaped %3F for that field in the SIP implementation SHOULD insert an escaped %3F for that field in the SIP
CLF record. CLF record.
The carriage return line feed (CRLF) at the end of a given header
field value MUST NOT be logged. Thus, mandatory fields MUST NOT
contain a CRLF when logged so no escaping mechanism is required for
it.
Clearly a SIP parser could not possibly successfully parse a SIP CLF
record in its entirety given the SIP CLF format described in this
document. It is possible to parse individual fields in the SIP CLF
record if they are extracted and given to a SIP parser that would
normally parse those sequence of strings. It should be noted that as
a result of the escaping mechanisms used in this document ('-' and
'?') a field that would normally be able to parse if it appeared in a
SIP header (as opposed to a log file) may not be syntactically
parsable by a SIP parser.
4.3. Optional Fields 4.3. Optional Fields
The <OptionalFields> portion of the SIP CLF record is shown below: The <OptionalFields> portion of the SIP CLF record is shown below:
0 7 8 15 16 23 24 31 0 7 8 15 16 23 24 31
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| 0x09 | Tag | 0x40 |\ | 0x09 | Tag | 0x40 |\
+-----------+-----------+-----------+-----------+ \ +-----------+-----------+-----------+-----------+ \
| Vendor-ID | \ | Vendor-ID | \
+-----------+-----------+-----------+-----------+ \ +-----------+-----------+-----------+-----------+ \
skipping to change at page 15, line 34 skipping to change at page 15, line 44
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
Figure 5: Optional Fields Figure 5: Optional Fields
Optional fields are those SIP message elements that are not a part of Optional fields are those SIP message elements that are not a part of
the mandatory fields list detailed in Section 8.1 of the mandatory fields list detailed in Section 8.1 of
[I-D.ietf-sipclf-problem-statement]. After the <MandatoryFields> [I-D.ietf-sipclf-problem-statement]. After the <MandatoryFields>
section, there is an OPTIONAL <OptionalFields> group (shown in section, there is an OPTIONAL <OptionalFields> group (shown in
Figure 5) that MAY appear zero or more times. This <OptionalFields> Figure 5) that MAY appear zero or more times. This <OptionalFields>
group provides extensibility to the SIP CLF. It allows SIP CLF group provides extensibility to the SIP CLF. It allows SIP CLF
implementers the flexibility to extend the logging capability of the implementers the flexibility to extend the logging capability of this
indexed-ASCII representation beyond just the mandatory log elements indexed text representation beyond just the mandatory log elements
described in Section 8.1 of [I-D.ietf-sipclf-problem-statement]. described in Section 8.1 of [I-D.ietf-sipclf-problem-statement].
Logging any optional SIP elements MUST be done according to the Logging any optional SIP elements MUST be done according to the
format shown in Figure 5. The location of the start of format shown in Figure 5. The location of the start of
<OptionalFields> within the SIP CLF record is indicated by the <OptionalFields> within the SIP CLF record is indicated by the
"Optional Fields Start Pointer" field in <IndexPointers>. After the "Optional Fields Start Pointer" field in <IndexPointers>. After the
initial Tab delimiter byte (0x09) shown in Figure 5, the optional initial Tab delimiter byte (0x09) shown in Figure 5, the optional
field being logged is generally represented by the notation: field being logged is generally represented by the notation:
Tag@Vendor-ID,Length,Value Tag@Vendor-ID,Length,Value
skipping to change at page 17, line 7 skipping to change at page 17, line 11
be populated by the name "Reason-Phrase" followed by a colon be populated by the name "Reason-Phrase" followed by a colon
(":") and a single space (SP) between the colon and the logged (":") and a single space (SP) between the colon and the logged
Reason-Phrase value. Reason-Phrase value.
The corresponding "Length" field includes the length of the The corresponding "Length" field includes the length of the
entire "Value" field. This includes the field-name, the colon, entire "Value" field. This includes the field-name, the colon,
and any LWS separator. and any LWS separator.
If an optional field occurs more than once in a SIP message If an optional field occurs more than once in a SIP message
(e.g. Contact, Route, Record-Route, etc.) then each occurrence (e.g. Contact, Route, Record-Route, etc.) then each occurrence
MUST be logged separately with same Tag value. MUST be logged with the same Tag value (i.e., Tag=00) as a
distinct optional field entry in the SIP CLF record. These
repeated optionally logged header fields MUST preserve the
ordinal position of the repeated header fields in the SIP
header. For example, a SIP header containing two Via header
fields with the following ordinal positions within the SIP
header: V1,V2. If optionally logging these header fields they
would occur as the following entries in the SIP CLF record.
(Note: For the sake of brevity this example only shows how
these optional header fields would be logged and omits the
remainder of the SIP CLF record):
Tag = 01 - Log message body 00@00000000,length_V1,Via: V1 00@00000000,length_V2,Via: V2
SIP message bodies with the following body types can be The CRLF at the end of a given header field value MUST NOT be
optionally logged: logged. Thus, optional SIP header fields logged with Tag=00
MUST NOT contain a CRLF when logged so no escaping mechanism is
required for it.
(a) Session Description Protocol (SDP) [RFC4566] (Content- Tag = 01 - Log message body
Type: application/sdp)
(b) Extensible Markup Language (XML) [W3C.REC-xml-20081126] SIP message bodies of all types can be optionally logged using
payloads (Content-Type: application/*+xml) Tag=01. If the message body is logged it MUST adhere to the
(c) binary (Content-Type: application/{isup,qsig}) maximum size limitation of 4096 bytes for a SIP CLF field, as
(d) miscellaneous text content (Content-Type: message/sipfrag, detailed in Section 8 of [I-D.ietf-sipclf-problem-statement].
message/http, text/plain, ...) Unlike with Tag=00, there can only be a single entry in the SIP
CLF record with Tag=01. When optionally logging the message
body if the maximum SIP CLF field size of 4096 bytes is
exceeded the message body being logged MUST be truncated to
meet these size limitations.
When logging a message body (Tag=01), the associated "Value" When logging a message body (Tag=01), the associated "Value"
field is populated with the Content-Type itself plus the SIP field is populated with the Content-Type itself plus the SIP
message body separated with a linear white space (LWS) message body separated with a space. In this manner,
separator. In this manner, everything about all four body everything about the SIP message body is self-described using a
types is self-described using a single tag as compared to single tag as compared to enumerating a separate tag for each
enumerating a separate tag for each body type. Additionally, body type. Additionally, the corresponding "Length" field
the corresponding "Length" field includes the SIP message body, includes the SIP message body, the length of the embedded
the length of the embedded Content-Type, and the LWS separator Content-Type, and the space separator between the MIME type and
between the MIME type and the body content. Note that binary the body content. Note that binary bodies MUST be base64
bodies would have to be byte encoded to render them in the encoded to render them in the SIP CLF log file.
ASCII file.
If an optionally logged SIP message body contains any CRLFs
they MUST be escaped by using the URI encoded equivalent value
of "%0D%0A". This escaping mechanism applies to all body
types.
Tag = 02 - Log entire SIP message Tag = 02 - Log entire SIP message
Logging the message body (Tag=01) or the entire SIP message The entire SIP message (i.e., SIP header and message body) can
(Tag=02) MUST conform to the maximum size limitation of 4096 be optionally logged using a Tag=02. Logging the entire SIP
message MUST conform to the maximum size limitation of 4096
bytes for a SIP CLF field, as detailed in Section 8 of bytes for a SIP CLF field, as detailed in Section 8 of
[I-D.ietf-sipclf-problem-statement]. These can be repeated [I-D.ietf-sipclf-problem-statement]. Unlike with Tag=00, there
multiple times to accommodate SIP messages or bodies that can only be a single entry in the SIP CLF record with Tag=02.
exceed 4096 bytes in length. When optionally logging the entire SIP message if the maximum
SIP CLF field size of 4096 bytes is exceeded the entire SIP
message being logged MUST be truncated to meet these size
limitations.
All instances of CRLFs, whether they appear in the SIP headers
or the SIP message body MUST be escaped by using the URI
encoded equivalent value of "%0D%0A".
(2) Vendor-ID = PEN (2) Vendor-ID = PEN
A Vendor-ID set to a vendor's own private enterprise number from A Vendor-ID set to a vendor's own private enterprise number from
the complete current list of private enterprise numbers maintained the complete current list of private enterprise numbers maintained
by IANA [PEN] is used to log any other vendor-specified optional by IANA [PEN] is used to log any other vendor-specified optional
element of a SIP header or body. The value of the Tag is set at element of a SIP header or body. The value of the Tag is set at
the discretion of the implementer: the discretion of the implementer:
Tag = Vendor-specified tag Tag = Vendor-specified tag
The remaining fields in the format shown in Figure 5 are defined The remaining fields in the format shown in Figure 5 are defined
below: below:
Length Field (4 bytes): Indicates the length of only the "Value" Length Field (4 bytes): Indicates the length of only the "Value"
field of this optionally logged element, hexadecimal encoded. field of this optionally logged element (as shown in Figure 5),
This length does not include the header shown in Figure 5. hexadecimal encoded. This length corresponds to the length of the
"Value" field only and MUST NOT include any of the other elements
shown in Figure 5.
Value Field (0 to 4096 bytes): Contains the actual value of this Value Field (0 to 4096 bytes): Contains the actual value of this
optional field. As with the mandatory fields, ASCII Tab optional field. As with the mandatory fields, UTF-8 Tab
characters (0x09) are replaced with ASCII space characters (0x20). characters (0x09) are replaced with UTF-8 space characters (0x20).
The following are examples of optionally logged SIP elements using The following are examples of optionally logged SIP elements using
the syntax described in this section. All these examples only show the syntax described in this section. All these examples only show
the <OptionalFields> portion of the SIP CLF record. The mandatory the <OptionalFields> portion of the SIP CLF record. The mandatory
<IndexPointers> and <MandatoryFields> portions of the SIP CLF are <IndexPointers> and <MandatoryFields> portions of the SIP CLF are
intentionally omitted for the sake of brevity. Note that all of intentionally omitted for the sake of brevity. Note that all of
these examples of optionally logged fields begin with a leading Tab these examples of optionally logged fields begin with a leading Tab
delimiter byte (0x09) that is not apparent here. delimiter byte (0x09) that is not apparent here.
(1) Contact header field logged as an optional field: (1) Contact header field logged as an optional field:
skipping to change at page 19, line 29 skipping to change at page 20, line 15
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.example.com o=alice 2890844526 2890844526 IN IP4 host.example.com
s=- s=-
c=IN IP4 host.example.com c=IN IP4 host.example.com
t=0 0 t=0 0
m=audio 49170 RTP/AVP 0 8 97 m=audio 49170 RTP/AVP 0 8 97
This body has a Content-Type of application/sdp and is of length This body has a Content-Type of application/sdp and is of length
of 123 bytes including all the line-feeds. When logging this of 123 bytes including all the line-feeds. When logging this
body the "Value" field is composed of the Content-Type and the body the "Value" field is composed of the Content-Type and the
body separated by a LWS, which gives it a combined length of 139 body separated by a space, which gives it a combined length of
(0x008B) bytes. This SIP body would be logged as an optional 139 (0x008B) bytes. This SIP body would be logged as an
field in the following manner: optional field in the following manner:
<allOneLine> <allOneLine>
01@00000000,008B,application/sdp v=0\r\no=alice 2890844526 01@00000000,008B,application/sdp v=0%0D%0Ao=alice 2890844526
2890844526 IN IP4 host.example.com\r\ns=-\r\n 2890844526 IN IP4 host.example.com%0D%0As=-%0D%0A
c=IN IP4 host.example.com\r\nt=0 0\r\n c=IN IP4 host.example.com%0D%0At=0 0%0D%0A
m=audio 49170 RTP/AVP 0 8 97\r\n m=audio 49170 RTP/AVP 0 8 97%0D%0A
</allOneLine> </allOneLine>
Note that the body is actually logged on a single line and are Note that the body is actually logged on a single line and is
thus captured between <allOneLine/> tags. The line-feeds are thus captured between <allOneLine/> tags. The line-feeds are
escaped using \r\n to delimit the various lines in the message escaped using %0D%0A to delimit the various lines in the message
body. body.
(4) Codec information from the SDP body logged as an optional field: (4) Codec information from the SDP body logged as an optional field:
Consider the SIP message: Consider the SIP message:
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8
To: Bob <bob@example.com> To: Bob <bob@example.com>
From: Alice <alice@example.com>;tag=1928301774 From: Alice <alice@example.com>;tag=1928301774
skipping to change at page 22, line 18 skipping to change at page 22, line 20
INVITE sip:192.0.2.10 SIP/2.0 INVITE sip:192.0.2.10 SIP/2.0
To: <sip:192.0.2.10> To: <sip:192.0.2.10>
Call-ID: DL70dff590c1-1079051554@example.com Call-ID: DL70dff590c1-1079051554@example.com
<allOneLine> <allOneLine>
From: "Alice" <sip:1001@example.com:5060>; From: "Alice" <sip:1001@example.com:5060>;
tag=DL88360fa5fc;epid=0x34619b0 tag=DL88360fa5fc;epid=0x34619b0
</allOneLine> </allOneLine>
CSeq: 1 INVITE CSeq: 1 INVITE
Max-Forwards: 70 Max-Forwards: 70
Date: Thu, 21 Feb 2012 15:02:03 GMT
<allOneLine> <allOneLine>
Via: SIP/2.0/TCP 192.0.2.200:5060; Via: SIP/2.0/TCP 192.0.2.200:5060;
branch=z9hG4bK-1f6be070c4-DL branch=z9hG4bK-1f6be070c4-DL
</allOneLine> </allOneLine>
Contact: "1001" <sip:1001@192.0.2.200:5060> Contact: "1001" <sip:1001@192.0.2.200:5060>
<allOneLine>
Allow: INVITE,CANCEL,ACK,OPTIONS,INFO,SUBSCRIBE,NOTIFY,BYE,
MESSAGE,UPDATE,REFER
</allOneLine>
Supported: replaces,norefersub
User-Agent: Some Vendor
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 418 Content-Length: 418
v=0 v=0
o=1001 1456139204 0 IN IP4 192.0.2.200 o=1001 1456139204 0 IN IP4 192.0.2.200
s=- s=Session SDP
c=IN IP4 192.0.2.200 c=IN IP4 192.0.2.200
b=AS:2048 b=AS:2048
t=0 0 t=0 0
m=audio 13756 RTP/AVP 0 101 m=audio 13756 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=x-mpdp:192.0.2.200:13756
m=video 13758 RTP/AVP 96
a=rtpmap:96 H264/90000
<allOneLine>
a=fmtp:96 profile-level-id=420015; max-mbps=47520; max-fs=1584;
max-dpb=7680
</allOneLine>
a=x-mpdp:192.0.2.200:13758
Shown below is approximately how this message would appear as a Shown below is approximately how this message would appear as a
single record in a SIP CLF logging file if encoded according to the single record in a SIP CLF logging file if encoded according to the
syntax described in this document. Due to internet-draft syntax described in this document. Due to RFC conventions, this log
conventions, this log entry has been split into five lines, instead entry has been split into five lines, instead of the two lines that
of the two lines that actually appear in a log file; and the tab actually appear in a log file; and the tab characters have been
characters have been padded out using spaces to simulate their padded out using spaces to simulate their appearance in a text
appearance in a text terminal. terminal.
A0000FE,0053005C005E006D007D008F009E00A000BA00C700EB00F500FE A000100,0053005C005E006D007D008F009E00A000BA00C700EB00F70100
<allOneLine> <allOneLine>
0000000000.010 RORUU 1 INVITE - sip:192.0.2.10 1328821153.010 RORUU 1 INVITE - sip:192.0.2.10
192.0.2.10:5060 192.0.2.200:56485 sip:192.0.2.10 - 192.0.2.10:5060 192.0.2.200:56485 sip:192.0.2.10 -
sip:1001@example.com:5060 DL88360fa5fc sip:1001@example.com:5060 DL88360fa5fc
DL70dff590c1-1079051554@example.com server-tx client-tx DL70dff590c1-1079051554@example.com S1781761-88 C67651-11
</allOneLine> </allOneLine>
A Base64 encoded version of this log entry (without the changes A Base64 encoded version of this log entry (without the changes
required to format it for an Internet-Draft) is shown below. required to format it for an RFC) is shown below.
begin-base64 644 clf_record begin-base64 644 clf_record
QTAwMDBGRSwwMDUzMDA1QzAwNUUwMDZEMDA3RDAwOEYwMDlFMDBBMDAwQkEwMEM3MDBF QTAwMDEwMCwwMDUzMDA1QzAwNUUwMDZEMDA3RDAwOEYwMDlFMDBBMDAwQkEwMEM3MDBF
QjAwRjUwMEZFCjAwMDAwMDAwMDAuMDEwICBST1JVVSAgIDEgSU5WSVRFICAgICAgICAt QjAwRjcwMTAwCjEzMjg4MjExNTMuMDEwCVJPUlVVCTEgSU5WSVRFCS0Jc2lwOjE5Mi4w
ICAgICAgIHNpcDoxOTIuMC4yLjEwICAxOTIuMC4yLjEwOjUwNjAgMTkyLjAuMi4yMDA6 LjIuMTAJMTkyLjAuMi4xMDo1MDYwCTE5Mi4wLjIuMjAwOjU2NDg1CXNpcDoxOTIuMC4y
NTY0ODUgICAgICAgc2lwOjE5Mi4wLjIuMTAgIC0gICAgICAgc2lwOjEwMDFAZXhhbXBs LjEwCS0Jc2lwOjEwMDFAZXhhbXBsZS5jb206NTA2MAlETDg4MzYwZmE1ZmMJREw3MGRm
ZS5jb206NTA2MCAgICAgICBETDg4MzYwZmE1ZmMgICAgREw3MGRmZjU5MGMxLTEwNzkw ZjU5MGMxLTEwNzkwNTE1NTRAZXhhbXBsZS5jb20JUzE3ODE3NjEtODgJQzY3NjUxLTEx
NTE1NTRAZXhhbXBsZS5jb20gICAgIHNlcnZlci10eCAgICAgICBjbGllbnQtdHgK Cg==
==== ====
To recover the unencoded file, the Base64 text above may be passed as To recover the unencoded file, the Base64 text above may be passed as
input to the following perl script (the output should be redirected input to the following perl script (the output should be redirected
to a file). to a file).
<CODE BEGINS>
#!/usr/bin/perl #!/usr/bin/perl
use strict; use strict;
my $bdata = ""; my $bdata = "";
use MIME::Base64; use MIME::Base64;
while(<>) while(<>)
{ {
if (/begin-base64 644 clf_record/ .. /-- ==== --/) if (/begin-base64 644 clf_record/ .. /-- ==== --/)
{ {
if ( m/^\s*[^\s]+\s*$/) if ( m/^\s*[^\s]+\s*$/)
{ {
$bdata = $bdata . $_; $bdata = $bdata . $_;
} }
} }
} }
print decode_base64($bdata); print decode_base64($bdata);
<CODE ENDS>
6. Text Tool Considerations 6. Text Tool Considerations
This format has been designed to allow text tools to easily process This format has been designed to allow text tools to easily process
logs without needing to understand the indexing format. Index lines logs without needing to understand the indexing format. Index lines
may be rapidly discarded by checking the first character of the line: may be rapidly discarded by checking the first character of the line:
index lines will always start with an alphabetical character, while index lines will always start with an alphabetical character, while
field lines will start with a numerical character. field lines will start with a numerical character.
Within a field line, script tools can quickly split fields at the tab Within a field line, script tools can quickly split fields at the tab
characters. The first 12 fields are positional, and the meaning of characters. The first 12 fields are positional, and the meaning of
skipping to change at page 25, line 10 skipping to change at page 24, line 39
depending on traffic volume at a processing entity and the amount of depending on traffic volume at a processing entity and the amount of
information being logged. As such, any enterprise using SIP CLF information being logged. As such, any enterprise using SIP CLF
should establish operational procedures for file rollovers as should establish operational procedures for file rollovers as
appropriate to the needs of the organization. appropriate to the needs of the organization.
Listing such operational guidelines in this document is out of scope Listing such operational guidelines in this document is out of scope
for this work. for this work.
9. IANA Considerations 9. IANA Considerations
This document does not require any considerations from IANA. 9.1. SIP CLF Version
This document defines the SIP CLF "Version" field in Section 4.1.
IANA has created a registry of Version values entitled "SIP CLF
Version Values". Version numbers MUST be incremented for any new SIP
CLF protocol specification that changes any part of the SIP CLF
record format. Changes include addition or removal of fields or a
change of syntax or semantics of existing fields.
Version numbers must be registered via the Standards Action method as
described in [RFC5226]. IANA has registered the Versions shown in
Table 1 below.
+---------+--------------------+-----------+
| Version | FORMAT | Reference |
+---------+--------------------+-----------+
| 0x41 | Defined in RFCXXXX | RFCXXXX |
+---------+--------------------+-----------+
Table 1: IANA-Registered SIP CLF Versions
[[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to
this specification, and remove this paragraph on publication.]]
9.2. SIP CLF Transport Flag
This document defines the SIP CLF "Transport Flag" as fourth byte in
the Flags Field of the SIP CLF record. The format and values of the
Transport Flag are described in Section 4.2. IANA has created a
registry of SIP CLF Transport Flag values entitled "SIP CLF Transport
Flag Values".
SIP CLF Transport Flag values must be registered via the IETF Review
method as described in [RFC5226]. IANA has registered the Transport
Flag values shown in Table 2 below.
+-------+--------------------+-----------+
| Value | Transport Protocol | Reference |
+-------+--------------------+-----------+
| U | UDP | RFCXXXX |
| T | TCP | RFCXXXX |
| S | SCTP | RFCXXXX |
+-------+--------------------+-----------+
Table 2: IANA-Registered SIP CLF Transport Flag
[[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to
this specification, and remove this paragraph on publication.]]
10. Acknowledgements 10. Acknowledgements
The authors of this document would like to acknowledge and thank The authors of this document would like to acknowledge and thank
Peter Musgrave for his support, guidance, and continued invaluable Peter Musgrave (the chair of the SIPCLF working group) and Robert
feedback. Sparks (the assigned area director) for their support, guidance, and
continued invaluable feedback.
This work benefited from the discussions and invaluable input by the This work benefited from the discussions and invaluable input by the
various members of the SIPCLF working group. These include Brian various members of the SIPCLF working group. These include Brian
Trammell, Eric Burger, Cullen Jennings, Benoit Claise, Saverio Trammell, Eric Burger, Cullen Jennings, Benoit Claise, Saverio
Niccolini, Dan Burnett. Special thanks to Hadriel Kaplan, Chris Niccolini, Dan Burnett. Special thanks to Hadriel Kaplan, Chris
Lonvick, Paul E. Jones, John Elwell for their constructive comments, Lonvick, Paul E. Jones, John Elwell, Claudio Allocchio for their
suggestions, and reviews that were critical to the formulation and constructive comments, suggestions, and reviews that were critical to
refinement of this draft. the formulation and refinement of this document.
Thanks to Anders Nygren for his early implementation, insight, and Thanks to Anders Nygren for his early implementation, insight, and
reviews of the SIP CLF format. reviews of the SIP CLF format.
This document was written with the xml2rfc tool described in
[RFC2629].
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-sipclf-problem-statement] [I-D.ietf-sipclf-problem-statement]
Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O. Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O.
Festor, "The Common Log Format (CLF) for the Session Festor, "The Common Log Format (CLF) for the Session
Initiation Protocol (SIP): Framework and Data Model", Initiation Protocol (SIP): Framework and Data Model",
draft-ietf-sipclf-problem-statement-09 (work in progress), draft-ietf-sipclf-problem-statement-11 (work in progress),
December 2011. March 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
11.2. Informative References 11.2. Informative References
[PEN] IANA, "Private Enterprise Numbers", [PEN] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers , 2009. http://www.iana.org/assignments/enterprise-numbers , 2009.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
Authenticated Identity Management in the Session June 1999.
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
and H. Schulzrinne, "Session Initiation Protocol (SIP) and H. Schulzrinne, "Session Initiation Protocol (SIP)
Torture Test Messages", RFC 4475, May 2006. Torture Test Messages", RFC 4475, May 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Description Protocol", RFC 4566, July 2006. IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for
Documentation Use", RFC 5612, August 2009. Documentation Use", RFC 5612, August 2009.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010. BCP 153, RFC 5735, January 2010.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, January 2010. Reserved for Documentation", RFC 5737, January 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010. Address Text Representation", RFC 5952, August 2010.
[W3C.REC-xml-20081126] [W3C.REC-xml-20081126]
Yergeau, F., Sperberg-McQueen, C., Maler, E., Paoli, J., Sperberg-McQueen, C., Yergeau, F., Maler, E., Paoli, J.,
and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008, xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>. <http://www.w3.org/TR/2008/REC-xml-20081126>.
Authors' Addresses Authors' Addresses
Gonzalo Salgueiro Gonzalo Salgueiro
Cisco Systems Cisco Systems
7200-12 Kit Creek Road 7200-12 Kit Creek Road
 End of changes. 70 change blocks. 
146 lines changed or deleted 272 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/