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.vanmegge...@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 <ule...@gmail.com> wrote: > >> Nice! Thanks, looking at it now. >> >> On Fri, Jan 25, 2019 at 10:22 AM Ben Ford <bf...@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 <ule...@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 <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 >>> >>> >>> >>> -- >>> *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 >> 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 > >
-- _____________________________________________________________________ -- 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
