[VoiceOps] Any subscribers from the UK?

[Alex Balashov]

Alex Balashov wrote:
> Daryl G. Jurbala wrote:
> 
>> Nor would I, but the setup I inherited is doing just that 
>> (registrations handled by a commercial SBC, codec based routing 
>> directly to an asterisk box or a cluster of Dialogic IMG 1010s, 
>> Asterisk using Realtime and PHP-AGI hitting Postgres for routing) and 
>> I'm easily passing 1.2 mil minutes a day.  As mentioned in another 
>> thread, I do need 15 asterisk boxen to pull this off, but it works.  
>> And once you get things together, its surprisingly stable.  You just 
>> need to jump off the upgrade bandwagon, pick one, make it work, and 
>> stick with it.
> 
> I don't mean to sound derogatory, but what is this enormous fixation 
> that people have with building AGI scripts in PHP-AGI?
> 
> It's nothing personal;  lots of my customers do it, it seems widely 
> prevalent in the ITSP cottage industry.
> 
> 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.
> 
> Secondly, calling AGI(somescript.php) causes the entire PHP interpreter 
> and runtime library environment to be loaded *every* *single* *time* 
> *the* *script* *is* *called*.  Also, there's no application server or 
> back end to provide pooling of persistent database connections on 
> demand;  every time you run it, it goes through the entire process of 
> establishing a connection to PostgreSQL.  Every time.  Over and over.
> 
> I can only conclude that the reason PHP is so often used is because call 
> shops hire developers chiefly with the aim of web portal/interface 
> design in mind, and when it comes time to develop some of the backend 
> logic used within the actual platform -- "Well, uh, we have a bunch of 
> web developers who know PHP, so let's use that."  It's one of those 
> succinct examples of suit vs. technocracy decisions;  it's a conclusion 
> some "business guy" with "vision" would see as a very rationale instance 
> of code reuse, economies of scale, and return on talent pool, but makes 
> no sense from an engineering perspective.
> 
> It'll work for 1.2m minutes, but this won't cut it for high volumes of 
> call setups.
> 
> The proper approach here would be to build a minor piece of middleware: 
> a FastAGI service that provides AGI command responses over a network 
> socket.  Simultaneously, the service can maintain persistent database 
> connections in order to speed up that process.  It also gives you the 
> ability to centralise all your call control and business layer logic 
> into one "logic controller" and essentially utilise the Asterisk boxes 
> as "dumb computing resources."  In the most extreme and rewarding case, 
> you would hardly have a dial plan;  all aspects of the user experience 
> would be dispatched through FastAGI, and any hostwise application-level 
> constructs (such as Asterisk call Queues with a capital Q) would be 
> parallelised and simulated through AGI-based call control (i.e. MoH, 
> wait time announcements, etc.)  Then you can just "farm" the work out 
> across a cluster of Asterisk boxes of arbitrary size and get higher 
> returns to scale.  You would also not need to reprovision them every 
> time you make a logic change.
> 

You will also reduce your per-port cost requirement by making the 
process more efficient.  It may not be a big deal because of the low 
price of commodity hardware, but every little bit helps, especially on a 
large scale.  At that point, the limitation you run into becomes more 
the number of concurrent calls that Asterisk can reliably maintain 
inherently, rather than the enormous weight and latency of your setup 
process.  That's a better place to be.

-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775