Tried sworker and can confirm that it fixes the original issue. Now is more clear separation between: - receiving SIP (via TCP socket workers, or via default TCP child listeners) - processing SIP (via async workers group)
Thanks for the answers, Stefan
On Tue, Jun 24, 2025 at 4:24 PM Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
besides the async/suspend/continue mechanisms mentioned previously, sworker module is another option that can be considered for dispatching messages on a busy connections to a group of other workers that start processing with request_route/reply_route.
Cheers, Daniel