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

 

From: Daniel-Constantin Mierla <miconda@gmail.com>
Sent: Thursday, April 9, 2020 9:48 AM
To: luis.rojas@sixbell.com; Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org>; Henning Westerholt <hw@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

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

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda