A Common Log Format for SIP using IPFIX Files
draft-niccolini-sipclf-ipfix-04

Abstract

This draft defines a log file format conforming to the information model defined in the SIP-CLF problem statement based upon the IPFIX File Format. It details the creation and interpretation of these files, and provides examples based on common SIP situations.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on February 18, 2011.

Copyright Notice

Copyright (c) 2010 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
    1.1.  Introduction to IPFIX
    1.2.  Encoding and Limits
2.  Information Elements for SIPCLF
3.  Recommended Templates for SIPCLF
4.  IPFIX File Format for SIPCLF
    4.1.  Logging Large SIP Bodies
    4.2.  Supporting fast searches of SIPCLF log files
5.  Efficiency Analysis
6.  Examples
    6.1.  Base Template Export
    6.2.  UAC registration
    6.3.  Direct Call
    6.4.  Single Downstream Branch Call
    6.5.  Forked Call
    6.6.  Torture Tests
7.  Security Considerations
8.  IANA Considerations
9.  Acknowledgments
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses

1.  Introduction

The SIPCLF WG is chartered to produce a format suitable for logging at any SIP element. The charter explicitly addresses the need to search, merge and summarize log records from one or more possibly diverse elements as well as the need to correlate messages from multiple elements. An additional consideration to be taken into account when defining the file format is the extensibility of SIP. SIPCLF is additionally chartered to identify the fields to appear in a log record and provide one or more formats for encoding those fields. As the IPFIX File format (Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, “Specification of the IP Flow Information Export (IPFIX) File Format,” October 2009.) [RFC5655] meets these requirements, SIPCLF is presently considering an IPFIX File-based binary logging format, in addition to an ASCII text-based format. This document describes the IPFIX format.

Specifically, this document defines new Information Elements for the SIPCLF IPFIX file format (based on the data model detailed in [I‑D.ietf‑sipclf‑problem‑statement] (Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O. Festor, “The Common Log Format (CLF) for the Session Initiation Protocol (SIP),” June 2010.)), proposes common IPFIX Templates for this data model, uses these templates to define a format, and presents examples of an IPFIX File logging format for SIPCLF. For this purpose examples were taken from [I‑D.ietf‑sipclf‑problem‑statement] (Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O. Festor, “The Common Log Format (CLF) for the Session Initiation Protocol (SIP),” June 2010.), and torture tests to demonstrate the applicability of the format to uncommon situations from [RFC4475] (Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, “Session Initiation Protocol (SIP) Torture Test Messages,” May 2006.).

1.1.  Introduction to IPFIX

IPFIX (IP Flow Export Protocol) (Claise, B., “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information,” January 2008.) [RFC5101] is an IETF Proposed Standard protocol for the export of network traffic information. In addition to a transport-agnostic unidirectional export protocol, it defines a simple encapsulation into files (Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, “Specification of the IP Flow Information Export (IPFIX) File Format,” October 2009.) [RFC5655] which expands its applicability into logging and file storage. Originally designed for flows, its flexible and extensible data model lends itself readily to any situation involving events occurring on a network.

The central unit of or storage in IPFIX is the Message. An IPFIX Message is composed of a header and one or more Sets. The header contains metadata about the message such as its length and when it was exported; see section 3.1 of [RFC5101] (Claise, B., “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information,” January 2008.) for details. Each Set is prefixed by a header containing an ID, which identifies the type of the set's contents; and the length of the set; this is detailed in section 3.3 of [RFC5101] (Claise, B., “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information,” January 2008.).

The ID of the set refers to a Template describing each Record within the Set. A Template is an ordered list of Information Elements drawn from a registry covering many fields relevant to network traffic export. New Information Elements may be added to the IANA registry to cover new applications, and may also be defined on the fly as enterprise-specific Information Elements, scoped to private registries within an SMI Private Enterprise Number.

Templates are exported inline, alongside data, within IPFIX Sets identified by special Set IDs. In this way, an IPFIX Message stream is self-describing with minimal overhead in situations where the number of records is much greater than the number of record types. This is a feature of the SIPCLF data model, and indicates the applicability of IPFIX to SIPCLF logging.

1.2.  Encoding and Limits

