So, here's some API draft.
I will introduce 2 new ARI requests and 1 ARI event.
* POST ari/channels/{channelId}/application?
Add the application execution into the queue.
* * parameters
name: application name
args: application arguments
* DELETE ari/channels/{channelId}/application
Exit from the current application execution.
* New ARI event
ChannelApplicationStatus
Represent application execution was finished.
{
"type": "ChannelApplicationStatus",
"timestamp": "2019-04-02T21:44:03.197+0200",
"channel_application": {
"name": "queue",
"args": "test,n,,3",
"status": "done"
},
"channel": {
...
},
"asterisk_id": "00:11:22:33:44:55",
"application": "test"
}
channel_application
"name" : application name
"args": application arguments
"status": status of application execution. Could be one of "queued",
"started", "finished".
On 4/2/19 12:49 AM, Joshua C. Colp wrote:
On Mon, Apr 1, 2019, at 7:16 PM, Sungtae Kim wrote:
<snip>
What events are created? Do they get propagated to ARI?
It was looks like this.
Dial: https://pastebin.com/8tdBZBrM
Confbridge: https://pastebin.com/FLjJDDNT
Transfer: https://pastebin.com/GmkCupyg
The ARI couldn't get receive the module's event such as QueueJoin.
Because the module subscription is not ready yet. Will implementing this
as we had a talk before(new subscription type for module).
This is something else that would need to be documented, and asked for actual
users whether they would expect such a thing and could tolerate it. You still
receive events for things you didn't directly initiate. That is: The
applications can create events based on what they are doing.
Agree.
Confbridge: It created new bridge and stayed there. After destroying the
bridge, the original channel gets back to waiting for ARI request.
Transfer: Didn't work. It didn't do the transfer but no hangup as well.
Haven't look that in depth, will figure out why.
Because if the Stasis calls the this ARI, the application taking the
ownership(sort of).
But the Stasis()/ARI still can send the ARI request to the channel.
Can you explain what you mean here?
I was taking about Hangup. If the ARI executed the application, the
application does blocking process. But ARI can send the Hangup request
via ARI while its executing.
Right, it can currently hang it up only.
I agree that some of the application(i.e. park) doesn't really respect
the AST_SOFTHANGUP_ASYNCGOTO signal somehow. But I think this is not
this feature's problem this is the application's problem. Because I can
see the same behaviors with 'Redirect' AMI action as well. And this
could be fixed in another way.
There's a lot of unknowns as to how exactly everything would behave in my mind
and they'd need to be answered.
Essentially I think there would need to be an accepted list or a denied list of
applications that are just incompatible with this. It would also be good to get
feedback from other people as to what they'd expect and how they would expect
to interact/use this new functionality. The asterisk-app-dev mailing list may
catch their attention.
Thank you for giving me an idea. But I'm not clear how to do this. As
you can see I'm terrible about writing. :P
I can make a list of what I've tested after done this work. But need
some help to complete the list later.
I think posting to asterisk-app-dev asking what dialplan applications people
still find themselves needing to go into the dialplan for from their ARI
application would be useful, as well as why and if they would be fine with a
limited set of applications being permitted.
As for making the list, I think starting with a minimal allowed list based on
what people actually need or use would be best so that everything doesn't have
to be tested.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
