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.
You can use the following network services with MediaSense:
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.
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.
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.
![]() 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. |
There are multiple ways to search for the recorded media files in the Search and Play window.
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:
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 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.
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.
To deploy AgentInfo gadget on Finesse, perform the following tasks:
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>
| ||
Step 4 | The AgentInfo
gadget gets added to the Finesse desktop.
|
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:
Network layer:
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.
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 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 (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.
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.
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.
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. |
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: |
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.
UCS-E installations and all installations with fewer than 7 vCPUs are limited to one-server and two-server deployments.
A single-server deployment has one MediaSense server on the Unified Communications OS platform. All network services are enabled by default.
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.
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.
![]() 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 have a primary server, a secondary server, and one expansion server. All network services are enabled by default on all servers in the cluster.
![]() 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 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.
![]() 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.
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.
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:
The replication operation between the primary and secondary MediaSense servers differs based on the time of replication:
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]
Follow these guidelines to ensure a high availability deployment and to provide data replication:
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. |
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.
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.
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:
Approved Unified Computing System (Unified CS) servers. For a list of approved UCS servers, see the Cisco MediaSense Design Guide.
In addition to the approved servers, MediaSense can be installed on a UCS-E module inside a router. A UCS-E module is a router blade that has its own processors, storage, network interfaces, and memory. For more information about approved UCS-E models, see the Cisco MediaSense Design Guide. For more information about UCS-E modules, see http://www.cisco.com/en/US/products/ps12629/index.html.
Virtual machine requirements specific to MediaSense are available at Virtualization for Cisco_MediaSense.
For details about virtual machine templates, ESXi, sizing information, and other virtual machine-specific process details, see Unified Communications in a Virtualized Environment.
For more information about hardware limitations, see the Cisco MediaSense Release Notes on Cisco.com (CDC).
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.
The primary licensing and feature activation method for MediaSense is trust-based licensing, therefore, you do not need to install any MediaSense licenses.
MediaSense must have an uninterrupted power supply at all times to prevent unpredictable behavior due to power failure.
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. |