[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-19 22:36 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?
====================================================================== 

---------------------------------------------------------------------- 
 (0109317) escape2mtns (reporter) - 2009-08-19 22:36
 https://issues.asterisk.org/view.php?id=14660#c109317 
---------------------------------------------------------------------- 
That first redirect of both channels to hold music works beautifully!

But when I perform the last step of my attended transfer (using AMI) where
two channels from separate calls are both redirected together (using
redirect with extrachannel) into a meetme room, I get a Segmentation fault.
 That's new.

I tried connecting an inbound call to the agent phone and redirecting both
to hold music and then redirecting both of those back to a meetme (take off
hold) and put back on hold and take off hold (redirects happening each
time) and there was no issue... no matter how many times I did that.

I then tried placing two outbound calls where I place the first call and
then it goes on hold via redirects... then I place a second call and try to
bridge the two outbound channels together in a meetme room using redirect
and I get the same Segmentation fault.   

Finally, I tried just placing an outbound call and putting it on hold with
the redirects.  I got the segmentation fault right there.  What I'm doing
is redirecting the outbound channel of a Local channel transfer.  So when
the call goes out, there are two channels ... one from the meetme room and
one to the outside caller... that make up that leg up the call.  After the
initial call, we're redirecting that outside caller channel.  Without the
patch it works functionally (ignoring cdrs).  With the patch I get the
segmentation fault.

/usr/sbin/safe_asterisk: line 125:  4296 Segmentation fault      (core
dumped) nice -n $PRIORITY ${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS}
>&/dev/${TTY} < /dev/${TTY}
Asterisk ended with exit status 139
Asterisk exited on signal 11.
Automatically restarting Asterisk.
mpg123: no process killed 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-19 22:36 escape2mtns    Note Added: 0109317                          
======================================================================