Re: [OpenCALEA] Recent updates

[Norman Brandinger]

Hi,

Agree with Jesse in regard to being crazy busy and haven't had time to
work on the project.  That said, I've just recently updated my
development environment locally (Mac OSX) and compiled opencalea
successfully. Needed to install glib but that wasn't too much trouble.

There is a fair amount of infrastructure coding that needs to be done
that isn't dependent upon the "standards".  With a little luck you'll
see some commits in the near term.

Regards,
Norm


Jesse Norell wrote:
> 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.
>>>
>>>
>>>
>>>
>>>
>>>       
>>
>>
>>