Contents
1 Alarm Description
This alarm is raised when the operator sets the administrative state of the Call Session Control Function (CSCF) to SHUTTINGDOWN. When this alarm is active, ongoing INVITE dialogues are not affected and the CSCF only accepts registration traffic from users that have active INVITE dialogues. Registrations from users without ongoing INVITE dialogues are rejected, with the aim to register the users in another CSCF.
When the S-CSCF is in shutting down mode, it is possible to configure the S-CSCF to limit the intensity of the redirection of registrations from users without INVITE dialogues. Registrations from users that have active INVITE dialogues are rejected or accepted, depending on the configuration of the shutting down behavior. For how to configure the shutting down behavior of the S-CSCF, refer to CSCF Configuration Management.
Stateless CSCF applications are directly able to shut down and then automatically enter the administrative state LOCKED, while stateful CSCF applications stay in SHUTTINGDOWN until all INVITE dialogues are ended and all users are de-registered.
It is possible to configure the S-CSCF to enter the administrative state LOCKED automatically after a shutting down period expires. For how to configure the shutting down period of the S-CSCF, refer to CSCF Configuration Management.
The same administrative state applies for all enabled CSCF applications in a collocated node. The enabled applications are configured by cscfISPBehavior, ecscfEnabled, eatfEnabled, and bcfEnabled. When the last collocated node has completed its shutting down activities, the entire CSCF network element is set to LOCKED. However, at any time during the SHUTTINGDOWN, the operator can manually change the administrative state to LOCKED or UNLOCKED by command.
If the alarm is not solved, the CSCF node is taken out of service and is likely to be blacklisted by neighboring SIP nodes.
|
Alarm Cause |
Description |
Fault Reason |
Fault Location |
Impact |
|---|---|---|---|---|
|
The operator has ordered the CSCF application to be shut down. |
The CSCF application is ordered to be gracefully taken out of service by the operator. |
The CSCF application is manually set to SHUTTINGDOWN (through the attribute cscfAdministrativeState), typically for maintenance purposes. This can be, for example, to remove a new network port to the CSCF, or reduce the traffic during a system upgrade. |
The attribute cscfAdministrativeState in the MOC CSCF-Application is set to SHUTTINGDOWN. |
The CSCF application slowly decreases the amount of traffic and number of registered users by moving users when they re-REGISTER. When no users are registered, the administrative state automatically changes to LOCKED. For information about how to configure the intensity and gracefulness, refer to CSCF Configuration Management. |
|
Attribute Name |
Attribute Value |
|---|---|
|
Major Type |
193 |
|
Minor Type |
6684675 |
|
Managed Object Class |
CSCF-Application |
|
Managed Object Instance |
ManagedElement=<node_name>,CscfFunction=1,CSCF-Application=CSCF |
|
Specific Problem |
CSCF Application Shutting Down |
|
Event Type |
processingErrorAlarm (4) |
|
Probable Cause |
x736OutOfService (414) |
|
Additional Text |
- |
|
Perceived Severity |
warning (6) |
2 Procedure
2.1 Handle Alarm CSCF Application Shutting Down
If cscfAdministrativeState is set to SHUTTINGDOWN, this alarm indicates that there are active INVITE dialogues in the node.
Prerequisites
- This instruction references the following documents:
- No tools are required.
- The following condition must apply:
- The alarm is raised.
Steps
- Is a reconfiguration planned on the node that requires
to take the node out of service?
Yes: Ignore this alarm until the reconfiguration has been completed and proceed to Step 3.
No: Continue to the next step.
- If this alarm does not cease, select the appropriate action:
- To graceful shutdown, see Section 2.1.1
- To force shutdown, see Section 2.1.2
- To undo shutdown, see Section 2.1.3
- Job is completed.
2.1.1 Handle Graceful Shutdown
Steps
- Wait and let the active dialogues end.
Result:
No new registrations or re-registrations for users without already established INVITE dialogues are accepted by the node, so the traffic typically fades out within the period of the maximum registration refresh time configured by cscfRegistrationRefreshMax.- Note:
- Ongoing INVITE dialogues are not ended by the CSCF.
- Wait until cscfAdministrativeState automatically changes to LOCKED.
Result:
No dialogues are active and no users are registered in the node. - Has this alarm ceased and is the alarm CSCF Application Locked
For Maintenance raised?
Yes: Proceed to Step 5.
No: Continue to the next step.
- If the alarm is not ceased, consult the next level of
maintenance support.
Further actions are outside the scope of this instruction.
- Job is completed.
2.1.2 Handle Force Shutdown
Steps
- Manually lock the node by setting cscfAdministrativeState to LOCKED.
Result:
The active dialogues close and the users de-REGISTER. - Has this alarm ceased and is the alarm CSCF Application Locked
For Maintenance raised?
Yes: Proceed to Step 4.
No: Continue to the next step.
- If the alarm is not ceased, consult the next level of
maintenance support.
Further actions are outside the scope of this instruction.
- Job is completed.
2.1.3 Handle Undo Shutdown
Steps
- Unlock the node by setting cscfAdministrativeState to UNLOCKED.
Result:
Dialogues continue and new registrations are accepted. - Has the alarm ceased?
Yes: Proceed to Step 4.
No: Continue with the next step.
- If the alarm is not ceased, consult the next level of
maintenance support.
Further actions are outside the scope of this instruction.
- Job is completed.