I have asterisk 18.5.0 running fine, but today our users are complaining about failed/cut calls.
Asterisk is running with realtime MySQL and uses only Stasis to process calls.
There are < 200 channels, so the instance load is low.
The only thing I was able to see in the console are those warning messages :
WARNING[4543] taskprocessor.c: The ‘stasis/m:rtp:all-0000149c’ task processor queue reached 500 scheduled tasks again
I suppose that this could be the cause of my failed calls?
I was not able to find anything about the “m:rtp” thing for the task processor, why it would overload the taskprocessor when I have more channels without any issues with the same setup on different instances?
Is there something I can do to increase the queue length or pinpoint why it is too high?
It is likely to be a symptom of the cause, but not the actual cause. The message implies an internal backlog of processing, which could be due to an overload, slow processing (e.g. lots of external database accesses), or a deadlock.
There is no need to increase the queue length as the message you are getting is a warning and doesn’t correspond with anything being dropped. As far as I know, there are no hard limits on the actual queues; the limits represent a judgement as to when queues are so long that there is probably something going wrong elsewhere.
Incidentally putting all logic in ARI is not something that many people do. Also ARA is only community supported.
Thanks for the clues, is there a mean to trace what’s causing the pressure on the rtp topic?
I would understand if the stasis topic spits warning and know that I need to look after the stasis implementation, but the RTP topic, I mean I have an instance with almost 1K calls and the exact same setup, and there are no warnings, that is very strange.
As for the extensive use of ARI, I don’t see anything else that can provide such dynamic support for handling calls, channels, bridges, audio and recording
