[asterisk-users] CDR Design

Tue Nov 25 11:29:46 CST 2008

We are suggesting the same thing, what you describe is multidimensional. 
If you think of the cdr's as being in a database, and say you wanted to 
have it show you all the calls today and all the calls that are 
associated with that call. Your select grabs the first dimension, a list 
of all calls. Then using the unique identifier of each call you build a 
second dimension of the related calls.

regs at kinetix.gr wrote:
> In order to avoid a multidimensional schema we could have 1 cdr per call 
> leg. So , for instance, one
> call that had 3 different dial() commands as outgoing attempts would be 
> described by 4
> CDRs (1 for the incoming leg that has all the originating channel data 
> and 3 for the outgoing
> legs that hold all the terminating channel's data). Those CDRs would be 
> bound by a unique
> identifier field (the same for all 4). The terminating CDRs could be 
> also identified by a increment field that indicates
> the order that the channels were called. Another issue is that failed 
> attempts should also be logged because
> this is valuable info for many (or at least have the option to choose 
> the desired behavior - which is available in asterisk as we speak).
>
> Anthony Francis wrote:
>   
>> 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
>>>   
>>>     
>>>       
>> _______________________________________________
>> -- 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
>   

-- 
Thank you and have any kind of day you want,

Anthony Francis
Rockynet VOIP
(303) 444-7052 opt 2
voip at rockynet.com