[Home]

Summary:ASTERISK-16838: Channel redirect doesn't work
Reporter:Dmitry Blokhin (santafox)Labels:
Date Opened:2010-10-20 03:57:48Date Closed:2010-11-22 13:42:05.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) issue_18171_full_log.rar
Description:When I'm trying to make a blind transfer (via console CHANNEL REDIRECT command, or by my Snom phone's "Transfer" button), new extension doesn't even made a ring, and both sides (caller and callee) are hung up.

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

For example, customer calls to SIP 210 peer:
   -- Called 210
   -- SIP/210-0000000a is ringing
   -- SIP/210-0000000a is ringing
   -- SIP/210-0000000a is ringing
   -- SIP/210-0000000a is ringing
   -- SIP/210-0000000a answered DAHDI/i1/9856434327-5

Then 210 peer presses "Transfer" button and calls for 213 extension.

   -- Started music on hold, class 'default', on DAHDI/i1/9856434327-5
   -- Stopped music on hold on DAHDI/i1/9856434327-5
 == Spawn extension (local, 213, 1) exited non-zero on 'DAHDI/i1/9856434327-5' in macro 'stdexten'
 == Spawn extension (local, 213, 1) exited non-zero on 'DAHDI/i1/9856434327-5'
[Oct 20 12:45:56] DEBUG[18276]: sig_pri.c:5689 sig_pri_hangup: sig_pri_hangup 1
[Oct 20 12:45:56] DEBUG[18276]: sig_pri.c:5735 sig_pri_hangup: Not yet hungup...  Calling hangup once with icause, and clearing call
   -- Hungup 'DAHDI/i1/9856434327-5'
Comments:By: Stefan Schmidt (schmidts) 2010-10-20 05:30:43

We require a complete debug log to help triage the issue.

This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue:

http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt


thanks!
By: Dmitry Blokhin (santafox) 2010-10-20 05:44:49

Uploaded log file. Look for call from DAHDI/i1/9856434327 to SIP/210 and then blind transfer to SIP/213.
By: Stefan Schmidt (schmidts) 2010-10-20 05:56:41

i change this to privat cause there are some personal information like callerids in the log.
By: Stefan Schmidt (schmidts) 2010-10-21 02:56:13

i can reproduce this also in 1.6.2 and i think the problem is the softhangup part in the async_goto if the channel is linked to pbx.
http://www.asterisk.org/doxygen/asterisk1.6.2/pbx_8c.html#e0ba2eb966a9e3376de61d30513f7302

EDIT: i can reproduce this with channel redirect command from cli.


By: Clod Patry (junky) 2010-11-17 00:31:31.000-0600

Just as a note, I tried Richard's patch from the reviewboard as so far so good,the redirect works like before.

https://reviewboard.asterisk.org/r/1013/
By: Digium Subversion (svnbot) 2010-11-22 12:46:28.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:28.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:12.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:04.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