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

[Steve Davies]

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. <luis.rojas at 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
>
> 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>
> <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) 22001288mailto:luis.rojas at sixbell.com <luis.rojas at sixbell.com>http://www.sixbell.com
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200408/a2c51e64/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/a2c51e64/attachment.png>