[asterisk-bugs] [Asterisk 0011093]: CDR Created incorrectly on Transfer of outgoing call

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11093 
====================================================================== 
Reported By:                rossbeer
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   11093
Category:                   Applications/app_cdr
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.13  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             10-26-2007 10:02 CDT
Last Modified:              11-21-2007 15:00 CST
====================================================================== 
Summary:                    CDR Created incorrectly on Transfer of outgoing call
Description: 
When making an outgoing call and then transferring a call to another
extension the CDR details are incorrect.

I would expect to see two CDR's created, one for the outgoing call and
another for the transfer as Asterisk does, however it stops (ends) the
outgoing CDR at the point of transfer, instead of continuing to increment
the 'seconds'.

This problem occurs on both blind transfers and attended (using a Snom and
not using '#' or '*1' features). However attended transfers are more
accurate than blind transfers, they do continue to count however the time
is not 100% accurate.

I have tried to fix this myself in the dial plan by using '/n' and a local
channel however it still occurs. This problem did not occur in previous
versions of Asterisk.
====================================================================== 

---------------------------------------------------------------------- 
 jpabuyer - 11-21-07 15:00  
---------------------------------------------------------------------- 
I upgraded from 1.2 to 1.4 yesterday, and hit this bug miserably. So I had
to go back, and after researching and testing a lot, this is what I found:

First, the main scenario are this Steps:
1.- A Calls B and B answers, let's say instantly (for the sake of math
simplicity)
2.- X seconds later, B transfers the Call to C, C answers, and B gets out
of the way.
3.- Y seconds later A or C hang up.

After step 3, two CDRs should be created:
1.- one for A calling B, lasting X+Y seconds.
2.- one for B calling C, for Y seconds.

And that's the behavior we had until 1.4-r59485 inclusive.
Since r59486 (http://bugs.digium.com/view.php?id=8221) the behavior starts
changing to this: Two CDRs are created:
After Step 2:
1.- one for A calling B, lasting only X seconds.
After Step 3:
2.- one for B calling C, for Y seconds.

This is totally wrong, and totally breaks our billing system. But it
doesn't end here.

Since 1.4-r60989, CDRs for transfered calls are totally useless. For any
transfered call, 6 CDR entries are created. Describing them might be as
useless as the records themselves, but anyway:
After Step 2:
1.- accountcode present, src is empty, dst is C, answered.
2.- accountcode is empty, src is empty, dst is 's', answered.
3.- accountcode is present, src is empty, dst is B, answered.
4.- accountcode is present, src is B, dst is B, failed. (Channel says
<ZOMBIE>)
After Step 3:
5.- accountcode is empty, src is empty, dst is 's', answered.
6.- accountcode is present, src is B, dst is empty, failed.

Latest svn release 1.4-r89505 is not much better. It creates 4 entries:
After Step 2:
1.- accountcode present, src is B, dst is B, answered.
2.- accountcode is empty, src is empty, dst is empty, answered.
3.- accountcode present, src is A, dst is B, answered.
After Step 3:
4.- accountcode present, src is B, dst is 's', answered.


rossbeer, if you need correct CDR records, like I do, you will need to
stick to release 1.4.2 or svn release 59485.

murf, your hands have been in all the patches that have broken CDRs for
transfered calls hahahaha :-D so it's perfect that you've been assigned for
this bug. If I can help in any way, don't hesitate to ask me. I already
have 4 polycoms in my desktop to make tests, and I am very interested in
this problem to be solved. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-21-07 15:00  jpabuyer       Note Added: 0074164                          
======================================================================