Recovery:

1. You can monitor destination status from SS7/Sigtran > Maintenance > Remote Signaling Points and RMU/subsystem status from SS7/Sigtran > Maintenance > Remote MTP3 Users.
   • If the subsystem's status changed to Prohibited because SCMG received a SSP message, an audit of the status of the RMU via the SCCP subsystem status test (SST) procedure is performed.
   • If the subsystem's status changed to Prohibited because SCCP received a MTP-PAUSE indication from M3RL, then recovery actions of restoring the RSP/Destination status to Available will be invoked by M3RL.
   • If the subsystem's status changed to Prohibited because SCCP received a MTP STATUS cause=unequipped user indication from M3RL, then no automatic recovery will be initiated. Only manual action at the remote node can correct a remote point code that has not been configured with SCCP.
   • If the subsystem's status changed to Prohibited because SCCP received a MTP STATUS cause=unknown or inaccessible indication from M3RL, then SCCP will automatically invoke subsystem status testing depending upon the network type:
     • ANSI: subsystem status testing of all RMUs associated with the point code.
     • ITU: subsystem status testing SCMG (SSN=1) associated with the point code.
2. Verify IP network connectivity exists between the MP server and the adjacent servers.
3. Select Alarms & Events > View History and check the event history logs for additional SS7 events or alarms from this MP server.
4. Verify the adjacent server is not under maintenance.
5. Follow local procedures to determine the reason why the far-end SSN is down. If it is not down, but it continues to be reported as down, it is recommended to contact My Oracle Support if further assistance is needed.