[asterisk-users] CDR Design

[Andrew Thomas]

Amen!
	  	

-----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Apostolos
Pantsiopoulos
Sent: 05 December 2008 13:46
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] CDR Design

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: regs at kinetix.gr
------------------------------------------- 



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