Best practices for Sametime broadcast services

by
Kay
Saffari

Level: Intermediate
Works with: Sametime
Updated: 03-Sep-2002

Sametime’s Broadcast Services allow a meeting to be held with one or more presenters and many audience members. The presenters in a broadcast meeting have access to all of the Sametime meeting tools—audio/video, chat, whiteboard, screen-sharing, and the ability to send Web pages or polls. The broadcast audience members have a limited set of Sametime tools. They can listen to the meeting, but not speak; they can view a presentation, but not edit it. Sametime broadcast is best for teaching classes or making presentations to a large, remote, and dispersed audience. Although there is no set rule that dictates when you should have a broadcast meeting, you should consider broadcast if the meeting will have more than 20 participants. In a meeting of that size or larger, it is unlikely that more than a few people will need full Sametime send-and-receive functionality.

The broadcast meeting is a valuable tool in both the business and academic worlds, offering the ability to provide cost-effective corporate presentations or distance learning for a large audience. But both broadcast meeting presenters and audiences must often deal with issues that do not occur with other types of online meetings. In this article, we’ll take a look at what issues can occur and what can be done to prevent or solve them. This article is intended for Sametime server administrators, although broadcast meeting participants can also benefit from the article by gaining an understanding of broadcast meeting issues.

Networking 101
To understand the potential problems of broadcast meetings, you must first understand the basic networking fundamentals involved with Broadcast Services. To access Broadcast Services, you must be sure your networking environment enables at least one of the following transports between the server and your broadcast audience members:

UDP multicast
This type of transport allows you to use one connection for an unlimited number of meeting participants. As the administrator, you can select the transport speed that best suits your needs—as high as you like. Meeting performance is not affected by an increase in the number of meeting participants because they all share the single multicast stream transmission. The transport speed selected should be able to propagate across all possible LAN and WAN connections between server and broadcast audience member without exceeding the speed capacity of any of those network segments.
UDP unicast
This type of transport requires that each user connect separately to the Sametime server, which creates redundant streams and results in additional bandwidth consumption for each additional UDP-unicast connected broadcast member. The speed you select (which is applied to data components only) is multiplied by the number of users. Total bandwidth is the sum of the data speed, the audio speed, and the video speed. Because unicast UDP consumes more bandwidth with each user who joins the meeting, this type of transport limits the number of meeting participants who can connect to the meeting.
TCP tunneling mode
Broadcast Services also supports a TCP mode for customers who choose to disable UDP traffic on their WAN/LAN.

To understand the difference between unicast and multicast UDP, consider the analogy of a radio broadcast (multicast UDP) versus a telephone conference call (unicast UDP). With a radio broadcast, a single radio program is broadcast to an unlimited number of listeners who tune in to the radio station. The radio broadcast operates in the same way regardless of the number of listeners. On the other hand, a telephone conference call requires that each participant in the call dial in on his or her own line. The number of participants cannot exceed the number of connections available for the call.

The best possible scenario for Broadcast Services performance is for all servers to use multicast UDP. You can choose a very high speed setting without limiting the number of connections, and thus, the number of users, who can access the Broadcast Services. Of course, the entire network must be multicast-enabled to take full advantage of the higher speed setting. If some parts of the network are multicast-enabled and others are not, UDP unicast (or even possibly TCP tunneling) is used in those segments, resulting in a higher overall bandwidth usage on those network segments and other segments close to the Sametime server.

As a graduate of Networking 101, you now know that the multicast UDP transport for all servers provides the best possible performance for Sametime’s Broadcast Services.

Troubleshooting
Now let’s take a look at some of the problems you might encounter.

It's too slow
What’s the most common question about Sametime broadcast meetings? Most often, customers ask why their broadcast meetings are so slow. But in most cases, the customer is not comparing Broadcast Services to competitive broadcast products. Instead, they are comparing broadcast meeting performance to meetings held in Sametime’s Meeting Room Client (MRC), which is an unfair comparison. Expecting a broadcast meeting to perform like an MRC meeting is like expecting a network television show to display equally on both the television set and the Internet. Like the television and the Internet, the MRC and Broadcast Services are two very different tools designed for different purposes.

