<div dir="ltr"><div>+1 to the context idea<br></div><div><br></div><div>Something like <i><b>context = stasis:app_name</b></i> would be nice. I presume this could be achieved by adding the functionality to the PBX module and most (if not all) channel drivers would work without modification.<br></div><div><br></div><div>Thanks,</div><div>Anil</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 13, 2018 at 2:16 AM Dan Jenkins <<a href="mailto:dan@nimblea.pe">dan@nimblea.pe</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Oh I do remember the context idea  - which seemed like a good idea at the time because of not having to change much internally</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 12, 2018 at 7:07 PM Seán C. McCord <<a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Correction: when I said the "latter," I should have said the "third"<br>
option.  The last option does not really work well, since _channels_<br>
map to _contexts_, not CELs.<br>
On Wed, Dec 12, 2018 at 1:52 PM Seán C. McCord <<a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.com</a>> wrote:<br>
><br>
> Neither of my previous emails appear to be showing up.... third time's<br>
> the charm?<br>
><br>
> We had briefly discussed the idea of creating virtual context/dialplan<br>
> to handle this.  The idea would be that a context and dialplan would<br>
> be internally and automatically generated which would direct calls<br>
> sent to that context directly to ARI.  Since the impetus for this<br>
> feature was operational simplicity, not any kind of optimization of<br>
> Asterisk itself, the idea of a virtual dialplan should work well and<br>
> would seem to not cause much disruption or require much code-wrangling<br>
> elsewhere.<br>
><br>
> I see a few ways that this might be implemented (at the user level):<br>
>  - Upon connecting an ARI application, the additional URL parameter<br>
> "context" may be passed, which would create the virtual context and<br>
> pass all calls to that context to the ARI app.<br>
>  - Add an ARI REST API call which creates a virtual context/dialplan<br>
> including, optionally, ARI parameters to be included with that call.<br>
>  - Define an automatic naming scheme for virtual dialplans associated<br>
> with ARI applications and have them generated automatically when an<br>
> ARI application connects.  For instance, the ARI application named<br>
> 'HOWDY' may have an automatically-generated context named<br>
> 'ari_autocontext_HOWDY'.<br>
>  - Define a single context (say, 'ari_auto') whose _extensions_ map to<br>
> the names of ARI applications.<br>
><br>
> I am partial to the latter, since it seems to be the simplest, but the<br>
> second has merit, too, since it allows any number of associations and<br>
> additional execution parameters to be set.<br>
><br>
> On Wed, Dec 12, 2018 at 11:22 AM Ben Ford <<a href="mailto:bford@digium.com" target="_blank">bford@digium.com</a>> wrote:<br>
> ><br>
> > Hey all,<br>
> ><br>
> ><br>
> > We’re looking into AstriCon feedback and one of the things we want to touch on is ARI --  specifically, the ability to not have to create an extensions.conf in order to dial into Stasis. Before we start working on this, we’d like some direction from the community on what people would be looking for. From a user perspective, how would you expect something like this to work? Where would you look for information on how to do this, or where it would be configured? Any feedback is welcome!<br>
> ><br>
> ><br>
> > Ben<br>
> ><br>
> ><br>
> > --<br>
> > Benjamin Ford<br>
> > Digium - A Sangoma Company | Software Engineer<br>
> > 445 Jan Davis Drive NW - Huntsville, AL 35806 - US<br>
> > Check us out at: <a href="https://digium.com" rel="noreferrer" target="_blank">https://digium.com</a> · <a href="https://sangoma.com" rel="noreferrer" target="_blank">https://sangoma.com</a><br>
> ><br>
> ><br>
> > --<br>
> > _____________________________________________________________________<br>
> > -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
> ><br>
> > asterisk-dev mailing list<br>
> > To UNSUBSCRIBE or update options visit:<br>
> >    <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
><br>
><br>
><br>
> --<br>
> Seán C. McCord<br>
> <a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.com</a><br>
> CyCore Systems<br>
<br>
<br>
<br>
-- <br>
Seán C. McCord<br>
<a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.com</a><br>
CyCore Systems<br>
<br>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div>