Recovery of the Failed Unit
The host application is informed of recovery of the communication to the SIU with the same method used for notification of the failure. The RSI_MSG_LINK_ STATUS message in this case contains a status value of 1 (link to SIU recovered).
The host nominated to receive management indications (normally host 0) will also receive an API_MSG_SIU_STATUS message with status value 31 (decimal) indicating a host link has recovered to the specified host ID.
Transferring Control Back
Immediately following re-establishment of communication with the primary SIU, the application should send deactivate circuit group messages to this SIU to ensure that groups are only active on the secondary unit (this may be the case if the inter-SIU link had also failed). If the primary unit has recovered from a complete failure, no circuit groups will be active. This deactivate command will fail if the groups were not active and the application should ignore any acknowledgement of this command with a status value indicating processing failure. A “busy” response should cause the application to reattempt the deactivate.
When communication with the primary SIU has been re-established, the application should allow sufficient time to ensure that the communication is stable, thus avoiding repeatedly transferring circuits between units. After this time has expired, the application should transfer control of the affected circuit groups back to the original SIU.
This is achieved by deactivating the groups on the secondary SIU and re-activating the ones on the primary SIU. However, before the groups are deactivated, the circuits in that group should be maintenance blocked. (Using the Circuit Group Supervision Control API message). This does not affect any calls in progress, but will prevent these circuits from being selected for any new incoming calls. The application should also ensure that none of the affected circuits are selected for new outgoing calls.
When all existing calls are completed (all the circuits are therefore idle), the application should deactivate the circuit group by sending an API_MSG_COMMAND message with cmd_type of 9 to the secondary unit. When the acknowledgement that this command has been success- fully processed has been received, the groups should be activated on the primary unit by sending an API_MSG_COMMAND message with cmd_type of 8.
Once the acknowledgement of the activation has been received by the application, all affected circuits should be reset. This will force the circuits to a known (idle) state and remove the blocking status. When the reset is acknowledged from the terminating switch (by receipt of a circuit group supervision control confirmation message) the application may begin exchanging call traffic with the SIU.
Circuit Group Conflict
Both SIUs in a dual-resilient configuration periodically poll each other to determine which circuit groups are active on each unit. If a group is active on both units at the same time, an API_MSG_USER_EVENT message is issued by the unit that detects the conflict, indicating the group ID of the affected circuit group. The controlling application host should issue a deactivate command to the SIU that should not be controlling the circuit group and re-synchronize the circuits in the group (on the correct SIU) by issuing a reset.
The SIUs prevent this situation from arising by automatically sending a deactivate circuit group command to the other unit on receipt of the activate command. If the nature of the failure is such that inter-SIU communication is lost, it may be impossible for the SIU to issue the automatic deactivate command. Under this circumstance, when the failed SIU recovers, circuit groups may be active from the time before the initial failure. This situation is handled by the application sending a deactivate command for all of the previously active groups immediately following restoration of the communication with the SIU.
