I am seriously trying not to reinvent the wheel here, but.....
Recently, I volunteered (always a bad thing) to help set up a dedicated, inhouse (maybe add on extern later) video conferencing system based on pc's runing winblows with webcams, some Tandberg IP video phones and some PC's with big plasmas on the wall in a listen-in mode on conference 0. Since no more than 4 displayed users should be required at any given time, I looked at OpenMCU, which should do this out of the box.

The system will be operated by lusers and since I try to design everything with the assumption that I may be hit by a bus tomorrow and some other poor slob will have to support this later, I have to make some design decisions and direction now.

I always prefer load time linked modules, but most of the telephony stuff out there is recommending optnoshare to statically link in modules and do a total rebuild when adding new features. This idea blows chunks, but if it must be, it must be.

Reading extensively, on the PWlib vs. PTlib trees has me baffled, as the PTlib tree claims to be the inheritor of PWlib, yet Ekiga uses Opal (PWlib) and furnishes h.264, whereas the PTlib does not.

I move on the h.323 handling. Openh323 vs. H323plus. Again, which is the main trunk for the tree? The H323plus seems to have standards based signaling (H.460) not contained in Openh323, but does not include many of the codecs that are furnished by Openh323.

Moving on to GnuGK: Recommended pairing libraries of PWlib+Openh323 OR PTlib+H323plus. ARGHHH!!!! The first paring would seem to give the widest codec compatibility among dissimilar clients, but the second would seem to be more compliant with signaling.

I could probably set it up without a gatekeeper, but it would make the Tandberg units simpler to set up and manage with a gatekeeper and/or gateway (remember, I might be hit by a bus tomorrow) A gatekeeper would also simplify future expansion to external clients, should the need arise and I may have already been hit by that bus at that time.

If I can get all this working well, I also plan to pile Asterisk on top of it so a closet full of Cisco phones from a previous experiment with IP Telephony can be put back in use. I know it has issues with h323, so the systems will probably remain independent until Asterisk passes video to gatekeepers.

A smart man learns from his mistakes. A brilliant one learns from others mistakes. It is my feeling that I can't be the first person to tread this road.

I am running CentOS 5 on the equipment, so yum repositories are preferred, if I can do that without breaking the setup and I can leave documentation along with my last will and testament.

So, who out there has a smile on there face from having "been there, done that, got the t-shirt"?

Stick to H323Plus and PTLib. OpenH323Plus/PWLib is outdated.

In my experience OpenMCU won't work well enough for video to be useful.

The gnugk.org website lists combinations of libraries that work together well:
http://www.gnugk.org/compiling-gnugk.html

1 members found this post helpful.

THANKS! This is what I understood, but it was a bit confusing. What seemed to be the use issue with OpenMCU? I was looking at it so that I could provide a "Brady Bunch" view of the conference. It is my understanding that GnuGK does not provide multconferencing. I hope I am wrong. I haven't dug this deep into Linux configuration since the time I put it on an old Sparc 2 that had a video (ecl ) that identified as a common bw5. Thar drove me and the developer nuts for a while. I did manage to kludge up the driver to work and sent the patches back to the developer. It was not a common video sold by Sun, but Solaris understood it out of the box.

I can get my hands dirty to make this work, but if I have to do that, I'll have to make sure the solution is generic enough to make it mainstream in the development channel. I always worry about that bus. Again, thanks for pointing me down a path.

BTW: Somebody upstairs doesn't want me working on this today. The power is out on half the street and I am relegated to my phone for research until they get it fixed. I do hope soon, 100+F expected today.
I will post my detailed results as the project progresses. If I can get external set up correctly on a test box, maybe some of the folks here would be willing to beat on it with various clients. I am used to working across time zones, so that wont bug me.