[asterisk-dev] Asterisk ARI improper usage pattern for channels REST API

Scott Griepentrog sgriepentrog at digium.com
Thu Oct 9 10:39:43 CDT 2014


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 <nir.simionovich at gmail.com>
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 <sgriepentrog at digium.com
> > 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 <
>> nir.simionovich at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141009/b1db23b6/attachment.html>


More information about the asterisk-dev mailing list