Re: [Openh323-devel] opalvoip vs h323plus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxx
[mailto:openh323-devel-bounces@xxxxxxxxxxxxxxxxxxxxx]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@xxxxxxxxxxxxxxxxxxxx;
Opalvoip-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Openh323-devel] opalvoip vs h323plus


Sigh, I know I should not do this but ....


> -----Original Message-----
> From: openh323-devel-bounces@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323-
> devel-bounces@xxxxxxxxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openh323-devel


-------------------------------------------------------------------------
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openh323-devel

[Index of Archives]     [IETF SIP]     [Gnu Gatekeeper]     [Asterisk PBX]     [Asterisk SS7]     [Fedora Linux]     [Gimp]     [Yosemite News]     [Yosemite Campsites]     [ISDN Cause Codes]

  Powered by Linux