Summary:ASTERISK-20354: ResetCDR(e) problem - Duration time value is wrong
Reporter:Krzysztof Chmielewski (kristoff)Labels:
Date Opened:2012-09-03 11:14:47Date Closed:2012-09-04 09:33:36
Versions: Frequency of
Environment:Attachments:( 0) full.rar
test001 A is calling to test002, test002 does not answer. After 10 seconds call is forwarded to test003. Test003 answers the call after 5 seconds. Test001 and test003 are talking for 3 sec, and test003 ends the call.

Dial Plan:
exten => 100,1,Dial(SIP/test002,10)
exten => 100,n,ForkCDR(r)
exten => 100,n,ForkCDR(eA)
exten => 100,n,Dial(SIP/test003)

In asterisk
CDR between test001 and test002, has status No Answer and billsec = 0, and this is ok. But duration time for this CDR is set to duration of test001 <-> test003 after call was forwarded by test002. In My opinion, duration time for this call should be set to 10 seconds.

What I'm trying to do here is create one main CDR for call from test001 (duration 10 + 8 = 18 and billsec = 3). This is why I'm doing first ForkCDR(r). Next I would like to have CDR from actual call test001 -> test002 which status  No Answer and duration time 10, billsec 0. To do this I use second ForkCDR(eA). This CDR should end after we stop calling to test002. Finally I need CDR for forwarded call test001 and test003 which duration time = 8 and bilsec = 3.

instead of what i wrote above  second CDR (between test001 and test002) has the same duration like 3rd CDR, duration time = 8 seconds.

In asterisk second CDR in this scenario has duration set to 0.
Comments:By: Krzysztof Chmielewski (kristoff) 2012-09-03 11:17:48.668-0500


By: Matt Jordan (mjordan) 2012-09-04 09:33:30.263-0500

CDRs do not take into account scenarios involving multiple call legs.  The behavior of CDRs in such situations is undefined, and depends on the implementation.  For complex scenarios involving transfers, forwarding, or other situations in which a channel is bridged multiple times, you are better off relying on CEL.

The behavior most likely changed slightly between the versions in 1.8 due to a bug fix that set the CDR duration when a CDR is explicitly ended, as opposed to when the CDR is written.  Waiting until the CDR write caused errors when batch mode was used.  I don't expect us to change this behavior back.

By: Krzysztof Chmielewski (kristoff) 2012-09-04 09:59:40.597-0500

Thank You for response. I will switch to CEL mechanism.

Best Regards