[asterisk-dev] Asterisk ARI improper usage pattern for channels REST API
Nir Simionovich
nir.simionovich at gmail.com
Mon Oct 13 06:39:55 CDT 2014
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 <nir.simionovich at gmail.com>
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 <
> nir.simionovich at gmail.com> 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 <
>> sgriepentrog at digium.com> 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 <
>>> nir.simionovich at gmail.com> 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 <
>>>> 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
>>>>>
>>>>
>>>>
>>>> --
>>>> _____________________________________________________________________
>>>> -- 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/20141013/2aebfd0a/attachment-0001.html>
More information about the asterisk-dev
mailing list