Is there any feedback from Digium on the future of the AMI ? Is it being replaced with the ARI (rest interface) or will both be supported long term?
It’s not being replaced. They serve different purposes. AMI isn’t going to go away.
As I understand it, AMI is for third party control, whereas ARI is more like first party control with the application code remotely hosted, although I think that it may be used for some applications that closer to third party control.
There is definitely some overlap–for example, two different ways of listening for events.
ARI (as of Asterisk 16.3) also has the capability to create channel definitions on the fly, without referencing contexts defined in extensions.conf. These channels should be able to interact with AMI and AGI in the same way as those from statically-configured contexts.
So what can you still do with AMI+AGI that you cannot (yet) do from ARI? Frankly, I can’t see a lot.
One thing that annoys me is we now have two different uses of the term “application”–the original one, for commands that you can put into a context definition, and the newer ARI one, for filtering events.
AMI has far more events, as it has application level events and even more core level events. It also has far more actions - because they’re actions from applications and other functionality, and not low level primitives. AGI also allows you access to dialplan applications while ARI does not.
If your usage is extremely narrow then ARI can replace them. For everyone else, it can’t.
1 Like
Many people tend to get confused with the use of AMI, AGI and ARI, and each of these interfaces has a very different purpose and use case.
Asterisk Wiki
- AGI is analogous to CGI in Apache. AGI provides an interface between the Asterisk dialplan and an external program that wants to manipulate a channel in the dialplan. In general, the interface is synchronous - actions taken on a channel from an AGI block and do not return until the action is completed. Example of use cases
IVR connected to databases, Remote API system like Google TTS , Google Speech recognition
- AMI provides a mechanism to control where channels execute in the dialplan. Unlike AGI, AMI is an asynchronous, event driven interface. For the most part, AMI does not provide mechanisms to control channel execution - rather, it provides information about the state of the channels and controls about where the channels are executing.
Example of use cases
Queue dashboard, Auto dialer system using Originate action, and any other app for remotely monitor to send actions to Asterisk
Is good to know before Asterisk 12, if you wanted your own custom communication application, you could:
** Write an Asterisk module in C, or*
** Write a custom application using both AGI and AMI, performing some herculean effort to marry the two APIs together (as well as some dialplan trickery)*
Don’t forget “Async AGI” mode, where an AMI connection can be used to control channel execution.
So you see, the separation between the various Asterisk APIs is far from clear-cut, and just seem to get more tangled over time.
I think one of the things that confuses people is that the low level protocol used makes it appear that Asterisk is the server in the relationship. In particular, that leads to people doing things like using it to originate a call based on an external event and a process that only runs for as long as it takes to start the call running.
The reality is that the process making the ARI requests is intended to be more like a server to Asterisk, although it might be better to describe it as a coroutine relationship, and the intention is that the process should be monitoring for use of the application that it implements the whole time that Asterisk is running.
I don’t know the reasoning for using a protocol that pulls events in this case. Was it just because RESTful was fashionable at the time? The normal reason for pulling events is to mitigate a power imbalance, as results from the typical internet consumer behind NAT situation, where that consumed is tryhing to do something server like, like accepting incoming email, or instant messages, immediately, rather than by polling.
I’m not sure what you mean by “pulling” events. There is no polling or pulling with ARI for events. Websockets are a persistent connection, essentially a TCP/IP connection and events go over it when they are produced. The ARI application doesn’t poll or pull from it.
Regarding your post over on FreePBX. Some ARI operations can be done without a running ARI application, such as originate, if the call is not sent to an ARI application. That works fine.
I meant that the connection to receive the events is set up from the ARI side, although I may have misunderstood the details and assumed because things are done as HTTP type requests, the events are sent as responses to those requests.
I’m suggesting that this is becoming one of the main uses of ARI, and making people think it is an AMI replacement. I assume that the ability to this was put in to support the operation of applications, rather than as a primary use case.
The connection to receive the events is set up from the ARI application side to Asterisk as a persistent connection. It’s been requested to allow Asterisk to connect out to the ARI application instead, but that doesn’t exist today.
Some of the ARI operations working without an application is really just a side effect of the way core things work. Some were done because “why not” - originate to the dialplan being an example, because it uses the same core interface as call files, CLI originate, and AMI originate so it wasn’t that much effort.
We currently use AMI and have some extremely large call centers where they can see hundreds-thousands of SIP calls come into the system within a couple seconds. The AMI events and actions do see slowdowns because there is so much going on for a single connection.
We are in the process of migrating much of the work to ARI because it provides us the ability to distribute the websocket and ARI communication.
Asterisk is phenomenal at handling the calls, bridging media, etc. ARI’s External Media session ability opened an entirely new world of possibilities for us.
1 Like
Events in ARI are received by setting up a WebSockets connection. WebSockets is a full-duplex, message-based, reliable transport, but Asterisk uses it as a one-way connection for sending event notifications to the listener.
I have put together a couple of unpublished examples of how to originate calls using ARI: one ignores the “application” setting you have to pass, while the other makes use of it. I found the two had to work very differently: the latter has to set up its own bridge as well, the former does not.
I should probably add these to my Seaskirt Examples repo.
I’m curious if you have experimented with different values of “rtcpinterval” (rtp.conf) to change how often the rtcp reports are transmitted during calls?
We have not experimented with the rtcpinterval in rtp.conf.
From what I recall, we do disable the RTCP events entirely from the manager events.