PHPAGI Annoyances or maybe…

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

Leave a Reply