I've taken the liberty of starting a new thread to discuss the design of the Asterisk CDR mechanism. The discussion has been kindly initiated by murf putting together a proposal: http://svn.digium.com/svn/asterisk/team/murf/RFCs. After reading the proposal I still don't think it's the right way to go. To my mind adding more channel variables increases the complexity in a situation that is already overly so. I think it's a mistake to try and think about all the different call scenarios and come up with little tricks for the more complicated ones. There will always be something missed; app_shotgun initiates calls to 100 random numbers and as soon as three or more calls are answered it will start randonly transferring them amongst each other at 2 second intervals. I think it's important to clarify at the outset what a CDR should be. The most fundamental requirement for CDRs is that they accurately record the following pieces of information for EVERY call entering or leaving the system (note every means every and not; "channel" calls but not "peer" calls). 1. Destination (aka as A Number) 2. AccountCode (aka as B Number) 3. Call Start Time (answer time), 4. Duration. Of course adding extra information can be very useful and I'm not proposing any fields be removed from the current implementation (although for pity's sake one change that should be made it to use a GUID/UUID for the CDR's uniqueid and save endless confusion). People that really do need verbose or enhanced CDRs to do things like tracking a call's flow as it travels in and out of queues, parking lots etc. would be better off using AMI or the new CEL and not CDRs. At the very least if problems arise with their call flow tracking they will still be able to rely on the accuracy of the CDRs to piece it altogether to work out what's going wrong. My proposal of creating a 1-to-1 relationship between CDRs and Asterisk channels already exsits but somewhere along the line it's going awry. As an experiment, and to actually do something instead of continually moaning about it, I started commenting out the blocks of code in res_featrures.c and sip_channel.c that muck around with the channel CDRs when a transfer occurs. The results of that were that the CDRs for blind and attended transfers actually got better! They're still not quite right but are pretty close with only one CDR on each having a wrong detstination. Regards, Greyman.
I've taken the liberty of starting a new thread to discuss the design of the Asterisk CDR mechanism. The discussion has been kindly initiated by murf putting together a proposal: http://svn.digium.com/svn/asterisk/team/murf/RFCs. After reading the proposal I still don't think it's the right way to go. To my mind adding more channel variables increases the complexity in a situation that is already overly so. I think it's a mistake to try and think about all the different call scenarios and come up with little tricks for the more complicated ones. There will always be something missed; app_shotgun initiates calls to 100 random numbers and as soon as three or more calls are answered it will start randonly transferring them amongst each other at 2 second intervals. I think it's important to clarify at the outset what a CDR should be. The most fundamental requirement for CDRs is that they accurately record the following pieces of information for EVERY call entering or leaving the system (note every means every and not; "channel" calls but not "peer" calls). 1. Destination (aka as A Number) 2. AccountCode (aka as B Number) 3. Call Start Time (answer time), 4. Duration. Of course adding extra information can be very useful and I'm not proposing any fields be removed from the current implementation (although for pity's sake one change that should be made it to use a GUID/UUID for the CDR's uniqueid and save endless confusion). People that really do need verbose or enhanced CDRs to do things like tracking a call's flow as it travels in and out of queues, parking lots etc. would be better off using AMI or the new CEL and not CDRs. At the very least if problems arise with their call flow tracking they will still be able to rely on the accuracy of the CDRs to piece it altogether to work out what's going wrong. My proposal of creating a 1-to-1 relationship between CDRs and Asterisk channels already exsits but somewhere along the line it's going awry. As an experiment, and to actually do something instead of continually moaning about it, I started commenting out the blocks of code in res_featrures.c and sip_channel.c that muck around with the channel CDRs when a transfer occurs. The results of that were that the CDRs for blind and attended transfers actually got better! They're still not quite right but are pretty close with only one CDR on each having a wrong detstination. Regards, Greyman.
On Sat, 2008-11-22 at 04:02 +0000, Grey Man wrote:> I've taken the liberty of starting a new thread to discuss the design > of the Asterisk CDR mechanism. The discussion has been kindly > initiated by murf putting together a proposal: > http://svn.digium.com/svn/asterisk/team/murf/RFCs. > > After reading the proposal I still don't think it's the right way to > go. To my mind adding more channel variables increases the complexity > in a situation that is already overly so. I think it's a mistake to > try and think about all the different call scenarios and come up with > little tricks for the more complicated ones. There will always be > something missed; app_shotgun initiates calls to 100 random numbers > and as soon as three or more calls are answered it will start randonly > transferring them amongst each other at 2 second intervals. > > I think it's important to clarify at the outset what a CDR should be. > The most fundamental requirement for CDRs is that they accurately > record the following pieces of information for EVERY call entering or > leaving the system (note every means every and not; "channel" calls > but not "peer" calls). > > 1. Destination (aka as A Number) > 2. AccountCode (aka as B Number) > 3. Call Start Time (answer time), > 4. Duration. > > Of course adding extra information can be very useful and I'm not > proposing any fields be removed from the current implementation > (although for pity's sake one change that should be made it to use a > GUID/UUID for the CDR's uniqueid and save endless confusion). > > People that really do need verbose or enhanced CDRs to do things like > tracking a call's flow as it travels in and out of queues, parking > lots etc. would be better off using AMI or the new CEL and not CDRs. > At the very least if problems arise with their call flow tracking they > will still be able to rely on the accuracy of the CDRs to piece it > altogether to work out what's going wrong. > > My proposal of creating a 1-to-1 relationship between CDRs and > Asterisk channels already exsits but somewhere along the line it's > going awry. As an experiment, and to actually do something instead of > continually moaning about it, I started commenting out the blocks of > code in res_featrures.c and sip_channel.c that muck around with the > channel CDRs when a transfer occurs. The results of that were that the > CDRs for blind and attended transfers actually got better! They're > still not quite right but are pretty close with only one CDR on each > having a wrong detstination. > > Regards, > > Greyman.Greyman-- 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. 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/20081124/96d9d54d/attachment.bin
> > 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
Just seconding Freddi's idea - as it makes perfect sense. Otherwise we could quite easily start testing a call that hasn't actually finished yet.
> On Fri, Dec 5, 2008 at 8:11 PM, Steve Murphy <murf at digium.com> wrote: > > Hmmm. See your point. I can suppress these HOLD events, and any > others I end up covering with a config file. Whether it's by default > on or off, we can arrange as the majority, whatever that is, > requests. > > In my current line of thinking, the HOLD period was output to > help describe what was done with the channel. Whether folks > on hold are charged the same as folks not on hold, that's a > business decision. > > I personally cannot predict with any certainty what folks > will be interested in billing or not billing. You seem pretty > certain that HOLD information is useless to billing, but can you > guarantee me that this info is useless in all possible billing > situations?No I can't but it would be the first I'd ever heard of anybody being differently when they were on hold compared to a normal call. Putting a call hold does not change the original call ends and the time on those calls keeps ticking so I can guarantee you there a people like me that want to bill the call besed on endpoints and whether the call is on hold, listening to streaming radio, being sent a festival tts message etc. is irrelevant.> Well, if I take a UUID type field and tack it onto the end of the > current LinkedID, will that do? I get something I can sort timewise > and make a quick decision on; you get something that but once every > billion-trillion-gazillion times, will be unique. And you can also > tack a system id onto the end, or the begin for that matter, on the > way to the database....In my perfect World I'd change uniqueid to a UUID since that's what it claims to falsely be. But as you say there are other ways a unique id can be added and if needs be we could do it that way. I've being trying to avoid a bunch of comma separated data in the UserField but that's no big deal either way.> maybe. But, you can do one-touch stuff via dtmf to asterisk, and > do transfers that way. How this might reflect back into the sip > protocal, I'm not certain right now. A sip device might not be > able to tell what happened, but this is conjecture on my part.No it doesn't. A SIP transfer is a striaght forward operation and the only way to do one is with a REFER request. How you generate the REFER request can be different such as DTMF or transfer button but the effect is identical. When Asterisk processes the REFER request it is going to end up initiaiting a call and for a blind transfer hanging one up. That's it.> I'll have to think on this. Perhaps an option to reduce everything > to single per-chan cdrs. It'll be a ton easier to implement something > like this by NOT storing the CDR on a channel.In my life as a software engineer simple solutions tend to be the right ones. Regards, Greyman.