Cisco Cisco MediaSense Release 9.1(1) Guia Do Desenho

credentials, and to handle a 302 redirect. HTTP-BASIC credentials must now be provided with all RTSP and HTTP download requests.

A new VMWare VM template is provided in Release 9.1(1) which provisions 16 GB of memory rather than the 8 GB which was called for in
Release 9.0(1) and earlier.  For any server which is being upgraded to 9.1(1), the VM configuration must be manually adjusted to reserve that
increased amount of memory.

There is a new feature in Release 9.1(1) which permits recorded media storage to be increased in size after installation.  This feature is not
available in upgraded systems, however.  It only functions in systems that have been fresh-installed with Release 9.1(1).  The new uploaded
media partition on the other hand, also introduced in Release 9.1(1), is automatically created during upgrade, and 

 support the ability to

be increased in size after installation.

If you upgrade a Cisco MediaSense cluster from 9.0(1) to 9.1(1), and then wish to add nodes to your cluster, please be aware that, though the
new nodes will be installed with expandable recorded media storage, Cisco still recommends that you do not take advantage of that flexibility. 
The recommendation is to provision approximately the same amount of recording space on the each 

 node as was available on each 

 node.  Though storage space disparity across nodes in the cluster does not present a problem for the Cisco MediaSense product, it

upgraded
could result in pruning ahead of the configured retention period on smaller nodes, but not on the larger nodes.  Administrators may find this
behavior confusing and unpredictable.

Each rack-mounted Cisco MediaSense server supports up to 400 media streams simultaneously (200 calls), at a sustained busy hour call
arrival rate of two calls per second, on up to 12 terabytes of disk space. 400 is a total of all streams used for recording, live monitoring,
playback, MP4 conversion, and HTTP download, all of which may occur in any combination.  The latter two activities are of course, not strictly
speaking streaming activities, but they do use system resources in a similar way and are considered to have equal weight.  Playback of video
track takes about 9 times the resources of an audio track.  As a result, each uploaded video playback (one video track + one audio track) has
the weight of 10 audio tracks, leading to a maximum capacity of 40 simultaneous video playbacks per node.

Each SRE-based Cisco MediaSense server supports up to 60 media streams (30 calls), at an average arrival rate of 20 calls per minute, with
a fixed recording disk space of 200 gigabytes.

In determining how many streams are in use at any given time, you will need to predict the number of onsets for each activity per unit time, as
well as their durations. Recording, live monitoring and playback of course have a duration which is equal to the length of the recording.  Video
playbacks, if configured to play once only have a duration equal to the length of the video.  Video playbacks for Hold purposes must be
estimated to last as long as such video callers typically remain on Hold.  MP4 conversions and HTTP download durations can be safely
estimated to be about 5 seconds per minute of recording.

Essentially, to determine the number of servers required, one would simply evaluate:

the number simultaneous audio streams needed, plus 10 times the number of videos being played, divided by 400 (for rack-mount
servers), or 60 (for SRE modules);
the number of busy hour call arrivals per second divided by two; and
the space required for retained recording sessions divided by 12 terabytes (for rack-mount servers) or 210 gigabytes (for SRE
modules)

The number of servers required is equal to whichever of the above is greater, rounded up.

Another factor which significantly impacts performance is the number of Cisco MediaSense API requests in progress.  This is limited to 15 at a
time (3 at a time for SRE modules), with the ability to queue up to 10 more (or 3 more for SRE modules).  These numbers are per node, but
they can be doubled for Cisco MediaSense clusters which contain both a Primary and a Secondary node.

Cisco MediaSense does not enforce these limits, with the exception of the number of concurrent API requests.  It does however enforce a
higher set of limits in order to protect itself from overload conditions which could affect its ability to perform vital functions. See "System
Resiliency and Overload Throttling" above for more information.

The media output operations -- monitoring, playback and HTTP download -- are entirely under client control. The client should be able to
enforce its own limits in these areas. The remaining operations, call recording and uploaded media file playback, are not under client control. 
However, the deployment can be sized such that the overall recording and video playback load will not exceed a desired maximum
cluster-wide (leaving room for an enforceable number of monitoring, playback and HTTP download operations).  It can be assumed that the
recording and video playback load will be balanced across all servers.  (Perfect balance will not always be achieved, but each server has
enough headroom to accommodate most disparities.) 

When Cisco MediaSense nodes start up, they adjust their capacity expectations according to the hardware resources they discover from the
underlying virtual machine.  The following table indicates the relationship between virtual machine resources and supported capacities.  The
table presents information on a per-node basis.  When the server is installed using one of the Cisco-provided OVA templates, the correct
amount of CPU and memory are automatically provisioned, and either the "Standard" or "SRE" profile will be selected from the table below.  If
an incorrect OVA template is used, or if the virtual machine's configuration is changed after the OVA template is applied such that the virtual