Hello, On 12/10/2014 03:57 PM, Heenan, Timothy Steven wrote: This is likely because these replies are being handled by distinct (parallel) Kamailio SIP worker processes. The kernel chooses which child process handles which incoming packets semi-randomly, and there is no means of forcing replies belonging to the same transaction, message flow, Call-ID, etc. to be handled serially by one process. 0.05 msec sounds like it could be within the timing tolerance that would create such a race condition. There's not much you can do here. You can probably rig up something with locking, but any such strategy will end up blocking a whole child process, and it's risky--it might not get unblocked if there is abnormal messaging behaviour. Your best bet is to figure out why the 183 and the 200 are coming in near-simultaneously, as that is abnormal--if not exactly proscribed--behaviour. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/