[asterisk-dev] CDR differences

[Steve Murphy]

On Wed, Mar 31, 2010 at 5:53 PM, Terry Wilson <twilson at digium.com> 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
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
Steve Murphy
ParseTree Corp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100331/678b1c75/attachment.htm