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

Nir Simionovich nir.simionovich at gmail.com
Thu Oct 9 04:56:03 CDT 2014


"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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141009/c98de101/attachment.html>


More information about the asterisk-dev mailing list