On Mon, 2009-01-12 at 17:08 -0200, David fire wrote: > > > 2009/1/12 Russell Brown <russ...@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 <m...@digium.com> Digium
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users