Hardware Review: Allo.Com GSM Card

** This post is cross-posted on www.greenfieldtech.net **

Honestly, this is something I should have already done a long time ago. About 4 months ago, Allo.Com approached us (GreenfieldTech) to write a review about some of their products. After they agreed to the terms – mainly that they we’ll publish our findings, good or bad – we had to move offices, so everything kind’a went into limbo. Last week, finally, we got around to start reviewing the hardware. We currently started with 2 products, the Allo.COM GSM card (http://www.allo.com/gsm-card.html) and the Allo.Com MegaPBX (http://www.allo.com/megapbx-line.html).

As Eric is still evaluating the MegaPBX, we’ve decided to publish our findings regarding the GSM Card for Asterisk.

Hands on the product

So, the product itself is nicely packaged – in terms of the electronics involved. I’ve examined the soldering quality, and it would appear that it provides a fairly consistent 60% coverage of soldering, which is fairly acceptable for a card of this scale and quality. One thing I didn’t like was the usage of external wires, however, as this is not the first time I’ve seen that, I can accept it. The card itself is available in 2 form factors, so in general, the “hands on” evaluation passes nicely.

Installation

“Patches? Patches? We don’t need to stink’n Patches!” – I admit it, there is nothing I hate more than patching DAHDI drivers (Old OpenVox Style) or adding some 3rd party middleware for DAHDI to make things work (Sangoma). This card takes a slightly higher road. Yes, you are required to have the Asterisk (I do mean Asterisk) source code available. However, it will compile the “channel driver” and an internal resource, very much like the SIP channel – not requiring you to patch Asterisk or DAHDI at all – so in that respect – KUDOS !

To be honest, it took me about 2 days to get the card running, but I was at fault – well, not completely. While the compilation of a “native asterisk” channel driver is a wonderful idea, the documentation kind’a sucks. They still have milage to go with that, however, after contacting their very professional and helpful support staff – it was compiled at ease.

Operation

One thing to get used to – this card is slower, and I do mean much slower, than a normal analog card. The reason isn’t the card, it’s the GSM network. It takes about 10-30 seconds for the card to become fully active, mainly due to the fact that the SIM cards need to register with the GSM network. Once fully active, it will present a channel type GSM, which operates very much like its DAHDI analog equivalent.

The Fire Test

How the hell do you test a card? you make it work really hard – and I do mean hard. So, in order to do so, I’ve created the below Asterisk dialplan:

[from-ipphone]
exten => _X.,1,Set(TIMEOUT(absolute)=${RAND(600,7200)})
exten => _X.,n,Answer()
exten => _X.,n,Wait(${RAND(10,30)})
exten => _X.,n,Dial(GSM/2/050808XXXX,120,R)

exten => h,1,Originate(Local/111@playback-loop,exten,from-ipphone,1111,1)

[playback-loop]
exten => _X.,1,Answer()
exten => _X.,n,Wait(1)
exten => _X.,n(loop),Playback(demo-congrats)
exten => _X.,n,goto(loop)

This dialplan is designed to create random length calls, with a random waiting period between calls. I then issued the following command from the dialplan, to kick it off:

<div id="_mcePaste">noc*CLI&gt; channel originate Local/111@playback-loop extension 222@from-ipphone</div>

The above will start dialing over and over and over again. My test was really simple, generate X number of calls from my Asterisk host, receive X number of calls on my other SIP gateway. Calls will traverse the GSM network, always playing back the same message and information.

Final Result

Ok, so the test I devised was fairly harsh, specifically due to the fact that I left it running for 5 days !

My origination gateway had originated over 1000 calls in 5 days, sorry to say, only 500+ calls were accepted at the other side. Primary reason appears to be GSM network related and not card related – so it’s hard for me to attribute the result to a specific issue. However, in general, the card performed as I more or less expected it to perform.

Who should use this card?

If you plan to build a GSM gateway – this card isn’t for you, you need something with a bit more control and variability. For a mobile office or as a cellular backup to your PRI line in the office, this will make a nice addition, at a reasonable price range.

Overall mark: 7.5 out of 10

Technology? Religion? or just pure Ego?

Open Source – What really drives it? is the desire to change and create something new? is it a firm belief in the idea that knowledge wants to be free and that software should roam the world? or when you boil down – is it just plain Ego?

I’ve been an Open Source advocate and evangelist for the better part of the last 20 years. I’ve started my days with Slackware Linux, moved to RedHat, then to Mandrake, then over to CentOS – which is now my choice of OS for the desktop and server. During these 20 years, I’ve seen various project come and go, companies rise and fall, technologies adopted and abandoned. A recent post on facebook from Dovid Bender got me thinking about this issue again:

Now, let’s put aside the grand discussion on the way the OpenSIPS project came about, their domain hijacking tactics, their overall confusion in the initial stages in regards to the difference between OpenSIP and OpenSER/Kamailio – let’s just put these apart for a second. Honestly, I can’t really tell the two apart, they use the same general configuration syntax and in most cases (over 95%), you can use the same configuration on both and it would work exactly the same. So, what does it boils down to? it boils down to Ego. Do I want to be considered traditional and stable and work with Kamailio, or would I like to be perceived as cutting-edge and work with OpenSIPS (although that isn’t true at all).

The same issue can be attributed to the ever growing battle between Asterisk and FreeSWITCH. Now, each one was built for a totally different class of operation (although, Asterisk 12 does introduce new functionality that makes it shine much harder than FreeSWITCH). People repeat the old “You’re melting our switches” FreeSWITCH urban myth, but again, I still hadn’t seen one installation that truly did everything with FreeSWITCH and is truly focused on using FreeSWITCH to leverage something else. So, if FreeSWITCH is only used as a media/application server, then I see no difference between it and Asterisk in that regard. More than that, if the added value of using FreeSWITCH is just a mere 5-10% increase in performance, it just isn’t worth my time to do so. Now, I’ve used FreeSWITCH in the past, don’t get me wrong – it’s a wonderful tool in that respect, and for Class-4 switching it is a massive tool. But when it comes to Class-5 and high-level services, sorry to say, Asterisk will always be my choice – not because it is better, not because it’s support and community is far more experienced, not because it out-performs FreeSWITCH – it will always be due to one simple reason – it is the one I know will require the less amount of ongoing support and maintenance and will bring me to my target much faster than FreeSWITCH.

A few weeks ago, I put the following status on facebook:

Now, the two have direct correlation – When a CTO/VP R&D isn’t a telecom’s guy – and he takes decisions for development of the platform – simply based upon the writings of others on the net – which is purely influenced by a religious war – he is incapable of making the right decision. Take Jajah for example, when Roman and Daniel started Jajah, they only tool they used back then with Asterisk@Home – because that’s what they had. When the company grew, they could have easily moved to new grounds – FreeSWITCH was already around. Why didn’t they? Why did Jajah remain with Asterisk – adding OpenSER/Kamailio into the mix later on? Why didn’t they move to a new platform? was it because they have loads of code developed? companies throw away code like dirty socks every other day – they had the resources. Fact remains, the service was alive for a long time, the company was bought out by Telefonica Digital at a price of $215 Million.

On the other hand, let’s take a company like Truphone (and pardon me James, I know you’re gonna kick my ass next time we meet). Truphone had changed technologies over the course of times many times. Each time, abandoning the previous tech and going for a new one. So did companies like Rebtel, Spikko, Skuku and others. Amazingly enough, none of them could be considered a massive success. Word on the market currently says that Truphone is looking for additional investors, as their existing ones aren’t willing to put in more cash. Spikko’s original model is totally gone and the company literally caved-in on itself – and same applies to many others.

So, what does it boil down to? is Asterisk better? is OpenSIPS better? – these are the wrong questions. The questions should be:

  1. Is your R&D lead actually knows the arena he’s treading in?
  2. Are your decisions based on actual investigation or just by whim?
  3. Are you completely aware of the various obstacles and challenges you’ll meet?
  4. Are you building your development and product on rapidly changing technology?
  5. Who is backing your choice? a proper business entity? or a mere group of people with an idea?

When it comes to choosing between Asterisk and FreeSWITCH, here are my reasons for choosing Asterisk over FreeSwtich any day:

  1. The ability to rapidly prototype any application is 5 times faster and 2 times more economical than FreeSWITCH
  2. The installation path for FreeSWITCH is much more complex and convoluted than Asterisk, making future maintenance a nightmare
  3. Digium is indeed a young company, but it sticks by its products and makes all efforts to make it the best it can – I always have someone to talk to
  4. Barracuda Networks is a well established company in the Storage/Security market – if you go to their website, their support for FreeSWITCH (CudaTel) isn’t there at all – does that mean something?
  5. Asterisk is a very reliable, dependable, predictable piece of code – it is something I can put my money on and know exactly what I’ll get, FreeSWITCH still isn’t

Extreme Asterisk Cloud Performance – Part I

*** This post was originally posted at http://www.greenfieldtech.net

Here’s a challenging question for the Asterisk technical savvy of you… What is the top performance you can squeeze out of an Asterisk box, running on Amazon EC2 – or to that extent, a cloud infrastructure? If you scout the Internet, you may find various answers – however, most of them aren’t backed up by real numbers or real information,made accessible in a normal readable form.
Recently, we’ve become heavily involved in a project requiring massive usage of cloud based infrastructure. I won’t go into details as to what the project is or what we are doing, however, I felt that some interesting facts about Asterisk 11.0.1 and Cloud infrastructure can be shared with the rest of you.

Before we dig deep into the actual results, let’s talk about the various measurements usually associated with performance assessments of an Asterisk box, mainly, the machines load average. In order to continue, we must first understand what the Linux Load Average actually is. Most of you know load average as the below:

Load Average Example

Most people know the load average as those 3 numbers, ranging from 0 to anything higher, and if the numbers reach a certain level – it’s bad. But the question is: “What is a good number? and what makes a number bad?” First, let’s understand what the number represents. Load average is an exponential average of all your machines processes. Running processes, sleeping processes, waiting processes and on Linux, also processes currently waiting for I/O access. Now, these number are directly correlated to the number of processors/cores your server has. In general terms, a machine with a single core, any number higher than 1 is considered bad – where 1 represents 100% of the resources being consumed. So, if your machine has 4 cores, the number 4 is your top most number – and from there it’s linear. Now, can we calculate HyperThreading into the equation, multiple CPU pipelines, SSD access – in Linux, all these come into play into that equation. In other words, we’ll never know what is the actual top limit, but working with a rule of thumb based upon the number of cores is a good practice – specifically if your operational environment is a virtualized one.

Now, there are 3 numbers in there – a 1 minute average, a 5 minute average and a 15 minute average. Technically speaking, the 1 minute average isn’t really interesting – as it is highly affected by context switches and process bootstrapping, thus, there is a good chande that its number will be higher than the “advised” number. The numbers that are more interesting are the 5 minute and 15 minute average. Technically speaking, if your machine’s load average is considerably higher than the advised at these, something is definitely wrong.

Updates, Astricon, Allo.com and more

Ok, before all of you jump at my throat for not posting for a long time – I’m sorry. I can’t believe the last time I posted was around June, much has changed since then. So, let’s start with some updates… well, there are no big news updates. Since I left Humbug, I’ve been doing my best to keep busy with GreenfieldTech projects. We’ve successfully completed 10 different custom development projects since June and we’ve started a brand new services branch at GreenfieldTech – the VoIP Security Audits branch – but that’s a different post altogether.

So, I spoke at this years’ Astricon, which took place in Atlanta, Georgia!. This is my first time to the southern parts of the USA and might I add, Southern Hospitality is something you need to experience (I’ll write about that later). Much had changed at Digium in the past 2 years. Many of the long time project members had left to new grounds, Asterisk-SCF is now officially no longer in active development, in other words – this years’ Astricon was a fresh breeze of wind, specifically with new people at the driver seat and new ideas springing about.

So, let’s talk PRI cards. Once every often a company approaches me to evaluate their products. I do my best to be as impartial as I can – after all, Digium products are my favorite. However, I’m always happy to see a product that can compete nicely with Digium, simply because I believe it will make Digium products better and stronger. So, a couple of months ago, Allo.com approached me to evaluate their PRI card. I agreed, and they’ve sent me their PCI-e version of a quad span E1/T1 card.

Allo.Com PRI Card

So, let’s start with what I didn’t like about the card. People, it’s 2012, technology had progressed a great deal since the old Zaptel days, not to talk about the old Xilinx Spartan chips – comm’on, even the crappy Chinese boards don’t use that anymore – move on. Ok, let’s put aside the issue of the actual chips being used on the board – can someone PLEASE explain to me why I need to patch my DAHDI modules to support these cards? How shall I put it, patching DAHDI/ZAPTEL is so 2004. Make your card fully compatible with DAHDI, no patching, stream line the card with the DAHDI stock kernel module – OpenVOX did it, Yeastar did it (do an extent) – you want me to use your hardware, make it easy to install and simple to update and maintain.

OK, regardless of my somewhat reluctant feelings regarding drivers compatibility, I had the unit installed in a test gateway. It performed as I expected from a low-cost compatible. It held up nicely with normal traffic, but when I tried pushing 30 call initiations per second on the card, it heated up slightly and CPU spikes could be observed here and there. Now, in an office scenario – sure this card will do nicely – in a service provider scenario – I’ll think twice. Now, in the past I’ve received similar performance from other clone cards, so my estimate is that there is a group of engineers passing from one company to another, coming in with the know-how for a single design and they wrap that into a card.

Final word regarding the Allo.com card – not my favorite, but definitely a possibility for office environments. I have no idea how their other equipment holds up, but I hope that it holds as well, so that the office/smb market has a new option to choose from.

I will post my Astricon update later on.

The natural evolution… of people and startups

It has been a while since I’ve written, I guess I didn’t have much to write about. Ok, I admit it, I had a shit load of stuff to write about, however, I simply never got around to actually do it. A full time job, two babies – or as they call it – real life, has somewhat managed to creep up to me and take its toll on my writing time. Over the course of the past few months, I’ve been heavily thinking about the role of the founder in a startup. Many people regard the founder of a startup as the CEO or some other key role in the company, but it’s not always like that. The question that I asked myself, and I have been for quite some time, is: “as a founder of a startup, what is the most important thing I need to know?” – I recently realized that the most important thing, is also the hardest thing to do.

As I see it now, the most important thing a founder needs to know how to do is: “When to walk away!” – Yes, you heard me right, understanding that you as a founder have to walk away from your creation is the hardest thing you’ll ever do. In many cases, walking away may seem to you like bailing out or giving up, but this is not the case. Sometimes, walking away means: “I’m entrusting my creation with someone else, simply because I can’t progress it any more”. It is very easy to become infatuated with your startup, it’s just like a baby. Initially, it’s just an idea, then after a long incubation time, suddenly it takes form. You hire people, slowly afterwards, you have a proof of concept, then you start selling, then different things can happen – some good, some bad. At that point in time, that’s a critical path, this is the time where you might find yourself at an impasse with your partners, investors, customers, VC’s, etc. What should you do? stay and fight? or just pack up and leave? – well, it all depends on your situation. I won’t detail the situation when you need to fight and stand your ground, as those are fairly easy. The harder ones relate to when to leave.

I would say, that if any of the following are upon you, it’s time to leave:

  • Your investors are pushing toward an illogical track, although, they have no idea how the market nor the niche works.
  • You ran into financial issues and leaving is a logical step in order to continue the life of the company.
  • You are at an impasse with the CEO or other members of management, the issue can’t be bridged.
  • You have lost trust with your partners.

At any of those, you must pack up and leave. The reasons are simple enough, all of those relate to direct trust between people. When trust is no longer there, it’s better to pack it up and move forward, simply because it won’t go to good places.