I recently described the difficulties in getting video conferencing past firewalls, and last week I wrote about H.460, which uses tunneling to pass video traffic through the firewall to an external server. The alternate approach is to use a Session Border Controller (SBC). The SBC is a device that is specifically designed to understand the H.323 and SIP protocols and act as a security gateway to allow video (and voice) traffic in and out of the enterprise network. But the SBC has additional capabilities that support alias-based dialing, like E.164 numbers, that can take a disparate enterprise and tie together the dialing plan to make connections easy.The SBC sits beside the firewall. It has two ports, a WAN-side port and a LAN-side port. The WAN-side port gets an external address, and the LAN-side port gets an internal address. The SBC handles the NAT translation between the two address spaces just like the firewall does.
Figure 1 - Video Firewall Bypass using SBCs
I have shown the SBC here completely bypassing the firewall. Most SBC vendors have submitted their systems to tests to verify that they are hardened against intrusion attacks, and so this is a reasonable configuration. But in many enterprises, the security team will not allow this configuration because they want their enterprise-standard firewall to be the only device making decisions about what traffic passes through to the outside world, and vice versa.
So alternate SBC configurations are often deployed where the SBC outside port is in the DMZ as shown in Figure 2, or the SBC LAN port is in the DMZ as shown in Figure 3.
Figure 2 - SBC WAN port in DMZ 
Figure 3 - SBC LAN port in DMZ 
In either case the firewall is configured to allow video traffic to pass to the SBC. The LAN and WAN ports of the SBC must still match the LAN and WAN address spaces, and the SBC must be allowed to do the NAT translation to make the system work correctly.
To manage the higher level addressing (E.164 or SIP URI style addressing) the SBC will need functionality that will connect together gatekeepers on either side of the firewall. SBCs support various approaches to solving this problem, including allowing an internal gatekeeper to peer with an external gatekeeper, or embedding a gatekeeper in the SBC to support registration, and then peering again with an internal gatekeeper.
The SBC approach has the advantage of supplying the right amount of bandwidth at each firewall to support that location's specific needs. This means the design is simple to scale, as decisions about bandwidth are not made at a central location but by each facility or enterprise connecting across the intermediate WAN.
We'll take a deeper look at how these approaches to firewall traversal (H.460 and SBCs) behave in the larger context of service providers and exchanges in upcoming postings.
