[OpenSIPS-Users] get_dynamic_lock best practice

[Liviu Chircu]

Hi Cinthia,

Although the t_check_trans() enhancement solves one corner case, there 
are plenty more which could lead to lingering grabbed locks or too many 
lock releases:

* what if the UAS (original UAC in your scenario) becomes offline due to 
a network event for 1 minute? The Re-INVITE will time out (having 
received no reply), and your onreply_route will not get triggered, 
causing a lingering lock. You might get away by releasing it inside the 
failure_route, but it still looks error-prone to me.

* how do we handle call forking? Because you are grabbing the lock once, 
but releasing it for each reply of a forked outgoing branch.

Although I wrote the cfgutils locking support, I would advise against 
using it in such a SIP-centered, complex use case. I suggest simply 
storing/testing for a marker at dialog level, combined with 
t_check_trans() to detect retransmissions.

Upon an in-dialog request arrival:

* if the marker is not there -> put it, and proceed normally (e.g. if 
(!$dlg_val(request_pending)) $dlg_val(request_pending) = 1;)
* if the marker is there (e.g. if ($dlg_val(request_pending))) -> drop 
the request, let the UAC retransmit it. Hopefully, by the time the 
retransmission arrives, the marker is invalidated, otherwise we will 
have to keep on dropping them.

Upon an in-dialog reply arrival, we invalidate the marker 
($dlg_val(req_pending) = 0)

Cheers,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 22.01.2018 22:47, Cinthia Leung wrote:
> Hello all,
>
> We're trying to use get_dynamic_lock as a solution to a race 
> condition.  OpenSIPS receives an in-dialog INVITE and UPDATE almost at 
> the same time from a UAS and passes both to the SIP client 
> immediately.  The client responds to whichever one arrives first and 
> sends a SIP 500 to the second packet.
>
> I know we should look into fixing this behavior in the UAS.  But this 
> wonderful cfgutil feature looks like something that may help us in the 
> meanwhile.  We call get_dynamic_lock for the first packet in in-dialog 
> route.  release_dynamic_lock is called when we receive a final 
> response, which should not take long because there's no human 
> interaction involved.  And then the second packet gets the lock.
>
> We have since learned that this approach does not work well when 
> there's network latency that causes the UAS to retranx, as you can 
> imagine.  We are planning to use t_check_trans() before calling 
> get_lock.  At the same time we're wondering if there's a way to keep 
> track of these locks, potentially periodically purge them as needed.
>
> If you have any other ideas on how to solve our originally problem 
> then even better.
>
> TYVMIA!
>
>
> Cindy
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180123/44c365a6/attachment-0001.html>