[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-12 10:19 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?
====================================================================== 

---------------------------------------------------------------------- 
 (0108949) escape2mtns (reporter) - 2009-08-12 10:19
 https://issues.asterisk.org/view.php?id=14660#c108949 
---------------------------------------------------------------------- 
Example of cdrs when using AMI redirect with this patch.  The caller #is
replaced with 1111111111 and the DID number is replaced with 2222222222 and
the extension in queue 777 that took the call was 170.  The outbound number
that the inbound call is ultimately connected to is replaced with
3333333333.

In this example an inbound call from 1111111111 to DID 2222222222 was
routed to queue 777 and delivered to static  member sip/170.  The operator
at sip/170 answers the call and uses the call center app to place the call
on hold.  When this happens, an AMI redirect sends both channels (caller
and agent) to a music on hold context.  The agent then dials an outside
party using the call center app ... which results in an AMI originate to
the outside number from a temp meetmeroom accessed using context
qvcallpickup.  Meanwhile, the operator is placed in this same room using a
redirect through context qvpickup.  When the outbound call is answered the
operator patches the outbound caller with the original inbound channel with
an AMI redirect of both the inbound channel and the outbound channel to a
meetme through context qvmeetme.  The operator channel is disconnected.

Note that we use the inbound channel's uniqueid as the unique meetme conf
#.