This issue is confused a bit by the vendors, because Tandberg pushes one approach and Polycom pushes the other. In fact a reader, Mr. Nutley, posted a comment on my last approach saying the problem is solved, H.460 is the way to go. Let's start with the H.460 tunneling and see where it makes sense to use this approach.As described in my last post, the nature of video is that we need to be able to initiate it from either side of the firewall and have it successfully cross the firewall, without compromising the security that the firewall provides to the data network. So we have to find a way of allowing this traffic to flow that still respects the concerns of the security team about hackers, who also want to cross the firewall and will take every opportunity to do so.
The H.460 solution (e.g. the Tandberg Expressway) provides a trusted server outside the firewall that acts as a proxy for all video conferencing traffic that crosses the firewall. Endpoints register with the H.460 server and open a channel to the server to send and receive signaling messages.
When an endpoint wishes to connect with another endpoint, signaling passes through the server. The server provides its own IP address as the destination IP address for all media streams. Each endpoint sets up a connection through the server, and so the firewalls on each end allow the call setup, since each was initiated from the trusted side of the firewall.
Note that the laptop user who is not behind a firewall gains access in the same way by connecting directly to the H.460 server.
The clear advantage to this approach is that there is no need to create special rules on the firewalls, and no need for the firewalls to understand the complexities of the H.323 or SIP protocols. Internal IP addresses are protected because each firewall does its usual NAT translation. The far-end video conferencing system never sees any address other than the address of the H.460 server. External endpoints gain access directly as well by registering to the same H.460 server. For a small deployment this solution works extremely well. The simplicity of the setup and call process makes this architecture the easiest way to go for small numbers of endpoints and/or small numbers of geographic locations (offices or remote sites.)
As the number of locations and the geographic diversity increases, however, this approach has some clear scaling constraints. The single server is managing not only signaling but all transport streams. As the number of simultaneous calls grows, so will the demand on this server, and it will soon run out of capacity.
The second problem is one of geography. When offices become globally located, having a single server may mean that calls get routed very long distances. Distance translates into latency, which degrades the interactivity of the call.
For instance, suppose in the diagram above that corporate HQ and the H.460 server are located in Chicago. Suppose further that one of the offices is in Singapore and the remote worker is in Hong Kong. When these two endpoints connect for a video call, the call is routed from Singapore to Chicago and then back to Hong Kong. Clearly a more direct route would be preferable for the global enterprise.
In my next post we will look at a different approach which is not quite as simple as H.460 but does a better job of addressing the scaling and geography issues.
