Or the looping of operations is essentially flooding the message bus with messages faster than the consumers can consume them.
That’s probably it. The queue clears quickly (less than half a second, possibly a lot less) after the warning appears. But if a SIP register (and probably others) message comes in exactly during that short time span, it is going to get a 503 response. BTW, it may make sense to include Retry-After header in a response, so the client retries after a few seconds.
There is a configuration option[1] in pjsip.conf to limit its behavior to only PJSIP specific taskprocessors, such that it won’t reject traffic if other taskprocessors are overloaded.
[1] https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample#L1281
1 Like
Thanks. That will help in the short term, though obviously I need to redesign the dialplan.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.