I’d like to get current parked calls from ARI.
I checked all of ARI documents but I couldn’t find the API.
https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+ARI
Could you teach me how to get parked calls from ARI? Other method is also welcome.
If you mean get a list of parked calls, no. That doesn’t exist in ARI. It exists in AMI[1].
[1] Asterisk 20 ManagerAction_ParkedCalls - Asterisk Project - Asterisk Project Wiki
Thank you so much. I hope the function is implemeted in ARI in the future.
Why should it be? One of the problems I see with software is that people come up with a new concept, that does something well, typically to replace something overly complex, but rather than just use it for that purpose, over time, people try and add more and more features to it, to make it do everything. The result is the new overly complex system just waiting for the cycle to start again.
It seems to me the whole point of ARI is to replace the hodgepodge of miscellaneous bits stuck together that AMI+AGI has become, just rebuilt on a cleaner foundation. So yes, it should include all the functionality that the older interfaces offer, if it doesn’t do so already.
By the way, can’t you get a list of channels via ARI, and wouldn’t that information include the channel status? Would that include the information that it is parked?
It’s not meant to replace AMI or AGI, or to unify any of that. They all serve different purposes. It sits in the middle[1], in a place where people were trying to potentially combine the two in order to achieve things.
Parking information is not present as part of channel status.
[1] Asterisk REST Interface (ARI) - Asterisk Project - Asterisk Project Wiki
Remember why people were trying to combine AMI and AGI: it was precisely because of the gap between them. That’s why “Async AGI” mode was introduced, to try to bridge that gap. And don’t forget the peculiarities with opening an AMI connection to listen for events, versus using one for initiating actions: you’d think the two are best kept separate … until you encounter how the Originate action works.
ARI does away with all of this.
Okay, that doesn’t alter the goal of ARI. It’s not to completely replace AGI and AMI.
Let us get back to the goals of ARI as described on that page that you yourself referenced:
“… designed to let a developer build their own custom communications application.”
“ARI is an asynchronous API that allows developers to build communications applications by exposing the raw primitive objects in Asterisk…”
“By handing control of these resources over to all developers - regardless of their language choice - Asterisk becomes an engine of communication, with the business logic of how things should communicate deferred to the application using Asterisk.”
Now, looking at what you know about AMI and AGI, can you point to any feature(s) that they offer that is not helpful with these goals?
The definition of custom communications application within ARI was scoped specifically to the ability to essentially write dialplan applications outside of Asterisk, to yield that business control outside with lower level primitives to give control over a channel. The page talks about that. Not to interface with existing dialplan applications - which is what happens partially with ARI, and a lot with AMI.
Your definition of custom communications application may be more broad and generic (such as an outside program that uses Queue AMI actions to do things), but that’s not what ARI was scoped to. It was scoped to replace Queue.
I don’t foresee that changing.
Unfortunately, I get the impression that a lot of people are trying to use it to replace dialplan, possibly on fashion grounds, e.g. a manager says we must use a REST API.
Worth pointing out that the ability to create dialplan contexts out of thin air was only added in Asterisk 16.3, while ARI was introduced in Asterisk 12.
This means you can’t point to that feature as a core design goal of ARI, since it wasn’t there from the beginning. The fact that it was added as an ARI feature, not available with AMI+AGI, just reinforces my point that ARI is the future, while AMI+AGI are legacy technologies from this point.
I don’t know what that has to do with things, so I’m just going to walk away. You can believe as you wish.
When you look at phrases like “build their own custom communications application” and “engine of communication”, they are in fact apt descriptions of Asterisk itself, right back to version 1.0. All these interface APIs, from AMI to ARI, are just steps along the way to achieving the same goal. As limitations of an existing approach become apparent, beyond that which can be fixed within the existing framework, a new one is created to address them.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.