[asterisk-dev] ARI, Stasis, and Dialplan

Thu Dec 13 13:44:59 CST 2018

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> 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> 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>
>> 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> 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>
>>>> 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
>>>>
>>>> --
>>>> _____________________________________________________________________
>>>> -- 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
> 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://sangoma.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20181213/1cb181a6/attachment-0001.html>