Re: [h323plus] [Openh323-devel] opalvoip vs h323plus
Robert
I hate to be blunt but I would like to point out a few facts.
The decision to fork Opal to OpalVoIP was purely yours and craigs. Nobody forced you to make the fork and you guys did it very much with your eyes wide open. You knew very well what new work I was doing in openH323 as well as the numerous projects such as Asterisk,Yate,GnuGk, PacPhone etc rely on OpenH323 for their H.323 support and that support would be disrupted if not lost with the abrupt move to OpalVoIP. There was a flurry of "concerned" private emails on the topic and was actively discussed on the days leading up to your public announcement.
The decision to start h323plus was made in part in response to your decision and to ensure continuation of support for these "orphaned" projects and also to ensure the new work I was doing in OpenH323 saw the light of day. It became impossible to do in openh323, although I had made several public gestures to taking over the OpenH323 project, I never received any response from anybody on the topic so I was forced to take the action I did.
Facts remain there has been little new H.323 work in Opal aside from the video plugin work with majority of that focus been on the SIP side which is completely understandable as this has been your prime focus. For instance, the new H.264 and MPEG4 codecs in the Opal repository didn't even have H.323 support. (Well not completely true, I'm testing H.264 code and will get to the MPEG4 shortly)
To be honest, the H.323 support in Opal is currently at the level of about openH323 v1.18 meanwhile over the last 12 months I have been diligently adding H.230,H.239,H.249,H.341,H.350,H.460.x etc to the openH323 plugins branch (abit with Roberts paid (from somebody) support for the video plugins :) ) with the an aim to have that work ported to Opal when you guys were ready, nobody has EVER contacted me on doing this to date (aside from Hannes) and the offer is still there and I certainly welcome you to do so. Nothing at all changes that. As you are aware I still commit changes to ptlib and the opal plugins in OpalVoIP SVN and you are very much welcomed to take any of the new H323plus work and add it to OpalVoIP.
I don't understand, Although the desire to make a smaller ASN.1 footprint is a completely fantastic idea but why do you want to effectively exclude such a large number of projects which currently rely on OpenH323 (now h323plus) or basically force these projects to recode to Opal. In many respects there is no compelling business case (or benefit) for these projects to move to Opal but more importantly, politics may be the deciding factor as unlike openH323, Opal may be seen as a competitor especially on the SIP side and with the current demand for H.323 very low they might just abandon any new H.323 work altogether. This is my greatest fear.
The purpose of h323plus is to continue on from your (and craig's) fantastic work on OpenH323 and the unique neutral place OpenH323 had in the marketplace and develop it further with app sharing, conference controls etc,(hence the + in h323plus) and make that available to the widest audience possible, continuing the history of being the one really good advanced open source H.323 stack which everyone has relied on for so many years.
Simon
-----Original Message----- From: openh323-devel-bounces@lists.sourceforge.net [mailto:openh323-devel-bounces@lists.sourceforge.net]On Behalf Of Robert Jongbloed Sent: Saturday, 3 November 2007 11:33 AM To: 'Discussion on enhancements and development issues with the OpenH323 library'; h323plus@lists.packetizer.com; Opalvoip-devel@lists.sourceforge.net Subject: Re: [Openh323-devel] opalvoip vs h323plus
Sigh, I know I should not do this but ....
-----Original Message----- From: openh323-devel-bounces@lists.sourceforge.net [mailto:openh323- devel-bounces@lists.sourceforge.net] On Behalf Of Simon Horne Sent: Sunday, 28 October 2007 3:19 PM
...
There are dozens of very popular open source stacks like asterisk and Yate that rely on openH323 for their H.323 support. With the migration to Opal this support is hampered as openH323 was seen as a component where as OpalVoIP may be viewed a little differently. My greatest fear is that H.323 support in these projects would stagnate or be dropped entirely which would be a major loss. Hence the maintaining of that support in H323plus.
And this is my greatest fear as well. Unfortunately when the primary champions of the H.323 protocol decide NOT to use the OPAL environment, they are going a long way to ensuring that this WILL be the case.
H323plus has a completely different focus to that of OpalVoIP and is designed to undertake advanced H.323 development (hence the plus) and unleach the full potential of what H.323 is capable of where are OpalVoIP is more of a generalist which to date has focused a lot of their attention (of late) on SIP.
True, because much as I hate SIP as a protocol, we can't ignore it. Many consumers of OpenH323 (YATE, Asterisk, etc) have SIP as well, they just use someone else's stack.
Now saying that, it does not mean the work in H323plus cannot be ported across to OpalVoIP or visa versa. Case in point the Video Plugins from Opal (which Robert did a lot of work on) and the plan to port the app sharing H.239 to Opal (which I authored). The H323plus stack is built off ptlib and uses the same audio/video plugins which I still actively assist in maintaining.
Yes, but as time goes on and the stacks continue to diverge, this gets harder and harder.
For example, one idea Craig and I have toyed with is changing the ASN.1 PER system to use the iii compiler. This reduces the code footprint by a staggering amount. Literally an order of magnitude, a 3 megabyte executable being reduced to less than 300 kilobytes. This involves changing (in a semi-automatic way) thousands of lines of code. However, once that is done any porting between the two is ten times harder as diff's can no longer be used on files that used to be 95% identical.
We don't know if we would do this or not, but maintaining the ability to port between OpenH323 and OPAL becomes a factor against in the decision making process.
The real question is not which is better but which better suits your needs. If you are starting a new project and need to support SIP with quality H.323 support then use OpalVoIP. If you have an existing project or don't require SIP but need advanced H.323 features such as app sharing, HD Video, conference controls, LDAP, SNMP then you should consider H323plus.
And therein lies the problem. What if someone wants both? They shouldn't need to choose. There is really no technical reason for it.
If you use OPAL and just use H.323 (i.e. only create an H323EndPoint and not a SIPEndPoint), that should be IDENTICAL to using OpenH323. Once upon a time it was!
The "generalist"/"specialist" argument not a good one IMHO. OPAL is a LIBRARY, as with any library you use as much or as little as you need and ignore the rest.
....
I certainly wish them all the best. However the move does have its downside as projects such as GnuGk, YATE, Asterisk are forced to migrate their H.323 support or let it stagnate (which is my greatest fear) which was the prime motivating force for h323plus.
As I said before, if you were working on OPAL, then the H.323 within it would never stagnate.
It is to my everlasting regret that I never could get around to producing a "porting guide" from OpenH323 to OPAL. A nice, detailed recipe on the API changes that need to be tweaked. There are already examples of dual mode applications in the contrib directory now and not THAT much changes. If I had managed to produce such a document then I do not think this would have been an issue.
I say this because I believe the REAL reason applications such as GnuGk etc have not moved to OPAL is that the authors did not know, nor want to expend valuable time figuring out, how to change their applications to use the new API. I do not blame these people in the slightest for that decision. The fault is mine in not producing sufficient information to make it easy.
However, that fundamental mistake several year ago has caused a juggernaut to move on. It is probably now impossible for OPAL to ever have the same functionality as OpenH323 as the likelihood of us having time to port the code is small (we need to earn a living), and the likelihood of someone paying for it is even smaller. I know if I was an application writer with requirements for H.323 with the extras and needed SIP too, I would be using OpenH323 and some other SIP stack such as oSIP/Vocal/reSIProcate etc.
So, I believe the divergence will continue and this makes me profoundly sad.
Robert Jongbloed OPAL/OpenH323 Architect and Co-founder.
------------------------------------------------------------------------- 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/ _______________________________________________ Openh323-devel mailing list Openh323-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openh323-devel
Simon Horne wrote:
Robert
I hate to be blunt but I would like to point out a few facts.
The decision to fork Opal to OpalVoIP was purely yours and craigs. Nobody forced you to make the fork and you guys did it very much with your eyes wide open.
You are correct that the decision was mine and Robert's. It was not a trivial decision - it's something that I have agonised over personally for many years - but I felt the time had come that it had to happen.
Everyone has been very supportive about the shift, and I hope you agree that it was the right thing to do.
You knew very well what new work I was doing in openH323 as well as the numerous projects such as Asterisk,Yate,GnuGk, PacPhone etc rely on OpenH323 for their H.323 support and that support would be disrupted if not lost with the abrupt move to OpalVoIP. There was a flurry of "concerned" private emails on the topic and was actively discussed on the days leading up to your public announcement.
The decision to start h323plus was made in part in response to your decision and to ensure continuation of support for these "orphaned" projects and also to ensure the new work I was doing in OpenH323 saw the light of day. It became impossible to do in openh323, although I had made several public gestures to taking over the OpenH323 project, I never received any response from anybody on the topic so I was forced to take the action I did.
You've always had the public support of myself and Robert for your work on OpenH323. In fact, if it was not for your support then the decision to move Opal to a new site would have been much harder for the very reasons you describe.
Facts remain there has been little new H.323 work in Opal aside from the video plugin work with majority of that focus been on the SIP side which is completely understandable as this has been your prime focus. For instance, the new H.264 and MPEG4 codecs in the Opal repository didn't even have H.323 support. (Well not completely true, I'm testing H.264 code and will get to the MPEG4 shortly)
Much of the work in OPAL has been in the shared code-base, so it is common to both H.323 and SIP. For example, Hannes has done some amazing work on allowing multiple video streams in a single call, which he has running on H.323. We're looking forward to getting this code into the mainstream release.
To be honest, the H.323 support in Opal is currently at the level of about openH323 v1.18 meanwhile over the last 12 months I have been diligently adding H.230,H.239,H.249,H.341,H.350,H.460.x etc to the openH323 plugins branch (abit with Roberts paid (from somebody) support for the video plugins :) ) with the an aim to have that work ported to Opal when you guys were ready, nobody has EVER contacted me on doing this to date (aside from Hannes) and the offer is still there and I certainly welcome you to do so.
From my point of view, the main reason why we never got around to doing this was that I always sort of considered the new H.450.x etc code as still in development, because it was never moved to CVS head.
But, if you are saying it is all ready to go, then let's get moving!!
Nothing at all changes that. As you are aware I still commit changes to ptlib and the opal plugins in OpalVoIP SVN and you are very much welcomed to take any of the new H323plus work and add it to OpalVoIP.
It's something we've always intended to do. This was one of driving forces behind moving Opal to a new site.
I don't understand, Although the desire to make a smaller ASN.1 footprint is a completely fantastic idea but why do you want to effectively exclude such a large number of projects which currently rely on OpenH323 (now h323plus) or basically force these projects to recode to Opal. In many respects there is no compelling business case (or benefit) for these projects to move to Opal but more importantly, politics may be the deciding factor as unlike openH323, Opal may be seen as a competitor especially on the SIP side and with the current demand for H.323 very low they might just abandon any new H.323 work altogether. This is my greatest fear.
We have not done the ASN.1 changes in Opal or OpenH323 to date for the very reason that it would cause problems for these existing projects. I'd really like to start a discussion on how we can get the advantages of the new ASN while minimising the impact for developers.
H.323 is still active developed within OPAL and is a crucial part of the project. I do not consider it any way secondary or subvservient to the SIP component.
Whilst we are on this subject: if a project was to convert to OPAL and the new ASN would it be better to do it in one big step, or two smaller ones?
The purpose of h323plus is to continue on from your (and craig's) fantastic work on OpenH323 and the unique neutral place OpenH323 had in the marketplace and develop it further with app sharing, conference controls etc,(hence the + in h323plus) and make that available to the widest audience possible, continuing the history of being the one really good advanced open source H.323 stack which everyone has relied on for so many years.
I completely understand your decision to create h323plus, and I agree that it is the best way to continue to support projects that rely on OpenH323.
It is my fervent wish to provide a migration path for those projects to move to OPAL so that they can benefit from the architectural improvements in OPAL, as well as providing the ability to include other protocols such as SIP, if they so wish.
I'd also like to avoid splitting the effort of the maintainers such yourself and us because, as you understand, it is a *lot* of effort and such duplication could be wasteful.
Craig
----------------------------------------------------------------------- Craig Southeren Post Increment – VoIP Consulting and Software craigs@postincrement.com.au www.postincrement.com.au
Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren@hotmail.com Mobile: +61 417231046 Jabber: craigs@jabber.org
"Science is the poetry of reality." Richard Dawkins
participants (2)
-
Craig Southeren -
Simon Horne