Two personal firewalls were tested on a Windows XP machine with a VCON Armada Escort 25 videoconferencing system installed. The remote machine (unrestricted by a firewall) was another VCON system installed on a Windows 2000 machine. The firewalls tested were the XP Built-in Firewall and the Cisco VPN Client's "Stateful Firewall". Hardware-based firewalls have a similar effect on videoconferencing, but the individual user has little control over their configuration.
Good news for home users: Chances are that your home DSL hardware has a firewall that kept you from using a personal endpoint like Polycom PVX. If you use UVa Anywhere you will be able to connect to a U.Va.-based videoconference endpoint.
The Windows XP Service Pack 2 firewall is more configurable than the original built-in firewall. As expected, an XP machine using the SP2 firewall without exceptions enabled cannot be contacted from another videoconference station. However, enabling an exception for the H.323 protocol (one of the setup options) still does not allow videoconferencing, no matter which site initiates the call. This is because the video signal coming into the firewalled computer is blocked and cannot be enabled. The problem is that incoming video and audio streams can use any of a large range of ports, and the firewall cannot be configured to use a range. To be fair, if the firewall did allow this huge range to be excepted, there would be little reason to have a firewall at all, since essentially most inbound traffic would be allowed. Therefore it is easiest to disable the XP SP2 firewall just before a videoconference session, and re-enable it afterwards.
Some Test Results
Notes: Either firewalled machine was able to register with the gatekeeper successfully. Connection behavior was the same whether a gatekeeper address or an IP address was used by the calling client.
| Firewall Type | Connection Direction | Behavior |
|---|---|---|
| Built-in XP | Open to Firewalled | Failure: One audible "ring" sounds on the firewalled machine, then the call fails -- the open client displays an "unreachable" message. |
| Firewalled to Open | Success: The call succeeds, with both the audio and video channel being passed between both machines. Even "hang up" works correctly. | |
| VPN Stateful | Open to Firewalled | 
Failure: The open
machine's client "rings" repeatedly, but the firewalled machine's
client never responds. |
| Firewalled to Open | 
Failure: Call setup
completes, but both audio and video from the open to the firewalled machine
fails, while audio and video from the firewalled to the open machine
succeeds. Each client must "hang up" the call independently.
"Blank" remote window on firewalled
client, 
but local signal is sent to other client. |
Conclusion: A firewalled machine cannot be "called" by another machine, though the failure signs vary.This was expected. A firewalled machine can call an unrestricted machine, but some firewalls will block the returning audio/video signals even if call set-up succeeds.
Collaboration through firewall
The T.120 (collaboration) applications have to be considered individually, and behave differently according to how they are implemented. The VCON MeetingPoint client allows T.120 applications to be handled either through NetMeeting or via processes built in to MeetingPoint. The built-in applications generally do not work when a firewall is involved. The NetMeeting applications mostly work, but see the chart below for specifics. Of course, if the audio/video portion of the videoconference doesn't work, the participants may not bother to worry about whether the T.120 applications work.
| Firewall Type | Connection Direction | NetMeeting T.120 | MeetingPoint T.120 | |||||
|---|---|---|---|---|---|---|---|---|
| Whiteboard | Chat | File Transfer | Shared Application | Whiteboard | File Transfer | Shared Application | ||
| Built-in XP | Open to Firewalled | YES | YES | YES | YES | NO | NO | NO |
| Firewalled to Open | NO | NO | YES | YES | NO | NO1 | NO1 | |
| VPN Stateful | Open to Firewalled | YES | YES | YES | YES | NO | NO | NO |
| Firewalled to Open | YES | NO2 | YES | YES | NO | YES3 | YES | |
1 A panel is displayed but the service eventually fails.
2Displays "Chatting with 0 others"
3 There is a bug if the specified "receive location" does
not exist.
Turning off the firewall
If you routinely run a personal firewall and realize that you forgot to turn it off before your videoconference began, you may be able to recover easily. If you run the VPN Stateful firewall you can shut it off from the VPN application without disturbing the videoconference. (Instructions are here.) If you run the XP built-in firewall, turning it off will cause the videoconference call to terminate.
Since the behavior of these two firewalls is so different, it demonstrates that a particular piece of software may implement services differently. If you run some other kind of personal firewall you may want to make a quick test to see what terminating it will do to an existing videoconference. If it behaves like the VPN firewall, then you can routinely shut it down when you see that it is affecting a videoconference, and then turn it back on afterwards. If it behaves like the built-in XP firewall you will need to remember to turn it off before the videoconference starts, which is more bothersome but still feasible.
A hardware firewall will show similar results, but an individual user will not have the option of turning it off to accommodate occasional videoconferencing. Machines that need to run videoconference software should not be placed behind a hardware firewall. There are commercial products known as "firewall traversal units" , but these are an expensive solution.
Why is this so complicated?
Some services, such as the web, use just one port for all network data. The H.323 protocol describes a service that uses many network ports. Moreover, both TCP and UDP ports are used. There are approximately 10 TCP ports and a couple of UDP large address ranges used in the protocol.
Many firewalls will allow incoming data to a port if it is returning in response to an outgoing request on that same port. If the incoming data is on a different port, this simple rule doesn't work. An H.323 outgoing data stream may occur on one port, and the corresponding incoming data stream will be on a different port. There are so many ports involved, and the ranges of addresses on the UDP (lower level) ports so extensive that manually opening all the ports on a firewall to allow general videoconferencing is tantamount to not having a firewall at all.