Peter

I certainly don't know what the fuss is about. Opal has already really good H.323 support but you cannot *make* people or *conjole* people to migrate. H.323 is a very low priority these days with a lot of projects and many projects may just want to continue their existing code base then h323plus will do that (aka Asterisk (chan_h323),GnuGk etc), others like you are indicating might want to migrate to opal to include SIP or they might just go off and get any one of the dozens and dozens of quality SIP stacks out there. There are others who are using their own SIP stack who just want to add a H.323 stack which might be opal or h323plus or even ooh323.

h323plus exists because there is a need of it, all the new work in h323plus is MPL 1.1 so you don't have to worry about licensing issues, want MPL ok, what GPL ok too, just go cherry pick what you want and leave whatever you don't, I'm not fussy. If you want a bit of support for it, then I'm willing to assist with direct enquiries. If you don't think any of it's relevent then forget it even exists and just use whatever you are using.

But saying I should do this and that.... Sure everyone wants SIP so go use openser or the dozens of other quality SIP stacks, if you also need H.323 support use Asterisk or FreeSwitch or YATE or this little great project called Opal. Opal is a tiny small fish in a huge ocean. How is me moving to Opal going to change anything except cut off H.323 support for some of the bigger open source projects which relied on OpenH323 for there support, sure they can move to opal but honestly they'll probably just let (like they have been doing) their H.323 support stagnate. Just as with Asterisk and GnuGK I'm happy in assisting updating existing codebases from openh323 to h323plus. Easy, we went though the process last week with both projects.

H323plus is meant to be project neutral (anyone can use it), it's a drop in replacement for openh323 and I still intend (where possible) to be highly compatible with opal so if your not ready to migrate then h323plus or cannot see a business case to do it, then it is there until you decide to (if ever) to migrate. You can pull out any of the new code and drop it straight into opal, I certainly will not be standing in anybodies way.

With respect to any other projects that may occur they will be the same format so they too will be a neutral stand alone project library which probably be more suited to the asterisk channel type model rather than the more integrated Opal model.

I really want to bring this whole discussion to an end. For the majority of people it has little relevence. For the rest, it is as it is. let's move on.

Simon

-----Original Message----- From: opalvoip-devel-bounces@lists.sourceforge.net [mailto:opalvoip-devel-bounces@lists.sourceforge.net]On Behalf Of Peter Nixon Sent: Saturday, 3 November 2007 11:13 PM To: opalvoip-devel@lists.sourceforge.net Cc: h323plus@lists.packetizer.com; GNU Gatekeeper Developer; Discussion on enhancements and development issues with the OpenH323 library Subject: Re: [Opalvoip-devel] [Openh323-devel] [h323plus] opalvoip vsh323plus

On Sat 03 Nov 2007, Peter Robinson wrote:

Hi All,

I've been a user of openh323/opal and on the mailings lists since very early on when gnomemeeting was in the early 0.x releases and have watched it all evolve, even contributing minor patches and testing on ocasion.

There are a number of things that disurb me about this whole "we've been orphaned" deal.

OPAL as it stands has been in development for years, it was essentially openh323 version 2. Just like gnomemeeting was renamed to ekiga to reflect the fact that it wasn't just aimed solely at gnome, openh323's name was changed to reflect the fact that it didn't just support h323, and as a result was essentially version 2. It was advertised as such for years.

Simon there is certainly currently more development of the SIP side of opal at the moment but I see that is the case for 2 reasons. firstly the H323 support was very stable and established, and secondly the people doing the H323 development was being done one openh323. The OPAL H323 side of things wouldn't stagnate as long as there's developers. And if you and everyone else were to develop on openh323 version 2 (OPAL) there wouldn't be missing features because you'd only have to do the work once. And the only reason the H323 features would stagnate is if the devs working on it and the maintainers of the H323 portion of the code (you and others) moved onto other things. That would give everyone better features on all three protocols currently supported... and any others that come along.

I'm sure if the opal project had remained named openh323 and called v2 with new apis when they added sip support and later renamed there wouldn't be this disparate uncessary separation and code divergence and H323 would get nice features like the latest codecs developed by craig, robert and co and SIP would get some of the great features you and others develop for openh323 with very little effort.

This community is too small for all the in fighting that I'm seen between all the various developers over the years. Way more than a lot of the other projects I follow,

I was just reading through this thread over my Saturday morning coffee and thought I should write a reply. Then I got this this email which very nicely sumarises almost everything I wanted to say.

I do have one thing to add however. I have known both Simon and Craig (and the gnugk and ekiga people) for several years now and have had the pleasure of being involved in some spirited face to face discussions over that time. I respect you all and consider you all friends.

Simon, with that caveat, I would like to say that I think it is a good thing for h323plus to exist given the state of the openh323 "project" but I heartily wish that its goal was more of a "maintenence mode" project than an actively developed alternative to OPAL. I have heard your reasons for continuing development on openh323/h323plus instead of OPAL several times before and I have to say that I was never fully convinced, however recent events have made me ever less sure.

Three months, I made the transition from owner of my own company, to a new position as RnD Director for a VoIP CPE vendor. This has given me a different perspective on things, given that I had always been involved in the "large" side of VoIP deployments where you have gigabytes of disk space and ram and a very different development environment, time to market requirements and market realities.

The fact is, despite incompatibilities, functionality gaps and all wisdom to the contrary, SIP is the current market standard for VoIP CPEs.

If I told my CEO that I wanted to build a H.323 only CPE he would tell me to reconsider, or reconsider my position at the company. On the other hand, if I can build a SIP device, then deliver H.323 functionality practically for "free" by using OPAL then I can build either an "advanced" model with both SIP and H.323 support (It would cost more due to the required flash and ram increase), or an alternate H.323 firmware for the "standard" device. This, as H.323 proponent, is good for you, and this is a major reason for me to pick OPAL as the stack to develop on, otherwise I would just as likely pick one of the many other very good open source SIP stacks available, and I would never even consider doing the work to develop completely independent H.323 support using h323plus.

Please spend a moment to consider "new" users like my company, and not only the temporary difficulties that some old users (like gnugk for example) would face porting from openh323 to opal. The VoIP industry is far from done, and as you know, there are new protocols coming out like AMS and others which I hope one day will also be available as part of OPAL also.

I think the decision to do new development in h323plus is a little short sighted, because it makes using your wonderfull new features (and I really mean that) difficult for new VoIP developers due to the hurdle of learning and using another library for H.323 in addition to whatever library they already use for SIP (Or IAX or AMS or whatever), and the even bigger hurdle of deciding to add H.323 support in the first place!

Consider also, what you will do when AMS is released.. You will at some point outgrow the existing openh323 design and API and be forced to refactor things at which point you will likely end up with something a lot like OPAL :-)

Please, consider doing your future h323 development on OPAL! I really believe that you will end up with a lot more people using your code (and H.323) in the long term.

--

Peter Nixon http://peternixon.net/

------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opalvoip-devel mailing list Opalvoip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opalvoip-devel