[Home]

Summary:ASTERISK-16891: [regression] Redirect function (over console or AMI) does not work anymore
Reporter:Vincenzo Marrone (vmarrone)Labels:
Date Opened:2010-10-29 06:27:17Date Closed:2011-01-12 09:01:21.000-0600
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Channels/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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.

****** ADDITIONAL INFORMATION ******

Example for reproduce the bug with use of AMI, but is the same with console.

extensions.conf

[test]
exten => s,1,Ringing()
exten => s,2,Wait(1000)
exten => s,3,Goto(2)
exten => s,4,Answer()
exten => s,5,Goto(2)
exten => s,6,Playback(demo-congrats)
exten => s,8,Goto(2)

(BY AMI:)

Action: Originate
Channel: SIP/1003
CallerID: 123456
Context: test
Exten: s
Priority: 2
Async: true


(The sip phone answer)

(BY AMI:)

Action: Redirect
Channel: SIP/1003-00000001
Context: test
Exten: s
Priority: 6

Here the difference between 1.6.2.2 and 1.8.0 in cli (debug mode):

1.6.2.2 ----------------WORK----------------------

[Oct 28 18:11:30] DEBUG[16762]: manager.c:2993 process_message: Manager received command 'Redirect'                                              
[Oct 28 18:11:30] DEBUG[16762]: channel.c:1634 ast_softhangup_nolock: Soft-Hanging up channel 'SIP/1003-00000001'                                
[Oct 28 18:11:30] DEBUG[16810]: pbx.c:4297 __ast_pbx_run: Spawn extension (test,s,6) exited non-zero on 'SIP/1003-00000001'              
 == Spawn extension (test, s, 6) exited non-zero on 'SIP/1003-00000001'                                                                  
[Oct 28 18:11:30] DEBUG[16810]: pbx.c:3687 pbx_extension_helper: Launching 'Playback'                                                            
   -- Executing [s@test:6] Playback("SIP/1003-00000001", "demo-congrats") in new stack                                                  
[Oct 28 18:11:30] DEBUG[16810]: channel.c:3695 set_format: Set channel SIP/1003-00000001 to write format gsm                                      
[Oct 28 18:11:30] DEBUG[16810]: rtp.c:3844 ast_rtp_write: Ooh, format changed from unknown to ulaw                                                
[Oct 28 18:11:30] DEBUG[16810]: rtp.c:3870 ast_rtp_write: Created smoother: format: 4 ms: 20 len: 160                                            
[Oct 28 18:11:30] DEBUG[16810]: channel.c:2405 ast_settimeout: Scheduling timer at (50 requested / 50 actual) timer ticks per second              
   -- <SIP/1003-00000001> Playing 'demo-congrats.gsm' (language 'en')


1.8.0 ----------------NOT WORK----------------------

[Oct 28 17:14:42] DEBUG[7029]: manager.c:4481 process_message: Running action 'Redirect'                                                          
[Oct 28 17:14:42] DEBUG[7029]: channel.c:2576 ast_softhangup_nolock: Soft-Hanging up channel 'SIP/1003-00000018'                                  
[Oct 28 17:14:42] DEBUG[7349]: pbx.c:4724 __ast_pbx_run: Spawn extension (test,s,4) exited non-zero on 'SIP/1003-00000001'                
 == Spawn extension (test, s, 6) exited non-zero on 'SIP/1003-00000001'                                                                  
[Oct 28 17:14:42] DEBUG[7349]: channel.c:2576 ast_softhangup_nolock: Soft-Hanging up channel 'SIP/1003-00000001'                                  
[Oct 28 17:14:42] DEBUG[7349]: channel.c:2704 ast_hangup: Hanging up channel 'SIP/1003-00000001'                                                  
[Oct 28 17:14:42] DEBUG[7349]: chan_sip.c:5807 sip_hangup: Hangup call SIP/1003-00000001, SIP callid 6328710776a3d01b3334bf04336dbf7b@XXX.XXX.XXX.XXX:5060                                                                                                                                          
[Oct 28 17:14:42] DEBUG[7349]: res_rtp_asterisk.c:2391 ast_rtp_remote_address_set: Setting RTCP address on RTP instance '0xd6e41d0'              

Comments:By: Leif Madsen (lmadsen) 2010-11-02 09:09:26

First thing I see different is here:

WORK:

[Oct 28 18:11:30] DEBUG[16810]: pbx.c:4297 __ast_pbx_run: Spawn extension (test,s,6) exited non-zero on 'SIP/1003-00000001'
 == Spawn extension (test, s, 6) exited non-zero on 'SIP/1003-00000001'

NOT WORKING:

[Oct 28 17:14:42] DEBUG[7349]: pbx.c:4724 __ast_pbx_run: Spawn extension (test,s,4) exited non-zero on 'SIP/1003-00000001'
 == Spawn extension (test, s, 6) exited non-zero on 'SIP/1003-00000001'


The NOT WORKING part shows test,s,4 for some reason. Not too sure why that happens, or if it's just an incorrect DEBUG message?
By: Vincenzo Marrone (vmarrone) 2010-11-03 03:23:48

