Quote : "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."
A 3rd party "live" application introduces one more point of failure in the whole process. A 3rd party CDRs aggregator can run at its own pace (and multiple times if any issue arises). A 3rd party "live" application could get choked on heavy loads and introduce inconsistency. I think what Vlasis suggests is that there are times that you need an event-based system (PBX, predictive dialing etc). And there are times that you need bulk non-realtime processing of the CDRs (sometimes the billing can be done days or weeks after the actual call). In the first situation you need a real time system, but in the second situation you don't. Being a programmer that dealt with both situations I can say that we need both approaches in asterisk :). In fact the LEGO paradigm would be the ideal solution. I think that asterisk should cope with both situations instead of just choosing one. I think we all agree on that. -- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: [EMAIL PROTECTED] ------------------------------------------- Andrew Thomas 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). > > 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. > > 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 :). > > > > _______________________________________________ > -- 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
