[asterisk-users] CDR Design

[Steve Murphy]

On Fri, 2008-12-05 at 12:35 +0000, 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 :).
> 

LOL, santa murf here, just making note that a generic CDR generator,
maybe with a few different flavors, generating CDR's 'realtime' or done
on event logs once a month standalone, isn't going to be a walk in the
park. Sure, there's going to be some simple bits to it, but as in every
system with a fair number of event types, exceptions to rules, etc., 
it's going to involve some serious thinking, blood, sweat and tears. The
code will encapsulate some hard-earned experience, minus some false
assumptions that had to be corrected.

Now, it might end up being a walk in the park, and maybe I'm just
being pessimistic, but personally, as a programmer, a CDR spec is
going to be easier to bill from than a sequence of interlaced events.

murf

> 
> 
> _______________________________________________
> -- 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/5f97529c/attachment.bin