ARI using a single websocket, is it a bottleneck?


We have an application that uses ARI4Java.
The application is supposed to handle hundreds of callers and dozens of bridges.
We have written it so that it connects to Asterisk across 12 web sockets.
Each web socket must connect to a different stasis app, so we have set up a single extension with a dial plan that randomly selects which stasis application will receive the caller.

This works pretty well, but the problem is with bridge messages. Each web socket that deals with a given bridge becomes subscribed to that bridge and we start to receive messages on different sockets for each event, this causes multiple recording finished messages, playback started, etc…

The question is, is it necessary to have so many different web sockets, or will a single web socket handle the messaging for thousands of events?


Hi civicharles! I’m not the most experienced in ARI application but I think one web socket can handle thousands of calls and masseges and etc. I don’t know how ARI4Java works and my experience is most implementing my own API on C++, but for today for example I had almost 21k calls running the system for 8h and each call generates a lot of messages because I need to change channels between bridges, put on hold, play some sounds and so on.
Also I have to subcribe the the stasis app too to get the messages generated by the bridges and I know how much stuff gets to the websocket because of it.
So I think the main concern is how to deal with each message that comes to your web socket so the system don’t freeze processing all those messages.


Thanks ltardioli
I worked out problem by attaching the websocket object to the channel, or bridge, objects in my code. That way when I receive a bridge message across multiple sockets I can ignore any that aren’t on the socket attached to that specific bridge.