Each Information Element specifies a data type, covering most primitives (e.g. signed and unsigned integers, floats, booleans, strings) as well as some network-specific types (addresses, timestamps). All types other than strings and octet arrays are stored in network byte order. Within a Template, an Information Element may be specified to have a fixed length or a variable length; if the latter, the field in the Record has a length prefix of one or three bytes. One-byte prefixes represent lengths from 0 to 254; three byte prefixes are encoded as 255 followed by an unsigned16 in network byte order and can represent lengths from 0 to 65535. Typically, strings are stored with variable length, so IPFIX string fields can be thought of as length-prefixed (or "Pascal") strings. Two advantages of this encoding are that each variable-length field in IPFIX can be skipped with one or two comparisons (depending on the length representation), and that the framing itself is immune to misformatted strings (e.g., with embedded NULs).

Although IPFIX variable length Information Elements can represent single values up to 65535 bytes long, there is an additional length limit imposed by the Message format itself. Each Message has an unsigned 16-bit length in its header; this length includes the length of the header itself as well as any set headers, to facilitate easy framing and deframing of messages. Since the header is 16 bytes, and the set header 4 bytes, the minimum per-message overhead (a message with one set containing only one record) is 20 bytes, leading to a record limit of 65515 bytes. A record containing a single variable-length element with 3-byte length encoding therefore has a content limit of 65512 bytes. The implications this has for SIPCLF are discussed in Section 4.1 (Logging Large SIP Bodies).

2.  Information Elements for SIPCLF

This section formally defines information elements for SIPCLF based on the data model proposed in [I‑D.ietf‑sipclf‑problem‑statement] (Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O. Festor, “The Common Log Format (CLF) for the Session Initiation Protocol (SIP),” June 2010.).

The IANA IPFIX Information Elements registry available at http://www.iana.org/assignments/ipfix/ipfix.xhtml defines a number of Information Elements useful to SIPCLF. These concern traditional flow key and timing information, and appear in the table below:

In addition, we define the following Information Elements to represent the SIP-specific mandatory fields defined in [I‑D.ietf‑sipclf‑problem‑statement] (Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O. Festor, “The Common Log Format (CLF) for the Session Initiation Protocol (SIP),” June 2010.), many themselves taken from [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). As these are not yet registered with IANA, but required to support experimental implementation during the development of this representation, these are provisionally located within the number space assigned to Private Enterprise Number (PEN), here registered within the private enterprise number 35566, which belongs to one of the authors of this draft. It is intended that these Information Elements be registered within the IANA number space, should this draft become a Proposed Standard.

The sipObservationType IE encodes whether the device logging the entry was the sender or received of the message. It can take the following four values:

The sipMethod IE encodes the supported methods from [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) as integers, by the order in which they appear in the IANA SIP Parameters Methods registry at http://www.iana.org/assignments/sip-parameters:

The following Information Elements are defined to represent additional SIP fields which have been identified as potentially useful by the SIPCLF working group.

Bringing this all together, the additional Information Elements required by SIPCLF, in textual IE specification format (Trammell, B., “A Lightweight Textual Format for IPFIX Information Models and Templates,” August 2010.) [I‑D.trammell‑ipfix‑text‑iespec] is as follows; IE numbers appear in parentheses, IPFIX types in angle brackets, and sizes ("v" for variable-length) in square brackets:

sipAuthUsername(35566/401)<string>[v]
sipMethod(35566/402)<unsigned8>[1]
sipRequestURI(35566/403)<string>[v]
sipFromURI(35566/404)<string>[v]
sipFromTag(35566/405)<string>[v]
sipToURI(35566/406)<string>[v]
sipToTag(35566/407)<string>[v]
sipCallId(35566/408)<string>[v]
sipSequenceNumber(35566/409)<unsigned32>[4]
sipContactURI(35566/410)<string>[v]
sipPaiURI(35566/411)<string>[v]
sipResponseStatus(35566/412)<unsigned16>[2]
sipServerTransaction(35566/413)<string>[v]
sipClientTransaction(35566/414)<string>[v]
sipSessionId(35566/415)<octetArray>[16]
sipBodySection(35566/416)<octetArray>[v]
sipBodySectionOffset(35566/417)<unsigned64>[8]
sipBodyLength(35566/418)<unsigned64>[8]
sipObservationType(35566/419)<unsigned8>[8]

3.  Recommended Templates for SIPCLF

