[asterisk-dev] 1.8 SIP deadlock on transfer using REFER

[Jonathan Thurman]

On Mon, Dec 20, 2010 at 8:56 AM, Russell Bryant <russell at digium.com> wrote:
> On Sun, 2010-12-19 at 14:54 -0800, Jonathan Thurman wrote:
>> I started to look at what changed between 1.6.2 and 1.8 in that
>> section of the code, and it looks like this is related to the
>> processing of parking.  Specifically, the function used to identify if
>> the blind-transfer extension is a valid parking lot number.  Within
>> that function (main/features.c: ast_parking_ext_valid) there is a call
>> to pbx_find_extension which then calls ast_autoservice_stop on the
>> channel and Deadlock!
>>
>> From reading through other code sections, it doesn't seem necessary to
>> pass the channel information to pbx_find_extension when looking to see
>> if an extension is a valid parking lot pilot. Setting the channel to
>> NULL on the call resolves the deadlock, and I have uploaded a patch
>> for testing, and would like some feedback if this satisfies the issue,
>> or if I should keep looking for another area for deadlock avoidance.
>
> That fix is probably fine for yours (and most) installations.  However,
> we won't be able to merge that as the final solution.

That's what I was thinking, as this doesn't "fix" the problem but avoids it...

> Channel autoservice is required when doing any sort of dialplan lookup
> because it may require some sort of lookup to a database and/or over a
> network to accomplish.  Since these operations may block for some period
> of time, we must ensure that the channel is still being serviced.

This is our use case, as the dialplan lookup hits and ODBC connection.
 The problem is the exact opposite thing actually happens without this
patch.  All SIP channels stop being serviced.  The lock done by the
autoservice is fine, but when ast_autoservice_stop is called, all SIP
traffic hangs while autoservice "waits for the list to rebuild"
(main/autoservice.c line ~273).

> You might just be able to release the lock on the sip_pvt before
> checking if the parking spot is valid and then grab it back afterwards.

I'll give that a shot and see what happens.

-Jonathan