Ok, the picture shows a donkey not a Unicorn – as you know, Unicorns are very hard to find. Asterisk Scaleability is somewhat of a unicorn – not because it doesn’t exist, it is a little tricky to do and get it right first time.

Over the years, there had been multiple approaches to building a scaleable Asterisk platform, most of them relied on the same principals: multiple Asterisk servers, singular point of entry with load balancing, single point of exit with LCR. Normally, when you talk Class-4 services (call routing, DID services, Calling Cards), this methodology would work just fine. When it comes to Class-5 (Centrex, Voicemail, Queues), things tend to get a bit more complex – but again, the basic methodology applies and remains. Over the years, we’ve seen contenders come and go, FreeSwitch, Kamailio, OpenSIPS, SER, OpenSEMS – they are all a means to an end, just get the number of concurrent calls and CPS ratio higher.

The question is this: “Is there a singular approach to Asterisk scaleability? is there a bullet proof recipe that we can use to achieve this Unicorn type configuration?” – the answer is: NO! – it is very much dependent on your application, your client side application, your general usage patterns and what kind of agility you are looking to expose to the end consumer.

Since the inception of Asterisk, and specifically since the inception of FreeSwitch, many people had been dissing Asterisk as being a monolithic environment. Many times, if you ask someone – “what does that mean?” – you would end up with a very googly eyed face, not really understanding what monolithic means. Yes, Asterisk is by definition a monolithic environment, which means, it was designed to work a self enclosed unit. If you think about it, how many PBX systems do you know that are not monolithic. The question in that case is: “If Asterisk is monolithic, how can we scale and expand it? how can we build something really big from something like Asterisk?”.

In martial arts you always learn to use your opponents strength as their weakness, as your weakness as your strength. If Asterisk’s monolithic nature is its weakness, let’s try and make it into its strength. How do we do that? we make sure that any decision (process, calculation, state handling, etc) that is cross platform is handled outside of Asterisk, while keeping call control and media handling at the monolithic layer. This yields two distinct advantages: we can develop our cross platform logic at ease, without impacting our Asterisk development process, we can develop our Asterisk logic as a singular unit and expand it as required, simply by adding more computation units horizontally. In network and platform design there is a simple rule of thumb – growing deep is complex, growing wide is simple. If the question of scaleability becomes a question of brute forcing additional computation resources, the issue is simple. If scaling out requires changes in the computational structure – you’ve done something wrong.

Over the years, we’ve developed several large scale Asterisk platforms. These had recently hit the combined user number of 15 Million, with over 850 Million minutes served on all platforms combined. Some of these are carrier oriented, some are social oriented – but in all of them the scaleabilty factor was important. In other words, the Unicorn is out there, we’ve actually managed to find it several times, each time somewhere else – but it was always grazing in similar locations. If you keep looking for the bulls, you will surely miss the Unicorn standing at the right of the road – right next to you.

In my previous post I’ve announced the bootstrapping of a new PHP project, called “Project Stanley”. Project Stanley was an attempt at creating a Asterisk ARI developer kit, based upon the PHP programming language (yes, I call it a programming language).

Shortly after initiating the development and reaching a point where our code was actually able to do something, we realized that we’ve gone the wrong way. The wire frame we’ve created relied heavily on the Ellislabs CodeIgniter MVC framework. Now, don’t get me wrong, I love CodeIgniter – but, it was the wrong choice. It was wrong, because we were locking our developers into an MVC structure, that truly isn’t needed for something like this.

So, we’ve stopped working on Project Stanley (you can still find it on github if you really want to) and we migrated the code into the PHPARI project. PHPARI is a cleaner approach to providing a simple, to the point, ARI developer kit using PHP. It relies on 2 PHP external libraries – PHPWS and PEST.

PHPWS is a WebSocket client implementation in PHP, while PEST is a REST client implemented in PHP. Both are actively maintained and had been tested by multiple projects as stable and battle tested. We’ve also enabled PHPARI in packagist, you can look it up for installation. Make sure you use the dev-master part of the package, not the dev-develop – it’s unstable and may actually contain broken code.

Asterisk ARI – for a seasoned AGI/AMI developer like myself, ARI is a serious mind warp. Why is it a mind warp? simple, it’s all the things we wanted AGI to be, and the reliability we wanted AMI to have, minus all the work around we needed to do – in order to get similar functionality in the past.

