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

[Atis]

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 :)

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