[asterisk-users] CDR Desgin

[Steve Murphy]

On Wed, 2008-11-26 at 01:13 +0100, Freddi Hansen wrote:
> >
> > 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...
> >   
> I was part of a team that did design a multiservice billing system about 
> 15 years ago and the solution people seems to agree on here (and me to) 
> looks pretty much the same i.e one call may consist of several calls 
> legs. In addition to the linkedid it would be nice to have an indication 
> in the cdr that tells us that 'this is the lastone on this  linked id'.
> Our experience was that  we shouldn't  for load reasons work with cdr's 
> in the immidiate multileg format in the DB. So we did collect cdr's in a 
> tmp DB until we got the the record with end marker set. We would then 
> produce our final cdr for the actual service, store it in billing col. 
> and delete it from the multileg col. When a new service is created we 
> only have to make a the new customized cdr, we don't have to touch the 
> generation of the multileg format.  
> 
> Freddi

Freddi--

Very interesting. Brian Degenhardt had some code we just gave some
thought
to, wherein we determine if the last channel involved in a linkedID set
has been closed. If so, then the entire set is finished. We can use this
facility to get you a closing attribute, that could be added to the last
CDR emmitted for that set; OR, we could just emit another CDR with type
CLOSE or FINAL or something, that signals the end of the chain.

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/20081201/f06853bf/attachment.bin