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