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

On 8 Apr 2020, at 18:01, Steve Davies &lt;steve-lists-srusers(a)connection-telecom.com&gt; wrote: Hi Luis, Kamailio architecture isn't going to change I'm sure. There is no central orchestrator - each worker process just grabs messages as fast as it can. If your processing is slow for some and fast for others then they can get out of order I reckon. 180s are really neither here nor there if there's a 200 OK right behind it. Perhaps a proxy like Drachtio would work better for you? Steve On Wed, 8 Apr 2020 at 17:44, Luis Rojas G. &lt;luis.rojas(a)sixbell.com <mailto:luis.rojas@sixbell.com>> wrote: 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 <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: -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.rojas@sixbell.com <mailto:luis.rojas@sixbell.com> http://www.sixbell.com <http://www.sixbell.com/> _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users