[asterisk-users] CDR Desgin

JD jdupuy-list at socket.net
Mon Dec 1 13:20:07 CST 2008


Daniel Hazelbaker wrote:
> On Dec 1, 2008, at 9:07 AM, JD wrote:
>
>   
>> Steve Murphy wrote:
>>     
>>> Freddi--
>>>
>>> Very interesting. Brian Degenhardt had some code we just gave some
>>> thought
>>> to, wherein we determine if the last channel involved in a linkedID  
>>> set
>>> has been closed. If so, then the entire set is finished. We can use  
>>> this
>>> facility to get you a closing attribute, that could be added to the  
>>> last
>>> CDR emmitted for that set; OR, we could just emit another CDR with  
>>> type
>>> CLOSE or FINAL or something, that signals the end of the chain.
>>>
>>> murf
>>>
>>>       
>> Just thinking out loud: how about a feature wherein, after the FINAL  
>> is
>> sent, asterisk can
>>  1. create a temp text file with just those entries, and
>>  2. launch a user-made script.
>>
>> cdr_manager.conf
>>  [general]
>>  legparsecmd=/usr/local/bin/my_parser.pl
>>
>> wherein the linkedID is passed as the first parameter and the text  
>> file
>> name&path as the second
>>
>> Ignore this suggestion if it horribly complicates things.
>>     
>
> Hmm.. While I normally like having this kind of "instant  
> notification", I could see this as a very big problem for larger  
> installations.  Most OS's are not so great at launching new tasks, and  
> on a heavily loaded system that could easily be a number of tasks  
> launched every second, each doing a lot of database queries.  Perhaps  
> a different approach would be to have a field that can be set to show  
> that the record(s) have been parsed into whatever standard CDR format  
> you want.  This may or may not make more sense as a separate table  
> with just a list of linkedid's that have been parsed.
>
> Daniel

I agree with your and Phillips take on that. It would definitely have to 
be optional; perhaps disabled by default.

And the launcher would need to be generic. That way, it could be a 
compiled C program, etc.

Even if this were implemented, I would hope that the optional 'parsecmd' 
or whatever it's called would
merely add to the function, not turn the main CDR logging off. If 
nothing else, I'd want the main CDR text file still made for debugging 
purposes.

As to the idea of piping to a deamon via socket or dbus: how would 
asterisk behave if the daemon froze or worse, it lagged? I'd hate to 
create a dependency.

(This, by the way, is the core problem I always had with some of the 
OBDC stuff for asterisk. It doesn't handle partial failure well.)

John



More information about the asterisk-users mailing list