[asterisk-dev] ARI, Stasis, and Dialplan

Sun Feb 3 06:55:11 CST 2019

Sorry, that didn't make much sense.

I meant mapping the appname in the URL to [stasis-appname] in the dialplan.
The [user] portion of the ari.conf file is obviously irrelevant here.

Jim

On Sun, Feb 3, 2019 at 7:19 AM Jim Van Meggelen <jim.vanmeggelen at gmail.com>
wrote:

> Folks,
>
> I am writing up the ARI chapter at this time, and I've been keeping my
> eyes on this whole 'automatic dialplan' discussion, because I have to
> figure out how to document something that is quite literally being
> developed/decided as I'm writing it, and seems to be to be something
> important to document correctly.
>
> Although I appreciate that there may be a few details still to sort out,
> what I'm writing is not a comprehensive bible on how to develop complex
> apps with ARI, but rather a small introduction to ARI, with some useful
> best practices.
>
> So, I would like to ask for feedback on the following points:
>
>    - First and most importantly: Will this be shipping as part of
>    Asterisk 16 in, say, four to six months? (roughly when the book will hit
>    the ... er ... "shelves" ...).
>    - Is the concept of mapping [appname] in ari.conf to [stasis-appname]
>    dialplan sufficiently likely to survive any tweaks to the finished
>    product? (i.e. can I write about that?) (I hope so because that sounds like
>    a simple and logical way to handle all this automatic-dialplan magic.
>
> I can hold off for a week or two more, but I am expected to submit the
> final draft by the end of February, so ... no pressure!
>
> Thanks for any and all thoughts.
>
> Jim
>
>
>
> On Fri, Jan 25, 2019 at 11:50 AM Seán C. McCord <ulexus at gmail.com> wrote:
>
>> Nice!  Thanks, looking at it now.
>>
>> On Fri, Jan 25, 2019 at 10:22 AM Ben Ford <bford at digium.com> wrote:
>>
>>> Hey all,
>>>
>>> Just a quick update - this functionality is now up for review on Gerrit,
>>> and can be found here
>>> <https://gerrit.asterisk.org/#/c/asterisk/+/10882/>.
>>>
>>> More eyes on it would be helpful!
>>>
>>> On Thu, Dec 20, 2018 at 1:40 PM Seán C. McCord <ulexus at gmail.com> wrote:
>>>
>>>> As Josh says, all calls would go to the app; the (completely
>>>> non-user-facing and non-user-editable) context would be roughly
>>>> equivalent to having fallthrough enabled and extension 's' going to
>>>> the Stasis App.  You should not be able to assign an existing real
>>>> context to an ARI app.  That would lead to confusion, which is one of
>>>> the reasons why I like the idea of having deterministic context names.
>>>>
>>>> As to the channel-in-bridge on ARI app transfer, I would fully expect
>>>> that channel to stay in whatever bridge it may be.  Bridges are
>>>> logical link points between ARI apps anyway, and they can be
>>>> manipulated by multiple ARI apps at any given time anyway (this
>>>> assertion is from memory... it is possible I am mistaken here).  Now,
>>>> as to whether the ARI app should automatically gain a subscription to
>>>> member bridges, that's a good question.  I would lean toward not doing
>>>> so, but I do not have a strong argument beyond simplicity.
>>>>
>>>>
>>>> On Thu, Dec 20, 2018 at 1:25 PM Joshua C. Colp <jcolp at digium.com>
>>>> wrote:
>>>> >
>>>> > On Thu, Dec 20, 2018, at 2:14 PM, Corey Farrell wrote:
>>>> > > 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?
>>>> >
>>>> > The context would send all calls to that application (except for the
>>>> h extension). That application would then be able to move that channel to
>>>> another application according to its own routing logic if it wanted.
>>>> >
>>>> > --
>>>> > Joshua C. Colp
>>>> > Digium - A Sangoma Company | Senior Software Developer
>>>> > 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
>>>> > Check us out at: www.digium.com & www.asterisk.org
>>>> >
>>>> > --
>>>> > _____________________________________________________________________
>>>> > -- 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190203/70c130a9/attachment.html>