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
--
_____________________________________________________________________
-- 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
