Re: [OpenCALEA] control design

[Jesse Norell]

My last post somewhat answers this, considering a different design.

For the short term, the current controller/collector can be a stop gap,
and if we come up with a df_collector interface we can manually start
CmII collection agents on say a dhcp server (or integrate that into the
controller, too).  The "control" discussion I think is more of a long
term gameplan on design.

For the shorter term, probably implementing a df_collector and getting
all the data to lea_collector in ASN.1 are probably more important.  I'm
considering a few different scenarios for dhcp and radius, and Norm is
working on sip and ASN simultaneously ... but to answer some of my
questions, I keep coming back to that central df_collector, and the
interface to it.


On Thu, 2007-04-05 at 15:56 -0400, Manish Karir wrote:
> This idea was tossed around at Merit as well.  Essentially building
> a "stats/monitor/health" interface into tap.  This way we can check on
> it periodically and also get some useful stats out if it to make
> sure its working correctly.  Is this in line with what you have in mind?
> 
> -manish
> e
> 
> On Thu, 5 Apr 2007, Jesse Norell wrote:
> 
> >
> > Hello,
> >
> >  More thoughts, on a different piece...
> >
> >  To perform a surveillance, the specific data sources involved (ie. the
> > specific IAP's collecting CmII and CmC) need to be identified, started,
> > and monitored.  If for some reason something was interrupted, say a tap
> > machine was rebooted, that needs to be caught and the surveillance
> > restarted (and there are also some optional CmII events to be reported
> > for that).
> >
> >  In the short term this could quite viably be a manual process, which
> > is the current track things are heading.  Eventually it would be nice to
> > be able to define an "interception" in some manner, which would define
> > exactly what IAP's are involved, what they're looking for, where to send
> > the data, the case id, subscriber identity, etc. and have everything
> > automated.
> >
> >  One possibility is to have a controlling application that both allows
> > creation of an "interception" object with the above info, which also
> > knows how to invoke/monitor/restart the IAP's, and generates
> > corresponding CmII events.  If the controlling app gets restarted, the
> > surveillance object needs to be persistent and it can pick back up
> > monitoring/etc.  The controlling app can also log some of the data that
> > would be relevant to the "secure and accurate record of each
> > interception" that we're required to keep (eg. date/time that
> > interceptions are enabled/disabled, etc.).  Possibly the app could store
> > the entirety of the record info to easily print (I believe the actual
> > record needs to be on paper, as it has to be signed).
> >
> >  Another option would be to define an "interception" in a database of
> > sorts (rdbms or otherwise), and have every IAP source independently
> > check that database periodically (frequently), and take appropriate
> > action (eg. start/restart/stop an intercept, and send CmII events).
> > There would still need to be an interface (possibly gui?) to define an
> > intercept, and if each data source logged info it could also be used as
> > part of the "secure and accurate record" we keep.
> >
> >  Ideas for other options are certainly welcome.  Any anyone that wants
> > to think about the pros/cons of the options and render an
> > opinion/suggestion, please speak up.  I don't think I have a preference
> > right now .. the record keeping on the first setup might be a little
> > easier, the ongoing monitoring on the second may be easier (even more
> > robust?).
> >
> > Jesse
> >
> >
> > -- 
> > Jesse Norell - jesse@kci.net
> > Kentec Communications, Inc.
> >
> >
-- 
Jesse Norell - jesse@kci.net
Kentec Communications, Inc.