Delays in ARI events over websocket

Hi Team,

Hope you are having amazing time. I am using Asterisk ARI with stasis java application to handle incoming calls on my asterisk instance running on ubuntu 22.04 having 16-core CPU and 32GB RAM. I am successfully able to handle up to 400 simultaneous calls with single asterisk instance where each call is having 30s of duration. I am handling DTMF event, playback start/finish event etc. using this setup.

But the issue I’m facing is that after 400+ simultaneous calls if I further increase the simultaneous calls count, the events over websocket starts coming with significant delays of up to 10 seconds. For example: If I answer a channel at X:Y:35:ABC timestamp using ARI answer API (where X=hour, Y=minute, ABC=milliseconds) then I receive corresponding event (ChannelStateChange) at X:Y:40:ABC or after that on my websocket and same thing is happening with playback related APIs which is causing delays and longer call than expected duration. As per my stasis app logs, there is no delay in java application processing but since events are coming with significant delay from asterisk end so calls are getting slower response.

Is there any way to log in asterisk logs when an event was transmitted from asterisk over websocket (assuming my stasis app is not properly handing incoming events which is not the case most probably) or is there any configuration that can be tuned to optimize websocket performance. I have tried performance tuning article on asterisk official website (thread pool stuff) and few other articles but no improvement was noticed. Both asterisk and stasis apps are installed in same system and there is no http delay in hitting ARI APIs from stasis app to asterisk.

System stats (400+ simultaneous calls):
Asterisk version: 18.8.0
Load average: 4-5
Free RAM: 18-20 GB
Channel driver: PJSIP
Asterisk log level: Minimal
CDR module is also turned off in cdr.conf

My dialplan config:
exten => _X.,1,Stasis(stasisapp)
same => n,Hangup()

Any help would be high appreciated since it’s been considerable time I am trying to debug this issue.

There’s the “ari set debug on” CLI command which will cause a verbose message to get output into logging when an event is written to the websocket. That doesn’t include any delay with the TCP stack itself though, and events themselves also include a timestamp.

Hi Joshua. Thank you for your valuable suggestion. I’m finally able to identify the root issue which was caused due to the TCP delay only.

Hi @akgarg0472, would you mind sharing what exactly the issue was? This will be super helpful for future visitors.

There were some network traffic related system configuration which was causing the issue and slightly optimizing websocket listener’s Java code allowed me to handle more simultaneous calls.

Also, all thread pool related configs are reverted back to defaults.

Once my testing is done, I’ll update here about the simultaneous number of calls I’m able to achieve (currently targeting 1000-1500 simultaneous calls without any delay) along with configuration (if there is any specific/special one).

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.