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
