MediaSense supports specification-based virtualization. Under this
feature, Cisco extensively tests a number of specific hardware configurations
(known as the tested reference configurations (TRC)), and then derives a set of
specifications by which a partner or customer can select equivalent hardware
models either from Cisco or from other vendors.
configurations are divided into those that have direct attached disks (DAS) and
those that don't. For diskless servers, you must provision fiberchannel SAN.
For DAS servers, fiberchannel SAN is optional. It is important to ensure that
the selected server can support sufficient disk space to house the amount of
media storage required and that it meets the minimum disk configuration and
performance specifications cited on the virtualization wiki.
When ordering C-series servers, be sure to include either battery
backup or the Super Cap option for the write cache.
hypervisor is required. MediaSense is not designed to run on bare metal
MediaSense uses storage for two distinct purposes. One set of disks
holds the operating software and databases, and the other set is used for media
storage. The two kinds of storage have very different performance and capacity
requirements. Thin provisioning is not supported for any MediaSense disks.
Recorded Media Storage. Up to 60 terabytes is supported per
cluster, divided into 12TB in each of five servers. This is the theoretical
maximum, which could only be attained if you are using SAN storage. If you are
using Directly Attached Disks (DAS), then you are limited to the physical space
available in the server.
Uploaded Media Storage. Uploaded media requires much less
storage, but can also support up to 60 terabytes, divided into 12TB in each of
If you are using Directly Attached Disks (DAS), then the first two
disks (for operating software and database) must be configured as RAID 10.
If you are using SAN, note that only fiber-channel attached SAN is
supported, and the SAN must be selected according to Cisco's specifications for
supported SAN products (see "Cisco Unified Communications on the Cisco Unified
Computing System" at
http://www.cisco.com/go/swonly). Also, SAN storage must
be engineered to meet or exceed the disk performance specifications for each
MediaSense virtual machine. These specifications are per node. If the nodes are
sharing the same SAN, then the SAN must be engineered to support these
specifications, times the number of nodes. For security purposes, it is
permissible to use an encrypted SAN for media storage as long as the
specifications at the link below can still be met.
UCS-E router blade modules come with fixed disk hardware and
MediaSense scalability limits for each type of module are designed with their
actual performance characteristics in mind. You do not need to engineer their
disk arrays to meet the specifications above. However, all of the drives should
be manually configured as RAID-1.
Also, for these modules, the required downloadable .OVA template
automatically carves the disks into two 80GB drives and one 210GB drive,
formatted. For those modules that have additional disk space available, you may
configure the additional space for either uploaded media or recorded media as
best suits your application.
depends only on the versions of Unified CM and IOS. There is no particular
dependency on Unified CVP or Unified CCE.
deployments that include both MediaSense and Unified CVP where the two products
will be sharing the same router, the IOS version running on that router must be
one that is compatible with both products. It is important to verify this in
the compatibility matrix for each product at deployment time.
For CUBE-based forking, all
Cisco phones are supported; but for video calls only the audio portion is
For endpoint-based forking
(also known as Built-in-Bridge, or BiB forking), all Cisco phones that support
BiB technology are supported, but you must ensure there is enough bandwidth
available. BiB forking can result in up to 5 media streams :
two audio streams
involved in the conversation (in and out of the user's phone).
two audio streams sent
from the phone to the recorder (copies of the in and out streams).
one audio stream if
No Cisco phones are currently capable of forking video.
For direct recording, all
Cisco phones are supported for both audio and video media.
For outbound streaming of
uploaded videos, any Cisco phone that can handle the audio codecs shown in the
table below is supported, as long as it can also handle the video resolution of
the uploaded video (the same is true for recorded video greetings in the Unity
Connection integration). Most Cisco endpoints can automatically scale whatever
resolution they receive, but some (such as the Cisco 9971) cannot down-scale.
table is a partial list of supported devices and codecs.
streams from video calls (g.729, g.711µLaw and aLaw, g.722, AAC-LD)
(g.729, g.711µLaw and aLaw, g.722, AAC-LD)
(g.729, g.711µLaw, g.722, AAC-LD)
(at maximum 640x480 resolution)
EX-90, and SX-20.
recording, EX-60 must be configured for g.711uLaw/aLaw or g.722 due to
CSCul00473. Other devices can support AAC-LD as well. AAC-LD media forking
requires CUBE IOS 15.3(3)M1 or later.
outbound streaming, g.711aLaw is
not supported, but AAC-LD is.
series is not supported for any purpose.
Web browsers are
used for accessing the Serviceability and Administration functions on
MediaSense servers. The following browsers are supported:
Windows 7 only
Windows 7 and MacOS
When running the
Search and Play application through one of the above browsers, a minimum
version of the Java JDK or Java JRE must be installed, depending on the
underlying operating system.
Minimum Java version
JDK or JRE 7 update 25, 64-bit
JDK or JRE 7 update 25, 32-bit
only be upgraded from one immediately previous release to the next. If you are
upgrading from an earlier release, you will need to upgrade through each
intervening version first. Upgrades from releases prior to 8.5(4) are not
release contains minor changes to the MediaSense API, that are always upward
compatible—but with one exception. The exception is between release 8.5(4) and
9.0(1), in which security enhancements were introduced. Those enhancements
require that client software be modified in order to provide HTTP-BASIC
credentials and to handle a 302 redirect. This applies to all RTSP streaming
and HTTP download requests.
A new VMWare VM
template was provided in release 9.1(1) that provisions 16 GB of memory rather
than the 8 GB that was called for in release 9.0(1) and earlier. For any server
being upgraded to 9.1(1), the VM configuration must be manually adjusted to
reserve this increased amount of memory.
A new feature was
added in release 9.1(1) that permits recorded media storage to be increased in
size after installation. However, this feature is not available in systems
upgraded from prior releases; it only functions in systems that have been
fresh-installed with release 9.1(1) or later. The new uploaded media partition
introduced in release 9.1(1) is automatically created during upgrade and does
support the capability to be increased in size after installation.
If you upgrade a
MediaSense cluster from 9.0(1) to 9.1(1) or later and then wish to add nodes to
your cluster, be aware that though the new nodes will be installed with
expandable recorded media storage, Cisco does not support that flexibility.
Provision approximately the same amount of recording space on each new node as
is available on each upgraded node. Although storage space disparity across
nodes in the cluster does not present a problem for MediaSense, it could result
in pruning ahead of the configured retention period on smaller nodes.
Administrators may find this behavior unpredictable.