[asterisk-dev] CDR differences

[Terry Wilson]

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