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/
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
