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
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