[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-16 18:58 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?
====================================================================== 

---------------------------------------------------------------------- 
 (0109090) escape2mtns (reporter) - 2009-08-16 18:58
 https://issues.asterisk.org/view.php?id=14660#c109090 
---------------------------------------------------------------------- 
I just ran the more complicated scenario - the one we're using - and I
think I might have figured out the issue with duplicate CDR records.

Just like the last test, I called from 1111111111 into DID 2222222222 that
routes to queue 777. The call was answered by Sip/172. Then I did a manager
redirect to send both the inbound channel and the call recipient channel to
a music on hold context.

The channel for Sip/172 that had received the call was redirected from the
MOH context to a meetme room.

An outbound call to 3333333333 was originated from that same meetme room.

I then redirected the original inbound call channel from MOH to the meetme
room and the original call recipient dropped off.

This is a manager-controlled supervised transfer.

I think what's going on is that when the inbound call channel is
redirected to the MOH context it forks the original cdr entry but the new
action (MOH context) doesn't generate a CDR event.  So when it is
subsequently redirected to the Meetme room, we're duplicating based on the
original 'call received from queue' cdr record and therefore duplicating
the original event.


"calldate";"clid";"src";"dst";"dcontext";"channel";"dstchannel";"lastapp";"lastdata";"duration";"billsec";"disposition";"amaflags";"accountcode";"uniqueid";"userfield";"agent"
"2009-08-16 19:27:23";"\"CALLER NAME\"
<1111111111>";"1111111111";"777";"ext-queues";"SIP/SIP1-b774cea8";"SIP/172-08fb9cd8";"Queue";"777|tr||";"20";"20";"ANSWERED";"3";"2222222222";"1250465243.226";"3";
"2009-08-16 19:27:23";"\"CALLER NAME\"
<1111111111>";"1111111111";"777";"ext-queues";"SIP/SIP1-b774cea8";"SIP/172-08fb9cd8";"Queue";"777|tr||";"20";"20";"ANSWERED";"3";"2222222222";"1250465243.226";"3";
"2009-08-16 19:27:43";"\"CALLER NAME\"
<1111111111>";"1111111111";"1250465243226";"qvmeetme";"SIP/SIP1-b774cea8";"SIP/172-08fb9cd8";"MeetMe";"1250465243226|1dFqAx";"17";"17";"ANSWERED";"2";"2222222222";"1250465243.226";"3";
"2009-08-16 19:27:56";"\"CALLER NAME\"
<1111111111>";"1111111111";"1250465243226";"qvpickup";"SIP/172-08fb9cd8";"SIP/172-08fb9cd8";"MeetMe";"1250465243226|1dFqAx";"5";"0";"FAILED";"2";;"1250465263.230";"3";
"2009-08-16
19:27:57";"2222222222";"2222222222";"3333333333";"from-internal";"Local/1250465243226 at qvcallpickup-808d,1";"SIP/SIP1-08fbb7a0";"ResetCDR";"vw";"3";"2";"ANSWERED";"3";"2222222222";"1250465277.231";"3";
"2009-08-16
19:27:57";"2222222222";"2222222222";"1250465243226";"qvcallpickup";"Local/1250465243226 at qvcallpickup-808d,2";;"MeetMe";"1250465243226|1dFqx";"3";"3";"ANSWERED";"3";"2222222222";"1250465277.232";;


Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-16 18:58 escape2mtns    Note Added: 0109090                          
======================================================================