Asterisk’s New Friend in Israel – Cellcom

Cellcom

Cellcom

Since early 2006, an ever increasing competition between the local PTT carriers in Israel, had introduced an unlikely friend to the Asterisk community in Israel. While Cellcom, one of Israel’s largest cellular carriers, isn’t closely associated with the PSTN market – it’s entrance to the local PTT market, especially into the E1 PRI market, had introduced the most unlikely friend to Asterisk.

Cellcom’s highly aggressive marketing techniques, rapid deployment of skillful sales agents and a highly motivating sales campaign – had yielded a migration of many customers from the local PTT carrier (Bezeq) utilizing Analog lines with traditional PBX systems, to low cost, PRI circuits provided by Cellcom, with low cost Asterisk based IP PBX systems.

Now, coming 2009, Cellcom had sprung up a new marketing campaign for their new service line: all-in-one Internet access and telephony service for your home. The service is rendered via the utilization of an OPTION GlobeSurfer II devices, allowing you to connect your home wireless network and an analog phone directly to the device.

OPTION GlobeSurfer II

OPTION GlobeSurfer II

So, why is Cellcom becoming a better Asterisk friend? very simple, the usage of the GlobeSurfer II device, in an SMB environment is the ideal companion for a small time Asterisk installation – in the office. Each GlobeSurfer devices allow us up to 2.4Mbps of downlink Internet with 384kbps of uplink – and a dedicated phone line. All of this, for a low cost of 29$ per month (give or take a few dollars). By all standards, that price is lower than any of the high-power uplink Broadband connections in Israel – thus, this is an ideal choice for a small office. Now, all that we need to facilitate an office of 4-6 people, is to have two of these units, get a router that can support multiple (2 or 3) Internet uplinks – walla – we have the perfect office communications suite. Another added value is that our office is now truely mobile – we want to move offices, no problem, takes 10 minutes to move the offices and start working again. Now, the only thing that’s missing from the mix is the availability of static IP addresses on the link, and you’ve got a serious potential looking at the new PTT killer in Israel – Wireless Internet and telephony to go – at a price you can afford.

Other questions that remain are:

  1. Will Cellcom allow for a single mobile number/landline number to be associated with multiple SIM card gateways such as this, allowing for office redundancy and maybe in the future true IVR capabilities?
  2. Will Cellcom allow its customers to aggregate more bandwidth in the future, allowing for true VoIP services to operate using these units?
  3. While the units are fully capable of rendering up to 7.2Mbps downlink and 2.4 Mbps uplink, Cellcom is limiting these to 2.8 Mbps downlink and 384kbps uplink – will they increase that in the near future?

All things considered, I believe that this unit will make Cellcom into a new contender in the market, allowing for new residential services and competition to exist – in other words, the heat in the Israeli residential and SMB market in on – let’s get cooking.

Raichu Asterisk Anyone? – PIKA WARP REVISITED

When I last reviewed the PIKA WARP Asterisk appliance, I  named the post “Pokemon Asterisk” – today I’ve decided to review the PIKA WARP Asterisk appliance again, only this time, with the newly released Asterisk GUI 2.0 release – our cuddly Pikachu is now a Raichu (relax, it took me about 30 minutes to find out what a Picachu evolves into).

The new PIKA appliance now boasts the new star fangled Digium Asterisk GUI 2.0, which takes the old Asterisk GUI (which was OK, but still had some miles to go) and more or less throws it into the waste bin. The new GUI is far more useful, far more usable and most importantly – makes life way easier for the integrator. While the previous version of the PIKA Warp appliance was targeted for developers, the new version of the WARP is aimed directly into the heart of the integration scene.

Asterisk GUI 2.0 on PIKA WARP

Asterisk GUI 2.0 on PIKA WARP

Now, I have to admit that after upgrading the system to the new PIKA WARP cuImage I had some issues logging into the system. So, what I did is more or less hack myself in via ‘single user mode’. Here’s a small guide on how to do that. Before we being, you will require a serial cable connection to the WARP appliance in order to do this, which means, this is more or less a hardcore procedure.

The PIKA WARP Serial Connector Port

When the system boots up, and you are confronted with a message saying “Hit any key to stop autoboot:” simply hit any key on your keyboard, and you’ll be fronted with the “=>” prompt, indicating that the boot loader is now waiting for information. Now, we need to tell the PIKA WARP appliance to boot into single user mode.

To do so, we need to modify the ‘ramargs’ environment variable of UBOOT, to indicate that we want to start single user mode. Enter the following command:

setenv ramargs setenv bootargs root=/dev/ram rw ramdisk_size=130000 single

