On 8 Apr 2020, at 18:01, Steve Davies
<steve-lists-srus...@connection-telecom.com
<mailto:steve-lists-srus...@connection-telecom.com>> 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. <luis.ro...@sixbell.com
<mailto:luis.ro...@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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5407%23page-22&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475291806&sdata=RAqaEpyoKIedkPmVMHa%2Fl72%2B3JBkU%2F7PyiAjCMqpr4E%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%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475301797&sdata=gqiNRCFj%2F1GUuTnnB0X7bBmO2z6zDrXns6qJBWAXkfE%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%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475301797&sdata=7bZMGT2k%2Fi%2BdVrYgIfoS2gt%2F50YCfBeyKMI%2Bxx04FsY%3D&reserved=0>
*From:* sr-users <sr-users-boun...@lists.kamailio.org>
<mailto:sr-users-boun...@lists.kamailio.org> *On Behalf Of *Luis
Rojas G.
*Sent:* Tuesday, April 7, 2020 10:43 PM
*To:* sr-users@lists.kamailio.org
<mailto:sr-users@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 :
<image001.png>
UAS is 172.30.4.195:5061
<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2F172.30.4.195%3A5061%2F&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475311794&sdata=i%2FMPGmKH%2BoZrk1BhqVfB6BYrLwyeDTT%2BZ3g%2FbR4f1bU%3D&reserved=0>.
UAC is 172.30.4.195:5080
<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2F172.30.4.195%3A5080%2F&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475321788&sdata=a0%2FA4NPnvgECMGGqSFmB0A%2FV04sof91YEEFrDl7lUsA%3D&reserved=0>.
Kamailio is 192.168.253.4:5070
<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.253.4%3A5070%2F&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475321788&sdata=lsh41ie0Pt8V9e7dYY22XGFSf3N%2Bx7AH7KNjdZz0wZM%3D&reserved=0>
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.ro...@sixbell.com
http://www.sixbell.com
<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475331785&sdata=mdRBm3%2FLquXhok2NdBHLsPdolLZaYxixSDi04dubqpE%3D&reserved=0>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.kamailio.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsr-users&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475331785&sdata=5VqpYRjbnYTDa70nvXNIT3Ywj6%2FF5Uh%2B%2Bd2rudw2d5w%3D&reserved=0>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
