Explore Cisco
How to Buy

Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

Cisco MediaSense User Guide, Release 10.5(1)_SU1

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco MediaSense User Guide, Release 10.5(1)_SU1

Chapter Title

MediaSense Overview

Results

Updated:
November 30, 2017

Chapter: MediaSense Overview

MediaSense Overview

About MediaSense

MediaSense is the media-capture platform for Cisco Unified Communications. It can be used to record calls in Cisco and non-Cisco contact centers; however, non-Cisco contact centers must use Cisco Unified Border Element as the ingress point.

MediaSense can be used by compliance recording companies whose regulatory environment requires all sessions to be recorded and maintained. These recordings can later be used by a compliance auditor or a contact center supervisor to resolve customer issues or for training purposes. The recordings can also be used by speech analytics servers or transcription engines.

MediaSense uses Unified Communications Manager to provide user-authentication services. It uses Web 2.0 application programming interfaces (APIs) to expose its functionality to third-party customers to enable them to create custom applications. The product is supported on Microsoft Windows 7 and the Apple Mac OS.

Network Services

You can use the following network services with MediaSense:

  • Cisco MediaSense Administration— Enables you to configure MediaSense using a graphical user interface.
  • Cisco MediaSense Serviceability Administration— Enables you to configure the MediaSense Serviceability application using a graphical user interface.
  • System Service— Enables you to control service operations within the MediaSense clusters. This service manages the clustering and setup functionality for the secondary server and expansion servers.
  • Perfmon Agent— Enables you to control the performance monitoring infrastructure within the MediaSense Serviceability Administration interface. The Java Management Extensions (JMX) technology, which allows you to manage and monitor applications and other system objects, is represented by objects called Managed Beans (MBeans). The Perfmon Agent retrieves the counter values from the JMX MBeans and writes them to the Unified Communications Manager database.
  • Diagnostics Service— Enables you to troubleshoot and debug MediaSense. This service is available in all MediaSense servers.

In the MediaSense and Unified OS user interfaces, each MediaSense service name is preceded by the product name. To avoid redundancy in this document, service names are sometimes referred to without the preceding product name.

Network services are started automatically after installation in each server in the cluster. If advised to do so by Cisco support personnel, network services can be stopped.

Feature Services

MediaSense contains the following feature services:

  • Configuration Service— Saves and updates all changes made to the MediaSense configuration database. Each multiple-server cluster can have only two instances of the configuration service, one instance is in the primary server and the other instance is in the secondary server. If a cluster has more than two servers, the expansion servers cannot have a configuration service.

  • API Service— Processes API requests and enables communication between the user interface and the server. You can enable the API service only after the database service is enabled. Each multiple-server cluster can have only two instances of the API service, one instance is in the primary server and the other instance is in the secondary server. If a cluster has more than two servers, the expansion servers do not have an API service.

  • Database Service— Contains and controls the meta database and the configuration database. Each multiple-server cluster can only have two instances of the database service, one instance is in the primary server and the other instance is in the secondary server. Each server writes data only to its local database. The primary and secondary servers interact to synchronize data.

  • Storage Management Agent (SM agent)— Monitors the overall storage in each server in the cluster and generates threshold events based on disk usage. This service is available in all servers and should be activated before the media service and call control service.

  • Media Service— Receives, saves, and plays back media. The media service must be enabled before the call control service. This service is available in all servers in the cluster.

  • Call Control Service— Coordinates call receiving and recording. The call control service can only be enabled if the media service is already enabled. This service is available in all servers in the cluster. The call control service is referred to as a SIP trunk in the Unified Communications Manager user interface and Unified Communications Manager documentation.

All feature services are installed on the primary and secondary nodes (servers) in a cluster. Expansion nodes have only the media service, call control service, and SM agent.

Search and Play

After MediaSense is installed and configured, use the Search and Play application to search for specific media files, play them, or download them to your desktop.

To access the Search and Play application, do one of the following:

  • Use a Mozilla Firefox or Windows Internet Explorer browser to go to https://<hostname>:8440/mediasense.

    or

  • Click the Cisco MediaSense Search and Play link from the main MediaSense access window at http://<MediaSense hostname>.


Note

Before launching Search and Play, you need to install the 32-bit version of JDK on a 32-bit Windows machine, the 64-bit version of JDK on 64-bit Windows machine, and the 64-bit version on Mac computers. Also, ensure that you have JDK7 update 25 or later installed.

The MediaSense media player is implemented as a downloadable Java application. Due to recent security enhancements in Java, users have to accept a pop-up security warning every time the Java application is executed; meaning that users must accept a security warning every time a recording is played.

