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 –
Dialer API –

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.

When I last reviewed the PIKA WARP Asterisk appliance, I  named the post “Pokemon Asterisk” – today I’ve decided to review the PIKA WARP Asterisk appliance again, only this time, with the newly released Asterisk GUI 2.0 release – our cuddly Pikachu is now a Raichu (relax, it took me about 30 minutes to find out what a Picachu evolves into).

The new PIKA appliance now boasts the new star fangled Digium Asterisk GUI 2.0, which takes the old Asterisk GUI (which was OK, but still had some miles to go) and more or less throws it into the waste bin. The new GUI is far more useful, far more usable and most importantly – makes life way easier for the integrator. While the previous version of the PIKA Warp appliance was targeted for developers, the new version of the WARP is aimed directly into the heart of the integration scene.

Asterisk GUI 2.0 on PIKA WARP

Asterisk GUI 2.0 on PIKA WARP

Now, I have to admit that after upgrading the system to the new PIKA WARP cuImage I had some issues logging into the system. So, what I did is more or less hack myself in via ‘single user mode’. Here’s a small guide on how to do that. Before we being, you will require a serial cable connection to the WARP appliance in order to do this, which means, this is more or less a hardcore procedure.

The PIKA WARP Serial Connector Port

When the system boots up, and you are confronted with a message saying “Hit any key to stop autoboot:” simply hit any key on your keyboard, and you’ll be fronted with the “=>” prompt, indicating that the boot loader is now waiting for information. Now, we need to tell the PIKA WARP appliance to boot into single user mode.

To do so, we need to modify the ‘ramargs’ environment variable of UBOOT, to indicate that we want to start single user mode. Enter the following command:

setenv ramargs setenv bootargs root=/dev/ram rw ramdisk_size=130000 single

This will indicate to the UBOOT loader to initiate a single user mode bootup. Once in single user mode, you can use the ‘passwd’ command to change the root password of the PIKA WARP appliance. This procedure can be used by an other PIKA WARP based appliance.

Once of the nice additions in the new Asterisk GUI 2.0 is the support for Class of Service, which doesn’t really exist in FreePBX. In many offices, managers like to restrict various extensions from accessing different parts of the telephony system – that is performed utilizing the Class of Service screen.

Class of Service management

Class of Service management

The “Class of Service” management enables you to create groups with access to specific trunks or PBX functions, thus, enabling you to seperate users and groups of users from specific PBX resources. For example, some users can be completely restricted from using outbound trunks, while others can be restricted to using a single FXO interface out of 4 connected FXO interfaces. In general, this is one of the best features in the GUI yet in my opinion.

I’m currently reviewing the new version, so once I have new information I’ll post my findings.

Ok, it’s been almost 24 hours since I started my serious playing around with Amazon EC2, and I can honestly say that I’m tired – however, I’m very pleased with my results. Like any other experiment, this one started with a requirement. The requirement was to install and operate one of the dialer frameworks I’ve written in the past year on an EC2 based instance. In order to evaluate the process, let’s start with our baseline installation, meaning, what am I using in the real-world:

Hardware and Software Specification

The original machine answered to the following specification: Quad Core CPU, 2GB of RAM, 250GB of Hard Drive. My original machine was running CentOS 5.2 with an x86_64 kernel installed. In terms of software installed, we had Asterisk, MySQL 5.X, PHP, FreePBX, Apache and my dialer framework.

Introducing Amazon EC2 AMI

An EC2 AMI is basically an image of a computer, contained with a single installation manifest on the Amazon cloud computing system. AMI’s provide for the simplest manner to start using EC2, as these usually include a pre-defined server installation, that usually has some stuff already installed.

Choosing your AMI

Amazon provides a multitude of AMI’s to work with, unfortunately, most of these are either out-dated and the sheer number of these makes the choice somewhat overwhelming. I decided to start working with a working AMI image of Fedora Core 8, that already had the LAMP stack installed – the one I used was:

LAMP Web Starter
LAMP Web Starter (AMI ID: ami-ba4eaad3)
Fedora Core 8, 32-bit architecture, PHP 5.0.4, Apache 2.0.54, and MySQL 4.1.20

The YUM Repository issue