This will indicate to the UBOOT loader to initiate a single user mode bootup. Once in single user mode, you can use the ‘passwd’ command to change the root password of the PIKA WARP appliance. This procedure can be used by an other PIKA WARP based appliance.

Once of the nice additions in the new Asterisk GUI 2.0 is the support for Class of Service, which doesn’t really exist in FreePBX. In many offices, managers like to restrict various extensions from accessing different parts of the telephony system – that is performed utilizing the Class of Service screen.

Class of Service management

Class of Service management

The “Class of Service” management enables you to create groups with access to specific trunks or PBX functions, thus, enabling you to seperate users and groups of users from specific PBX resources. For example, some users can be completely restricted from using outbound trunks, while others can be restricted to using a single FXO interface out of 4 connected FXO interfaces. In general, this is one of the best features in the GUI yet in my opinion.

I’m currently reviewing the new version, so once I have new information I’ll post my findings.

PIKA Warp + FreePBX = Still some distance to go…

As I wrote a couple of days, I’m currently in the process of evaluating the PIKA WARP appliance. As I already said before, the PIKA WARP isn’t a real PBX, but actually a framework for building PBX type appliances.

For me, the entire evaluation process is more or less a process of trial and error, trying to figure out how the box is built, both from the software side and both from the build-tools provided with the appliance.

The process of flashing the new FreePBX based images wasn’t much of a hassle, actually, after more or less fucking up the box a couple of times, I became fairly handy with both the warploader and uboot tools, used to flash the onboard flash memory with a new boot image. After flashing the FreePBX about 3 times, I got it to come up right on my browser window, which produced the following screen:

PIKA FreePBX Screen

PIKA FreePBX Screen

Now, it was fairly clear to me that MySQL (a mandatory component of FreePBX) isn’t a shoe in for the WARP appliance, after all, for an appliance it would be a blowtware. So, FreePBX here comes with SQLite, which on the surface should provide for similar functionality. Having worked with SQLite in the past, I knew for fact that some portions of FreePBX will not work – who am I kidding? if they would work it would be the most amazing thing I’ve seen a long time.

Mainly, this is caused by variations between the SQL code and various table management that FreePBX imposes on the FreePBX database structure, when installing or upgrading new or existing modules. For example, trying to go about and install the FreePBX IVR module yields the following error:

FreePBX error on WARP appliance

FreePBX error on WARP appliance

Well, that’s understandable – basically means that the unit isn’t yet fully useable with FreePBX – but we are getting there I guess, after all, rome wasn’t built in a single day.

Pokemon Asterisk Anyone?

So, over the past 2 years, we’ve seen many Asterisk appliances – ranging from the Digium AADK on one side of the spectrum to the RoweTel IP04 appliance, it is clear that appliances are the hottest thing in the Asterisk sector to-date.

While most appliances take on a similar form, usually one of the following: an ADI BlackFin reference design or a PC-Engines Geode based appliance, one company decided to go completely the other way around – namely PIKA technologies. Now, don’t let the name PIKA fool you, these guys are no pokemons, they know their stuff.

While at AstriCon 2008, I’ve been approached by the people at PIKA technologies, asking me to test and evaluate their WARP Appliance product – a Linux based appliance framework, for building Linux based appliances, with a focus on telephony. They awarded me with an appliance to test, equipped with 5 FXS ports and 4 FXO ports, I was on my way to start my telephony appliance.

First thing’s first, computing power – while most appliances rely on fairly low scale computing power, the PIKA appliances boasts a massive PowerPC CPU, with a uCkernel based Linux 2.6.X kernel – while many other appliances still rely on 2.4.X. The on-board LCD display makes finding your appliance IP number a breeze, which is very important in my book. Opening the box is very easy, exposing its inner workings:

One thing nice about the LCD display is the fact that once you plug something in, the LCD will show the applicable LCD icon as connected – making for quick diagnostics for the lame sysadmin a breeze.

Now we’re getting to the slightly annoying part, the WARP appliance is not your average PBX appliance – in fact, it’s not a PBX at all – it’s a framework for building telephony appliances. So, if you want to get Asterisk + FreePBX to run on it, you’ll need to spend some time getting it up and running correctly. If you want to start working with the appliance, I suggest that you get to know cross-compiling and build tools, in order to utilize the buildtools provided with the appliance.

Over all, the appliance comes with a fairly stock Linux and Asterisk pre-compiled, with all the required modules to get a fully functional PBX running. For my initial tests, I’ve used the AsteriskGUI, which worked just fine with the system, making the configuration a breeze.

I’m currently evaluating their FreePBX build-tool, provided by Philippe from FreePBX, and we’ll see how that goes.

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…