[asterisk-users] CDR Rewrite -- Questions to the users (Steve Murphy)

Steve Murphy murf at digium.com
Mon Jan 12 14:06:11 CST 2009


On Mon, 2009-01-12 at 17:08 -0200, David fire wrote:
> 
> 
> 2009/1/12 Russell Brown <russell at lls.lls.com>
>         Quoth Steve Murphy...
>         >Date: Mon, 12 Jan 2009 08:51:03 -0700
>         >
>         >QUESTIONS:
>         >
>         >Which of the two would you see being useful to you?
>         
>         Obvious comment really but given LEG based CDR, one can
>         determine the
>         'Simple' data but you can't work it the other way.
>         
>         I'd therefore find LEG based CDR more useful as the
>         granularity (time on
>         Hold, in Queue, Waiting on pre-xfer ring etc etc) would be
>         good.
>         
>         
>         --
>          Regards,
>             Russell

> 
> hi
> one question, i will need to rewrite all my apps that use the cdr?
> and the queue_log will be rewrited?
> thanks
> 

Well, the wish/plan/whatever, if followed thru, would require 
people who have software that works with the existing CDR's, 
to tweak their code to work with the new regime.

I don't think the queue_log stuff will need to be modified, at
least with respect to CDR's, as all they do is reference the
uniqueID...  there may be other reasons pertaining to enhancements,
etc. that might demand some code update there, but that's not
in the realm of CDRs.

By "tweak their code", is might involve a few lines of update,
or a total rewrite, I don't know.

But the idea is make the specs for the new system as public and
known as possible in advance of a new implementation. The 
period of time during which the old code would still exist 
would be an entire release, so that gives you probably about 2 years...
in the meantime, we'll probably want to cease maintaining the old code.
That should mean that the old code should actually become more stable,
because so far, it's very difficult to change ANY aspect of the current
CDR system without introducing  new regressions.

Given the fact that the current implementation has serious problems,
holes and gaps wrt to parking, xfers, etc, and is so hard to
maintain in its current format, the long-term goals of reducing
the cost of maintenance, and getting higher reliability, hopefully
will make the effort of recoding worth that effort.

murf

-- 
Steve Murphy <murf at digium.com>
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/20090112/4e6432c6/attachment.bin 


More information about the asterisk-users mailing list