Is just an incorrect debug message.. I have made many test with different priority, and I have mix the results for explain reasons, sorry for the mistake, but is sure that don't work! I have worked much with Asterisk and the AMI... Anyway, if you try the example You can verify this.
Thanks for the answer!
By: jpgmot (jpgmot) 2010-11-04 02:29:55

Hi,

I've the same problem, my scripts works fine with asterisk 1.6.2.13, but with 1.8, the channel hangup after a redirect, but I've a Redirect Success returned, and an Event: HangUp Cause: 16

Asterisk Call Manager/1.1
Response: Success
Message: Authentication accepted

Event: FullyBooted
Privilege: system,all
Status: Fully Booted

Response: Success
Message: Redirect successful

Event: Hangup
Privilege: call,all
Channel: SIP/ovh-00000000
Uniqueid: 1288856497.0
CallerIDNum: XXXXXXXXXX
CallerIDName: 67
Cause: 16
Cause-txt: Normal Clearing  

Thanks
By: Vincenzo Marrone (vmarrone) 2010-11-04 05:28:54

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.
By: Digium Subversion (svnbot) 2010-11-22 12:46:40.000-0600

Repository: asterisk
Revision: 295790

U   branches/1.4/apps/app_macro.c
U   branches/1.4/include/asterisk/channel.h
U   branches/1.4/include/asterisk/frame.h
U   branches/1.4/main/channel.c
U   branches/1.4/main/pbx.c

------------------------------------------------------------------------
r295790 | rmudgett | 2010-11-22 12:46:27 -0600 (Mon, 22 Nov 2010) | 46 lines

The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.

To recreate the problem:
1) Party A calls Party B
2) Invoke CLI "channel redirect" command to redirect channel call leg
associated with A.
3) All associated channels are hung up.

Note that if the CLI command were done on the channel call leg associated
with B it works.

