[asterisk-dev] CDR differences

[Matthew Nicholson]

On Wed, 2010-03-31 at 18:53 -0500, Terry Wilson wrote:
> So, there have been some changes in how CDRs work over the course of the 1.4 branch (and other branches). What I'm trying to do is figure out what the "correct" behavior should be.  For example, for a dialplan example that looks like:
> 
> [default]
> exten => _XXXX,1,ForkCDR
> exten => _XXXX,n,Dial(SIP/${EXTEN})
> exten => _XXXX,n,Hangup
> 
> the following CDR entries are created
> tags/1.4.0:
> "","","6004","default","","OSS/dsp","","ForkCDR","","2010-03-31 23:20:49","2010-03-31 23:20:49","2010-03-31 23:20:55",6,6,"ANSWERED","DOCUMENTATION","1270077649.1",""
> "","","6004","default","","OSS/dsp","SIP/6004-0259f770","Dial","SIP/6004","2010-03-31 23:20:49","2010-03-31 23:20:49","2010-03-31 23:20:55",6,6,"ANSWERED","DOCUMENTATION","1270077649.1",""
> 
> branches/1.4:
> "","","6004","default","","Console/dsp","","Dial","SIP/6004","2010-03-31 23:26:15","2010-03-31 23:26:15","2010-03-31 23:26:28",13,13,"ANSWERED","DOCUMENTATION","1270077975.0",""
> "","","6004","default","","Console/dsp","SIP/6004-00000000","Dial","SIP/6004","2010-03-31 23:26:15","2010-03-31 23:26:15","2010-03-31 23:26:28",13,13,"ANSWERED","DOCUMENTATION","1270077975.0",""
> 
> You'll notice that the lastapp in the first record of each is different with a ForkCDR record followed by a Dial record being the original behavior, and two Dial records being the new behavior. Now, it seems obvious to me that having two Dial() records would be incorrect. But, I'm a little dubious about ForkCDR being the lastapp as well. It doesn't seem like particularly useful information as it overwrites what the last action that was taken before the CDR was forked, and that you can tell a CDR was forked anyway by there being multiple CDRs with the same uniqueid. But, since pbx.c sets the lastapp as soon as ForkCDR is called, I can understand why this would be the case.  And of course, it seems like we should be minimizing the behavior changes.
> 
> So, I was wondering if some people could weigh in on what they thought the correct behavior was so I can write some tests that enforce that behavior in the future. I'm currently leaning towards just making things behave the way they did in the original 1.4.0 release.  I'm pretty sure one of the causes of the change was r195881 in May of 2009.
> 
> Terry

I believe the behavior of branches/1.4 is correct.  Forking the cdr
should still allow it to be updated.  The end time and answer time in
the original CDR are also updated.  I believe there is an option to lock
the CDR record if the user does not want it to be updated.

As for ForkCDR being the lastapp recorded in the CDR, this may not be
very useful, but it is the "correct" behavior.  I suppose it is more of
a side-effect of how the lastapp field works than what some one at some
point thought should happen with that field when used with ForkCDR.

-- 
Matthew Nicholson
Digium, Inc. | Software Developer