BTW, the below would be parsed as a RADIUS Accounting message. So essentially what this could mean is the "log file" entry format is a pcap packet format, one "capture packet" per log entry. You could encode the whole SIP message in such as usual, including real IP/UDP headers, or you could encode what effectively looks like a RADIUS message in such to encode specific TLV's (Radius Attributes) - or you can do *both* in the same log stream. Or if we think 255 attributes of up to 255 octets each is not enough, one could encode it as DIAMATER messages - again you're not running DIAMETER, it's just an encoding format that supports TLV's which happens to look like DIAMETER for tools receiving it, without actually running RADIUS/DIAMETER and thus without the responses and application of those - just streamed log entries. Just a whacky idea, probably. But there sure is a lot of available, running code for this. -hadriel > -----Original Message----- > From: Hadriel Kaplan > Sent: Thursday, March 26, 2009 5:06 PM > To: Hadriel Kaplan; Vijay K. Gurbani; Adam Roach > Cc: sipping WG; draft-gurbani-sipping-clf@xxxxxxxxxxxxxx > Subject: RE: Alternate CLF syntax proposal > > > Actually, ya know we can combine this with something like Adam's draft. > If you take the pcap entry format, and encode a "log" entry with the > following header: > > > | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | > ------------------------------------------------------------------------- > | seconds | > ------------------------------------------------------------------------- > | microseconds | > ------------------------------------------------------------------------- > | saved_len | > ------------------------------------------------------------------------- > | orig_len | > ------------------------------------------------------------------------- > | all 0x00 | > ------------------------------------------------------------------------- > | 0x00 | 0x0800 | 0x4500 | > ------------------------------------------------------------------------- > | log_entry_len | seq_no | 0x000001 | 0x11 | > ------------------------------------------------------------------------- > | all 0x00 | > ------------------------------------------------------------------------- > | 0x00 | 0x0715 | 0x0715 | entry_len | > ------------------------------------------------------------------------- > | 0x00 | 0x04 | 0x00 | tot_len | 0x0000 | > ------------------------------------------------------------------------- > | all 0x00 | BEGIN | > ------------------------------------------------------------------------- > > Then starting with the BEGIN bytes, you can record each Tag-Length-Value > triple using the following: > 1-Byte Type > 1-byte Length (including type and length bytes) > 1-255 bytes of chars > > And once again there would be plenty of tools/running-code which can > already parse that today. :) > > Or we could do a slightly different variant of the "header", if you want > TLV's which can be bigger/longer. > > -hadriel > > > -----Original Message----- > > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On > Behalf > > Of Hadriel Kaplan > > Sent: Thursday, March 26, 2009 3:57 PM > > To: Vijay K. Gurbani; Adam Roach > > Cc: sipping WG; draft-gurbani-sipping-clf@xxxxxxxxxxxxxx > > Subject: Re: Alternate CLF syntax proposal > > > > > > If the purpose of it is troubleshooting, or threat analysis type stuff, > I > > think the following format satisfies the needs as well: > > http://wiki.wireshark.org/Development/LibpcapFileFormat > > > > The advantages: > > 1) There's running code > > 2) There's open source, on all operating systems, and also for > commercial > > use > > 3) It's used by many people > > 4) There are many tools which accept/process it > > 5) It's fast to write/save > > 6) It supports a sub-second timestamp > > 7) It supports length encoding of packets, so you can skip past them > > 8) It supports truncated saving of packets, so you don't have to save > all > > of very big ones > > 9) It records the method name or response code very early in the saved > log > > entry for each packet > > > > Disadvantages: > > 1) Nothing much new to specify, except to document it? > > 2) It's a little tricky for SIP/TLS, where you basically have to create > > fake segments/packets for the low layers, and same may be true for > SIP/TCP > > depending on when you record the log > > 3) It doesn't provide a way to report internal system > events/actions/info > > (although we could fix that) > > 4) Afaik, there is no specific remote push/streaming mechanism for it > > defined (there was an attempt at it, but not final) > > > > -hadriel > > > > > -----Original Message----- > > > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On > > Behalf > > > Of Vijay K. Gurbani > > > Sent: Wednesday, March 25, 2009 10:58 PM > > > > > > Adam Roach wrote: > > > > In the spirit of "send text," I've put together a straw-man proposal > > for > > > > an easy-to-generate and fast-to-process extensible format for saving > > SIP > > > > log messages: > > > > > > > > http://www.ietf.org/internet-drafts/draft-roach-sipping-clf-syntax- > > > 00.txt > > > [...] > > > > > > Adam: Essentially you are advocating for a table-of-content > > > type of approach where you read the ToC and index straight > > > to where you want to go. I have worked on SIP parsers > > > designed this way. > > > > > > The parsing is optimized, yes, when compared to the ASCII > > > version -- though perl can do wonders, but not to outperform > > > binary parsing. The disadvantage is that you loose readability > > > and would need specialized tools to, say, grep through such > > > a file. > > > > > > It will be interesting to see what others think... > > > > > > Thanks, > > > > > > - vijay > > > -- > > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > > > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > > > Web: http://ect.bell-labs.com/who/vkg/ > > > _______________________________________________ > > > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > > > Use sip@xxxxxxxx for new developments of core SIP > > _______________________________________________ > > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > > Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
