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

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-18975:
----------------------------------------

A potentially related issue was resolved in 1.8.15.0.  You may want to try reproducing the problem using that version (or later) to see if your issue still occurs.

If it does, please note in the comments here and I'll unlink the issue.

> 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