On Tue, 2008-11-25 at 08:06 +0000, Grey Man wrote: > >On Mon, Nov 24, 2008 at 6:56 PM, Steve Murphy <[EMAIL PROTECTED]> wrote: > > For the moment, let's not worry about the implementation. Let's > > get consensus on the spec first. In the scenario, where A calls B, > > B xfers A to C, C xfers A to D, or some such similar scenario, > > half the world wants a single CDR for A, from the time it started, > > to the time it hung up with D. The other half wants A->B's dial and > > bridge, > > a cdr for A & C's bridge, a CDR for A & D's bridge, and mayhaps some > > CDRs > > to describe the xfers, where B xfers A to C and C xfers A to D. > > > > My document is pointing in the former direction, and either we need to > > spec both, or pick one. > > To me the obvious answer is to provide a CDR for every call leg so for > A calling B via Asterisk there would be two CDRs produced. It's far > far easier to disregard the unwanted CDRs than it is to try and > generate the missing ones and in some cases it's virtually impossible. > If it's weighed up I think people would vote to have accurate CDRs > ahead of anything else and if single legs are the best way to do that > then it's the way it should be done. > > In addition with single leg CDRs it will solve the dilemna about > acommodating every possible call scenario that I know has caused you a > lot of consternation over the last 18 months. > > Sure it's a change from the current situation so maybe needs to use > the standard apporach of a configuration setting to opt in initially > before becoming the default in the subsequent major release.
OK, Greyman, your logic is solid. If we provide a CDR implementation that just generates the individual call legs, and ties them together via the linkedid (see team/group/newcdr), then both camps should be able to derive the info they need for billing, via hopefully not-overly-complex SQL queries to a backend db. I'll modify my RFC to reflect this line of thinking. Yes, it is a bit of shift. And, yes, the implementation will make this new approach optional, and not default. But, pardon if I make it available via the CEL domain come implementation time. It should take me a week to rehash my document; perhaps longer (I'm in bugfix mode, and this borderline development work); in the meantime, those with decided CDR needs might make their wishes known, if they do not think this approach will work. Speak now, or forever hold your peace; or forever complain... or whatever. If this is particularly distressing to you, perhaps your fears might be slightly assuaged when you read the details... murf -- 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