Re: [Openh323-devel] opalvoip vs h323plus

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

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 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 >>
Openh323-devel mailing list

[Open H.323]     [IETF SIP]     [Gnu Gatekeeper]     [Asterisk PBX]     [Fedora Linux]     [Gimp]     [Yosemite News]     [Yosemite Photos]     [Yosemite Campsites]     [ISDN Cause Codes]

Add to Google Powered by Linux