Steve Murphy wrote: > 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 > Just thinking out loud: how about a feature wherein, after the FINAL is sent, asterisk can 1. create a temp text file with just those entries, and 2. launch a user-made script.
cdr_manager.conf [general] legparsecmd=/usr/local/bin/my_parser.pl wherein the linkedID is passed as the first parameter and the text file name&path as the second Ignore this suggestion if it horribly complicates things. John _______________________________________________ -- 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