[asterisk-bugs] [JIRA] Issue Comment Edited: (ASTERISK-18975) Manager Redirect action on bridged channel pair causes intermittent hangup on second channel

[trol (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-18975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194814#comment-194814 ] 

trol edited comment on ASTERISK-18975 at 7/12/12 12:41 PM:
-----------------------------------------------------------

I am also having this issue on 1.8.7.1. I was using this feature on 1.2 for years, without any problem. Redirect with extra channel is the only way to send a bridged call to a meet me room, as far as I know.
Any development or workaround?

Thanks

      was (Author: trol):
    I am also having this issue on 1.8.7.1. I was using this feature on 1.2 for years, without any problem. Redirect with extra channel is the only way to send a bridged call to a meet me room, as far as I know.
Any development or workaround?
  
> Manager Redirect action on bridged channel pair causes intermittent hangup on second channel
> --------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-18975
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-18975
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Channels
>    Affects Versions: 1.8.7.1
>            Reporter: Ben Klang
>            Severity: Minor
>         Attachments: broken.log, working.log
>
>
> We have an application where two channels are first bridged and then split back out, with the option of re-bridging.  When the split occurs, we use an AMI Redirect action with both channels (Channel and ExtraChannel) filled out so both legs go somewhere in the dialplan.  When this happens, approximately 50% of the time, the ExtraChannel will be hung up.
> Kevin Fleming was very helpful on IRC today working on the possible cause.  His last comment on the issue was:
> kpfleming: so... theorizing here: if the Redirect action is creating a new PBX thread for the second channel to use after it has been pulled out of the bridge, and somehow that thread ends up on the second channel before the original thread has caused the masquerade to occur, things will get very messy
> I have attached two DEBUG logs illustrating the issue.  In the first example, the app works as expected, where both channels are split and continue in the dialplan.  In the second example, the second channel (SIP/grant-00000019) *should* be masqueraded, but is instead hung up.
> This feels like a race condition where, somehow, the AST_FLAG_ZOMBIE is getting set on the secondary channel, when it should not.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira