[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:              02-25-2008 12:23 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.
====================================================================== 

---------------------------------------------------------------------- 
 murf - 02-25-08 12:23  
---------------------------------------------------------------------- 
OK, I'll be taking a look at this. I took a CDR vacation when I tried to
look into 10927 and spent a good week on it, and still wasn't finished.
It's been a few months, maybe it's time to get going again. That was work
on the chan_zap, but yours appears to be chan_sip related.

My main difficulties with working on 1.4 CDR issues, is I can't possibly
win. Any fix I make (or have made so far) might fix one issue, but usually
have created other issues. But it won't hurt to look at this closely and
see what exactly might be entailed, and maybe this is something where I can
win-- a fix to a specific issue where no other affects are created. You
never know.

So, tell me these things: 

1. You say you are using a snom. Lucky day. I have a snom 360. I might be
able to reproduce this sequence pretty closely. What about A and C? Are all
phones involved SIP phones? are there any zap interfaces involved?

2. Exactly what buttons are pressed on the snom to do the transfer, and in
what order. Hate to get picky here, but sometimes, if I choose an alternate
path, I might fix a problem and not help your situation. It may not make
any difference, but just to be safe.... You hit the conference button, I
suppose, and B all three were talking until B hung suppose... correct? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-25-08 12:23  murf           Note Added: 0082875                          
======================================================================