Hello,
it was a reply to my email where I mentioned the route_locks_size
parameter. As he said he looked at that parameter, I assumed it was
about the route_locks_size, because there was not other parameter listed
in the emails. So using the route_locks_size parameter doesn't require
to use dialog module.
Cheers,
Daniel
On 09.04.20 10:29, Henning Westerholt wrote:
Hello,
I mentioned in some of earlier e-mails as one possible option to track
the state of a dialog and to act depending on it.
Cheers,
Henning
--
Henning Westerholt –
https://skalatan.de/blog/
Kamailio services –
https://gilawa.com <https://gilawa.com/>
*From:* Daniel-Constantin Mierla <miconda(a)gmail.com>
*Sent:* Thursday, April 9, 2020 9:48 AM
*To:* luis.rojas(a)sixbell.com; Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org>rg>; Henning Westerholt <hw(a)skalatan.de>
*Subject:* Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
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%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481963069&sdata=CWh4qvJwYloHLPCOFUdVXRuge3l2rvuAUDM6FBNjFMA%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