[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-17 21:13 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?
====================================================================== 

---------------------------------------------------------------------- 
 (0109196) escape2mtns (reporter) - 2009-08-17 21:13
 https://issues.asterisk.org/view.php?id=14660#c109196 
---------------------------------------------------------------------- 
The ast_cdr_update didn't fix the duplicate cdrs caused by the double
redirect.  I just tried that and got the following cdr's.

In this test I did a supervised transfer where the inbound caller was
received by the agent from queue 777 right away and after 25 seconds both
the inbound caller and the agent were redirected to hold.

After another 30 seconds or so (1 minute into the call) the agent was
redirected to a meetme room and the outbound call was originated from that
room .

After another 30 seconds or so (1:30 into the call) the original inbound
call was redirected from hold music to the meetme room and the agent
dropped off.

That meetme conference continued for another 1:30 before both legs
disconnected.

"calldate";"clid";"src";"dst";"dcontext";"channel";"dstchannel";"lastapp";"lastdata";"duration";"billsec";"disposition";"amaflags";"accountcode";"uniqueid";"userfield";"agent";"queue_duration"
"2009-08-17 21:41:00";"\"CALLER NAME \"
<1111111111>";"1111111111";"777";"ext-queues";"SIP/SIP1-b7600468";"SIP/172-085e2538";"AGI";"VERBOSE";"23";"23";"ANSWERED";"3";"2222222222";"1250559660.16";"3";"172";"1"
"2009-08-17 21:41:00";"\"CALLER NAME \"
<1111111111>";"1111111111";"777";"ext-queues";"SIP/SIP1-b7600468";"SIP/172-085e2538";"AGI";"VERBOSE";"23";"23";"ANSWERED";"3";"2222222222";"1250559660.16";"3";"172";"1"
"2009-08-17 21:41:23";"\"CALLER NAME \"
<1111111111>";"1111111111";"125055966016";"qvmeetme";"SIP/SIP1-b7600468";"SIP/172-085e2538";"MeetMe";"125055966016|1dFqAx";"67";"67";"ANSWERED";"2";"2222222222";"1250559660.16";"3";;"0"
"2009-08-17 21:41:59";"\"CALLER NAME \"
<1111111111>";"1111111111";"125055966016";"qvpickup";"SIP/172-085e2538";"SIP/172-085e2538";"MeetMe";"125055966016|1dFqAx";"32";"0";"FAILED";"2";;"1250559683.20";"3";;"0"
"2009-08-17
21:42:00";"2222222222";"2222222222";"3333333333";"from-internal";"Local/125055966016 at qvcallpickup-5ea9,1";"SIP/SIP1-085fa2b0";"ResetCDR";"vw";"30";"28";"ANSWERED";"3";"2222222222";"1250559720.21";"3";"172";"0"
"2009-08-17
21:42:00";"2222222222";"2222222222";"125055966016";"qvcallpickup";"Local/125055966016 at qvcallpickup-5ea9,2";;"MeetMe";"125055966016|1dFqx";"30";"30";"ANSWERED";"3";"2222222222";"1250559720.22";;"172";"0"

* In these cdrs the 'last application' for the first queue event is now
AGI because we're now passing the Queue command a connect-time agi script
to run.

The double CDR entry for the first inbound call is still there.  It would
almost make sense if the uniqueid was different for the 2 events because
each could represent the two channels of that first inbound call (that are
both redirected to a hold music context). 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-17 21:13 escape2mtns    Note Added: 0109196                          
======================================================================