[asterisk-users] CDR Design

[Steve Murphy]

On Fri, 2008-12-05 at 14:47 +0200, Atis Lezdins wrote:
> On Fri, Dec 5, 2008 at 2:35 PM, Andrew Thomas <andy at datavox.co.uk> wrote:
> > "I'd disagree. In some cases a event based system would be the best
> > solution, but in systems with high call volumes, scanning through events
> >
> > looking for the proper billing information and parsing them would be a
> > hard job compared to CDRs."
> >
> > That's just it - you wouldn't be 'scanning' any CDR's - you'd be given
> > Events.  Your 3rd party app could then do anything it wanted to with
> > them.
> >
> > Events are real time - not historic (like CDR's).  Events are presented
> > as they happen (hold, ring, etc) - CDR's are usually presented AFTER the
> > call has finished so you miss things like hold-times etc.
> >
> > Remember, I am not saying that everyone should stop using the CDR's if
> > they feel comfortable with them - but I, for one, don't trust them for
> > building a stable billing platform or a real time stats package (which
> > more and more customers seem to want these days).
> 
> Pardon me,
> 
> I have created realtime stats package that's based on CDR, you see new
> info immediately after call leg/event is over
> 
> http://ftp.iq-labs.net/screenshots/cdr_view.jpg
> 
> > If you start to change the CDR's to account for extra bits (using a
> > unique ID) then your 'scanning' actually increases as you will need to
> > tie up all the unique ID's to get one full call progress path.
> 
> This is exactly how real-time billing works. If you somebody wants it,
> they put in custom ResetCDR(w) in their dialplan and have all kinds of
> events logged. Having Asterisk write all the timestamps/durations into
> database is just much simpler.
> 
> > Please note, I am not trying to cause flame wars here - just stating
> > that I'd love an event based stream, that I can parse any way I see fit.
> > I know there's the AMI - but that is a 2-way, give-you-everything
> > solution.  All I want is to know when a handset and/or trunk does
> > something (I don't care about SIP registrations etc).
> >
> > I guess we'll just have to wait and see what santa murf gives us all for
> > Christmas :).
> >
> 
> I really want to contribute this discussion (and RFC), i'm reading it
> and i have lot of to say, but it's hard to find time for reading RFC
> (i'm in middle yet). So, i hope this will go on and allow me to
> respond with some objective comments.

Atis--

I welcome your input. I don't want to write junk.
And to make this useful to as many users as possible,
I need to know what they need/want.

I can't possibly make everyone happy, but I might get
away with giving them something that makes getting to 
their desination possible.

There's many ways to get a job done. I'm looking for 
the simplest and the most complete/general.

murf

> 
> Regards,
> Atis
> 
> 
-- 
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/c1764c3f/attachment-0001.bin