[Mac-telephony-list] Asterisk/OpenPBX on Mac vs. Linux

[Benjamin Kowarsch via List]

On Dec 22, 2006, at 11:30 PM, Tom Rymes via List wrote:

> I know that Asterisk is not 100% reliable, and I don't mean
> to imply that OpenPBX is less reliable than Asterisk.

But I meant to imply that opbx is at least as reliable as asterisk  
is. Not on OSX in particular but in general.


> However, OPBX is still a release candidate,

Funny you should say that.

It reminds me of a news feature I saw on BBC World News this week. A  
new hotel in Milan had assigned itself 7 stars where so far the  
consensus has been that 5 stars is the top score. The BBC then quoted  
a Swiss hotelier who said there was no internationally recognised  
system of hotel star rating and what is considered 7 stars in Milan  
might as well be equivalent to 3 stars in Lugano. In other words, the  
stars by themselves mean absolutely nothing outside of their local  
context.

The very same applies to software release numbering, especially with  
open source software. The criteria used by Digium how to determine  
whether or not a given snapshot of their SVN is to become a release  
number is very different from and entirely incompatible with and thus  
not at all comparable to the criteria used by the OpenPBX.org team.

OpenPBX.org could have done as Digium does and pick a snapshot deemed  
satisfactory for as long as it works on Linux and then call it a  
release. It would then be up to whoever takes it upon themselves to  
do the quality assurance for a given non-Linux platform. Unlike  
Digium though, the opbx project has an official cross-platform  
charter which means a full release is made when the targeted OS  
platforms have gone through a quality assurance process.

On some platforms (including Linux 2.6) opbx releases are as reliable  
as a full release would be.

It is rather silly to draw any conclusions from the numbering scheme  
when you consider that OpenPBX.org was forked from the Asterisk SVN  
in the same week that Digium took a snapshot from the very same  
source to release Asterisk 1.2. At that point you had one version of  
the code being called a release, and another which wasn't even  
considered a release candidate by a long shot. How anyone would draw  
any reliability comparisons from this is beyond me.


> and OPBX on Mac is certainly not ready for prime-time (the
> CLI doesn't work, for instance.) Even if that bug is fixed this
> afternoon, then I certainly wouldn't want to install a production
> server (especially for something so important as a business PBX!) on
> software that doesn't really have a reasonably well proven track
> record.

Asterisk's reliability track record is anything but impressive and  
thus you probably shouldn't be running asterisk in production either.  
The whole track record thing has a lot more to do with perception  
than anything else. Fair enough, but let's not pretend that  
perception is an objective decision making instrument.


> Perhaps the word I should have used is "Proven".

OK, but then again, just because you are unaware of the track record  
those who run opbx in production have established doesn't mean it  
doesn't exist.


>>> 3.) Unicall not yet complete, so no PCI cards
>>
>> It's not the Unicall part which is missing. It's the drivers.
>
> My point is that PCI cards don't work yet. Again, a major drawback
> IMHO. Once Unical and all of the drivers, etc are working, then I
> expect it will be superior to Zaptel, but until then, it's still non-
> functional and not ready for any of my production servers.

I was merely trying to explain the nature of Unicall, in particular  
the fact that Unicall != drivers.

It is correct to say that the full potential of Unicall will only be  
realised when more driver software is made to hook into it.

However, it is incorrect to say such things as "once Unicall  
works ..." because it creates the impression that Unicall was not  
ready yet. Not only would this be wrong, but it is also  
counterproductive. If vendors and driver developers are led to  
believe that Unicall is not ready, they are less likely to make the  
effort to hook their drivers up.

Also note that this is a chicken-and-egg situation. With Zaptel,  
vendors have little incentive to write drivers for other platforms,  
including OSX because Zaptel is at the very best problematic on non- 
Linux platforms (Note, I am being extremely diplomatic here).

Once you have drivers hooked up to a cross-platform HAL framework  
like Unicall, there is a strong incentive for vendors to deliver  
drivers for other platforms.

Promoting and proliferating Unicall is therefore in our best interest  
(as Mac users).

rgds
benjk