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 <ule...@gmail.com> wrote: > 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 <bf...@digium.com> wrote: > >> 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 applications? >> >> On Wed, Dec 12, 2018 at 11:42 PM Anil Gupta <anilgupt...@gmail.com> >> wrote: >> >>> +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 <d...@nimblea.pe> wrote: >>> >>>> 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 <ule...@gmail.com> >>>> wrote: >>>> >>>>> 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 <ule...@gmail.com> >>>>> wrote: >>>>> > >>>>> > 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 that context directly to ARI. Since the impetus for this >>>>> > feature was operational simplicity, not any kind of optimization of >>>>> > Asterisk itself, the idea of a virtual dialplan should work well and >>>>> > would seem to not cause much disruption or require much >>>>> code-wrangling >>>>> > elsewhere. >>>>> > >>>>> > I see a few ways that this might be implemented (at the user level): >>>>> > - Upon connecting an ARI application, the additional URL parameter >>>>> > "context" may be passed, which would create the virtual context and >>>>> > pass all calls to that context to the ARI app. >>>>> > - Add an ARI REST API call which creates a virtual context/dialplan >>>>> > including, optionally, ARI parameters to be included with that call. >>>>> > - Define an automatic naming scheme for virtual dialplans associated >>>>> > with ARI applications and have them generated automatically when an >>>>> > ARI application connects. For instance, the ARI application named >>>>> > 'HOWDY' may have an automatically-generated context named >>>>> > 'ari_autocontext_HOWDY'. >>>>> > - Define a single context (say, 'ari_auto') whose _extensions_ map >>>>> to >>>>> > the names of ARI applications. >>>>> > >>>>> > I am partial to the latter, since it seems to be the simplest, but >>>>> the >>>>> > second has merit, too, since it allows any number of associations and >>>>> > additional execution parameters to be set. >>>>> > >>>>> > On Wed, Dec 12, 2018 at 11:22 AM Ben Ford <bf...@digium.com> 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 like some direction from the community on what people would be >>>>> looking for. From a user perspective, how would you expect something like >>>>> this to work? Where would you look for information on how to do this, or >>>>> where it would be configured? Any feedback is welcome! >>>>> > > >>>>> > > >>>>> > > Ben >>>>> > > >>>>> > > >>>>> > > -- >>>>> > > Benjamin Ford >>>>> > > Digium - A Sangoma Company | Software Engineer >>>>> > > 445 Jan Davis Drive NW - Huntsville, AL 35806 - US >>>>> > > Check us out at: https://digium.com · https://sangoma.com >>>>> > > >>>>> > > >>>>> > > -- >>>>> > > >>>>> _____________________________________________________________________ >>>>> > > -- 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 >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Seán C. McCord >>>>> > ule...@gmail.com >>>>> > CyCore Systems >>>>> >>>>> >>>>> >>>>> -- >>>>> Seán C. McCord >>>>> ule...@gmail.com >>>>> CyCore Systems >>>>> >>>>> -- >>>>> _____________________________________________________________________ >>>>> -- 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 >>> >>> -- >>> _____________________________________________________________________ >>> -- 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 >> >> >> >> -- >> *Benjamin Ford* >> Digium - A Sangoma Company | Software Engineer >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US >> <https://maps.google.com/?q=445+Jan+Davis+Drive+NW+-+Huntsville,+AL+35806+-+US&entry=gmail&source=g> >> Check us out at: https://digium.com · https://sangoma.com >> >> >> -- >> _____________________________________________________________________ >> -- 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 > > > > -- > Seán C. McCord > ule...@gmail.com > CyCore Systems > -- > _____________________________________________________________________ > -- 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 -- *Benjamin Ford* Digium - A Sangoma Company | Software Engineer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US <https://maps.google.com/?q=445+Jan+Davis+Drive+NW+-+Huntsville,+AL+35806+-+US&entry=gmail&source=g> Check us out at: https://digium.com · https://sangoma.com
-- _____________________________________________________________________ -- 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
