[asterisk-dev] ARI, Stasis, and Dialplan

Mon Feb 4 10:19:13 CST 2019

With the current approach, the context is now reliant on the appname, and
if you are wanting to do "automatic" entry into Stasis with an endpoint,
the only context that will matter is the one automatically created on
application launch. Say your application is "master". When it's launched,
you'll have a context named "stasis-master". As long as your endpoint has
the context "stasis-master", all calls will dial into that Stasis
application. The context parameter shouldn't matter in this case, and with
the addition of the new "move" REST API call, you can send your channel to
any other active application. Overall, less work!

Hopefully this answers your question. If I'm misunderstanding, just let me
know.

On Mon, Feb 4, 2019 at 10:01 AM Dan Jenkins <dan at nimblea.pe> wrote:

> Ah so just to confirm - above in the thread theres a variable in the url
> passed in called context so that you could have an app name of foo but a
> context of bar and also an ari application without a context called alice
> and therefore alice could still be addressable from dialplan. So do we want
> the dialplan entry automatically generated by app name or context variable
> passed in the url?
>
>
>
> On Mon, Feb 4, 2019 at 3:52 PM Ben Ford <bford at digium.com> wrote:
>
>> 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
>>
>>
>> --
>> _____________________________________________________________________
>> -- 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/da5fdd19/attachment-0001.html>