[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:all-tabpanel ]

Matt Jordan reopened ASTERISK-22936:
------------------------------------

    
> 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