Business video conferencing is a very demanding application for the enterprise network. The first step in a video...
conferencing setup is to understand the video conferencing bandwidth requirements on the network. Once we know the video conferencing bandwidth requirements, the network can be properly provisioned to support it.
These two key parameters drive video conferencing bandwidth requirements:
- The bandwidth per video conference call
- The number of concurrent video conference calls on each network link
Determining video conferencing bandwidth requirements
Video conference calls can operate anywhere from 128 Kbps for a desktop system all the way up to 20 Mbps or 30 Mbps for a telepresence suite. The video resolution and the ability of the session to handle image motion are directly tied to the amount of bandwidth needed. The table below gives typical examples of video conferencing bandwidth requirements, given the specified resolution and frame rate. Frame rate determines the ability of the video conference call session to handle motion, while resolution determines how many pixels there are on the screen image, and thus how much detail users will be able to see in that image.
|384 Kbps||CIF||30 fps|
|512 Kbps||4CIF||15 fps +|
|768 Kbps||4CIF||30 fps|
|1 Mbps||HD720||15 fps +|
|2 Mbps||HD720||30 fps|
|4 Mbps||HD720||60 fps|
|6 Mbps||HD1080||30 fps|
This chart shows the video transport bandwidth. When planning a video conferencing setup, the video conferencing team will use these values to assess network bandwidth. This is the amount of traffic supported inside the RTP packet headers. The actual bandwidth experienced on the IP network, after adding RTP, UDP, IP and Ethernet headers will be about 20% higher. So 1 Mbps video conference calls actually use about 1.2 Mbps of network bandwidth. I refer to these values as "transport bandwidth" (e.g., 1 Mbps) and "network bandwidth" (e.g., 1.2 Mbps) to ensure there is no confusion.
To determine the right resolution and frame rate for your company, make sure the actual users experience the behavior of the video conference calls in the actual context where they will be used -- with the screens or projectors you plan to use -- to determine if the proposed video conference call quality is sufficient. If end users are not comfortable with the quality, they will quickly resort to other methods of communication, such as a telephone call or travel.
Estimating the number of concurrent video conference calls
Step two is to determine how many concurrent calls must be supported on each WAN link. For small offices where there are only one or two video conferencing systems, just assume that the two are running concurrently. For larger offices, make your best guess on how many video conference calls will occur concurrently based on your busiest meeting times. If the company has multiple-time-zone offices, take the time shifts into account. Map the call patterns onto the network topology and create a spreadsheet to track concurrent call assumptions and the bandwidth per call determined above. I use a spreadsheet so that the inevitable "what if" questions can be answered by simply changing spreadsheet input parameters.
Beware of the video conferencing bridge
The video conferencing bridge, or MCU (multi-point control unit), is a bandwidth hotspot. All video conferencing endpoints involved in concurrent multipoint video conference calls connect directly to the bridge. Thus, the bridge has to be in a location that supports a high-bandwidth connection.
New business video conferencing strategies often put the bridge in a data center because it looks and smells like a server. But the best place for the bridge may be in a colocation facility near the core of the WAN service provider's network. Bandwidth is inexpensive at these locations, and since the video conferencing call connections are coming from all parts of the WAN, the bridge is now in the right place to support many endpoints. This approach also scales well as video conferencing calls grow within the company.
Small companies are tempted to use the built-in MCU capability available in some video conferencing endpoints. I try to discourage this because it means end users have to be aware of the network topology and its bandwidth limits. If you have to do this, limit the endpoints with MCU capability to the HQ location or other locations where there is sufficient bandwidth to support the full MCU capacity that those end points support. Do not let a smaller office location use an embedded MCU or else the WAN access link will quickly become overloaded.
Managing bandwidth with call admission control
The last step is to make sure your video conferencing setup has a call admission control (CAC) capability. The communications manager or gatekeeper is programmed to understand the network topology and how many concurrent calls are allowed on each link. If a new video conference call will violate one of those constraints, the call is denied. This mechanism ensures that video conference calls get the bandwidth they need and maintain high quality throughout the call.
About the author:
John Bartlett is a principal consultant at NetForecast. He is a leading authority on real-time traffic, Internet performance and Quality of Service (QoS) techniques. NetForecast specializes in network-based application performance issues for transaction-based and real-time applications.
John has 28 years of experience in the semiconductor, computer and communications fields in marketing, sales, engineering, manufacturing and consulting roles. He has contributed to microprocessor, computer and network equipment design for over 40 products. He has been consulting since 1996. He can be reached at firstname.lastname@example.org.