Well, it’s finally out – my new book that is

Some of you already know, but over the past year I’ve been busy writing a new book. This time it’s a book for Asterisk developers, especially tailored to PHP developers wishing to utilizing the PHPAGI framework. The book is out from Packt Publishing (Like my old AsteriskNOW book) and is updated with all the recent changes in Asterisk – including version 1.6.X and DAHDI.

Asterisk Developers Book

If you like my work with Asterisk and would like to read more of my work, go ahead and get an electronic version of this book. I know it’s a little self promoting, by hey, it never hurts does it?

I’ve included a chapter on how to build a complete project from scratch, detailing the various analysis steps and various paradigms required to develop a fully functional Asterisk based application. I believe that even experienced Asterisk developers will benefit from this book.

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 1.4.22.1, 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:

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

[development]
name=Fedora Core $releasever - Development Tree
baseurl=http://archives.fedoraproject.org/pub/archive/fedora/linux/core/development/$basearch/
enabled=1
gpgcheck=0

[extras-development]
name=Fedora Extras $releasever - Development Tree
baseurl=http://archives.fedoraproject.org/pub/archive/fedora/linux/extras/development/$basearch/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras
gpgcheck=0

[extras]
name=Fedora Extras $releasever - $basearch
baseurl=http://archives.fedoraproject.org/pub/archive/fedora/linux/extras/$releasever/$basearch/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras
gpgcheck=1

[updates-testing]
name=Fedora Core $releasever - $basearch - Test Updates
baseurl=http://archives.fedoraproject.org/pub/archive/fedora/linux/core/updates/testing/$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-test

[updates-released]
name=Fedora Core $releasever - $basearch - Released Updates
baseurl=http://archives.fedoraproject.org/pub/archive/fedora/linux/core/updates/$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora

[base]
name=Fedora Core $releasever - $basearch - Base
baseurl=http://archives.fedoraproject.org/pub/archive/fedora/linux/core/$releasever/$basearch/os/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora

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.

Ok, it goes without saying: “A2Billing is one of the most complete Calling Card systems in the Asterisk market today.” – on the other hand, it is also true that: “A2Billing is one of the most complex and convoluted pieces of code ever written!”.

The combination of the above makes for a fairly combustible mixture, especially if you have a big system. Now, I recently ran into an issue, where PHP was litterally eating up almost 512MB of ram, in order to run the A2Billing reports. In it self, that didn’t make much sense to me. However, after inspecting the code, and realizing that A2Billing uses GD in run-time to generate images out of thousands of CDR records, it made perfect sense that it may just be eating up memory.

So, increasing the memory on PHP to go up to 512MB of RAM helps, but creates an interesting probelm. Whenever Apache will invoke a script, it will automatically consume a shitload of RAM, and for each time I intiate a new query, it will spawn a new Apache instance, and consume the same amount of memory. That said, after 6 queries of 512MB, about 50% of the machines RAM was already eaten up – and Apache will not free it!

At this point, I had 2 choices:

1. Go into the A2Billing code, change the GD code to work right or simply change it completely to something else (maybe flash).
2. Work around the problem with a mix of proper IT practices.

I admit that I hate quite a lot of things (I won’t list these here); however; nothing ranks up the list as modifying someone elses code, when I know for fact that it will be unmaintainable in the future. So, I choose option number 2.

I’ve being playing alot with Lighttpd lately, and got some really nice performance from it. So, I said to myself, this would be a great test to see if Lighttpd+FastCGI can solve the problem here. I had to work my way around lighttpd to do what I wanted and verify that my FastCGI server in Lighttpd doesn’t consume all memory, however, here is what I got working with A2Billing, and really nice.

Step 1: Enable the required modules:

server.modules              = (

                               "mod_access",

                               "mod_auth",

                               "mod_status",

                               "mod_fastcgi",

                               "mod_accesslog" )

Step 2: Enable the FastCGI Server

fastcgi.server             = ( ".php" =>

                               ( "localhost" =>

                                 (

                                   "socket" => "/var/run/lighttpd/php-fastcgi.socket",

                                   "bin-path" => "/usr/bin/php-cgi",

                                   "idle-timeout" => 30,

                                   "max-procs" => 1,

                                   "min-procs" => 1

                                 )

                               )

                            )

Step 3: Modify user permissions (required if you are using FreePBX)

