Asterisk 3rd Party API – and their importance

As some of may know, I spend most of my time working as an Asterisk Developer and Consultant in my own company – called Greenfield Technologies Ltd. – named GreenfieldTech for short. Since the day I started my company I knew a few facts and truths:

  1. GreenfieldTech starts as a one man operation – thus, spending more than 15% of my day to day tasks on support issues will surely stress me out and drive my business to the ground.
  2. I don’t really want to deal with PBX installations and various office telephony aspects of using Asterisk – simply because it requires to much of item 1.
  3. I need a way to be able to provide a fast response to my customers, maintain a low support over head and make sure that what ever I do, it can be accounted for.

Hence the above, I understood that GreenfieldTech‘s products are not really the various services it provides, but actually the products vary completely from what a product looks and feels like. I understood that in order to provide this fast development turn-around I needed my own development framework. Surely PHPAGI, Adhearsion and Asterisk-JAVA can easily provide for a development framework – but it still doesn’t help me one bit – I needed something different.

I then realized that GreenfieldTech‘s products are the one product line that all developers and vendor steer away from: Programmatical API frameworks. The programmatic framework should provide the most basic feature set, allowing it to be extended and continued onwards at ease. Hence, the suite of GTx API frameworks were born. A set of 3 different APIs provide all the facilities required for building any of the below:

  • Dynamic IVR structures – driven via web services
  • Recording systems
  • Pre-Paid/Post-paid solutions
  • Inteligent Network (IN) services
  • Automatic Dialers – Predictive, Power, Progressive, Preview
  • Broadcasting systems
  • and more …

The entire API suite is based upon XML-RPC based web services. When I introduced XML-RPC to one of my customers, he immediately indicated: “But, XML-RPC doesn’t really provide for session oriented persistency. Why are you using XML-RPC?” – The reason is simple – we don’t need session persistency in the API – Asterisk can provide all of that internally. Thanks to Asterisk’s channel oriented architecture, we can regard each of Channel thread in Asterisk as a seperated data container, capable of holding all your session information and persistency information at ease.

Recorder API – http://www.greenfieldtech.net/products/gtrapi
IVR API – http://www.greenfieldtech.net/products/gtvapi
Dialer API – http://www.greenfieldtech.net/products/gtdapi

The best thing about the GTx API suite is this – they are all interconnected. For example, call being handled by the Dialer API can be then handed over to the IVR API, operating within the same Asterisk server or a remotely located Asterisk server (via SIP/IAX2).

In the time to come, I’ll be showing you various XML-RPC structures and example of how to use the GTx API suite, and do all sorts of interesting IVR and Dialer structures.

Leave a Reply