Operating Instructions 2/1543-AXM10104/1 Uen K

MRF H.248 Link Unavailable
Virtual Multimedia Resource Function

Contents


1 Overview

This instruction concerns alarm handling.

1.1 MRF H.248 Link Unavailable Alarm Description

The alarm is a primary alarm. The alarm is issued either by the MrfH248Interface Managed Object (MO) or the SctpEndpoint MO. The severity of the alarm is Major.

An alarm is issued when the H.248 control link signaling between MTAS and vMRF has failed to function.

In case an already established SCTP transport link loss is detected, a 30-second timer is started. If the link recovers before the timer expires, the MRF H.248 Link Recovered after Temporary Outage event is reported, and the timer is cancelled. If the link does not recover before the timer ends, the alarm is raised.

If the fault is at the local endpoint and no SCTP connection can be opened towards MTAS, the alarm is issued by the SctpEndpoint. If the SCTP connection is established and the fault is in the network or in MTAS, the alarms is issued by the MrfH248Interface MO. Traffic is impacted on each VM that is connected to the faulty MTAS.

The possible alarm causes and fault locations are explained in the table below.

Table 1   Alarm Causes

Alarm Cause

Description

Fault Reason(1)

Fault Location

Impact

SCTP association is down

SCTP transport layer cannot transfer the H.248 messages

SCTP transport unavailable

vMRF

Network

MTAS

No new sessions can be set up on the affected link(s) while the alarm is active. Ongoing calls are not impacted.

No ServiceChange response is received from MTAS

H.248 layer connectivity failure between MTAS and vMRF

Timeout for ServiceChange transaction reply

MTAS

No new sessions can be set up on the affected link(s) while the alarm is active. Ongoing calls are not impacted.

Protocol negotiation failed

There is a functional incompatibility between MTAS and vMRF

H.248 profile mismatch, or

H.248 version mismatch,

or

H.248 error code received from MTAS

MTAS

vMRF

No new sessions can be set up on the affected link(s) while the alarm is active. Ongoing calls are not impacted.
(1) Fault reason is described in the additional info field of the alarm and it is used when analyzing the alarm.
Note:

The H.248 protocol negotiation failure can occur as a result of the maintenance activity.

If the alarm is not solved, all H.248 communication between MTAS and vMRF stays down. The alarm is ceased automatically if it was raised due to timeout while waiting for ServiceChange reply and ServiceChange reply is received from MTAS, or if the MrfH248Interface MO is locked during the procedure, in which case all traffic towards the MTAS will stop.

The alarm attributes are listed and explained in Table 2.

Table 2   Alarm Attributes

Attribute Name

Attribute Value

Major Type

193

Minor Type

5308419

Managed Object Class

MrfH248Interface

SctpEndpoint

Managed Object Instance

ManagedElement=1,MediaResourceFunction=1,MrfH248Control=1,MrfH248Interface= <MrfH248InterfaceId>

ManagedElement=1,Transport=1,SctpEndpoint=<SctpEndpointId>

Specific Problem

MRF H.248 Link Unavailable

Event Type

communicationsAlarms (2)

Probable Cause

CommunicationsProtocolError (305)

Additional Text

<reason>(2); uuid:<uuid>(3)

Perceived Severity

major (4)
(2) <reason> is one of the fault reasons from Table 1.
(3) If the alarm is issued by the SctpEndpoint MO, <uuid> is the identity of the Virtual Machine from which the alarm is issued.

2 Procedure

The following procedure describes how to cease a MRF H.248 Link Unavailable alarm.

2.1 Analyzing the Alarm

Steps

  1. See details for the alarm MRF H.248 Link Unavailable. Check the additional info field of the alarm.

2.2 Clear an Alarm when SCTP Association Is Down

Steps

  1. Identify the issuing MO of the alarm.
  2. Based on the issuing MO, continue with one of the following sections:

2.2.1 Local Endpoint Configuration Fault

Steps

  1. Check the localIpAddress attribute of the SctpEndpoint MO. If the attribute has no IP address, check the DHCP server to see if it allocates a proper IP address.
  2. Check the signalingLocalPort attribute of the MrfH248Control MO. The value specifies the local SCTP port used towards MTAS for every SctpEndpoint MO.
  3. Reconfigure the signalingLocalPort attribute of the MrfH248Control MO if needed. To do this, lock all the associated MrfH248Interface MOs before the procedure, by setting the value of the attribute, administrativeState to LOCKED. Unlock them after the reconfiguration, by setting the value of the attribute, administrativeState to UNLOCKED.
    Note:

    By locking the MrfH248Interface MO, the alarm will be automatically ceased and all traffic towards the MTAS will stop.

  4. If the alarm remains, consult the next level of maintenance support. Further actions are outside the scope of this instruction. Continue to Perform Concluding Routines.

2.2.2 Remote Endpoint Configuration Fault

Steps

  1. Check the remotePortNumber and remoteIpAddress attributes of the MrfH248Interface MO. These are restricted values and cannot be reconfigured without deleting and recreating the MO.
  2. Ensure that the IP address and port defined in the vMRF VNF match with IP address and port defined in the MTAS. If the alarm has ceased, continue to Perform Concluding Routines.
  3. To reconfigure the attributes mentioned in Step 1, the MrfH248Interface MO must be locked, deleted, and created again. If the alarm has ceased, continue to Perform Concluding Routines.
    Note:

    By locking the MrfH248Interface MO, the alarm will be automatically ceased and all traffic towards MTAS will stop.

  4. If the alarm is issued again, consult the next level of maintenance support. Further actions are outside the scope of this instruction. Continue to Perform Concluding Routines.

2.3 Clear an Alarm when No ServiceChange Response Is Received from MTAS

Steps

  1. Ensure that the IP address and port defined in the vMRF VNF match with IP address and port defined in MTAS. If the alarm has ceased, continue to Perform Concluding Routines.
  2. If the alarm remains, consult the next level of maintenance support. Further actions are outside the scope of this instruction. Continue to Perform Concluding Routines.

2.4 Clear an Alarm when Protocol Negotiation Failed

Steps

  1. If the additional info indicated a H.248 profile or version mismatch, confirm that the MTAS has the correct H.248 version.
  2. If the additional info described a H.248 error code received from MTAS, contact the MTAS operators with the error code.
  3. After all possible procedures on MTAS side are done, view the currently active alarms in the alarm list.
  4. If the alarm is still active, lock the MrfH248Interface MO that issued the alarm. To do this, select the MO and set the value of the attribute, administrativeState to LOCKED.
  5. Unlock the MrfH248Interface MO. To do this, select the MO and set the value of the attribute, administrativeState to UNLOCKED. Continue to Perform Concluding Routines.
    Note:

    By locking the MrfH248Interface MO, the alarm will be automatically ceased and all traffic towards MTAS will stop.

  6. If the alarm is raised again, consult the next level of maintenance support. Further actions are outside the scope of this instruction. Continue to Perform Concluding Routines.

2.5 Perform Concluding Routines

Steps

  1. Make a report.
  2. The job is completed.

Copyright

© Ericsson AB 2016, 2017. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.