If you are deploying video conferencing, you are probably aware that it requires significant bandwidth and also...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
tightly controlled jitter, latency and packet loss. Perhaps you have a stable and well- performing network already that may even be running VoIP. So you should be good to go, right? Not so fast.
What to consider before rolling out video conferencing over your enterprise WAN
There are a few things to check and consider before you move ahead with your video conferencing deployment, especially if that traffic will traverse your enterprise WAN. Remember that TCP-based applications tend to take good care of themselves even when there is congestion on the network. Real-time applications, however, utilize UDP, which has no form of flow control or error correction. A more stable network environment will provide for better video conferencing performance. Even if VoIP is already in use, video will put more demands on the network.
Network performance problems can be very visible in a video conference session. Video users may include customers and key executives, and performance expectations will be high. Addressing the specific network requirements for video up front should be considered essential. Video should be deployed with an adequate amount of dedicated bandwidth and with Quality of Service (QoS) implemented in both the WAN and LAN.
Calculate video conferencing bandwidth requirements
Start with an inventory of sites, endpoints and network access loop sizes. Determine the desired resolution for video calls and how much bandwidth this requires. Your system vendor can provide a table of resolution versus bandwidth. It's a good idea to test extensively to confirm how a given resolution/bandwidth actually looks in practice. Content sharing, such as showing a speaker's PowerPoint slides, takes away bandwidth from the live stream. Be sure to test a given resolution setting while running a presentation to understand how the live video will look when content is shared. Video bandwidth specifications reflect only the video payload. Actual bandwidth consumed by the video conference session on the IP network will be 20% more than the vendor's table sheet value when network overhead is included. Therefore, when endpoint bandwidth is chosen, the data sheet value will need to be increased by 20% to reflect how much bandwidth will be consumed on the network for video conferencing.
When you have completed the site inventory and determined endpoint resolution, you will now be able to add up the network traffic generated by video conferencing at each site. Take the number provided to you by your video conferencing vendor and increase that by 20% to include the network overhead. Next add the total video conferencing bandwidth requirement per site to the bandwidth required for enterprise applications. When you add up the traffic, don't forget choke points. If you are installing a bridge or using an external bridging service, be sure to account for the traffic to the bridge or egress point. If you choose to allow site codecs to host multipoint calls, be sure the site has the bandwidth to support it. For example, consider a site with a single HD endpoint with 50% of the site's bandwidth allocated to video. If a second video conference session is started using the endpoint's multicall capability, 100% of the site's bandwidth will be consumed. To prevent this disruptive behavior, increase site bandwidth to allow this operating mode, or disable multipoint calling in the endpoint's system configuration.
Review existing contracts and circuits before adding bandwidth
Your video conferencing bandwidth requirements may reveal some sites with adequate bandwidth and other sites that need more. When upgrading, consider using Ethernet in lieu of bonded T1 / E1 access lines. This can enable future upgrades without local loop replacement. If contracts are approaching expiration it may be an excellent time to conduct an RFP. Your incumbent supplier might provide improved pricing if you ask, but getting competitive quotes will give you a comparison on the current cost of bandwidth.
While reviewing network bandwidth, it may be a good time to think about a WAN optimization strategy. While you are reserving capacity for video traffic (and VoIP), you will be preventing other traffic from bursting into the space reserved for video. While most WAN optimizers don't optimize video traffic themselves, they do get other traffic out of the way of video, allowing the associated applications to run at acceptable performance levels with less bandwidth. WAN optimization often results in an improved user experience and bandwidth savings at the same time.
Include QoS in your video conferencing bandwidth calculation
Providing adequate bandwidth is like building an expressway for video conferencing traffic. Implementing QoS policies is like providing commuter lanes, speeding video traffic past congestion points. Although the discussion here is centered on video, the QoS and bandwidth strategy should take other application traffic into account. The RFC 4594 entitled "Configuration Guidelines for DiffServ Service Classes" provides guidance and examples of differentiating traffic by application type and then providing suitable QoS levels for those applications.
Implementing QoS begins with classifying packets for priority treatment and marking accordingly. This establishes the trust boundary at the network edge. Priority queues are established along the network path to manage congestion. Policing and shaping can throttle burst traffic to avoid congesting interfaces. Call admission control (CAC) can be used to limit the amount of video traffic being presented to the network. It may be advisable to provision for 100% utilization of all video suites unless a scheduling process can be implemented to reserve bandwidth in advance. Otherwise there are bound to be disappointed users who find that their attempts to launch a scheduled video conference are denied by CAC due to network congestion. If your WAN is MPLS-based, work with your network service provider to implement your QoS policy. You will have something like four to six classes in which applications will be mapped to. If your WAN is frame relay or using a private line, QoS will be managed through your site routers. Video conferencing expert John Bartlett explains how to handle QoS for your video conferencing environment in this tip: WAN video conferencing network design requirements for QoS.
Target values for acceptable video conference performance are 150 ms latency, 40 ms jitter and 1% or less packet loss. Latency includes a fixed component related to the network transmission path length, so physical distance makes this parameter somewhat difficult to control. Jitter -- variation in network delay -- and packet loss result when there is congestion. Providing adequate bandwidth and implementing QoS end-to-end are the tools needed to achieve these targets and ultimately user expectations. Overprovisioning bandwidth alone won't prevent bursty traffic from impacting real-time application quality.
There are a lot of steps in implementation of QoS, but a lot of resources are available to assist with the process. Your LAN switch and router manufacturers are good sources of information on setting up QoS with their equipment. A trusted VAR or reseller can provide guidance and professional services. Also, the book End-to-End QoS Network Design by Tim Szigeti and Christina Hattingh, from Cisco Press (2005), covers the topic extensively.
Install, implement and test your video conferencing system
As you install your video conferencing systems and implement QoS, test extensively. Run multiple conferences simultaneously and look for issues on the network and with conference quality. Problems such as pixilation, ghost images or loss of lip-sync will generate help desk calls and can create a negative buzz about the deployment. Better to find problems in the beginning than to hear about them from disgruntled users after the launch.
Monitor to find the video conferencing problems before your users
The network team should know there is a problem before a user calls the help desk. Problems can result from traffic growth, configuration changes or circuit trouble. Network tools that test end-to-end are the best choice. Video conferencing is a demanding real-time application, but with adequate network provisioning and end-to-end QoS implemented in the network, you will be well positioned to meet user expectations.