[asterisk-dev] [Code Review] Fix AMI redirect action with two channels failing to redirect both channels.

[Mark Michelson]

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



/branches/1.8/main/features.c
<https://reviewboard.asterisk.org/r/2243/#comment14318>

    Hm, should autoservice be used here to ensure that the channel does not build up a large frame queue while waiting for the flag to clear?


- Mark


On Dec. 12, 2012, 2:24 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2243/
> -----------------------------------------------------------
> 
> (Updated Dec. 12, 2012, 2:24 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> The AMI redirect action can fail to redirect two channels that are bridged together.  There is a race between the AMI thread redirecting the two channels and the bridge thread noticing that a channel is hungup from the redirects.
> 
> * Made the bridge wait for both channels to be redirected before exiting.
> 
> * Made the AMI redirect check that all required headers are present before proceeding with the redirection.
> 
> * Made the AMI redirect require that any supplied ExtraChannel exist before proceeding.  Previously the code fell back to a single channel redirect operation.
> 
> 
> This addresses bugs ASTERISK-18975 and ASTERISK-19948.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18975
>     https://issues.asterisk.org/jira/browse/ASTERISK-19948
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/include/asterisk/channel.h 377921 
>   /branches/1.8/main/features.c 377921 
>   /branches/1.8/main/manager.c 377921 
> 
> Diff: https://reviewboard.asterisk.org/r/2243/diff
> 
> 
> Testing
> -------
> 
> The redirect of both channels now succeeds.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121212/7bacc31b/attachment.htm>