Hi, Henning,
No need to be ironic. As I mentioned on my first post, I tried stateful
proxy and I observed the same behavior.
/"I tried using stateful proxy and I obtained the same result."/
The asynchronous sleep seems promising. I will look into it.
Thanks,
Luis
On 4/8/20 9:30 AM, Henning Westerholt wrote:
Hi Luis,
I see. Well, you want to use Kamailio as a stateless proxy, on the
other hand it should do things that are inherently stateful. 😉
As mentioned, have a look to the dialog module to track the state of
dialogs that you process. This will not work in a stateless mode, though.
You can also use the htable module to just store some data about the
processed messages in a shared memory table and use this to enforce
your ordering. There is also the option to do an asynchronous sleep
(with the async) module on the message that you want to delay but
still processing other messages during it.
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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311846648&sdata=Rlxmq4vieb20HKUi4se4MfGJSuETpO%2Bd8uK0KzBTWO0%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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311846648&sdata=nAvHd08RTXoEAFfpOuoGQJnoRmOtzQ0RSfS2RYwIyQs%3D&reserved=0>
*From:* Luis Rojas G. <[email protected]>
*Sent:* Wednesday, April 8, 2020 3:00 PM
*To:* Henning Westerholt <[email protected]>; Kamailio (SER) - Users
Mailing List <[email protected]>
*Subject:* Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5407%23page-22&data=02%7C01%7C%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311856645&sdata=fwVfaNyZ7hCyBvYz%2BdlWBMf52MuFdhBxHpnYysjA0FA%3D&reserved=0>
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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311866648&sdata=HCaqkR5PR6BmByZVV5%2F59XWfNywkkedMaujpDOOG4dk%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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311866648&sdata=O1BqU4CI4M6M8OUaE10JvFbJIeH32uZRuQg3ihEkxN0%3D&reserved=0>
*From:* sr-users <[email protected]>
<mailto:[email protected]> *On Behalf Of *Luis
Rojas G.
*Sent:* Tuesday, April 7, 2020 10:43 PM
*To:* [email protected] <mailto:[email protected]>
*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:[email protected]
http://www.sixbell.com
<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311876634&sdata=25KyYHDQz9BU3XDEGdjjPHgRH4MCZIFOEyXeXUoKjzI%3D&reserved=0>
--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
mailto:[email protected]
http://www.sixbell.com
_______________________________________________
Kamailio (SER) - Users Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
