[asterisk-bugs] [JIRA] (ASTERISK-27911) Deadlock, likely when delegating calls from queue with Redirect

Joshua Colp (JIRA) noreply at issues.asterisk.org
Tue Jun 12 07:25:54 CDT 2018


     [ https://issues.asterisk.org/jira/browse/ASTERISK-27911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp updated ASTERISK-27911:
-----------------------------------

    Assignee: Örn Arnarson  (was: Unassigned)
      Status: Waiting for Feedback  (was: Triage)

> Deadlock, likely when delegating calls from queue with Redirect
> ---------------------------------------------------------------
>
>                 Key: ASTERISK-27911
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27911
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 13.1.0
>         Environment: Ubuntu 16.04.4 LTS, running on VMware
>            Reporter: Örn Arnarson
>            Assignee: Örn Arnarson
>            Severity: Critical
>         Attachments: backtrace-threads.txt, backtrace-threads.txt, core-show-locks.txt, core-show-threads.txt
>
>
> We have a PBX running with approx. 16 concurrent calls usually. Not a call center, so a fair number of calls that are producing the calls.
> We are experiencing several deadlocks per week with this PBX, likely in Chan_SIP, as the PBX stops processing new INVITES, yet the CLI seems to be working and the only way to stop is by using kill -9.
> We have a suspicion that this issue is caused when "picking up" calls from a call queue using FOP2, which actually uses Redirect via AMI with an auto-answer SIP header added. This may or may not happen also when we use Originate via AMI calling the PickupChan application. We haven't been able to confirm that.
> Asterisk was installed from the Ubuntu packaging system. We believe we have a recorded incident with backtraces and locks after having compiled the ubuntu package with the unoptimized and debug threads flags set. We are not certain though, as this rendered Asterisk too slow for production and we were dropping calls, so maybe it was an unrelated issue. But likely it was the same deadlock.
> The reason we haven't upgraded to a newer version as of yet is that we are running from an Ubuntu package and would prefer to keep it that way if possible, but of course are willing to update if it turns out that this is a known and fixed bug.



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



More information about the asterisk-bugs mailing list