Video Conferencing woes…
- Date: October 31st, 2005
- Author: Justin Fielding
- Category: H.323, video conferencing
- Tags:
I have been experiencing some problems with our Video Conferencing
(VC) equipment. Making calls from unit to unit within the organisation is no
problem–our sites are all inter-linked by IPSec tunnels so all traffic is
internal. The problem arises when trying to make a call from one site to
another, via external IP addresses. The call is made on unit A, and unit B
rings. When the call is picked up on unit B, the session is not created, no
audio/video link is created, and unit A does not recognise that the call has
been accepted. I looked into my firewall configuration, and I had allowed all
of the port ranges mentioned in the manuals. I also redirected those ports to
the conferencing unit so that incoming attempts would be delivered directly.
This all seemed ok, so I also checked the firewall logs while
attempting to make a call; nothing was being blocked. While this wouldn’t have
been a problem 3 weeks ago (because all of the VC traffic was internal), people
now want to receive VC calls from external companies. Doh!
After a lot of googling and reading mailing list archives, I
found references to issues with the H.323 set of protocols and firewalls. It
seems this is also the protocol set used by Microsoft Netmeeting, so there was
quite a bit of information on the subject. I checked the manuals of our VC
units and, sure enough, they do use H.323–great :/ There is a sliver lining; as I mentioned
before, this is a very popular standard. It actually means that VC systems made
by different manufacturers can still speak to each other. I called one of our
Sony units from Netmeeting on my laptop and it worked quite well (type conf.exe
in your ‘Run’ box).
A bit more googling and I found two open source solutions;
both are basically proxies which sit between both end points and deal with
incoming / outgoing connectivity. OpenGatekeeper H.323 Proxy is
one of these, NMproxy is
the other. Because of it’s simplicity and BSD compatibility, I have chosen to
take a closer look at nmproxy.
I don’t want to modify our existing gateway/firewall
machines with un-tested software, so I’ll create a lab environment using VMware Workstation as I mentioned in my
previous blog.
The Plan:
Set up a test environment to emulate a Video Conference call
between two firewalled networks.
- Build
two firewalls (OpenBSD) - Compile
and configure nmproxy - Build
two internal clients (Windows XP) - Netmeeting
+ Webcams (one on each client) can be used for testing the H.323 proxy
Thanks to the ‘clone’ feature on VMware, I don’t actually
need to build 4 separate machines from scratch. I’ll install OpenBSD (to show
people how simple this OS is to install and configure), compile nmproxy, then
clone it to create a replica and simply edit the machine configuration (IP
details, hostname etc). As I use VMware frequently for testing, I already have
a ‘virgin’ Windows XP image ready to use/clone; I assume everyone reading knows
how to install Windows.
I know this may sound a bit drawn out, but if you want to be
serious about security then you need to test new configurations in a secure
environment, not just give it a go on live systems and hope for the best!
Tune in again on Wednesday and we’ll install OpenBSD…