server.username            = "asterisk"

server.groupname           = "asterisk"

Step 4: Setup authentication and authorization (optional)

#### auth module

## read authentication.txt for more info

auth.backend               = "htpasswd"

auth.backend.htpasswd.userfile = "/var/www/.htpasswd"

auth.require               = ( "/" =>

                               (

                                 "method"  => "basic",

                                 "realm"   => "A2Billing Management",

                                 "require" => "valid-user"

                               )

                             )

The above configuration made the interface spwan a single FastCGI, insuring that memory usage is never over utilized. I still need 512MB of RAM to run the scripts, but at least now it’s limited to only 512MB of RAM, out of a machine that has 16GB of RAM.

I’m not much of an economist. I understand income and expenses, I understand more or less how the stock market works from time to time, but I’m no economist. I’ve been in the hi-tech industry since early 1997, which means, that I’ve seen this world being elevated to the level of godly hood, buried alive with the explosion of the dot.boom era, only to re-invent itself as a highly competitive telecom’s industry and the “Network is the Computer” manner of thinking.

About 2 weeks ago, a man I truely admire had written a post entitled: Economic Meltdown – Friend or Foe of Open Source? (written by Danny Windham, CEO of Digium). Danny talks about the various aspects of companies cutting down on their IT budgets and reversion to Open Source technologies, as a means to hedge needed cash. As I witnessed the Dot.Boom explosion of 2001, I can honestly say that 2001, at least as far as I can say, was the year that Open Source technologies had truly assimilated to the normal business practice of companies. Even beyond that, companies which were not based on Open Source and Linux/Unix based technologies were clearly not a valid option for investors.

One of the urban legends talks about Hotmail wishing to acquire an Israeli company called Commtouch, back then, a webmail company. Commtouch was purely based on Windows NT technologies back then, and while the business track of the negotiations were going fine, the deal collapsed as the technical sides, of a back then BSD based Hotmail, basically negated the deal. Now, I have no idea if the story is true or not, again, this is an urban myth, however, I believe myths are usually based on some portion of the truth - at least to an extent (even a small one).

While the adaptation of Open Source technologies is a must for companies, in order to survive the troubled waters of these time, it is highly dependant on the solution providers, consultants and IT outsourcing companies. In Israel, for example, it is very much a customary to hire outsourced IT assistance, on a part time basis, allowing you to cut your IT costs. When bringing in IT assistance, you’re not only bringing in IT assistance, you also bring in IT governance and IT policies – as an outsourced IT person will usually operate under the terms he had learned in his company. If his company is a M$ oriented company, no matter how Open Source will be crucial to the business, M$ will still rule the domain in that area. I believe that the first thing that needs to happen is for the consulting and IT outsourcing companies to realize that they need to change, first for their customers, then for themselves. If the small start-up companies and established companies will start falling, the consultants will simply dry out of work.

It is our responsibility as IT/Telecom/Development/Architecture/Design consultants to explain the aspects of using Open Source, assimilating it, integrating it, both the pros and the cons and then, assist our customers in doing so successfully – this is the only way to go.

For example, let us take examine the following scenario – a telephony service provider. Our telephony service provider is based on Asterisk as the switching environment, a purely M$ base for all the billing, web front-ends, databases, development and so on. Their entire IT infrastructure is fully owned by them, all running with ESX servers and other proprietary technologies. This company will be required to pay hundreds of thousands of dollars every year, for support purposes (and the year is coming close to an end), their expansion is highly dependant on 3rd parties and while they are self sufficient on the IT side, they are purely dependant on the technology side. Now, imagine that this company would have had their entire back-end based on Open Source technologies, let’s imagine PostgreSQL and Ruby on Rails as the web frame work, how much money will that save per year? now, let’s remove ESX out of the equation… let’s also remove non-Open storage solutions and replace those with CoRAID or something similar, we’ve saved hundreds of thousands of dollars on an annual basis. Radical? – YES! But drastic times call for drastic measures, and when drastic measures are required, Radical solutions are a must.

Over the past 12 months, I’ve been heavily involved in the development of high-speed dialers. While many companies published a prolific number of automatic dialers (power, predictive, broadcast) – none of these companies ever announced there top speed dialing capability.

