The number one requirement of all of my customers has been  
connectivity to the PSTN. VoIP is no more than icing on the cake, at  
least as far as PBXes go. Consequently, for me, VoIP has to fit into  
what's there today. I cannot make a living on selling future dreams  
of a world in which there is nothing but a single VoIP model, which  
is very unlikely to happen anyway.

I don't want to deal with the all too common ISDN is different from  
POTS is different from Foo is different from Bar is different from  
Baz. If you call out using X you can't use Y, if you call out Z you  
don't get response codes E, F, and G. If you bridge V and W you have  
to introduce your own E', F' and G' klugdes because V and W don't  
have E, F and G in common. These are precisely the problems Unicall  
is addressing and I don't see anybody else working on a unified call  
model.

A unified call model is the only thing that prevents the cruft we are  
all trying to get away from.

In any event, there are good reasons for revolution and there are  
good reasons for evolution. It isn't as clear cut as you try to make  
it look. Just because Tony decided one approach over the other,  
doesn't mean that everybody else has to pick the same approach. Both  
approaches have their place. Both have their advantages and  
disadvantages.

Besides, Unicall may not be the only library of interest which is  
incompatible with Freeswitch license terms.

There is a clear need for a project that is neither encumbered by  
Digium's nor by Tony's licensing policy. The inability to use  
libraries that are GPL only, such as Unicall, is a serious  
disadvantage and OpenPBX should stay away from incorporating  
Freeswitch on these grounds alone. People for whom this isn't a  
concern can use Freeswitch. People for whom GPL libraries are  
important should be able to have an alternative. If OpenPBX isn't  
going to be that alternative anymore, then there will likely be yet  
another fork of the Asterisk code base at some point.

As for a possible future direction of OpenPBX, I had a brief  
discussion with Nathan a while ago in which we both concluded that  
embedded devices are more future proof than running PBX software on a  
PC and that there probably should be some work towards an embedded  
OpenPBX, along the lines of AstLinux.

rgds
benjk


On Aug 6, 2006, at 3:11 PM, Daniel Swarbrick wrote:

> bkml wrote:
>> had qualities. Whilst this was a lot of rhetoric on his part, I fully
>> subscribe to the view that old means more mature and that new means
>> inexperienced and prone to risks and fallacies. Perhaps, there should
>> be more appreciation for slower pace, less bleeding edge and more
>> maturity.
>
> There's a difference between mature code and abandoned code. I'm not
> suggesting we use bleeding edge, but to the uninitiated, the OpenPBX
> project looks pretty dead - wiki is out of date, mailing lists are all
> but dead, Trac is overrun with spam, #openpbx occasionally sees some
> tumbleweed rolling by. One could be forgiven for thinking that OpenPBX
> is no longer being actively maintained by anybody.
>
>> The trouble I have with the way the Asterisk folks are fixing bugs is
>> that I have quite often seen a bugfix break something else. Not my
>> idea of bug fixing. It's often a matter of the devil you know versus
>> the devil you don't.
>
> Adding bugs while you fix bugs happens in most software  
> development. As
> long as you fix the bugs you add, and the overall direction is  
> forwards,
> isn't this how software evolves? Isn't that why it's called
> "development"? Look at the bugs that get introduced into the Linux
> kernel as it evolves. Next release, those bugs are fixed, some new
> features (and maybe some new bugs) are added. As much as Asterisk  
> might
> be adding new bugs, they're fixing old bugs... and at least code is
> being written, whether it be bugfixes or new code.
>
> If we didn't dare write new code for fear of introducing new bugs,  
> then
> I guess COBOL and FORTRAN programmers would still be in high demand.
>
>> I have recently been doing quite a bit of work on channels and ISDN
>> integration and the more insight I gained, the more apparent it
>> became to me that nothing quite matters as much as the Unicall
>> concept to make all interfaces look exactly the same to the telephony
>> engine and translate or simulate capabilities into a coherent unified
>> virtual interface layer.
>
> Sounds great. But can you convince others to share that opinion, or is
> this a one-man crusade?
>
>> The value of Unicall cannot be overemphasized. It is far more
>> important than whatever Freeswitchers are raving about. Without
>> something like Unicall, Freeswitch is going to ultimately run into
>> the same trouble Asterisk has.
>
> Hopefully some Freeswitchers are reading this list then, and give some
> thought to that advice.
>
>> Freeswitch has its place, but OpenPBX also has its place. With all
>> due respect, I don't think there should be any lets not do OpenPBX
>> any further, lets merge it into Freeswitch talk on this list.
>
> My point was that right from day one, there was an alternate plan for
> OpenPBX to use an alternate core. I didn't suggest merging with
> FreeSWITCH. I suggested FreeSWITCH as a possible alternate core,  
> and the
> development of modules to wrap around FreeSWITCH - essentially,  
> OpenPBX
> VoIP applications sitting on the FreeSWITCH "OS".
>
>> You can always replace the rusty pieces with stainless steel, one
>> piece at a time. If you have the tools to do it yourself, then this
>> will keep you from having to spend the money on a new car, while you
>> can still drive the old one as you are gradually rebuilding it.
>
> Rebuilding the Asterisk core piece by piece could take years  
> (especially
> if the number of OpenPBX developers continues to dwindle), and don't
> forget that Anthony considered (or even tried) doing that. He came to
> the conclusion that it was just too broken to be fixed, and that it  
> was
> easier to start from scratch. So, while you rebuild your car one piece
> at a time, five years later when you've finally finished it, you might
> find that you can no longer buy gasoline to run it on. That could  
> result
> in a lot of hair tearing-out.
>
> In the meantime, the VoIP market is exploding, and people don't  
> want to
> wait that long. You might have all the time you want if this was a
> university research project, but in the business world, customers want
> solutions on a deadline. If one option can't provide that solution,
> they'll simply choose another one, even if it might cost more  
> money. The
> cost of downtime may be more than the initial outlay of a different  
> system.
>
>> I personally would love to see LESS features and a more generic and
>> universal call model instead. Some other people will want to see lots
>> and lots more features. Yet more reason to have several different and
>> distinct projects to accommodate different views.
>
> Less features is exactly what FreeSWITCH is doing. They don't want  
> to be
> a PBX - they just want to be a softswitch. Inevitably, PBX modules  
> will
> be written by the community to run on top of FreeSWITCH, but that
> doesn't make those modules a part of FreeSWITCH, just like Apache  
> is not
> part of the Linux kernel.
>
> A stable ABI is one of the goals of the FreeSWITCH core, which also
> makes it attractive for commercial developers to write closed source
> modules that sit on top.
>
> Considering this scenario: you buy a Cisco 2800 series router for your
> VoIP to PSTN connectivity, and you run phones directly from that  
> router.
> You have basic IVR, and you can add voicemail by adding an AIM module.
> Or you buy a dirt-cheap Linksys SPA9000 with voicemail on a USB key  
> and
> run your office from that.
>
> Cheap VoIP "black boxes" are appearing on the market very fast, and  
> some
> of them are cheaper than the cost of a PC to run Asterisk / OpenPBX /
> FreeSWITCH. The only way that open source VoIP can stay ahead of these
> cheap commercial offerings is to out-innovate them, which is hard  
> to do
> if you're still changing the head gasket on your reconditioned engine.
>
> _______________________________________________
> Openpbx-dev mailing list
> [email protected]
> http://lists.openpbx.org/mailman/listinfo/openpbx-dev


                
___________________________________________________________ 
The all-new Yahoo! Mail goes wherever you go - free your email address from 
your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html
_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev

Reply via email to