|Summary:||ASTERISK-20354: ResetCDR(e) problem - Duration time value is wrong|
|Reporter:||Krzysztof Chmielewski (kristoff)||Labels:|
|Date Opened:||2012-09-03 11:14:47||Date Closed:||2012-09-04 09:33:36|
|Versions:||22.214.171.124 126.96.36.199||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.
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 188.8.131.52
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 184.108.40.206 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.