[asterisk-users] CDR Design

[regs at kinetix.gr]

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).




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
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081205/c751b574/attachment.htm