-
Cisco MediaSense Solution Reference Network Design Guide, Release 10.0(1)
-
Product overview
-
Characteristics and features
-
Codecs supported
-
Metadata database and the MediaSense API
-
Disk space management
-
System resiliency and overload throttling
-
MediaSense-specific deployment models
-
Solution environment
-
High availability
-
Security
-
Reporting and call correlation
-
Serviceability and administration
-
Design guidance
-
Compatibility matrix
-
Scalability and sizing
-
Index
-
Feedback
Contents
Compatibility matrix
This section describes (in general terms) versions, model numbers, and specifications of components that MediaSense is compatible with.
For the up-to-date specifics, see the following wiki locations:
- Server platforms
- Hypervisor
- Storage
- Other solution component versions
- Phones
- Web browsers
- MediaSense upgrades
Server platforms
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.
There are differences in the level of support that Cisco TAC provides for different hardware solutions. For more information, seehttp://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware.
A detailed list of TRC models and supported server specifications can be found at http://docwiki.cisco.com/wiki/Virtualization_for_Cisco_MediaSense . Other than the TRC models that are manufactured by Cisco, only Hewlett Packard (HP) and IBM servers are supported (subject to the stated minimum performance specifications).
Server 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
A VMWare hypervisor is required. MediaSense is not designed to run on bare metal hardware.
For a list of supported hypervisors, see http://docwiki.cisco.com/wiki/Cisco_MediaSense_Compatibility_Matrix.
Storage
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 five servers.
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.
For information about current disk performance specifications for MediaSense, see http://docwiki.cisco.com/wiki/Virtualization_for_Cisco_MediaSense.
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.
Other solution component versions
MediaSense depends only on the versions of Unified CM and IOS. There is no particular dependency on Unified CVP or Unified CCE.
However, for 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 current compatibility matrix information about MediaSense, see http://docwiki.cisco.com/wiki/Cisco_MediaSense_Compatibility_Matrix.
Phones
- For CUBE-based forking, all Cisco phones are supported; but for video calls only the audio portion is recorded.
- 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 silent monitoring.
Note
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.
The following table is a partial list of supported devices and codecs.
Endpoint category Endpoint forking CUBE forking Direct recording Outbound streaming for ViQ and VoH Unity Connection video greetings Models tested and verified Audio hard phones Audio (g.729, g.711µLaw and aLaw, g.722)
Audio (g.729, g.711µLaw and aLaw, g.722)
Audio (g.729, g.711µLaw and aLaw, g.722)
Audio (g.729, g.711µLaw, g.722)
Not applicable.
All Cisco phones that support BiB.
An up to date list may be found under "Unified Communications Manager Silent Monitoring Recording Supported Device Matrix" at http://developer.cisco.com/web/sip/wikidocs.
Cisco IP Communicator (CIPC) Audio (g.729, g.711µLaw and aLaw, g.722)
Audio (g.729, g.711µLaw and aLaw, g.722)
Audio streams from video calls (g.729, g.711µLaw and aLaw, g.722)
Audio (g.729, g.711µLaw and aLaw, g.722)
Video
Audio (g.729, g.711µLaw, g.722)
Video
Not applicable.
Cisco IP Communicator (CIPC) v7.0(1) or later.
Cisco Jabber Audio (g.711µLaw and aLaw)
Audio (g.711µLaw)
Audio (g.711µLaw)
Video
Audio (g.711µLaw)
Video
Audio (g.711µLaw)
Video (at maximum 640x480 resolution)
Cisco Jabber for Windows, Mac and iPad.
Video-capable phones Audio (g.729, g.711µLaw and aLaw, g.722)
Audio (g.729, g.711µLaw and aLaw, g.722)
Audio streams from video calls (g.729, g.711µLaw and aLaw, g.722)
Audio (g.729, g.711µLaw and aLaw, g.722)
Video
Audio (g.729, g.711µLaw, g.722)
Video
Audio (g.711µLaw)
Video (at maximum 640x480 resolution)
9971, 9951 and 7985.
Video greeting only works with Cisco 9971 (or similar) phones using g.711 (uLaw or aLaw) and with h.264.
See http://www.cisco.com/en/US/docs/voice_ip_comm/connection/10x/design/guide/ 10xcucdg070.html for a detailed list of supported phones.
Telepresence endpoints Not supported
Audio (g.729, g.711µLaw and aLaw, g.722, AAC-LD)
Audio streams from video calls (g.729, g.711µLaw and aLaw, g.722, AAC-LD)
Audio (g.729, g.711µLaw and aLaw, g.722, AAC-LD)
Video
Audio (g.729, g.711µLaw, g.722, AAC-LD)
Video
Audio (g.711µLaw)
Video (at maximum 640x480 resolution)
EX-60, EX-90, and SX-20.
For 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.
For outbound streaming, g.711aLaw is not supported, but AAC-LD is.
CTS series is not supported for any purpose.
Web browsers
Web browsers are used for accessing the Serviceability and Administration functions on MediaSense servers. The following browsers are supported:
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.
MediaSense upgrades
MediaSense can 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 supported.
Each successive 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.
