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 > -- Thank you and have any kind of day you want, Anthony Francis Rockynet VOIP (303) 444-7052 opt 2 [EMAIL PROTECTED] _______________________________________________ -- 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
