On Wed, 2007-06-13 at 00:44 +0300, Atis wrote: > On 6/12/07, Steve Murphy <[EMAIL PROTECTED]> wrote: > > I have created an asterisk.org blog entry: > > > > http://www.asterisk.org/node/48358 > > > > to describe what I will shortly be committing to trunk to correct the > > weaknesses of CDRs, that asterisk users and developers have been > > complaining about for quite some time. > > > > Highlights: Restructuring the code and philosophy of CDRs. > > Plans to eliminate the ForkCDR() application > > Plans to create the CDRstart(), > > CDRanswer(handle), > > and CDRclose(handle) functions to provide > > dialplan ability to create CDR records. > > > > (I am considering restructuring the CDR function, also, > > to allow mods to be made to not only Channel-attached > > CDR's, > > but also the fields in CDRs created by CDRstart(), BTW). > > > > I seek feedback from folks who have battled with CDRs to develop billing > > applications, and those who plan doing so in the future. Participate or > > be happy with the senseless mess that will surely result from your > > non-participation! > > Hi Murph. > > Cool, i'm one of such persons :)
Excellent! I appreciate your taking the time to look at my ideas! > > I'm still reading that doc, and am quite fascinated by all that > timings, they seem great :) > > Here goes some notes on samples (most of them are probably subject to > separate discussions, but i have to start somehow) > > 2. Wouldn't it be a good idea to add one more field in CDR, saying > which extension originates the transfer? I'm currently doing it > manually, but if it's easy for you, it might ease the job for others. That's the problem. I'd love to tie the transfers together into a single sort of thing, but it isn't that easy. Because it's being done quietly in the lower levels of the bowels of asterisk, it's almost invisible to the bridge that gets set up, that any xfers have occurred. > > 4/5. I really don't like that transfers can't be linked in simple way. > I would prefer to have call_id unique for one call (including all the > transfers within it). I have this now in dialplan logics - on first > channel set __global variable to current uniqueid, and then just > append it in following channels. As for attended (and hookflash) > transfers - it could be replaced, if call is later bridged to existing > call. > This is not a bad idea/strategy... I can't picture how you work it, tho. What I do picture is a highly parallel environment, where several calls are coming in simultaneously, and global vars would be fairly useless in this sort of environment. Hmmm. I *could* set up an extra var in a channel, that stores the uniqueid of a call. Once it is set, it is never changed. I could make the bridge copy it to the peer; but... will this always work? It seems like a hookflash to a new phone is hard to connect to the current call... it would involve code in the channel drivers, and I'm trying to avoid that right now. > 7: Third CDR timings seems out of bounds. Or i don't get something? > You are correct, the 3rd CDR shouldn't be there. Must have gotten carried away in the cutting and pasting. I've corrected the blog. > 17. This gap could be easily detected by having unique call-id as in > note for 4/5. > Hmmm. I'm still thinking about it. Hmmmm. > ForkCDR really isn't useful to me. However i employ NoCDR and ResetCDR > a lot. New mechanism seems really great, but i just hope that NoCDR > and ResetCDR won't be removed. I'm changing the bridging code to obey the noCDR flag. I'll study the ResetCDR. > > Btw, would it be possible to manipulate answer status of CDR somehow? > I imagine a situation, that call is picked up by IVR, but i don't want > it's CDR to have it ANSWERed in CDR. Instead i would like to reset it, > and count answer on next bridge. An app could be invented to reset answer status, but here's some good news-- if the incoming call doesn't talk to anyone, then no CDR, as things stand. Using the CDRstart() funcs, you can force a CDR to be generated in the dialplan, to record such doomed calls, if you want. > > Another great concern for me - queues. Can you provide some samples > for that? It's most of my billing, so i'm quite worried that you even > don't mention them. > I'll have to play with queues-- I have only once touched them. Looks like I'll have to get my feet wet again. > Great regards, > Atis -- Steve Murphy Software Developer Digium
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
