[asterisk-bugs] [Asterisk 0014660]: [patch] Lost info in CDR when transfering call via AMI's Redirect

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14660 
====================================================================== 
Reported By:                caspy
Assigned To:                mnicholson
====================================================================== 
Project:                    Asterisk
Issue ID:                   14660
Category:                   CDR/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.0.6 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-03-13 09:11 CDT
Last Modified:              2009-08-11 21:30 CDT
====================================================================== 
Summary:                    [patch] Lost info in CDR when transfering call via
AMI's Redirect
Description: 
- SIP/1344 call SIP/1340
- SIP/1340 answers, and they are speaking
- man-in-a-middle do a Redirect of SIP/1344 leg of this call to SIP/1341
- SIP/1341 answers, and 1344 speaks with 1341 successfuly.

The probles is in CDR.
For the first call (1344 to 1340) asterisk lost just all important
fields:


"","","s","fromoffice","","SIP/1340-08c6dce8","","","","2009-03-13
16:37:44","2009-03-13 16:37:47","2009-03-13
16:37:54",10,7,"ANSWERED","DOCUMENTATION","1236951464.550476",""

"","1344","1341","fromoffice","""Akzhan Test""
<1344>","SIP/1344-b4b3e758","SIP/1341-b51deec0","Dial","SIP/1341,60,twTWL(5400000)","2009-03-13
16:37:44","2009-03-13 16:38:00","2009-03-13
16:38:05",21,5,"ANSWERED","DOCUMENTATION","1236951464.550474",""


Also, mention that uniqueid is very strange: first part (time) is the
same, but second is decreesed for two. Why?
====================================================================== 

---------------------------------------------------------------------- 
 (0108925) escape2mtns (reporter) - 2009-08-11 21:30
 https://issues.asterisk.org/view.php?id=14660#c108925 
---------------------------------------------------------------------- 
We're wrestling with the same issue and were pleased to find this patch. 
I've installed on 1.4.25.1 and it appears to work as designed.  We will
know more tomorrow after a higher call volume has been put through the
system.

In our case we have a call center app that agents use to place the inbound
call on hold using AMI to redirect the channel to a music on hold context,
make an outbound call with AMI's originate, and then redirect the
inbound/outbound legs to a meetme conference to patch the call.

The only curiosity noticed so far is when redirecting that answered call
to the music on hold context (for example) the disposition for that next
leg of the call shows as "FAILED" even though the first CDR item had a
disposition of "ANSWERED".  In the limited testing I've done, it looks like
all associated records after that first one show a "FAILED" disposition. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-11 21:30 escape2mtns    Note Added: 0108925                          
======================================================================