This regression was a result of the fix for issue ASTERISK-15731
(https://reviewboard.asterisk.org/r/740/).

The regression affects all features that use an async goto to execute the
dialplan because of an external event: Channel redirect, AMI redirect, SIP
REFER, and FAX detection.

The struct ast_channel._softhangup code is a mess.  The variable is used
for several purposes that do not necessarily result in the call being hung
up.  I have added doxygen comments to describe how the various _softhangup
bits are used.  I have corrected all the places where the variable was
tested in a non-bit oriented manner.

The primary fix is the new AST_CONTROL_END_OF_Q frame.  It acts as a weak
hangup request so the soft hangup requests that do not normally result in
a hangup do not hangup.

JIRA SWP-2470
JIRA SWP-2489

(closes issue ASTERISK-16838)
Reported by: SantaFox
(closes issue ASTERISK-16847)
Reported by: kwemheuer
(closes issue ASTERISK-16873)
Reported by: zahir_koradia
(closes issue ASTERISK-16891)
Reported by: vmarrone
(closes issue ASTERISK-16950)
Reported by: mbrevda
(closes issue ASTERISK-16972)
Reported by: nerbos

Review: https://reviewboard.asterisk.org/r/1013/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=295790
By: Digium Subversion (svnbot) 2010-11-22 13:28:35.000-0600

Repository: asterisk
Revision: 295843

_U  branches/1.6.2/
U   branches/1.6.2/apps/app_macro.c
U   branches/1.6.2/include/asterisk/channel.h
U   branches/1.6.2/include/asterisk/frame.h
U   branches/1.6.2/main/channel.c
U   branches/1.6.2/main/pbx.c

------------------------------------------------------------------------
r295843 | rmudgett | 2010-11-22 13:28:27 -0600 (Mon, 22 Nov 2010) | 53 lines

Merged revisions 295790 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines
 
 The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.
 
 To recreate the problem:
 1) Party A calls Party B
 2) Invoke CLI "channel redirect" command to redirect channel call leg
 associated with A.
 3) All associated channels are hung up.
 
 Note that if the CLI command were done on the channel call leg associated
 with B it works.
 
 This regression was a result of the fix for issue ASTERISK-15731
 (https://reviewboard.asterisk.org/r/740/).
 
 The regression affects all features that use an async goto to execute the
 dialplan because of an external event: Channel redirect, AMI redirect, SIP
 REFER, and FAX detection.
 
 The struct ast_channel._softhangup code is a mess.  The variable is used
 for several purposes that do not necessarily result in the call being hung
 up.  I have added doxygen comments to describe how the various _softhangup
 bits are used.  I have corrected all the places where the variable was
 tested in a non-bit oriented manner.
 
 The primary fix is the new AST_CONTROL_END_OF_Q frame.  It acts as a weak
 hangup request so the soft hangup requests that do not normally result in
 a hangup do not hangup.
 
 JIRA SWP-2470
 JIRA SWP-2489
 
 (closes issue ASTERISK-16838)
 Reported by: SantaFox
 (closes issue ASTERISK-16847)
 Reported by: kwemheuer
 (closes issue ASTERISK-16873)
 Reported by: zahir_koradia
 (closes issue ASTERISK-16891)
 Reported by: vmarrone
 (closes issue ASTERISK-16950)
 Reported by: mbrevda
 (closes issue ASTERISK-16972)
 Reported by: nerbos
 
 Review: https://reviewboard.asterisk.org/r/1013/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=295843
By: Digium Subversion (svnbot) 2010-11-22 13:36:23.000-0600

Repository: asterisk
Revision: 295866

_U  branches/1.8/
U   branches/1.8/apps/app_macro.c
U   branches/1.8/include/asterisk/channel.h
U   branches/1.8/include/asterisk/frame.h
U   branches/1.8/main/channel.c
U   branches/1.8/main/pbx.c

------------------------------------------------------------------------
r295866 | rmudgett | 2010-11-22 13:36:11 -0600 (Mon, 22 Nov 2010) | 60 lines

Merged revisions 295843 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
 r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines
 
 Merged revisions 295790 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines
   
   The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.
   
   To recreate the problem:
   1) Party A calls Party B
   2) Invoke CLI "channel redirect" command to redirect channel call leg
   associated with A.
   3) All associated channels are hung up.
   
   Note that if the CLI command were done on the channel call leg associated
   with B it works.
   
   This regression was a result of the fix for issue ASTERISK-15731
   (https://reviewboard.asterisk.org/r/740/).
   
   The regression affects all features that use an async goto to execute the
   dialplan because of an external event: Channel redirect, AMI redirect, SIP
   REFER, and FAX detection.
   
   The struct ast_channel._softhangup code is a mess.  The variable is used
   for several purposes that do not necessarily result in the call being hung
   up.  I have added doxygen comments to describe how the various _softhangup
   bits are used.  I have corrected all the places where the variable was
   tested in a non-bit oriented manner.
   
   The primary fix is the new AST_CONTROL_END_OF_Q frame.  It acts as a weak
   hangup request so the soft hangup requests that do not normally result in
   a hangup do not hangup.
   
   JIRA SWP-2470
   JIRA SWP-2489
   
   (closes issue ASTERISK-16838)
   Reported by: SantaFox
   (closes issue ASTERISK-16847)
   Reported by: kwemheuer
   (closes issue ASTERISK-16873)
   Reported by: zahir_koradia
   (closes issue ASTERISK-16891)
   Reported by: vmarrone
   (closes issue ASTERISK-16950)
   Reported by: mbrevda
   (closes issue ASTERISK-16972)
   Reported by: nerbos
   
   Review: https://reviewboard.asterisk.org/r/1013/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=295866
By: Digium Subversion (svnbot) 2010-11-22 13:42:11.000-0600

Repository: asterisk
Revision: 295867

_U  trunk/
U   trunk/apps/app_macro.c
U   trunk/include/asterisk/channel.h
U   trunk/include/asterisk/frame.h
U   trunk/main/channel.c
U   trunk/main/pbx.c

------------------------------------------------------------------------
r295867 | rmudgett | 2010-11-22 13:42:03 -0600 (Mon, 22 Nov 2010) | 67 lines

Merged revisions 295866 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r295866 | rmudgett | 2010-11-22 13:36:10 -0600 (Mon, 22 Nov 2010) | 60 lines
 
 Merged revisions 295843 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ................
   r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines
   
   Merged revisions 295790 via svnmerge from
   https://origsvn.digium.com/svn/asterisk/branches/1.4
   
   ........
     r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines
     
     The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.
     
     To recreate the problem:
     1) Party A calls Party B
     2) Invoke CLI "channel redirect" command to redirect channel call leg
     associated with A.
     3) All associated channels are hung up.
     
     Note that if the CLI command were done on the channel call leg associated
     with B it works.
     
     This regression was a result of the fix for issue ASTERISK-15731
     (https://reviewboard.asterisk.org/r/740/).
     
     The regression affects all features that use an async goto to execute the
     dialplan because of an external event: Channel redirect, AMI redirect, SIP
     REFER, and FAX detection.
     
     The struct ast_channel._softhangup code is a mess.  The variable is used
     for several purposes that do not necessarily result in the call being hung
     up.  I have added doxygen comments to describe how the various _softhangup
     bits are used.  I have corrected all the places where the variable was
     tested in a non-bit oriented manner.
     
     The primary fix is the new AST_CONTROL_END_OF_Q frame.  It acts as a weak
     hangup request so the soft hangup requests that do not normally result in
     a hangup do not hangup.
     
     JIRA SWP-2470
     JIRA SWP-2489
     
     (closes issue ASTERISK-16838)
     Reported by: SantaFox
     (closes issue ASTERISK-16847)
     Reported by: kwemheuer
     (closes issue ASTERISK-16873)
     Reported by: zahir_koradia
     (closes issue ASTERISK-16891)
     Reported by: vmarrone
     (closes issue ASTERISK-16950)
     Reported by: mbrevda
     (closes issue ASTERISK-16972)
     Reported by: nerbos
     
     Review: https://reviewboard.asterisk.org/r/1013/
   ........
 ................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=295867