[asterisk-dev] Asterisk ARI improper usage pattern for channels REST API
Nir Simionovich
nir.simionovich at gmail.com
Fri Oct 10 13:38:19 CDT 2014
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 <sgriepentrog at digium.com>
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 <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
>
> --
> _____________________________________________________________________
> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141010/5741e727/attachment.html>
More information about the asterisk-dev
mailing list