On Fri, 2008-12-05 at 14:47 +0200, Atis Lezdins wrote: > On Fri, Dec 5, 2008 at 2:35 PM, Andrew Thomas <[EMAIL PROTECTED]> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ -- 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
