[asterisk-app-dev] ARI Channel-Exec Suggestion

[Alistair Cunningham]

On 18/02/14 05:38, Matthew Jordan wrote:
> Thinking about the concept of transfers:
>
> * Today, if a SIP transfer occurs, the channel is removed from the
> currently executing AGI and transferred to the specified destination.
> When that occurs, for all intents and purposes, it looks like the
> channel has hung up and returned to the dialplan. The same is true for
> Asterisk's feature transfers - if you Dial from an AGI and you allow
> blind transfers, the blind transfer will not return the channel to the
> AGI - it will return it to the dialplan. The act of transferring a
> channel from an external process or an internal process is completely
> dialplan dependent today.
>
> * ARI has the same behaviour as AGI, with one key difference: right
> now, there is no mechanism to use the features. Instead, you can
> implement your own features by capturing the DTMF and choosing to take
> some action. While you could release the channel back to the dialplan
> - or send it to Park - you could just as easily create your own
> 'blind', 'attended', 'parking' - or virtually anything else.

Which is great for billing systems, because the ARI application knows 
exactly what's going on and can bill accordingly. It also makes it easy 
for multi-tenant systems to have different behaviour for different 
customers (different transfer codes, etc).

> In this
> regard, ARI has the same limitation as AGI - and externally initiated
> transfer will trigger the same results - but is more flexible
> internally. Note that you can always prevent externally initiated
> transfers at the channel driver level, if you wish.

SIP REFER transfers is one of the main areas I need to research and 
check we get the information we need to bill all calls reliably.

>>> (2b) Remote execution of other dialplan applications opens up a whole
>>> world of permission escalation vulnerabilities. For example, would it
>>> be allowable for me to run the System dialplan application through
>>> that exec statement?
>>
>> Don't we already allow that in AGI?
>
> Yes, I'm not sure it's such a good idea. :-)
>
> AGI "gets away" with this by not having any permissions - it's hard to
> have a permission escalation vulnerability when there are no
> permissions! ARI has authentication with some very coarse grained
> permissions (read/write). Since we authenticate and provide
> permissions, it by its very nature opens us up to possible permission
> escalation vulnerabilities. I don't think that's a bad thing, but it
> is something to keep in mind. I do feel like we avoided the worst of
> AMI's flaws by not implementing nearly arbitrary authorization levels
> that don't have a logical mapping in the core - but it's worth keeping
> in mind that the dialplan is powerful. Asterisk is powerful. I'm not
> sure we need system altering power exposed through an external facing
> interface.

Fair enough.

>> AGI(), because we support AGI user plugins.

Any thoughts on this one? I guess it would be complex. One solution 
might be to have the Statis app create an outbound local channel, 
passing the parameters somehow, and then having dialplan retrieve the 
parameters and invoke AGI().

>> Echo()
>
> You could probably create Echo in a perverse fashion using some
> convoluted bridges and Local channels, but otherwise, currently there
> is no way to create an Echo loop on a channel. (How useful is this
> really - or is a channel getting put into Echo merely to hold it
> forever?)

We only really use it for testing purposes, and I suspect that's true of 
most people who use it.

How about an echo bridge type?

> * SendFax/ReceiveFax are highly specialized for specific types of
> calls. Once a call has been determined to be servicing a fax, it's
> usually only going to get dropped into one of these two applications
> and then the call doesn't do much else. There's little business logic
> in these applications as well - other than knowing whether or not it
> worked and doing something with the resulting fax, you basically just
> want it to either send the image or receive it. Since the goal for ARI
> is to allow people to implement business logic outside of Asterisk -
> and these two applications by the nature of what they do eschew much
> business logic in the first place - there's not a lot of value in
> putting them in ARI, save to prevent someone from writing any
> dialplan.
>
> I wouldn't say that we would never put a /fax resource in ARI, but
> that doesn't feel quite as important as some of the others.

It would be good to make these "first class citizens", particularly as 
they're a commercial Digium product. If not on the cards, perhaps the 
outbound local channel idea, as for AGI() above, might be feasible.

> * AMD - as I mentioned above, this one is odd. I'd put Zapateller in
> there as well. I'd have to think about that one some more.

How about a parameter to switch on AMD when doing operations such a POST 
/channels to create a new outbound channel? If an answering machine is 
then detected, an event can be raised.

> But think about it this way: out of all of the Asterisk applications
> you listed, there's really only three that are not readily doable, and
> all three of those are highly special purposed.

Yes, I'm pleased to see how many of the Asterisk applications we use are 
already possible. I agree that we're down to the special purpose ones. 
Many thanks for such a detailed review of the list!

-- 
Alistair Cunningham
+1 888 468 3111
+44 20 799 39 799
http://integrics.com/