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
- Stasis event stream
- Http command
- 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.
- 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.
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:
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.