[asterisk-dev] Adding new ARI for application execute
Sungtae Kim
pchero21 at gmail.com
Mon Apr 1 17:15:49 CDT 2019
On 4/1/19 9:31 PM, Matt Fredrickson wrote:
> On Mon, Apr 1, 2019 at 2:23 PM naruto360 <abdelhady20190 at gmail.com> wrote:
>> Hello Are you talking to me about the problem that was asked by me
> They're having a discussion about Asterisk ARI development. ARI is
> Asterisk's REST API.
>
> Matthew Fredrickson
>
>> في الاثنين، ١ ابريل، ٢٠١٩ ٨:٤٣ م Joshua C. Colp <jcolp at digium.com> كتب:
>>> On Mon, Apr 1, 2019, at 3:25 PM, Sungtae Kim wrote:
>>>
>>> <snip>
>>>
>>>>>> So, I was thinking how about make the stasis/ARI possible to execute the
>>>>>> applications? And I've created ticket for adding this feature to ARI
>>>>>> which is enabling the ARI to executing the application.
>>>>>> https://issues.asterisk.org/jira/browse/ASTERISK-28365
>>>>> So ARI wasn't written or designed to really function the same way as AGI for example. It expects to be the final owner of a channel. This has the consequence that it can be unsafe to execute dialplan applications which they themselves want to be the final owner of the channel on. Your change overcame this to a degree by making it blocking. This is problematic, though, as it means that the ARI application has lost its control and can't do anything until the dialplan application is over. It can't, for example, stop the dialplan application execution and regain control. The queue of any requests is blocked, thus the ARI application is blocked.
>>>> The application making a block is true, but ARI still control the flow.
>>>> Because the channel is still in the stasis(), the ARI can send the
>>>> hangup() or hangup with AST_SOFTHANGUP_ASYNCGOTO(I didn't implement this
>>>> yet) to exit from the application and it can give the control back to ARI.
>>> I think this would need to be implemented so that the ARI application can indeed take back control.
Agree, I will add it later.
>>>
>>>>> I'd also wonder what certain applications would do and the resulting events. What happens if you execute Dial, or ConfBridge, or perform a transfer while in a dialplan application in ARI?
>>>> Dial: It created a new channel and connected to each other(put in the
>>>> same bridge) And after hangup the dialed channel, the original channel
>>>> gets back to waiting for ARI request.
>>> 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).
>>>
>>>> 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.
>>>
>>>> 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.
>>>
>>> --
>>> Joshua C. Colp
>>> Digium - A Sangoma Company | Senior Software Developer
>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
>>> Check us out at: www.digium.com & www.asterisk.org
>>>
>>> --
>>> _____________________________________________________________________
>>> -- 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
>> --
>> _____________________________________________________________________
>> -- 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
>
>
More information about the asterisk-dev
mailing list