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 <jc...@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 ule...@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
