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. > > [EMAIL PROTECTED] 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. >>> >>> [EMAIL PROTECTED] 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 >> >> > > _______________________________________________ -- 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
