[VoiceOps] Any subscribers from the UK?

Peter Beckman beckman at angryox.com
Mon Aug 3 15:53:16 EDT 2009


On Sat, 1 Aug 2009, Alex Balashov wrote:

> I don't mean to sound derogatory, but what is this enormous fixation that 
> people have with building AGI scripts in PHP-AGI?
>
> PHP is a language designed for serving dynamic web pages;  of all the runtime 
> environments suitable for the development of standalone utilities, it is 
> absolutely the worst and most perverse one you could use.

  You have some very valid points, and some ones I disagree with.  Here's
  why we do it, and how we do it better.

  Before I start, I strongly disagree that PHP is bad for handling Asterisk
  dialplan logic.  You want to write your business logic in code once, then
  reuse it.  We happen to expose our business logic via a PHP API that our
  Perl FastAGI uses, but not everyone has the talent/ability/forethought to
  build it that way.  The easiest way to reuse that business logic code you
  wrote for the website is to build libraries you can reuse elsewhere.  In
  this case, a PHP that talks to Asterisk in an AGI sort of way (not
  directly).

  First off, calling AGI(somescript.php) is awful.  We decided to do it in
  Perl, but we could have done it in PHP.  We implemented it as a FastAGI
  script, running as a TCP service that asterisk connects to on a listening
  local port.  It handles all of our database connections, forks new
  processes off for each call, and does everything we need the way we want
  it done, not having to add on a bunch of hacked-together scripts and
  modules in Asterisk.

  Second, if you know PHP and nothing else, it is definitely easy to get it
  done in PHP, especially if your business logic is in neat libraries you
  can include and make calls to.  If you call it directly via AGI(), it can
  and likely will hurt or kill your resources, but using it as a long
  running FastAGI daemon it can be managed and connections to the DB can be
  shared.

  Last, if all of your business logic is already done in PHP for your
  website, it's really easy to simply re-use this existing code in your AGI.
  And if you do it right and well, it may even scale fairly well.

  Your point however is still very valid: most customers do NOT do it right
  and well, and they should be motivated to learn how to do it better.  I do
  think your downplay of PHP as an AGI language is simply misdirected.  PHP
  can do FastAGI, and you can pool connections, fork processes, do things
  elegantly, same as with a Perl or C++ compiled FastAGI script.  Of course
  we all know C++ will run faster, but we also know good C++ folk are hard
  to find, and once they build it, it's hard to find them again to update
  it.  PHP programmers are easier to find, and if we simply educate them
  about how to build a FastAGI written in PHP reusing business logic already
  build into their website, well, it seems like a pretty good path to me.

  Are there better ways to do it?  I'm certain.  But most buseinsses don't
  have access to really and truly talented Asterisk admins who also know SQL
  and really can manage the full dialplan on a regular basis, who also know
  PHP well and can work on the web side of things too, and that's why they
  use PHP.

  Now go teach them to use a FastAGI written in PHP (it's not that hard) and
  they'll be a long way along.

  For my Perl FastAGI, I use Net::Server::Fork and Asterisk::AGI (with a few
  fixes and modifications) and it works great.

Beckman

References:
     http://www.packtpub.com/article/asterisk-gateway-interface-scripting-with-php (Nir!)
     http://us2.php.net/manual/en/function.socket-listen.php
     http://phpagi.sourceforge.net/ (not maintained)
     http://gattolino.blogspot.com/2009/03/asterisk-fastagi-server-in-php.html (incomplete)
---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beckman at angryox.com                                 http://www.angryox.com/
---------------------------------------------------------------------------


More information about the VoiceOps mailing list