Enabling secure video conferencing is an ongoing challenge that stems from an inherent design difference between...
video conferencing and firewalls. Firewalls are designed to be asymmetric, trusting traffic initiated on the inside and not trusting traffic initiated on the outside. Video conferencing must open connections from inside and outside to establish a call and thus is very symmetric.
A common symptom that indicates a firewall problem is that one user can see and hear the other user, while the second user sees only a blank screen. This is usually the firewall blocking the video and audio inbound from the Internet.
So how can we enable secure video conferencing and allow video conferencing to easily traverse the firewall without compromising the security that the firewall provides? Here are a number of approaches in use today -- and their limitations.
Direct Internet connection
Clearly, one approach to secure video conferencing is to connect video conferencing systems directly to the Internet and thus avoid the firewall issue. An appliance-based video endpoint in a small office may be directly connected to the Internet. A road warrior with video capability on a laptop may also connect directly to the Internet, although in many cases this user will actually be connected through a fairly open firewall at a Wi-Fi hotspot or in a hotel.
A video endpoint connected to the DMZ of a firewall can have all external traffic passed directly to it. This is a common configuration in a small (or home) office where there are no other DMZ servers and is how my H.323 video endpoint is connected. The firewall redirects any incoming traffic that was not initiated internally to the video conferencing endpoint, so it behaves as if it were directly connected to the Internet.
Through the firewall
A video endpoint can be connected through a firewall if there is a dedicated static Internet address available for the video unit. The firewall is configured to do NAT translation between the dedicated video Internet address and the actual internal IP address of the video endpoint. Any traffic coming to that specific address is then forwarded to that specific video conferencing endpoint.
While using this method to secure video conferencing works very well, it is difficult to support in environments where addresses change often, where video conferencing systems move, or where a large number of video endpoints may be located in the same facility. The NAT configuration of the firewall is a manual process and subject to error. Lastly, it may be expensive to purchase and maintain a large number of dedicated Internet addresses for this purpose.
A traversal server is a separate server connected directly to the Internet or sometimes to the firewall DMZ, specifically designed to support H.323-based video conferencing firewall traversal. Video endpoints inside the enterprise tunnel through the firewall using the H.460 protocol and connect to the traversal server.
If endpoints do not directly support the H.460 protocol, a proxy device can be implemented in the enterprise network that acts as a gateway between the video endpoints and the external traversal server.
Video endpoints on the Internet can connect directly to the traversal server and then select an internal video endpoint using an E.164 extension. Cooperating enterprises can neighbor their traversal servers and share a dialing plan to further simplify video calling. This is the approach used by the Tandberg Expressway product.
Traversal servers work well for enterprises with small offices, as only one traversal server needs to be employed. Note that all Internet-based video will pass through this one server, so the server can become limited by the volume of the traffic.
Session border controller
A session border controller (SBC) is a device that sits between two networks (in this case the enterprise network and the Internet) and provides passage for only well-qualified traffic streams (in this case, video conferencing). An SBC has two network connections: One connects to the enterprise network; the other, to the Internet (or firewall DMZ).
The SBC is involved in the video conferencing signaling setup, and it uses this information to determine which specific audio and video streams are "qualified" and should be allowed to pass the firewall.
The SBC, like the traversal server, must carry all the video traffic crossing that boundary. But because the SBC is specific to an enterprise network boundary, it is easier to scale for large video conferencing deployments. Conversely, it is not as good a solution for many small offices because each small office would be required to have its own SBC device.
The simple solutions for enabling secure video conferencing provided at the beginning of this article are tempting for small companies or those who are just getting into video conferencing, but the later solutions provide much better scaling and will simplify the user dialing requirements. I encourage enterprises that want to use Internet-based video to dig into the details and determine which solution works best for their specific situation.
About the author:
John Bartlett is a principal consultant at NetForecast. He is a leading authority on real-time traffic, Internet performance and Quality of Service (QoS) techniques. NetForecast specializes in network-based application performance issues for transaction-based and real-time applications.
John has 28 years of experience in the semiconductor, computer and communications fields in marketing, sales, engineering, manufacturing and consulting roles. He has contributed to microprocessor, computer and network equipment design for more than 40 products and has been consulting since 1996. He can be reached at firstname.lastname@example.org.