[asterisk-dev] ARI, Stasis, and Dialplan
Corey Farrell
git at cfware.com
Thu Dec 20 12:14:10 CST 2018
How will the ARI/dialplan integration handle specific extensions? For
example if I have a stasis app which registers itself to dialplan as
'somecontext', how does this integration decide which extensions are
handled by the app? Does that app get calls for all extensions or only
specific extensions? Do we create a new type of ARI app which would
respond to PBX switch callbacks where all calls go to the stasis router
app which then accepts or rejects calls based on the ARI apps own
extension list? For example if we have a context:
[from-outside]
exten => 7002052000,1,Stasis(myapp)
exten => 7002052001,1,Stasis(myapp)
How do you envision replicating having these two extensions handled but
all other extensions being invalid?
On 12/17/18 10:54 AM, Ben Ford wrote:
> Thanks for all the feedback! I believe we have a strong enough
> consensus to move forward. If anyone has any other thoughts on the
> direction of this, feel free to post them here anytime, preferably
> sooner rather than later so that if there is a conflict or something
> really cool we'd love to add, development isn't too far along yet :)
>
> On Thu, Dec 13, 2018 at 3:27 PM Seán C. McCord <ulexus at gmail.com
> <mailto:ulexus at gmail.com>> wrote:
>
> Sorry if I was unclear. Yes, I would love to extend the
> "Continue" function to add App and AppArgs as an option to use
> instead of Context/Extension/Priority. "Originate" and "Create"
> both allow these already. Adding these to "Continue" would be
> very helpful.
>
> On Thu, Dec 13, 2018 at 2:45 PM Ben Ford <bford at digium.com
> <mailto:bford at 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
> <ulexus at gmail.com <mailto:ulexus at 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
> <bford at digium.com <mailto:bford at 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
> <anilgupta83 at gmail.com <mailto:anilgupta83 at 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
> <dan at nimblea.pe <mailto:dan at 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
> <ulexus at gmail.com <mailto: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
> <mailto: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
> <mailto: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 <mailto:ulexus at gmail.com>
> > CyCore Systems
>
>
>
> --
> Seán C. McCord
> ulexus at gmail.com <mailto: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
>
> --
> _____________________________________________________________________
> -- 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://digium.com/> · https://sangoma.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 <mailto: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
>
>
>
> --
> *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://digium.com/> ·
> https://sangoma.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 <mailto: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
>
>
>
> --
> *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://digium.com/> ·
> https://sangoma.com <https://sangoma.com/>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20181220/c737d160/attachment-0001.html>
More information about the asterisk-dev
mailing list