[OpenCALEA] DF design

[Jesse Norell]

Hello,

  No nice pictures (yet?) but to get a conversation going I'm sending
this.  I'd like to discuss the DF design and hopefully we'll end up with
somewhat of a gameplan.

  There are 2 options that immediately come to mind to deliver data to
the LEA, which is the DF function.  An opencalea site is going to have
several (potentially many) separate pieces collecting data (both CmII
and CmC), so either 1) those separate pieces can all send data directly
to the LEA or 2) those separate pieces can be collected "locally" and a
single delivery point sends all the data to the LEA.  Kicking around
those options a little, everything I can see points to the second option
as the most desirable; for that matter, it may even be a requirement of
T1.IAS, depending on how you interpret it, but it is certainly how it's
logically layed out.  If anyone wants to discuss/debate those two (or
other) options, now's a good time; otherwise I'm proceeding assuming we
need to create a unified DF collector (called "df_collector" ?) to
locally gather all CmII and CmC, package it up in ASN.1, and ship it to
the LEA (lea_collector).

  Right now "tap" is the only source of CmC.  I imagine there may be
others (potentially even for the May 15 deadline, depending how sip
support plays out).

  There will be a lot more CmII sources.  DHCP and Radius support is
planned for initial deadline, and Norm is working on parsing sip data to
meet his T1.678 requirements.  I have no doubt other people with
different needs will need/add more later.  There are also some
"administrative" CmII events in Appendix C (though they are optional),
eg. service changes and the surveillance activation/continuation/
change/deactivation ones.  Norm's sip work will certainly bring in more.

  I was thinking of having a commandline utility that can be called to
create/send a CmII event message (eg. to integrate into a radius server,
or a program that monitors dhcp log files).  Norm is looking at the
asn.1 and commented to the effect that there are way so many
options/pieces of info to put into CmII (he's looking at the sip piece),
that it would make a single utility difficult/complicated.

  So, lets have some thought/discussion on the interface to a
df_collector.  Something that would make creating new CmII sources
relatively easy to implement.  Norm mentioned that one of the asn
compilers can produce both BER and xml; perhaps we could use the xml as
the interface to df_collector, which itsself can repackage the event as
BER and ship it to lea_collector?  Heck, I don't remember any mention of
BER at all in the spec anyways, so maybe we'd even keep it in xml?
(Less network efficient, but easier to work with.)

Jesse


-- 
Jesse Norell - jesse@kci.net
Kentec Communications, Inc.