[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:                     feedback
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:              06-13-2008 10:23 CDT
====================================================================== 
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.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0010927 Zap assisted xfer via hookflash yield C...
related to          0012724 Asterisk does not log all legs of call ...
====================================================================== 

---------------------------------------------------------------------- 
 murf - 06-13-08 10:23  
---------------------------------------------------------------------- 
looking over the history of this bug, I've noticed that folks are pretty 
loose about their event descriptions, and because of that, they get
different
results. Maybe this shouldn't be; but at the moment, it is.

As an example, jpabuyer describes the xfer:
...
2.- X seconds later, B transfers the Call to C, C answers, and B gets out
of the way.
...
and reports that:

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.

Greyvoip, otoh, reports on 1.2:

1.- one for A calling B, lasting X seconds (NOT X+Y seconds).
2.- one for B calling C, for Y seconds. 

Now, I just did a test a day or two ago on 1.2, and saw two CDR's ending
at the same time, which would be jpabuyer's results. 
Is Greyvoip wrong? Not necessarily! It all depends on which method you
use to perform:

2.- X seconds later, B transfers the Call to C, C answers, and B gets out
of the way.

Let's see: there's the 'features' approach of using '#' to xfer a call.
And, (2.) could be accomplished by using either 'attended' or 'blind' xfer
methods native to the phone itself. Between 'blind' and 'attended' xfers,
you can get different CDR results. Using '#' vs phone xfer buttons could
also, theoretically, give different CDR results.

Also, on 3-ways, different CDR's can result based on who hangs up first.

So, if we are going to discuss what CDR's **should** look like, we need to
get really specific about the sequence of events. You shouldn't be saying
"A tranfers B to C"... you should be saying "A hits the 'hold' button,
puts
B on hold, dials C, talks, and then hits the Xfer button." or somesuch, so
we can reproduce the exact sequence in question. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-13-08 10:23  murf           Note Added: 0088670                          
======================================================================