Workers process SIP messages, which means both requests and replies. So, you can't use request-oriented tracking to make that decision.

The answers to your question are basically:

1. Keep your call processing as fast and light as possible.

2. Use async methods.

Async methods only help so much, due to the strict timing tolerances of SIP, and real-time, delay-sensitive communication in general. The fundamental answer is basically #1--incur as little delay as possible.

On 26 October 2014 14:33:43 GMT-04:00, davy van de moere <davy.van.de.moere@gmail.com> wrote:

Gents,

assuming we don't use async methods (I know, it's against fashion), eventually you'll end up in having some bottlenecks in your config... 

Now thanks to a lot of children you can easily work around this, a maximum of 32 children gives you already quite something, and if you use the dispatcher, you can ramp that up to quite some capacity. ;)

Now, there are moments where still limits are passed, so what would be the best way to keep your system healthy?

I was thinking in the direction of using a hashtable value or $var to keep track of the children in use and e.g. if 31 children are used, refuse to process the 32th request (assuming 32 children are setup).  Would this be a valid strategy? Or am I overthinking?  

Grtz,

Davy 

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

--
Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.

Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0671
Web: http://www.evaristesys.com/, http://www.alexbalashov.com

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users