[asterisk-bugs] [Asterisk 0018230]: [regression] Redirect function (over console or AMI) is not work anymore

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18230 
====================================================================== 
Reported By:                vmarrone
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18230
Category:                   Channels/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.8.0 
JIRA:                       SWP-2489 
Regression:                 Yes 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-10-29 06:27 CDT
Last Modified:              2010-11-04 05:28 CDT
====================================================================== 
Summary:                    [regression] Redirect function (over console or AMI)
is not work anymore
Description: 
With Asterisk 1.8.0, after have Originated a call, and request by AMI or by
console the command redirect to another priority of the same context or
another context, extension and priority, the channel is "hangupped" by
Asterisk without errors.
In previous versions, when was requested the redirect, correctly the
channel was jumped to the extension or priority in the dialplan doing the
correct application.
====================================================================== 

---------------------------------------------------------------------- 
 (0128603) vmarrone (reporter) - 2010-11-04 05:28
 https://issues.asterisk.org/view.php?id=18230#c128603 
---------------------------------------------------------------------- 
Eureka!
I have test the patch at the issue 0018185 and the problem is solved!
Here the patch and th description:

The call is dropped when ast_queue_control is called in main/channel.c to
read the remaining frames. You can remove that call with this patch:

--- main/channel.c 2010-10-22 18:22:31.000000000 +0200
+++ main/channel.c 2010-10-22 21:49:44.669221930 +0200
@@ -3620,7 +3620,7 @@
                 * frame. */
- if (ast_check_hangup(chan)) {
- ast_queue_control(chan, AST_CONTROL_HANGUP);
- } else {
+// if (ast_check_hangup(chan)) {
+// ast_queue_control(chan, AST_CONTROL_HANGUP);
+// } else {
                        goto done;
- }
+// }
        }

How I have read in the comments near the code (channel.c: "...Instead of
just going to 'done' in the case of ast_check_hangup(), we instead need to
send the HANGUP frame so that it can mark the end of the read queue. 
If there are frames to be read, ast_queue_control will be called
repeatedly, but will only queue one hangup frame."), seams that HANGUP
frame is wrong interpreted. 
This patch solve this problem, but I don't understand why there is this
additional call at the ast_queue_control method. 
I think that it's need to add some further if-else condition, but I don't
know which is.
I hope to receive an answer soon.
Thanks at all. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-11-04 05:28 vmarrone       Note Added: 0128603                          
======================================================================