IP video conferencing can provide businesses substantial communications efficiencies and cost savings. However, IP video conferencing is has traditionally only worked between businesses that have similarly configured video conferencing equipment and firewall rules. The good news, is this is no longer true. So, why do firewalls break video and what to do about it?
The biggest difficulty to IP video conferencing is Network Address Translation (NAT). NAT is a popular method for allowing a one-to-many relationship of IP addresses in a corporate network. NAT keeps track of requests from machines inside a network to machines outside the network. To the outside world, all requests appear to come from one IP address, the public address. As information comes back, NAT handles the magical translation from the one public facing address back into the internal addressing scheme.
NAT was designed before business to business (B2B) video conferencing over the internet became possible. NAT was developed in a way that the NAT device was responsible for translating traffic from the internal, private address space to the external space. By performing the translation at the border to the public network, one address can be used for a multitude of machines.
Security gurus also like NAT because it hides the footprint of the network inside the firewall -- the network endpoints are obscured. Another security consideration is that since the connection to the endpoint must be initiated from inside the network and cannot come from the outside, it is impossible to connect into the network uninvited. This security provided by NAT causes a headache for videoconferencing over IP.
Why is it a headache? NAT firewalls typically look at Layer 3 and Layer 4 (of the OSI model) That's where they need to do their magic. However, video calls also includes information in layer 5 that tell the receiving system how to connect back to the originating system. NAT firewalls fix the layer 3 and 4 addresses, but typically don't understand the information at layer 5. This means the return connection doesn't make it back to the originating system. From a user's perspective, the call just doesn't work.
The solution is to use a firewall that is truly video aware.
See Polycom Firewall Traversal & Security page or Part 2, 3, and 4, of this blog, which describe specific solutions to these problems:
Part 2 - Polycom Real Presence Access Director
Part 3 - Polycom Video Border Proxy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.