Codename Pinemango



 

Introduction -- The Asterisk Applications API

 

Why are we doing this

 

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.

 

Overview of Issues with the Current Interfaces

 

TODO 

 

Proposed New Architecture

 

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.

 

 

Asterisk Applications API Support Components

 

These six elements are needed in the core of asterisk to provide the functionality to the API modules to control all aspects of Asterisk.

 

Extensions and Application Execution (ast_pbx)

 

The PBX interfaces is the existing infrastructure that provides the following functionality:

 

Notes:

 

Generic Event System (events)

 

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:

 

Data Retrieval Interface (data_get)

 

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:

 

data_put

 

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).

 

 

hooks

 

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).

 

call api

 

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:

 

internal asterisk methods

 

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.

 

api-exported methods

 

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).

 

API Layer Modules

 

These modules will export the mechanisms of the API support components to external applications.

 

res_api

 

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.

 

language bindings

 

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.

 

RPC

 

Another API layer would be a thin RPC layer that would communicate over standard RPC mechanisms such as Java RMI, DBUS, CORBA, etc.

 

mod_json

 

This is an API layer that implements an http server that delivers JSON-encoded data to http requests.

 

Things to Consider