In fact, Broadcast Services are slower by design. Sametime’s Broadcast Services were designed to meet a specific requirement that was not required for the MRC: to handle an unlimited and undetermined number of meeting participants. To handle a potentially large audience and to avoid limits on the number of participants, the Broadcast Services cannot allow data streams to consume too much bandwidth. The administrator restricts the data being sent by defining, in the Connection Speed Settings, a maximum bandwidth that is not to be exceeded. This limit can drastically affect the flow, and therefore the speed, of data displayed in the meeting via the whiteboard or application-sharing. Note that the speed of audio/video is not affected in broadcast meetings. In fact, these components function in almost exactly the same way in broadcast meetings as they do in MRC meetings.

The administration user interface (UI) offers a choice of rate (bit rate) settings for each stream type (audio, video, and screen-sharing/whiteboard) for this Connection Speed Setting. However, as the administrator, you can override the screen-sharing and whiteboard bit rate UI setting and select a higher rate by changing the setting in the database. For best results, do not attempt this step without contacting Sametime Customer Support.

To access the Connection Speed Settings from the Sametime Administration Tool, click Administer the server and then choose Configuration - Meetings Services. Select the Connection Speed Settings tab. The following screen shows the connection speed settings available from the UI. For more information, see the Connection speed settings section of this article.

Another factor affecting the speed of broadcast meetings is the use of LAN/WAN and modem settings. For both the MRC and Broadcast Services, the administrator has the option to configure data speeds for meetings with or without audio/video for both LAN/WAN and modem users. When users create new meetings, they can specify whether or not the meeting will include participants on modems. This user-determined selection at meeting creation time determines which set of administrator-configured settings will be used. If the modem setting is selected, all streams are limited to a maximum speed defined by the configured setting. If even one participant connects to the meeting via a modem, all participants receive data at the slower modem setting speed. For more information, see the Connection speed settings section of this article.

The MRC functions differently. Its endpoints ignore the “Screen sharing and whiteboard” rate settings and instead use an automatic mechanism with runtime interactivity between the server and each MRC endpoint. In this case, the MRC uses the maximum amount of bandwidth available. So even if modem participants are selected for a meeting, only the audio/video rates are reduced; the data component will run at the speed of the network for each individual connection.

The too slow complaint also arises when users attempt to play back a recorded meeting. Often users report that the original meeting conducted in the MRC went smoothly with no performance problem but the recording of that same meeting is slow. Why? The record-and-playback feature relies on Broadcast Services and therefore, must overcome the same performance obstacles. See the Record-and-playback issues section of this article for more information.

Audio/video/data problems
During a broadcast meeting, audience members may experience one or more of the following:

The audio may be silenced for short durations (two to three seconds).
The video picture may freeze or display large video blocks for up to 15 seconds.
The whiteboard or screen-sharing presentation may appear to freeze for up to 45 seconds before information is received again.
Audience members may not receive all of the chat text, sent Web pages, or polls.

These problems occur with network congestion. Sametime uses the User Datagram Protocol (UDP) to transmit network packets in broadcast meetings. UDP is a communications protocol that uses the Internet Protocol (IP) and is often referred to as UDP/IP. UDP is an alternative to the Transmission Control Protocol (TCP) and has similarities and differences with that protocol. Like TCP, UDP uses IP to transfer data units (called datagrams) from one computer to another. Unlike TCP, however, UDP does not divide a message into packets (datagrams), reassemble them, or provide sequencing of the packets. Any application program that uses UDP must ensure that the entire message has arrived and is in the right order.

