[asterisk-bugs] [JIRA] (ASTERISK-26284) pjsip: Deadlock with suspend + masquerade (Alternate scenarios)

[Richard Mudgett (JIRA)]

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

Richard Mudgett commented on ASTERISK-26284:
--------------------------------------------

[~gjoseph] pointed out that scenario 1 as described cannot deadlock since the B and E parties will have their own unique {{pjsip/outsess/<endpoint>}} serializers since they are outgoing call legs and thus there cannot be a deadlock between two call pickup actions.  The other two scenarios can happen because the channels involved in the masquerade are incoming.

The deadlock window can be minimized by changing how the serializers are suspended.  Currently when a masquerade tries to suspend a serializer it pushes a suspend task onto the *end* of the serializer's task queue.  If that queue happens to contain a pending task that needs to do a masquerade then the deadlock will happen.  However, if the serializer suspension is made a priority task that will be the next task to execute then it will suspend the serializer earlier and make the window of opportunity smaller.  This cannot close the window entirely because if the serializer's *current* task is also trying to do a masquerade you will still deadlock.

> pjsip: Deadlock with suspend + masquerade (Alternate scenarios)
> ---------------------------------------------------------------
>
>                 Key: ASTERISK-26284
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26284
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip, Resources/res_pjsip
>    Affects Versions: 13.10.0
>            Reporter: Richard Mudgett
>            Assignee: George Joseph
>
> This issue describes a couple unlikely scenarios that can deadlock PJSIP channels similar to the deadlock seen in ASTERISK-26145.  For the moment these scenarios are theoretical for busy systems.
> Scenario 1 Call pickup:
> # A calls B
> # While B is ringing C does a channel driver call pickup (features pickupexten option)
> # At the same time another call pickup with D, E, and F do the same thing as A, B, and C respectively.
> Call pickups currently require a masquerade to implement the pickup.  Thus, if C and E are handled by serializer S1 while B and F are handled by serializer S2 then a deadlock will happen if the C and F INVITE processing tasks are queued in the serializers before either is processed.
> A simple fix for scenario 1 is to make call_pickup_incoming_request() package the code that calls ast_pickup_call() into a routine and push it to a serializer not used for handling calls.  The pjsip/default serializers are handy for this since they are not used for call handling any more.
> Scenerio 2 Remote attended transfer:
> # B calls C on Asterisk A1
> # B puts C on hold to call an application (say voicemail) on Asterisk A2
> # B initiates the transfer of C to the remote application
> # A1 sends INVITE (D) with Replaces header to A2
> # At the same time another remote attended transfer with E, F, and G doing the same thing as B, C, and D respectively.
> A remote attended transfer of a call to an application requires a masquerade to implement.  Thus, if B and the INVITE (G) are handled by serializer S1 on A2 while E and INVITE (D) are handled by serializer S2 on A2 then a deadlock will happen if the D and G INVITEs are queued in the serializers before either is processed.
> A similar fix for scenario 2 is needed in refer_incoming_invite_request().  A third scenario would involve a hybrid of scenario 1 and 2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)