[asterisk-dev] ARI, Stasis, and Dialplan

Mon Feb 4 09:50:48 CST 2019

Hey there,

The short answer is "yes" to both. The plan is to have this change in 13,
16, and master. Once it is done with the review process and merged into the
branches, the next release we cut will contain these changes. As for the
appname and the dialplan entry that's automatically added, that's correct.
Whenever an application is launched, this dialplan entry is automatically
added and directly pulls from the application name to fill out the context
name.

Hope this helps!

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

> 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
>>
>> --
> _____________________________________________________________________
> -- 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/20190204/318cbbdf/attachment.html>