OpenCALEA
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Historical
Re: [OpenCALEA] Recent updates
- From: Jesse Norell
- Date: Fri Jul 20 11:17:30 2007
Hello,
That looks correct. I think everyone's busy with other work
issues (I have, at least), and we're all waiting on / working with WISPA
for a new Calea safe-harbor standard, so it's been untouched for a
while.
Jesse
On Fri, 2007-07-20 at 11:06 -0400, Mario Antonio wrote:
> Jesee,
>
> Do you have some info about the status of the OpenCalea project?
> I saw that the latest entry in the SVN was in May 24.
>
>
> Regards,
>
> Mario Antonio
>
>
> ----- Original Message -----
> From: "Jesse Norell" <jesse@kci.net>
> To: "Mario Antonio" <dino@webjogger.net>; <opencalea@merit.edu>
> Sent: Tuesday, May 22, 2007 11:39 AM
> Subject: Re: [OpenCALEA] Recent updates
>
>
> >
> >
> > > I verified that
> > > If lea_collector is not running, df_collector saves the files CmC and
> CmII
> > > in the corresponding subfolders.
> > > If lea_collector is running, CmC files are saved but remain empty.
> >
> > That's actually the intended behavior for what was done there ... it's
> > not actually in the ATIS spec, but Norm wanted to "error on the side of
> > caution" here and save data to disk if the writes to CF (lea_collector)
> > failed. The standard is remiss in how to handle any type of
> > retransmission/errors/failures/etc. Perhaps we don't want an empty file
> > created when all writes succeed, though it's mostly harmless.
> >
> >
> > > Just one question, in the new design, how can I make the df_collector to
> > > connect to a remote host running the lea_collector?
> > >
> > > In the old design, tap was connecting to the lea_collector (no problem)
> > > But now, df_collector connects to localhost, which is the default
> behavior.
> > > The df_collector usage says:
> > > Usage: df_collector [-f config-file] [-u user] [-g group] [-b
> bind-addr]
> > > [-p df-port] [-v [...]] [-D debug-file] [-l log-level ] [-L logfile]
> [-h]
> > >
> > > It seems that there is no option to connect to a remote host, or as you
> said
> > > "the docs don't often line up with what's currently possible."
> >
> > Correct .. to handle multiple intercepts and also multiple
> > destinations of a single intercept (eg. part of T1.678 allows the
> > content of each separate voice channel to be sent to a different port on
> > the CF host, which would have to happen dynamically), we introduced
> > "routes" to df_collector. Ie. this is for picking the destination of
> > where something (CmII or CmC) goes, not the OS network routing table.
> > You create a route in df_collector, say to a given host/port/protocol,
> > then when you send a packet of CmII or CmC it has a routeid which is
> > used to look up the destination. We'll be using the same functionality
> > to "route" to (ie. save to) a file soon. In the short term it's just
> > pieced together - tap sends an add route message to df_collector, I
> > think it's hard-coded as to the destination. Long term (eg. once the
> > control daemon is in place, which is coming along) the route will
> > normally be created when an intercept is defined/started, and tap will
> > be told what routeid to stick in it's packets.
> >
> > --
> > Jesse Norell - jesse@kci.net
> > Kentec Communications, Inc.
> >
> >
> >
> >
> >
>
>
>
>
--
Jesse Norell
Kentec Communications, Inc.
jesse@kci.net
|