[asterisk-dev] Adding new ARI for application execute

[naruto360]

Hello Are you talking to me about the problem that was asked by me

في الاثنين، ١ ابريل، ٢٠١٩ ٨:٤٣ م 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.
>
> > > 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?
>
> > 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 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.
>
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190401/6acdef4e/attachment.html>