On Fri, 2008-12-05 at 13:39 +0200, [EMAIL PROTECTED] 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: [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 -- Steve Murphy Software Developer Digium
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ -- 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