14 May 09 Asterisk and Amazon EC2 – Amoocon Presentation
I recently gave a presentation at the Amoocon convention, held in Rostock, Germany – about Asterisk and Amazon EC2. Below is a medium quality video of that presentation:
or you may download it here:
Amazon EC2 and Asterisk video files
Tags: AGI, Amazon, Amazon EC2, Asterisk, Cloud computing, Dialers, economy, GreenfieldTech, php, PHPAGI, Virtualization, VMWARE
18 Feb 09 Asterisk AGI Programming – New Book
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.
Tags: AGI, Asterisk, Asterisk Book, Asterisk Developers, Book, GPL, open source, Packt Publishing, php, PHPAGI
28 Dec 08 Open Source has bad reputation in Israel!
The Open Source movement had been in existence since the 60’s, and we can surely find its roots somewhere along the hippie culture and movement. While Free-Love had transcended to Free-Code, or to be more exact – Free-Knowledge, the question of the sources for your Open Source is still questionable. Comparing it with the Sixties, it’s easy to compare the various “Free-Love” movements with the various “Open Source Paradigms” of today. While GPL, BSD, MPL, ZPL and others preach for Open Source adaptation – each one took a different path.
While the paths differ, but the end result is more or less the same, all suffer from a serious lack – a bad reputation. While in the early 2000, Open Source usually meant – highly stable, state of the art technology, increased ROI, lowered TCO and most importantly for many – COOL. Coming 2008, Open Source is starting to get a bad rep, due to the ever increasing simplicity of entering the Open Source world.
I started using Linux somewhere around 1994. My first Linux distribution was a Slackware, with a kernel of 1.0.28 – I needed 99 floppy disks in order to install the system, and it took me a few hours to do so. However, I can’t forget my amazement at seeing the X-Windows environment booting up, and more than that, being completely overwhelmed with the fact that I have a fully functional UNIX environment in my house, just like the one I had in my Army office. Now, I basically had no one to teach me this new environment, so, I had to take my UNIX skills (Solaris and AIX) and adopt to Slackware Linux – it took me a few weeks to get around, but I got around and stuck to it ever since.
Now, let’s jump 14 years forward in time. The year is 2008, a graphic based environment for Linux is no longer a myth and it is getting better and better by the day. People are starting to adopt Linux beyond the academic and the ISP market sectors, slowly integrating Linux based distributions (Mandriva, Ubutnu) on to their desktops and notebooks. Linux is become simple and appealing to everybody.
When something becomes easy to use, people make good use of it – a good example is the Asterisk project. Projects such as TrixBox (AKA: AsteriskAtHome), PBXinaFlash, AsteriskNOW and others had made Asterisk into a simple installation product, that can be installed and managed by any half-decent sysadmin. Problem is, while a half-decent sysadmin will do a fair job of maintaining the system, a shitty sysadmin will crap everything to hell. But hell, that is true for almost anything related to computers or technology – there’s nothing new here! Well, there is nothing new and everything is now new. People who were more or less selling shoes 3 years, then 2 years decided to sell ISP routers, then a year ago started selling IP phones, are now selling Asterisk based systems – using these distibutions, while having no idea what they are selling or promoting. For these people, Asterisk is nothing more beyond FreePBX – once encountering deeper issues, will simply abandon the customer – leaving the Open Source product with a bad rap with the, now disappointed, customer.
I want to believe that other places in the world are different, I want to believe that Israel will reach a point in time when this doesn’t happen – however, I guess that only time will tell and I surely hope this will change in Israel.
Tags: Asterisk, Asterisk At Home, FreePBX, Linux, open source, PBX-in-a-flash, php, TrixBox
14 Oct 08 A2Billing+Apache vs. A2Billing+Lighttpd
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:
- Go into the A2Billing code, change the GD code to work right or simply change it completely to something else (maybe flash).
- 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.
Tags: A2Billing, Apache, Asterisk, Authentication, Authorization, errord, FreePBX, htaccess, Lighttpd, memory, php
27 Aug 08 Apache vs. Lighttpd (AKA: Lighty)
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…
Syndication
Say no to biometrics act
