[asterisk-dev] ARI, Stasis, and Dialplan

[Seán C. McCord]

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