[asterisk-dev] Adding new ARI for application execute

[Sungtae Kim]

On 4/1/19 4:22 PM, Joshua C. Colp wrote:
> On Sat, Mar 30, 2019, at 7:45 PM, Sungtae Kim wrote:
>> Hi Asterisk team,
>>
>> I want to talk about some feature for the ARI.
>>
>> Currently, ARI doesn't allow executing the Asterisk application.
>>
>> But this makes ARI users giving up and tired to use the ARI.
>> Because to use the Application, it has to be exit from the Stasis and
>> jump to the dialplan to executing the application. And have to execute
>> the Stasis() again to back to Stasis.
> I think using this as a way to way to determine any missing gaps in ARI and extend it is good, but I'm hesitant towards allowing arbitrary dialplan application execution. The cases I know of are tone recognition, speech recognition, and faxing.

Agree, I've just focused on the feature and benefits. But I want to see 
the penalties as well. That's why we're having a discussion here.

Generally, this is working same as the application in dialplan. It would 
be the same result. But I haven't done that test with all of 
applications yet...

>   
>> Since it makes the channel needs to be exit from the Stasis, ARI can not
>> control the call while it's not in the Stasis. This makes also hard to
>> control the call.
>>
>> 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'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.

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.

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.

Sure, how could I help? :)

Thank you.

Kind regards,
Sungtae