ARI Proxy design - your insight on HTTP commands

Hi all,

I have an ARI application running locally on a server with Asterisk. I am looking to improve redundancy and have been looking at the various proxy/message bus setups.

I have done lots of research into the available proxies and have a fair understanding of how they operate. I would like the get a bit of insight so that I can better adapt my existing application to work in this environment.

The existing proxies handle

  1. Stasis event stream
  2. Http command
  3. Http command responses.

I am unsure as to why the Http command/responses go via the proxy. The main purpose I can see for this is that the events + command responses are merged into the same stream. I can imagine that I will need to do some refactoring to handle this.

The question:

  • Is there any problems that can arise from handling the events via message bus, but using http commands directly? image attached
  • Can anyone offer insights into the benefit to having all of the events/responses in the same stream? Is there a particular approach design pattern that this helps with?

Edit: The diagram should reflect that any app server could send http commands to any asterisk box directly.

Appreciate any input.

Proxy actions

1 Like

Not sure what this “message bus” thing is, but it does seem to represent a single point of failure.

Note that ARI works entirely over HTTP/HTTPS connections. Event notifications are sent via WebSockets, which are created from HTTP/HTTPS connections.

The message bus represents a cluster of something like NATS or RabbitMQ. An ARI application can only have a single websocket connection. The message bus allows more than one consumer of the events from an ARI application. The single websocket connection is actually the single point of failure - this alleviates that problem.

Note that in ARI, an “application” is just a name for filtering events.

I’m not aware of any limitation on the number of ARI connections a client process is allowed to have.

@ldo They’re referring to multiple application instances connecting to Asterisk as the same application name, which is not supported. Only a single connection per application is implemented currently.

Ah, OK. Still, it’s possible to have multiple ARI clients originating calls and listening for the resulting events, each using their own dynamically-generated application name.

One thing I have found is that, having created an ARI application name, there seems to be no API call to delete it.

I appreciate the interest in the post. I’ll refocus the question.

In a case where using an ARI proxy/message bus, what is the benefit of having the event stream, commands and responses all going via the same message bus?

ARI event notifications and commands/responses cannot go over the same connection.

Hello, if you are interested by amqp/ari we developed this modules:


Not sure I understand the point of this. It seems to be a step backwards in some ways, e.g. Not all AMI events are sent to AMQP · Issue #18 · wazo-platform/wazo-res-stasis-amqp · GitHub

Thanks @quintana. I’ll take a look through it now.

Hello, we are discussing ARI, not AMI, in this context. Currently, we do not use AMI in the module. From what I recall, not all AMI events are present in stasis. For AMI, we have a proxy that is responsible for pushing all AMI events onto the bus. I hope this clarifies your question.