Hello Are you talking to me about the problem that was asked by me في الاثنين، ١ ابريل، ٢٠١٩ ٨:٤٣ م Joshua C. Colp <jc...@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
-- _____________________________________________________________________ -- 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