UDP packets are generally assigned a low priority by network components such as routers, bridges, or gateways. When a network becomes congested or nears its capacity limit, low priority packets, such as UDP packets, are the first to be discarded. When packets are discarded on a congested network, end users can experience audio, video, and screen-sharing or whiteboard pauses (or dropouts). How long the pause lasts depends on the amount of network congestion and the individual stream protocol cycles used for audio, video, and screen-sharing/whiteboard data. The broadcast client pauses, and the stream does not play out until the next complete retransmission cycle (key frame) for that stream. The pause periods can vary for audio, video, and screen-sharing/whiteboard streams.

The key to resolving these types of problems is determining where and why congestion is occurring in your network. If the congestion is caused by Sametime traffic, you can reduce the maximum rates for Sametime streams using the Administration settings (which will result in lower performance respectively). If the congestion is due to other network issues, you can address those issues accordingly.

Record-and-playback issues
The record-and-playback feature of Sametime relies on Broadcast Services and therefore, is affected by the same issues faced by any broadcast meeting. For example, whiteboard and application-sharing playback can be perceived as slow when compared to the original MRC meeting content.

When using record-and-playback, the meeting will be recorded by the broadcast subsystem at the speed at which it took place from a broadcast endpoint perspective. If modem settings were used for the meeting, the recorded data will be shared at the slower modem rates listed in the Connection speed settings section of this article, and quality will be sacrificed. To test or preview how a meeting is being recorded, enable the meeting for broadcast and connect to a broadcast client. This client will show the rate being recorded and the rate with a ten-second delay. For data sharing, modem settings cause the data rate to be reduced to one-fourth of that of the LAN/WAN settings (using out-of-the-box configured settings), and whiteboard and application-sharing data will take four times as long to transmit for meetings with modem participants in comparison to meetings without modem participants. In contrast, data transmission to an MRC client results in using as much bandwidth as is available so that the data transmission speed is not affected by the modem participant setting.

An important consideration with recorded meetings is the use of image data. Selecting image data that requires shorter transmission times improves the speed of recorded meeting playback. The following table lists typical transmission times for various types of 640x480 size images:

Type of image	Modem (16Kbps)	LAN/WAN (64Kbps)
Raw image (no compression)	153.6 seconds	38.4 seconds
Photo-like image (2:1 compression)	76.8 seconds	19.2 seconds
Complex graphic (4:1 compression)	38.4 seconds	9.6 seconds
Busy graphic (8:1 compression)	19.2 seconds	4.8 seconds
Simple graphic (16:1 compression)	9.6 seconds	2.4 seconds
Minimal graphic (64:1 compression)	2.4 seconds	0.6 seconds

As the table shows, session data that can be most effectively compressed is delivered faster during playback. In addition, keep in mind that larger images (in width, and height, and depth) take longer to transmit during playback.

Another factor that can affect the playback of a recorded meeting is the initial image delivery time. Sametime data is delivered as a high-resolution/low-frame rate video signal. It has a keyframe, followed by multiple delta-frames of information. Keyframes are transmitted every 30 seconds (if the previous keyframe has completed transmission). A raw 640x480 image in modem speed can take up to 193.6 seconds to display during playback if the data delivery does not occur at the start of the keyframe transmission.

Some customers wonder why it takes several seconds before the playback of a recorded meeting begins. The Sametime broadcast client buffers ten seconds of data before beginning to play back the recording. Audio and video streams start about ten seconds after the client launches, but data streams can take longer depending on the complexity of the data, how well it compresses, and where in the keyframe cycle the stream is delivered to the broadcast endpoint.

Adjusting Sametime administrative settings
You can also minimize UDP packet-loss problems and improve broadcast performance by adjusting Sametime’s administrative settings. The following table identifies the administrative settings that can be used to improve broadcast meeting performance.

Setting	Improves
Time to buffer broadcast, audio, and video data	The playout of broadcast media streams to end users
Audio frames per packet	Audio quality
Connection speed	Broadcast meeting performance

