Latest News:

Advanced Communications and Electronic Systems (ACES) and Radisys Sign MOU to Accelerate 5G ORAN Innovation and Development

DriveNets and Radisys Partner to Enable Network Transformation Projects with European Service Providers

Next Generation InfraCo and Radisys Partner to Launch Digital Innovation Incubator in Ghana

NGIC Launches 5G In Ghana in partnership with Nokia, Radisys and Tech Mahindra, Paving the way for Digital Transformation

MG Digital Direct Expands Multi-Channel Marketing Services with Radisys' Engage Digital Platform

AccelerComm Welcomes Radisys to 5G LEO Satellite Regenerative Base Station Ecosystem Partner Program

Ramon.Space and Radisys Partner to Develop State-of-the-Art, Space-Resilient 5G Non-Terrestrial Network Solutions

Radisys Enables BridgeNET’s Transformation into a Digital Service Provider

Radisys Supports Watch Communications’ Expansion of Rural Ultra-Broadband Services

Media Server Support FAQ

Media Server Support FAQ

1. Who is eligible to open an incident report?

If you purchased product directly from Radisys Canada, ULC and you have a current support contract you are eligible to contact Radisys TAC. We ask that you provide a serial number for the product you wish to open a report against. The serial number will allow us to validate your support contract and warranty entitlement. If you purchased your product through a reseller, contact the reseller for further information.

2. What information do I need to open an incident report?

To open an incident report, you will need to provide:

  • Product Serial number
  • Type of platform
    • CMS3000, CMS6000, CMS 9000, MPX-12000
    • SCCII, SCCIII, MPCII, MPCIII, MPC IV, MPC5, MPH6
    • SWMS.
  • Full Release Number for Software or Firmware
  • Use of Product, for example: Lab, Trial, or Production
  • Severity level

3. What information will help expedite investigation of my incident report?

The following information may help expedite the incident investigation:

  • Meaningful case title stating the problem accurately

  • Detailed description of the problem and symptoms observed. Please note: limit one per incident report

  • Historical details of the problem and troubleshooting activities performed

  • Network topology

  • Output from relevant “Show” functions (Show slot status, Show Inventory, etc.) and all other relevant output

  • Relevant syslog, protocol logs, packet captures, log packages, and diagnostic files

  • Shipping address, contact name and telephone number (If hardware replacement is required)

4. What are the Media Server TAC Severity Level Definitions?

To help ensure that all incident reports are reported in a standard format, Radisys TAC has established the following severity definitions:

CRITICAL (SEVERITY 1): Problems categorized as “Critical” are problems that are service–affecting. Critical problems affect the End User’s normal business operations and have no acceptable workaround. An “acceptable workaround” is a workaround that (i) reduces the problem’s impact to the point where business operations are unaffected, and (ii) utilizes the End User’s resources at a level that is acceptable to the End User.

Examples of problems that may be classified as “Critical” are:

  • A total system failure that results in the loss of all transaction processing capability (e.g., call processing, data transmission)

  • Significant reduction in capacity or traffic handling capability

  • Inability to restart a card or a system

  • System–related loss or severe degradation of one or more primary network connections

  • Loss of access for maintenance or recovery operations

  • Loss of the system’s ability to provide any required Critical or Major alarm notification

HIGH (SEVERITY 2): Two types of problems may be categorized as “High” priority:

  • Problems that are service–affecting but that have an acceptable workaround. An “acceptable workaround” is a workaround that (i) reduces the problem’s impact to the point where business operations are unaffected, and (ii) utilizes the End User’s resources at a level that is acceptable to the End User.
  • Problems that cause major functionality to be inoperative and affect the End User’s normal business operations, but that occur in situations in which the equipment is not in–service (e.g., the equipment is in a lab environment).

Examples of High priority problems are:

  • Problems for which there is an acceptable workaround in place
  • Degradation in capacity or traffic handling capability
  • Difficulty restarting a card or the system
  • Any loss of functional visibility and/or diagnostic capability
  • Short system or subsystem outages, whose duration accumulates to greater than 5 minutes in any 24 hour period, or that continue to repeat over longer periods
  • Prevention of access for routine administrative activity
  • Significant degradation of the system’s ability to provide any required Critical or Major Trouble notification

MEDIUM (SEVERITY 3): Problems categorized as “Medium” priority are problems causing particular features or functionality to be inoperative, but that do not affect normal business operations.

Examples of Medium priority problems are:

  • Degradation of access for routine administrative capability
  • User interface problems for node management that are not service affecting.
  • Any other problems that are not service affecting.

LOW (SEVERITY 4): Problems categorized as “Low” priority are generally requests for information that are not directly related to a service outage or problem.

Examples of Low priority problems are:

  • Requests for assistance in the installation or configuration of a system or subsystem
  • Requests for documentation pertaining to a system or subsystem
  • Requests for information on product capabilities
  • Requests for feature enhancements
  • New product ideas