[SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Wed Apr 8 15:00:13 CEST 2020

Hello, Henning,

I am worried about this scenario, because it's a symptom of what may 
happen in other cases. For instance, I've seen that this operator 
usually sends re-invites immediate after sending ACK.   This may create 
race conditions like 3.1.5 of RFC5407

https://tools.ietf.org/html/rfc5407#page-22

I'd understand that one happens because of packet loss, as it's in UDP's 
nature, but in this case it would be artificially created by Kamailio. 
if there was no problem at network level (packet loss, packets following 
different path on the network and arriving out of order), why Kamailio 
creates it?

I'd expect that the shared memory is used precisely for this. If an 
instance of kamailio receives a 200 OK, it could check on the shm and 
say "hey, another instance is processing a 180 for this call. Let's wait 
for it to finish" (*). I know there could still be a problem, the 
instance processing the 180 undergoes a context switch just after it 
receives the message, but before writing to shm, but it would greatly 
reduce the chance.

In our applications we use a SIP stack that always sends messages to the 
application in the same order it receives them, even though is 
multi-threaded and messages from the network are received by different 
threads. So, they really syncronize between them. Why Kamailio instances 
don't?

I am evaluating kamailio to use it as a dispatcher to balance load 
against our several Application Servers, to present to the operator just 
a couple of entrance points to our platform (they don't want to 
establish connections to each one of our servers). This operator is very 
difficult to deal with. I am sure they will complain something like "why 
are you sending messages out of order? Fix that". The operator will be 
able to see traces and check that messages entered the Kamailio nodes in 
order and left out of order. They will not accept it.

(*) Not really "wait", as it would introduce a delay in processing all 
messages. it should be like putting it on a queue, continue processing 
other messages, and go back to the queue later.

Well, thanks for your answer.

Luis

On 4/8/20 3:01 AM, Henning Westerholt wrote:
>
> Hello Luis,
>
> as the 1xx responses are usually send unreliable (unless you use 
> PRACK), you should not make any assumption on the order or even the 
> arrival of this messages. It can also happens on a network level, if 
> send by UDP.
>
> Can you elaborate why you think this re-ordering is a problem for you?
>
> One idea to enforce some ordering would be to use the dialog module in 
> combination with reply routes and the textops(x)  module.
>
> About the shared memory question – Kamailio implement its own memory 
> manager (private memory and shared memory pool).
>
> Cheers,
>
> Henning
>
> -- 
>
> Henning Westerholt – https://skalatan.de/blog/ 
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F&data=02%7C01%7C%7C9909a729fd8a426f81aa08d7db8aab0a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C1%7C637219260993836600&sdata=ZLmPqvbWKbsXY49s870sElN2I0uIn0DtDQSqJOoxr6I%3D&reserved=0>
>
> Kamailio services – https://gilawa.com 
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F&data=02%7C01%7C%7C9909a729fd8a426f81aa08d7db8aab0a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C1%7C637219260993836600&sdata=Hdgzfwgu80wiwJBOjh9N70hvXSvWjt8abuKFjVRsavo%3D&reserved=0>
>
> *From:* sr-users <sr-users-bounces at lists.kamailio.org> *On Behalf Of 
> *Luis Rojas G.
> *Sent:* Tuesday, April 7, 2020 10:43 PM
> *To:* sr-users at lists.kamailio.org
> *Subject:* [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
>
> Good day,
>
> I am testing the dispatcher module, using Kamailio as stateless proxy. 
> I have a pool of UAC (scripts in SIPP) and a pool of UAS (also scripts 
> in SIPP) for the destinations. Kamailio version is 
> kamailio-5.3.3-4.1.x86_64.
>
> Problem I have is, if UAS responds 180 and 200 OK to Invite 
> immediately, sometimes they are propagated out of order. 200 OK before 
> 180, like this :
>
> UAS is 172.30.4.195:5061. UAC is 172.30.4.195:5080. Kamailio is 
> 192.168.253.4:5070
>
> Difference between 180 and 200 is just about 50 microseconds.
>
> My guess is that both messages are received by different instances of 
> Kamailio, and then because of context switches, even though the 180 is 
> received before, that process ends after the processing of 200. 
> However, I had the idea that in order to avoid these problems the 
> kamailio processes synchronized with each other using a shared memory. 
> I tried using stateful proxy and I obtained the same result.
>
> By the way, anyone has any idea about how Kamailio's share memory is 
> implemented? It clearly does not use the typical system calls 
> shmget(), shmat(), because they are not shown by ipcs command.
>
> Before posting here I googled, but I couldn't find anything related to 
> this. I can't believe I am the only one who ever had this problem, so 
> I guess I am doing something wrong...
>
> Please, any help. I'm really stuck on this.
>
> Thanks.
>
> -- 

-- 
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
mailto:luis.rojas at sixbell.com
http://www.sixbell.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200408/4308d7b7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 49792 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200408/4308d7b7/attachment.png>