An so I ask myself: “What is the reason not to release these numbers publicly?” – interesting, isn’t it. So, I decided to experiment myself and see if I would release public numbers for my dialer. I’ve designed my dialer to be capable of generating upto 35 calls concurrently. My questions was this: “While the dialer is fully capable these numbers in a test scenario, will this number be reached in real life?”

So, I started experimenting with my code – doing a very simple test. I’ve installed my dialer on a Dual Quad Core system, 8GB RAM, and a RAID-1 array as the storage. Now, I’ve setup the system to generate up to 35 calls every second, allowing the server to sustain a total of 180 concurrent calls – 360 channels.

What happend was actually this: the dialer generated about 180 dials within a period of about 8 seconds, and then, simply waited till some of the calls completed in order to generate additional calls. Ok, that is understandable, however, what is the throughput of the dialer? So, I decided to do another test, I filled up my queue with a total of 50,000 records. In addition, I’ve arranged with my carrier to terminate the calls to on of their SigValue systems, to sustain the enormous number of inbounds. In addition, I asked them to perform a small measurement of the average call inits per second. I was shocked with the result!

While the dialer simply peaked upon startup, after 20 seconds of operations it started normalizing at around 6 call initiations per second. But how can that be? how can it be that a dialer capable of dialing 35 calls is slowed down to crawl? – the reason is simple, the latency imposed by the PSTN/VoIP network, the time it takes for the calls to terminate and the actual time the call is left on the air, while the dial happens. All these factors together had given me the notion that there is no practical top speed, as it is in direct relation to the demographics of the dialer operations.

Having said that, is it possible to devise a formula to calcualte this number on a per demographic basis? maybe on a per PSTN/VoIP carrier type? maybe a combination of the both? will a formula such as that will enable for the better creation of broadcast/predictive dialer? – no use dialing tons of number into a demographic that can’t handle it, while at the other side of the spectrum, what demographics will benifit from the utilization of an automated dialer?

For a while now I’ve been toying around with the idea of utilizing Lighttpd for various web based applications. One of these application is my Automatic Dialer framework, also known as the GTD-API. The main issue with the GTD-API (besides that it is highly reliant on a MySQL database), is the fact that all requests have to be processed via XML-RPC HTTP post requests.

The main issue that I had was this: in a production scenario, a dialer management system will generate over 100 requests to the XML-RPC server. While Apache is fully capable of rendering services at such a speed, its increasing size and boilerplate automatically introduce a management issue. In addition, as I was trying to build a dialer appliance that can be used in any enterprise, the ever expanding Apache wasn’t a good choice.

While I was looking at both NginX and Lighttpd, the latter captured my eye, thanks to a simple advantage – The integration of FastCGI based PHP was so easy, that it almost troubling that I used Apache all these years.

At this point, once I got Lighhtpd working with my Dialer, I said to myself: “It would be really cool to go about and send status reports back from the dialer, directly to the web client activating the call. In addition, I really don’t want to go about and perform these updates to the database, then query the database – that would, literally, kill the MySQL server.

So, I implemented a local session storage area for each call, which updated the call status as it traverses. The information was stored on the hard drive, which allowed a better response time than the ever indexing MySQL server. The status reports were picked up from the Lighttpd server via an Ajax client (which I didn’t write – I suck at JS) – and it works quite well.

I wonder, can Lighttpd completely replace Apache? … time will tell…

Lets put it this way: I am no web developer, nor was I ever, nor will I ever be. While I do enjoy playing around with various web designs and web technologies, I’m no web developer. Think about it, this blog is based upon the WordPress system, which means, that while I could easily build my own blog system – I didn’t.As most developers are, I am a lazy person – when it comes to writing code, that is. This means that when I write an application, I really like spending my time working on the application logic, rather than wasting my time on GUI. I’ve always looked for better ways to improve my applications development track, especially, the ability to seperate the logic from the display in such a way that both become agnostic to one another. So, I started looking into various MVC (Model-View-Controller) frameworks – which had been springing up all over the past year.

While the most popular one seems to be Ruby-On-Rails, I don’t like Ruby and prefare PHP. Various options exist here, so I seeked one that was easy to integrate and that is backed by a company of some sort.

Zend Framework

Much like PHP, Zend Framework appears to be a mixture of functions, closely wrapped into a set of classes, to help you create an MVC environment. I’ve started learning it, and shortly came to a conclusion: much like PHP, Zend Framework enables you a feature rich environment, however, it isn’t always clear how to get to do something with it.

