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

Mark Michelson reviewboard at asterisk.org
Tue Dec 16 17:07:16 CST 2014


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



branches/13/main/pbx.c
<https://reviewboard.asterisk.org/r/4271/#comment24488>

    I think the ast_channel_is_leaving_bridge() test here is too specific. The problem can happen on any code path that expects the channel to end up running dialplan after the fact.
    
    Simple example: Originate a channel into the Goto app. There's no bridge involved, but the expectation would be that the channel ends up running dialplan at the location pointed to by the Goto.
    
    Less stupid example: Originate a channel into the Dial() application with the 'G' option specified. Again, there's no bridge involved here, but it's expected that the channel will end up running dialplan at the specified location.
    
    So the test here for whether to start a PBX on the channel should focus instead on some other property (or properties) of the channel than whether it was involved in a bridge. I'm not sure what ast_channel_context(), ast_channel_exten(), or ast_channel_priority() return for originated channels normally, but if the channel has been in any way redirected, I'd expect these to be filled in with valid values.
    
    The other thing to double-check (possibly through an assertion) is that the originated channel doesn't have a PBX on it already. If it does, there's no need to start a new PBX on the channel.



branches/13/res/ari/resource_channels.c
<https://reviewboard.asterisk.org/r/4271/#comment24490>

    Same comment from pbx_outgoing_app() applies here. While you don't have the entire gamut of possible applications to originate a caller into in this case, you could still have the case where the originated channel enters Stasis, and the channel is then continued into the dialplan. There's no bridge involved, but the channel should run dialplan.



branches/13/res/ari/resource_channels.c
<https://reviewboard.asterisk.org/r/4271/#comment24489>

    Got some red here.


- Mark Michelson


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/64c4801a/attachment.html>


More information about the asterisk-dev mailing list