[asterisk-users] CDR Design

[Anthony Francis]

It is my belief that before redesigning the CDR engine some time should 
be spent looking at current PSTN CDR formats and what information is 
kept in them.
The main problem that I feel we face is that calls can be complicated, 
but we want the record of it to not be.
In reality a CDR that incorporates all information about a call would 
have at least two dimensions.
In the first you would have the base call record as we do now, in the 
second we would have the event list.
The event list would be a time indexed list of event names and 
attributes, just as you would currently store event information.
The event list would be your glue (with a bit of front end logic of 
course.) that would relate a call that dialed X external numbers to the 
X different new CDR's that generated.
That would allow you all the call path info you could ever want. The 
most important thing would be a new config file that allows an 
administrator granular control over what information is "important to 
them. And of course a "keep it simple stupid" mode that just writes the 
top level cdr as it does now.

regs at kinetix.gr wrote:
> I think that the custom cdr back-end can be successfully used to 
> maximize or minimize the CDRs detailing
> on a per-needs basis. Furthermore, the CDR() function gives plenty of 
> room for even more detailing.
> In my opinion the detail level (fields) is not the issue with the CDRs 
> generation nor is the lack of backends (asterisk gives a lot of different
> backends to store your CDRs). I find the issue with asterisk CDRs to be 
> in the lack of proper CDRs generation for the B-leg of every call.
> If we want to really track what happens during a call through the CDRs 
> one has to have all the details not only for the incoming channel
> but for the outgoing one as well. Furthermore, one needs to be able to 
> tweak the B-leg CDRs like he does with the incoming legs. So what
> needs to be done in my opinion is record every B-leg CDR when such an 
> event occurs and give the user access to the CDR info by
> extending the CDR() function (so that one can specify the channel of the 
> CDR that is being tweaked) or creating a seperate one for
> the outgoing channels.
>
> Grey Man wrote:
>   
>> I've taken the liberty of starting a new thread to discuss the design
>> of the Asterisk CDR mechanism. The discussion has been kindly
>> initiated by murf putting together a proposal (link ommitted to see if
>> email gets accepted).
>>
>> After reading the proposal I still don't think it's the right way to
>> go. To my mind adding more channel variables increases the complexity
>> in a situation that is already overly so. I think it's a mistake to
>> try and think about all the different call scenarios and come up with
>> little tricks for the more complicated ones. There will always be
>> something missed; app_shotgun initiates calls to 100 random numbers
>> and as soon as three or more calls are answered it will start randonly
>> transferring them amongst each other at 2 second intervals.
>>
>> I think it's important to clarify at the outset what a CDR should be.
>> The most fundamental requirement for CDRs is that they accurately
>> record the following pieces of information for EVERY call entering or
>> leaving the system (note every means every and not; "channel" calls
>> but not "peer" calls).
>>
>> 1. Destination (aka as A Number)
>> 2. AccountCode (aka as B Number)
>> 3. Call Start Time (answer time),
>> 4. Duration.
>>
>> Of course adding extra information can be very useful and I'm not
>> proposing any fields be removed from the current implementation
>> (although for pity's sake one change that should be made it to use a
>> GUID/UUID for the CDR's uniqueid and save endless confusion).
>>
>> People that really do need verbose or enhanced CDRs to do things like
>> tracking a call's flow as it travels in and out of queues, parking
>> lots etc. would be better off using AMI or the new CEL and not CDRs.
>> At the very least if problems arise with their call flow tracking they
>> will still be able to rely on the accuracy of the CDRs to piece it
>> altogether to work out what's going wrong.
>>
>> My proposal of creating a 1-to-1 relationship between CDRs and
>> Asterisk channels already exsits but somewhere along the line it's
>> going awry. As an experiment, and to actually do something instead of
>> continually moaning about it, I started commenting out the blocks of
>> code in res_featrures.c and sip_channel.c that muck around with the
>> channel CDRs when a transfer occurs. The results of that were that the
>> CDRs for blind and attended transfers actually got better! They're
>> still not quite right but are pretty close with only one CDR on each
>> having a wrong destination.
>>
>> Regards,
>>
>> Greyman.
>>
>> _______________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-users
>>   
>>     
>
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>