Dinner with Captain Crunch

It is a fairly rare occasion when one gets to meet one’s childhood (or to be more accurate, teen) hero. For me, growing up as a teenage computer geek in Israel, during the late 80’s, early 90’s, the electronic world was a bold new frontier of opportunities and challenges. I distinctively remember the original myths that were spread around the teenage geeks – there is a box, called a “blue-box”, it’s a box of wonders – enabling you to bypass the local PTT systems and call abroad for FREE. It was the early 90’s, long distance phone calls were expensive, beyond expensive – they were outrageous. Calling abroad was even worse, it could easily amount to $2-$3 per minute, doing it the normal way. The “blue-box” for us was a myth, a box of wonders that no one never get around to actually seeing one.

Then, late 1989 something happened, a friend of mine returned from the US with, what I could only call a magazine – back then it was called a zine. I can’t call it a magazine, as it was a group of dot-matrix printed pages, stapled together. My friend said: “This is a hacker’s magazine, but I can’t understand the blue-box thing”. My eyes lit, could it be, did the pages truly include description of what the blue-box was? I looked at it and replied: “Of course you don’t understand this, you are a computer science major – not electronics”. I studies electronics and the blue box made sense to me. The pages included the entire circuit diagram – I was fascinated. I built the my first “blue-box” using those diagrams, it was crude, it wasn’t pretty, but it worked – well, it worked for exactly 15 minutes, then the power regulator I used kind’a fried. That was my beginning in the world of Hacking and Computer security.

Following to reading about/building my first “blue-box”, I continued to consume information. I used the box, each time for short intervals and each time getting to download more information. I remember being connected to the Channel One BBS in the US, downloading the hacker’s chronicle and reading through like mad. I learned about the works of a man nick named: “Captain Crunch”. His work in investigating the various properties of the telephone network amazed me – at that age, for me, he was a modern day Robin Hod. Fighting the system, from within the system – showing how frail it is, and abusing it to the max. I must say something here, unlike the USA at those time, we didn’t have anti-hacker laws in Israel, thus, computer crime was so rare, they didn’t even know what to do with hackers – if they ever managed to catch them.

Fast forward 25 years, I’ll be 40 next month. Over the years I’ve learned that Captain Crunch is the alias of John Draper. I’ve met John first time in 2000, in a hackers’ convention in Israel called Y2Hack. I didn’t get to chat with him much back then, it was a busy event. This years’ Astricon was in Las Vegas, where John currently lives. After learning about John’s medical condition, I’ve decided I would like to pay the man a visit. Normally, you don’t get around to meeting people who had influenced your life in such a deep manner, but here I had a chance. So, Eric and I contacted John – who was more than happy to join us for dinner.

It is clear that John is not at his best, in severe pain from his latest surgery – and most surely medicated for his pain. However, sitting down with him for dinner, one thing is very much clear – when it comes to technology, John is as sharp as ever. The conversation rapidly moved from talking about history, to talking about modern day cellular technologies, how roaming works, phantom base stations, HTML5, WebRTC and more. At times, it would seem that the conversation would float away, but John rapidly closes in on the subject – and being in his physical condition, that isn’t simple (I guess).

John, very much like other visionaries that hadn’t been completely acknowledged by society – sorry to say, is far from what we would imagine him to be at this age. Normally, we imagine that people like John would be living a good life, after all, the computer age was very much built on much of his work and findings. But, the truth is that John’s friends started a qikfunder campaign to fund hi medical bills. Amazingly enough, John isn’t a rich man at all. For someone who was acclaimed as “If it hadn’t been for the blue box, there would have been no apple” (Steve Jobs, 1994) – it is somewhat discomforting to see him like this.

I truly wish John all the best and wish him a speedy recovery – as his mind is as sharp as ever, and I truly hope to see him back at the tech-helm as soon as he can.


Astricon, Vegas and Geekness

So, Astricon 2014 is over and behind us, so now I’m now sitting at the Holiday Inn in Chicago. I have to admit that moving from the RedRock resort and Casino to the Holiday Inn in Chicago – talk about a mind blowing change. Just to give a general idea, the bath room in Vegas was roughly the size of the entire room here (mental note to self – next time order something better via BA miles).

