On Sat, 2008-11-22 at 04:02 +0000, 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: > http://svn.digium.com/svn/asterisk/team/murf/RFCs. > > 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 detstination. > > Regards, > > Greyman.
Greyman-- For the moment, let's not worry about the implementation. Let's get consensus on the spec first. In the scenario, where A calls B, B xfers A to C, C xfers A to D, or some such similar scenario, half the world wants a single CDR for A, from the time it started, to the time it hung up with D. The other half wants A->B's dial and bridge, a cdr for A & C's bridge, a CDR for A & D's bridge, and mayhaps some CDRs to describe the xfers, where B xfers A to C and C xfers A to D. My document is pointing in the former direction, and either we need to spec both, or pick one. murf -- Steve Murphy Software Developer Digium
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ -- 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