The following Templates are defined as recommended Templates for SIPCLF request and response messages. These are base templates, containing only mandatory Information Elements. Request and Response Templates MUST contain at lease the Information Elements defined here. Optional Information Elements MAY be added to them, and the IPv4 addresses within these Templates MUST be replaced with IPv6 addresses for logging IPv6 transport of SIP messages. A sipServerTransaction Information Element SHOULD be added for all messages logged by a User Agent Server, and a sipClientTransaction Information Element SHOULD be added for all messages logged by a User Agent Client. These templates follow the recommended fields for request and response logging in [I‑D.ietf‑sipclf‑problem‑statement] (Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O. Festor, “The Common Log Format (CLF) for the Session Initiation Protocol (SIP),” June 2010.), and are defined using the representation in [I‑D.trammell‑ipfix‑text‑iespec] (Trammell, B., “A Lightweight Textual Format for IPFIX Information Models and Templates,” August 2010.).

observationTimeMilliseconds(323)[8]
sipSequenceNumber(35566/409)[4]
sourceIPv4Address(8)[4]
destinationIPv4Address(12)[4]
sourceTransportPort(7)[2]
destinationTransportPort(11)[2]
protocolIdentifier(4)[1]
sipMethod(35566/402)[1]
sipObservationType(35566/419)[1]
sipRequestURI(35566/403)[v]
sipToURI(35566/406)[v]
sipToTag(35566/407)[v]
sipFromURI(35566/404)[v]
sipFromTag(35566/405)[v]
sipCallId(35566/408)[v]

observationTimeMilliseconds(323)[8]
sipSequenceNumber(35566/409)[4]
sourceIPv4Address(8)[4]
destinationIPv4Address(12)[4]
sourceTransportPort(7)[2]
destinationTransportPort(11)[2]
sipResponseStatus(35566/412)[2]
protocolIdentifier(4)[1]
sipMethod(35566/402)[1]
sipObservationType(35566/419)[1]
sipToURI(35566/406)[v]
sipToTag(35566/407)[v]
sipFromURI(35566/404)[v]
sipFromTag(35566/405)[v]
sipCallId(35566/408)[v]

Note that the Information Elements in these templates are ordered to place the fixed-length elements before the variable-length ones, which speeds random access to fixed-length elements. Elements are also kept in native alignment within records. However, since element order within a record is unimportant in IPFIX, any ordering of the mandatory Information Elements within a record MUST be accepted as a valid SIPCLF record for that record type.

The record type is determined by the presence of the sipResponseStatus field. If present in the Template, the Template describes a response record. If absent, it describes a request record.

4.  IPFIX File Format for SIPCLF

Now that we have defined Information Elements to support the SIPCLF Data Model and recommended Templates to define the records, we combine this data model to the IPFIX File format to define the SIPCLF format over IPFIX.

The IPFIX File format is defined in [RFC5655] (Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, “Specification of the IP Flow Information Export (IPFIX) File Format,” October 2009.) as a serialized set of IPFIX Messages containing Data Records organized in Sets defined by Templates; these are in turn defined in the IPFIX Protocol specification (Claise, B., “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information,” January 2008.) [RFC5101]. The file format is designed to facilitate interoperability, flexibility, and reusability among a wide variety of storage, processing, and analysis tools.

A SIPCLF-IPFIX file is then defined as an IPFIX File as in [RFC5655] (Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, “Specification of the IP Flow Information Export (IPFIX) File Format,” October 2009.) containing Templates containing at least the Information Elements defined in the recommended Templates above, followed by Data Sets containing records defined by those Templates.

The Template mechanism provided by IPFIX allows some flexibility here. A SIPCLF-IPFIX file writer MAY include other Information Elements in the Templates it uses for SIP logging (for example, to add additional information such as in the list of optional Information Elements, above), and MAY include Templates and records described by them which do not contain SIPCLF information; these latter records MAY be ignored by SIPCLF file readers.

Some specific considerations for SIPCLF-IPFIX files are detailed in the subsections below.

4.1.  Logging Large SIP Bodies

As noted in Section 1.2 (Encoding and Limits), the IPFIX Message format places a practical limit of 65515 bytes of content per Message. Some SIPCLF fields, particularly the SIP Body, may contain more than 65515 bytes of information. There are two ways to address this.

First, for applications where the requirements do not include full body export, the body can be truncated. This specification provides the sipBodySection and sipBodyLength Information Elements to represent this. Here, the first N bytes of the body would be exported in the variable-length sipBodySection Information Element, and the total length of the SIP body in the sipBodyLength Information Element. A template for requests received at a UAS is shown in Figure 4 (Template for Request Record with Partial Body at UAS).