For some strange reason, the AMI images contained in the Amazon repository are all unable to perform any updates to their installed RPM packages. It took me a while to understand what’s wrong, but in general, the fedora project had simply removed the old releases from their repository, so I had to go in and manually modify the /etc/yum.repos.d/ configuration files. For you convenience, here is the repos list that I’m using at this point:

YUM Repositories for Amazon EC2 Fedora images <- click this to download the file

name=Fedora Core $releasever - Development Tree
name=Fedora Extras $releasever - Development Tree
name=Fedora Extras $releasever - $basearch
name=Fedora Core $releasever - $basearch - Test Updates
name=Fedora Core $releasever - $basearch - Released Updates
name=Fedora Core $releasever - $basearch - Base

If you are trying to install an instance, you may use the above for any Fedora based AMI on EC2.

Creating my own AMI

While going about and building a single server is fun, I needed a way to create my own installation AMI once I’ve completed my modifications. The Amazon EC2 resources website gives out a whole lot of information, which can be somewhat confusing for the first time reader. So, I searched for a better way to construct my own AMI image. I found the following web page, which was really really helpful: Azeez’s Notes.

Azeez’s blog gives a very concise and to the point, step by step, guide to building your own AMI image – it got me up and running in less than 10 minute – WAY TO GO AZEEZ.

So far, so good …

So far my installed instances are working just fine and I’m currently operating a cluster of a few of these dialer systems. I’m in the process of checking what kind of mileage I’ll get from the EC2 instances, in comparison to a real hardware server – which is really interesting.

My main objective here is to be able to build a dialer-on-demand framework, which will enable my customers to increase their capacity utilizing a simple web interface to initiate my AMI instances. I’ll report back with additional information once I have it.

I really like marketing spins, there is nothing more amuzing than a good marketing spin – especially when its being performed by a big company. Israel, as much as I don’t like admiting it, is one of the world’s biggest spin experts, especially when it comes to technology and marketing. One of my best friends used to work as a marketing manager at a high-tech company. According to him: “We can take each and every product of ours and resell it as 5 different products, it all depends on the customer required spin that we need to display!” – well, putting marketing aside and going back to technology, Sangoma recently announced 2 new Hybrid interface boards for Asterisk.

The boards are called: “B600” and “FlexBRI”. Let us examine the spec on these:

Sangoma B600 Board

The Sangoma B600 board boasts 4 Analog FXO interface and a single FXS interface. The combo is very interesting, as it enables a small office to utilize up to 4 inbound analog trunks, while connecting their FAX machine directly to the board itself, allowing for better fax transmission without relying on T38 and other Fax-Over-IP methodologies.

In general, I believe that the card density and idea is good. While many people believe that Sangoma competes head-on with Digium, I believe that this product has nothing to do with the Digium/Sangoma race. In my view, this board actually tackles the same niche market as the PIKA WARP appliance, as it boasts a similar perspective in terms of connectivity. I don’t believe this is a spin, as this product has a valid market share, especially in upcoming markets such as Africa. With a boasting price of around the 400US$ mark, I believe the card will gain popularity with the small TrixBox/Elastix/PBX-in-a-flash fly-by-night integrator scene, as it fits that niche fairly well.

Sangoma FlexBRI

Ok, the Sangoma FlexBRI card, at least from where I’m standing, in nothing but a worthless spin. It boasts 4 BRI interfaces and 2 analog interfaces (FXO or FXS). Why do I call it a spin? well, simply because I hadn’t seen a BRI installation in the past 4 years. I figure that Sangoma in now tackling the German market, especially the one being catered by the card made by Junghanns, however, these provide a fairly strange combo. In any case, the niche here is very much target to a select number of countries in the EU, so the validity of this product in the world is close to null – thus, I call this one a pure spin. The marketed price is yet to be revealed, however, judging from the density and the functionality of such a card, I’m not sure its price will allow it to be a valid market option. In addition, with the PIKA WARP ISDN appliance that is due to be out later this year, there is a high chance that this product’s voice will be nulled by an appliance of same density and easier integration.

Yeastar YE110 – Single Span E1/T1/J1

