Bandwidth Manager statistics

Understanding the IBM® Sametime® Bandwidth Manager monitor statistics can be useful for fine-tuning site and link bandwidth allocations and peak utilization points.

Links and sites

  • Bandwidth in Use shows the static amount of bandwidth allocated for the call, link, or site based on applied Call Rate policies. As such, it is not a reflection of the real-time current bandwidth consumed - rather, it should be considered a maximum allowed for the call.

    The allocated bandwidth does not affect other activities that might be occurring in the monitored element - it affects only audio/video traffic. Chat, call setup, server communication overhead are all not counted towards the bandwidth allocation. The allocated bandwidth affects only the payload and does not include any transport-related data.

  • Bandwidth Remaining

    shows the difference between the configured maximum bandwidth for the site or link and the current Bandwidth in Use.

  • Utilization is the percentage of the maximum bandwidth currently allocated.
  • Calls is the current number of active calls on the link or site. For conference calls hosted on an MCU, each individual call leg for each participant is reported as a separate call in the Bandwidth Manager Monitor.

    As a general rule-of-thumb for planning purposes, you can assume the actual single-call one-way send bit rate is approximately 65-75% of the configured maximum call rate as defined in the policy, assuming the client utilizes a codec/resolution that matches the policy. This general rule assumes H264 video is used with ISAC audio, and takes into account transport-independence, normal call activity, and overhead, but it does not take into account other non-audio/video activity that might be taking place concurrently (although unless users are doing lots of big file downloads, this affect should be small relative to the A/V traffic). The receive bit rate will vary depending on the sender's codec/resolution, and this can also change during a conference call as the active speaker changes. For a large population of users, it should be possible to estimate with a good degree of accuracy the best maximum bandwidths and peak utilization points of any given site or link, but this exercise is beyond the scope of this documentation.

Call details

The call details give information about the specific call or call legs on a site or link such as time started, duration, and bandwidth sent or received. Note that the "Callee sent" statistic makes sense only in the context of point-to-point calls since for conference calls the callee is always the MCU, and the data sent from the MCU differs depending on the other originating call leg.

Sametime Client auto-tuning feature and its effect on allocated bandwidth

The Sametime client has an auto-tune feature that potentially reduces either frame-rate or video resolution during a call depending on the current load of the CPU on which the client is running. Overall real bandwidth consumed for a site or link may be further reduced if there are a significant number of overtaxed computers running Sametime on those sites or links. If link and site capacity seems to be consistently insufficient, the auto-tune feature may be the reason.

Holding calls and pausing videos and their effects on allocated bandwidth

When the user holds a call (or pauses video), the Sametime Bandwidth Manager retains the original bandwidth allocation for the call. Retaining the original bandwidth allocation keeps the bandwidth available when the call resumes. However, this policy results in certain calls being allocated more bandwidth than they are actually using, which is a necessary trade-off for the guarantee of being able to resume calls. When resuming a call from a prior hold, the Sametime Bandwidth Manager gets a new look at the negotiated session, which might or might not match the initial session parameters. As such, the Sametime Bandwidth Manager might fine-tune the allocated bandwidth to match the new session. The Sametime Bandwidth Manager never denies such a call, but it will never allocate more bandwidth than was previously allocated for the same call leg because initial allocations make the most conservative assumptions.

Reflector policies and their effects on allocated bandwidth

Reflectors in the topology also affect the amount of bandwidth allocated for each call that flows through reflectors. Defining a reflector on a site effectively doubles the bandwidth allocated for that site for each affected call to account for the extra hop that media traffic must take as it traverses the reflector site.

For example, assume you have the following route:

Caller site = Transit site = Receiver site

Without a reflector, the bandwidth used for a single call on each of the three sites is n. When you add a reflector on the Transit site, the allocated bandwidth is still n on the Caller and Receiver sites, but becomes 2n on the Transit site.