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