So, is ARI truly a replacement for AGI/AMI? well… I think the true answer will be NO. Is a replacement for the Asterisk dialplan? well… I think the answer to that is NO as well. “Say, are you messed in the head? first you say “What AGI/AMI should have been”, and then you say it’s not a replacement? – are you mental?” – well, there are a few reasons why I claim it’s not a direct replacement, and I’ll detail these here.

In order to explain, I’ll give a few examples, using the “in-development” PHP ARI wireframe that I’m developing, called Stanley.

Synchronous vs. Asynchronous

ARI by definition is asynchronous. Keeping that in mind, in means that that any command you give it will get queued or spooled in some manner, and return back an immediate result. Just to illustrate it, let’s examine the following code segment:

$this->stasisLogger->notice("Stasis Start");
$lastResult = $this->channels->channel_playback($this->ari_endpoint, $messageData->channel->id, "sound:hello-world");
$this->stasisLogger->notice("Last result: " . $lastResult);
$lastResult = $this->channels->channel_playback($this->ari_endpoint, $messageData->channel->id, "sound:demo-congrats");
$this->stasisLogger->notice("Last result: " . $lastResult);

For all practical purposes, you should regard $this->stasisLogger as a simple logging object, and $this->channels as a model to initiate ARI Channel requests. If you use the above the code, and activate it from with a Stasis application, you would listen to the “hello-world” and “demo-congrats” segments. Now, let us examine the following code segment:

$this->stasisLogger->notice("Stasis Start");
$lastResult = $this->channels->channel_playback($this->ari_endpoint, $messageData->channel->id, "sound:hello-world");
$this->stasisLogger->notice("Last result: " . $lastResult);
$lastResult = $this->channels->channel_playback($this->ari_endpoint, $messageData->channel->id, "sound:demo-congrats");
$this->stasisLogger->notice("Last result: " . $lastResult);
$this->channels->channel_delete($this->ari_endpoint, $messageData->channel->id);

The only difference here is the last line. If you activate this code, you will hear the world “Hello”, immediately followed by a disconnect. “Wait a minute, what just happened? – wasn’t I supposed to hear everything?” – that’s exactly the point, the answer is NO! The asynch nature of ARI will simply queue the first 2 playback requests, while the hangup is performed almost immediately – the playback simply never get to be executed.

In other words, if you need something to be synchronous within the dialplan, you may need to work differently about it. If you are familiar with the Node.JS framework, you are fairly familiar with this issue.

ARI is for writing applications, not IVRs

When the Asterisk team created ARI, their idea was simple: “Don’t manage the queue application, simply write your own”. Same applies for managing multi party conference calls, call origination, etc. In 2009 I wrote a book about AGI programming, where I’ve explained the methodology for “Atomic AGI development“. The concept behind Atomic AGI was to contain small logic units in AGI scripts, and leave most of the heavy lifting to the dialplan. This methodology enables to create scaleable Asterisk platforms at fair ease, and introduce additional technologies, without going about and adding odd things into Asterisk.

ARI is meant to do something similar, in the form where you can go about and create your own logic, contain it into a singular application and activate when you require – for example, rewriting the queue application. One of the first applications that I’ve decided to re-write using ARI was a Radio broadcasting system that I’ve developed in 2006. The problem with that application was that I need to hold about 600 callers in a single queue, and attach them over to the broadcasting booth as required. Of course I needed to enable full call control, caller management, UI and more. Initially, I used MeetMe, MySQL, and AMI to do this. Later on it changed to MeetMe, Redis, AstManProxy and some other tools – but it never seemed to please me. The fact that I needed to maintain 2 MeetMe bridges, one for holding people and one for the actual broadcasting really bugged me. Yes, when Asterisk 1.8 came out I migrated to the Bridge application and yes, I updated bits and pieces here and there, but it was never what I wanted it to be.

When I started playing around with ARI, I said to myself – this is the perfect application to migrate to ARI. The only thing I needed was a simple Stasis application to read my state correctly, and that would be activated once the called is put into the waiting area – so in terms, I’ve developed a very simple queue application.

IVR heavy lifting was done using dialplan, but the actual service was done with ARI.

Blades and Bleeding Edge

Now, before you go about migrating all your existing code to ARI – you must remember this: If you walk on the bleeding edge, expect the blade to cut you here and there. Currently, I hadn’t yet seen any proper ARI wireframe available. I’ve seen some work done with Node.JS and Ruby, but I can’t say that I’ve taken a fancy to any of those. Honestly, my comfort zone is very much PHP and C/C++, what can I say, I’m old school.

