[asterisk-dev] [Code Review] The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.

reviewboard at asterisk.org reviewboard at asterisk.org
Tue Nov 16 16:32:25 CST 2010


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1013/
-----------------------------------------------------------

Review request for Asterisk Developers, Russell Bryant, Terry Wilson, and David Vossel.


Summary
-------

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 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, 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.  


This addresses bugs 18171, 18185, 18192, 18211, and 18230.
    https://issues.asterisk.org/view.php?id=18171
    https://issues.asterisk.org/view.php?id=18185
    https://issues.asterisk.org/view.php?id=18192
    https://issues.asterisk.org/view.php?id=18211
    https://issues.asterisk.org/view.php?id=18230


Diffs
-----

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

Diff: https://reviewboard.asterisk.org/r/1013/diff


Testing
-------

The channel redirect command no longer causes the call leg of party A to be hungup.


Thanks,

rmudgett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20101116/a830db34/attachment-0001.htm 


More information about the asterisk-dev mailing list