observationTimeMilliseconds(323)[8]
sipSequenceNumber(35566/409)[4]
sipBodyLength(35566/418)[4]
sourceIPv4Address(8)[4]
destinationIPv4Address(12)[4]
sourceTransportPort(7)[2]
destinationTransportPort(11)[2]
protocolIdentifier(4)[1]
sipMethod(35566/402)[1]
sipObservationType(35566/419)[1]
sipRequestURI(35566/403)[v]
sipToURI(35566/406)[v]
sipToTag(35566/407)[v]
sipFromURI(35566/404)[v]
sipFromTag(35566/405)[v]
sipCallId(35566/408)[v]
sipServerTransaction(35566/413)[v]
sipBodySection(35566/416)[v]

For exporting large complete SIP bodies, a second continuation template is necessary, as in figure Figure 5 (Template for Request Record Body Continuation). In this case, a record containing the first 64k (minus the length of the other fields) is exported using a template similar to the partial body template above. Then additional sections of the SIP body at subsequent specified offsets into the SIP body are exported in continuation records in subsequent messages. The SIP message whose body is continued is uniquely identified by the 5-tuple flow key and the observation time. This template allows the export of up to 65487 bytes of body per IPFIX message (65515 message payload - 25 fixed fields - 3 sipBodySection length).

observationTimeMilliseconds(323)[8]
sipBodyOffset(35566/417)[4]
sourceIPv4Address(8)[4]
destinationIPv4Address(12)[4]
sourceTransportPort(7)[2]
destinationTransportPort(11)[2]
protocolIdentifier(4)[1]
sipBodySection(35566/416)[v]

4.2.  Supporting fast searches of SIPCLF log files

The order of fields in an IPFIX data record is semantically unimportant, since the Template defines where each field in the record is. However, note that in all the Templates defined to this point, we have placed fixed-length fields before variable length fields. This increases the efficiency of both Message export and decoding, since each fixed length field as well as the first variable-length field have fixed offsets into the Message.

Random access to a field within a record (i.e., for comparison purposes during a sequential scan) is therefore constant-time for fixed-length fields, and requires one or two comparisons per subsequent field for variable-length fields.

However, since Sets encode the length of the Set, not of the records therein, and each Set may contain multiple records, a Set containing records with variable-length fields must be sequentially searched in order to find the beginning of the next Message. This situation can be improved by exporting only one Record per Set: in this case, the Set length equals the Record length minus the constant Set header length (4), reducing the number of comparisons needed for skipping records.

5.  Efficiency Analysis

[TODO]

6.  Examples

This section presents several views of an example IPFIX-based SIPCLF log, in order to increase understanding of what IPFIX would mean for SIPCLF. We present both binary and textual forms. The tools to generate this section are based upon the open-source ripfix (Trammell, B., “ripfix: IPFIX for Ruby,” .) [ripfix] implementation of IPFIX, maintained by one of the authors of this draft.

Here we show the log entries generated by the situations in sections 9.1 through 9.4 of [I‑D.ietf‑sipclf‑problem‑statement] (Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O. Festor, “The Common Log Format (CLF) for the Session Initiation Protocol (SIP),” June 2010.).

6.1.  Base Template Export

A SIPCLF log file is, as described above just an IPFIX File with SIPCLF Templates. As Templates are themselves exported in IPFIX Messages, and a File is simply composed of a stream of Messages, first, we can export a Message containing only Templates describing the record formats we will use in subsequent examples. These Templates are as shown in Figure 2 (Base Request Template (IPv4)) and Figure 3 (Base Response Template (IPv4)).

Exporting these Templates results in the following IPFIX message, illustrated as an annotated hexdump in Figure 6 (Base template message export).

0000: 00 0a 00 ec 4c 62 7f e8 00 00 00 00 00 00 30 39  ....Lb........09
     [ IPFIX message header, length 236              ]
0010: 00 02 00 dc                                      ....
     [ Template set (ID 2) header, length 220 ]
0014:             01 01 00 10                              ....
                 [ Template ID 257, count 16 IEs ]
0018:                         01 43 00 08 81 99 00 04          .C......
0020: 00 00 8a ee 00 08 00 04 00 0c 00 04 00 07 00 02  ................
0030: 00 0b 00 02 00 04 00 01 81 92 00 01 00 00 8a ee  ................
0040: 81 93 ff ff 00 00 8a ee 81 96 ff ff 00 00 8a ee  ................
0050: 81 97 ff ff 00 00 8a ee 81 94 ff ff 00 00 8a ee  ................
0060: 81 95 ff ff 00 00 8a ee 81 98 ff ff 00 00 8a ee  ................
0070: 81 9e ff ff 00 00 8a ee 81 9d ff ff 00 00 8a ee  ................
     [ Base request template content (ID 257)        ]
