[asterisk-users] CDR Design

[Steve Murphy]

On Fri, 2008-12-05 at 10:52 +0000, Andrew Thomas wrote:
> Thanks for this Greyman - it's all beginning to make sense now ;).
> 
> I agree that the 'loss of CDR upon txfr' is a nasty bug which does need
> to be addressed before anything else (assuming it hasn't been already).
> 
> But, wouldn't it be better if you could ignore the CDR's completely and
> use an event based system?  This would give you ALL the information you
> need.  All that remains is to filter out the un-required bits.
> 
> Like I said earlier - the CDR's aren't reliable enough for a billing
> platform (as you've rightly pointed out) but are OK for very basic call
> logging (something the customer can look at).
> 
> Hopefully, the murf'ster will chirp in here :).
> 

I'll Chirp here. I'm kinda impressed with the number of CDR Design
messages in the Q since last I checked, but I'll try to plow my 
way thru them. I've been ruminating over Greyman's suggestion about
simplified CDR's for the past few days, stepped outside my 'box', and
I think realized what he actually was asking for, at last.

As to the event system, say no more. CEL is it. It will spew out 
all possible CDR related events in any of several formats, in somewhat
real-time (as they occur) order. The state of the channels are included
with the time of each event.

But, this alone isn't really useful in a database. Try coming up with
SQL queries that tell you useful things about what's happened, 
or happening... CDR format is useful that way; and, like Brian,
yes, you can mix the two to your heart's content, even add manager
events to the mix.

murf

> Cheers
> Andy
> 
> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com
> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Grey Man
> Sent: 05 December 2008 09:37
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [asterisk-users] CDR Design
> 
> On Fri, Dec 5, 2008 at 8:26 AM, Andrew Thomas <andy at datavox.co.uk>
> wrote:
> >
> > In summary: Leave CDR exactly as it is and create a new CEL (Call
> Event
> > Logging) module (optional in modules.conf) that puts out (and does not
> > accept) call event information (ie. a one-way fire-and-forget output
> > from Asterisk).
> >
> 
> Hi Andrew and Others,
> 
> This thread is actually part of a discussion that has been going on
> for over a year. The links below provide the background to the whole
> thing.
> 
> http://www.asterisk.org/node/48358
> http://bugs.digium.com/view.php?id=11849
> http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.htm
> l
> 
> Up until recently the approach was to try and fix the specific bugs
> with transfer CDRs as a typical bug. There is now a realisation that
> that is a lot trickier than inially thought so it's been decided to
> try and come up with a good design for the Asterisk CDR sub-system.
> 
> 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
-- 
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/20081205/05b56839/attachment.bin