Are there issues in managing video streams across an enterprise wide area network?

Yes there are issues in managing video, just like there are issues in managing telephony across a WAN.

Most often addressed by video compression (that is negotiated in the session establishment) such as H.263, the video component of the packet stream can be quite low. Regardless of whether a video meeting or a desktop video conference, a great deal of the background of the video is likely to be unchanging. Similar to silence suppression in G.729B, the pixels of a stilled background are not transmitted.

This simple fact, makes video much more practical than most people believe.

Video conferencing, just like telephony conferencing, is burdened by users high expectations. Video quality of network TV and cable channels have been conditioning folks into recognizing excellent picture quality and excellent audio quality. It will not suffice for network managers to penalize their video-using brethren with lowsy bandwidth allocations. At issue is the adequacy of the bandwidth allocated to video and how it is managed.

For companies where the IP Video service shares the call control, authentication and privacy services of the IP Telephony system, video streams will likely be treated with the same care as voice streams. However, the issue remains when and how to engage the prioritization and segmentation services appropriately.

When the user has a specific device for IP telephony – the IP phone – the MAC address can be the basis for the LAN switch's automatic determination that this port is to be segmented onto the vLAN for voice traffic, and in this way automatically assure quality. Prioritization flags can be set at the phone and then respected as the packet streams passes through the WAN.

With desktop IP video, where the IP telephony service is initiated at the PC and then built up as a media-rich video session, this segmentation and prioritization may not happen. Without some automatic method for enabling these two services – segmentation onto a vLAN service and packet prioritization (IEEE 802.1Q), the basic quality expectations may not be met, resulting in disappointed users and slow technological diffusion.

One way to solve this, is to have the IP Telephony module, the software controlling the call setup for example, automatically assign MAC ports associated with IP telephony call setups to the vLAN. This requires intimate knowledge of the vLAN control procedures as well as the IP telephony server.

The second method, is considerably more tricky. The LAN administrator must know which PCs are equipped with desktop video cameras, or are engaged in IP telephony services through a softphone, for example, so that she can manually assign user devices to the voice vLAN. Although still practical, it does tend to contaminate the voice vLAN with other traffic types – printing, email – where the demanding security and quality are not typically associated or required.

This post has already been read 0 times!