[asterisk-dev] possible lack of CDR data recorded after an attended transfer (atxfer)

[Steve Murphy]

On Fri, 2007-05-18 at 23:25 +0200, Stephen Davies wrote:
> > > But, I've got plenty of time to work on straightening out CDR's.
> > > And the
> > > more I do, the more I want to just totally rip it out, and re-code it.
> > > [...]
> 
> Can I suggest that any new CDR system be implemented alongside the old
> one.  That way people can still generate CDRs in the old format for
> existing billing systems whilst getting to grips with the new ones.

Steve-- (nice name, by the way!)

Therein lies the rub-- this isn't a "new" CDR system, it's a fix for the
old one.
I've worked on a new CDR system; it's quite different. The current
implementation
has some shortcomings, which if I fix, may cause you some heartburn.

I'd like not to have to provide a "Keep buggy CDR implementation" config
option, and worry about conditionally executing every mod I make; on the
same hand, I do see your point; you have code that works, and even if
just make even a small change in behavior, it will cost you time and
money to adapt to it.

But, sooner or later, you will start hitting the aforementioned
problems, and the only way you'll ever get them fixed is to turn off the
config-file option you desire, and adapt your code... 

And, it could easily be, that you are already paying for the problems...
Some transfer situations to external numbers will never show up in the
CDR records. Indeed, someone with a knowledge of the weaknesses here
could avoid being billed for calls if they play the system right!

I don't know if this could exactly be considered a security problem, but
it borders on one, methinks...

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-dev/attachments/20070520/e66df2ce/smime.bin