Because the application does not run as part of the browser executable, it is subject to the security requirements of the Java Virtual Machine (JVM) that is installed on the user's computer (rather than those of the browser). A troubleshooting tip provides instructions for setting up each client desktop where Search and Play is executed to avoid the warning (http:/​/​docwiki.cisco.com/​wiki/​Administration:_​Search_​and_​Play_​application_​users_​encounter_​security_​warning_​before_​each_​playback#Search_​and_​Play_​application_​users_​encounter_​security_​warning_​before_​each_​playback).


Note
The media player takes longer to start in Windows Internet Explorer than in Mozilla Firefox. Windows Internet Explorer users may also see an option to open a downloaded jnlp file.

When prompted for login credentials, use the API user credentials defined on the MediaSense API User Configuration page of the Administration application.


Note
You are logged out from the Search and Play application if the session remains idle for 30 minutes.

Search For, Play, or Download a Recorded Call

There are multiple ways to search for the recorded media files in the Search and Play window.

Procedure
    Step 1   When you first access the Search and Play application, the page opens to the Recent Calls default search results (all calls within last 7 days). You may select the Recent Calls or Active Calls searches by clicking those tabs at any time.
    Step 2   For a simple search, enter either a participant identifier or a tag in the search box and click Search.

    For participant ID, enter the complete value of the identifier. To search for multiple participants, use a space to separate each entry; the delimiter is considered as an OR operator.

    For tags, you can enter one or two letters because a complete value is not required. For more information, refer to Tags in Advanced Search (Step 3).

    Use a space to separate each entry; the delimiter is considered as an OR operator. By default, the simple search returns calls within the last 7 days.

    Step 3   For an advanced search, enter values in any of the search parameters from the Search Recordings drop-down menu.

    The search properties include:

    • Session ID—The identifier of a recording session with one or more tracks associated with it. Enter a session identifier in the text box. Only one Session ID can be searched at a time.

    • Participant(s)—The identifier for recording session participants, which is a phone extension. Enter a participant identifier in the text box. Multiple participants can be searched by separating the identifiers with a comma. When multiple participants are defined, the search returns only those calls containing all of the participants (the delimiter is treated as an AND operator).

    • Tag—Enter any text. Searches for tags are treated as CONTAINS, so entering a single letter results in all tags that contain that letter. Spaces used in the search box are considered part of the value being searched, not as a delimiter. Therefore, searching for two words separated by a space returns only those calls with a tag containing both words separated by a space.

    • XRefCI—The recording session identifier. Enter a recording session identifier in the text box. Only one XRefCI can be searched at a time.

    • CCID—The identifier of an individual track within a recording session. Enter a track identifier in the text box. Only one CCID can be searched at a time.

    • Range—The date the recording session started. Select to search Within a specific time frame or Between a range of dates. If no time frame is selected, the system defaults to within the last 7 days.

      When selecting a range of times, choose short time periods. Searches that result in large numbers of recordings may take an exceptionally long time to process and impacts system performance.

    • Duration—Select a time unit, then use the slide bar to select the interval amount for the recorded session in seconds, minutes, or hours.

    • Show—Use the check boxes to indicate if you want to search for completed calls, active calls, or calls with recording errors.

    Step 4   Click Search.

    • Click the Sort by drop-down menu to sort the files by age or duration.

    • Click the download icon to download a recording.

    • Click the Expand Call icon to view the strongly associated recording sessions displayed in the Associated Session box. Strongly associated sessions have at least one common xRefci value. Each session in the displayed list can be individually played or downloaded.

      Note    MediaSense 10.5 supports call association for the Built-in-Bridge recordings.

    • Click the play icon to play a recording.

    • Users can select the number of results to display on each page and step through the result pages using the Previous and Next buttons.

    Note   

    When exiting the media player, users may receive a warning stating "MediaSense player quit unexpectedly while using the lib... plug-in". This warning may be reported as an error, but it is not an error and can be disregarded.

    Media Player

    MediaSense has a built-in media player in the Search and Play application to play a recording. To run the media player, you should have the updated Java version (For Java version, refer the "Web Browsers" section in the Cisco MediaSense Design Guide at http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​mediasense/​products-implementation-design-guides-list.html. The track slider displays the progress of the audio recordings. The slider can be dragged to the right to forward or to the left to rewind the recording being played.

    When a recording finishes, and you want to replay it, drag the slider back to the starting point, however, it should be done in less than 30 seconds. After 30 seconds, the playback session ends and the player get closed.


    Note

    For video recordings, the track slider is not supported. However, the timer is displayed to view the progress of the video recordings.

    You can increase and decrease the volume by dragging the slider on the Volume bar.

    Limitations of the media player:

    • Time is not displayed while you drag the slider for rewind or forward.
    • Pause button does not automatically convert to the Play button after a recording ends.
    • Media Player session gets aborted if the Play and Pause button is clicked more than twice after the slider reached the end of the playback stream.
    • During a playback session, when you click any point to rewind or forward, the track slider moves near the clicked point, but not on the exact point.

    In-Browser Playback

    MediaSense has an in-browser playback that uses the HTML5 playback feature of the browser to play back a recording. The in-browser player converts a recording into mp4 format irrespective of its original format. It has play, pause, and volume controls and displays the progress of the recording being played. In-browser playback does not require you to download the recording or manage any security certificate issues, which is an advantage over the built-in Java media player used for playback.

    The other recording playback alternative, using a Java download, requires you to download the recording and has security certificate issues. By default, MediaSense uses the Java media player for playback.


    Note

    MediaSense supports in-browser player on Internet Explorer 9 and 11, and Mozilla Firefox version 24 and later.

    To enable in-browser playback, you need to configure the settings in the Search and Play Configuration window in Cisco MediaSense Administration. For more information, see Search and Play Configuration.

    Currently, in-browser playback is supported for stored audio calls only. The video recordings are played back on the media player irrespective of the configurations being saved in the Search and Play Configuration window.


    Note

    To run the in-browser player on Internet Explorer and Mozilla Firefox, MediaSense server must have a self-signed certificate added to the trusted root certification authority of the browser.

    Finesse AgentInfo Gadget

    Finesse AgentInfo gadget conveys agent information from Finesse to MediaSense, which includes login ID, login name, first name, and last name. The information is linked with all the calls in which the agent is involved. In MediaSense, getSessions API calls having the agent information use the gadget. The gadget is deployed on the Finesse Agent desktop and can be hosted on both primary and secondary MediaSense nodes, however, not simultaneously. To deploy the gadget on Finesse Agent desktop, refer Deployment of Finesse AgentInfo Gadget on Finesse.

    When an agent signs in to the Finesse desktop with valid Finesse credentials, the gadget signs in to the MediaSense server.


    Note

    In case of gadget sign-in failures, the gadget retries every three minutes indefinitely. Sign-in is reattempted for all the failure cases except for the sign-in with invalid credentials.

    The gadget is present on the agent's desktop as a title and a frame. However, it performs a number of functions that are invisible to the agent.

    • START action

      When an agent signs in, the gadget sends the following parameters information to MediaSense, which it uses to associate specific agent information to their individual recordings.

      • extension

      • event(Start)

      • stateChangeTime

      • FirstName

      • LastName

      • LoginID

      • LoginName

    • KEEPALIVE action

      The gadget sends MediaSense a keepalive message every three minutes.

    • STOP action

      The gadget sends agent information to MediaSense when an agent signs out, which includes login Id and extension.

    As a result of these actions, MediaSense knows about the agents' details and their login extensions as well as keeping track of the time the agent signs in and out. This also helps MediaSense to keep its data accurate, even in case of a browser failure.

    Deployment of Finesse AgentInfo Gadget on Finesse

    To deploy AgentInfo gadget on Finesse, perform the following tasks:

    Procedure
      Step 1   Log in to Cisco Finesse Administration with valid credentials.

      The Cisco Finesse Administration window appears.
      Step 2   Click the Desktop Layout tab.

      The Manage Desktop Layout window appears.
      Step 3   In the Finesse Layout XML section, add the gadget tag within the layout xml.

      The gadget tag has the xml file path of the gadget.

      For example: <gadget>https://<Host>:<Port>/ora/gadget_agentInfo/MSAgentInfoGadget.xml</gadget>

      Note   

      In Mediasense, you can access an API using https on Port 8440.

      Step 4   The AgentInfo gadget gets added to the Finesse desktop.

      Note    The gadget can be hosted on either primary or secondary MediaSense, but not both as it will lead to having two gadgets on Finesse desktop.

      Architecture

      MediaSense is part of the Unified Communications solution and runs on Cisco Unified Operating System.

      MediaSense architecture contains the following components:

      • Application layer:

        • The Search and Play application allows you to play back recordings.

        • APIs support real-time recording controls (such as hold, pause, and resume) for third-party applications.

        • Application and media APIs incorporate requirements from various industry partners and are published for use by third-party applications.

        • The API Service provides web service interfaces to enable applications to search for and retrieve recordings and associated session history and metadata. This metadata information is stored in the meta database.

      • Media Processing layer:

        • The media service terminates media streams to be stored on a local disk for archiving and playback.

        • Running media service on all the servers in a deployment allows for load balancing.

      • Network layer:

        • Gateway and session border controller (SBC) media forking and media forking at endpoints.

        • Integration with Cisco Unified Communications Manager (Unified Communications Manager) for audio recording.

        • Integration with Cisco Unified Border Element (Unified Border Element) for audio and video recording.

      Cisco Unified Communications Manager Network-based Recording

      With Unified Communications Manager network-based recording (NBR), you can use a gateway to record calls. NBR allows the Unified Communications Manager to route recording calls, regardless of device, location, or geography.

      With NBR, call recording media can be sourced from either the IP phone or from a gateway that is connected to the Unified Communications Manager over a SIP trunk. Unified Communications Manager dynamically selects the right media source based on the call flow and call participants.

      NBR offers an automatic fallback to Built-in-Bridge (BiB) when the Integrated Services Routers (ISR) are unavailable because no separate recording configuration is required. This fallback is useful in cases where customers want to include agent-agent consult calls in the recording policies because Unified Border Element cannot record consult calls, so BiB needs to be enabled separately.

      For more information on Unified Communications Manager NBR, refer to the Features and Services Guide for Cisco Unified Communications Manager.

      Call Correlation

      Both NBR and BiB calls can be correlated using xRefci, which is available from Unified Communications Manager JTAPI. CISCO-GUID is not required, which means that neither the CTI server nor CTIOS connections are required. Because there is a single correlation identifier, correlation across components is stronger and can be done in a uniform way independent of the call flow. Using NBR, directly-dialed as well as dialer-initiated outbound calls can be correlated with their appearance in other solution components. Using NBR, TDM gateway recording is automatically used without splitting the capacity of the router.


      Note
      MediaSense supports TDM gateway recording.

      Unified Communications Manager Deployments

      Unified Communications Manager must be configured appropriately to direct recordings to MediaSense recording servers. The configuration includes setting a recording profile and various SIP parameters. Because MediaSense uses the Administrative XML layer (AXL) to authenticate users, the Unified Communications Manager AXL service also must be enabled on at least one of its servers.

      A basic Unified Communications Manager deployment for MediaSense requires one of the phones to be configured for recording. If both phones are configured for recording, two separate recording sessions are captured. Media forked by a phone is sent to the recording device where the forked streams are captured. See the Cisco MediaSense Design Guide at http:/​/​www.cisco.com/​en/​US/​products/​ps11389/​products_​implementation_​design_​guides_​list.html for further details.

      All Cisco IP Phones that MediaSense supports have a built-in-bridge (BiB) that allows incoming and outgoing media streams to be forked. MediaSense makes use of this capability to record inbound and outbound forked media. For more details about media forking, see the Unified Communications Manager documentation at http:/​/​www.cisco.com/​en/​US/​products/​sw/​voicesw/​ps556/​prod_​maintenance_​guides_​list.html.

      Cisco Unified Border Element Deployments

      Cisco Unified Border Element (Unified Border Element) is the Cisco session border controller (SBC) gateway that facilitates connectivity between independent VoIP networks by enabling SIP, H.323, VoIP, and video conference calls from one IP network to another.

      MediaSense integrates with Unified Border Element to enable recording without regard to the endpoint type. Because of this capability, MediaSense can use Unified Border Element to record inbound and outbound media.

      See the Unified Border Element documentation for more information about Unified Border Element.

      The following figure illustrates a MediaSense deployment with Unified Border Element. Even in a Unified Border Element deployment, MediaSense depends on Unified Communications Manager to provide authentication services.

      Figure 1. MediaSense Deployment with Unified Border Element



      In the preceding illustration, the Real-Time Protocol (RTP) carries voice data between the endpoints and Unified Border Element. The Session Initiation Protocol (SIP) carries call signaling information between the endpoints and Unified Border Element. Two RTP unidirectional streams represent two audio streams forked from Unified Border Element to MediaSense. Streams from Unified Border Element to MediaSense are unidirectional because only Unified Border Element sends data to MediaSense; MediaSense does not send any media to Unified Border Element. Unified Border Element has three dial-peers: inbound, outbound, and forking. (See Dial-Peer Level Setup for more information.)

      Typically, Unified Border Element can fork only SIP-to-SIP calls. However, because you can use the same Cisco router as both a TDM-to-IP gateway and a media-forking device for call recording, you can also record incoming TDM or analog calls if you have the required licensing and an appropriate Cisco IOS version. (For more information, see the Unified Border Element documentation.)

      To use this feature, you must enable both gateway and border-element functionality in the device. You can configure the gateway to receive the TDM or analog call and then feed the call back to itself as a SIP call with a different dialed number. When you configure this loop, the router actually handles each call twice. (This feature cuts the router capacity in half and Unified Border Element can process only half as many calls.) For more information, see the "Media Forking on a TDM Gateway" section in the Cisco MediaSense Developer Guide and the MediaSense FAQ article at http:/​/​docwiki.cisco.com/​wiki/​FAQs_​for_​Cisco_​MediaSense#How_​to_​Configure_​a_​TDM_​Gateway_​for_​Media_​Forking.

      Cisco Unified Communications Manager and Cisco Unified Border Element Scenario Differences

      Unified Communications Manager is used to set up the recording profile and call control service connection (SIP trunk) with MediaSense. Similarly, with Unified Border Element, the dial-peers and media class settings determine communication with MediaSense.


      Note
      See the Cisco MediaSense Design Guide for further details about Unified Border Element media forking and UC endpoints media forking.

      Regardless of whether MediaSense is deployed with Unified Communications Manager or Unified Border Element, the events, response codes, and parameter definitions are the same for both scenarios. All events, response codes, and parameters are explained in detail in the Cisco MediaSense Developer Guide.



      Table 1 Unified Communications Manager and Unified Border Element Scenario Differences

      MediaSense Feature

      With Unified Communications Manager (Built-in-Bridge or Network-based Recording)

      With Unified Border Element Dial Peer

      Initiating recordings

      The direct outbound recording scenario, which is initiated when a client calls the startRecording API, is supported with Unified Communications Manager deployments.

      The direct outbound recording scenario, which is initiated when a client calls the startRecording API, is not supported with Unified Border Element deployments.

      Recording

      Two media streams are sent to MediaSense (called Track 0 and Track 1). Recording requires two phones with at least one phone configured for media-forking capabilities (two SIP invitations).

      Recording uses SIP devices (referred to as SIP User Agent in Unified Border Element). As long as the call is processed by Unified Border Element as a SIP call, the endpoint can be of any type. Two media streams are sent to MediaSense. These two streams ultimately result in two tracks without any differentiation for Track 0 and Track 1.

      Identifying tracks for calling versus called party

      See the FAQs for MediaSense website (How do you determine which track has the calling and which has the called party?).

      The numerically smaller xRefCi parameter usually refers to the track of the calling party.

      Track 0 contains the media stream corresponding to the dial-peer in which the media recording profile is configured.

      Recording session

      See the Cisco MediaSense Developer Guide for details about recording sessions and hold/resume, pause/resume, transfer/conference commands.

      If a call is placed on hold, the logical recording session is terminated. When a participant resumes the call, a new recording session is created.

      The SIP Session may be updated multiple times with corresponding media track events. There is only one recording session even if the call is placed on hold and resumed multiple times.

      Differences in the captured recording data

      See the Cisco MediaSense Design Guide.

      To obtain information such as the original calling number, called number, and type of call, see the Call Detail Records section in the Unified Communications Manager Administration Guide.

      Unified Border Element can store calls in an external database known as AAA - RADIUS. Calls can be searched by Cisco-GUID, which corresponds to the CCID in the MediaSense session data.

      Mid-call codec change

      Does not generate mid-call codec changes.

      A new session starts.

      Endpoint MAC address

      Captured.

      Not captured.

      Recording media source

      The endpoints provides the forked media.

      Unified Border Element provides the forked media.

      Supported Deployments

      MediaSense supports the following deployments:

      • One-Server Deployment— One active server.

      • Two-Server Deployment— Two active servers providing high availability.

      • Three-Server Deployment— Two active servers providing high availability and one expansion server to provide additional recording capacity.

      • Four-Server Deployment— Two active servers providing high availability and two expansion servers to provide additional recording capacity.

      • Five-Server Deployment— Two active servers providing high availability and three expansion servers to provide additional recording capacity.


      Note

      UCS-E installations and all installations with fewer than 7 vCPUs are limited to one-server and two-server deployments.

      In all the deployments, the installation and configuration of the primary server differs from the installation and configuration of the other servers in the same deployment. If you are configuring any server in a MediaSense deployment, be aware that the platform administrator configures the MediaSense application administrator username and password (in addition to the platform and security password). See Install MediaSense and Unified OS for further details.


      Note
      The application administrator username and password must be the same on all servers in a MediaSense deployment. You can reset the application administrator username and password using the following CLI commands:
      • utils reset_application_ui_administrator_name
      • utils reset_application_ui_administrator_password.

      MediaSense Cluster Deployments

      In a MediaSense deployment, a cluster contains a set of servers with each server containing a set of services. Cluster architecture provides high availability (for recording but not for playback) and failover (if the primary server fails, there is automatic failover to the secondary server).

      MediaSense functions only within local area networks (LAN). Wide area networks (WAN) are not supported. All MediaSense servers and Unified Communications Manager servers must be located in the same LAN. Within a LAN, the maximum round-trip delay between any two servers must be less than 2 milliseconds.

      The primary and secondary servers in a MediaSense deployment are synchronized when administrative changes are made on either server. Database replication copies the data automatically from the primary server to the secondary server, and vice versa.

      The following cluster deployment rules are enforced by the installation and configuration procedures:

      • All servers in the same cluster must run the same version of MediaSense.

      • A MediaSense deployment can consist of one to five MediaSense servers. Each server in a cluster must always have a call control service, media service, and an SM agent.

      • MediaSense supports any of the following combinations of servers:
        • One primary server
        • One primary server and one expansion server
        • One primary, one secondary server, and from one to three expansion servers

      • UCS-E installations and all installations with fewer than 7 vCPUs are limited to one-server and two-server deployments.

      Single-Server Deployments

      A single-server deployment has one MediaSense server on the Unified Communications OS platform. All network services are enabled by default.

      In single-server deployments, the primary server has the following feature services:

      • API service

      • Configuration service

      • Call control service

      • Media service

      • Database service

      • SM agent

      Figure 2. Cisco MediaSense Single-Server Deployment



      Single-service deployments enable you to add more servers later to address redundancy issues, to provide high availability, to increase storage capacity, and to increase simultaneous recording capacity. For more information on deployment models, refer to the Cisco MediaSense Design Guide.

      Dual-Server Deployments

      A dual-server deployment has two MediaSense servers on the Unified Communications OS (Unified OS) platform. The first server is called the primary server. The second server is called the secondary server. All network services are enabled on both servers.

      Both primary and secondary servers have the following feature services:

      • API service

      • Configuration service

      • Call control service

      • Media service

      • Database service

      • Storage Management agent (SM agent )

      Figure 3. Dual-Server Deployment. Dual-server deployments provide high availability. The recording load is automatically balanced across the primary and secondary servers because all services are always active on both servers.




      Note

      MediaSense does not provide automatic load balancing in the API service or the configuration service. When both of those services are enabled on the primary and secondary servers, you must point your browser or server-based API to one of these services.

      See the Cisco MediaSense Design Guide for details about the maximum number of simultaneous recordings, playback, and monitoring sessions that are supported.

      Three-Server Deployments

      Three-server deployments have a primary server, a secondary server, and one expansion server. All network services are enabled by default on all servers in the cluster.

      The primary server and the secondary server have the following feature services:

      • API service

      • Configuration service

      • Call control service

      • Media service

      • Database service

      • SM agent

      The expansion server has the following feature services:

      • Call control service

      • Media service

      • SM agent

      Figure 4. Three-Server Deployment. The three-server model provides redundancy and increases storage capacity and simultaneous recording and playback capacity. The recording load is automatically balanced across the servers because services are always active on their respective servers.




      Note
      MediaSense does not provide automatic load balancing in the API service and Configuration service on the primary and secondary servers. While those services are enabled, you must point your browser or server-based API to only one of these services.

      See the Cisco MediaSense Design Guide for details about the maximum number of simultaneous recording sessions, playback sessions, and monitoring sessions that are supported.

      Four-Server and Five-Server Deployments

      Four-server and five-server deployments have one primary server, one secondary server, and two or three expansion servers. All network services are enabled by default on all servers in the cluster.

      Primary servers and secondary servers have the following feature services:

      • API service

      • Configuration service

      • Call control service

      • Media service

      • Database service

      • SM agent

      The remaining servers, called expansion servers, only have the following feature services:

      • Call control service

      • Media service

      • SM agent

      Figure 5. Five-Server Deployment. This deployment model provides redundancy, increases storage capacity, and increases capacity for simultaneous recording and playback sessions. The recording load is automatically balanced across the servers because services are always active on their respective servers.




      Note

      MediaSense does not provide automatic load balancing in the API service and Configuration service on the primary and secondary servers. While those services are enabled, you must point your browser or server-based API to only one of these services.

      See the http:/​/​www.cisco.com/​c/​en/​us/​td/​docs/​voice_ip_comm/​cust_contact/​contact_center/​mediasense/​105/​Design_Guide/​CUMS_​BK_​MC36D963_​00_​mediasense-srnd_​10-5.html for details about the maximum number of simultaneous recording sessions, playback sessions, and monitoring sessions that are supported.

      MediaSense High Availability Deployments

      Some deployments require that all available media is recorded. A call control service failure may result in no recordings unless your deployment supports high availability. If Unified Communications Manager cannot contact one of the MediaSense servers, you must ensure that an alternate server is available for Unified Communications Manager or Unified Border Element to make the required connection.

      For more information, see the Cisco MediaSense Design Guide.

      Data Replication Considerations

      Database high availability support in MediaSense deployments is provided using Informix enterprise replication (ER) for both the meta database and configuration database. While a MediaSense cluster can have up to five servers, data replication is enabled only between the primary and secondary servers.

      At installation time, if the server you are installing is identified as the secondary server, the following considerations apply:

      • This server automatically applies the on-tape backup from the primary server without any constraints on the data size in the primary server.
      • Data replication is performed between the primary and secondary servers. Data written to the primary server is also replicated to the secondary server, and vice versa.

      The replication operation between the primary and secondary MediaSense servers differs based on the time of replication:

      • Activation time— During the service activation process, Informix ER automatically begins replication between the primary and secondary servers. The differential data between both servers are replicated from the primary server to the secondary server.
      • Run time— During run time, data replication is bidirectional. If, for any reason, one of the MediaSense servers is shut down or in a failed state, data continues to be written to the surviving server. When the shut down or failed server is revived, Informix ER automatically restarts between the two servers and synchronizes the data. Depending on the data size, synchronization time may vary. Retention period refers to the number of days that data can be stored on the surviving server without breaking the replication. See the Cisco MediaSense Design Guide.

      Data Replication and Recovery for Primary or Secondary Node

      If either the primary or secondary server goes out of service, the database replication process proceeds as follows:

      • MediaSense continues to write data to the recording database. Because the data cannot be replicated to the out of service node, Informix stores the data in the ora_ersb replication buffer on the node that is still working. If the node that is out of service comes back up before ora_ersb is full, replication is automatically restored and the data in ora_ersb is synchronized between both nodes.

      • If one node is out of service for an extended period, the ora_ersb buffer on the working node may fill up. If ora_ersb reaches 90 percent of its capacity, the system automatically stops replication on the working node (which then acts like a single node). The system does this to prevent ora_ersb from getting too full and the system from becoming dysfunctional.

      • If replication is stopped on the working node, it is automatically restored after the out-of-service node comes back into service. User intervention is not required. After replication is restored, data sync jobs are launched to compare both the meta data and the configuration data on both nodes and to synchronize this data.

      You can check the data sync job status by running the following CLI command on either one of the nodes:

      show db_synchronization status [db_ora_meta|db_ora_config]

      Deployment Considerations for High Availability

      Follow these guidelines to ensure a high availability deployment and to provide data replication:

      • Verify that the API service is enabled and running. The API service monitors its internal performance to provide overload protection. If an overload condition is detected, the API service may begin to automatically reject third-party requests. Client applications should be able to retry requests on the alternate API service if they receive rejections.
      • A deployment can contain up to five possible call control services in the cluster.

      The following table identifies the possible MediaSense high-availability scenarios.

      MediaSense Scenarios

      With Unified Communications Manager (Built-in-Bridge or Network-based Recording)

      With Unified Border Element Dial Peer Recording

      Normal scenario

      The Unified Communications Manager uses a round-robin method to reach an available call control service to place an outbound call and times out if it is still unsuccessful after attempting to reach the last call control service.

      Unified Border Element always sends a call to the first MediaSense server in the media-recording list.

      Failed server scenario

      Unified Communications Manager uses the next available MediaSense server in the list.

      Unified Border Element uses the next available MediaSense server in the media-recording list.

      Failure Condition Considerations

      If a MediaSense primary or secondary server fails for any reason, the surviving server continues to write meta data to the meta database and to the MediaSense Enterprise Replication Smart Binary Large Object. This large object is referred to as the ora_ersb.

      Recovery time is the time taken by the failed MediaSense server to synchronize data with the surviving server after the failed server comes back in service. The length of recovery time for a failed server depends on the following factors:

      • Volume of data written to the surviving server when one server is down

      • Duplex network connection speed between the two servers

      • Level of call load running when recovery is in progress

      • Whether replication stopped on the surviving server

      A failed MediaSense system can degrade at two levels:

      • When ora_ersb is less than 90 percent full. If the failed server is brought back before ora_ersb is 90 percent full on the surviving server, no metadata is lost.

      • When ora_ersb is more than 90 percent full. If the ora_ersb becomes 90 percent full on the surviving server before the failed server is restored, replication stops on the surviving server. This allows the surviving server to continue to write data so that no metadata is lost. When the failed server comes back into service, replication must be reestablished and it may take longer for services to be ready. It may take substantially longer to synchronize the data after the failed server comes back into service.

      In both situations, when the failed server is back up and available, replication automatically starts to catch up. No manual intervention is required.

      For details about failure recovery times, see the Cisco MediaSense Design Guide.

      MediaSense Requirements

      This section identifies requirements for MediaSense.

      Media Storage Requirements

      Cisco provides an Open Virtualization Archive (OVA) virtual machine (VM) template with options for primary and secondary servers, for expansion servers, and for smaller configurations. These template options specify the supported VM configurations for MediaSense servers. These template options specify, among other things, a memory footprint and a requirement for the available CPUs on specifically identified servers. You must use this Cisco-provided template in all of your MediaSense Servers.

      To ensure high availability in environments with two or more MediaSense servers, you must install the primary and secondary servers on different physical hosts.

      For more information, see the Cisco MediaSense Design Guide.

      Hardware Requirements

      MediaSense is packaged with the Linux-based Unified Communications Operating System (OS), an appliance model developed by Cisco.

      An approved servers for MediaSense must meet the following hardware requirements:

      For more information about hardware limitations, see the Cisco MediaSense Release Notes on Cisco.com (CDC).

      Software Requirements

      MediaSense must meet the following software requirements:

      • The required Unified Communications Manager cluster must already be configured and deployed before you set up MediaSense.

      • The MediaSense administration web interface uses approved web browsers. For a list of approved web browsers, see the Cisco MediaSense Design Guide.

      License Requirements

      The primary licensing and feature activation method for MediaSense is trust-based licensing, therefore, you do not need to install any MediaSense licenses.

      Other Requirements

      MediaSense must have an uninterrupted power supply at all times to prevent unpredictable behavior due to power failure.

      Port Usage

      The section identifies the TCP and UDP ports that are used by MediaSense.


      Note
      Users cannot configure these ports. The table below shows how MediaSense is configured when it is installed.

      The columns in the table below provide the following information:

      • Server or application protocol— The name of the open or private application protocol.

      • Server protocol and port— The TCP or UDP port that the server or application is listening on, along with the IP address for incoming connection requests when acting as a server.

      • Remote protocol and port— The TCP or UDP port that the remote service or application is listening on, along with the IP address for incoming connection requests when acting as the server.

      • Remote device— The remote application or device making a connection to the server or service.

      • Used by— The service, services, or agents that use each port or ports.

      Server or

      Application Protocol

      Server

      Protocol and Port

      Remote

      Protocol and Port

      Remote Device

      Used by

      HTTPS

      TCP 443, 8443

      Any

      Web browser

      Administration, serviceability

      HTTPS

      TCP 8440

      Any

      Client application

      API access

      HTTPS

      TCP 9443

      Any

      Client application

      Used by media service to redirect authenticated requests.

      HTTPS

      TCP 8446

      Any

      Web browser, API client

      Call control service.

      HTTPS

      TCP 9081

      Any

      Client application

      Used by media service to redirect authenticated requests.

      HTTP

      TCP 80, 8080

      Any

      Web browser

      Administration, serviceability

      HTTP

      TCP 8081

      Any

      Web browser, API client

      Call control service

      HTTP

      TCP 8085

      Any

      Another CMS node

      Call control service

      HTTP

      TCP 8087

      Any

      CMS cluster nodes only

      System service

      HTTP

      TCP 8088

      Any

      CMS cluster nodes only

      Configuration service

      RTSP

      TCP 554, 8554

      Any

      RTSP media player

      SM agent

      RTSP

      TCP 9554

      Any

      Client application or media player

      Used by media service to redirect authenticated requests.

      SIP

      TCP 5060

      UDP 5060

      TCP 5060

      UDP 5060

      Unified Communications Manager or Unified Border Element

      Call control service.

      TCP/IP

      TCP 1543

      Any

      CMS cluster nodes only

      Used by Informix ER to make connections between primary server and secondary servers.

      Used by API service or configuration service to make JDBC connections with Informix.

      Keep-alive heartbeats

      UDP 8091

      UDP 8091

      CMS cluster nodes only

      Used by a call control service to detect availability of other call control services.

      JMS

      TCP 61610

      Any

      CMS cluster nodes only

      API service

      JMS

      TCP 61612

      Any

      CMS cluster nodes only

      Call control service

      JMS

      TCP 61616

      Any

      CMS cluster nodes only

      SM agent

      Ephemeral port range

      UDP 32768 - 61000

      Any

      Phone or gateway that sends RTP media streams.

      Range of ports used by media service to receive RTP media streams.

      Ephemeral port range

      UDP 1024 - 65535

      Any

      RTSP media player which is being used to listen to an archived or live recording.

      Range of local ports used by media service to send RTP media streams.

      Was this Document Helpful?

      FeedbackFeedback

      Contact Cisco