[asterisk-dev] CDR issues - Can someone sanity check them?

[Terry Wilson]

> > I'm not even sure I agree with the goal. *Every* time we touch CDRs
> > we
> > seem to break something for someone. It is impossible to get
> > consensus
> > from the community on this kind of thing because there are probably
> > (10s or 100s of?) thousands of users who will never know about the
> > change
> > until after the fact. I'd rather just let CDRs be historically
> > consistent and
> > "not optimal" and push people to use CEL. We've lost *months* of
> > people's
> > time to "fixing CDRs" with change after change being reverted (or
> > even worse
> > in some of the cases, not reverted).
> >
> 
> I had hoped to avoid that response by pointing out that where the
> currently generated CDR data is clearly correct, it would remain
> untouched. The cases that need fixing are mostly lost and duplicated
> data or blatantly incorrect data (negative billsecs is quite possible
> with the current code!)

The problem is there isn't a "clearly correct" or "clearly incorrect" in most cases. People often have tons of code for parsing their CDRs and working around oddities and bugs that are there. Or dialplan hacks. Or whatever. We could fix something that is "clearly wrong" and all of the sudden we break someone's workaround. Dropped CDR in one case? We fix it. Now someone has a case that they aren't dealing with (or had already dealt with and we just broke it). It is super super difficult to make a change to CDRs without having unintended consequences. Ask Steve Murphy about it sometime. It just isn't worth it when there is a viable alternative in CEL. In my view, CDRs should never ever be touched again. Ever. Leave them as a relic, forever acting as they always have and move on to CEL.
 
> Regardless, can someone CDR-savvy review the 2 issues mentioned in
> the
> OP as they are hopefully fixes that do not require open-heart CDR
> surgery. Between the 2 of them, they fix:
>
> ASTERISK-17826
> - At least one case where 2 CDRs are lost on a call
> - At least one case where an answered call is logged as unanswered

For instance, in this patch you are clearing the HANGUP_DONT flag. Who knows what cases that might break since these calls could now execute the hangup extension when they wouldn't have before? I know that I can't anticipate every single CDR and dialplan setup in existence, and I'm not willing to screw with people's billing systems that they've invested tons of time in when it is nearly impossible to touch CDRs without causing unintended side-effects. It just isn't worth it.