CakePHP

CakePHP appears to be a slightly more rigid PHP MVC environment, with a fairly vibrant and lively community backing it up. However, like any other young community backed project, it lacks one main element: proper documentation. The documents available on the CakePHP.org website are sketchy at best, which means, there is no ordered manner of getting started fast with CakePHP.

Code Igniter

Code Igniter is a PHP MVC environment, backed by Ellis Labs – the same people behing Expression Engine. So, from a technical point of view, this is a plus, as Ellis Labs had made it its business to make Code Igniter a valid product. The amount of information available on the Internet is satisfactory, and the documentation on the website is more than good – it’s down right GREAT! The addition of video tutorials with a very clear naration enables even a novice developer to go about and start working fast with Code Igniter. The one thing that Code Igniter lacks is a rigid framework, which means, that just like PHP – it’s easy to fuck about and mess things up.

My Choice

Currently, I use a mixture of Code Igniter + Prototype + XAJAX to build my web applications, which makes for a fairly rapid development environment – I’d love to hear what you have to say about these.

As most of you reading this blog, you must know that I’ve published an AsteriskNOW book early this year. I’m happy to say that I’ve received numerous emails since the publication of the book, all asking various questions about Asterisk in general and AsteriskNOW in particular.

Most of the questions that I received were related to the development of AGI and AMI scripts, and how to utilize Asterisk as an application layer platform. This inspired me to work on additonal title, to complete my previous book. I’m currently working on an Asterisk Developers guide, for AGI/CTI development with Asterisk. The book serves as a complete guide, summarizing the various aspects of developing AGI/CTI applications with Asterisk, while, enjoying various additions from my day-to-day experience with AGI/CTI development with Asterisk. The book is written as an eye-opener for experienced developers, wishing to make their transition to AGI/CTI development, and teaches them how to avoid the most common mistakes of early day AGI developers.

I’ll be be updating the blog with my progress. Currently, chapters 1 through 5 are complete, covering the basic aspects of dial-plan and AGI development. More information will be released soon.

Lately I’ve come to the realization, that we are to blame for our own inability to promote Open Source and the adaptation of Open Source proficiency. Being an Open Source evangelist and consultant, this is very weird to be said by one like myself, however, this is my realization – and I will explain.

In the early days of Open Source adaptations (late 90′s, early 2000), Open Source software was a somewhat magical solution that meant: pay nothing, get more. Software packages like Linux, Apache, mySQL, PostgreSQL and programming languages like PERL and PHP had lowered the bar on the adaptation of new technologies, and enabled a prolific number of solutions and services.

I still remember the early days, when a Windows based Mail Relay would cost anything between 800$ to 1200$, and I would come in with a Linux based solution that would do the same thing for FREE – amazing. As time progressed, so did the technology and the penetration of Open Source into new fields. CRM, ERP, Telecoms, management – all of these now enjoy a diverse number of Open Source solutions. However, the original concept of ‘Open Source = Magical FREE Solution’ had still remained in the minds of managers and business people.

Today we are confronted with ‘would-be’ Open Source solution experts, which adopt and develop upon Open Source products and project various applications. In example, let’s take a look at Asterisk. Asterisk has a multitude of Open Source solutions, ranging from PBX system, Prepaid calling cards, Wholesale routing platforms, Attendance system, Presence systems – and even a plant watering solution. The problem with this ever growing number of solutions is that Asterisk is immediately considered to be: “A magical solution” capable of solving any problem – when it’s not even remotely related to Asterisk. For example, a friend of mine had been asked to develop an Asterisk based solution, that would support a total of 250 concurrent call initiations and up-to 3000 concurrent calls on the system. Any Asterisk developer would take a look at this, and would immediately say: “Hmmm…. this requires several servers, but hey, what about the application itself? that would also have an impact”. Now, the customer of the project has a ‘would-be’ Asterisk tech in his company which said: “I was able to initiate 200 concurrent SIP invites to Asterisk via SIPP, no problem’ – HELLO! STUPID! where’s the application? where’s the database? where’s the user information flow? comm’on, are you listening to yourself speak? or simply are filled with the gasses coming out of your ass that are affecting your brain?

