[asterisk-users] CDR Design

Tue Nov 25 14:31:10 CST 2008

Yes, I know we are suggesting the same thing... I just thought you are 
suggesting putting this multidimensional
CDR in one row (which of course requires data structure other than a 
simple comma separated row - XML perhaps).
I did not understand you were referring to a conceptual 
multi-dimensional and not an actual multidimensional storage method.

Anthony Francis wrote:
> 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
>>   
>>     
>
>   