The rants and raves of a technogeek
Posts tagged digium
Say No To TrixBox Campaign – Update
Jun 23rd
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.
The unbearable manner of the “me too” syndrome
May 1st
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.
The world’s fastest Asterisk based Dialer
Mar 2nd
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…




Picasa
Twitter
Facebook
LinkedIn
Youtube
RSS