[asterisk-users] CDR Desgin

[Steve Murphy]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20081124/96d9d54d/attachment.bin