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

Peter Musgrave <peter.musgrave@magorcorp.com> Wed, 27 April 2011 18:11 UTC

Return-Path: <peter.musgrave@magorcorp.com>
X-Original-To: sip-clf@ietfa.amsl.com
Delivered-To: sip-clf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6ADDE0710 for <sip-clf@ietfa.amsl.com>; Wed, 27 Apr 2011 11:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.798
X-Spam-Level:
X-Spam-Status: No, score=-101.798 tagged_above=-999 required=5 tests=[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_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlTpTj483OEZ for <sip-clf@ietfa.amsl.com>; Wed, 27 Apr 2011 11:11:06 -0700 (PDT)
Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0E150E0681 for <sip-clf@ietf.org>; Wed, 27 Apr 2011 11:11:05 -0700 (PDT)
Received: by gxk28 with SMTP id 28so1106825gxk.27 for <sip-clf@ietf.org>; Wed, 27 Apr 2011 11:11:05 -0700 (PDT)
Received: by 10.236.175.165 with SMTP id z25mr3008182yhl.450.1303927865295; Wed, 27 Apr 2011 11:11:05 -0700 (PDT)
Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id x68sm496298yhn.57.2011.04.27.11.11.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2011 11:11:04 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-25--796851502
From: Peter Musgrave <peter.musgrave@magorcorp.com>
In-Reply-To: <091E2FD2-02D6-4A85-AB1C-0BC5EB86FC62@cisco.com>
Date: Wed, 27 Apr 2011 14:11:02 -0400
Message-Id: <5FC78793-9C05-4365-BCA6-78B5A4DCCC55@magorcorp.com>
References: <091E2FD2-02D6-4A85-AB1C-0BC5EB86FC62@cisco.com>
To: Gonzalo Salgueiro <gsalguei@cisco.com>
X-Mailer: Apple Mail (2.1084)
Cc: "sip-clf@ietf.org Mailing" <sip-clf@ietf.org>
Subject: Re: [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, 27 Apr 2011 18:11:07 -0000

Hi, 

<as individual>
This is ok by me. Simple and flexible - which is what a logging format should be. 

<as chair>
More input needed 
PLEASE - let's get these final issues laid to rest and get these doc done!

Thanks,

Peter Musgrave

> 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:
> 
> tag@PEN,Length,Value
> 
> where:
> 
> 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. 
>     
> Example:
> 
> Consider the SIP response:
> 
> SIP/2.0 180 Ringing
> Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
>  ;received=192.0.2.1
> To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
> From: Alice <sip:alice@atlanta.com>;tag=1928301774
> Call-ID: a84b4c76e66710
> Contact: <sip:bob@192.0.2.4>
> 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@192.0.2.4>
> 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
> 
> Example:
> 
> 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
> 
> v=0
> 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.
> 
> Regards,
> 
> Gonzalo
> 
> 
>  
> 
>         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)            | /
>         +-----------+-----------+-----------+-----------+/
> _______________________________________________
> sip-clf mailing list
> sip-clf@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-clf