[asterisk-users] CDR Desgin

[Steve Murphy]

On Tue, 2008-11-25 at 08:06 +0000, Grey Man wrote:
> >On Mon, Nov 24, 2008 at 6:56 PM, Steve Murphy <murf at digium.com> 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
-------------- 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/20081125/6d5605d2/attachment.bin