Ok, I'm now looking into implementing a similar thing with the "continue" request. The main issue that I'm seeing is this - the ast_findlabel_extension function, requires a channel and a callerid.
I've tried ascertaining how i can obtain that information from within the ast_ari_channels_continue_in_dialplan function, but had failed to do so. Any pointers? Nir S On Mon, Oct 13, 2014 at 1:52 AM, Nir Simionovich <[email protected]> wrote: > Ok, > > I've opened an issue on JIRA ( > https://issues.asterisk.org/jira/browse/ASTERISK-24412) with a small > patch submission > that will correct the issue at hand - for the originate requests at this > point. > > Basically, before moving forward, I'd like to make sure I'm not off base > with the implementation - and that I've done it right. > It's the first time I'm touching that side of the code, so I would > appreciate the assistance and feedback. > > Cheers, > Nir S > > On Sun, Oct 12, 2014 at 12:46 AM, Nir Simionovich < > [email protected]> wrote: > >> So, here's what I thought - instead of modifying the existing JSON, >> changing from "int" to "string" in priority, I think the better >> way would be to add a new variable - "label". If defined, it will >> supersede the "priority". Judging from what I see in the code, >> the "arguments" from the JSON POST are contained in the *args buffer, so >> I should now have an args->label in there. >> >> So, if I'm not mistaken, the following should translate from the label to >> the priority:ast_find_label_extension. >> >> So, I would need to add a "label" argument to >> ari_channels_handle_originate_with_id. However, and correct me if I'm wrong, >> it would seem to me that the actual channel origination is performed >> using 'ast_pbx_outgoing_exten', and that would >> return back the 'ast_channel' structure back to *chan in >> ari_channels_handle_originate_with_id. >> >> Makes the entire thing kind'a tricky - no? >> >> >> >> On Fri, Oct 10, 2014 at 9:48 PM, Scott Griepentrog < >> [email protected]> wrote: >> >>> Yes, that's the function that converts a label to a priority. You >>> should be able to use that to enable label lookup from the rest api. >>> >>> On Fri, Oct 10, 2014 at 1:38 PM, Nir Simionovich < >>> [email protected]> wrote: >>> >>>> Well, >>>> >>>> Can I assume you are referring to the following section in the code >>>> (pbx.c): >>>> >>>> 12371 if (sscanf(pri, "%30d", &ipri) != 1) {12372 ipri = >>>> ast_findlabel_extension >>>> <http://doxygen.asterisk.org/trunk/db/de0/pbx_8h.html#0be9518646cf9aca4878b313cc02e901>(chan, >>>> context ? context : ast_channel_context >>>> <http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#582dee4d5ea9b2ff6f309f0c5239f6bd>(chan),12373 >>>> exten ? exten : ast_channel_exten >>>> <http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#a8b52fbc8168e939bc5553502367d46a>(chan), >>>> pri,12374 S_COR >>>> <http://doxygen.asterisk.org/trunk/d6/d90/strings_8h.html#38a896048b2ca84076864505f0aa8f01>(ast_channel_caller >>>> >>>> <http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#c2dc872b606534943c98304aed841b34>(chan)->id.number >>>> <http://doxygen.asterisk.org/trunk/d6/d49/structnumber.html>.valid, >>>> ast_channel_caller >>>> <http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#c2dc872b606534943c98304aed841b34>(chan)->id.number >>>> <http://doxygen.asterisk.org/trunk/d6/d49/structnumber.html>.str, NULL >>>> <http://doxygen.asterisk.org/trunk/dc/d7f/resample_8c.html#070d2ce7b6bb7e5c05602aa8c308d0c4>));12375 >>>> if (ipri < 1) {12376 ast_log >>>> <http://doxygen.asterisk.org/trunk/d1/d8c/logger_8h.html#cb8ee436a0c80c66dfcdec6b6bcc6196>(LOG_WARNING >>>> >>>> <http://doxygen.asterisk.org/trunk/d1/d8c/logger_8h.html#df4476a6a4ea6c74231c826e899d7189>, >>>> "Priority '%s' must be a number > 0, or valid label\n", pri);12377 >>>> return -1;12378 } else12379 mode = 0;12380 } >>>> >>>> >>>> If I read it correctly, line 12372 will translate a label to a >>>> priority number. >>>> >>>> Am I on the right track? >>>> >>>> Nir >>>> >>>> >>>> On Thu, Oct 9, 2014 at 6:39 PM, Scott Griepentrog < >>>> [email protected]> wrote: >>>> >>>>> If you want to add the label option, my first thought would be to >>>>> recommend you look at the implementation of app GoTo() for the api to >>>>> lookup/specify a label. Then you would need to modify the channels.json >>>>> in >>>>> rest_api/api-docs to specify the new/different parameters to the rest >>>>> methods, do a make ari-stubs to rebuild the rest handlers, and finally >>>>> make >>>>> the change to the method implementation in res/ari/resource_channels.c. >>>>> >>>>> On Thu, Oct 9, 2014 at 4:56 AM, Nir Simionovich < >>>>> [email protected]> wrote: >>>>> >>>>>> "Forgive me father for I have sinned, it has been over 25 years since >>>>>> I've used GWBasic/Basica - please spare thy humble servant from doom, as >>>>>> I >>>>>> repent my sins and go back in time 25 years" :-) >>>>>> >>>>>> Now seriously, this may work nicely for classic dialplan, but for AEL >>>>>> that's a no go - don't even want to think about LUA at this point. >>>>>> >>>>>> Any prospects in regards to this development? I've hadn't ever dug >>>>>> into this part of the code, but, how does Asterisk keep the dialplan in >>>>>> memory? is it a simple data structure? how do labels are manifested in >>>>>> that >>>>>> data structure? >>>>>> >>>>>> Point me in the right direction for the information (apart from the >>>>>> code itself) - and I'll have a look at it. >>>>>> >>>>>> Nir S >>>>>> >>>>>> On Wed, Oct 8, 2014 at 9:01 PM, Scott Griepentrog < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> The only two ARI methods I'm seeing where a priority is used are: >>>>>>> >>>>>>> 1) Channel origination (optionally sending channel to dialplan >>>>>>> instead of into a Stasis app) >>>>>>> >>>>>>> 2) Channel continue (jump out of application into a specific point >>>>>>> in dialplan) >>>>>>> >>>>>>> And yes, you are correct in pointing out that the continue is using >>>>>>> an int rather than a long, which is clearly a consistency mistake in the >>>>>>> API. >>>>>>> >>>>>>> In both cases, the priority is given as a part of typical >>>>>>> context/extension/priority method of addressing where exactly in the >>>>>>> dialplan you want to send the channel to. The most common scenario is >>>>>>> to >>>>>>> have a priority 1 as the starting point. The other numbers (using same >>>>>>> => >>>>>>> n) are then sequential but arbitrary, and it is generally not necessary >>>>>>> to >>>>>>> know what they actually are to jump to them directly. >>>>>>> >>>>>>> As you point out, labels in dialplan are a convenient way of >>>>>>> allowing dialplan execution to jump or goto a specific point without >>>>>>> needing to know the actual priority number. Unfortunately, the >>>>>>> implementation in ARI does not (currently) allow for a label to be >>>>>>> specified. This is a limitation that should probably be fixed - >>>>>>> possibly a >>>>>>> topic of discussion for Astridevcon. >>>>>>> >>>>>>> For a workaround, I would suggest using arbitrarily large priorities >>>>>>> to jump to the correct label where this functionality is needed. >>>>>>> >>>>>>> For example: >>>>>>> >>>>>>> exten => _x.,1,Answer() >>>>>>> same => n,GoToIf($["${GOTTAGONOW}" = "1"]?louie) >>>>>>> same => n,Playback(tt-monkeys) >>>>>>> same => n,Hangup() >>>>>>> same => n(louie),Playback(lyrics-louie-louie) >>>>>>> same => n,Hangup() >>>>>>> >>>>>>> exten => _x.,10001,GoTo(louie) >>>>>>> >>>>>>> On Wed, Oct 8, 2014 at 8:33 AM, Nir Simionovich < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Guys, >>>>>>>> >>>>>>>> While working on PHPARI, I've come to a realization that the >>>>>>>> channels REST API >>>>>>>> has a slight issue - primarily, its usage of the "priority" member >>>>>>>> in the REST API. >>>>>>>> >>>>>>>> Currently, the specification states that "priority" is either >>>>>>>> "int" or "long" (depending >>>>>>>> on the request). >>>>>>>> >>>>>>>> The problem with that is for someone like myself, who codes >>>>>>>> dialplan in AEL or >>>>>>>> using the "same => n," or the "exten => _X.,n," methodology - we >>>>>>>> have no visibility >>>>>>>> of priority numbers - we use labels. >>>>>>>> >>>>>>>> I'm not that familiar with the ARI part of the Asterisk code yet, >>>>>>>> as I'm focused on how >>>>>>>> to actually work with it, but this is somewhat of a show stopper in >>>>>>>> my book, as all my >>>>>>>> existing code relies heavily on label usage. >>>>>>>> >>>>>>>> Btw, I tried pushing a label into the REST interface, got a 500 >>>>>>>> error - which means >>>>>>>> it's designed to work with numbers and not labels. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Nir S >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> _____________________________________________________________________ >>>>>>>> -- 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> [image: Digium logo] >>>>>>> Scott Griepentrog >>>>>>> Digium, Inc · Software Developer >>>>>>> 445 Jan Davis Drive NW · Huntsville, AL 35806 · US >>>>>>> direct/fax: +1 256 428 6239 · mobile: +1 256 580 6090 >>>>>>> Check us out at: http://digium.com · http://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 >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> _____________________________________________________________________ >>>>>> -- 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> [image: Digium logo] >>>>> Scott Griepentrog >>>>> Digium, Inc · Software Developer >>>>> 445 Jan Davis Drive NW · Huntsville, AL 35806 · US >>>>> direct/fax: +1 256 428 6239 · mobile: +1 256 580 6090 >>>>> Check us out at: http://digium.com · http://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 >>>>> >>>> >>>> >>>> -- >>>> _____________________________________________________________________ >>>> -- 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 >>>> >>> >>> >>> >>> -- >>> [image: Digium logo] >>> Scott Griepentrog >>> Digium, Inc · Software Developer >>> 445 Jan Davis Drive NW · Huntsville, AL 35806 · US >>> direct/fax: +1 256 428 6239 · mobile: +1 256 580 6090 >>> Check us out at: http://digium.com · http://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 >>> >> >> >
-- _____________________________________________________________________ -- 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
