[asterisk-bugs] [JIRA] (ASTERISK-22936) Deadlock during masquerade when a PJSIP channel attended transfers a 3+ party bridge to dialplan

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-22936:
----------------------------------------

I don't think this patch will work. You can't delay a masquerade. Failing to complete the fix up here will result in a masqueraded (zombie) channel with an active session. Anything using that session will be pointing to the Zombie channel, and - assuming they don't blow up in some spectacular fashion - have a high likelihood of simply failing.

Even if we assume that the task can be put at the front of the taskprocessor queue, any operation currently in flight will be operating on an invalid channel.

I only see two possibilities here:

# Fix the locking inversion between the task processor and the entity pushing the synchronous task. That is, you can't hold a channel lock when pushing a synchronous task.
# Go with a modified version of the patch, but assume that the session object has to be protected as well.
                
> Deadlock during masquerade when a PJSIP channel attended transfers a 3+ party bridge to dialplan
> ------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-22936
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22936
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip, Resources/res_pjsip_refer
>    Affects Versions: SVN, 12.0.0-beta2, 12.0.0
>         Environment: Ubuntu 13.10 64-bit
>            Reporter: Jonathan Rose
>            Severity: Critical
>         Attachments: lockdata.txt, pjsip_masquerade_fixup_blocked.diff
>
>
> If a PJSIP channel attended transfers a three-way call to dialplan (as opposed to another bridge), Asterisk will attempt to masquerade swap a local channel with the transferer's channel that is currently in the dial plan. I've tracked this to a sticking point in ast_do_masquerade. An attempt to lock the channels container never returns.
> I tried a similar transfer scenario with chan_sip and that worked fine, so it seems likely that we are breaking some (possibly unwritten) rules when issuing ast_bridge_transfer_attended from res_pjsip_refer.c
> I've marked this issue as critical since this bug can easily be triggered by any PJSIP line with the ability to do attended transfers and once it has happened Asterisk becomes less than usable since the channels container lock is stuck. Yay masquerades.
> Steps for reproduction:
> * Start a three way call.  At least one of the three channels must be a PJSIP line.
> * Perform a SIP attended transfer from the PJSIP line to an extension that will linger in the dialplan.  Answer to Wait(20) works just fine.
> * Complete the transfer. The transfer will fail and the channels lock will be stuck preventing any new channels from being made and preventing
>   old channels from... doing lots of stuff.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira