On Mon, Apr 1, 2019 at 2:23 PM naruto360 <abdelhady20...@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 <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 -- Matthew Fredrickson Digium - A Sangoma Company | Asterisk Project Lead 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA -- _____________________________________________________________________ -- 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