Yeastar is a chinese manufacturer, making Asterisk compatible boards for the Analog market. The YE110 is their first attempt at approaching the highly growing market of the E1/T1 circuits market. According to the website, the YE110 is fully compatible with the Zaptel drivers, thus, it doesn’t require any driver patches – which is a wonderful thing. We still have to learn about the stability and capabilities of this card, however, as it uses a similar chipset to the old Digium TE110P card, I suspect we’ll notice similar performance and capabilities – yet to be seen.

PhonicEQ cuts price by almost 40%

PhonicEQ had cut their prices by almost 40%, across their entire product line. Now, I admit that I’ve used their products and I was fairly happy for a while – however, as Zaptel versions progressed and Zaptel turned into DAHDI, PhonicEQ didn’t issue out any new drivers and updates – so I had to patch my own versions of the driver.

In my view, PhonicEQ cards needs to regarded as: “The poor man’s Asterisk card” – if you can’t afford anything else, then go with PhonicEQ. You’re probably wondering why I’m saying that, after all, everybody who knows me knows that I’m strongly affiliated with Digium. Well, when I started my business, I couldn’t afford a Digium card, even used cards were fairly expensive, I have a distinct issue with the Sangoma distributor in Israel (so I’ll never use Sangoma) and PhonicEQ seemed like a good choice at the time. I purchased the card, only to realize that I need to massively patch Zaptel in order to get it to work (something that wasn’t said on the site). For me, patching Zaptel and Asterisk isn’t anything new, so it took me about 30 minutes and I was up and running, no problem. However, for most Asterisk users, this may be a slightly more advanced task than others. In any case, PhonicEQ is still considered in my book as “The poor man’s Asterisk card” – use it only if you have no other choice.

ITExpo 2009 – Miami Beach, Florida

Well, it’s now official, I’ll be lecturing at ITExpo about utilizing Asterisk and VMWARE as a dialer framework for high-speed dialer services. If you will be in Miami for the conference and you’d like to meet, just look me up. I’ll be landing on the 2nd, so I guess i’ll only be up and running (pending jet-lag) on the 5th. C’ya all there …

As if my previous post was’t enough, this week the ever annoying bad rep of Open Source in Israel showed its face yet again. This time, I’m talking about a recent talkback on the online magazine website. The talkback was related to an article relating to various telecom tenders currently in progress in Israel. As part of the article, the authod mentioned the existance of a new Call Center solution for Asterisk from EasyRun – one of the world’s better known call/contact center solution providers – being in the market for over 15 years now.

Here is a screen shot of the post:

For those not speaking Hebrew, I’ll translate. Talkback number 1 is from Alexander Argov, CEO of Tikal Networks informing the public that Tikal Networks also has a call center solution based on Asterisk, with a link to the demo. In itself, there’s nothing wrong there in my book – however, it would appear that others don’t agree. Number 3 says: “Well, if you are a part of this party, why do you need to advetise in a talkback?”, only to be followed by: “Well, Tikal is a Me-Too as always – nothing new there”. Well, comments will be comments and talkbacks will be talkbacks. However, numbers 6 and 7 are something else. Number 6 excuses Mr. Argov and his Sales VP (a Mr. Harari) as providing poor service and a poor product, warning people not to purchase Tikal based prodcuts. Now, number 7 goes the distance saying: “Selling a product that costs a single shekel for tens of thousends of shekels and giving poor service is something any 7th grade student can do. Don’t touch the solution provided nor any Tikal product”. Number 7 is currently simply stating: “Don’t touch Asterisk, the service is not good”. Number 7 seems to be incapable of distinguishing between the Tikal product line and Asterisk, and for him, they are one and the same. The end result is a bad rep for Asterisk, while the bad rep is actually intended to the solution provider in this case.

It would appear that in Israel, people mix up FreePBX, Asterisk and the solution provider as one and the same. The solution provider goes about saying: “I’m selling an Asterisk product, I’m state of the art!”, using the Asterisk name to leverage the sale. The customer belives that what he’s buying is actually Asterisk, while the only thing he’s actually buying is the integration service and support service. As long as people in Israel don’t realize that Open Source solutions mean: Free Software (Free as in Beer), Paid Support and Professional Services – the situation will remain the same for ever.