Time to buffer broadcast, audio, and video data setting
Use this setting to minimize the effect of network congestion on the playing of broadcast media streams to end users. Broadcast meeting streams are transmitted at a consistent rate, but network congestion can cause some packets to be delayed or to arrive in the incorrect order. If packets are played immediately as they arrive, end users may experience intermittent audio and video or garbled speech—also known as jitter effects. If there is no audio/video in a meeting, then synchronization between the different streams is not an issue, and this setting is ignored. In other words, if you have a data-only meeting without audio or video, then there is no pre-roll delay. Application-sharing and whiteboard data will be seen immediately.

To avoid jitter effects, the Sametime broadcast client accumulates 10,000 milliseconds (or ten seconds) of audio and video data in its buffer before playing the stream for the end users. By storing the data in the buffer, the client can handle up to ten seconds of network congestion without causing jitter effects for the end users. Using the buffer causes a slight ten-second delay in the meeting broadcast, but it ensures that the meeting audio and video plays without interruption.

If end users in your environment are experiencing disruptive jitter effects, you can increase this setting as needed to create a buffer of more than the default ten seconds. Recognize that increasing this setting can have an undesirable impact on recorded meeting playback. Each time a user jumps forward or back in a recording, the buffer will reset, causing a pause equal to the value of this setting. If you increase this setting, the pause experienced by the user will be longer. Therefore, be careful not to increase the setting to the point of causing too long of a pause for the user. See the Sametime Administrator’s Guide for detailed instructions on how to increase this setting.

Audio frames per packet setting
Use the Audio frames per packet setting to minimize the effect of network packet loss on audio quality. Audio quality can degrade because of garbled speech, moments of unexplained silence, or sound that is intermittently lost. This setting also affects network bandwidth usage.

The Audio frames per packet setting specifies the number of audio frames sent in every Real-time Transport Protocol (RTP) packet in the audio stream. Each G.723 audio frame equals 30 milliseconds (ms) of audio data, and each G.711 frame equals 20 ms of audio data. You can specify settings of one, two, or three audio frames per packet.

You can increase or decrease the Audio frames per packet settings to best suit the needs in your environment. Increasing the setting does the following:

Reduces network bandwidth usage
Increases the possibility of poor audio quality due to packet loss

Decreasing the setting does the following:

Increases network bandwidth usage
Decreases the possibility of poor audio quality due to packet loss

With a higher setting, each packet contains more audio data. Fewer packets are needed, which results in less bandwidth usage during transmission. Each lost packet causes a bigger pause and interruption to the end user. With a lower setting, each packet contains less audio data. More packets are needed, which results in greater bandwidth usage during transmission. But because each packet contains less audio data, lost packets create less of a disruption to the end user.

When network packet loss is affecting audio quality, lower the Audio frames per packet setting and increase the Audio/Video jitter buffer setting to minimize the impact of lost packets on the audio quality. These adjustments increase the amount of delay (or latency) in the meeting, but improve the audio quality.

So how do you know if you should raise or lower the Audio frames per packet setting? Lower the setting for users with LAN/WAN connections; the end users will enjoy better audio quality. This type of connection can handle the increased bandwidth usage that results from the lower settings.

You may need to increase the setting for users with modem connections due to the limited bandwidth capabilities of these connections. If audio data bandwidth consumption routinely strains the network, set Usage Limits and Denied Entry settings for the server. See the Sametime Administrator’s Guide for detailed instructions about increasing or decreasing the Audio frames per packet setting.

Connection speed settings
Use the Connection speed settings to set the speeds at which audio, video, and data (screen-sharing/whiteboard) streams are sent on the network to the Sametime broadcast clients. You must set separate Connection speed settings for meetings that include audio and video and for meetings that do not include audio/video (data-only meetings).

You can select one of two connection speeds for Sametime meetings when a new meeting is created: modem or LAN/WAN. Because Sametime does not allow multiple speeds for a single meeting, the meeting creator must select the connection speed that would satisfy the slowest potential user. In other words, if one user is connecting to the meeting via modem, the slower modem connection speed must be used for all users in the meeting. The following table identifies the default speeds for audio, video, and data sharing for meetings with modem users and meetings with LAN/WAN users:

	Meetings with modem users	Meetings with LAN/WAN users
