<div dir="ltr">Hello all,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>If you have any other ideas on how to solve our originally problem then even better.</div><div><br></div><div>TYVMIA!</div><div><br></div><div><br></div><div>Cindy</div></div>