So, this years’ Astricon was, at least for me personally, one of the best I’ve been to. Various topics that I’ve started talking about years ago, had finally made their way to the public’s ear, and the community and adopters are finally picking up on these. Security, privacy, cloud computing, proper usage of Linux and virtualization – these are now become the predominant subject people are confronted with.

Unlike previous years, I decided to talk about Cloud computing and some tips from the Cloud front line. Cloud computing, specifically cloud based servers are and infrastructure that many want to use – but very few truly understand what it means. What kind of impact does SWAP have over your instances, what is the swapiness value? and why the hell would I choose one cloud over another – aren’t they all the same at the end?

This year, we had the first ever Astrion Hackathon. I’ve participated in several Hackathons in the past, but this was very special to me. While in most Hackathons I’ve participated the participants never knew each other (well, at least 95% of them), here, most participants knew each other – some on a very personal basis. As you know, my latest Open Source passion is my own pet project – phpari. My hack for the contest was a phpari sandbox, imagine it to be a cross between jsfiddle, Asterisk and PHP. A simple use playground, where you can try various parts of ARI in general and the toolkit in particular. Much to my surprise (as there were other strong candidates), the phpari sandbox won the “Asterisk Developer’s Team” Award, for best use of Asterisk during the Hackathon. To me personally, it means a whole lot. I’ve been dealing and working with Asterisk for over 12 years now, in fact, I was joking around with Corey Mc’fadden that we are currently, probably the oldest Asterisk community members around – well, probably oej, joshc and a few others are as old as us. We never had a chance to actually see how we work together, how we think about various problems and challenges. This was the first ever time we’ve got to see each other work, how we work, how we look at things – it was exciting. Looking at Tim Panton as he battles the various concepts of Respoke and he’s application – trying to figure out exactly why “Respoke” didn’t work as he expected (amusing to say the least).

So, after Astricon, we spent the last evening going out to the Vegas Strip. I have one thing to say right now: “I don’t think I like Vegas all that much”. It’s just too much of everything. Too much “Putti’n on the Ritz” facade, too much commercialism of everything and anything, just too much for me. Don’t get me wrong, it’s an interesting place to visit, but I don’t believe that being there more than 2-3 days is required in order to appreciate the place. Be it the lights that are always bright, making you believe it is day light, the hotel that literally had no windows to the outside – so you won’t know if it’s day or night, the entire system gets screwed up totally.

So, during the night of the “geeks take over Vegas”, the following group of people decided to head to the strip:

  • Allison Smith
  • Peter – Aka: Mr Allison (hey, what do you want, you’re married to the voice of Asterisk)
  • Ben Klang (Adhearsion/Mojo-Lingo)
  • Evan (sorry, can’t recall the rest)
  • Steve (Mojo-Lingo)
  • Dan Jenkins (Respoke)
  • Eric Klein (My partner in crime)
  • Correy McFadden (Venoto)
  • Beth – Correy’s Wife
  • Steve (From South Africa)

So, here we are sitting at the cosmopolitan waiting for our table to the STK. Once we got it (at 10:45PM), we sat down at the stools waiting for our table. At the table next to us, a man and two young ladies were definitely getting it on. To be more descriptive, apart from actually going at it in front of us all, they were all over the place. As they say, what happens in Vegas – stays in Vegas. But what happens at a public restaurant, don’t be surprised to find it on Twitter. Coming to think about, we should have videoed the entire thing. Now, don’t get me wrong, I’m as much a man as the other guy, and I admit that the display was interesting (so say the least) – but comm’on, we’re a public place – get a bloody room. The funny bit was that Peter came back from the rest rooms, saying that he was delayed due it being occupied. When the door opened, two girls walked out of the same compartment – and I’ll let your imagination continue from here. So, as Eric commented on Trip Avisor – the music was loud, the service was slow – but the Steak WAS PERFECT. In deed, one of the finest steaks I’ve had in a long time.

One more thing I need to mention in our dinner (Eric and Myself) with John Draper – aka: Capation Crunch, but that’s a whole different story all together.


The Asterisk scaleability Unicorn

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.


Stanley is gone – Welcome PHPARI

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 – What AGI/AMI should have been

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.