[sip-clf] Logging Optional Fields in the SIP CLF

Gonzalo Salgueiro <gsalguei@cisco.com> Wed, 20 April 2011 19:24 UTC

Return-Path: <gsalguei@cisco.com>
X-Original-To: sip-clf@ietfc.amsl.com
Delivered-To: sip-clf@ietfc.amsl.com
Received: from localhost (localhost []) by ietfc.amsl.com (Postfix) with ESMTP id 6C8C3E074D for <sip-clf@ietfc.amsl.com>; Wed, 20 Apr 2011 12:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.698
X-Spam-Status: No, score=-9.698 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfc.amsl.com []) (amavisd-new, port 10024) with ESMTP id oyW3ToIUqzal for <sip-clf@ietfc.amsl.com>; Wed, 20 Apr 2011 12:24:55 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com []) by ietfc.amsl.com (Postfix) with ESMTP id D186FE074B for <sip-clf@ietf.org>; Wed, 20 Apr 2011 12:24:55 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com []) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3KJOs4C002761; Wed, 20 Apr 2011 15:24:54 -0400 (EDT)
Received: from rtp-gsalguei-87112.cisco.com (rtp-gsalguei-87112.cisco.com []) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3KJOrWN022345; Wed, 20 Apr 2011 15:24:54 -0400 (EDT)
From: Gonzalo Salgueiro <gsalguei@cisco.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-21-750263058
Date: Wed, 20 Apr 2011 15:24:53 -0400
Message-Id: <091E2FD2-02D6-4A85-AB1C-0BC5EB86FC62@cisco.com>
To: "sip-clf@ietf.org Mailing" <sip-clf@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [sip-clf] Logging Optional Fields in the SIP CLF
X-BeenThere: sip-clf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Common Log File format discussion list <sip-clf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-clf>
List-Post: <mailto:sip-clf@ietf.org>
List-Help: <mailto:sip-clf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 19:24:57 -0000

Folks - 

According to the discussions in Prague we decided that a single format be used to log optional fields. The current format draft presents two separate formats; one for logging Pre-defined optional fields and another to log vendor-specific elements. The discussions in Prague have indicated that a universally agreed upon list of Pre-Defined optional fields is too restrictive. Rather, the ability to log ANY SIP header (or header element) as well as body (or body element) should be optionally allowed by this format.

I'd like to propose the following format to log optional elements:

byte 1 0x09 (Tab)
byte 2-5 Tag (Hex)
byte 6 0x40 ('@')
byte 7-10 Vendor-ID (PEN)
byte 11 0x2C (comma)
byte 12-15 Length (Hex)
byte 16 0x2C (comma)
byte 17-... Value (variable length)

Note: This format is represented graphically in the diagram at the end of this message (view with fixed-width font).

This is a TLV format for logging optional fields that can be represented as:



I.  PEN=0x0000 is used to log the entire SIP message, message body, or any non-mandatory SIP header fields plus the Reason-Phrase

tag=0x0000 Log SIP Header Field or Reason-Phrase
tag=0x0001 Log message body
tag=0x0002 Log entire SIP message
- For the case of 0000@0000 the associated "Value" field MUST be populated by the entire header field being logged. That is, the field-name, the associated colon (":") and the field-value. This mechanism provides the capability to optionally log ANY SIP header field by identifying the field being logged in the "Value" field.
- Because the Reason-Phrase in a response is part of the Status-Line and is not identified with a field-name, it is a special case. In this instance, the the associated "Value" field MUST be populated by the name "Reason-Phrase" followed by a colon (":") and a single space (SP) between the colon and the logged reason phrase value.
- The corresponding "Length" field includes the length of the entire "Value" field. This includes the field-name, the colon, and any LWS separator.
- The cases of logging the message body (0001@0000) or the entire SIP message (0002@0000) are subject to the same field length limitation of 4k as detailed in the Problem Statement. 

Consider the SIP response:

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@>
CSeq: 314159 INVITE
Content-Length: 0

The Contact header field and the reason phrase would be logged respectively as optional fields in the following manner:

0@0,1C,Contact: <sip:bob@>
0@0,16,Reason-Phrase: Ringing

II. PEN=Vendor-ID is used to log everything else (i.e. any vendor specified element of a SIP header or body)

tag=vendor-specified tags


Consider the SIP message:

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <bob@biloxi.com>
From: Alice <alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 147

o=UserA 2890844526 2890844526 IN IP4 here.com
s=Session SDP
c=IN IP4 pc33.atlanta.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

A vendor may choose to log the codec information from the SDP body. This would be formatted as follows:

3@32473,14,a=rtpmap:0 PCMU/8000

or perhaps a vendor wants to log that this message is the n^th message received from a peering partner.  To do so, it would log this information as:

7@32473,16,1877 example.com

which would signify that this is the 1,877^th message from the peering partner example.com

Please provide any feedback on this proposal as it is one the very few remaining open issues ti finalize the format draft.




        0          7 8        15 16       23 24         31
        |    0x09   |             Tag (Hex)             |\
        +-----------+-----------+-----------+-----------+ \
        | Tag (cont)|    0x40   |       Vendor-ID       |  \   
        +-----------+-----------+-----------+-----------+   \  Repeated
        |    Vendor-ID (cont)   |    0x2C   |   Length  |    \ as many
        +-----------+-----------+-----------+-----------+    / times as
        |        Length (Hex) (cont)        |   0x2C    |   /  necessary
        +-----------+-----------+-----------+-----------+  /
        |            Value (variable length)            | /