Network bandwidth requirements for media traffic in Lync Server 2013
Topic Last Modified: 2015-09-24
An important part of network planning is ensuring that your network can handle the media traffic generated by Lync Server. This section helps you plan for that media traffic.
Media Traffic Network Usage
The media traffic bandwidth usage can be challenging to calculate because of the number of different variables, such as codec usage, resolution, and activity levels. The bandwidth usage is a function of the codec used and the activity of the stream, both of which vary between scenarios. The following table lists the audio codecs commonly used in Lync Server 2013 scenarios.
Audio Codec Bandwidth
| Audio codec | Scenarios | Audio payload bitrate (KBPS) | Bandwidth audio payload and IP header only (Kbps) | Bandwidth audio payload, IP header, UDP, RTP and SRTP (Kbps) | Bandwidth audio payload, IP header, UDP, RTP, SRTP and forward error correction (Kbps) |
|---|---|---|---|---|---|
RTAudio Wideband |
Peer-to-peer |
29.0 |
45.0 |
57.0 |
86.0 |
RTAudio Narrowband |
Peer-to-peer, PSTN |
11.8 |
27.8 |
39.8 |
51.6 |
G.722 |
Conferencing |
64.0 |
80.0 |
95.6 |
159.6 |
G.722 Stereo |
Peer-to-peer, Conferencing |
128.0 |
144.0 |
159.6 |
223.6 |
G.711 |
PSTN, Conferencing |
64.0 |
80.0 |
92.0 |
156.0 |
Siren |
Conferencing |
16.0 |
32.0 |
47.6 |
63.6 |
The bandwidth numbers in the previous table are based on 20ms packetization (50 packets per second) and for Siren and G.722 include the additional secure real-time transport protocol (SRTP) overhead from conferencing scenarios and assume the stream is 100% active. Forward Error Correction (FEC) is dynamically used when there is packet loss on the link to help maintain the quality of the audio stream.
The stereo version of the G.722 codec is used by systems based on the Lync Room System, which enables stereo microphone capture to allow listeners to better distinguish multiple talkers in the meeting room.
For video, the default codec is the H.264/MPEG-4 Part 10 Advanced Video Coding standard together with its scalable video coding extensions for temporal scalability. To maintain interoperability with Lync 2010 or Office Communicator 2007 R2 clients, the RTVideo codec is still used for peer-to-peer calls between Lync 2013 and legacy clients. In conference sessions with both, Lync 2013 and legacy clients the Lync 2013 endpoint may encode the video using both video codecs and send the H.264 bitstream to the Lync 2013 and the RTVideo bitstream to Lync 2010 or Office Communicator 2007 R2 clients.
The bandwidth required depends on the resolution, quality, and frame rate. For each resolution, there are two interesting bit rates:
Maximum payload bitrate This is the bitrate that a Lync 2013 endpoint will use for resolution at the maximum frame rate supported for this resolution. This value is interesting because it allows the highest quality and frame rate video.
Minimum payload bitrate This is the bitrate below which a Lync 2013 endpoint will switch to the next lower resolution. In order to guarantee a certain resolution, the available video payload bitrate must not fall below this minimum bitrate for that resolution. This value is interesting so that you can understand the lowest value possible in cases where the maximum bitrate is not available or practical. For some users, such a low bitrate video might be considered an unacceptable video experience, so use caution when considering these minimum video payload bitrates. Note that for video scenes with little or no movement of the user the actual bitrate may temporarily also fall below the minimum bitrate.
Lync 2013 supports many more resolutions. This allows you to better adjust to different network bandwidth and receiving client capabilities. In addition the default aspect ratio for Lync 2013 has been changed to 16:9. The 4:3 aspect ratio is still supported for webcams which don’t allow capture in 16:9 aspect ratio.
Video Resolution Bandwidth
| Video codec | Resolution and aspect ratio | Maximum video payload bitrate (Kbps) | Minimum video payload bitrate (Kbps) |
|---|---|---|---|
H.264 |
320x180 (16:9) 212x160 (4:3) |
250 |
15 |
H.264/RTVideo |
424x240 (16:9)) 320x240 (4:3 |
350 |
100 |
H.264 |
480x270 (16:9) 424x320 (4:3) |
450 |
200 |
H.264/RTVideo |
640x360 (16:9) 640x480 (4:3) |
800 |
300 |
H.264 |
848x480 (16:9) |
1500 |
400 |
H.264 |
960x540 (16:9) |
2000 |
500 |
H.264/RTVideo |
1280x720 (16:9) |
2500 |
700 |
H.264 |
1920x1080 (16:9) |
4000 |
1500 |
H.264/RTVideo |
960x144 (20:3) |
500 |
15 |
H.264 |
1280x192 (20:3) |
1000 |
250 |
H.264 |
1920x288 (20:3) |
2000 |
500 |
Video FEC is included in the video payload bitrate when it is used so there are not separate values with video FEC and without video FEC.
Endpoints do not stream audio or video packets continuously. Depending on the scenario there are different levels of stream activity which indicate how often packets are sent for a stream. The activity of a stream depends on the media and the scenario, and does not depend on the codec being used. In a peer-to-peer scenario:
Endpoints send audio streams only when the users speak.
Both participants receive audio streams.
If video is used, both endpoints send and receive video streams during the entire call.
For video scenes with little or no movement the actual bitrate may temporarily be very low as the video codec will skip encoding regions of the video without change.
In a conferencing scenario:
Endpoints send audio streams only when the users speak.
All participants receive audio streams.
If video is used, all participants can receive up to five receive video streams and one panoramic (for example, aspect ratio 20:3) video stream. By default the five receive video streams are based on active speaker history but users can also manually select the participants from which they want to receive a video stream.
Each participant that turns on the user’s send video stream will send one or more video streams. Lync 2013 add the capability of sending up to five video streams to optimize the video quality for all the receiving clients. The actual number of video streams being sent is determined by the sender based on CPU capability, available uplink bandwidth, and the number of receiving clients requesting a certain video stream. The most common case is that one H.264 and one RTVideo video stream are being sent in case a legacy client joins the conference. Another common scenario is that several H.264 video streams (for example, with different video resolutions) are sent to accommodate different receiver requests.
In addition to the bandwidth required for the real-time transport protocol (RTP) traffic for audio and video media, bandwidth is required for real-time transport control protocol (RTCP). RTCP is used for reporting statistics and out-of-band control of the RTP stream. For planning, use the bandwidth numbers in the following table for RTCP traffic. These values represent the maximum bandwidth used for RTCP and differ between audio and video streams because of differences in the control data
RTCP Bandwidth
| Media | RTCP maximum bandwidth (Kbps) |
|---|---|
Audio |
5 |
Video (Only H.264 or RTVideo being sent/received) |
10 |
Video (H.264 and RTVideo being sent/received) |
15 |
For capacity planning purposes, the following two bandwidths are of interest:
Maximum bandwidth without FEC The maximum bandwidth that a stream will consume, including the typical activity of the stream and the typical codec used in the scenario without FEC. This is the bandwidth when the stream is at 100% activity and there is no packet loss triggering the use of FEC. This is interesting for computing how much bandwidth must be allocated to allow the codec to be used in a given scenario.
Maximum bandwidth with FEC The maximum bandwidth that a stream consumes, including the typical activity of the stream and the typical codec used in the scenario with FEC. This is the bandwidth when the stream is at 100% activity and there is packet loss triggering the use of FEC to improve quality. This is interesting for computing how much bandwidth must be allocated to allow the codec to be used in a given scenario and allow the use of FEC to preserve quality under packet-loss conditions.
The following tables also list an additional bandwidth value, Typical bandwidth. This is the average bandwidth that a stream consumes, including the typical activity of the stream and the typical codec used in the scenario. This bandwidth can be used for approximating how much bandwidth at any given time is being consumed by media traffic but should not be used for capacity planning, because individual calls will exceed this value when the activity level is higher than average. The typical video stream bandwidth in the tables below is based on a mix of different video resolutions as observed in measured customer data. For example, in peer-to-peer sessions a majority of users would use the default video render window whereas some percentage of users would increase or maximize the Lync application to allow higher video resolutions.
The following tables provide these three bandwidth values for the various scenarios.
Audio/Video Capacity Planning for Peer-to-Peer Sessions
| Media | Codec | Typical stream bandwidth (Kbps) | Maximum stream bandwidth without FEC | Maximum stream bandwidth with FEC |
|---|---|---|---|---|
Audio |
RTAudio Wideband |
39.8 |
62 |
91 |
Audio |
RTAudio Narrowband |
29.3 |
44.8 |
56.6 |
Main video when calling Lync 2013 endpoints |
H.264 |
460 |
4010 (for maximum resolution of 1920x1080) |
Not applicable |
Main video when calling Lync 2010 or Office Communicator 2007 R2 endpoints |
RTVideo |
460 |
2510 (for maximum resolution of 1280x720) |
Not applicable |
Panoramic video when calling Lync 2013 endpoints |
H.264 |
190 |
2010 (for maximum resolution of 1920x288) |
Not applicable |
Panoramic video when calling Lync 2010 or Office Communicator 2007 R2 endpoints |
RTVideo |
190 |
510 (for maximum resolution of 960x144) |
Not applicable |
Audio/Video Capacity Planning for Conferences
| Media | Typical codec | Typical stream bandwidth (Kbps) | Maximum stream bandwidth without FEC | Maximum stream bandwidth with FEC |
|---|---|---|---|---|
Audio |
G.722 |
46.1 |
100.6 |
164.6 |
Audio |
Siren |
25.5 |
52.6 |
68.6 |
Main video receive |
H.264 and/or RTVideo |
260 |
8015 |
Not applicable |
Main video send |
H.264 and/or RTVideo |
270 |
8015 |
Not applicable |
Panoramic video receive |
H.264 and/or RTVideo |
190 |
2010 (for maximum resolution of 1920x288) |
Not applicable |
Panoramic video send |
H.264 and/or RTVideo |
190 |
2515 (for sending bitstreams using multiple resolutions/codecs |
Not applicable |
For the main video the typical and maximum stream bandwidth is the aggregated bandwidth over all received video streams and over all send video streams respectively. Even with multiple video streams the typical video bandwidth is smaller than in the peer-to-peer scenario because many video conferences are using content sharing that leads to much smaller video windows and thus smaller video resolutions. The maximum supported aggregated video payload bandwidth is 8000 Kbps for both, send and receive streams which would be used e.g. if there are two incoming 1920x1080p video streams.
The typical stream bandwidth for panoramic video is based on currently available devices that only stream up to 960x144 panoramic video. Once devices with 1920x288 panoramic video become available the typical stream bandwidth is expected to increase.
Audio Capacity Planning for PSTN
| Media | Typical codec | Typical stream bandwidth (Kbps) | Maximum stream bandwidth without FEC | Maximum stream bandwidth with FEC |
|---|---|---|---|---|
Audio |
G.711 (this includes PSTN participants in conferences) |
64.8 |
97 |
161 |
Audio |
RTAudio Narrowband |
30.9 |
44.8 |
56.6 |
The network bandwidth numbers in these tables represent one-way traffic only and include 5 Kbps for RTCP traffic overhead for each stream. For video the maximum video bit rate is used for computing the maximum stream.