[asterisk-bugs] [Asterisk 0018516]: SIP REFER transfers do not work

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18516 
====================================================================== 
Reported By:                kkm
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18516
Category:                   Channels/chan_sip/Transfers
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.8.1.1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-12-21 22:24 CST
Last Modified:              2010-12-21 23:39 CST
====================================================================== 
Summary:                    SIP REFER transfers do not work
Description: 
SIP blind transfer does not work: Transferree does not enter the transfer
context.
====================================================================== 

---------------------------------------------------------------------- 
 (0129868) kkm (reporter) - 2010-12-21 23:39
 https://issues.asterisk.org/view.php?id=18516#c129868 
---------------------------------------------------------------------- 
I see the following fix in the trunk's pbx.c:4828

295867   rmudgett  } else if (c->_softhangup & AST_SOFTHANGUP_ASYNCGOTO)
{
295867   rmudgett    c->_softhangup &= ~AST_SOFTHANGUP_ASYNCGOTO;

which is praised down to the following changeset:

$ svn log -r295867
------------------------------------------------------------------------
r295867 | rmudgett | 2010-11-22 11:42:02 -0800 (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
https://issues.asterisk.org/view.php?id=16946
      (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 https://issues.asterisk.org/view.php?id=18171)
      Reported by: SantaFox
      (closes issue https://issues.asterisk.org/view.php?id=18185)
      Reported by: kwemheuer
      (closes issue https://issues.asterisk.org/view.php?id=18211)
      Reported by: zahir_koradia
      (closes issue https://issues.asterisk.org/view.php?id=18230)
      Reported by: vmarrone
      (closes issue https://issues.asterisk.org/view.php?id=18299)
      Reported by: mbrevda
      (closes issue https://issues.asterisk.org/view.php?id=18322)
      Reported by: nerbos

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

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