[asterisk-dev] ARI, Stasis, and Dialplan

Mon Dec 17 09:54:02 CST 2018

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> 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> 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> 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
>>
>>
>> --
>> _____________________________________________________________________
>> -- 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/20181217/e8d6d7c3/attachment-0001.html>