Greetings,
I've recently run into a rather strange issue where, in response to an INVITE sent by Kamailio, I'm receiving a 183 Session Progress and SIP 200 OK response about .000050 seconds apart (.05 miliseconds) .
Kamailio is choosing to forward the SIP 200 OK ahead of the 183, as if they had arrived at the same time and is prioritizing the 200.
Is there a truncate limit on timestamp values? Is this possibly adjustable?
Thank you in advance, -Tim
---------------------------------------------------------------------- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
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 -
Heenan, Timothy Steven