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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
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
