I'd want to be able to specify an application and pass arguments to it. On Thu, 13 Dec 2018, 19:46 Ben Ford, <bf...@digium.com> 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 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
-- _____________________________________________________________________ -- 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
