[asterisk-dev] ARI, Stasis, and Dialplan

[Seán C. McCord]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190125/94e97567/attachment.html>