Default audio bit rate	6.3Kbps	64Kbps
Default video bit rate	16.0Kbps	64Kbps
Default application-sharing and whiteboard shared data bit rate	16.0Kbps	64Kbps or 128K*
* If a meeting with LAN/WAN users is a data-only meeting (with no audio/video), the default data bit rate is increased to 128K.

Setting Connection speed settings for broadcast meetings that do not include audio/video
The Sametime 3.0 Administration Tool includes separate Connection speed settings for broadcast meetings that do not include audio/video. A broadcast meeting without audio/video can include screen-sharing, whiteboard, chat, send Web page, and polling activity (questions and answers).

If a user schedules a broadcast meeting and does not include the audio/video tools in the meeting, the meeting streams are transmitted at the rates defined in the Connection speed settings of the Sametime Administration Tool.

Different meeting stream transmission rates are available for users who have modem connections to the server and users who have LAN/WAN connections. The available transmission rates are 16K (Kilobits per second), 32K, 64K, and 128K. Select a slower rate for modem users (perhaps 32K) and a faster rate (128K) for users with LAN/WAN connections.

You can select only one transmission rate for a meeting—either the transmission rate specified for LAN/WAN connections or the transmission rate specified for modem connections. The default settings for all Sametime broadcast meetings use the LAN/WAN connection speed settings. To use the slower modem Connection speed settings in a broadcast meeting, the end user must override the default by selecting the "People are attending using a modem" option on the Tools tab of the New Meeting page when creating the meeting.

Meeting performance can improve significantly with the higher bit-rate settings. However, you must also consider the slowest speed at which users connect. For example, if you specify the bit rate setting for the meeting as 64K and a user connects to the server using a 56K modem, the user cannot attend the meeting.

Setting Connection speed settings for broadcast meetings that include audio/video
When setting Connection speed settings for broadcast meetings with audio/video, consider the slowest speeds at which users connect and the cumulative bandwidth required to transmit all meeting streams in the broadcast meeting. These factors can greatly affect meeting performance for the end users.

For the best performance when attending a broadcast meeting with audio, video, and screen-sharing/whiteboard activities, all users should have a DSL or cable modem or a LAN/WAN connection to the Sametime server.

If your environment requires users to consistently access broadcast meetings via 56K modems, the meeting creator should consider eliminating video from the meeting. Meetings without video generally require a connection speed of greater than 37Kbps to view and to hear the meeting, and 56K modems can perform well with these bandwidth requirements.

Another solution for accommodating users with slow connection speeds is to use a telephone conference call for the audio portion of the meeting. Without the audio stream, the Connection speed settings defined for meetings that do not include audio/video are used to transmit the data streams, which can significantly improve screen-sharing or whiteboard presentations. If audio/video is not used in a meeting, then the pre-roll delay is discarded and data stream information is displayed immediately.

Summary: What can be done?
So now we know that data flow in broadcast meetings is constrained by design, and this article has shown ways to work around this design to improve broadcast meeting performance. To summarize, the tips for improving broadcast meeting performance are:

Enable as much of your network as possible to use multicast UDP.
Use a faster data transmission speed by overriding the data transmission speed settings available on the UI. (Contact Sametime Customer Support for more information.)
Use LAN/WAN connection speed settings for all participants. (Remember that for recorded meetings, LAN/WAN settings cause replay problems for modem users.)
Avoid using 56Kbps modems if possible; instead use DSL and cable modems for remote connectivity.
Use easily compressible images with application-sharing and whiteboard data. (For example, don’t use gradient color on whiteboard presentations.)
Use smaller image sizes (width, height, and depth).
Adjust the administration settings as needed.

ABOUT THE AUTHOR
Kay Saffari is a freelance writer in Lexington, Kentucky, where she lives with her husband and two children. She was previously employed by Lotus as a technical writer/editor, by AT&T as a technical writer, and by Electronic Data Systems as a computer programmer.