[asterisk-dev] [Code Review] 4271: ARI: Allow interoperation of ASYNCGOTO and channels originated to Stasis()

Joshua Colp reviewboard at asterisk.org
Tue Dec 16 17:25:38 CST 2014


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


I think before accepting this as the solution we need to understand more about what is going on. I say this because ast_async_goto has logic which is supposed to handle this case:

        /* Channels in a bridge or running a PBX can be sent directly to the specified destination */
        if (ast_channel_is_bridged(chan) || ast_channel_pbx(chan)) {

So why in this case is the bridge in a state where we can't do an explicit goto? Is this check wrong?

- Joshua Colp


On Dec. 16, 2014, 8:41 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4271/
> -----------------------------------------------------------
> 
> (Updated Dec. 16, 2014, 8:41 p.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24591
>     https://issues.asterisk.org/jira/browse/ASTERISK-24591
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> When the AMI Redirect action is used with a channel bridged inside Stasis() and not running a pbx, the channel is hung up instead of proceeding to the desired location in dialplan. This change allows such channels to be Redirected properly by detecting the operation used by Redirect (ASYNCGOTO) and starting a pbx if necessary to allow the channel to execute dialplan at the desired location.
> 
> 
> Diffs
> -----
> 
>   branches/13/res/ari/resource_channels.c 429611 
>   branches/13/main/pbx.c 429611 
> 
> Diff: https://reviewboard.asterisk.org/r/4271/diff/
> 
> 
> Testing
> -------
> 
> Ran the test that found this bug and verified that it passed with the expected events. See review 4272 for the test in question.
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141216/7c9e760a/attachment-0001.html>


More information about the asterisk-dev mailing list