See custom essay writing for the details.
The following is an email sent to asterisk-dev explaining the impetus for this project:
I know for fact that carriers in Israel hadn't adopted Asterisk fully
due to its lack of RADIUS/DIAMETER support.
Before we can begin on this project, we need to change the way we think
about Asterisk. Asterisk doesn't have perl, python, ruby, .Net, ftp,
smtp, POP3, pam, firefox, MS Word, Outlook, Exchange, SalesForce.com,
SugarCRM, 37signals, Google Docs, Excel, or Facebook support either.
There's two ways to fix this:
1) Fire up vi and write it all in C as a module for Asterisk. This has
been the traditional approach, and the various features in Asterisk done
this way are testaments to the efforts and vitality of the community. I
just happen to believe it's the wrong way to do it.
2) Give Asterisk a flexible programming API such that this functionality
can be done outside of Asterisk in a development framework. Apache +
Rails is a great example of this. Does Rails diminish the importance of
Apache? It does a bit, but imagine how diminished Apache would be if
you couldn't use Rails with it because it didn't expose enough of an API.
Now, this doesn't mean that the #1 approach is going away. Apache still
has mod_auth_radius. All I'm asking for is the *ability* to do it via
#2, which doesn't exist in Asterisk today.
TODO
The Asterisk Application Programming Interface (API) is a proposed architecture created with the goal of simplifying and unifying the various interfaces used today to create Asterisk applications. Asterisk applications in this context are not Asterisk dialplan applications as they exist today. This effort addresses interfaces that provide the ability to build applications that use Asterisk as the telephony engine.
Below is a graphic that represents the key layers of the proposed new architecture.
The above will allow for an Authorization API to be created, with empty calls at the start of the development
and we'll add functions and calls to it as we go along the way. -- Nir S
Judging from the latest responses on the mailing list and the importance of the subject, I believe that before approaching the actual problem of how to do it, we must first decide on what is actually related to what. Both oej and Tzafrir had brought up interesting points in relation to call control security, signalling access security and various other issues directly related to Asterisk internals. In my view, the API must first provide the basic security granularity for 3rd party telephony application developers (aka: AGI script writers and IVR developers). My thought is to seperate the single Authorization API into 2 distinct API structures, one used primarily for 3rd party application developers and the other used for direct connections into the core.
Consider the following diagram (excuse the change of colors):
In the above diagram, I've seperated the authorization API's, dictating that we first concentrate on the data_get, data_put, events and call_api which are currently not only lacking security, but also lack proper support. I'd really love to see a data_get interface, that would enable me to throw my Manager lookup callbacks, however, introducing a proper security structure for that would be amazing for phase 1. Then continue the work from that point onwards. I believe the issues indicated by Ph.1 - 3 can be accomplished using the current code base. Once we tackle the problem in that arena, we will be able to deduce what is required for ast_pbx and the hooks interfaces and then do it properly. -- Nir S
We can't simply put an authorization layer attached to the API, because many actions that potentially require authorization may happen indirectly. A channel may be generated. Two channels may be bridged. Channel may use a codec. Channel may use a function. A channel may initiate an AGI script or an external process.
As you note, in my view it is the channel that does everything. I think that this is how Asterisk is built. Channels hold the context of everything. If we have an authorization layer that is not strongly tied to what channels are authorized to do, we will have the same issues as we have today with the manager interface: the interface does not have the knowledge to manage authorization.
My basic perception of this is of a sort of an "operating system" where the channels are the processes and anybody that connects through an interface are users. -- Tzafrir
These six elements are needed in the core of asterisk to provide the functionality to the API modules to control all aspects of Asterisk.
The PBX interfaces is the existing infrastructure that provides the following functionality:
Notes:
The events subsystem will be the base for all manager events, as well as provide events to other components in asterisk such as CEL logging, MWI, and devicestate notifications.
The event subsystem has already been implemented. Here is the relevant code for the core event system:
Here is the doxygen documentation related to the existing events framework internal to Asterisk:
Changes Needed:
The data_get interface will supply an abstract way for modules to provide data to various components in asterisk including: manager, cli, dialplan, res_snmp, etc. A namespace in asterisk will be used to reference the various providers of data, as well as a mechanism for discovering which namespaces and data are supplied.
Code:
Notes:
The purpose of this mechanism is to enable an API for modifying all asterisk configuration, regardless of backend storage. This will remove the need for asterisk configuration frameworks to have to generate config files. While realtime allows some of this, the data_put interface solves the problem of changing the database underneath Asterisk, since Asterisk will be aware of all changes and be able to respond to them (eg: flush a sip_peer from the cache when it's deleted).
level, than the mutex solution will do just fine. If the granulatry is at the configuration_object level, a simple mutex will not suffice. -- Nir S
Hooks are arbitrary callbacks within the internals of asterisk where external components can modify asterisk's behavior. While the dialplan allows applications to control much of the asterisk behavior, hooks allow for business logic to be applied to situations that are not associated with a call (eg: a sip registration hook could allow time-goverened registration period), or for situations that occur during the execution of a diaplan application (eg: codec negotiation hook to apply business logic to codecs proposed in the middle of a Dial command, or a transfer hook to execute business logic when a SIP REINVITE is received).
The call api encompasses all of the things available in the core of asterisk to modules for controlling calls. There are two facets of the call api:
API layer modules may want to directly call methods such as ast_do_masquerade(), or ast_hangup() in order to control the behavior of the system.
Some modules may export specific methods to the API layer that facilitate calling directly by the frameworks. An example of this is the manager command Originate, or the Bridge command. Most manager commands that actually execute an action should be redefined as an api-exported method, such that they can be used by manager, the cli, as well as all of the other API layer interfaces such as mod_json. There probably won't be much difference between the syntax of defining a manager command and defining an api-exported method, aside from the data returned will be more structured (ala data_get).
These modules will export the mechanisms of the API support components to external applications.
This module will provide a socket-based API to external applications. Ideally, this interface will be abstracted in order to better provide an API contract with external customers. This will allow us to potentially change the underlying support component implementations without breaking API compatability with third-party applications and frameworks.
It's possible to embed a high-level language interpreter directly into asterisk which will be able to control all aspects of the PBX. pbx_lua is an example that uses the existing struct ast_switch interface to implement a dialplan in lua. Future language bindings will go beyond just the dialplan and be able to play a part in all aspects of Asterisk's behavior using the API Components.
Another API layer would be a thin RPC layer that would communicate over standard RPC mechanisms such as Java RMI, DBUS, CORBA, etc.
This is an API layer that implements an http server that delivers JSON-encoded data to http requests.
I'm leaning towards ASN.1 via asn1c for res_api and probably russell's internal structure for internal data_get representation (unless asn.1 is usable for the internal stuff too) -bmd