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

Jeremy Betts (JIRA) noreply at issues.asterisk.org
Tue Oct 23 16:49:18 CDT 2012


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

Jeremy Betts commented on ASTERISK-18975:
-----------------------------------------

This issue still exists in 1.8.15.0.
                
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list