Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

OpenCALEA

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: [OpenCALEA] control design

  • From: Manish Karir
  • Date: Thu Apr 05 15:56:09 2007


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.










Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.