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