0080: 01 02 00 10                                      ....
     [ Template ID 258, count 16 IEs ]
0084:             01 43 00 08 81 99 00 04 00 00 8a ee      .C..........
0090: 00 08 00 04 00 0c 00 04 00 07 00 02 00 0b 00 02  ................
00a0: 81 9c 00 02 00 00 8a ee 00 04 00 01 81 92 00 01  ................
00b0: 00 00 8a ee 81 96 ff ff 00 00 8a ee 81 97 ff ff  ................
00c0: 00 00 8a ee 81 94 ff ff 00 00 8a ee 81 95 ff ff  ................
00d0: 00 00 8a ee 81 98 ff ff 00 00 8a ee 81 9e ff ff  ................
00e0: 00 00 8a ee 81 9d ff ff 00 00 8a ee              ............
     [ Base response template content (ID 258)       ]

6.2.  UAC registration

Having exported templates, now we create a simple SIPCLF-IPFIX log message representing a UAC registration as seen from the UAC, corresponding to example 9.1 in [I‑D.ietf‑sipclf‑problem‑statement] (Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O. Festor, “The Common Log Format (CLF) for the Session Initiation Protocol (SIP),” June 2010.). This message contains two records, including the UAS registration request, and the response received. This is shown in the annotated hexdump in Figure 7 (Message containing two log entries for UAC registration).

0000: 00 0a 00 d8 4c 62 8f 37 00 00 00 00 00 00 30 39  ....Lb.7......09
     [ IPFIX message header, length 218              ]
0010: 01 01 00 6b                                      ...k
     [ Data set (ID 257) header, length 107 ]
0014:             00 00 01 29 13 66 13 93 00 00 00 01      ...).f......
0020: c6 33 64 0a c6 33 64 01 13 c4 13 c4 11 0c 02 0f  .3d..3d.........
0030: 73 69 70 3a 65 78 61 6d 70 6c 65 2e 63 6f 6d 00  sip:example.com.
0040: 00 15 73 69 70 3a 61 6c 69 63 65 40 65 78 61 6d  ..sip:alice@exam
0050: 70 6c 65 2e 63 6f 6d 05 37 36 79 68 68 15 66 38  ple.com.76yhh.f8
0060: 31 2d 64 34 2d 66 36 40 65 78 61 6d 70 6c 65 2e  1-d4-f6@example.
0070: 63 6f 6d 06 63 2d 74 72 2d 31 00                 com.c-tr-1.
     [ Request record content                        ]
007b:                                  01 02 00 5d                ...]
            [ Data set (ID 258) header, length 93 ]
007f:                                              00                 .
0080: 00 01 29 13 66 15 24 00 00 00 01 c6 33 64 01 c6  ..).f.$.....3d..
0090: 33 64 0a 13 c4 13 c4 00 c8 11 0c 01 00 00 15 73  3d.............s
00a0: 69 70 3a 61 6c 69 63 65 40 65 78 61 6d 70 6c 65  ip:alice@example
00b0: 2e 63 6f 6d 05 37 36 79 68 68 15 66 38 31 2d 64  .com.76yhh.f81-d
00c0: 34 2d 66 36 40 65 78 61 6d 70 6c 65 2e 63 6f 6d  4-f6@example.com
00d0: 06 63 2d 74 72 2d 31 00                          .c-tr-1.
     [ Response record content                       ]

While this demonstrates the binary nature of the SIPCLF-IPFIX format, and shows the content framing for this message, it is not readable for illustration purposes. In Figure 8 (Message containing two log entries for UAC registration), as in all subsequent examples, we run the message through the rfdump tool provided with ripfix to provide a more human-readable view. Note that the sipMethod and sipObservationType are encoded according to the registries in Section 2 (Information Elements for SIPCLF).

