asterisk users - Jun 2007 - CDR changes in Trunk -- Transfers, CDRs, Life, and Everything

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!

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/20070612/496303c6/smime.bin

Hi Steve,

Please look at my asterisk-dev post from a few minutes ago about
dcontext and dst where the behaviour changed in a bad way in svn trunk
recently.

Thanks,
Steve

Murf,

you crack me up, but I totally agree with the vote or don't complain
model.


Thanks,
Dave

On Tue, 2007-06-12 at 13:05 -0600, Steve Murphy 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!
> 
> murf
> 
> 
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev

On 6/12/07, Steve Murphy <murf@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 :)

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.

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.

7: Third CDR timings seems out of bounds. Or i don't get something?

17. This gap could be easily detected by having unique call-id as in
note for 4/5.

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.

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.

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.

Great regards,
Atis