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

Richard Mudgett updated ASTERISK-26284:
---------------------------------------

    Description: 
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.

  was:
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.  A third scenario would involve a hybrid of scenario 1 and 2.


> 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
>
> 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)