When I started building the Stanley wireframe, it was fairly frustrating – simply because not everything was that much clear and clean. In addition, as Asterisk advances, ARI will change and advance as well. What ever you write, make sure it’s modular enough so you can change it as required.

 

Ok All, this is my official Astricon Countdown – start your engines, as Eric Klein and myself will be attending Astricon this year, Vegas here we come.

So, what are we going to talk about: Security and Cloud computing. Yes, over the past year, I’ve been returning to my old stomping ground, the various cloud infrastructure that is publicly available – and how to exploit it to the max. I will be talking about the various methods of speeding up your clouded Asterisk server, and most importantly, I’ll share some of the methodologies and logic behind building these instances, maintaining them and the various do’s and don’ts I’ve learned along the way.

I’m planning a few surprises and giveaways for my talk, so make sure you stay updated on this page 🙂

 

Tux, the Linux mascot

Image via Wikipedia

When I started using Open Source software, it seemed like all Open Source projects are driven by philanthropic agendas. We were all focused on “sticking it to the man” – showing all these would be software vendors that community driven projects can do just as well – if not better.

"When I was a child I spoke as a child I 
understood as a child I thought as a child; 
but when I became a man I put away childish 
things." - I Cor. xiii. 11.

Well, I’m not claiming that Open Source is childish – absolutely not, however, when you are a student you tend to look at things in one way, when you have a family to care for – you start looking at things differently. You remember these days in life when your dad said: “When you’ll have children you will understand” – well, now I do.

So, what am I rambling about exactly? I’ll tell you. The day before Passover I attended several meetings, which when I came back home had pissed me off immensely. I feel an urge to write all about these meetings, including who I met exactly, however – I won’t do that. However, I will give a rough idea of these.

Meeting 1 : A world recognized Mobile application player

I came into the meeting with this company, where the CTO of the company explained to me that they are looking to create an Asterisk based solution for their application’s users. My initial question was: how many users? what is your concurrency level? – The answer that I got was: “Oh, we don’t need something major, just a few lines of configurations in Asterisk config files in order to make this work”.

I left the meeting slightly pissed off, thinking to myself: “You bloody inconsiderate prick! You bring me to a meeting, spend my time – and then telling me that this is just a few lines of configuration. If it is that simple, why don’t you do it yourself? you have 20 developers in there, 4 IT people and god knows how many outsourced workers off-shore – if it was that simple, you would have done it already – so probably it isn’t – right?”

Meeting 2 : A well established IVR services vendor

The second meeting was with a well established IVR content vendor, this company runs around 16M minutes of inbound IVR traffic every month. They invited me in order to talk about expanding into new countries, wishing to get premium based access numbers in various countries. So, we started talking, and the guy indicates that he wants a certain kick-back payout, which I know is impossible – at least without charging the user more. Actually, the guy indicated that out of the interconnect fee, he wants to get almost 90% as a kick back.

Meeting 3 : A start up rendering IVR content

The third meeting was the most amazing one – these guys wanted to build an Asterisk system to server around 4000 concurrent channels – outsource the entire development to my company – and pay as a revenue share. When I asked for their business model, marketing plan, investors, profiles – I got a response of – we don’t yet have all of these, we only have an idea at this point that we want to implement.

Garage based companies are built by people who can do the work themselves, not the other way around.

Photograph of Mark Shuttleworth by Martin Schm...
Image via Wikipedia

At this point, you are probably asking yourself: “What does this have to do with the title?” – Well, all of these meetings had one thing in common. The people I met were under the impression that Open Source is some form of philanthropy. Or to be more exact, people who deal with the Open Source market are philanthropists. My question is this: “Why are we perceived as philanthropists? don’t we have families to care for? don’t we need to pay mortgages and bills just like everybody else?”. I guess when people read about the various Open Source entrepreneurs, such as Mark Shuttleworth – the immediately associate Open Source with Big Exists – this is not the case.

At some level, this is purely our fault – we educated people that Open Source is a highly economical methodology of solving technical challenges. No where along the way, had we educated the public that behind the model there are people, people who need to make a living.

If you are an Open Source consultant, developer, evangelist or just someone who may have an opinion on this, I’d love to read what you say.

Reblog this post [with Zemanta]