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

[Matt Jordan (JIRA)]

Matt Jordan created ASTERISK-22948:
--------------------------------------

             Summary: Deadlock during masquerade when a PJSIP channel attended transfers a 3+ party bridge to dialplan
                 Key: ASTERISK-22948
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22948
             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


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