Hello, Daniel,
I am not so sure. I first tried adding that parameter, but it did not
work at all. Same behavior. Then I read the documentation more carefully :
https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size
route_locks_size
Set the number of mutex locks to be used for synchronizing the execution
of messages sharing the same Call-Id. In other words, enables Kamailio
to execute the config script sequentially for the requests and replies
received *within the same dialog* – a new message received *within the
same dialog* waits until the previous one is routed out.
Locks to execute sequentially messages belonging to same dialog. How
will Kamailio be aware that messages belong to same dialog, without the
dialog module?. With just stateless proxy it has no idea about dialogs,
it just forwards messages. I guess that's why just adding that parameter
did not work.
Am I wrong?
Luis
On 4/9/20 3:47 AM, Daniel-Constantin Mierla wrote:
Hello,
On 08.04.20 23:03, Luis Rojas G. wrote:
Hello, Daniel,
I looked into that parameter, but I need to use with the dialog
module, and I'm pretty afraid to use that.
who said or where is written than you need to load the dialog module?
You definitely don't.
Cheers,
Daniel
I was looking more into the stateless proxy, because I need to
process a lot of traffic.
My target is 4200CAPS. with duration between 90s and 210. Let's say,
150 seconds. That would mean 630.000 simultaneous dialogs. I don't
think the solution can go that way.
it would really help me to be able to use completely stateless proxy
plus Async in reply_route(), to introduce an artificial delay before
forwarding 200 OK to Invite.. As someone mentioned, it would help me
on request_route(), for race conditions between ACK and Re-Invite.
Any idea why Async is not allowed in reply_route()?
Best regards,
Luis
On 4/8/20 1:07 PM, Daniel-Constantin Mierla wrote:
Hello,
you have to keep in mind that Kamailio is a SIP packet router, not a
telephony engine. If 180 and 200 replies are part of a call is not
something that Kamailio recognize at its core. Its main goal is to
route out as fast as possible what is received, by executing the
configuration file script. Now, a matter of your configuration file,
processing of some SIP messages can take longer than processing
other. And the processing is done in parallel, a matter of children
parameter (and tcp_children, sctp_children).
With that in mind, a way to try to cope better with the issue you
face is to set route_locks_size parameter, see:
*
https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size
<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2Fdevel%2Fcore%23route_locks_size&data=02%7C01%7C%7C4ccc34db19ff4d0ca9b808d7dc5a4e1c%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220152764096691&sdata=P%2BETJg%2FH4%2BbbCR0Jtp6QpEx6QtBqdOr4saB7XKZbLYM%3D&reserved=0>
Probably is what you look for.
But if you want more tight constraints, like when receiving a 180
after a 200ok and not route it out, you have to make the logic in
configuration file by combining modules such as dialog or htable (as
already suggested).
Cheers,
Daniel
On 08.04.20 16:04, Luis Rojas G. wrote:
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%7C4ccc34db19ff4d0ca9b808d7dc5a4e1c%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220152764096691&sdata=XZpyIXwvOjenJKg5MIt6pNESBbpF2RV0waycxScsrkU%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%7C4ccc34db19ff4d0ca9b808d7dc5a4e1c%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220152764106687&sdata=CQbRA%2FVw6bAhHFVfuzuZh9zlrPzV%2B8jvZmIlCsc7Smk%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%7C4ccc34db19ff4d0ca9b808d7dc5a4e1c%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220152764106687&sdata=AuT9tjl1pJfrODPS7A50UErX222ToW7FP%2FGSF2nX%2FVk%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%7C4ccc34db19ff4d0ca9b808d7dc5a4e1c%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220152764116681&sdata=8hi51h9HXRKYWgJhZKOEa7yXSKVtCnkw8XqdX%2BW4Oo0%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%7C4ccc34db19ff4d0ca9b808d7dc5a4e1c%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220152764116681&sdata=pgrjB%2BIn5KEvDGMQrnKo1Y9rrD8qDUrmr9bBn9ieR9Q%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%7C4ccc34db19ff4d0ca9b808d7dc5a4e1c%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220152764126676&sdata=hf2GbP47LWZ9BOziUuyYS6VmSpsrgZv01ea9mAq1adU%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
--
Daniel-Constantin Mierla --www.asipto.com
www.twitter.com/miconda --www.linkedin.com/in/miconda
--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
mailto:[email protected]
http://www.sixbell.com
--
Daniel-Constantin Mierla --www.asipto.com
www.twitter.com/miconda --www.linkedin.com/in/miconda
--
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
