[asterisk-users] CDR Desgin

[JD]

Steve Murphy wrote:
> On Wed, 2008-11-26 at 01:13 +0100, Freddi Hansen wrote:
>   
>>> To me the obvious answer is to provide a CDR for every call leg so for
>>>       
>>>> A calling B via Asterisk there would be two CDRs produced. It's far
>>>> far easier to disregard the unwanted CDRs than it is to try and
>>>> generate the missing ones and in some cases it's virtually impossible.
>>>> If it's weighed up I think people would vote to have accurate CDRs
>>>> ahead of anything else and if single legs are the best way to do that
>>>> then it's the way it should be done.
>>>>
>>>> In addition with single leg CDRs it will solve the dilemna about
>>>> acommodating every possible call scenario that I know has caused you a
>>>> lot of consternation over the last 18 months.
>>>>
>>>> Sure it's a change from the current situation so maybe needs to use
>>>> the standard apporach of a configuration setting to opt in initially
>>>> before becoming the default in the subsequent major release.
>>>>         
>>>   
>>>
>>>
>>> OK, Greyman, your logic is solid. If we provide a CDR implementation
>>> that just generates the individual call legs, and ties them together via
>>> the linkedid
>>> (see team/group/newcdr), then both camps should be able to derive the
>>> info
>>> they need for billing, via hopefully not-overly-complex SQL queries to a
>>> backend db.
>>>
>>> I'll modify my RFC to reflect this line of thinking. Yes, it is a bit of
>>> shift.
>>> And, yes, the implementation will make this new approach optional, and
>>> not
>>> default. But, pardon if I make it available via the CEL domain come
>>> implementation time.
>>>
>>>
>>> It should take me a week to rehash my document; perhaps longer (I'm in
>>> bugfix mode, and this borderline development work); in the meantime,
>>> those with decided CDR needs might make their wishes known, if they do
>>> not think this approach will work. Speak now, or forever hold your
>>> peace; or forever complain... or whatever.
>>> If this is particularly distressing to you, perhaps your fears might be
>>> slightly assuaged when you read the details...
>>>   
>>>       
>> I was part of a team that did design a multiservice billing system about 
>> 15 years ago and the solution people seems to agree on here (and me to) 
>> looks pretty much the same i.e one call may consist of several calls 
>> legs. In addition to the linkedid it would be nice to have an indication 
>> in the cdr that tells us that 'this is the lastone on this  linked id'.
>> Our experience was that  we shouldn't  for load reasons work with cdr's 
>> in the immidiate multileg format in the DB. So we did collect cdr's in a 
>> tmp DB until we got the the record with end marker set. We would then 
>> produce our final cdr for the actual service, store it in billing col. 
>> and delete it from the multileg col. When a new service is created we 
>> only have to make a the new customized cdr, we don't have to touch the 
>> generation of the multileg format.  
>>
>> Freddi
>>     
>
> 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.

John