[asterisk-users] CDR Rewrite -- Questions to the users

[Steve Murphy]

Hello!

Most are probably bored seeing another letter about this,
but I've put in a fair amount work on a spec for rewriting
the CDR system in Asterisk, and I have some questions:

First, please look at what I've written so far:

svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs

and look at the file "CDRfix2.rfc.txt" in the RFCs dir.

The spec SIGNIFICANTLY alters the way CDRs are generated,
how they are structured, and what they express.

If you have ANYTHING to do with CDRs, then it is critical
you become involved in the design process for the new system!
Or suffer with the results!

What's going on?

I wrote up two modes of CDR generation: Leg-Based, and Simple.

A new field, "linkedID", that can be used to link CDRs as part
of the same total call.

Leg-Based is (or can be) very detailed. Every CDR has a type,
like CALL, AXFER, BXFER, PARK, etc. Depending on what actions
occur during a call, a call can be split up into several
"legs". A dialplan func to insert an event that will create
a new "leg" will be available, with its own user-specified
type.

Simple is just that. One CDR is generated per activated channel.
The start time is when it was created. The end time when it died/hungup.
The answer time is... you know! No fine-grained details. No dialplan
fanciness. linkedID can help you group channels involved in a single
'logical call'.

QUESTIONS:

Which of the two would you see being useful to you?

Is there Yet Another CDR system you would like to see instead?
How would/should it work?

Will both fulfil the requirements of CALEA?

It's been proposed that we implement just the Simple 
CDR now, and it be introduced in some 1.6.x (or higher)
release.  In that release, the existing CDR system would be
deprecated, and in some "futurer" release the "old" (now current)
CDR system would be dropped entirely. What do you
think? Are we high on drugs, or what?

murf

-- 
Steve Murphy <murf at digium.com>
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/20090112/3eac2fd1/attachment.bin