[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:                     ready for testing
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-21 23:18 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?
====================================================================== 

---------------------------------------------------------------------- 
 (0109501) escape2mtns (reporter) - 2009-08-21 23:18
 https://issues.asterisk.org/view.php?id=14660#c109501 
---------------------------------------------------------------------- 
Thanks!  That last patch did the trick.  There were no crashes and the
cdr's appear to be a much better representation of what occurred.  We'll do
more testing next week but here's what I got from the test I ran:

Inbound call from 1111111111 to 22222222222 is routed to queue 777 and
answered by sip/172.  

After 20 seconds both channels are redirected to music on hold.  

At 50 seconds, sip/172 is redirected to a meetme room and we originate an
outbound call from that same meetme room.

At 60 seconds both the original inbound channel and the outbound channel
are redirected to a meetme room as their calls are patched and sip/172
disconnects.

They stay patched for about a minute and 10 seconds or so.

"calldate";"clid";"src";"dst";"dcontext";"channel";"dstchannel";"lastapp";"lastdata";"duration";"billsec";"disposition";"amaflags";"accountcode";"uniqueid";"userfield";"agent";"queue_duration"
"2009-08-21 23:41:31";"\"CALLER NAME \"
<1111111111>";"1111111111";"777";"ext-queues";"SIP/SIP1-b7d47728";"SIP/172-09a0aa00";"AGI";"VERBOSE";"21";"21";"ANSWERED";"3";"2222222222";"1250912491.42";"3";"172";"2"
"2009-08-21 23:41:52";"\"CALLER NAME \"
<1111111111>";"1111111111";"777";"from-internal";"SIP/172-09a0aa00";"SIP/172-09a0aa00";"MusicOnHold";;"30";"30";"ANSWERED";"3";;"1250912491.44";"3";;"0"
"2009-08-21 23:41:52";"\"SCHURKE ERIC K \"
<1111111111>";"1111111111";"777";"ext-queues";"SIP/SIP1-b7d47728";"SIP/172-09a0aa00";"MusicOnHold";;"40";"40";"ANSWERED";"3";"2222222222";"1250912491.42";"3";;"0"
"2009-08-21
23:42:22";"2222222222";"2222222222";"3333333333";"from-internal";"Local/125091249142 at qvcallpickup-ba5b,1";"SIP/SIP1-b7d6dc08";"ResetCDR";"vw";"10";"8";"ANSWERED";"3";"2222222222";"1250912542.63";"3";"172";"0"
"2009-08-21
23:42:22";"2222222222";"2222222222";"125091249142";"qvcallpickup";"Local/125091249142 at qvcallpickup-ba5b,2";;"MeetMe";"125091249142|1dFqx";"10";"10";"ANSWERED";"3";"2222222222";"1250912542.64";;"172";"0"
"2009-08-21
23:42:22";;;"s";"default";"DAHDI/pseudo-56698133";;;;"11";"0";"NO
ANSWER";"3";;"1250912542.65";;;"0"
"2009-08-21 23:42:22";"\"CALLER NAME \"
<1111111111>";"1111111111";"125091249142";"qvpickup";"SIP/172-09a0aa00";"SIP/172-09a0aa00";"MeetMe";"125091249142|1dFqAx";"11";"11";"ANSWERED";"2";;"1250912512.46";"3";;"0"
"2009-08-21 23:42:32";"\"CALLER NAME \"
<1111111111>";"1111111111";"125091249142";"qvmeetme";"SIP/SIP1-b7d47728";"SIP/172-09a0aa00";"MeetMe";"125091249142|1dFqAx";"70";"70";"ANSWERED";"2";"2222222222";"1250912491.42";"3";;"0"


Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-21 23:18 escape2mtns    Note Added: 0109501                          
======================================================================