Now, once the customer learns that Asterisk is most probably not the right solution for the problem, he becomes angry. Why? because he now learns that he needs to spend about 10 times more money than he anticipated for the creation of this tool – well, that’s life when you have no idea what you are doing/saying, and you believe in magical solutions. However, we – “The Open Source Community – is the one to blame for this scenario, because we got the world accustomed to the idea that Open Source is like magic – flip the Linux magic wand, and the rest will solve itself.

I’d like to open the floor for discussion on this, as I believe most of you will have something to say about this.

Since I’ve released my dialer framework demo about 2 months ago, I’ve been swamped with many requests from various contact centers around the world – to utilize my dialer framework for the development of a custom made predictive dialer.

For those of you who are not in the know, a predictive dialer is a tool that is capable of analyzing the performance of each agent in a contact center, accurately predicting when his current call will be completed, and thus, start calling outbound to ensure that the agent is utilized as much as possible.

Most contact center managers believe that if an agent is utilized 100% of the day (or at least a close enough number), they will maximize their profits and work will be done faster. This is not always the case, and there are some cases where predictive dialers will be nothing more than a “White Elephant”, sitting in your call center, doing nothing.

Considering the following scenario: We have a contact center selling computer insurance plans by phone. Each agent is trained to make a sale, that is: “Don’t get off the bloody phone without a credit card!”. One of the issues with such a contact center is that there is no-way of predicting how long a sale will take. Lets imagine that one call a sale happens in 15 minutes, while in the next, we start with the kid in the house, move to the older brother, move to the mother, move to the father, ending up making a sale after 35 minutes. In other words, we have no way of profiling an agent, as there is no proper profile to the customers.

So you can argue that by utilizing statistical models and proper targeting of potential customers, we can go about and perform more accurate predictions. However, these predictions will all go up in flames, the minute a deviation from the norm of the statistic happens. We then immediately create a form of ripple effect, that is then carried across the entire contact center.

In the book “The Goal“, by Eliyahu M. Goldratt, the author tells us a story about a group of boys walking in the woods. The group of boys constantly are unable to walk the path at the designated speed, due to various timing and synchronization issues. In theory, a predictive dialer is used to better synchronize the contact center intake (numbers to be dialed), with the contact center’s ability to perform (the ability to make a sale). However, this model fails when the sale constraint is unknown, thus, making the entire model fail.

In most cases, contact centers are better off using “Preview Dialers” and not “Predictive Dialers”, unless, the contact center is highly targeted with its campaigns and sale strategy. A “sell or die” contact center strategy immediately negates the possibility of accurately measuring the contact center performance and bottle necks, thus, having an automatic pace creator in such a scenario will become redundant and will most probably just cost funds.

Ok, the service is up and running, so now I can show it off. Israel’s 60th independance day parties information service is running of an Asterisk servers – how do I know that, you ask? simple, it’s my Asterisk server!

Well, actually, the service is being run by BeLowCall, an IVR and telecom services company, while the platform was developed by me. Essentially, the system is an Asterisk based application engine, that has a very minimalistic dialplan code and communicates with an SQL backoffice then instructs the Asterisk server what to do – in turn, turning the Asterisk server into a high scaleable state transition machine – capable of developing IVR system at any depth or as wide as you want.

If you want to feel the system, you are welcome to call +972-73-2126060. The entire application took about 4 hours to provision, including the database registration system and the recording – not bad, right?

As some of you may already know, I’ve been chosen by Digium to perform Asterisk training services here in Israel. For me, as a long time Asterisk community member, it is fairly a big thing, even bigger than the book I’ve written – as it incorporates two of the things I really like – teaching and Asterisk.

The first bootcamp is currently planned for the 25th of May till the 29th of May, in Ramat Gan, Israel.

You can find additional information at http://www.greenfieldtech.net/asterisktraining.

Oh, btw, did I mention that I’m now a freelance consultant? check out my website at http://www.greenfieldtech.net/

As most of you already know, I’m heavily involved within the Asterisk Open PBX project. Over the course of the past 5 years of my dealing with Asterisk, Asterisk had always suffered a serious flaw, and that is, a single-threaded Manager interface – which usually led to serious dead-locks when writing a multi-threaded server that connects to it.

One of my long time challenges was to surpass the 4-5 originate requests to the Asterisk Manager interface, enabling me to automatically dial more than 4-5 calls at the same second. My initial work had began with the idea of increasing that by a factor of 50%, going up to around 7-8 calls per second – I had achieved that using a combination of smart synchronization between the manager interface and my originating server – and also enabling asynchronous originate requests – however, that methodology had proved to be problematic – in terms of reliability.

