Re: [Sipping] Alternate CLF syntax proposal

Hadriel Kaplan <HKaplan@acmepacket.com> Mon, 30 March 2009 22:35 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3813F3A69A1 for <sipping@core3.amsl.com>; Mon, 30 Mar 2009 15:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level:
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUot643U10cW for <sipping@core3.amsl.com>; Mon, 30 Mar 2009 15:35:10 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 469863A68D1 for <sipping@ietf.org>; Mon, 30 Mar 2009 15:35:10 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 30 Mar 2009 18:36:07 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 30 Mar 2009 18:36:07 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Cullen Jennings <fluffy@cisco.com>, sipping <sipping@ietf.org>
Date: Mon, 30 Mar 2009 18:36:01 -0400
Thread-Topic: [Sipping] Alternate CLF syntax proposal
Thread-Index: Acmxaqf7uIhTgN1OSrG7yipvxjfZJwAGsWzw
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC315022D0A95@mail>
References: <49CAE21C.5060309@nostrum.com> <c164605b0903260836p45a8bd8eg9ad50f670ef82302@mail.gmail.com> <167dfb9b0903290326t519e6df8naacdb396a259f8f2@mail.gmail.com> <49CFCD7B.5020304@iptel.org> <011225FB-A116-4659-938E-46B22EB05868@cisco.com>
In-Reply-To: <011225FB-A116-4659-938E-46B22EB05868@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Jason Fischl <jason.fischl@gmail.com>, Adam Roach <adam@nostrum.com>, "draft-gurbani-sipping-clf@tools.ietf.org" <draft-gurbani-sipping-clf@tools.ietf.org>
Subject: Re: [Sipping] Alternate CLF syntax proposal
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Mar 2009 22:35:11 -0000

Pcap is just a file format. (well, technically it's an API library, but we're just talking about the pcap file format)  

The format of the file and its entries is ridiculously simple binary.  It has a 24 byte file header, and a 16-byte header per record entry.  Each record entry header has a timestamp, which is something I think we'd need for a CLF, and it has a length, which is something people said in the ad-hoc they'd like.

How we use such a format is actually up to us.  The fact that it follows a pcap file format can be purely coincidental.  If we want currently available tools which support pcap files to be able to read this formatted file, right now without any changes, then we'd have to be careful in what we put in each record after the per-record header.

-hadriel

> -----Original Message-----
> From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf
> Of Cullen Jennings
> Sent: Monday, March 30, 2009 3:06 PM
> To: sipping
> 
> I might not understand everything that is possible with pcap but it
> seems to me that the problem with PCAP is that it generally saves the
> whole SIP message if you want to get all the headers - Say for example
> an operator wants to log who sent INVITES to what what numbers and
> when the correlated BYE happened so  that they can debug stuff later.
> But they do not want to capture the IP addresses of the UAs because if
> they save them then they have to respond to court orders to provide
> the logs with IP in them which is just a huge pain for with the
> operator and does not provide any revenue. The other issue is that
> logging the complete messages is often just too much data.
> 
> I like the proposal - mostly I just want something that works in high
> performance systems.
> 
> Cullen in my individual contributor role.
>