==== message sequence 0 in domain 12345 at 2010-08-11 11:53:27 UTC ====
---- record 12345/257 ----
observationTimeMilliseconds => 2010-06-07 17:12:23 UTC
sipSequenceNumber => 1
sourceIPv4Address => 198.51.100.10
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 12
sipObservationType => 2
sipRequestURI => sip:example.com
sipToURI =>
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => 76yhh
sipCallId => f81-d4-f6@example.com
sipClientTransaction => c-tr-1
sipServerTransaction =>
---- record 12345/258 ----
observationTimeMilliseconds => 2010-06-07 17:12:24 UTC
sipSequenceNumber => 1
sourceIPv4Address => 198.51.100.1
destinationIPv4Address => 198.51.100.10
sourceTransportPort => 5060
destinationTransportPort => 5060
sipResponseStatus => 200
protocolIdentifier => 17
sipMethod => 12
sipObservationType => 1
sipToURI =>
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => 76yhh
sipCallId => f81-d4-f6@example.com
sipClientTransaction => c-tr-1
sipServerTransaction =>

6.3.  Direct Call

[TODO: from section 9.2]

6.4.  Single Downstream Branch Call

[TODO: from section 9.3]

6.5.  Forked Call

[TODO: from section 9.4]

6.6.  Torture Tests

To demonstrate that the SIPCLF-IPFIX file format can handle other than simple situations, here we show how log entries from selected SIP torture tests given in [RFC4475] (Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, “Session Initiation Protocol (SIP) Torture Test Messages,” May 2006.). Note that this demonstrates only that there is nothing inherent to the logging format that precludes handling these cases; implementors of logging using SIPCLF-IPFIX must still take care that the SIP-specific side of the implementation handles these torture tests correctly. Each of these tests displays a resulting record with templates defined in Section 6.1 (Base Template Export) and values for unspecified fields taken from Section 6.2 (UAC registration).

The torture test in section 3.1.1.2 tests the handling of unusual characters. Assuming that the SIP parser is able to handle this message, the resulting log entry in rfdump format is shown in Figure 9 (Message containing wide variety of characters) (hand-edited to fit long lines within Internet-Draft limits). Note that the unknown SIP method is logged as such (method 0 = Unknown).

==== message sequence 0 in domain 12345 at 2010-08-12 07:44:33 UTC ====
---- record 12345/257 ----
observationTimeMilliseconds => 2010-08-12 07:44:33 UTC
sipSequenceNumber => 139122385
sourceIPv4Address => 198.51.100.10
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 0
sipObservationType => 1
sipRequestURI => sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/
  ;;*:&it+has=1,weird!*pas$wo~d_too.(doesn't-it)@example.com
sipToURI => sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/
  ;;*@example.com
sipToTag =>
sipFromURI => sip:mundane@example.com
sipFromTag => _token~1'+`*%!-.
sipCallId => intmeth.word%ZK-!.*_+'@word`~)(><:\/"][?}{
sipClientTransaction =>
sipServerTransaction =>

The torture test in section 3.1.1.4 tests the handling of embedded NULs in strings. Since IPFIX uses length-prefixing for variable length strings, this does not present a problem for logging. The resulting record rfdump format in Figure 10 (Message containing NULs in URIs). Here, hex escaping shows that the NUL is properly embedded in the string.

==== message sequence 0 in domain 12345 at 2010-08-11 13:01:05 UTC ====
---- record 12345/257 ----
observationTimeMilliseconds => 2010-08-11 13:01:05 UTC
sipSequenceNumber => 14398234
sourceIPv4Address => 198.51.100.10
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 12
sipObservationType => 2
sipRequestURI => sip:example.com
sipToURI => sip:null-\x00-null@example.com
sipToTag =>
sipFromURI => sip:null-\x00-null@example.com
sipFromTag => 839923423
sipCallId => escnull.39203ndfvkjdasfkq3w4otrq0adsfdfnavd
sipClientTransaction =>
sipServerTransaction =>

The sipToURI portion of the record is shown in Figure 11 (Message containing NULs in URIs) as an annotated hexdump. Note the length byte at the beginning of the string, and the NUL embedded inside.

003f:                                              1b                 .
                          [ varlen record, length 27 ]
0040: 73 69 70 3a 6e 75 6c 6c 2d 00 2d 6e 75 6c 6c 40  sip:null-.-null@
                 [ note NUL here ^^ ]
0050: 65 78 61 6d 70 6c 65 2e 63 6f 6d                 example.com

[TODO multipart body in 3.1.1.11]

7.  Security Considerations

[TODO]

8.  IANA Considerations

[TODO: add new SIP IEs to, create new SIP Method registry, or add numbering to existing registry.]

9.  Acknowledgments

Cullen Jennings has provided insightful discussions, specific comments and much needed corrections. Nico d'Heureuse helped with the RFC 3665 examples.

10.  References

10.1. Normative References

10.2. Informative References

Authors' Addresses