asterisk: do we need openh323?

[Tzafrir Cohen]

On Mon, May 16, 2011 at 01:43:26PM +0200, Kilian Krause wrote:
> Hi Tzafrir,
> 
> On Mon, 2011-05-16 at 12:27 +0300, Tzafrir Cohen wrote:
> > Historically Asterisk has had three different H.323 channel drivers:
> > 
> > chan_oh323:
> > The first one. Was never included in Asterisk, and eventually abandoned.
> > This was the package asterisk-oh323 which was eventually removed. It
> > used OpenH323. This message does not consider it at all.
> > 
> > chan_h323:
> > Included in Asterisk. Does build and link (once you tweak the Asterisk
> > build system badly enough). Uses OpenH323 as well. This one is basically
> > maintained. It was included in the separate package asterisk-h323 to
> > avoid the extra dependencies of the openh323 stack for most users (and
> > also past licensing issues?).
> > 
> > chan_ooh323:
> > At some point Digium was sick of the OpenH323 code and wanted a H.323
> > channel driver that does not use it. The result is this. It has its own
> > oddities. But then again: it does not depend on the beast. In the 1.4
> > it was completely broken. Later on someone ("may", Alexandr Anikin)
> > started fixing it.
> > 
> > At the moment it seems that chan_ooh323 is preffered by Upstream (that
> > is: it is the least broken of the two). Do we want to keep chan_h323?
> > 
> > If we do, do we want to keep support the current libopenh323? Or do we
> > move forward? Moving forward to H323plus or to Opal?
> 
> Is there plans to do so by its current upstream or are you trying to
> propose we'd be taking up to do that ourselves? I think if there is
> nobody stepping up with some patches and expressed will to keep
> maintaining them, we should not try to patch it into life and put the
> extra burden on the Debian Security team - who would in the long need to
> support it for stable Debian releases.

Yes, Upstream does not really maintain it.

See, e.g. https://reviewboard.asterisk.org/r/1117/
which basically ended with "I'm droping this work in favor of ooh323.
I'll propose killing off chan_h323 ?? and promoting chan_ooh323 now that
addons is included in the core source."

> 
> 
> > $ apt-cache rdepends libopenh323-1.18.0
> > libopenh323-1.18.0
> > Reverse Depends:
> >  |yate-openh323
> >  |simph323
> >  |libopenh323-dev
> >   libopenh323-dbg
> >   libopenh323-1.18.0-develop
> 
> All above (except) yate come from OpenH323 IIRC. Not sure how stable the
> OpenH323 support in YaTE is, but I guess asking Diana about moving
> forward to OPAL/H323+ won't hurt. If she's still subscribed to this list
> I guess we'll hear some news soon.
> 
> >  |asterisk-h323
> 
> In case nobody else is willing to maintain it, I would keep it as legacy
> for now and check if we can offer some migration path for those users
> actively using asterisk-oh323 to asterisk-h323. But only until someone
> can confirm it being converted to H323plus at least as OpenH323 itself
> is not as actively maintained AFAIK. Otherwise have it removed with
> proper notification of our users who are currently relying on a properly
> working H.323 stack.

Both H323plus and Opal have saner build systems than the original
OpenH323. The build system of OpenH323 is insane. If one of the above
two will make it possible to drop all the build odities (running 'make'
twice, odd link issues, and such), I would feel more comfortable with
it.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir