Video is an extremely valuable collaboration tool. With video we get rich communication with our colleagues, customers and others where not only do we hear, we see. Seeing others lets us know their attention level, their concern, and even helps us get to know people better. Video, as the saying goes, is the next best thing to being there.
As valuable as it is, this richness comes with a price: bandwidth. Video streams are shared via networks, and everyone who has ever watched a video off the web knows video can take a lot of network resources. But, how much network resource exactly? This article shows how IBM Sametime 9 video uses bandwidth and let's you do basic calculations to determine how much bandwidth you need in your own environment.
- in communications, refers to the actual audio and/or video data. Media is typically used as separate from control
, the SIP commands that control the call.
Bitrate, Bandwidth, Line Rate ,Call Rate
- is the number of bits
that are conveyed or processed per unit of time. Bandwidth, line rate, call rate, and bitrate have been synonymously used here in this article .
- is the communication path from client to the MCU
- is the communication path from MCU to client
- It is bit stream originating from a particular media source. It can be audio or video.
- is the number of distinct pixels
in each dimension that can be displayed
- also known as frame frequency and frames per second (FPS)) is the frequency
(rate) at which an imaging device produces unique consecutive images called frames
- short for "coder-decoder", a codec is a method for compressing and encoding media before transmission, then decompressing and decoding when it is received. Different codecs require different amounts of CPU or network resource.
Scope of Article
This contents of this article are applicable to Sametime 9.0 client and Sametime 9.0 server only . A separate article for interoperability for legacy clients will be published soon.
Understanding the total audio-video bandwidth needs for your organization depends on two-factors: First the concurrency
, number of users participating in video conferences at the same time. This requires some educated estimation based on the organization's existing data such as assumption, usage culture or pattern on similar technology, or pilot programs. If the estimate is too high, there will be bandwidth left over, and that could be costly and wasteful. Conversely, if the estimate is too low, audio and/or video quality may not be acceptable, and other networked applications may suffer due to bandwidth capacity overflowed. This part of the assessment requires that you poll your users, collect metrics on their video use, or some other way determine how much they use the video feature.
The main topic of this article is the second factor: how the media is generated and packaged. Each communication session involves audio-only or audio and video, so the network bandwidth required for a user is basically the total bitrate of the codecs
being used in the session. Audio codecs, in general, require much lower bitrates than video codecs because audio data is less in volume than video data. So the first step in knowing the bandwidth cost of a given session knowing what codecs are being used.
IBM Sametime 9.0 provides 6 audio codecs (SAC (Siren-LPR Scalable) , Siren-LPR , G.722.1C , G.722.1, G.729, G.711) and 3 video codecs (H.264-SVC , H.264 and H.263). Each codec requires different network bandwidth to operate. Within a video codec, there are many attributes that effect the data payload size and bitrate. For example, video resolutions, HD resolutions require higher bandwidth than SD resolutions.
Out-of-the-box, Sametime defaults to SAC (Siren-LPR Scalable) for audio and H.264-SVC for video as preferred codecs during SIP session negotiation between two Sametime endpoints –client to client, or client to the V-MCU. However, endpoints may select a different audio codec than SAC (Siren-LPR Scalable) and H.264-SVC to establish the call in an integrated environment with external audio/ video bridge. This flexibility does effect the bandwidth and can be configured and controlled from the external bridge.
IBM Sametime provides capabilities to protect the network from being over-run by audio and video data packets in case the usage concurrency is higher than expectation and not planned for. When deployed, each audio and video call is monitored to control bandwidth usage based on class of users and location policies. The call may be allowed, rejected, or modified to meet the utilization of the network bandwidth constraint imposed for audio and video.
The following sections describe in detail the Sametime audio and video codecs usage and network bandwidth management.
Sametime 9.0 uses Siren-LPR Scalable(Scalable Audio Codec) for audio communication. The available bandwidth is split between all users in the call , such that more bandwidth is allocated for the active speaker (48k approx) and less for background speakers (10k approx for each)
The table below lists the bandwidth requirements for each of the audio codecs supported by Sametime 9.0.
Table 1: Sametime audio codecs, bitrates and sampling rates
Sampling Rate (kHz)
|SAC (Siren-LPR Scalable)||32/ 48/ 64||48|
|Siren-LPR ||24/ 32/ 48/ 64|| 48|
|G.722.1C||24/ 32/ 48||32 |
G.729 (only used in SUT)
Sametime 9.0 uses H264- SVC ( Scalable Video Codec) , for enhancing the video conferencing experience. In simple terms, this refers to the use of layering when sending video - a less capable client will request only the lower, low quality, layers, while a more capable client will receive multiple layers, which combine together to display a higher quality video. The benefit over older technologies is that SVC is able to perform a more graceful degradation of video when low bandwidth or CPU usage is encountered. Like its predecessor H.264/AVC, SVC covers a wide application range, from low bitrate mobile applications, to High-Definition Television (HDTV) broadcasting. For more information on SVC, refer to RFC 6190
The video conference experience is dictated by the client line rate. The client line rate is set by the administrator as part of the user policy. Some group of users may have different video policy than others. The policy has the provision for adding conference templates. Each conference room owned by the user maps to a conference template in the video policy . The template specifies three important settings - Conference Mode , Conference Experience and Conference Line rate . These settings along with the client line rate determine the overall video experience for a conference.
- The default setting for client line rate - 384 kbps
- The default setting for mobile client line rate is - 384 kbps
- The default setting for a conference template is -
- Conference Mode - Mixed AVC+SVC
- Conference Experience - Optimized for Mobile Devices
- Conference Line Rate - 384 kbps
The client line rate defines the highest bandwidth that can be allocated for the client . The conference line rate determines maximum bandwidth allowed for any user in the call.
Note : The conference line rate is not the aggregate of bandwidths of all the users in the conference but a bandwidth per user.
Sametime 8.5.2 clients will continue using the video resolution parameter in the video policy to determine the maxbitrate , framerate and video resolution.
Video Resolutions and Bandwidth Requirement for Down-link from V-MCU to Client
Depending on the number of participants in the conference, Sametime client can receive remote video streams of different resolutions. The video resolution of these streams are decided by the line rate you have been assigned by policy. E.g if there are ten participants in the conference, client can receive maximum six remote video streams. With the line rate of 1024kbps, two streams will be 180p@30fps
, while four will be 180p@15fps
Number of Remote Video Streams: 6
Number of Remote Video Streams: 5
Number of Remote Video Streams: 4
Number of Remote Video Streams: 3
Number of Remote Video Streams: 2
Number of Remote Video Streams: 1
Video Resolutions and Bandwidth Requirement for Uplink from Client to V-MCU
The Sametime client sends three temporal layers (T0, T1 and T2) of 7.5, 15 and 30 frames per seconds (fps) for each of the spatial resolutions of 180p, 360p and 720p. Bandwidth requirement for each temporal layer is listed below:
The Sametime client can send multiple temporal layers of each resolution based on bandwidth available. The list of uplink resolutions for a given bandwidth is listed below. E.g with 1024 kbps, client can send three streams of 180p@30fps
. However, to save bandwidth, client will send a stream only if there is at-least one remote client in the conference receiving it. E.g. if no remote client is receiving the 720p@15fps
, then it will not be sent. Client will send only 180p@30fps
Lets consider an example to make things clear
A video conference of 6 participants, 2 on mobile, 2 on mid-range laptop, and 2 on high-end laptop with large screen and powerful processor.
The table below explains bandwidth consumption metrics for each type of user.
|Video Resolution@Frame Rate (fps) x Number of Users|
Possible Number of Remote Videos
Downlink Bandwidth Consumed by client (kbps)
Uplink Bandwidth Consumed By Client (kbps)
|Mobile 1||180P@7.5fps x 2 |
|Mobile 2||180P@15fps x 1 + 180P@7.5fps x 2|
|Mid range Desktop 1||180P@7.5fps x 5|
|Mid range Desktop 2||180P@15fps x 5|
|High end Desktop 1||180P@30fps x 4 + 180P@15fps x 1|
|High end Desktop 2||180P@30fps x 5|
Aggregate bandwidth consumed for this conference will be 4864 kbps in downlink and 1536 kbps in uplink.
Due to the estimated concurrent call rate that might not stand up with reality or known limitation of bandwidth availability, audio and video data rate should be moderated to protect the network for other business critical applications and to provide enough bandwidth for acceptable voice and visual quality.
Sametime uses SIP to negotiate media session. Embedded in the SIP message is a SDP (Session Description Protocol RFC 4566) section containing the desired session bandwidth attribute, which the Bandwidth Manager uses to monitor transmission rates on the managed network.
As illustrated in Figure 3 below, Bandwidth Manager, when deployed, will be part of the signalling path, and it will perform CAC (Call Access Control) based on the available bandwidth.
Depending on user policy, locations of the call, and available bandwidth, the Bandwidth Manager may let the call through, reject the call, or modify the media or the bandwidth attribute in the SDP. The action ensures that the total transmission rate for audio and video will not exceed the available bandwidth allocated for audio and video usage in the system configuration.
Calls are recorded with detail such as call locations and bandwidth required. Organizations may use this information to measure the usage of audio and video and their utilisation of the network capacity for future planning. How much impact the deployment of audio and video exerts on the network can be calculated with the data captured by the Bandwidth Manager.
There are differences in audio and video codecs bandwidth usage due to how the Media Manage processes the data in Sametime 9.0. Calculating the required network bandwidth for an organization should be based on the formulas given in (2) and (4). It should be part of capacity planning to afford the most optimal network conditions for audio and video. Organizations should consider deploying Bandwidth Manager to protect the network and to ensure quality audio and video calls. Using data captured by the Bandwidth Manager enables organization to plan for future capacity.