[asterisk-users] CDR Design

[Steve Murphy]

On Fri, 2008-12-05 at 13:39 +0200, regs at kinetix.gr wrote:
> Quote : "Like I said earlier - the CDR's aren't 
> reliable enough for a billing platform (as you've 
> rightly pointed out) but are OK for very basic call
> logging (something the customer can look at)."
> 
> I couldn't disagree more. The CDRs is the MOST reliable
> source for billing purposes (in postpaid mode that is - 
> for prepaid you have to use something else (although 
> even then the CDRs can be helpful for consistency checks)).
> 
> Other alternatives (e.g. radius) could not give you
> the same level of consistency as the CDRs (although better 
> than other implementations because the gateway retries
> to send the packet many times before giving up). What would 
> happen if your radius server was overloaded and could 
> not process accounting packets for a few secs/mins/hours?
> What would happen if the network is down (and the event 
> processing handler is in another box)?
> All these calls would be lost. This can rarely be seen 
> with CDRs logging. Because, whatever might happen you can 
> always count on them to rectify the situation.
> 
> I think the same can be said about other event based 
> billing setups. The gateway itself cannot (and shouldn't 
> really) be aware if the event was successfully processed by 
> the handling back-end so you end up with inconsistent data 
> and lost calls.
> 
> Now, a combination of the two (e.g. radius+CDRs) can cover 
> all the possible gone-wrong scenarios. But in order for that 
> to work you need all the detailing you can get in the CDR.
> 
> If ,however, you don't want to load your gateway with complex 
> CDRs you could entirely turn them off (or parts of it e.g. b-leg
> logging, log only a few details etc).
> 
> 

Well, if we spec some options, and it doesn't get *too* out of control,
we can spell out a few different scenarios for the generated CDR's.
Greyman's just wanting to know how long A was connected, how long B,
etc, is an entirely different approach than spelling out each leg.
Dropping stuff like HOLD and PARKING is possible, too.


> 
> Andrew Thomas wrote: 
> > Thanks for this Greyman - it's all beginning to make sense now ;).
> > 
> > I agree that the 'loss of CDR upon txfr' is a nasty bug which does need
> > to be addressed before anything else (assuming it hasn't been already).
> > 
> > But, wouldn't it be better if you could ignore the CDR's completely and
> > use an event based system?  This would give you ALL the information you
> > need.  All that remains is to filter out the un-required bits.
> > 
> > Like I said earlier - the CDR's aren't reliable enough for a billing
> > platform (as you've rightly pointed out) but are OK for very basic call
> > logging (something the customer can look at).
> > 
> > Hopefully, the murf'ster will chirp in here :).
> > 
> > Cheers
> > Andy
> > 
> > -----Original Message-----
> > From: asterisk-users-bounces at lists.digium.com
> > [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Grey Man
> > Sent: 05 December 2008 09:37
> > To: Asterisk Users Mailing List - Non-Commercial Discussion
> > Subject: Re: [asterisk-users] CDR Design
> > 
> > On Fri, Dec 5, 2008 at 8:26 AM, Andrew Thomas <andy at datavox.co.uk>
> > wrote:
> >   
> > > In summary: Leave CDR exactly as it is and create a new CEL (Call
> > >     
> > Event
> >   
> > > Logging) module (optional in modules.conf) that puts out (and does not
> > > accept) call event information (ie. a one-way fire-and-forget output
> > > from Asterisk).
> > > 
> > >     
> > 
> > Hi Andrew and Others,
> > 
> > This thread is actually part of a discussion that has been going on
> > for over a year. The links below provide the background to the whole
> > thing.
> > 
> > http://www.asterisk.org/node/48358
> > http://bugs.digium.com/view.php?id=11849
> > http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.htm
> > l
> > 
> > Up until recently the approach was to try and fix the specific bugs
> > with transfer CDRs as a typical bug. There is now a realisation that
> > that is a lot trickier than inially thought so it's been decided to
> > try and come up with a good design for the Asterisk CDR sub-system.
> > 
> > Regards,
> > 
> > Greyman.
> > 
> > _______________________________________________
> > -- 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
> >   
> 
> _______________________________________________
> -- 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/6f24aca8/attachment.bin