[asterisk-dev] ARI, Stasis, and Dialplan

[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 <ulexus at 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 <ulexus at 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 <bford at 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
> > ulexus at gmail.com
> > CyCore Systems
>
>
>
> --
> Seán C. McCord
> ulexus at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20181212/31cb5523/attachment.html>