[asterisk-users] Re: [asterisk-dev] CDR changes in Trunk -- Transfers, CDRs, Life, and Everything

[Steve Murphy]

On Wed, 2007-06-13 at 00:44 +0300, Atis wrote:
> On 6/12/07, Steve Murphy <murf at digium.com> 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
-------------- 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/20070613/9bef6cfb/smime.bin