Zivney: Independent of the network path, the security industry has increased the requirements for encryption. AES Rijndael encryption standards which exceed triple DES are being required between client and server, and between server and controller. We are seeing similar DESfire requirements between the card and reader for smart cards. Soon everything will be encrypted. If the IT department is involved early, they can be a good partner.
ST&D: Have you made security video available on the corporate network or used the corporate backbone for video transport? Do have any advice to give to anyone considering this in the near future?
Lockhart: Video is currently being deployed across corporate LANs and WANs all of the time. The only real constraint is bandwidth allocation and utilization. On the LAN side, any well-designed, 100 Mps switched infrastructure should handle video. The issue is what well-designed means, and that is why the IT people must be an integral part of any video surveillance system design. For remote access and transport over WANs or Internet connections, pipe size is the only real problem. The newer codecs of MPEG-4 and H236/264 allow for allocating bandwidth utilization by controlling frame sizes and rates to available throughput. This along with internal QoS software of most edge devices can make this work quite well. But as in the LAN design, the IT/WAN folks must be part of the design team.
Moss: We both make products that make video available on networks and we have video available on our own network. If you're not careful, video can soak up a lot of bandwidth needlessly. We've done several things to address video in a bandwidth-conserving way. First, our products implement something called video proxy a technique for reducing the number of connections required to each individual camera. Second, we cache images and only transmit them when they have changed, and then only at the size of image being requested.
Even with all of that, however, we have increased the outbound network capacity. Typically you'll find that network bandwidth is sold as so much outbound and so much inbound. Usually the inbound value is much higher because the scheme is set up to support people who surf Web sites and thus require a lot more data in than they send out. With video, this balance can reverse you're sending more out than you get in. As a result, when increasing bandwidth, be sure to increase it in the right direction (namely, outbound) if you're transmitting video.
Zivney: IP cameras, such as those made by Axis, are intranet and Internet optimized. They work well with our systems. Fortunately, we built a browser into our front end and added a Web server to support IP cameras embedded into our graphics package. However, it came together easily for us and our customers because both Hirsch and Axis followed IT and Microsoft standards. We have also interfaced to AD digital video recorders using the AD API. The interface for both video and control is via TCP/IP, so the DVR, or DVRs, can be located next to our server or connected via the Web anywhere in the world.
Prokupets: Yes, we have done both extensively. In fact, we deployed the largest IP video installation in the world at Cisco Systems. To date, it has more than 2,600 cameras in operation around the globe. My advice for anyone considering using the corporate backbone for video is to balance customer requirements with available network bandwidth. Understand your system architecture, frame rate, compression rate, and the priority of business applications versus digital video needs based on quality of service, the number of video streams and available bandwidth. With proper design and careful consideration of the bandwidth required for the video stream and the customer's surveillance needs, video applications can utilize the corporate network without interfering with day-to-day critical business applications.