Posts tagged digium
Well, I just got back from the ITExpo show in Miami, Florida. I have to admit that I really enjoyed the venue, although I didn’t really have time to walk the floor. The main reason that I was unable to walk the floor was due to the fact that I gave a talk, as part of the Digium Asterisk World venue, which was co-located with TMCnet’s ITExpo.
My talk was about the possibilities and incentives for Virtualizing Asterisk using VMWARE and Amazon EC2. Following below is the presentation that I gave.
As some of you may know, I’ll be attending the ITExpo in Miami Beach, Florida. The subject I’ll be lecturing about is “Virtualizing Asterisk”. However, I have to be honest, I really need to change the subject to be called “Asterisk in the Cloud“.
Ever since the introduction of Amazon EC2, people had been trying to get Asterisk to run properly inside an EC2 instance. While installing a vanilla Asterisk on any of the Fedora/RedHat variant instances in EC2 isn’t much of a hassle, getting the funky stuff to work is a little more tricky.
One of these tricky bits (which I hadn’t yet found a solution for) is the issue of supplying a timer for Asterisk’s MeetMe application. In the old days (prior to Asterisk 1.6), Asterisk required the utilization of a virtual timer driver, provided by Zaptel in the past and now the DAHDI framework. The problem is, that while you are fully capable of compiling and installing DAHDI on an Amazon EC2 instance – the problem starts once you want to use it.
A few words about Amazon EC2
For those not familiar with Amazon EC2, its general infrastructure is based upon the XEN virtualization project. XEN is a para-virtualization framework, meaning that is performs some of the work utilizing the underlying Operating System kernel and some of the work performed with a special Kernel in the virtualized Operating System instance. This poses an interesting issue with every type of application that relies on hardware resources and their emulation.
To learn more about the XEN project, go to http://www.xen.org.
So, where’s the big deal?
So, if you can compile your code and run it in an instance, as long as you have the kernel headers and kernel source packages – you should be just fine – right? WRONG!
Amazon EC2 deploys its own Kernel binary image upon bootstrap, causing what ever compilation you may have done to the Kernel to go away (unless you’re creating a machine from real scratch). Another issue is a version skew between the installed Operating System kernel modules, the actual kernel and the installed compiler. For example, the instance that I was using had the XEN capable kernel compiled with gcc version 4.0.X, while the installed operating system was gcc version 4.1.X – so, no matter what I did to compile my kernel modules or binary kernel, I would always end up in a situation where loading the newly compiled kernel modules will generate an error.
Did I manage to solve it? – NOT YET. I’m still working on it, and I have to admit, that considering the fact that I have over 10 years of Linux experience and had compiled kernels from scratch many times, this one has gotten me a little baffled – I guess I’ll just need a few more nights and a case of Red-Bull to crack this one open.
So, what can we do with EC2?
In my view, EC2 + Asterisk is the ultimate IN/NGN services environment – and I have proof of that. A recent lab test that I did with one of my customers showed a viable commercial alternative to Sigvalue when using Asterisk and EC2 structures. The main reason for our belief in using EC2 was the following graph:
What we’ve noticed was that while our IN/NGN system was generating traffic, it’s general usage showed peak usage for a period of 2.5 hours, with a gradial increase and decrease over a period of almost 10 hours. Immediately that led us to a question: “Can we use Amazon EC2 to provide an automatd scaling facility for the IN/NGN system, allowing the system to reduce its size as required?”
To do this, we’ve devised the following IN/NGN system:
Our softswitch would have a static definition of routing calls to all our Asterisk servers, including our EC2 instances which had static Elastic IP numbers assigned to these. The EC2 Controller server was incharge of initiating the EC2 instances at the pre-defined times, mainly, 30 minutes prior to the projected increase in traffic. Once the controller reaches its due timer, it will automatically launch the EC2 instances required to sustain the inbound traffic.
For our tests, we’ve initiated 5 AMI instances, using the EC2 c1.medium instance. This instance basically includes 2 cores of an AMD opteron, about 8GB of RAM and about 160GB of Hard drive – more than enough. Initially, we’ve started spreading the load evenly across the servers, reaching about 80 concurrent channels per instance, and all was working just fine. We managed to reach a point where we were able to sustain a total of about 110 concurrent channels per instance, including the media handling – which is not too bad, considering that we are running inside a XEN instance. The one thing that made the entire environment extremely light weight is the GTx Suite of APIs for Asterisk. Thanks to the GTx Suite of APIs, scalability is fairly simple, as all application-layer logic is controlled from a central business logic engine, serving the Asterisk servers via an XML-RPC based web service. Thanks to Amazon, practically infinite, bandwidth allocation – the connections from the Asterisk servers to the US based central business logic was set at a whopping 25mSec, thus, there was no visible delay to the end user.
It is clear that the utilization of Asterisk and EC2 operational constructs can allow a carrier to establish their own IN/NGN environment. However, how these are designed, implemented and operated are at the hands of the carrier – and not a specific vendor. If the carriers around the world will take to this approach, time will tell. As a recent survey stated that 18% of the US PBX market is currently dominated by Open Source solution, having Digium dominate 85% of these 18% (~15%), I’m confident that we will see this combination of solutions in the near future.
As some of may know, I spend most of my time working as an Asterisk Developer and Consultant in my own company – called Greenfield Technologies Ltd. - named GreenfieldTech for short. Since the day I started my company I knew a few facts and truths:
- GreenfieldTech starts as a one man operation – thus, spending more than 15% of my day to day tasks on support issues will surely stress me out and drive my business to the ground.
- I don’t really want to deal with PBX installations and various office telephony aspects of using Asterisk – simply because it requires to much of item 1.
- I need a way to be able to provide a fast response to my customers, maintain a low support over head and make sure that what ever I do, it can be accounted for.
Hence the above, I understood that GreenfieldTech‘s products are not really the various services it provides, but actually the products vary completely from what a product looks and feels like. I understood that in order to provide this fast development turn-around I needed my own development framework. Surely PHPAGI, Adhearsion and Asterisk-JAVA can easily provide for a development framework – but it still doesn’t help me one bit – I needed something different.
I then realized that GreenfieldTech‘s products are the one product line that all developers and vendor steer away from: Programmatical API frameworks. The programmatic framework should provide the most basic feature set, allowing it to be extended and continued onwards at ease. Hence, the suite of GTx API frameworks were born. A set of 3 different APIs provide all the facilities required for building any of the below:
- Dynamic IVR structures – driven via web services
- Recording systems
- Pre-Paid/Post-paid solutions
- Inteligent Network (IN) services
- Automatic Dialers – Predictive, Power, Progressive, Preview
- Broadcasting systems
- and more …
The entire API suite is based upon XML-RPC based web services. When I introduced XML-RPC to one of my customers, he immediately indicated: “But, XML-RPC doesn’t really provide for session oriented persistency. Why are you using XML-RPC?” – The reason is simple – we don’t need session persistency in the API – Asterisk can provide all of that internally. Thanks to Asterisk’s channel oriented architecture, we can regard each of Channel thread in Asterisk as a seperated data container, capable of holding all your session information and persistency information at ease.
The best thing about the GTx API suite is this – they are all interconnected. For example, call being handled by the Dialer API can be then handed over to the IVR API, operating within the same Asterisk server or a remotely located Asterisk server (via SIP/IAX2).
In the time to come, I’ll be showing you various XML-RPC structures and example of how to use the GTx API suite, and do all sorts of interesting IVR and Dialer structures.
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.
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.
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.
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.
I really like marketing spins, there is nothing more amuzing than a good marketing spin – especially when its being performed by a big company. Israel, as much as I don’t like admiting it, is one of the world’s biggest spin experts, especially when it comes to technology and marketing. One of my best friends used to work as a marketing manager at a high-tech company. According to him: “We can take each and every product of ours and resell it as 5 different products, it all depends on the customer required spin that we need to display!” – well, putting marketing aside and going back to technology, Sangoma recently announced 2 new Hybrid interface boards for Asterisk.
The boards are called: “B600″ and “FlexBRI”. Let us examine the spec on these:
Sangoma B600 Board
The Sangoma B600 board boasts 4 Analog FXO interface and a single FXS interface. The combo is very interesting, as it enables a small office to utilize up to 4 inbound analog trunks, while connecting their FAX machine directly to the board itself, allowing for better fax transmission without relying on T38 and other Fax-Over-IP methodologies.
In general, I believe that the card density and idea is good. While many people believe that Sangoma competes head-on with Digium, I believe that this product has nothing to do with the Digium/Sangoma race. In my view, this board actually tackles the same niche market as the PIKA WARP appliance, as it boasts a similar perspective in terms of connectivity. I don’t believe this is a spin, as this product has a valid market share, especially in upcoming markets such as Africa. With a boasting price of around the 400US$ mark, I believe the card will gain popularity with the small TrixBox/Elastix/PBX-in-a-flash fly-by-night integrator scene, as it fits that niche fairly well.
Ok, the Sangoma FlexBRI card, at least from where I’m standing, in nothing but a worthless spin. It boasts 4 BRI interfaces and 2 analog interfaces (FXO or FXS). Why do I call it a spin? well, simply because I hadn’t seen a BRI installation in the past 4 years. I figure that Sangoma in now tackling the German market, especially the one being catered by the card made by Junghanns, however, these provide a fairly strange combo. In any case, the niche here is very much target to a select number of countries in the EU, so the validity of this product in the world is close to null – thus, I call this one a pure spin. The marketed price is yet to be revealed, however, judging from the density and the functionality of such a card, I’m not sure its price will allow it to be a valid market option. In addition, with the PIKA WARP ISDN appliance that is due to be out later this year, there is a high chance that this product’s voice will be nulled by an appliance of same density and easier integration.
Yeastar YE110 – Single Span E1/T1/J1
Yeastar is a chinese manufacturer, making Asterisk compatible boards for the Analog market. The YE110 is their first attempt at approaching the highly growing market of the E1/T1 circuits market. According to the website, the YE110 is fully compatible with the Zaptel drivers, thus, it doesn’t require any driver patches – which is a wonderful thing. We still have to learn about the stability and capabilities of this card, however, as it uses a similar chipset to the old Digium TE110P card, I suspect we’ll notice similar performance and capabilities – yet to be seen.
PhonicEQ cuts price by almost 40%
PhonicEQ had cut their prices by almost 40%, across their entire product line. Now, I admit that I’ve used their products and I was fairly happy for a while – however, as Zaptel versions progressed and Zaptel turned into DAHDI, PhonicEQ didn’t issue out any new drivers and updates – so I had to patch my own versions of the driver.
In my view, PhonicEQ cards needs to regarded as: “The poor man’s Asterisk card” – if you can’t afford anything else, then go with PhonicEQ. You’re probably wondering why I’m saying that, after all, everybody who knows me knows that I’m strongly affiliated with Digium. Well, when I started my business, I couldn’t afford a Digium card, even used cards were fairly expensive, I have a distinct issue with the Sangoma distributor in Israel (so I’ll never use Sangoma) and PhonicEQ seemed like a good choice at the time. I purchased the card, only to realize that I need to massively patch Zaptel in order to get it to work (something that wasn’t said on the site). For me, patching Zaptel and Asterisk isn’t anything new, so it took me about 30 minutes and I was up and running, no problem. However, for most Asterisk users, this may be a slightly more advanced task than others. In any case, PhonicEQ is still considered in my book as “The poor man’s Asterisk card” – use it only if you have no other choice.
ITExpo 2009 – Miami Beach, Florida
Well, it’s now official, I’ll be lecturing at ITExpo about utilizing Asterisk and VMWARE as a dialer framework for high-speed dialer services. If you will be in Miami for the conference and you’d like to meet, just look me up. I’ll be landing on the 2nd, so I guess i’ll only be up and running (pending jet-lag) on the 5th. C’ya all there …