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
Requires Free Membership to View
SearchUnifiedCommunications.com members gain immediate and unlimited access breaking industry news, expert advice on UC, technical guides, and more -- all at no cost. Join me on SearchUnifiedCommunications.com today!
Kate Gerwig, Editorial Director
how many pixels there are on the screen image, and thus how much detail users
will be able to see in that image.
| Bandwidth | Resolution | Frame Rate |
| 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.
|
|
|
|
| John Bartlett | |
|
|
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 john@netforecast.com.
This was first published in July 2010