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

[Apostolos Pantsiopoulos]

Steve Murphy wrote:
> 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
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> -- 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
Hi,

    The specs look very promising. I think everyone
here should be grateful for your efforts. In answer to your
question I personally find both approaches very useful, although
I would prefer to see the "simple" approach implemented first
chronologically since I believe it is simpler to implement and we could
get immediate results.
    One small question. I tried finding the "peeraccount" variable that
was brought up many times in past emails in your CDRs fields descriptions
but I couldn't. This field was supposed to hold the accountcode for the 
terminating side
(and could be set for each channel using CHANNEL()) according to this :

http://www.venturevoip.com/print.php?rssid=2011

Is this field going to be implemented?


-- 
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: regs at kinetix.gr
------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090112/9a6aa470/attachment.htm