Well, it’s been almost a month since I’ve started writing about the humbug project. Now, it’s time to actually get you people involved, at least in the initial levels. We are looking to add 10 additional members into the humbug call analytics suite. Currently available analytics during the alpha testing is inbound call analytics.

Our aim is to gather as much information as we can and as much user requests as we can, humbug is a community oriented project, thus it relies on community oriented input and feature requests. Participating members will  be granted access to the humbug analytics portal, allowing them to gather statistical information regarding their inbound call hits and their top ten DID numbers – we are working on additional statistics. As new stats will become available, we’ll role those out into the service as soon as possible.

In order to participate in the closed alpha testing, please send an email to alphatest at humbuglabs.org, and we’ll send you a short piece of dialplan code to insert into your Asterisk server. Technically speaking, we’ll send you a short AGI command that looks like this:

exten => _X.,n,AGI(agi://somehost/DataReceiver,some_unique_ident)

The above line needs to be inserted into any place you would like to generate call analytics from. We’ll also enclose configuration steps for FreePBX (and other FreePBX compatible distributions). We are hard at work for creating a FreePBX integrated module, so you can do a one-click install.

When most of us think about PBX systems, we usually associate these with cumbersome usage, confusing dialing codes and in most cases – a PBX system is automatically associated with the annoying task of transferring a call from one handset to another. Lately, I’ve been thinking deeply about how people use PBX systems, is this really the only way to use a PBX system? is there something else to the mix? can we really enrich one of the oldest operational paradigms in the world? – and for that matter, can the public be re-educated to assimilate a new breed of PBX systems or services?

As to answering the question of re-educating the public, I guess I’ll have to leave that question to the head shrinks. As to answering the latter, enriching the PBX experience is both achievable and advisable. When I say enriching, I mainly talk about your ability to bring to the IP phone functionality usually not associated with it. Imagine to have the ability to receive a stock exchange RSS feed to your phones idle screen, notice that you stock is either rising or falling, and by the flick of a button – either sell or buy. We’ve all come accustomed to IP phones that look like the one of the right. A whole bunch of buttons, that in most cases have no direct use when our phone is utilized using a single account. However, these buttons can be externally re-assigned and re-programmed to achieve greater functionality – surpassing the normal behavior of just making phone calls.

The technology involved exists on almost every high-end IP phone on the market (well, at least those made by SNOM, Aastra, Cisco and Polycom – most of the Chinese makers don’t have this) – it’s called a Mini Browsers. Mini Browsers are exactly what they are called, these are simplified versions of your typical Internet browser. Some vendors had produced their own XML based Mini browser markup language (SNOM, Cisco, Aastra) while others had decided to provide a sub-set of XHTML (Polycom). The variations between the vendors are at the neck deep of the problems of using Mini Browsers, and that is that the formats are considerably different. Sure, SNOM had more or less adopted Cisco’s general structure, however, it still varies.

Through the utilization of this technology, it is possible to create phone based browser applications, that seem native to the phone user, as the general interface resembles the native phone interface. It is now the developers job to make the web interface displayed to the user as seamless and as native as possible, keeping in mind that the developer must remain agnostic to the information retrieval layer. Most companies leave their phone systems and these tasks to their system administrators and infrastructure team, however, this task is far beyond their capabilities and skill set. Creating an agnostic IP phone minibrowser dislplay layer, capable of utilizing multiple vendors and models, is a question of content management and content rendering, very must similar to the content transcoding problem that is common to the mobile content world – in other words, a sys-admin will create an ad-hoc solution, a programmer will create a proper, well structured, well designed solution that carry the enterprise beyond its initial needs and requirements.

A short example of how these interfaces work can be found here – on my company blog.

If there is one thing I like doing is testing hardware, specifically, testing new hardware that is related to Asterisk. I was more than pleased when OpenVox had approached me, asking to review one of their products – specifically after I once announced that I really dislike cheap clone cards. So, I got OpenVox’s D210P card, which is a fairly similar clone to the TE205/TE210 of Digium, and I decided to take a it for a test drive.

So, first off, lets take a look at Digium’s TE205 card:

Digium TE205P Card

The card is based upon two specific chips, the Xilinx Spartan FPGA and an Inifineon based Quad E1/T1/J1 framer chip. Technically speaking, the entire brain of the outfit is located in the Xilinx FPGA (naturally), which on the TE205P now enables remote firmware upgrades and some additional features. Digium had been using Xilinx based boards for over 8 years now, and they’ve been doing the job more than well.

Now, let’s take a look at the OpenVox clone board:

OpenVox D210 Card

The Test Scenario and Comparison

All of the above tests were conducted according to the following scenario:

Testing Lab Server

In general, I’ve connected 3 different IP phones to the testing server: A Polycom 650, a SNOM 370 and a Grandstream GXP2000. All IP phones include the latest firmwares and updates and were all working flawlessly with another similar setup, so I assumed they were all bug and issue free for the testing lab. The main reason I’m using 64Bit CentOS is simply due to the fact that all my servers are 64Bit capable (mainly E5410 and E5405).

Test 1: Normal Telephony

Well, in general, the card does exactly what it should – provides a connection to an E1 circuit (we only have E1 circuits in Israel). I’ve conducted normal telephony functions from all the above mentioned phones. In general, I’ve conduct from each phone a total of 40 calls, and repeated the test once for the Digium TE205P card and once for the OpenVox D210P card. The results were fairly similar with a slight advantage for Digium. In general, the OpenVox card had slipped about 4% of the calls, mainly to an IRQ miss that occurred for some reason. With the Digium card, the IRQ misses were not exhibited, allowing for all 120 calls to traverse normally.

Conclusion: In a normal office telephony scenario, the D210P is a fair choice – however, not my preference for a Call Center or a service provider.

Test 2: 3G based transmission (64kbps bearer capability)

I’ve been playing around with IVVR and Asterisk, mainly using the Fontventa H264 packages for Asterisk (that’s why I used 1.4 branch). With this test, the D210P provided less then medium results, specifically when trying to stream large 3gpp based video streams, while the TE205P had showed no specific issue with the transmission. Main issues exhibited were related to choppy video streams, causing jumps in the stream. The Digium card was fully capable of stream the video without a hitch. Now, I won’t hold this again OpenVox, as this usage is fairly advanced and is required by a very small portion of the market, but I believe they still have some work to do there. As they are using the same framer as Digium, I would deduce that their firmware is either an older import from Digium (reverse engineer) or some other firmware related issue.

Conclusion: Not a pick for 3G transmission with Asterisk.

Test 3: Dropped calls during high loads

No matter what test I did, with OpenVox I’ve always received a dropped call ratio of around 3-4% – when at high loads that went up to around 7%. When I mean high loads, I mean generating 30 outbound calls from Asterisk to one circuit, then receiving them on the second port (yes, a back-loop). I’ve conducted 100 runs of this test, at various speeds. It would appear that when generating calls with a 100ms interval between one initiation to another on the circuit, the OpenVox will drop a call here and there – at sporadic intervals. This may be actually related to the IRQ misses exhibited in Test 1.

Conclusion: If you have high load anticipated – OpenVox is not the choice for you.

Test 4: CPU Load/Spikes

It is a well known fact that all card that are used with Asterisk introduce load spikes of a sporadic nature. In the past, the masters of low spikes were Sangoma, however, with the introduction of Digium’s VoiceBus, that balance had tipped and Digium took the upper hand. In order to evaluate the spikes, I’ve monitor the machines’ load while having 30 calls traverse from one port to the other. The calls were playing back a static file of 5 minutes, and after disconnecting the calls would generate and additional one and continue from there. Both cards exhibited slight spikes when multiple calls either originate or disconnect, however, the CPU spikes that the OpenVox card had exhibited were about 40% higher than the ones exhibited by Digium and there were more spikes than with Digium.

Conclusion: If your system isn’t as beefy as mine, and you need full capacity – OpenVox isn’t the choice for you

Overall Operational Conclusion

The OpenVox card promises to be a low-cost alternative to the Digium card, and it surely delivers. Over all, if you have an office PBX system or a low scale IVR environment, the OpenVox alternative can be evaluated, although it’s not my personal favorite. Sure, in many cases I can say: “OpenVox would do the job” – but hey, I would always rather go with the original and not the clone. I believe that OpenVox are far ahead of its clone competitors (Atcom, Yeastar, Varion, PhonicEQ, etc), simply because it does a better job at building and designing a better card – however, they still have some way to go in order to be completely in-lined with Digium and Sangoma.

Well, I guess it’s time for another Israeli Asterisk update post – one that was well due a long time now. This post was written after the recent hectic 3 weeks of Asterisk events and news here in Israel. So, I guess we’ll open with some news – beep, beep, beep.

Asterisk based Contact Centers

EasyRun, a world wide provider of Call Center and Contact Center solutions had announced the availability of its EpicAcce solution.

EasyRun Partners with Xorcom to Offer the Industry’s First Enterprise Grade PBX Agnostic Contact Center

EPICAcce Delivers the Industry’s First PBX Agnostic Enterprise Grade Contact Center Solution

For those in the know, the EpicAcce solution is based upon the Asterisk Open Source PBX system, bundled inside a Xorcom XR3000 appliance. I’m proud to say that I had some involvement in the development of this product, mainly, having trained the EasyRun lead developers in the workings of Asterisk – in the first Asterisk Bootcamp that was held in Israel last year. The EpicAcce appliance is defined as a PBX agnostic contact center solution, thus, it will work in any type of PBX or enterprise installation – making it the ideal solution for any company wishing to embed a contact center to their customer care, without the requirement of changing their entire company telephony infrastructure. In addition, the same unit can also be used as a the company PBX system – after all, it is based on Asterisk underneath and FreePBX as the management interface for Asterisk.

Asterisk gains recognition by the TheMarker.Com

About 3 weeks ago, I got interviewed by Amitai Ziv, a telecom reported from the TheMarker.Com IT news section. The interview (in hebrew) is available at the following URL:

http://it.themarker.com/tmit/article/6255

Now, while the article had mentioned about 25% of the actual interview and also summed up various statements from other people two, in general, it was very supportive of the Asterisk initiative and movement in Israel. I guess, well at least from my point of view, this article is a valid turning point – where the Israeli main stream industry acknowledges Asterisk as a valid business viable solution. In addition, as the founding father of the Israeli Asterisk users forum (www.asterisk.org.il) it is a great honor to be interviewed for this magazine. Sure, I make a living from promoting Asterisk and developing Asterisk based platforms, but having your face (although a horid picture) in the paper and having your name mentioned in a positive manner – is always a good thing.

Israeli Telecom Manager Club recognizes Asterisk

Yesterday I attended the “Israeli Telecom Manager’s Club” quarterly meeting, which was focused entirely on the viability of Asterisk and other Open Source based solutions. While most of the audience was made of large companies and captains of industry (Coca-Cola, TEVA, Israeli Electric Company, others) – I didn’t get the dreaded lazy eye I got almost 3 years ago.

When I started promoting Asterisk in Israel, almost 7 years ago, people looked at me as the crazy guy that has no idea what he was talking about. After all, I was an IP/Web technologies engineer, suddenly, starting to talk about telephony – in a world where 50 year old engineers were controlling and dominating entirely. Suddenly, a new kid on the block comes in and says: “Listen, Open Source can do it as good – if not better“. Yesterday was a turning point, suddenly, all these people came in to listen to me, preach and promote, both Asterisk and proper Open Source adoptation and GPL compliancy.

Israel is changing, companies start realizing that using GPL and modifying GPL products isn’t something to be taken lightly – it must be done with experts, and people that actually know what they are doing in the Open Source world. The old time Open Source geeks are starting to gain the industry recognition – Israel is finally starting to reach the state where the US and Europe are currently located at.

Digium announces availability of Support Services

This is not the first time Digium had tried doing this – first time was about 2.5 years ago. The current support services are based upon a signed service agreement, allowing the customer to receive phone based support services. According to the Digium website, the pricing model is as following:

                               SMB L1   SMB L2   Enterprise L3   Enterprise L4
Included Systems (Servers)        1         1          Up to 5         Up to 10
Included Cases (Incidents)        2         5             10           Unlimited
Additional Server Price           —         —          $495.00         $395.00
Named Contacts                    1         1             1                3
Price - 1 Year Subscriptions   $595.00  $1,995.00     $3,995.00        $7,995.00

Ok, not that I have a problem with that – I guess in the world people are willing to pay upto 300$ for a support incident – however, in Israel, that makes no sense. Judging from my experience supporting Asterisk, over 90% of the support calls can be resolved in less than 30 minutes. Charging an amazing price of 300$ for remote hands support, for an incident of 30 minutes – that is outragous. It’s true, I’m a Digium fan and I promote their products where ever I go, however, in Israel – this model will not cut it.

My company, started rendering Asterisk support services in Israel back in December 2008. Our support model is completely different – making it ideal for the Israeli market. Our support model is based upon a base line service agreement, indicating that you pay a total of 2,300 Israeli Shekels (around $500) for up to 10 hours of phone based and remote hands support services. These are rendered for a single server only – additional servers will cost you a couple hundrad more shekels, but the overall agreement in terms of time remains in tact. People in Israel know that support cases happen once every few months, so paying an identical price for getting 2 incidents handled simply doesn’t make any sense in the Israeli Market.

TDM400 Compatible GSM Module

ASTERISK GSM MODULE

A new product on the market introduces a GSM module to the ever popular Digium TDM400P card. The new module, available at http://www.asteriskgsmmodule.com/index.html is a plug-in for the TDM400P card, allowing it to accept a GSM SIM card – instead of the standard FXO module.

Finally, a plug-in for Asterisk that negates the need to work with a GSM converter. The bad thing is that it requires a patch to the wctdm.c Zaptel driver, and aparently, isn’t yet available for DAHDI at all – but I guess this will be fixed in the short future. I surely hope that these guys will contact Digium and maybe introduce the driver into the main stream driver distro, after all, Digium doesn’t make GSM modules – so it’s no competing with any Digium product.

Sangoma recently introduced a new FXO product, the USBfxo. The USBfxo is a dual FXO port device, connected to your Asterisk server via a USB connection. Now, while I do admire the way Sangoma keeps trying to kick it up a notch with new products, but isn’t Sangoma a little late to jump on the USB train?

Sangoma USBfxo Device

Xorcom had been in this business for 4 years now and I see no reason why would the Sangoma product be any better than the Xorcom product. In addition, if Sangoma is targeting their product at the very low-end PBX systems, in my book, they actually missed the product line. In my view, if Sangoma wants to put a proper USB device on the market, it should have a minimum of 4 ports on it, 3 FXO and 1 FXS. You are probably wondering why I’m propsing such a weird combo, well, the reason is simple – Fax machines and they yet to be improved Asterisk FAX capabilities, and the fact that people still use FXS port of physical fax machines. I’m one of the biggest Asterisk and VoIP promoters I know, and even I use a physical fax machine at some points in time. True I used Hylafax and IAXmodem to receive most of my fax transmissions, but when it comes to sending faxes, nothing beats a physical machine.

So, as I started saying, Sorry Sangoma, too little, too late … better luck next time!

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.

Sangoma FlexBRI

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 …

I keep a vigilant eye on Google Alerts. To be more exact, I’ve got a few alerts defined, in accordance to subjects that interest me. Two of these subjects are Asterisk and FreeSwitch. Recently, the following had been posted on a personal blog:

Our PBX/IVR web-based generator Telfa has been moved from Asterisk to Freeswitch. Why?

Asterisk just seems to come from a different world than what I am used to. Inflexible and problematic. Very long configuration files with ancient syntax. Now I’m far from pretending I’ve used Asterisk enough to understand it pros and cons well, but I have a decent software development experience and I can tell when something “smells.” I didn’t want to build our system (that I want to be flexible and scale well) on some old technology that is only living from its past.

And (most importantly) there are many people experienced with both Asterisk and Freeswitch favoring the latter: Anders Brownworth, Jonathan Palley (creator of Telegraph, a Rails plug-in that lets you talk to Freeswitch), or of course the creator of Freeswitch (and former Asterisk developer!) Anthony Minessale himself.

[Extract from: http://onruby.flempo.com/2008/10/28/chose-freeswitch-over-asterisk/#comment-58]

Reading the above simply flames me UP – WHAT A LOAD OF BULL!

The writer admits that: “Now I’m far from pretending I’ve used Asterisk enough to understand it pros and cons well, but I have a decent software development experience and I can tell when something “smells.”” – If he’s such a worthy developer, the above simply proves that he’s simply an RTFM!

Asterisk provides a multitude of methodologies for configuration management, dialplan logic programming, programmatic API structures – basically, all the tools you need to go about and create your application. While I admit that FreeSwitch is slightly better at the “Core Switching” environment, implementing a near true Soft Switching architecture – Asterisk is a totally different thing.

A while back I decided to develop a couple of my better systems on FreeSwitch, as a test of my abilities. To see if I can be as proficient with FreeSwitch as I am with Asterisk. I re-developed the applications on FreeSwitch from scratch, however, FreeSwitch’s somewhat annoying XML configuration structures made it a hell for me to develop something that I would ask my customers to put their money on.

I started working with Asterisk in 2002, and starting 2003 I tried to have people in Israel start using Asterisk. I can honestly say that the first ever true adaptation of Asterisk in Israel came about only late 2005, and even that wasn’t for mission critical applications. Asterisk had achieved a point in which it is now considered a valid replacement for classic IN and NGN applications and engines, such as SigValue. I suspect that FreeSwitch will become a more dominant contender in that part within a period of 18 to 24 months, as its developer community will grow – time will tell.

In my large installations, I like using Asterisk as my IVR/Application engine envrionment and using FreeSwitch as my routing and LCR environment, simply because it’s capable of handling slightly more SIP-to-SIP connections than Asterisk – but that is the only reason, all the rest is Asterisk.

Both projects are wonderful tools, each one with its own set of strengths and weaknesses. Learn how to balance the use of the two, utilize the best of both world – and stop being a bloody purist, that’s exactly what leads to poor technologies such as Microsoft and poor life practices, like wars and terror.

We’ve recently learned that Fonality had forked FreePBX into its own version, to better serve the TrixBox community. Judging from what we’ve learned about Fonality/TrixBox/KG over the past few months, it is my personal belief that this is just another from of spin on the “TrixBox calls home” feature, simply doing something to hide it better – most probably will be somewhere in the management code now.

However, it led me to an interesting discussion with a friend – “will Fonality fork Asterisk?”

It is fairly clear that Fonality is doing all in its power to go about and distinguish itself from the rest of the community and the Asterisk eco system, by simply creating a product that is completely seperated from Asterisk. The amount of patches and modifications going into the TrixBox distribution, makes the running Asterisk on TrixBox a completely different one than the one running on AsteriskNOW, Elastix or pbx-in-a-flash. Is it stable? that is a good question, I’d like to believe that it is. After all, if it wouldn’t have been stable, Fonality would have been out of business. Fonality also goes to great deal to make sure that their TrixBox resellers can’t replicate their appliance easily. For example, over the course of the past 12 months, Fonality had changed the insides of their TrixBox appliance a few times, each time with a different motherboard, a different set of distribution packages and so on.

In the same fashion, it is only common sense for Fonality to fork Asterisk to their own product. My assumption is that Fonality at some point will either fork Asterisk, migrate their code to FreeSwitch or more probably CallWeaver, take over one of these projects like they took over TrixBox/AAH and completely distinguish themselves from the Asterisk community and product line. Will it do good for them? time will tell – if it happens. Will it be good for Asterisk/Digium? – in general terms that answer will be yes, as it will make Fonality/TrixBox automatically distinguishable from Asterisk. Which when asked what is the different between TrixBox and Asterisk, the immediate answer would be: “These are two completely different products!”.

It is my belief that by Q4 2010 we are to see some major shifts in the Open Source Telecom arena. My projection is that by Q4 2010 Digium will be in a position for either an IPO or an M&A. While my personal belief is that Digium prefers an IPO, an M&A proposition from a major vendor (Cisco/Nortel/Avaya) will come before the IPO option. I also believe that by the Q4 2010 Fonality will either fork Asterisk, adopt FreeSwitch or CallWeaver and distinguish themselves.

It is also my belief that by Q4 2010 Sangoma will try to acquire an Open Source PBX/Switch project. Although they recently acquired a SIP PBX company, I believe that this acquiry is nothing more than a small publicity stunt to keep Sangoma in the investor’s mind, making sure that Sangoma progresses in some form. The recent news about Sangoma integrating their signalling stacks to FreeSwitch makes me believe that the most likely candidate will be FreeSwitch – the Asterisk nemesis.

In any case, stay tuned for 2009… here we come…

As some of you noticed, I’ve started a “Say No To TrixBox” campaign. In order toPL go about and monitor the usage of the banner, and it’s deployment across the net, I’ve installed an OpenX ad server to support the campaign. I guess that I didn’t realize what the little campaign would do!

Current statistics show that the banner had been deployed to over 300 different websites across the world, had been viewed over 60,000 times and had been clicked on for about 800 times. Not a bad CTR ratio for a little community oriented campaign.

If you are an Asterisk user, and you are fed up with the way Fonality/TrixBox had been conducting their business over the past 3 years, it’s time to show your support and put this banner on your website. If you have a blog, a company website, an Asterisk oriented business, show your support to FreePBX and other Open Source Asterisk oriented projects and website by showing the world that the community has power.

I am all for competition, as a healthy competition always keeps us on our toes and makes sure we always progress and improve – but Fonality/TrixBox’s actions must be denounced and rejected.

There is nothing more annoying than the “me too” syndrome – the ever annoying human behavior of seeing something good and copying it – while doing a lousy job at it.

So, what am I ranting about this time? I’m ranting about the lousy job companies like Sangoma, Yeaster, Varion, PhonicEQ and other Digium would-be ‘clone’ companies are doing. Being the founder of the Israeli Asterisk community in Israel, I get man people come to me asking for Asterisk support and assistance. I render this support as much as I can (at least when I’m awake and next to my computer), to the best of my abilities, but I am always amazed at the crap people are willing to take – in the pursue of a lower price.

Let us take the Sangoma cards for example. If you were to ask me about 3-4 years ago, which card is superior, Digium or Sangoma, I have to  admit that I would most probably say that Sangoma was slightly superior back then. However, since the introduction of the TE?10P cards and TE?20P cards, Digium cards are superior in my book. Now, even in the old days, installing a card like Sangoma was a hassle. Patches and drivers and modules and services and a shit load of configurations that didn’t always work straight out of the box. Now, about 2 years ago, I completely abandoned Sangoma cards, due to a simple reason, they were no longer worth the hassle.

Now, a friend of mine got stuck tonight with a Sangoma board that didn’t work right, no matter what he did, the configuration didn’t work right. Now, the guy has over 2 years experience with Asterisk, hell, the guy wrote a rock-solid callback system, that is serving over 10,000 customers daily. Surely, he should be able to install a simple Sangoma card, shouldn’t he? well, imagine my surprise when he called me on the IM, saying: “I now understand why Sangoma suck! They have no idea how to program or work with Linux, their installation process is a mess!”.

So, Sangoma (and its similar) are faced with a problem: We manufacture cards, they’re actually quite good, but damn it, they’re not fully Zaptel compliant, so we need various patches to make them work – which means, that a normal, non-guru person will surely run into problems installing them. So, what do they do? simple, they turn to the users for the solutions, supporting various initiatives (mainly: TrixBox), and transfer the entire process of provisioning the card into the distro, making it seem automatic. Great, the user can install in 2 minutes and be up and running, but at the background, they hide much of the work that needs to be done, making it a fairly unmanageable system.

Why do I say that? simple, I had about a dozen TrixBox based customers with Sangoma Quad PRI boards, which I migrated to Digium TE410 cards, simply because the integration was much much much better.

Now, I have no problem with the “me too” syndrome when “me too” actually means: “me too, but I’m better”, this creates a proper sense of competition, which is always good for the market and the consumer. But when “me too” means: “me too, but not as good”, the market suffers and the consumer suffers and even worse.

Lets take an example of a good “me too”. A good “me too” would be the OpenVOX mini-pci initiative. None of the manufacturers are currently making mini-pci based Asterisk boards, while OpenVOX had initiated an interesting niche here. Having done some embedded development lately, mostly on WRAP and ALIX, the possibility of a 4 port FXO mini-pci, in my book, is perfect. As Digium currently doesn’t make anything like this, then OpenVOX is it. If Digium decides to push out a mini-pci line, I would test it, if it is as good as OpenVOX and integrates easily, then I’ll shift.

Most people in Israel know me as a pure Digium guy, which means that I always use Digium products. But when such products are none existent, I will use a product that covers my requirements, even if Digium doesn’t make it. However, if and when Digium comes out with a similar product, I’ll revert to that product immediately – mainly for the sake of compatibility, simplicity and most importantly, the supporting of the project and the company behind it.

As most of you already know, I’m heavily involved within the Asterisk Open PBX project. Over the course of the past 5 years of my dealing with Asterisk, Asterisk had always suffered a serious flaw, and that is, a single-threaded Manager interface – which usually led to serious dead-locks when writing a multi-threaded server that connects to it.

One of my long time challenges was to surpass the 4-5 originate requests to the Asterisk Manager interface, enabling me to automatically dial more than 4-5 calls at the same second. My initial work had began with the idea of increasing that by a factor of 50%, going up to around 7-8 calls per second – I had achieved that using a combination of smart synchronization between the manager interface and my originating server – and also enabling asynchronous originate requests – however, that methodology had proved to be problematic – in terms of reliability.

I understood that something else had to be devised, something that doesn’t rely completely on the manager interface, and that will allow me to originate calls freely, without clogging up the manager interface. So, I decided to move my interest from the Manager interface, and concentrate on understanding Asterisk’s channel handling, especially, how do calls originating from the manager interface are handled by the Asterisk spooler and the Asterisk channel drivers.

more will follow…