The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model
Extracted elements (32)
Establishing SIP CLF is more challenging than HTTP CLF because SIP supports parallel/serial forking (multiple final responses), dialog grouping of transactions with varying inter-arrival rates, ACK as a special non-response-eliciting method tied to INVITE, CANCEL, and provisional responses that must be logged for anomaly detection training.
IPFIX aggregates IP flows for network-layer analysis and does not produce human-readable log files amenable to ad hoc text processing tools, so it is unsuitable as a SIP CLF replacement.
Packet capture tools (e.g., Wireshark, tcpdump) are unsuitable as SIP CLF because they cannot decrypt TLS-protected SIP traffic, require third-party libraries on every platform, and produce output not amenable to simple command-line text processing.
SIP CLF is explicitly not a billing tool, QoS measurement tool, or lawful-intercept tool; it operates at the signaling layer only and cannot verify media-layer events, making it unsuitable for customer billing or MOS scoring.
SIP CLF operates at the transaction layer and logs SIP-specific fields (To/From tags, CSeq, Call-ID) that allow dialog state to be reconstructed; by contrast, CDRs are designed for charging and use identifiers that do not necessarily correspond to SIP headers, making dialog reconstruction from CDRs impractical.
Syslog is unsuitable as a primary SIP CLF mechanism because it mixes records from many originators requiring extra filtering, a collector may be unreachable (e.g., mobile clients), and sending every SIP log message to a remote collector imposes unacceptable overhead.
The document deliberately does not prescribe a specific representation format for SIP CLF records; it defines only an information model so that other documents (e.g., RFC 6873 for UTF-8 encoding) can define concrete formats, allowing multiple representations to coexist.
A common set of mandatory fields is essential for interoperability: without it, one implementation cannot reliably read a log file written by a different implementation, undermining the goal of cross-vendor tool compatibility.
The SIP CLF information model applies uniformly to UAC, UAS, proxy, B2BUA, registrar, and redirect server; fields prescribed for a proxy are equally applicable to a B2BUA, and fields for a UAS are equally applicable to registrars and redirect servers.
Before transferring the log file across administrative domains, operators SHOULD ensure that fields containing sensitive information (IP addresses, URIs) are appropriately anonymized or obfuscated.
Operators SHOULD require mutual authentication, channel confidentiality, and channel integrity when transferring SIP CLF log files between hosts; SSH transport layer or TLS are cited as suitable mechanisms.
Operators SHOULD use appropriate file and directory permissions on SIP CLF log files, consider disk encryption, and restrict physical and logical access to the host storing the log file.
The mandatory SIP CLF fields defined in Section 8.1 MUST appear in any SIP CLF record, regardless of the representation format used to generate the record.
The maximum size for any SIP CLF field is 4096 bytes. If the body of the SIP message is to be logged, it MUST also conform to this limit.
The representation document MUST define a means to indicate that a mandatory field cannot be parsed, to handle parsing errors.
The representation document MUST define how to indicate a mandatory field that is not applicable in the context of a given SIP CLF record (e.g., R-URI for a response, Status for a request).
The specific syntax and semantics for optional fields MUST be defined by the specific representation format used to generate the SIP CLF record.
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, because SIP bodies may contain characters that do not form a valid UTF-8 sequence.
SIP CLF fields such as IP addresses and URIs contain potentially sensitive information. Before transferring log files across administrative domains, operators should anonymize or obfuscate sensitive fields; a specification for interoperable privacy-friendly SIP CLF exchange is identified as further study.
Four network address fields are mandatory: Source-address (IPv4 or IPv6), Source-port, Destination-address (IPv4 or IPv6), and Destination-port, identifying the sender and recipient of the logged SIP message.
Optional fields extend the information model to include non-mandatory SIP headers, field components (e.g., Reason-Phrase), or vendor-specific data; their syntax and semantics must be defined by the representation format document.
The Call-ID, CSeq-Method, and CSeq-Number fields are mandatory, enabling correlation of transactions and dialogs across log records.
The Client-Txn field holds a client transaction identifier (e.g., the branch parameter inserted into the topmost Via header) used to associate client transactions with the server transaction for forking proxies or B2BUAs.
The From URI (without URI parameters for brevity) and From-tag, and the To URI (without URI parameters) and To-tag are mandatory fields; the To-tag will be absent in the initial dialog-forming request.
The Message-Type field indicates whether the SIP message is a request ('R') or a response ('r'), and the Directionality field indicates whether the message was sent ('s') or received ('r') by the logging SIP entity.
The R-URI (Request-URI including URI parameters) is mandatory for requests; the Status field (SIP response status code) is mandatory for responses. Each is marked not applicable (e.g., '-') when irrelevant.
The Server-Txn field holds a locally unique server transaction identifier (e.g., derived from the topmost branch-id of the incoming request) and is used to correlate ACKs and CANCELs to an INVITE transaction and to support forking correlation.
The Timestamp mandatory field records the date and time of the SIP request or response as the number of seconds and milliseconds since the Unix epoch.
The Transport field records the transport over which a SIP message is sent or received; allowable values are governed by the 'transport' production rule in RFC 3261 Section 25.1.
Implementers must pay particular attention to buffer handling when reading or writing SIP CLF log files, because entries can be unbounded in length (potentially thousands of octets for a full SIP message dump), posing buffer-overflow risks especially in log parsers that must handle extension fields.
Public access to a SIP CLF log file constitutes a greater privacy leak than eavesdropping on cleartext SIP traffic, because an adversary who cannot decrypt real-time TLS-encrypted SIP can still mount replay and eavesdropping attacks if they obtain the log file, which contains decrypted header values.
Threats to log files at rest include unauthorized viewing or copying, deletion of records, and replay attacks enabled by captured SIP header information. Threats during transfer include viewing, modification, insertion of fabricated records, and man-in-the-middle delivery of falsified logs.