Re: [asterisk-dev] ARI, Stasis, and Dialplan

2019-02-05 Thread Dan Jenkins
:thumbsup: On Tue, Feb 5, 2019 at 11:03 AM Joshua C. Colp wrote: > On Tue, Feb 5, 2019, at 5:27 AM, Dan Jenkins wrote: > > so in this scenario a context will be created with "stasis-master" > > and we can do all our magic if we want to; but its quite possible no > > endpoint is using that

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2019-02-05 Thread Joshua C. Colp
On Tue, Feb 5, 2019, at 5:27 AM, Dan Jenkins wrote: > so in this scenario a context will be created with "stasis-master" > and we can do all our magic if we want to; but its quite possible no > endpoint is using that context but there is a context called foo which > has some dialplan which

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2019-02-05 Thread Dan Jenkins
so in this scenario a context will be created with "stasis-master" and we can do all our magic if we want to; but its quite possible no endpoint is using that context but there is a context called foo which has some dialplan which eventually you send into stasis with app name "master" ie

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2019-02-04 Thread Ben Ford
With the current approach, the context is now reliant on the appname, and if you are wanting to do "automatic" entry into Stasis with an endpoint, the only context that will matter is the one automatically created on application launch. Say your application is "master". When it's launched, you'll

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2019-02-04 Thread Dan Jenkins
Ah so just to confirm - above in the thread theres a variable in the url passed in called context so that you could have an app name of foo but a context of bar and also an ari application without a context called alice and therefore alice could still be addressable from dialplan. So do we want

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2019-02-04 Thread Ben Ford
Hey there, The short answer is "yes" to both. The plan is to have this change in 13, 16, and master. Once it is done with the review process and merged into the branches, the next release we cut will contain these changes. As for the appname and the dialplan entry that's automatically added,

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2019-02-03 Thread Jim Van Meggelen
Sorry, that didn't make much sense. I meant mapping the appname in the URL to [stasis-appname] in the dialplan. The [user] portion of the ari.conf file is obviously irrelevant here. Jim On Sun, Feb 3, 2019 at 7:19 AM Jim Van Meggelen wrote: > Folks, > > I am writing up the ARI chapter at

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2019-02-03 Thread Jim Van Meggelen
Folks, I am writing up the ARI chapter at this time, and I've been keeping my eyes on this whole 'automatic dialplan' discussion, because I have to figure out how to document something that is quite literally being developed/decided as I'm writing it, and seems to be to be something important to

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2019-01-25 Thread Seán C . McCord
Nice! Thanks, looking at it now. On Fri, Jan 25, 2019 at 10:22 AM Ben Ford wrote: > Hey all, > > Just a quick update - this functionality is now up for review on Gerrit, > and can be found here . > > More eyes on it would be helpful! > > On

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2019-01-25 Thread Sylvain Boily
On 2019-01-25 4:21 p.m., Ben Ford wrote: Hey all, Just a quick update - this functionality is now up for review on Gerrit, and can be found here . Really nice! Thank you. Sylvain --

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2019-01-25 Thread Ben Ford
Hey all, Just a quick update - this functionality is now up for review on Gerrit, and can be found here . More eyes on it would be helpful! On Thu, Dec 20, 2018 at 1:40 PM Seán C. McCord wrote: > As Josh says, all calls would go to the app;

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-20 Thread Seán C . McCord
As Josh says, all calls would go to the app; the (completely non-user-facing and non-user-editable) context would be roughly equivalent to having fallthrough enabled and extension 's' going to the Stasis App. You should not be able to assign an existing real context to an ARI app. That would

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-20 Thread Joshua C. Colp
On Thu, Dec 20, 2018, at 2:14 PM, Corey Farrell wrote: > How will the ARI/dialplan integration handle specific extensions? For > example if I have a stasis app which registers itself to dialplan as > 'somecontext', how does this integration decide which extensions are > handled by the app? Does

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-20 Thread Corey Farrell
How will the ARI/dialplan integration handle specific extensions?  For example if I have a stasis app which registers itself to dialplan as 'somecontext', how does this integration decide which extensions are handled by the app?  Does that app get calls for all extensions or only specific

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-20 Thread Ben Ford
Another thing I'd like to bring up is what should be done with a channel in a bridge when switching applications. Would you expect the channel to leave the bridge or remain in it? It would be easy to have this as a configurable option for the API call too, so if you can see reasons for needing

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-17 Thread Ben Ford
Thanks for all the feedback! I believe we have a strong enough consensus to move forward. If anyone has any other thoughts on the direction of this, feel free to post them here anytime, preferably sooner rather than later so that if there is a conflict or something really cool we'd love to add,

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-13 Thread Seán C . McCord
Sorry if I was unclear. Yes, I would love to extend the "Continue" function to add App and AppArgs as an option to use instead of Context/Extension/Priority. "Originate" and "Create" both allow these already. Adding these to "Continue" would be very helpful. On Thu, Dec 13, 2018 at 2:45 PM Ben

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-13 Thread Dan Jenkins
I'd want to be able to specify an application and pass arguments to it. On Thu, 13 Dec 2018, 19:46 Ben Ford, wrote: > To elaborate on this further, would it be fine the way it is currently, > where you specify a context and extension, or is there any interest in > being able to alternatively

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-13 Thread Ben Ford
To elaborate on this further, would it be fine the way it is currently, where you specify a context and extension, or is there any interest in being able to alternatively specify an application and arguments to pass to it? On Thu, Dec 13, 2018 at 12:37 PM Seán C. McCord wrote: > Absolutely. I

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-13 Thread Seán C . McCord
Absolutely. I really forgot about that, because I've just molded my design approach to maintain a single ARI application per node, but that extension to Continue (similar to Originate's App/AppArgs properties), would be enormously helpful. On Thu, Dec 13, 2018 at 11:47 AM Ben Ford wrote: > I

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-13 Thread Ben Ford
I think having a context that's created when the application starts sounds like a solid approach. Another thing to consider is how to move from one application to the next. Any thoughts on the use of /continue to tackle this? Is this something you'd like to be able to make use of in your

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-12 Thread Anil Gupta
+1 to the context idea Something like *context = stasis:app_name* would be nice. I presume this could be achieved by adding the functionality to the PBX module and most (if not all) channel drivers would work without modification. Thanks, Anil On Thu, Dec 13, 2018 at 2:16 AM Dan Jenkins wrote:

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-12 Thread Dan Jenkins
Oh I do remember the context idea - which seemed like a good idea at the time because of not having to change much internally On Wed, Dec 12, 2018 at 7:07 PM Seán C. McCord wrote: > Correction: when I said the "latter," I should have said the "third" > option. The last option does not really

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-12 Thread Seán C . McCord
Correction: when I said the "latter," I should have said the "third" option. The last option does not really work well, since _channels_ map to _contexts_, not CELs. On Wed, Dec 12, 2018 at 1:52 PM Seán C. McCord wrote: > > Neither of my previous emails appear to be showing up third time's >

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-12 Thread Seán C . McCord
Neither of my previous emails appear to be showing up third time's the charm? We had briefly discussed the idea of creating virtual context/dialplan to handle this. The idea would be that a context and dialplan would be internally and automatically generated which would direct calls sent to

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-12 Thread Joshua C. Colp
On Wed, Dec 12, 2018, at 12:55 PM, Dan Jenkins wrote: > > Hey Ben, > > I'd envisage a setting in ari.conf which would be the app name of the > initial app where all calls get sent. Then I could perform logic in > that app to decide based on X parameters which other ARI app I should >

Re: [asterisk-dev] ARI, Stasis, and Dialplan

2018-12-12 Thread Dan Jenkins
On Wed, Dec 12, 2018 at 4:24 PM Ben Ford wrote: > Hey all, > > We’re looking into AstriCon feedback and one of the things we want to > touch on is ARI -- specifically, the ability to not have to create an > extensions.conf in order to dial into Stasis. Before we start working on > this, we’d

[asterisk-dev] ARI, Stasis, and Dialplan

2018-12-12 Thread Ben Ford
Hey all, We’re looking into AstriCon feedback and one of the things we want to touch on is ARI -- specifically, the ability to not have to create an extensions.conf in order to dial into Stasis. Before we start working on this, we’d like some direction from the community on what people would be