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

[reviewboard at asterisk.org]

> On 2010-11-17 17:27:37, David Vossel wrote:
> > /branches/1.8/main/channel.c, lines 3651-3656
> > <https://reviewboard.asterisk.org/r/1013/diff/1/?file=12922#file12922line3651>
> >
> >     Instead of creating a new control frame type for this exception, could we only queue the AST_CONTROL_HANGUP frame when softhangup is set to something that will actually result in a hangup.   Otherwise the if hangup is only equal to ASYNC_GOTO or UNBRIDGE we return NULL until those flags get cleared or a real hangup occurs.

The users of ASYNCGOTO, TIMEOUT, and UNBRIDGE clear the flags when they regain control to restructure the channels.  The TIMEOUT flag may or may not result in a hangup (usually if there is a 'T' extension present).  The TIMEOUT flag is a variation of ASYNCGOTO.

The new control frame is needed to distinguish between breaking the bridge and an actual hangup request.  In the TIMEOUT flag case, we should mark the end-of-Q if the timeout actually causes a hangup.  The end-of-Q marker is a weak hangup request that may actually result in a hangup.


- rmudgett


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


On 2010-11-16 16:32:25, rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1013/
> -----------------------------------------------------------
> 
> (Updated 2010-11-16 16:32:25)
> 
> 
> 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/20101117/57590188/attachment-0001.htm