I understood that something else had to be devised, something that doesn’t rely completely on the manager interface, and that will allow me to originate calls freely, without clogging up the manager interface. So, I decided to move my interest from the Manager interface, and concentrate on understanding Asterisk’s channel handling, especially, how do calls originating from the manager interface are handled by the Asterisk spooler and the Asterisk channel drivers.

more will follow…

OK, if there is one thing I really hate, is that when something so little as a small configuration change from one version to another causes things not to function properly. It is one thing to make sure that your code is backward compatible, no one really expects that your scripting language will suddenly start behaving differently, just because you upgraded to a new minor version – right?

So, here is the case, over the course of the past 2 years, I’ve done some extensive AGI programming with the PHP programming language – hell, I think that if I’ll sit down and write a book about AGI programming with PHP, it would be one of the most complete ones. I remember that when I started writing AGI scripts, I used to simply write everything by myself, each script was a self contained unit, everything was working hunky-dory. Shortly later, I discovered the PHPAGI class, a nicely wrapped AGI class for AGI, FastAGI and Asterisk Manager interaction, that made my life really easy. When Asterisk evolved to version 1.2, most of my PHPAGI scripts kept on working, apart from a small part of the Manager interface, however, that was easily worked around – and we’re back hunky dory. Even Asterisk 1.4 and Asterisk TRUNK liked PHPAGI, no problem there – till a week ago.

So here I am, working on a new project, and I’m working on my new snazzy development kit, that is installed according to the following:

CentOS 5.0 x86_64 with Kernel 2.6.18-8.1.4.el5
Asterisk stable 1.4.14
php version 5.1.6 (RPM package: php-5.1.6-12.el5)

At this point, all hell broke loss! All of my old PHPAGI scripts had simply gone crazy on me, causing each of the AGI “GET VARIABLE” commands to fail, always returning variables which are not there at all. That was fairly annoying, I’m issuing a command, getting an error response, issue the same command again, get a proper response only with the wrong variable, issue the command again – get the proper value. How annoying! – All these scripts used to work perfectly in the past, what happened? So, I deploy an older code of mine, guess what, that code doesn’t work either – at this point, I start pulling hairs off my head (not that I have much to pull on, my hair is very short).

So, what does any good Open Source programmer do when confronted with such a problem? “Use the source Luke, use the source!” – lets dig into the Asterisk code. Adding some AST_LOG functions here and there, doing some more debugging using valgrind, everything within Asterisk looks nice. Just to make sure, lets downgrade the Asterisk version and run the test again – same results. Conclusion: Asterisk isn’t the problem, doesn’t really matter what version I use.

OK, lets check the PHP scripts – some PHPAGI class hacking, more debug here, mode debug there, a few more syslog calls – everything looks on the PHPAGI script as if the input from Asterisk is messed up. Conclusion: something in the middle is fucking up royally!

Now, being a good programmer I said to myself: “OK, so one said that PHPAGI is the only language out there, lets go Python – besides, I always wanted to learn Python”. So I spend a day learning some Python, just so I would be able to re-write my script into Python. Ran the script – holly shit! – it works, as if nothing happened. Conclusion: something in the PHP environment is screwing up the environment. So, I decide to modify my execution from using php-cli to php-cgi, for all practical matters (at least from the script side) – it should behave identically. Modified it to work with php-cgi, suddenly the $argv variable isn’t being passed to the script! – Hmmmm…. that’s odd, it was there a minute ago. Lets dig into php.ini and see what’s wrong:

; This directive tells PHP whether to declare the argv&argc variables (that
; would contain the GET information). If you don’t use these variables, you
; should turn it off for increased performance.
register_argc_argv = Off

Dear god, why would $argv and $argc be turned off? just for performance sake? how would I run the AGI scripts that I want to run, after all, I am using the $argv variable. Turn the parameter back to “On” – JOY! Everything is back working as it should. So the question that remains is: “What is the main difference between php-cli and php-cgi that had caused this issue?” According to the voip-info.org website, there is some form of difference, however, it doesn’t really say how it is exhibited in the operation of AGI scripts.

Well, at least I solved my problem for the mean while, I’ll work on getting the proper explanation of php-cli vs. php-cgi later on.